טיפול בשגיאות API בממשק - UX שלא מתעלם מהמשתמש

תארו לעצמכם שאתם ממלאים טופס באתר, לוחצים על "שלח", ופתאום כלום לא קורה. אין הודעה, אין אינדיקציה, שום דבר. או גרוע מזה - מופיעה על המסך הודעת שגיאה גולמית עם מחרוזת JSON ארוכה שאף משתמש רגיל לא יבין. זה בדיוק הרגע שבו אפליקציה טובה נבדלת מאפליקציה גרועה, ורוב המפתחים משקיעים בו הרבה פחות תשומת לב ממה שהוא דורש.

לא כל שגיאה נולדה שווה

הטעות הכי נפוצה היא להתייחס לכל שגיאה כאילו היא אותו הדבר. אבל שגיאת רשת, שגיאת קלט ושגיאת שרת הן שלושה מצבים שונים לגמרי, וכל אחד דורש טיפול אחר.

שגיאת חיבור, כלומר המכשיר של המשתמש פשוט לא הצליח להגיע לשרת, אומרת שכדאי להציע לו לבדוק את החיבור לאינטרנט ולנסות שוב. שגיאת 4xx, למשל קלט לא תקין או משתמש לא מחובר, היא באחריות המשתמש, וההודעה צריכה להסביר מה בדיוק צריך לתקן. שגיאת 5xx, כלומר תקלה בצד השרת, היא לא באשמת המשתמש בכלל, וההודעה צריכה לשקף את זה בלי להטיל עליו אשמה.

ההבדל הזה קריטי כי הוא קובע גם את הטון של ההודעה וגם את הפעולה שתציעו למשתמש בעקבותיה.

מה המשתמש באמת צריך לראות

כלל אצבע פשוט: משתמש רגיל לא צריך לראות שום דבר שמתחיל ב-Error 500 או מכיל שם של פונקציה מהקוד שלכם. תרגמו כל שגיאה טכנית להודעה אנושית שמסבירה מה קרה ומה אפשר לעשות בקשר לזה.

במקום "Request failed with status code 400" עדיף לכתוב "לא הצלחנו לשמור את הפרטים, בדקו שכל השדות מלאים כראוי". במקום להציג stack trace על המסך, שמרו את הפרטים הטכניים ביומן פנימי לצורך דיבוג, והציגו למשתמש רק את מה שרלוונטי לו. זה לא אומר להסתיר מידע, זה אומר לתרגם אותו לשפה שהוא מבין.

הרביעייה המלאה - לא רק מסך שמח

כשמתכננים ממשק שתלוי בנתונים מהשרת, קל מאוד לתכנן רק את מצב ההצלחה - הנתונים הגיעו, הכל יפה. אבל בפועל יש ארבעה מצבים שצריך לעצב מראש: טעינה, שגיאה, ריק, והצלחה.

מצב הטעינה מראה למשתמש שמשהו קורה ברקע. מצב השגיאה מטפל במקרה שהבקשה נכשלה. מצב ריק חשוב לא פחות, ולעיתים קרובות נשכח - מה קורה כשהבקשה הצליחה אבל פשוט אין תוצאות להציג, למשל רשימת קניות ריקה? הצגת מסך ריק בלי הסבר גורמת למשתמש לחשוב שמשהו נשבר. ומצב ההצלחה הוא כמובן המסך המלא עם הנתונים. תכנון מראש של כל הארבעה, ולא רק הצלחה, הוא ההבדל בין ממשק שמרגיש מקצועי לממשק שמרגיש חצי אפוי.

מתי כדאי לתת כפתור נסה שוב

לא כל שגיאה מצדיקה כפתור "נסה שוב", אבל כשמדובר בשגיאת רשת או שגיאת שרת זמנית, זה בדיוק המקום. תנו למשתמש דרך פשוטה לחזור על הפעולה בלי שהוא יצטרך לרענן את כל הדף ולאבד את מה שהוא כבר מילא. לעומת זאת, אם השגיאה נובעת מקלט לא תקין, כפתור נסה שוב לא רלוונטי - מה שצריך הוא הכוונה ברורה איזה שדה לתקן.

הודעה מוטבעת או התראה צפה

בחירה נוספת שחוזרת שוב ושוב היא איפה להציג את השגיאה. הודעה מוטבעת, ליד השדה הרלוונטי בטופס למשל, מתאימה לשגיאות קלט שקשורות לפעולה ספציפית של המשתמש. התראה צפה, מה שנקרא toast, מתאימה יותר לשגיאות כלליות שלא קשורות לרכיב מסוים במסך, כמו אובדן חיבור לרשת. הכלל הפשוט הוא: אם המשתמש צריך לדעת בדיוק מה לתקן ואיפה, שימו את ההודעה שם. אם זו הודעה כללית שרק צריך להביא לידיעתו, toast עדין הרבה יותר נעים.

כל העקרונות האלה נכונים לכל ספרייה או פריימוורק שתבחרו לעבוד איתו, וזה בדיוק סוג הדברים שמלמדים בקורס צד לקוח - לא רק איך לכתוב קוד שעובד, אלא איך לבנות ממשק שמתחשב במשתמש בכל מצב אפשרי.

לסיכום

טיפול טוב בשגיאות API הוא לא תוספת קוסמטית, הוא חלק מהותי מחוויית המשתמש. הבדילו בין סוגי השגיאות, תרגמו אותן לשפה אנושית, תכננו את כל ארבעת המצבים מראש, והחליטו בקפידה איפה ומתי להציג כל הודעה.

אם יש לכם שאלות או תובנות משלכם בנושא, נשמח לשמוע בקהילת הדיסקורד.

הצטרפו לקהילה בדיסקורד