אדם: מחשב, מחק את הקובץ הזה בבקשה.

מחשב: רגע אחד, אתה בטוח שאתה רוצה למחוק את הקובץ הזה?

אדם: מחשב, תוריד את המסמך הזה בבקשה.
מחשב: אוקיי, אבל קודם תגיד לי –  איפה תרצה לשמור אותו?

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

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

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

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

 

הצומת המסוכנת

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

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

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

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

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

מה האלטרנטיבה?

הפתרון הנפוץ והנכון ביותר הוא לבצע מיידית את הפעולה ולאפשר להתחרט עליה באמצעות undo. ה- undo מייתר את הצורך באזהרה מפני שהוא הופך פקודה בלתי הפיכה להפיכה.

מה היתרונות של הגישה הזו?

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

מה החסרונות של הגישה הזו?

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

תוכלו לקרוא על היתרונות של ה- Undo למול הגישה הקלאסית ביתר פירוט במאמר הזה.

 

צומת פרשת הדרכים

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

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

הגישה הקלאסית תציג בפנינו את השאלה הזאת ממש כפי ששאלתי אותה כרגע. ההחלטה היא כולה שלנו:

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

אז מה אפשר לעשות אחרת?

הדרך היעילה ביותר להיפטר מצומת החלטה כזה היא פשוט לבטל אותו. כדי לאפשר את זה, עלינו להחליט בשביל המשתמש (ובכך למעשה לשלול את חופש הבחירה שלו). כדי לעשות זאת עלינו לקבוע מה דרך פעולה הרצוייה ע"פ הבחירה שרוב המשתמשים היו לוקחים.

את הבעייה שתוארה קודם בחרו מעצבי אפל לפתור באייפון באופן הבא: יומן השיחות מאופיין כך שלחיצה על איש קשר בעל מספר טלפונים תחייג למספר ממנו בוצעה השיחה אלינו, מבלי לשאול אותנו מה ההעדפה שלנו. כחלופה, ניתן ללחוץ על "כפתור חשיפת הפרטים"(Detail Disclosure Button), אותו כפתור כחול המעוטר בחץ סיטרואני, כדי לפתוח את הכרטיס של איש הקשר שמכיל את כל מספרי הטלפון, ומשם להוציא שיחה למספר אחר.

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

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

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

 

הצומת החד סיטרית

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

מה החסרונות בגישה הזאת?

ראשית, לא מדובר כאן בשאלה מהותית, שהתשובה לה חשובה להמשך התהליך, משום שממילא אין לנו ברירה אלא לאשר אם אנחנו רוצים להתקדם.

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

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

מה היתרון בשיטה הזאת?

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

איך אפשר אחרת?

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

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

הודעה קבועה שניתנת להסרה באמצעות כפתור "הסר", אך אינה מפריעה למהלך העבודה גם אם לא מסירים אותה (כלומר היא אינה מודאלית, ואינה מסתירה תוכן).

היתרונות:

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

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

החסרונות:

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

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

 

לסיכום

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

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