کاربر یک تغییر را ذخیره می‌کند و پیام «انجام شد» گوشه صفحه ظاهر می‌شود. معلوم نیست چه چیزی انجام شده و آیا اطلاعات روی سرور ثبت شده یا فقط در فرم تغییر کرده است. طراحی اعلان از همین ابهام شروع می‌شود: پیام باید به یک رویداد مشخص مربوط باشد و نتیجه آن را با میزان اطمینان درست بیان کند. شکل Toast یا Banner پس از تعیین محتوا و اهمیت انتخاب می‌شود.
همه خبرها نیاز به وقفه ندارند. ثبت یک علاقه‌مندی کوچک، شکست پرداخت و تغییر مجوز یک حساب پیام‌های هم‌ارز نیستند. اگر همه با یک رنگ، صدا و محل نمایش اعلام شوند، مخاطب باید اهمیت را از متن حدس بزند. یک نظام اعلان قابل نگهداری مشخص می‌کند چه رویدادی به پیام نیاز دارد، پیام کجا می‌ماند و فرد پس از خواندن چه کاری می‌تواند انجام دهد.
اعلان داخل صفحه را از Push جدا کنید
پیامی که نتیجه عمل جاری را در خود رابط نشان می‌دهد با نوتیفیکیشن سیستم‌عامل تفاوت دارد. Toast یا پیام کنار فرم ممکن است فقط به ساختار HTML و مدیریت وضعیت نیاز داشته باشد. Push موضوع دیگری است و به مجوز، زیرساخت و سیاست ارسال مربوط می‌شود. درخواست مجوز اعلان برای نشان دادن موفقیت یک ذخیره ساده، این دو نیاز را بی‌دلیل به هم وصل می‌کند.
در طراحی محصول، نام‌ها را با رفتار تعریف کنید. اگر Banner صرفاً در بالای صفحه است، معلوم کنید آیا موقت است، پس از خروج باقی می‌ماند یا قابل رد شدن است. اگر مرکز اعلان دارید، بدانید کدام پیام‌ها در آن ذخیره می‌شوند. تقسیم‌بندی باید به عمر پیام و اقدام مربوط شود؛ برچسب‌های ظاهری به‌تنهایی توضیح نمی‌دهند کاربر چگونه خبر را دوباره پیدا می‌کند.
خبر را با نتیجه قابل اعتماد بنویسید
«تغییرات ذخیره شد» فقط زمانی مناسب است که ذخیره مورد نظر واقعاً تأیید شده باشد. اگر عملیات در صف است، «در انتظار ارسال» دقیق‌تر است. اگر فایل روی دستگاه ذخیره شده اما هنوز همگام نشده، این دو وضعیت را جدا بیان کنید. پیام موفقیت زودهنگام ممکن است کاربر را به بستن صفحه تشویق کند و با نتیجه واقعی ناسازگار باشد. متن باید با مرحله‌ای که سامانه می‌شناسد هماهنگ بماند.
در پیام خطا، نام عمل و راه ادامه را بیاورید: «گزارش ارسال نشد. اتصال را بررسی و دوباره تلاش کنید». علت را فقط وقتی بنویسید که شناخته شده است. نسبت دادن هر شکست به اینترنت کاربر، وقتی خطای سرور رخ داده، گمراه‌کننده است. کد فنی می‌تواند برای پشتیبانی به شکل فرعی وجود داشته باشد، اما نباید تنها توضیح برای فردی باشد که می‌خواهد کارش را تمام کند.
جای پیام باید به محل عمل مربوط باشد
خطای یک فیلد بهتر است نزدیک همان فیلد توضیح داده شود. خبر سراسری مانند اختلال سرویس می‌تواند در ناحیه مشخص صفحه باشد. نتیجه یک عمل کوچک ممکن است با پیام کوتاه نزدیک کنترل یا Toast اعلام شود. اگر مخاطب برای فهم خطای فرم باید به گوشه دور صفحه نگاه کند، ارتباط میان عمل و پیام ضعیف است. رنگ قرمز در یک اعلان عمومی جای نشان دادن محل اصلاح را نمی‌گیرد.
در صفحه‌های باریک، پیام شناور ممکن است روی کنترل اصلی یا متن لازم قرار بگیرد. محل نمایش را با نوارهای ثابت، صفحه‌کلید نرم‌افزاری و محتوای طولانی هماهنگ کنید. چیدن چند Toast روی هم می‌تواند بخش بزرگی از صفحه را بپوشاند. برای پیام‌های تکراری، ادغام یا به‌روزرسانی همان وضعیت اغلب از ساخت یک پیام تازه برای هر رخداد قابل فهم‌تر است.
زمان ثابت سه تا پنج ثانیه قانون عمومی نیست
طول متن، نیاز به عمل و شرایط خواندن بر زمان لازم اثر دارند. پیام کوتاه تأیید ممکن است موقت باشد؛ پیام دارای دکمه اصلاح یا فرصت Undo نیاز متفاوتی دارد. اگر خبر مهم پس از چند ثانیه ناپدید شود و هیچ مسیر دیگری برای دیدن آن نباشد، بخشی از مخاطبان آن را از دست می‌دهند. مدت نمایش را بر اساس وظیفه انتخاب کنید و از یک زمان ثابت برای تمام پیام‌ها پرهیز کنید.
برای رخدادی که نتیجه‌اش در خود صفحه دیده می‌شود، Toast می‌تواند تأیید مکمل باشد. برای خطایی که انجام کار را متوقف کرده، توضیح پایدار نزدیک محل عمل مناسب‌تر است. اگر پیام موقت اقدام دارد، رفتار هنگام focus، توقف زمان و دسترسی دوباره به عمل را روشن کنید. دکمه‌ای که پیش از رسیدن کاربر با صفحه‌کلید حذف می‌شود، مسیر عمل قابل اتکایی ایجاد نمی‌کند.
قابل رد شدن به معنی حل شدن نیست
بستن Banner فقط باید پیام را از دید خارج کند، مگر اینکه رفتار دیگری به‌صراحت توضیح داده شده باشد. اگر مشکل همچنان وجود دارد، وضعیت باید جای دیگری قابل مشاهده بماند. در اختلال اتصال، بستن خبر نباید رابط را به ظاهر موفق برگرداند. نام کنترل هم بهتر است «بستن پیام» باشد تا کاربر آن را با تأیید یا انجام اقدام اشتباه نگیرد.
برای پیام‌های سراسری، تصمیم بگیرید رد کردن مربوط به همان صفحه، نشست یا حساب است. نمایش دوباره در هر تغییر مسیر می‌تواند خسته‌کننده باشد؛ پنهان کردن دائمی خبر مهم هم ممکن است مخاطب را بی‌اطلاع نگه دارد. این تصمیم باید با نوع خبر و زمان اعتبار آن هماهنگ باشد. ذخیره وضعیت خواندن نیاز به قرارداد داده مشخص دارد و نباید از ظاهر یک علامت ضربدر حدس زده شود.
وقفه را برای تصمیم واقعی نگه دارید
Modal مسیر فعلی را قطع می‌کند و باید برای موقعیتی استفاده شود که تصمیم یا تعامل متمرکز لازم است. اعلام موفقیت یک عمل کوچک معمولاً به چنین وقفه‌ای نیاز ندارد. اگر کاربر مجبور شود برای هر ذخیره روی «باشه» کلیک کند، طراحی به کار تکراری اضافه کرده است. شدت نمایش را از پیام مهم برداشت نکنید؛ مهم بودن خبر همیشه به معنی نیاز به قطع تعامل نیست.
وقتی واقعاً Dialog لازم است، نام، focus اولیه، مسیر بستن و بازگشت focus باید طراحی شوند. این مسئولیت‌ها با افزودن یک لایه نیمه‌شفاف حل نمی‌شوند. راهنمای طراحی Modal و Dialog درباره همین قرارداد تعاملی توضیح می‌دهد. برای هشدار دارای تصمیم، نتیجه هر دکمه را صریح بنویسید؛ «بله» و «خیر» بدون اشاره به عمل، خواندن دوباره متن را به مخاطب تحمیل می‌کند.
خبر بدون گرفتن focus هم باید قابل دریافت باشد
راهنمای Status Messages در WCAG درباره اعلام تغییر وضعیت بدون جابه‌جایی focus توضیح می‌دهد. پیام موفقیت، تعداد نتایج یا وضعیت انتظار می‌تواند در ناحیه مناسب با نقش برنامه‌ای روشن قرار گیرد. صرف تغییر رنگ یا افزودن متن در گوشه صفحه تضمین نمی‌کند که همه کاربران از آن آگاه شوند. ساختار اعلام باید با اهمیت و نوع پیام هماهنگ باشد.
الگوی Alert در W3C برای خبرهای فوری توضیح دارد و درباره وقفه و حذف سریع پیام‌ها هشدار می‌دهد. استفاده از alert برای هر تغییر کوچک می‌تواند جریان خواندن را شلوغ کند. پیام‌های معمول را با شدت مناسب اعلام کنید و focus را برای تأیید یک ذخیره بی‌دلیل منتقل نکنید. موضوع، رساندن خبر است؛ جابه‌جایی اجباری مخاطب باید دلیل جدا داشته باشد.
Undo باید با عمل واقعی هماهنگ باشد
اگر بعد از حذف، امکان Undo می‌دهید، معلوم کنید چه چیزی قابل بازگرداندن است و تا چه زمانی. حذف محلی یک ردیف با عملی که وابستگی‌های سرور را تغییر داده یکسان نیست. دکمه بازگردانی نباید ظاهراً عمل کند ولی داده را ناقص برگرداند. برای کارهایی که واقعاً برگشت‌پذیر نیستند، پیام و مرحله تصمیم باید همین محدودیت را قبل از انجام عمل بیان کنند.
در عملیات چندتایی، پیام باید دامنه نتیجه را روشن کند. «پنج فایل حذف شد» با «چهار فایل حذف شد و یک مورد نیاز به مجوز دارد» فرق دارد. نتیجه جزئی را موفقیت کامل معرفی نکنید. فرد باید بتواند موارد باقی‌مانده را پیدا کند و لازم نباشد همه عملیات را از ابتدا تکرار کند. جزئیات طولانی می‌توانند در بخش قابل باز کردن باشند، ولی خلاصه باید واقعیت نتیجه را منتقل کند.
از تکرار و افشای اطلاعات جلوگیری کنید
یک خطای پیوسته نباید هر لحظه پیام تازه بسازد. وضعیت قطع اتصال را به صورت پایدار نمایش دهید و هنگام بازگشت خبر را به‌روزرسانی کنید. اعلان‌هایی که از چند منبع می‌آیند نیاز به اولویت و جلوگیری از تکرار دارند. نمایش نام فایل خصوصی یا متن پیام شخصی در اعلان عمومی هم باید با زمینه و تنظیمات مخاطب هماهنگ باشد؛ جزئیات ضروری را در محیط مناسب نشان دهید.
برای تحویل سیستم اعلان، جدول رویدادها، متن، شدت، محل، عمر و اقدام را بنویسید. حالت انتظار، شکست، موفقیت جزئی و تکرار را جدا مشخص کنید. طراحی بازخوردهای کوچک به هماهنگی همین پیام‌ها با وضعیت کنترل کمک می‌کند. اعلان مناسب خبر واقعی را به‌موقع می‌رساند و امکان ادامه کار را حفظ می‌کند؛ تعداد کم یا ظاهر زیبا به‌تنهایی این نتیجه را نمی‌سازند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!