خوردن نان تست – جامعه dev

مقدمه

من عادت بدی دارم که در وسط یک کار متوقف شوم و در حالت تفکر قدم بردارم. این کار هم به عنوان یک قدرت و هم کریپتونیت کار کرده است.

یکی از این وظایف این صفحه ساده با یک رمزعبور فراموش شده بود که من برای میمون ها در حال توسعه بودم. یک کار نسبتاً ساده یک فرم با یک زمینه هیچ چیز عجیب و غریب در مورد آن نیست.

در اینجا یک پیش نمایش کوچک از صفحه آورده شده است.

پشیمان می شوم که این وبلاگ را زودتر ننوشتم ، اگر می دانستم چه چیزی مرا به این ماجراجویی سوق داده است ، ماجراجویی که در این وبلاگ می نویسم.

GIF از یک کاربر با ایمیل gopal@echitti.com با استفاده از صفحه رمزعبور فراموش شده برای ارسال لینک برای تنظیم مجدد رمز عبور است.
هیچ مشکلی در GIF وجود ندارد ، کاربر ایمیل خود را تایپ می کند ، روی ارسال کلیک می کند و یک نان تست با هشدار به کاربر هشدار می دهد که این پیوند با موفقیت ارسال شده است.

نان تست

ناگهان چیزی در ذهن من ظاهر شد و من شروع به تأمل در کل معامله ای که کاربر داشت.

این نان تست بود ، زیرا عنوان آن را آشکار می کند.

نان تست یک مؤلفه نسبتاً متداول است که اغلب برای نمایش پیام یا گاهی بازخورد یک عمل روی صفحه استفاده می شود.
تعریف رسمی تر توسط https://web.dev این روش است:

نان تست ها پیام های کوتاه غیر متقابل ، منفعل و ناهمزمان برای کاربران هستند. به طور کلی از آنها به عنوان یک الگوی بازخورد رابط برای اطلاع کاربر در مورد نتایج یک عمل استفاده می شود.

output برچسب لزوماً استفاده نمی شود ، اما اگر به معناشناسی HTML و A11y (به طور خاص WCAG) اهمیت می دهید.

هنگامی که من نان تست خود را با استفاده از پسوند Chrome Vox آزمایش کردم تا برنامه ما را برای خوانندگان صفحه نمایش آزمایش کند ، خوب کار کرد. پیام نان تست سریعاً خود را اعلام می کند.

چیزی هنوز هم کمی از جایی به نظر می رسید و صفحه احساس ناقصی می کرد. همانطور که بیشتر در مورد آن تأمل کردم ، شروع به خواندن کردم و مقالات خوبی پیدا کردم که برای من چیزهای زیادی را روشن می کرد.

نان تست ها را می توان از دست داد

به معنای استعاره و به معنای واقعی کلمه ، نان تست ها به معنای مصرف می شوند ، از دست رفته ممکن است شما را به گرسنگی برای صبحانه خود یا در متن ما گرسنه برای بازخورد یا پیامی که در نان تست موجود بود گرسنه باشید.

بیایید بگوییم کاربر ما ، پس از ارسال فرم توسط چیزی که توجه آنها را از صفحه دور کرد ، قطع شد و در این میان نان تست ظاهر شد و سپس ناپدید شد.
وقتی کاربر توجه خود را به عقب برگرداند ، هیچ نتیجه ای از عملکرد خود نخواهد داشت. اثر درب در اینجا یک دشمن حتی بدتر است ، اگر اصلاً روی دکمه کلیک کند ، کاربر ممکن است کاملاً فراموش کند.

من به مواردی مانند این بوی می گویم و وقتی بوی زیادی جمع می شود ، برنامه بو می شود. این باعث می شود برنامه شما غیرقابل توصیف و کمتر از انگیزه باشد ، این باعث می شود که بیشتر به تجارت و بازاریابی اعتماد کنید.

بوی نان تست

در وبلاگ تعریف پیام “نان تست” ، آدریان در زمینه دسترسی ، بوی عمیق تری می دهد.

نقل قول از وبلاگ.

“با توجه به ماهیت آنها ، اگر برخی از تلاشها از ابتدا انجام نشود ، نان تست ها به احتمال زیاد از حسابرسی WCAG خارج می شوند. در زیر معیارهای موفقیت WCAG 2.1 شما باید هنگام ساخت خود یا آزمایش یکی از گزینه های موجود ، در نظر داشته باشید.”

در اینجا لیستی از قوانینی وجود دارد که احتمالاً صفحه ما نقض می کند.

1. تنظیم زمان بندی (2.2.1)
2. محتوا روی تمرکز (1.4.13)
3. اندازه هدف (2.5.5)

هنگام توسعه مؤلفه ها ، اغلب فراموش می کنیم که چگونه کاربران مختلف به قسمت های مختلف وب دسترسی پیدا می کنند. در حالی که WCAG به عنوان یک کتابچه راهنمای متراکم رفتار می شود ، می تواند بینش جالبی در مورد نحوه استفاده از قطعات یا حداقل نحوه استفاده طبیعی آنها استفاده کند.

