פורסם במקור ב-5 בנובמבר 2010 תחת הכותרת "User Experience: Designing Form Validation the Right Way". תורגם על-ידי ויטלי מיז'יריצקי.
הערות המתרגם:
לאחרונה נתקלתי במאמר שמדבר על אפיון ולידציה בטפסים, ומביא הרבה דוגמאות יפות שרציתי לשתף. מאחר וזה לא יפה פשוט לגנוב את הדוגמאות, החלטתי לתרגם את כל המאמר.
המאמר משתמש במושגים webdesign ו-webdesigners, אותם בחרתי לתרגם כ"אפיון" ו-"מאפיינים", מאחר והסוגיות במאמר הן בעיקר אפיוניות ולא עיצוביות.
cc by jasleen_kaur
מהו אימות בטפסים?
בהקשר של מערכת יחסים בין בני אדם, אימות (validation) זה מה שקורה כשאומרים לך שאתה צודק. בהקשר של טופס מקוון, אימות זה כשהטופס אומר לך שאתה טועה. ליתר דיוק, אימות טפסים הוא התהליך שבו טופס מקוון בודק האם המידע שהוזן בו הוא נכון.
למשל:
· אם השדה מסומן כ"כתובת אימייל", הטופס עשוי לבדוק שהטקסט שהוזן הוא כתובת דוא"ל תקפה.
· אם השדה מסומן כ"מספר טלפון", הטופס עשוי לבדוק את עמידת הקלט בתבניות מסוימות (או במספר ספרות מסוים).
הבנתם את הרעיון: האימות מוודא שהמשתמש לא טעה.
אבל טעויות הן בטבע האדם, ולמרבה הצער, כנראה שגם הטופס המקוון שלכם אינו זר לטעויות אנוש. בטפסים ידידותיים למשתמש נכנס לתמונה תהליך האימות. תזכורת ויזואלית פשוטה שמסמנת למשתמש שמשהו לא מוזן כהלכה, יכולה לעשות את כל ההבדל בין הכיף שבטופס שמולא בצורה חלקה לבין התסכול שבניסיונות לנחש מה השתבש בהזנת הנתונים.
מדוע יש צורך באפיון מיוחד?
העיקרון הראשי של אימות טפסים טוב הוא: "דבר עם המשתמשים! תגיד להם כשמשהו לא בסדר!"
שילוב אימות הטפסים באפיוני האתר אינו קשה, אבל רוב המאפיינים לא מייצרים אפיונים כאלה. מדוע? בגלל שלעיתים קרובות משאירים את האימות לשלבים האחרונים של הפרויקט, כנושא שהמפתחים אמורים לדאוג לו.
זה יוצר תרחיש שבו אתה, המאפיין, מפקיד את אחד ההיבטים החשובים ביותר של חוויית המשתמש בידי מפתח שרוב הסיכויים שאינו יודע, או שלא אכפת לו, כיצד יש לעצב את אימות הטופס. תכל'ס, במקרים רבים, המפתח אפילו לא יטרח לייצר שום דבר מעבר לאימות הבסיסי ביותר – שעשוי לתסכל את המשתמשים.
זה לא מכוון כחץ לכיוון המפתחים (ויש מלא מפתחים מעולים שיתמודדו עם המטלה בצורה מצוינת), אבל לצורך העניין בואו נניח שהמפתח לא משקיע הרבה מאמץ.
הסתכלו על התמונה הבאה:
מה לא בסדר עם הטופס? הטופס כן מבצע אימות בכך שהוא מודיע למשתמש שמשהו אינו תקין, אבל המשתמש צריך לנחש לבד במה מדובר.
העיקרון הראשי של אימות טפסים טוב הוא: "דבר עם המשתמשים! תגיד להם כשמשהו לא בסדר!"
בואו נבחן את התמונה הבאה:
הרבה יותר טוב, נכון? כעת המשתמש מקבל את המידע שהוא זקוק לו כדי לתקן את הבעיה. זוהי דוגמא מפושטת, אבל שימו לב כיצד שילוב של מערכת משוב בסיסית משפרת את השימושיות עשרות מונים.
שלושת הסוגים הנפוצים של שגיאות בטפסים
כעת, כשהבנתם מה זה אימות, יש לקוות שאתם רוצים ליישם אותו בטפסים המקוונים שלכם. בגדול ישנן שלוש שגיאות שהמשתמשים עשויים לבצע בטופס:
בעיות פורמט
זוהי כנראה הבעיה הגדולה ביותר שהמשתמשים ייתקלו בה. האם מילאתם פעם טופס רק כדי לגלות ששילבתם תו אסור בשדה שם המשתמש, או שהשתמשתם ברווח בכתובת אינטרנט? כאן נכנס לתמונה אימות הפורמט.
רוב השדות בטופס מקוון הם שדות אלפאנומריים, אבל אם יש לכם שדות אימייל, כתובת אינטרנט, מספר טלפון או סיסמא, ניתן לדרוש בהם תבנית הזנה מיוחדת. אתם כנראה יכולים לנחש את המבנה הייחודי של כל שדה. אם כך, אימות הפורמט מביא תועלת כשמצפים לקבל מידע מסוג מסוים.
שגיאות שדות חובה
שגיאות כאלה מתרחשות כאשר המשתמש שוכח למלא שדה שסומן כשדה חובה, או מחליט לדלג עליו.
שגיאות תיאום
זה קורה כאשר צריכים לבדוק שערך מסוים זהה לערך אחר. זה חשוב בעיקר בטפסי כניסה למערכת, מאחר ואתם לא רוצים לאפשר למשתמשים להיכנס במידה והסיסמא שהזינו לא תואמת לסיסמא הנכונה. ניתן להשתמש בזה גם כדי לחייב משתמשים להקליד מחדש את כתובת הדוא"ל או הסיסמא שלהם, כאשר חייבים לוודא שהם לא מבצעים טעות בהקלדה.
הפתרון האפיוני
בעוד שניתן לעצב את הטופס באלף דרכים שונות, בעיקרון ישנם שלושה צעדים בסיסיים שיש לנקוט בהם כדי לעזור למשתמשים לתקן את בעיית האימות:
1. ליידע את המשתמש שקיימת בעיה בטופס.
2. להדגיש את השדה הבעייתי.
3. להראות לו דוגמא של הקלט המצופה (למשל: [email protected])
צבע הוא אחד הכלים המועילים ביותר באפיון האימות. מכיוון שהוא פועל ברמה אינסטינקטיבית, הוספת אדום להודעות שגיאה, או ירוק להודעות הצלחה, הוא פתרון חזק ביותר.
קירבה הינה כלי חשוב נוסף – יש למקם הודעות ספציפיות בקרבת השדה הבעייתי, והודעות כלליות המתייחסות לכל הטופס – הרחק מהשדות. אם ניתן לייצר פתרונות ייעודיים המשנים את מראה הטופס בצורה שתתמוך באסטרטגיות אלה (למשל עיצוב ההודעה בצורה שמחברת אותה פיזית לשדה מסוים), עוד יותר טוב.
פתרון מומלץ נוסף הוא להזהיר את המשתמשים מראש לגבי מקומות מועדים לטעויות. אתרים רבים מכילים תיבה צידית עם הוראות המילוי של הטופס. אתרים נוספים מציינים את הפורמט הנכון מתחת לתווית השדה. כל אחת מהשיטות האלו יכולה לעבוד, אבל חשוב להשתמש לפחות באחת מהן.
כפי שנציין בהמשך, בפרק "כיצד פועל האימות", רצוי גם להשתמש ב"אימות מיידי" במידת האפשר.
כשאתם מסתכלים על הדוגמאות האלו, שימו לב שהפתרון הוא תמיד פשוט: טולטיפ, תיבת הודעה, או קצת טקסט. כל עוד אתם ממקמים את ההודעות קרוב לשדה הבעייתי, אתם יכולים לאפיין, לעצב או לסגנן אותן בכל צורה שתרצו. הדבר היחיד שיש לזכור הוא שאתם צריכים לעזור למשתמש.
בואו נצלול אל הדוגמאות:
ThemeForest
ThemeForest מציגים מיידית הודעת שגיאה, ישירות מתחת לשדה. והזנה מוצלחת אפילו מקבלת הודעת "הצלחה!" ירוקה.
Frexy
Frexy משתמשת בגישה פשוטה אך יעילה: לצבוע את השדה הבעייתי ולהוסיף מלל בהיר של הודעה מתחתיה (יש לציין שהצבע הירוק עשוי להטעות את המשתמשים, אבל כאן כל אחד מאזן בין שיקולי מיתוג לשימושיות לפי טעמו האישי).
Twitter מוסיפה הודעה מימין לשדה כדי לציין שגיאות. היא עושה את זה מיידית, והם גם מוסיפים צבע למערכת המשוב כדי להדגיש את המסר!
Mint
Mint לא רק מאמתת את השדות באופן מיידי, אלא נותנת גם משוב חיובי וגם משוב שלילי. זה מרגיש כאילו שאתה והטופס מנהלים שיחה!
FancyForm
FancyForm הוא כלי טפסים שמדגים עד כמה יעיל יכול להיות מתן משוב מיידי וממוקד בצורת אייקונים.
Virb
Virb מוסיפה הודעה בהירה כשלא עושים משהו נכון. והם גם מרוויחים כמה נקודות בונוס על זה שהם פשוט לא מאפשרים לך להזין תווים אסורים – תנסו לבד!
WordPress
WordPress מספקים הודעה בסיסית, אבל מה שמיוחד בהם זה שהטופס עצמו ממש רועד כשמזינים מידע לא נכון.
InvoiceMachine
InvoiceMachine משתמשים בגישה הפשוטה ביותר. במקום עזרה טקסטואלית, הם צובעים את רקע השדה באדום כדי להצביע על בעיה. יש לזכור שטולטיפ טקסטואלי במעבר העכבר על הטופס ישפר אותו עוד יותר.
WPCoder
WPCoder מדגימים שגם חלון קופץ של ג'אווהסקריפט יכול לעבוד מצוין. (יש לציין שלא מדובר כאן באימות של טופס אלא בהודעה כללית שלא קשורה לנתונים שהוזנו – ו.מ.).
Yahoo
Yahoo משתמשים בגישה הומוריסטית… במקום להציג הודעת שגיאה רגילה על הזנת תאריך לידה שגוי, הם מתחצפים טיפה.
איך האימות עובד בפועל
מנקודת מבט טכנולוגית, קיימות שתי דרכים לבצע אימות בטופס.
· אימות צד-שרת מתרחש כאשר המשתמש שולח את הטופס, וסקריפט מנתח את התוכן ומחזיר הודעת שגיאה כשהמידע אינו עומד בקריטריונים של הצלחה.
· אימות צד-לקוח זה האימות מבוסס הג'אווהסקריפט שפוגשים בטפסים מודרניים. זה מה שקורה כשמתקבל משוב מיידי ברגע המעבר לשדה הבא, ללא הצורך לבצע שליחה של הטופס.
אימות צד-לקוח מספק את החלופה הידידותית ביותר למשתמש, כי היא יכולה לספק משוב בזמן אמת, כך שהמשתמש יכול לתקן את הטעות שלו מיידית. אבל החיסרון העיקרי של אימות צד לקוח הוא בהסתמכות על ג'אווהסקריפט, כך שאם המשתמש כיבה את התמיכה בג'אווהסקריפט בדפדפן, הוא לא יראה את הודעות האימות. לכן חשוב לבצע אימות צד-שרת כגיבוי למקרים כאלה.
ניתן לקרוא עוד על הצד הטכנולוגי של האימות באתר הרשת שלנו, Nettuts!
מחשבות אחרונות
הטפסים הטובים ביותר הם אלה שצופים מראש את התנהגות המשתמש. חשוב לתכנן את הטופס ולהבין מראש מהן הטעויות שהמשתמש עשוי לבצע, עוד לפני שהטופס נבנה. מדוע? מכיוון שאם אתם יכולים לחזות את המקומות הבעייתיים, קל לתכנן פתרון שיעזור למשתמשים להתגבר על הקושי. אבל השארת אפיון האימות עד לרגע האחרון עשויה להעלות את מחיר תיקון הטעויות לאחר סיום הפיתוח. השקעת הזמן הנוסף לתכנון אסטרטגיות ועיצוב בטפסים שלכם תחסוך זמן, כסף ותסכול בטווח הרחוק.
הדוגמה של virb דווקא מטעה לדעתי – השגיאה נראית כאילו היא קשורה לurl, למרות שהיא מדברת על email.
אריה, אני חושב שהרושם הזה נוצר בגלל שאנחנו רואים תמונה סטטית. בפועל המשתמש מסיים להזין את כתובת ה-url, עובר לשדה האימייל, ורק כשהוא מקליד תו אסור (סימן השאלה) או יוצא מהשדה, מופיעה ההודעה.
[…] באפיון בלוגים), ותרגמתי כמה כתבות של אחרים – עבור UXI (אפיון ולידציה בטפסים וגם שיפור conversion ע"י בניית טפסים במודל "השלמת […]
ויטלי – תודה על התרגום, וגם יפה שלא "גנבת" את החומר אלא הצגת דברים בשם אומרם.
הערה קטנה. לדעתי:
Validation = תיקוף
Verification = אימות
חוץ מזה שאלה שלא ראיתי אליה התייחסות.
מה דעתך עלהצגת שדות לא רלוונטיים למשתמש/למטלה הנוכחית בטופס כאפורים (Disabled)? בטפסים ב WEB נראה לי שמנסים פשוט לא להציג אותם, אבל לפעמים יש ערך להצגתם כדי לרמוז שהם רלוונטיים אבל לא במקרה הספציפי הנוכחי.
תודה רועי!
לגבי תרגום המילים – בעיקרון אתה צודק, אבל בעברית התרגלו לקרוא לזה אימות שדות, אז הלכתי עם התרגום המקובל. ודי הייתי צריך להכריח את עצמי שלא לרשום פשוט "ולידציה".
ולגבי השדות הלא רלוונטיים – כרגיל, "זה תלוי" :). בהחלט יש מקרים שחשוב להציג אותם, ויש מקרים שזה סתם מפריע, הבעיה זה לדעת לזהות את המקרה הנכון. לא חושב שיש פה כלל אצבע שיכול לתפוס באופן טיפוסי.