כאשר כלי AI מייצר תוכן, מעבד סט נתונים או מריץ משימה אוטונומית, המשתמש זקוק לדרך ברורה לצאת. יותר מדי ממשקים מתייחסים לעצירת חירום כאל מחשבה מאוחרת. הם מחליפים את התווית של הכפתור מ-"Stop" ל-"Stopped" וחושבים שהעבודה הושלמה. הצבע עשוי להפוך לאפור. האנימציה עשויה להיראות חלקה. ובכל זאת, המשימה ממשיכה לרוץ בשרת, ולמשתמש אין מושג שמשהו השתבש. עבור מישהו הנשען על קורא מסך, הכשל חמור עוד יותר. הוא שומע אישור קולי לכך שהתהליך הסתיים, בעוד שהעבודה ממשיכה בשקט ברקע. זה לא באג קטן. זה שבר באמון.
השקר של כפתור עצירה שקט
כפתור עצירה גרוע משקר למשתמשים שלכם. הוא מציג את המילה "Stopped" בזמן שהמשימה ממשיכה להתבצע אי שם בתוך קונטיינר או ב-worker מרוחק. זה קורה מכיוון שמפתחי front-end נוהגים לעדכן את הממשק באופן אופטימיסטי לפני שהשרת מאשר את ההפסקה. משתמש ויזואלי עשוי להבחין בחוסר ההתאמה אם סרגל ההתקדמות ממשיך לזוז או אם הלוג ממשיך לרוץ, אך למשתמש קורא מסך אין ערוץ משני כזה. הוא תלוי לחלוטין במה שהממשק מכריז. אם טקסט הכפתור משתנה מוקדם מדי ולא משוב קולי מבהיר את המצב האמיתי, המשתמש יאמין שהמצב החירום הסתיים כשבפועל הוא לא. נגישות כאן אינה בקשת פיצ'ר. היא דרישת בטיחות.
שני מצבים שונים
בקרת חירום אמיתית חייבת לטפל בשתי אחריותיות נפרדות. ראשית, המערכת מקבלת את הבקשה שלכם. שנית, המערכת מבטלת את הסמכות (revokes authority). אלו אינם אותו הדבר. קבלה (Acceptance) פירושה שה-front end שמע אתכם והעביר את ההודעה הלאה. ביטול (Revocation) פירושה שה-back end אכן סיים את התהליך. בגלל שיהוי רשת (latency), תורות עבודה ושכבות אורקסטרציה, הפער בין שני הרגעים הללו יכול להימשך שניות. במהלך החלון הזה, הממשק שלכם חייב לומר את האמת לגבי השלב שבו אתם נמצאים. איחוד שני השלבים לרגע אחד בלבד מניח קיומה של תשתית שאינה קיימת. המשתמשים שלכם ישלמו את המחיר על האופטימיות הזו.
מיפוי ארבעת המצבים לממשק שלכם
בנו את ה-UI שלכם סביב ארבעה מצבים מפורשים, כך שהמשתמשים תמיד ידעו היכן הם עומדים.
- Running: הציגו כפתור "Stop task" עם תווית ברורה. שמרו עליו גלוי בכל עת. אל תקבורו אותו תחת טאבים או פאנלים מתקפלים (accordions).
- Requesting: השביתו את הכפתור כדי שהמשתמש לא יוכל להציף בקשות נוספות. הציגו הודעה "Stop requested". הכנות הזו חשובה. היא אומרת למשתמש שהפקודה שלו בדרך ושהמערכת טרם אישרה את ההשלמה.
- Stopped: השביתו את הכפתור. הציגו מזהה קבלה (receipt ID). זה נותן למשתמש הוכחה לכך שהשרת הגיב והעצירה נרשמה. זה הופך טענה לרשומה.
- Failed: הפעילו כפתור "Try stop again". הציגו הודעת שגיאה ספציפית. לעולם אל תשאירו את המשתמש במצב של המתנה שקטה (limbo). אם השרת חזר ב-timeout או החזיר שגיאה, אמרו זאת.
מצבים אלו צריכים להניע משוב ויזואלי וקולי כאחד. כאשר המצב משתנה, קוראי מסך חייבים להכריז על התווית והסטטוס החדשים באמצעות אזור חי (live region) מנוהל כראוי. כפתור מושבת בשילוב עם הכרזה טקסטואלית מונע בלבול לגבי השאלה האם הבקרה עדיין פעילה.
כללי עיצוב שעומדים בלחץ
בקרות חירום נושאות נטל עיצובי שונה מכפתורים רגילים. משתמשים עשויים להיות חרדים, ממהרים או מגיבים לפלט בלתי צפוי. הממשק שלכם חייב להישאר שמיש תחת הלחץ הזה.
אל תשתמשו בצבע כאות היחידה שלכם. כפתור שהופך מאדום לירוק עוזר לחלק מהמשתמשים הרואים, אך למשתמשים עם עיוורון צבעים ולמשתמשי קורא מסך דרושים שינויים טקסטואליים ומבניים. שלבו צבע עם תוויות מפורשות, אייקונים עם חלופות טקסטואליות והכרזות על מצב המערכת.
אל תסתירו פקדים בתפריטי ריחוף (hover). אף אחד לא אמור לחפש בתוך תפריט נפתח בזמן מצב חירום. כפתור העצירה שייך לפורמט המרכזי של המסך (primary viewport), ותמיד צריך להיות נגיש ללא צורך בתנועות עכבר מדויקות במיוחד.
הפכו את הכפתורים לקלים ללחיצה עם סמן. לחץ מפחית את השליטה המוטורית העדינה. השתמשו ב-padding נדיב ובשטח לחיצה (hit target) גדול. אם המשתמש רועד או משתמש ב-trackpad ברכבת בתנועה, הוא עדיין אמור להצליח לבצע את הלחיצה.
ודאו שמשתמשי מקלדת יכולים להגיע לכפתור במהירות. סדר ה-tab לא אמור לאלץ מישהו לעבור דרך שלושים אלמנטים שניתן להתמקד בהם לפני ההגעה לבקרת החירום. שקלו קישור דילוג (skip link) או מיקום פוקוס לוגי שמציב את פעולת העצירה בהישג יד מיידי.
הימנעו מקיצורי מקלדת מקריים. קיצורי דרך גלובליים שעוצרים תהליך צריכים להשתמש בשילובים שקשה להפעיל בטעות. אם קיצור דרך נפוץ לשמירה או להדפסה חופף לפקודת העצירה שלכם, מישהו יפעיל אותו בטעות ויאבד עבודה.
אל תשתמשו באישור רב-שלבי במצבי חירום. תיבת דו-שיח לאישור היא חומה, לא מעקה בטיחות. עד שהמשתמש יקרא "האם אתה בטוח?" וילחץ שוב, ייתכן שהפלט הלא רצוי כבר נשלח. פעולה אחת נחרצת צריכה להספיק.
אישורים, אובדן רשת ומגבלות כנות
מזהה אישור (receipt ID) מוכיח שהשרת הגיב. הוא לא מוכיח שכל השפעה המשכית (downstream effect) בוטלה. משימת ה-AI שלכם עשויה הייתה להפעיל ממשקי API חיצוניים, כתיבת קבצים או תורות הודעות עד שהגיעה פקודת העצירה. עצירת האורקסטרטור (orchestrator) אינה מבטיחה שכל תהליך בן (child process) הופסק באופן מיידי. היו כנים לגבי מגבלה זו בהודעות שלכם ובתיעוד שלכם.
עליכם גם לתכנן עבור מצבי כשל שמתרחשים מחוץ לחדר השרתים שלכם. בדקו מה קורה כשהמשתמש מאבד קישוריות לרשת מיד לאחר לחיצה על עצור. בדקו מה קורה כשהתגובה לוקחת עשר שניות במקום מאה מילישניות. אם הבקשה נתקעת, הממשק שלכם צריך לעבור למצב של פקיעת זמן (timeout) למצב של כשל, במקום להישאר תקוע ב-"Requesting" לנצח. למשתמשים מגיע לדעת מתי הקשר נותק.
איך לבדוק כאילו זה באמת משנה
אימות אינו יכול להיות מחשבה בדיעבד. הריצו את הממשק שלכם בתנאים אמיתיים שמשתמשים עם מוגבלויות נתקלים בהם מדי יום.
ניווט באמצעות מקלדת בלבד. נתקו את העכבר. עברו באמצעות Tab בכל מצב. ודאו שניתן להגיע לכפתור העצירה מכל מקום בתהליך העבודה מבלי לכלוא את הפוקוס או ליצור עצירות Tab בלתי נראות.
זום של 200% בדפדפן. הגדילו את הדף. בדקו האם כפתור העצירה מסתדר מחדש (reflows) או נעלם. משתמשים עם ראייה מוגבלת מסתמכים על זום, וקריסת פריסה (layout collapse) מסתירה לעיתים קרובות בקרים קריטיים.
הגדרות תנועה מופחתת. מצב ה-"Requesting" שלכם עשוי להשתמש באנימציית פעימה או בטעינה מסתובבת. כבדו את prefers-reduced-motion. ספקו אינדיקטורים ויזואליים סטטיים לצד כל תנועה, כך שמשתמשים שמבטלים אנימציות עדיין יקבלו משוב ברור על המצב.
סדר ההכרזות של קורא מסך. השתמשו ב-live region כדי לשדר שינויי מצב, אך בדקו את הרצף בקפידה. סדר ההכרזה צריך להתאים להתקדמות הלוגית של האירועים. אם הכפתור מבוטל לפני שקורא המסך אומר "Stop requested", בדקו האם הרצף הזה יוצר בלבול. באגים קטנים בתזמון בטכנולוגיה מסייעת עלולים לעוות את ההודעה, לכן ודאו זאת עם קורא מסך אמיתי במקום להניח שהסימון (markup) לבדו יספיק.
השורה התחתונה
בניית עצירת חירום נגישה פירושה לכבד את המשתמשים שלכם מספיק כדי לומר להם את האמת. הממשק צריך לדבר בצורה פשוטה, לנוע בצורה צפויה, ולעולם לא להעמיד פנים שבקשה היא אותה דבר כמו תוצאה. כשהלחץ גבוה והנתונים בסכנה, בהירות מצילה יותר מאשר זמן. היא מצילה אמון. כפתור עצירה כנה לא רק עוצר משימה. הוא מוכיח שהמוצר שלכם בטוח להפעלה מלכתחילה.