صحبت کردن به روش دیگری WCAG بیشتر یک کتابچه راهنمای مهندسی است. در حالی که توسعه نرم افزار به ویژه توسعه Frontend به عنوان یک تلاش خلاقانه رفتار می شود ، WCAG یک راهنمای مهندسی برای آننداوور خلاق است.

فکر کنید مانند ساخت ماشین ، در حالی که می توانید یک ماشین خنک و آینده نگر به نظر برسید ، در صورت بالا بردن اهرم چشمک زن و جهت واقعی ، چشمک زن چشمک می زند ، در کل یک طراحی بد است.

به طور مشابه ، محتوای شناور روی Focus (1.4.13) یک ضربه گیر واقعی است ، هیچ میزان مشاهده ، ردیابی رویدادهای کاربر می تواند شما را از این امر نجات دهد. کاربران فشار می دهند Esc و به جای بستن نان تست عنصر دیگری مانند یک ابزار ابزار ممکن است بسته شود و این باعث می شود آنها ناامید شوند.

راه حل

بیایید مشکل را در صفحه خود حل کنیم و با شکستن مشکل خود شروع کنیم

1. موفقیت
   • برای کاربر زائد است که دوباره فرم را در مورد موفقیت ارسال کند. بنابراین پیام ما نمی تواند کوتاه مدت باشد ، زیرا نان تست ها به راحتی از دست می روند.
   • ما همچنین نمی توانیم دکمه “ارسال” را به طور دائم غیرفعال کنیم ، زیرا کاربر می تواند ورودی را تغییر دهد و دوست دارد دوباره ارسال کند.
2. خطا – خطاهای اعتبار سنجی
   • خطاهای اعتبار سنجی ساده است و ما نیازی به تغییر چیزی برای آنها نداریم ، موجود موجود عالی است.
3. خطا – ارسال
   • خطاهای ارسال نادر است و فقط از انتهای سرور می تواند رخ دهد ، بنابراین آنها یک سناریوی خاص هستند.
   • بنابراین ما می خواهیم کاربر خود را وادار کنیم که در صورت مواجهه با چنین ناهنجاری ، با پشتیبانی تماس بگیریم یا گزینه ای برای امتحان مجدد ارائه دهند.

با استفاده از دکمه ما

دکمه ما اولین نقطه تعامل در اینجا است و ما قبلاً به صورت پویا یک لودر را روی دکمه نشان می دهیم. ما پتانسیل زیادی را هدر می دهیم زیرا می توان از این عنصر پویا برای انجام کارهای بیشتر استفاده کرد.

بیایید با ترکیب دکمه خود با یک موفقیت و وضعیت شکست شروع کنیم.

export function ForgotPasswordForm() {
    const [loading, setLoading] = useState(false);
+   const [isSuccess, setIsSuccess] = useState(false);
+   const [isError, setIsError] = useState(false);
}

...

function handleSubmt() {
    try {
        //...
+       setIsSuccess(true);
+       setIsError(false);
    } catch (err) {
        //...
+       setIsError(true);
+       setIsSuccess(true);
    } finally {
        setLoading(false);
    }
}

دکمه ما اکنون می تواند متن متفاوتی را بر اساس وضعیتی که قبلاً اضافه کردیم داشته باشیم.

-   disabled={loading}
+   disabled={loading || isSuccess}
>
+  {!isError && !isSuccess && 'Submit'}
+  {!isError && 'Click to Retry'}
+  {!isSuccess && 'Submitted Successfully'}

ما دکمه موفقیت را غیرفعال می کنیم زیرا نمی خواهیم کاربر دوباره و دوباره ارسال کند زیرا این کار زائد است.

از آنجا که ما دکمه موفقیت را غیرفعال می کنیم ، باید راهی برای تنظیم مجدد حالت اضافه کنیم. به طوری که کاربر برای وارد کردن ورودی دیگر نیازی به تازه کردن صفحه نداشته باشد.

من با یک دکمه برای پاک کردن ورودی رفتم که وضعیت موفقیت را نیز تنظیم می کند.

با این کار اطمینان دادیم که کاربر راهی برای تنظیم مجدد ورودی دارد.

سرانجام برای نمایش پیام خطا ، می توانیم از نان تست موجود خود استفاده کنیم. یا فقط می توانیم متن خطا را در فرم نشان دهیم.

نتیجه نهایی به نظر می رسد

مورد موفقیت

مورد خطا

پایان

در حالی که طراحی باید قابل مشاهده ، جسورانه و تولید یک برند باشد. از طرف دیگر UX باید تا حد ممکن پنهان باشد.
یک UX خوب باید در راه کاربر باشد و احساس طبیعی تر می کند. این همیشه جزئیات کوچکی است که در UX بوی می دهد و وقتی این بوی تجمع می یابد ، UX بو می شود و محصول ناخواسته می شود.
به هیچ وجه نمی خواهم بیان کنم که نان تست ها بد هستند ، چشمان ما غالباً فریب می خورند ، فقط با پنهان کردن نان تست یا نگاه کردن به فراتر از آن ، مشکلات اساسی واضح تر به نظر می رسد.

منابع