כשמקלידים מידע בטופס, נדרשים לא פעם להכניס מספרים בתבנית מסויימת: מספר טלפון חייב קידומת, כרטיסי אשראי צריך לפעמים להפריד לקבוצות של 4 ולפעמים לא, תאריכים צריך להכניס עם קו נטוי אבל לפעמים עם נקודה וכן הלאה.
"תבנית סלחנית", באנגלית forgiving format, הוא עקרון עיצוב פשוט, שאומר: תנו למשתמשים להקליד מה שהם רוצים, ונסו להסתדר לבד עם מה שהם נתנו. תסלחו להם על טעויות קטנות, אם אפשר. מכאן השם – תבנית סלחנית.
דברים קטנים אבל מעצבנים
הכותרת הזו היא השם של מערכון משעשע של דודו טופז ז"ל, מאותה תוכנית שהיה בה מערכון "משה והאורנג'דה" המפורסם, פליטת פה. אח, אח, שנות ה-80. בטפסים יש שפע של דברים קטנים ומעצבנים, ותבנית סלחנית עוזרות להתגבר על חלק מהם.
הנה דוגמה לתבנית לא סלחנית מתוך המערכת flex הישראלית לניהול חשבונות:
flex. לא סולחת ולא שוכחת.
למקרה שלא הבנתם את הודעת השגיאה, הייתי צריך להקליד כאן 11/03/2010 ולא 11/3/2010. ברור, לא? כמה היה עולה לתכנת שדה שיודע להבין גם 11/3/2010 ולא רק 11/03/2010? שלא לדבר על 11-3-10 או 11.3.10. במקרה של flex הטעות חמורה אפילו יותר, כי יש כאן מקום להזנת תאריך, אבל אי אפשר לבחור מלוח שנה כמקובל בשדות תאריך. כך שכל מי שרוצה להזין תאריך לעשות את זה לפי איך שהמתכנת של השדה הזה הסכים לקבל תאריכים – his way or the highway.
בקצה השני של הסקלה: Google Maps. אפשר להזין שם של מקום בכל צורה שהיא, והוא ינסה להבין מה הכוונה. שם של מקום הוא הרבה יותר מסובך מתאריך, וכדי להבין אותו כראוי נדרשים הרבה יותר משאבי פיתוח. שימו לב שכתבתי יורשלים ולא ירושלים, ועדיין קיבלתי תוצאה.
גם טדי קולק ז"ל היה מסתדר עם המפות של גוגל, יוּרשלים
תאריכים סלחניים
ב-Outlook יש דוגמה מצויינת לתבנית סלחנית לתאריך. אם אני רוצה לקבוע פגישה ליום רביעי הקרוב, אני יכול להשתמש בתאריך מובנה:
- 17-3-2010
- 17/3/2010
- 17.03.2010
אני יכול להשתמש בתאריך מקוצר:
- 17/3
- 17
וגם ביום:
- Wednesday
- Wed
אפשר גם ברביעי הבא:
- Wed Week
- Wed W
וכן הלאה. כמה זה מסובך לתכנן ולתכנת את זה? לא מאוד. וזה יכול לעבוד בכל שדה תאריך.
ב-Google Calendar לקחו את זה עוד צעד, ונתנו לקבוע את כל פרטי הפגישה דרך שדה טקסט אחד. הם גם נותנים, כמובן, לכתוב קיצורים ולהשתמש בתבניות וניסוחים שונים. שני הניסוחים האלה יעבדו וייצרו את אותה הפגישה:
- Dinner with John tonight at 19:00
- Dinner at 19:00 with John
- 7pm dinner with John
הוספה מהירה בלוח השנה של גוגל
עמודי נחיתה סולחים בקלות
בטפסים שמופיעים בעמודי נחיתה (landing pages) יהיה בדרך-כלל שימוש נרחב בתבנית סלחנית. עמודי נחיתה הם כאלה שמגיעים אליהם כשמקליקים על באנרים פרסומיים ולפעמים גם מתוצאות חיפוש בגוגל. דיברתי עליהם כאן בפודקאסט לפני כמה שבועות עם תמיר, אתם יכולים להקשיב.
הסיבה שטפסים בעמודי נחיתה ישתמשו בדרך-כלל בתבנית סלחנית היא די ברורה: המטרה שלהם היא לאסוף מידע מהמשתמשים שהגיעו אליהם. הם לא רוצים לשים שום מכשול בפני המשתמשים בתהליך מסירת המידע, ולכן יעשו הכל כדי שהזנת המידע תעבור חלק. הנה למשל דוגמה מפרסומת:
טופס בעמוד נחיתה שאוכל הכל (כמעט)
תאמינו או לא, אבל הטופס קיבל את התוכן הזה כתקין. אני לא יודע אם הייתי הולך כל-כך רחוק, מספר הטלפון פה הוא שגוי באופן ברור, אבל מצד שני – חלק התוכנה שבודק את תקינות השדות לא יכול לדעת, אולי המשתמש הזין אימייל תקין וקשקש משהו סתם בטלפון כי הוא לא רוצה שייפנו אליו באמצעות הטלפון?
במקרה שלמעלה הפרסומת היא לדירת יוקרה; פרטים על מתעניינים רלוונטיים (leads) שווים הרבה כסף, ובשביל להגיע אליהם מוכנים גם להשקיע בסינון אנושי של פרטי הפונים הלא-רלוונטיים. לכן הבחירה של המתכנת או המעצב כאן, לקבל את הטלפון הזה כתקין, היא נכונה בעיני.
לבחור קידומת טלפון מרשימה? למה?
יש עמודי נחיתה שעושים את זה פחות טוב:
למה צריך לבחור את הקידומת מרשימה?
למה להכריח את המשתמש לעבור לעכבר (או להשתמש בקיצור מקלדת – למי שידוע) כדי לפתוח את הרשימה, לבחור את הקידומת הנכונה ואז להשלים את שאר המספר בהקלדה. הרי הרבה יותר קל ואינטואיטיבי לנו פשוט להקליד את 10 הספרות של הטלפון שלנו, אולי עם – מפריד או סוגריים, ולהמשיך הלאה. נראה שמי שתכנן את הטופס הזה פשוט העתיק מאיזה מקום אחר שגם עשה כזה, בלי לחשוב על מי שישתמש בזה.
בכלל, לבחור קידומת טלפון מרשימה זה רעיון גרוע, אל תעשו את זה. אפשר תמיד לבדוק אם הקידומת של הטלפון תקינה אחרי ההקלדה.
ולמה הפרוייקט הוא טקסט חופשי? דווקא כאן היה נכון לתת לבחור ולא טקסט החופשי. הדף שהטופס מופיע בו מציג כמה פרויקטים, אין שום סיבה לבחון את הבנת הנקרא של המשתמשים…
תבנית סלחנית – דפוס עיצוב
הזכרתי כאן דפוסי עיצוב, Design Patterns, לא פעם בעבר. אפשר לשמוע על הנושא בפודקאסט על דפוסי עיצוב שבו שוחחתי עם רן לירון. "תבנית סלחנית" הוא דפוס עיצוב חשוב, ואפשר למצוא עוד דוגמאות שלו באתרי דפוסי העיצוב השונים:
- ב-Quince
- ב-UI-Patterns
- ב-Designing Interfaces (האתר של הספר)
- ב-UXI עוד אין, אבל יהיה בקרוב… ויש שם גם כמה דפוסי עיצוב אחרים.
מעניין אם טופס flex יזין את התאריך ה"נכון" לחוקי השדה שלו: 11/03/2010 בתור האחד עשר לחודש מרץ או השלישי לנובמבר…(אני לא רואה בצילום המסך הסבר או הכוונה, אבל יכול להיות שזה בגלל שזה צילום חתוך או חלקי) אני כן רואה הכוונה בהודעת השגיאה (היום בחודש מופיע קודם), אבל הודעה כזו כנראה לא תופיע אם הקלדנו מראש 11/03/2010….
:)
היי שגיא,
מאחר והמערכת דוברת עברית, ומיועדת לקהל שחי בארץ או לפחות מנהל את עסקיו הפיננסיים מכאן, סביר לצפות שהיא תהיה בתבנית שמקובלת בעברית ובישראל: d/m/y. אני מניח שזו הציפיה שיש לרוב המשתמשים במערכת. אני לא חושב שבמקרה של מערכת בשפה אחת ומדינה אחת יש צורך לציין את התבנית במפורש, אם לזה כיוונת.
כן.. לזה כיוונתי,
בתור מנהל תמיכה של בית תכנה בארץ, אין לך מושג כמה אנשים חיים פה שלא נולדו בפתח תקווה
יש המון אמריקאים בארץ, דוברי עברית, ועולים מארצות אחרות שמערכת החלונות שלהם מסודרת כך שהחודש מגיע קודם ליום, וכך הם גם כותבים תאריכים…
אני לא מתווכח איתך כי באופן עקרוני אני "מסכים" איתך. הנסיון שלי בשטח מראה לי אחרת.
תודה שחלקת איתי ועם הקוראים כאן את הנסיון שלך, אני תמיד שמח ללמוד מהנסיון של אחרים.
כפי שהצעתי בפוסט, פתרון קל היה לשים שם פקד ייעודי להזנת תאריך (בחירה מתוך לוח שנה). מפלקס מסרו בתגובה לפוסט שהם עובדים על לשים שם אחד כזה.
מעניין מאוד.
עם זאת, יש הבדל גדול בין טופס סלחני שידע לזהות תאריך בכל מיני פורמטים, ובין המערכת החכמה של גוגל שיודעת לפענח חיפוש של "מסעדה בשדרה החמישית בניו יורק" ולהפריד בעצמה בין שם בית העסק, סוג בית העסק, רחוב, עיר ומדינה.
תודה, רומי.
בוודאי שיש הבדל, אבל העקרון העיצובי הוא אותו עיקרון.
הרי את המערכת החכמה של גוגל לאיתור מקום היה אפשר לפרק לבחירה בין:
שם מקום (מגדל אייפל, המסעדה של ג'ו), סוג מקום (מסעדה/מוזיאון) וכתובת (הרצל 34, תל-אביב), או שילוב כלשהו ביניהן. בדיוק באותו אופן אפשר לחלק את הבחירה של תאריך ל: יום, חודש, שנה, בשלושה dropdowns.
המטרה זהה: לקצר תהליכים עבור המשתמש תוך נסיון להבין את הכוונה שלו בלי שהוא יעבוד קשה. אני מסכים איתך שהמאמץ האלגוריתמי לפענוח תאריך שונה לאין ערוך מזה של חיפוש מקום/כתובת/עסק, אבל מדובר באותו דפוס עיצוב.
בתור משתמש אני מעדיף בהרבה שורה כמו של גוגל. זה חוסך ממני את המעבר בין שדות ואת הבדיקה מה צריך להקליד בכל אחד מהם.
זה גם מאפשר לי להגדיר אותם בתור מנועי חיפוש בדפדפן.
שניים שאני משתמש בהם ונוחים מאוד הם מפה ואגד.
מורי ורבי. שוב פוסט מעניין שפורט למילים ודוגמאות משהו שחשבתי שאני יודע אבל בצורה עמוקה יותר.
דוגמאות נוספות ומעיקות:
בחירה של שנת לידה מתפריט נגלל: להגיע לשנת הלידה שלי (שהיא כבר אי שם) היא די מעצבנת, ובנוסף רוב המפתחים כוללים גם שנים כמו ו1910 שגורמת לגלילה לצאת מהדף ומהפרופורציות;
במפות: הצורך למדוד עם סרגל בין נקודה לנקודה, בעוד שאם הייתי מגדיר את הנקודה השנייה כיעד ומבקש לחשב מסלול, המערכת הייתה אומרת לי מהו המרחק(דוגמא יותר מסובכת לפיתוח אולי, אבל עדיין…)
מותר עוד?
בנושא התאריכים הסלחניים, קיים עוד פתרון יעיל. הוא ממש לא סלחני, אבל הוא גם לא משאיר הרבה מקום לטעויות. הכוונה היא להגדרת mask שגורם למשתמש להצמד לפורמט, בין אם ירצה או לא, למשל שדה תאריך שהסימנים המפרידים "." או "/" כבר מובנים בו ואינם ניתנים לעריכה.
פעם היו משתמשים בזה יחסית הרבה, אבל זה הולך ונעלם (בינינו, זה די מכוער). אני עדיין רואה את זה בעיקר בהזנת מספרי כרטיסי אשראי או קודי הפעלה לתוכנות – שם מפרקים אותם לקבוצות של ארבעה תוים ע"מ להקל על המתשמשים להתמצא במחרוזת הארוכה.
כרגיל, תודה! :)
אם אני לא טועה, נתקלתי גם במקומות ש"מתקנים" את תוכן השדה כמה שניות לאחר סיום ההקלדה ויציאה מפוקוס השדה.
כך למשל "11/3/10" יהפוך ל "11/03/2010" או אפילו ל "11 למרץ 2010"
מסכימה מאוד עם ישי – זה באמת מעצבן שצריך לגלול ולחפש את השנה, וככל שאתה זקן יותר, ככה אתה גולל יותר… (למה להעליב את הגולשים?)
באופן עקרוני בטפסים אני תמיד מעדיפה להקליד את הנתונים בעצמי, ולא לבחור מרשימה.
נכון שזה משאיר יותר מקום לטעויות, אבל מצד שני, תכנון נכון של השדות ימנע את זה, ויצריך את המתכנת להיות "סלחני" במידה מינימלית.
לדוגמה, תאריך לידה: שדה של יום, שדה של חודש, שדה של שנה, עם כיתוב מעל השדה שמסביר מה צריך למלא בו. זה אולי קצת מעצבן למי שלא רגיל לעבוד עם ה-tab אבל לפחות זה ברור ומובן, והגולש לא יבזבז זמן בלהתלבט מה לרשום או לחפש את הערך שמתאים לו, דבר שהוא מעצבן הרבה יותר מאשר ללחוץ על השדה הבא ולהקליד.
יש עוד המון דברים כאלו באתרים, ובתור מעצבת אני מבינה יותר ויותר למה זה קורה: גם כשהמעצב/מאפיין חושב על הדברים האלו, המבצע – המתכנת, פשוט עצלן, וכל עוד זה לא הוגדר מראש כחלק מהפרויקט, צריך לריב איתו כדי שהוא יתאמץ ויבזבז על זה עוד 10 דקות (או חצי שעה). התוצאה היא שאנשים לא עושים "מעבר", ודרישות שהלקוח לא יודע לדרוש, לא מתבצעות אלא אם יש מישהו בדרך שמתעקש על זה.
חתול – בוודאי, זה בדיוק הרעיון – לאפשר לאנשים להזין את המידע במהירות ובקלות. החיפוש באגד הוא דוגמה מצויינת, אם כי תוצאות החיפוש לא מאוד נוחות, במיוחד כשיש כמה אפשרויות להגיע ליעד. אתר מפה הוא דוגמה ממש לא כל-כך טובה, בעיקר בחיפוש כתובת. נסה להקליד בו שם רחוב שלא קיים, למשל "אחוז 12, רעננה" במקום "אחוזה 12, רעננה", ותקבל מפה של רעננה. ה"אחוז" נמחק כי הרחוב לא מוכר למערכת. לא רק זה, גם אין משוב למשתמש שהכתובת שגויה. זו ממש לא תבנית סלחנית…
ישי, תודה תודה. דוגמאות מצויינות לשדות מעצבנים שאפשר היה בקלות להפוך למשהו נוח יותר באמצעות תבנית סלחנית.
ויטלי, מה שאתה מציע מזכיר לי נשכחות מימי המסופים (terminal) של מחשבי ה"וקס" שעבדתי איתם בצבא. ברררר… ההפרדה לקבוצות יכולה לעבוד טוב, המקום שבו רוב הטפסים נופלים בו בעניין הזה הוא בתיקון טעויות. הם יודעים להקפיץ אותך מקופסה 1 לקופסה 2 אחרי שמילאת את כל הספרות הנדרשות בקופסה 1, אבל אם תלחץ על Backspace מקופסה 2, לא תחזור לקופסה 1. אז עוזרים לך לקרוא את המידע עם החלוקה לקבוצות מספרים, אבל אז מכריחים אותך להשתמש בעכבר (או ב-SHIFT-TAB למקצוענים) כדי לתקן. גם זה לא תמיד עובד טוב, בגלל הסקריפט שמקפיץ את הסמן לשדה הבא כשהשדה הקודם מלא. ראיתי כל-כך הרבה טפסים שעושים את זה רע, שאני כבר לא בטוח אם החלוקה לקבוצות מספרים היא כדאית.
אוריאל, בכיף. התיקון אחרי כמה שניות הוא פתרון מוכר, גם Outlook שהבאתי כדוגמה עושה את זה, ואפילו לא מחכה כמה שניות, אלא מתקן מיד כשיוצאים מהשדה.
נופר, לעניין התאריכים, ההפרדה של יום-חודש-שנה לשדות שונים נופלת באותו מקום שכתבתי עליו לויטלי, כשרוצים לתקן טעויות. "זה אולי קצת מעצבן למי שלא רגיל לעבוד עם tab" – רוב האנשים לא יודעים מה זה tab. גם מבין אלה ששמעו על המקש, רבים לא יודעים שהוא משמש למעבר בין שדות. בדיוק בשביל זה תבניות סלחניות קיימות: כדי לאפשר למשתמשים להזין מידע באופן שאינטואיטיבי להם, ולתת למערכת "לשבור את הראש" על מה הם התכוונו. לתת דוגמאות לקלט תקין בשדה זה בדרך-כלל רעיון טוב, כל עוד הוא נחוץ ולא מעמיס (נגיד, בשדה "שם פרטי" לא הייתי נותן דוגמה…)
בקשר להערה שלך על מתכנתים, לקוחות וכו', זה דיון ארוך, אבל אני חושב שהעניין קם ונופל על כמה דברים:
1. רמת הידע של המעצב/מאפיין בתחום חוויית המשתמש.
2. תאום ציפיות בין המעצב למתכנת, בדמות מסמך, שיחה או אב-טיפוס חי שמגדירים את האינטראקציה במדוייק, ולא רק ציורי מסכים, מפורטים ככל שיהיו.
3. רמת הידע של המתכנת בתחום חוויית המתשמש.
אם אין הצלחה ב-1+2 או ב-3, קורים מצבים כמו שתיארת בהערה שלך. אני לא אומר שזה לא נפוץ, אבל זה בהחלט בידייך כמעצבת.
הדוגמא של פלקס היא ממש בלתי נסלחת, ולו בגלל שיש ב-PHP פונקציה מובנית שעושה בדיוק את זה – לוקחת שדה שהוזן כמחרוזת, ומעבדת אותו לתאריך. היא גם עובדת מעולה. לא ברור לי למה לא להשתמש בה, במקום לשבור את הראש.
(כן, אני יודע שהם ב-ASP, ולא, אני לא יודע אם יש כזה גם שם. שיעברו ל-PHP)
@נדב – מבחינה עיצובית, יש עדיפות מובהקת לפתור בעיות כאלו בצד הדפדפן.
אופציה טובה היא להשתמש במסכות… וכמובן שיש plugin לכל מטרה ולכל סביבת עבודה. לחובבי jquery אני ממליץ על
http://digitalbush.com/projects/masked-input-plugin/
השאלה היא לא איזה טופס הוא "סלחן"
אלא איזה טופס יודע לתקן טעויות הקלדה ולהעביר את המידע נכון ומצד שני לזהות דוגמאות שגויות בעליל ולדרוש תיקונן.
בתור משתמשת של פלקס- זה כ"כ נכון!! שיסדרו את זה כבר….