שיתוף:
שגיאות נפוצות בהודעות שגיאה
כמו שאין בני-אדם מושלמים, אין תוכנות מושלמות. כדאי להמנע כבר בשלב התכנות משגיאות, אבל לפעמים יש צורך להודיע למשתמש על בעיה תפעולית. הודעות שגיאה הן קודם כל הודעות. הנה כמה הנחיות לאפיון נכון שלהן.
רובי גורדון ; 28/02/2006
הודעות שגיאה הן חלק בלתי נפרד מכל תוכנה. ליתר דיוק, הן חלק בלתי נפרד מממשק המשתמש של התוכנה.
אפשר לחלק הודעות שגיאה לשלושה סוגים עיקריים:
- שגיאות ריצה של התוכנה (כאשר הקוד נתקל במצבי קיצון, למשל נסיון לכתוב לקובץ תפוס).
- שגיאות עבודה (כאשר המשתמש מבקש מהתוכנה משהו שאין באפשרותה לספק בהקשר הנתון).
- הודעות ושאלות (אלו אינן ממש הודעות שגיאה, אבל אותם חוקים חלים עליהן בזמן האפיון. הודעה כזאת יכולה להיות למשל בקשת אישור לפני מחיקת רשומה).
אי אפשר לוותר על כל הודעות השגיאה, גם אם מטפלים במסגרת הקוד בכל מצבי הקצה. לא כל הודעת שגיאה מעידה על "באג" בתוכנה, וכדאי מאוד שלא ניצור את הרושם הזה אצל המשתמשים שלנו.
למעשה, הודעות שגיאה הן חלק שאי אפשר להפריז בחשיבותו במסגרת ממשק המשתמש. תוכנה היא אינטראקציה בין המחשב לאדם, ולא סתם נבחרה המילה "דיאלוג" ("תיבת דו-שיח") כמונח המקצועי של חלונות כאלה. זהו דו-שיח עם המשתמש, ואם לא נדבר איתו בשפתו, הוא לא יוכל לענות לנו. במילים אחרות, אם לא נקפיד על שמישות בהודעות שגיאה, נאבד את השמישות של התוכנה כולה.
במאמר הבא אנסה לספק כמה טיפים והנחיות כלליות לניסוח ולעיצוב של הודעות כאלו. נתחיל דווקא בסיכום תמציתי, אבל המשך המאמר יספק הסברים נוספים, וגם כמה חיוכים.
נתחיל דווקא בסיכום:
השתמשו בשם היישום ככותרת להודעת השגיאה:
סביבת העבודה של המשתמשים כוללת עוד יישומים חוץ מזה שלכם. הם צריכים לדעת מה מקור השגיאה.
אל תאשימו את המשתמשים:
הודעת שגיאה היא חלק מהממשק. היא צריכה לתת חיווי על פעילות התוכנה, ולא על אופן עבודתם של המשתמשים.
תארו את הבעיה במונחים פשוטים ובהירים:
הדיאלוג בין התוכנה למשתמשים צריך להיות מנוסח במונחי העבודה שלהם, ולהיות ברור וחד-משמעי.
אל תעבירו תיאורי שגיאות ריצה של שפת התכנות אל המשתמשים:
תיאורי שגיאות של שפת התכנות מיועדים למתכנתים. שפת התכנות אינה "יודעת" מהו היישום שנכתב בה, ולכן אי אפשר לספק את ההודעות הללו כתיאור של מה שהשתבש, במונחי משימות המשתמשים.
נסחו את ההודעה כשאלה:
תנו למשתמשים הצעת פתרון להשלמת המשימה שלהם. הודעת שגיאה לא צריכה לעצור את זרימת היישום, אלא להוות דיאלוג קצר בין התוכנה למשתמשים.
חשבו היטב מה צריכה להיות הבחירה של ברירת המחדל:
משתמשים לא תמיד קוראים את ההודעה שלכם. אל תגרמו להם נזק אם הם פשוט סומכים על הצעת הפתרון שאתם מספקים.
אל תסמכו על מנגנון ההודעות שמספקת שפת התכנות:
עצבו דיאלוג עשיר יותר, שאינו מוגבל למבנה הקבוע, שגם יוצר רתיעה.
הודיעו למשתמשים אם בחירתם משנה את ההעדפות הכלליות בתוכנה:
הודעה למשתמשים יכולה להיות גם קיצור דרך לשינוי תצורה, אך הקפידו לתת למשתמש לבצע בחירה אקטיבית לשינוי כזה.
ביישומי רקע השתמשו בהודעות מרחפות:
אל תפריעו את עבודתם של המשתמשים אם היישום שלכם רץ ברקע.
השתמשו בשורת המצב או בפנל הודעות
הודעות קופצות קוטעות את עבודת המשתמשים. זה השיקול המרכזי בהחלטה היכן למקם וכיצד להציג כל הודעה.
המנעו ממצבי "מילכוד 22":
אל תתנו לאבסורדים של עולם התוכנה לדלוף החוצה ולבלבל את המשתמשים.
ועכשיו לפירוט ולדוגמאות:
השתמשו בשם היישום ככותרת להודעת השגיאה
סביר להניח שהמשתמשים מפעילים כמה תוכנות במקביל. אתם צריכים להבהיר להם מהו מקור הודעת השגיאה.
נכון
לא נכון
אל תאשימו את המשתמשים
אל תנסחו את הודעת השגיאה כהאשמה או באופן שמציג את המשתמשים כגורם לבעיה. למילה "שגיאה" (Error) יש קונוטציות שליליות ומרתיעות, לכן המנעו ככל שניתן משימוש בה. אל תצעקו על המשתמשים: אל תכתבו באותיות רישיות באנגלית, ואל תשתמשו בסימני קריאה. כדאי להמנע עד כמה שאפשר גם מצלמיות אדומות ומפחידות. זכרו: הודעת שגיאה היא חלק מהממשק, וכמו כל אלמנט ממשקי, מטרתה העיקרית היא לתת חיווי למשתמש על מהלך פעילות התוכנה.
נכון
לא נכון
נכון
לא נכון
ממש גרוע
(למעשה, זאת אינה הודעת שגיאה. ההודעה הזאת מוצגת לכל משתמש כבר בשלב התקנת התוכנה. ממש דרך נפלאה להתחיל עבודה משותפת. תארו לעצמכם שכך היו מקבלים אתכם לעבודה ביום הראשון שלכם...)
תארו את הבעיה במונחים פשוטים ובהירים
היו תמציתיים, מדויקים והחלטיים בניסוח. אל תשמתשו בז'רגון מקצועי או בהומור שיכול לקבל דו-משמעות. אם סבתא שלכם לא יכולה להבין מההודעה מה בעצם קרה, חשבו מחדש.
דוגמה רעה במיוחד:
(אין לי תמונה של ההודעה המקורית, אבל האמינו לי שדברי ימי המחשב כוללים גם את ההודעה הזאת. שפה לא אנושית, ניסוח מסורבל, ובילבול המשתמש במקום לעזור לו)
Your system shell has changed. The Compaq software will work with your new shell, but the new shell will not work with your Compaq software. Do you wish to keep your Compaq software working? Click yes if you are unsure.
אל תעבירו תיאורי שגיאות ריצה של שפת התכנות אל המשתמשים
משתמשים לא יודעים מה זה NullPointerException או index שנמצא out of bounds. יותר חשוב - זה לא מעניין אותם. בשלב התכנות יש לנסות לחשוב על כל שגיאה אפשרית ולטפל בה (רצוי באמצעות קוד, בלי להדרש בכלל להודעה). אם שגיאת הריצה מחייבת הודעה למשתמשים, יש לנסח אותה באופן שתואם את משימת העבודה שלהם ואת המונחים המקצועיים שלהם.
נכון
לא נכון
ממש גרוע
סיפור משעשע
(מזכירה מבולבלת ניסתה לשמור קובץ וקיבלה את ההודעה הזאת. היא צייתה, כמובן, והקלידה את המילה Mismatch. להפתעתה לא קרה שום דבר. זאת לא עוד בדיחה על בלונדיניות - זה סיפור אמיתי, כמו הרבה סיפורים שאנשי תמיכה טכנית אוהבים לספר.
משעשע? ברגע שתבינו באמת שלא על המזכירה יש ללגלג כאן, אלא על כותבי התוכנה, תדעו שאתם בכיוון הנכון)
נסחו את ההודעה כשאלה
תנו למשתמשים אפשרות להתגבר על הבעיה שנוצרה, ולהמשיך בעבודתם. הציעו פתרונות (השתדלו להציע פתרון אחד ויחיד, כדי לא לבלבל), בניסוח בהיר. אל תתנו לשגיאה לקטוע את משימת המשתמש. השתדלו להשתמש בשאלות כן/לא.
נכון
לא נכון
כמה דוגמאות רעות:
ממש גרוע:
חשבו היטב מה צריכה להיות הבחירה של ברירת המחדל
גם אם תנסחו את ההודעה היטב, משתמשים רבים לא יטרחו להתעמק בה. משתמשים "עונים" לפעמים על שאלת כן/לא שהדיאלוג מציג להם בלי לקרוא אפילו את השאלה עצמה. המנעו ממצב בו הבחירה המסומנת כברירת מחדל תסכן את העבודה או את הנתונים.
נכון
לא נכון
אל תסמכו על מנגנון ההודעות שמספקת שפת התכנות
כדי להיות יעילים יותר ולהפגין את החשיבות הנאותה להודעה שלכם, כדאי שתשכחו מה-Message Box הסטנדרטי. עצבו דיאלוג הודעת שגיאה ברור ונוח לקריאה. הדיאלוג צריך להציג תיאור תמציתי וברור של הבעיה, להציע פתרון, ולכלול כפתורים לאפשרויות הבאות:
- המשך עבודה: התעלמות מהשגיאה.
- עצירת התוכנה: למקרה שההודעה חוזרת שוב ושוב.
- עזרה: פתיחת דף עזרה מקוונת שקשור למשימה הנוכחית של המשתמשים.
- צפייה בפרטים טכניים: פרטים טכניים על מקור השגיאה לא צריכים להיות מוצגים למשתמש. כפתור מיוחד שמציג אותם לפי דרישה יהיה יעיל עבור צוותי תמיכה.
הודיעו למשתמשים אם בחירתם משנה את ההעדפות הכלליות בתוכנה
לפעמים אפשר לספק למשתמשים דרך לשנות את ההתנהגות של התוכנה במצבים דומים בעתיד. הפתרון הזה אינו מתאים לכל הודעה וכדאי לשקול שימוש בו בזהירות. בכל מקרה, תנו למשתמשים לבחור שינוי כזה באופן אקטיבי (למשל על-ידי צורך בסימון או בביטול סימון ב-checkbox). המשתמשים לא תמיד קוראים את ההודעה, ועלולים להיות לא מודעים לשינוי התצורה שביצעתם עבורם. יש לספק בתוכנה גם דרך נוחה להחזיר את ההתנהגות המקורית, והסבר על משמעות הבחירה - במסגרת חלון ההודעה או בקישור למסך עזרה רלוונטי.
נכון
לא נכון
ביישומי רקע השתמשו בהודעות מרחפות
הודעות שגיאה סטנדרטיות עוצרות את עבודת המשתמשים. הן דורשות את מלוא תשומת הלב ומחייבות מענה. יישומים שרצים ברקע (למשל שרת פקס, תוכנת דואר, קורא RSS, או תוכנת הודעות מיידיות) אינם צריכים להפריע לעבודה השוטפת של המשתמשים. לשם כך נועדו הודעות מרחפות, כמו הבלונים הצהובים של "חלונות", או ההודעות היפות של "MSN Messenger".
נכון
לא נכון
השתמשו בשורת המצב או בפנל הודעות
לא כל הודעה שהתוכנה מוציאה למשתמשים צריכה להופיע בחלון הודעה סטנדרטי. כדאי לזכור שחלון כזה קוטע את עבודת המשתמשים ומחייב את תגובתם. השיקולים לבחינת מיקומה וצורתה של ההודעה צריכים לנבוע ישירות מתכונה זו: הודעות אינפורמטיביות, שאינן מחייבות תשומת לב קפדנית ותגובה מיידית של המשתמשים, לא צריכות להופיע בחלון קופץ.
נכון
לא נכון
המנעו ממצבי "מילכוד 22"
זוכרים את ההודעה "Keyboard not found. Press F1 to continue"?
בניגוד למה שקורה בכמה סרטים שאנחנו אוהבים, המחשב הוא יצור טיפש. כותב התוכנה צריך להיות חכם מספיק כדי לא לחשוף את האמת המביכה הזאת.
ולסיום, הנה טקסט אמיתי שנתקלתי בו פעם, ולא אצל פרנץ קפקא:
You need to supply a fax number in order for your request not to receive fax notifications to be processed.
רק עוד רגע... לניוזלטר שלנו נרשמת?
אם מצאת את האתר מעניין, אנחנו מזמינים אותך לקבל היישר אל שולחנך (אוקיי, אל תיבת הדוא"ל שעל שולחנך) את "תקציר מנהלים" - מגזין היי-טקסט בגירסת דוא"ל, עם טיפים, כלים מעשיים, השראה, וכל מה שצריך כדי לתקשר את המוצר הטכנולוגי אל האנשים.
מבטיחים לא להציק יותר מדי, וכמובן לא להעביר את כתובת הדוא"ל שלך לאף אחד.
פרטים והרשמה כאן.
שיתוף:
מה זה פה? לאן הגעתי?
גם הטכנולוגיה הכי יפה ומתקדמת צריכה קודם כל להתחבר לבני-האדם.
וזה מה שאנחנו עושים ב-"היי־טקסט", מתוך תשוקה ונסיון הן בתחום הטכנולוגי והן בתחום הכתיבה, העיצוב וחוויית הלקוח.
באתר הזה אפשר למצוא מאמרים על תרבות טכנולוגית, מיתוג, שיווק, מיקרוקופי, ובעצם על כל הצד האנושי של הטכנולוגיה, ועל הדרכים שבהם אפשר וצריך לתקשר את המוצר הטכנולוגי אל האנשים. אנחנו מזמינים אותך לקבל כאן טיפים וכלים מעשיים, קצת השראה, ואפילו כמה תרגילים לבחינת התקשורת השיווקית ולפיתוח הנכון שלה.
עוד עלינו ועל מה שאנחנו עושים
עבודות נבחרות שלנו
עוד מתוך "תוכנה"
-
לשילוב טקסטים דינמיים במקומות קטנים של חוויית המשתמש והמיקרו-קופי יש כמה תועלות, לא תמיד כולן באות לידי ביטוי, אבל אם עושים את זה נכון, כמעט תמיד נקבל אחד או יותר מהתבלינים הבאים בתבשיל שלנו.
עוד במגזין
קריאה לפי נושא
כלים
השראה
מוזיקה שמנקה את הראש
ציטוטים שפותחים את המחשבה
עוד דברים שמעוררים את הדמיון
העולם האמיתי
הרוב המכריע של המונחים והתפיסות בתחום הטכנולוגי הם השאלה מ"החיים האמיתיים". תחשבו למשל על "חלונות", "שולחן עבודה", "תיקיה", "סל מחזור", ואפילו ה-CC, העותק של הודעת דואר-אלקטרוני, ששמו נגזר מ-Carbon Copy - העתק פחם (זכר לימים שבהם השתמשו בנייר פחם כדי ליצור עותק).
שמות סתומים שמנסים לבטא מקוריות וחדשנות עלולים ליפול למלכודת חוסר ההבנה של מהות המוצר או השירות בעיני הלקוח. שמות השאובים מ"העולם האמיתי" נקלטים מהר יותר, ויש להם סיכוי רב יותר להפוך לשמות גנריים (כמו למשל Firewall).
ניוזלטר ויצירת קשר
"תקציר מנהלים" - הניוזלטר שלנו: מגזין היי־טקסט בגירסת דוא"ל, עם טיפים, כלים מעשיים, השראה, וכל מה שצריך כדי לתקשר את המוצר הטכנולוגי אל האנשים.
מבטיחים לא להציק יותר מדי, וכמובן לא להעביר את כתובת הדוא"ל שלך לאף אחד.
נרשמים כאן.
ואנחנו גם אוהבים שעוקבים אחרינו:
וכמובן שיש גם עמוד "צרו קשר" מסורתי ומלא,
כאן.