اعلان باید به کاربر بگوید چه رخ داده، چرا به او مربوط است و آیا اقدامی لازم دارد. یک نشان قرمز با عدد، این سه سؤال را پاسخ نمی‌دهد. Notification Center محل نگهداری و پیگیری اعلان‌های محصول است و باید بتواند اطلاعات مهم را از خبرهای کم‌اهمیت جدا کند. طراحی از تعریف رویداد و مخاطب شروع می‌شود، نه از انتخاب آیکون زنگ.
مرکز اعلان داخل برنامه با اعلان سیستم‌عامل یا Push یکسان نیست. ممکن است کاربر مجوز اعلان بیرونی را ندهد ولی همچنان پیام‌های داخل حسابش را ببیند. این دو کانال باید با قرارداد روشنی هماهنگ باشند. رد مجوز مرورگر نباید به‌طور خودکار به معنی رد تمام اطلاعات عملیاتی تفسیر شود و نباید کار عادی برنامه را بی‌دلیل متوقف کند.
برای هر رویداد، مخاطب و اهمیت را تعریف کنید
در نمونه فرضی مدیریت درخواست، تغییر وضعیت، نیاز به اصلاح و خبر قابلیت تازه سه رویداد متفاوت‌اند. این مثال گزارش رفتار یک مشتری واقعی نیست. اصلاح درخواست به عمل کاربر نیاز دارد، تغییر وضعیت ممکن است فقط اطلاع‌رسانی باشد و خبر قابلیت معمولاً فوریت کم‌تری دارد. اگر همه با رنگ و لحن یکسان نمایش داده شوند، اهمیت واقعی پنهان می‌شود.
اعلان باید به فرد دارای نقش مربوط برسد. ارسال همه رخدادها برای همه کاربران، حجم پیام را زیاد می‌کند و می‌تواند داده غیرضروری را آشکار کند. کنترل مخاطب باید سمت سرور باشد؛ پنهان کردن یک کارت در رابط جای آن را نمی‌گیرد. اگر نقش یا دسترسی تغییر کرد، مسیر اعلان قدیمی نیز باید با اختیار فعلی هماهنگ شود.
قبل از افزودن رویداد، بپرسید نبود اعلان چه مشکلی ایجاد می‌کند. بسیاری از تغییرهای کوچک در صفحه مربوط قابل مشاهده‌اند و نیازی به پیام جدا ندارند. چند رخداد مرتبط می‌توانند در یک گروه خلاصه شوند. این تصمیم باید معنی را حفظ کند؛ خلاصه‌ای که عمل فوری را میان چند خبر معمولی پنهان کند، مسئله حجم را با از دست رفتن اولویت حل کرده است.
خوانده‌شده با انجام‌شده فرق دارد
باز کردن اعلان لزوماً به معنی اجرای عمل نیست. کاربر ممکن است پیام اصلاح درخواست را بخواند و هنوز فرصت اصلاح نداشته باشد. وضعیت read باید از وضعیت task جدا بماند. اگر با باز کردن مرکز، همه پیام‌ها انجام‌شده نمایش داده شوند، کاربر کار باقی‌مانده را گم می‌کند. قرارداد هر وضعیت را با نام و رفتار روشن ثبت کنید.
«علامت‌گذاری همه به عنوان خوانده‌شده» باید محدوده مشخص داشته باشد. آیا همه پیام‌های موجود در حساب است یا فقط فیلتر فعلی؟ تعداد و محدوده را پیش از عمل نشان دهید. پیام‌های تازه‌ای که بعد از عمل می‌آیند نباید تصادفاً خوانده شوند. این رفتار به زمان و شناسه عملیات وابسته است و باید در API و رابط هماهنگ تعریف شود.
حذف یا archive نیز با read تفاوت دارد. اگر حذف فقط از فهرست کاربر خارج می‌کند، نتیجه را همین‌طور توضیح دهید. پاک شدن اعلان نباید بدون قرارداد، رکورد اصلی درخواست را حذف کند. امکان بازگردانی، اگر وجود دارد، روشن باشد. نام «پاکسازی» برای چند عمل متفاوت می‌تواند مبهم باشد؛ UX Writing به نام‌گذاری دقیق کمک می‌کند.
هر کارت زمینه و مسیر معتبر داشته باشد
خلاصه باید رویداد و موضوع را معرفی کند. «یک اتفاق جدید دارید» برای درخواست، پرداخت و پیام شخصی تفاوت لازم را نمی‌دهد. عنوان رکورد یا شناسه قابل فهم می‌تواند زمینه بدهد، ولی اطلاعات حساس را بی‌دلیل در خلاصه نگذارید. زمان نیز با منطقه و قالب مناسب نمایش داده شود تا ترتیب رخدادها قابل تفسیر باشد.
لینک اعلان باید به مقصد معتبر و وضعیت فعلی برود. ممکن است رکورد حذف شده یا دسترسی کاربر تغییر کرده باشد. در این حالت، پیام توضیحی مناسب لازم است؛ صفحه خالی یا خطای عمومی مسیر را قطع می‌کند. اعلان سابقه یک رویداد است، اما مقصد ممکن است اکنون حالت دیگری داشته باشد. این تفاوت باید در تجربه قابل فهم باشد.
Quick Action مانند تأیید یا پاسخ باید همان قرارداد عمل در صفحه اصلی را رعایت کند. اگر تصمیم به اطلاعات بیشتری نیاز دارد، اجرای آن از کارت کوچک مناسب نیست. عمل حساس نباید با یک آیکون مبهم انجام شود. اگر عملیات ناموفق شد، کارت باید وضعیت معتبر را حفظ کند و نتیجه قطعی پیش از تأیید سیستم اعلام نشود.
گروه‌بندی و فیلتر به یافتن کمک کنند
گروه زمانی مانند امروز و روزهای قبل برای مرور مفید است، اما تاریخ مرجع و منطقه زمانی اهمیت دارد. گروه موضوعی می‌تواند اعلان‌های مربوط به یک درخواست را کنار هم بگذارد. خلاصه گروه باید تعداد و نوع رخداد را روشن کند. ادغام چند پیام با مخاطب یا فوریت متفاوت نباید اقدام لازم را پنهان کند.
فیلتر «مهم» به تعریف اهمیت نیاز دارد. ممکن است اهمیت از اولویت سیستم یا علامت شخصی کاربر بیاید؛ این دو را با نام یکسان مخلوط نکنید. «خوانده‌نشده» هم فقط state پیام است و الزاماً فوریت را نشان نمی‌دهد. کاربر باید بفهمد چه چیزی باعث حضور یک اعلان در فهرست شده و چگونه فیلتر را پاک کند.
در فهرست طولانی، pagination یا بارگذاری بیشتر را با حفظ موقعیت طراحی کنید. آمدن اعلان جدید نباید هنگام خواندن فهرست را ناگهان جابه‌جا کند. می‌توانید وجود پیام تازه را اعلام و اختیار نمایش آن را بدهید. اگر کاربر به جزئیات می‌رود و بازمی‌گردد، همان فیلتر و موقعیت باید طبق قرارداد حفظ شوند.
مجوز اعلان بیرونی را در زمینه درخواست کنید
راهنمای Notifications API در MDN محدودیت Secure Context، مجوز و رفتار مرورگرها را توضیح می‌دهد. درخواست مجوز باید با عمل و زمینه مناسب کاربر مرتبط باشد. باز کردن prompt در اولین ورود، پیش از توضیح نوع پیام، تصمیم آگاهانه نمی‌سازد. کاربر باید بداند چه چیزی و چرا بیرون برنامه نمایش داده خواهد شد.
حالت permission می‌تواند default، granted یا denied باشد و رفتار درخواست در مرورگرهای مختلف محدودیت دارد. اگر کاربر رد کرده، تکرار بی‌وقفه درخواست مناسب نیست. مسیر تنظیم و توضیح کانال‌های جایگزین بدهید. Push نیز معماری و Service Worker مرتبط خود را دارد؛ نام Notification Center به تنهایی این زیرساخت را فراهم نمی‌کند.
اعلان روی صفحه قفل ممکن است برای دیگران قابل مشاهده باشد. محتوای خلاصه را با حساسیت موضوع هماهنگ کنید و در صورت نیاز امکان محدود کردن پیش‌نمایش بدهید. نمایش کامل پیام خصوصی یا داده مالی فقط برای افزایش نرخ باز شدن، تصمیم مناسبی نیست. این موضوع باید در قرارداد محتوای هر کانال دیده شود.
تنظیم‌ها باید دسته و کانال را جدا کنند
کاربر ممکن است خبر قابلیت را از ایمیل بخواهد ولی اعلان فوری مرورگر را نخواهد. دسته محتوا و کانال دریافت دو انتخاب متفاوت‌اند. تنظیم‌ها باید این رابطه را واضح کنند. گزینه مبهم «اعلان‌ها خاموش» مشخص نمی‌کند آیا پیام امنیتی و پیام تبلیغاتی همگی حذف می‌شوند. محدوده هر انتخاب و استثناهای واقعی را توضیح دهید.
Digest یا خلاصه دوره‌ای برای بعضی رویدادها مناسب است. اما پیام نیازمند اقدام فوری را نباید صرفاً برای کم کردن تعداد در خلاصه دیرهنگام نگه دارید. زمان‌بندی و quiet hours باید با فوریت هماهنگ باشند. اگر استثنایی لازم است، آن را صریح معرفی کنید تا کاربر از تنظیمش انتظار متفاوتی نداشته باشد.
همگام‌سازی چند دستگاه و کانال باید جلوی پیام تکراری بی‌دلیل را بگیرد. read شدن در یک دستگاه ممکن است در دستگاه دیگر دیر به‌روز شود. state واقعی باید در منبع مناسب نگهداری شود و رابط محدودیت تأخیر را مدیریت کند. شمار badge نباید صرفاً از تعداد کارت‌های بارگیری‌شده استنباط شود اگر فهرست هنوز کامل نیست.
اعلان دیداری با Alert معنایی یکی نیست
الگوی Alert در WAI-ARIA APG برای پیام مهم و معمولاً کوتاه است و Focus را منتقل نمی‌کند. همه کارت‌های مرکز اعلان نباید role alert داشته باشند. خواندن ده‌ها پیام قدیمی در لحظه باز کردن فهرست می‌تواند فناوری کمکی را مشغول کند. ساختار list و پیام کوتاه وضعیت برای بسیاری از بخش‌ها مناسب‌تر است.
نشان unread فقط از رنگ نیاید؛ متن یا نام برنامه‌ای باید وضعیت را منتقل کند. دکمه زنگ باید نام واضح و شمار معتبر داشته باشد. اگر پنل باز می‌شود، رابطه expanded و Focus را با نوع پنل هماهنگ کنید. مقاله Popover به رفتار باز و بسته شدن و تفاوت پنل غیرModal می‌پردازد.
خطا در دریافت با نبود اعلان فرق دارد. برای empty، پیام متناسب با فیلتر بدهید و برای error، راه تلاش دوباره. Loading States ادامه مرتبط است. در تحویل، برای هر رویداد مخاطب، فوریت، کانال، مقصد و state را ثبت کنید تا افزوده شدن قابلیت تازه، مرکز را به فهرست بی‌قاعده تمام رخدادهای سیستم تبدیل نکند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!