Skip to content

חיווי מיידי: כשטופס מתחיל לדבר

16/09/2009

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

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

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

דוגמה לחיווי מיידי

דוגמה לחיווי מיידי (חיובי ושלילי) מתוך טופס ההרשמה של twitter

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

לוק רובלוסקי בדק את תגובתם של 22 משתמשים "ממוצעים" לצורות שונות של חיווי מיידי. הטופס שנבדק חולק ל-2 חלקים:

     

  • שדות פשוטים (מידע שהמשתמש כבר יודע – שם, דוא"ל וכו')
  • שדות מורכבים (מידע שהמשתמש צריך להמציא – יוזר וסיסמה).
  •  

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

תזמון החיווי

מתי הכי טוב להציג את החיווי? רובלוסקי בדק 3 אפשרויות:

     

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

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

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

סוג החיווי

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

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

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

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

מיקום החיווי

איפה כדאי למקם את החיווי והאם הוא צריך להיות קבוע או זמני? נבדקו האפשרויות הבאות:

     

  1. אחרי השדה (באנגלית – מימין לשדה), תמיד מוצג.
  2. אחרי השדה, חיווי חיובי נעלם בפייד אאוט לאחר כמה שניות.
  3. בתוך השדה, תמיד מוצג.
  4.  

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

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

     

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

סיכום

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

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

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

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

  3. poka-yoke. כל יום לומדים משהו חדש 🙂

    http://en.wikipedia.org/wiki/Poka-yoke

  4. הי מרטין.

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

    לדוגמה, בכניסה לאתר קופת חולים מכבי – https://da.maccabi-health.co.il/
    המערכת לא בודקת אם תעודת הזהות תקינה, ולא אם הסיסמה שהוזנה תקינה (ארוכה מספיק) אלא פשוט מודיע לך במידה וניסת להזין מספר ת.ז וסיסמה ולבצעה כניסה שמשהו בהם לא היה תקין שיש שגיאה באחד השדות. ועכשיו לך תגלה מה.
    העובדה שכמקובל, שדה הסיסמה מוסתר, בלי אפשרות להציג מה שאתה כותב, בודאי לא מקלה על העניין.

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s

%d בלוגרים אהבו את זה: