نوشتن متن فرم با اقدام و پیامد روشن و قابل آزمون
کاربر پیش از زدن دکمه چه بداند؟
متن دکمه باید اقدام بعدی را روشن کند و متن کنار آن، پیامد لازم را توضیح دهد. برای هر فیلد، برچسبی بنویسید که هنگام تایپ هم دیده شود. در صورت نیاز، کنار آن توضیح دهید کاربر چه اطلاعاتی وارد کند. این متن‌ها را همراه رفتار واقعی فرم بررسی کنید. جمله‌ای مثل «ذخیره شد» فقط زمانی درست است که ذخیره‌شدن واقعاً تأیید شده باشد.
فرض کنید کسی فرم ثبت‌نام یک نشست را پر می‌کند. به دکمه‌ی «ادامه» می‌رسد، اما نمی‌داند وارد مرحله‌ی بررسی می‌شود یا ثبت‌نام نهایی انجام می‌شود. این ابهام را ابتدا در جریان محصول حل کنید. بعد نام دکمه را از همان عمل انتخاب کنید؛ مثلاً «بررسی اطلاعات» یا «ثبت‌نام در نشست».
نام فیلد و متن راهنما چه فرقی دارند؟
نام فیلد می‌گوید چه داده‌ای لازم است؛ راهنما درباره‌ی شکل یا دلیل دریافت آن توضیح می‌دهد. برای مثال، «ایمیل» نام فیلد است. جمله‌ی «پیوند ورود به نشست را به این نشانی می‌فرستیم» راهنماست و به رفتار تأییدشده نیاز دارد. نمونه‌ی داخل فیلد می‌تواند شکل ورودی را نشان دهد.
راهنمای فرم‌های W3C تأکید می‌کند متن داخل فیلد جای برچسب را نمی‌گیرد. این متن هنگام واردکردن داده ناپدید می‌شود. برچسب باید به کنترل مربوط متصل باشد تا فناوری کمکی بتواند نام درست را ارائه کند. این‌ها الزام‌هایی برای طراحی و پیاده‌سازی‌اند؛ صرفاً نوشتن جمله‌ی خوب آن‌ها را تأمین نمی‌کند.
اگر فیلدی اختیاری است، همان‌جا مشخص کنید. اگر داده فقط برای کاری خاص لازم می‌شود، زمان درخواستش را بررسی کنید. توضیح مبهم «برای ارائه‌ی خدمات بهتر» دلیل مشخصی به خواننده نمی‌دهد. دلیل واقعی را از مسئول محصول بگیرید. اگر استفاده از داده هنوز روشن نیست، وعده‌ای به متن اضافه نکنید.
متن یک فرم کامل چگونه کنار هم بنشیند؟
فرم را از عنوان تا نتیجه‌ی ارسال، یک جریان پیوسته ببینید. مثال زیر یک سرویس فرضی ثبت‌نام نشست است. فرض تمرین این است که ایمیل برای ارسال پیوند ورود استفاده می‌شود و نام نمایشی اختیاری است. هیچ‌یک از این قابلیت‌ها درباره‌ی سایت والوری ادعا نمی‌شود.
متن‌ها را ابتدا بدون طراحی بصری بخوانید. آیا دلیل دریافت ایمیل معلوم است؟ کاربر می‌داند چه چیزی الزامی است؟ دکمه اقدام نهایی را می‌رساند؟ سپس وضعیت‌های انتظار و خطا را به همین فرم اضافه کنید. بدون این وضعیت‌ها، نمونه‌ی متن فقط بخشی از تجربه را پوشش می‌دهد.
| بخش | متن پیشنهادی فرضی |
|---|---|
| عنوان | ثبت‌نام در نشست طراحی پوستر |
| توضیح | ایمیل خود را وارد کنید تا پیوند ورود به نشست را برایتان بفرستیم. |
| فیلد الزامی | ایمیل |
| راهنمای ایمیل | نشانی‌ای را وارد کنید که به آن دسترسی دارید. |
| فیلد اختیاری | نام نمایشی، اختیاری |
| راهنمای نام | این نام در فهرست شرکت‌کنندگان دیده می‌شود. |
| دکمه | ثبت‌نام در نشست |
| در حال ارسال | در حال ثبت درخواست |
| نتیجه‌ی تأییدشده | ثبت‌نام شما انجام شد. پیوند ورود را به ایمیلتان فرستادیم. |
چطور خطاهای قابل پیشگیری را توضیح دهید؟
شرط لازم را پیش از ارسال نشان دهید و خطا را کنار داده‌ی مربوط توضیح دهید. اگر اندازه یا قالب فایل محدود است، آن را بعد از شکست اعلام نکنید. برای ایمیل ناقص نیز از پیام مرتبط با همان فیلد استفاده کنید. تشخیص موجودبودن یک نشانی، با بررسی شکل آن یکی نیست.
راهنمای اعلان‌های W3C، بازخورد روشن درباره‌ی نتیجه‌ی ارسال را توصیه می‌کند. راهنمای ساده‌ی رفع خطا نیز در آن آمده است. متن خطا باید با تشخیص واقعی سیستم هماهنگ باشد. اگر فقط می‌دانید درخواست کامل نشده، علت را به اینترنت یا کاربر نسبت ندهید.
برای فرم فرضی این مقاله، وضعیت‌ها در جدول زیر آمده‌اند. حفظ ورودی را هم فقط پس از آزمون وعده دهید. اگر ذخیره‌شدن در سرور نامعلوم است، تکرار ارسال باید با سازوکار محصول هماهنگ شود تا درخواست تکراری نسازد.
| وضعیت | متن نمونه | راه بعدی |
|---|---|---|
| ایمیل خالی | ایمیل خود را وارد کنید. | بازگشت به فیلد ایمیل |
| شکل ایمیل ناقص | شکل نشانی ایمیل کامل نیست. آن را بررسی کنید. | ویرایش همان فیلد |
| شکست ثبت، نتیجه معلوم | درخواست ثبت نشد. دوباره تلاش کنید. | تلاش دوباره |
| نتیجه نامعلوم | هنوز تأیید ثبت‌نام را دریافت نکرده‌ایم. | بررسی وضعیت درخواست |
عدد و جهت متن را چگونه بررسی کنید؟
واحد و قالب داده را کنار همان ورودی بنویسید. در فرم تاریخ، نوع تقویم و ترتیب روز و ماه باید روشن باشد. برای مبلغ، نام واحد را از تصمیم محصول بگیرید. نمایش فارسی نباید باعث شود ایمیل، شماره‌ی پیگیری یا بخش لاتین به ترتیب اشتباه خوانده شود.
آزمون را با داده‌ی بلند، نام چندبخشی و متن ترکیبی انجام دهید. نمونه‌ی کوتاه و مرتب، مشکل بریدگی را آشکار نمی‌کند. همچنین نتیجه‌ی کپی‌کردن و چسباندن داده را بررسی کنید. جزئیات فنی جهت متن به پیاده‌سازی وابسته‌اند؛ نویسنده می‌تواند داده‌های لازم برای آزمون را مشخص کند و مشاهده‌اش را ثبت کند.
چه آزمونی پیش از تحویل انجام دهید؟
با صفحه‌کلید از ابتدای فرم تا پایان حرکت کنید و نام هر فیلد را بخوانید. با صفحه‌خوان، ارتباط برچسب، راهنما و خطا را بررسی کنید. بعد از شکست ارسال، ببینید کاربر به کدام قسمت برمی‌گردد و آیا داده‌هایش باقی می‌مانند. متن موفقیت را هم فقط پس از مشاهده‌ی نتیجه‌ی واقعی تأیید کنید.
پس از ترجمه، نام فیلد و دکمه را با عمل واقعی تطبیق دهید. بررسی کنید معنای اقدام عوض نشده باشد. متن ترجمه‌شده را در نمایش باریک و با بزرگ‌نمایی ببینید. بریدگی یا هم‌پوشانی نباید نام فیلد و دکمه را پنهان کند.
یک فرم کوتاه از محصول خود انتخاب کنید. متن‌های فعلی، رفتار دکمه‌ها و وضعیت‌های ناقص را در جدول بگذارید. ابتدا یک ابهام پراثر را اصلاح کنید؛ مثلاً تفاوت بررسی اطلاعات و ارسال نهایی. همان مسیر را دوباره اجرا کنید و نتیجه‌ی مشاهده‌شده را همراه نسخه‌ی متن تحویل دهید.
منابع مقاله
- راهنمای W3C برای برچسب کنترل‌های فرم
اتصال برچسب به کنترل و ارائه‌ی نام درست به فناوری کمکی؛ ادعای قبولی آزمون دسترس‌پذیری مطرح نشده است.
تاریخ بررسی: ۱۲ مهر ۱۴۰۵
- راهنمای W3C برای توضیح‌های فرم
متن داخل فیلد جای برچسب نیست و با ورود داده ناپدید می‌شود.
تاریخ بررسی: ۱۲ مهر ۱۴۰۵
- راهنمای W3C برای اعلام نتیجه‌ی فرم
بازخورد روشن موفقیت و شکست و توضیح ساده‌ی رفع خطا؛ جدول فرم و پیام‌ها تألیفی و فرضی‌اند.
تاریخ بررسی: ۱۲ مهر ۱۴۰۵
در تهیه و بررسی این مقاله از هوش مصنوعی کمک گرفته‌ایم. منابع بالا برای بررسی بیشتر در دسترس‌اند. پیشنهادها را با شرایط کار خودتان بسنجید.
این روش را روی متن خودتان امتحان کنید
اشتباه یا نکتهٔ مبهمی دیدید؟ در گیت‌هاب گزارش کنید. نام مقاله و بخش مربوط کافی است؛ اطلاعات محرمانه را در گزارش عمومی ننویسید.
