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