וולידציה בטפסים - דפוסים ו-UX שכל מפתח צריך להכיר¶
כל מפתח שבנה טופס יודע לכתוב קוד שבודק אם שדה ריק. הבעיה היא לא הקוד, הבעיה היא התזמון והניסוח. טופס שצועק "שגיאה" על המשתמש בזמן שהוא עוד מקליד את השם שלו, או שמראה "קלט לא תקין" בלי להסביר מה בדיוק לא בסדר, גורם לאנשים לנטוש. הפוסט הזה לא על React או Vue או framework כלשהו, הוא על העקרונות שעומדים מאחורי וולידציה טובה, בלי קשר לטכנולוגיה שבה אתם בונים.
מתי בכלל לבדוק - התזמון קובע הכל¶
יש שלוש נקודות טבעיות לבדוק שדה: בכל הקלדה, כשעוזבים את השדה (blur), ובשליחת הטופס. לכל אחת יש מחיר.
בדיקה על כל הקלדה נשמעת אחראית, אבל בפועל היא מרגישה תוקפנית. אם מישהו מתחיל להקליד אימייל ואתם כבר בתו הרביעי מציגים "אימייל לא תקין", הוא עוד לא סיים לכתוב. זה מרגיש כאילו הטופס נוזף בו לפני שהוא בכלל טעה.
בדיקה רק בשליחה גם בעייתית מהכיוון ההפוך - המשתמש ממלא עשרה שדות, לוחץ שלח, ומקבל רשימה של שגיאות בבת אחת. זה מציף ומרגיש כמו עונש.
הדפוס שעובד הכי טוב ברוב המקרים הוא היברידי: בודקים כשהמשתמש עוזב שדה (blur), ולא לפני. ברגע שהשדה הראה שגיאה, רק אז עוברים למצב "בדיקה חיה" עליו - כלומר, ברגע שהמשתמש מתקן, השגיאה נעלמת מיד כשהקלט הופך תקין, בלי לחכות ל-blur הבא. זה נותן למשתמש מרחב לכתוב בלי הפרעות, אבל נותן משוב מיידי ברגע שהוא מנסה לתקן טעות שכבר סומנה.
הודעות שגיאה שבאמת עוזרות¶
"קלט לא תקין" היא ההודעה הכי פחות שימושית שאפשר לכתוב. היא לא אומרת למשתמש מה קרה, ובטח שלא מה לעשות הלאה.
הודעת שגיאה טובה עונה על שאלה אחת: "מה בדיוק צריך לתקן?" במקום "שדה לא תקין" - "כתובת האימייל חייבת להכיל @". במקום "סיסמה לא תואמת לדרישות" - "הסיסמה חייבת לכלול לפחות 8 תווים ואות אחת גדולה".
כלל אצבע פשוט: אם אתם קוראים את הודעת השגיאה שלכם ולא ברור לכם מיד מה לעשות כדי לתקן אותה, המשתמש שלכם גם לא יבין. נסחו את ההודעה כפתרון, לא כאבחון.
נגישות - שגיאה שלא רואים היא שגיאה שלא קיימת¶
הרבה טפסים מסמנים שדה שגוי רק בצבע אדום. זה נראה מספיק ברור למי שרואה את המסך בבירור, אבל זה נכשל לגמרי עבור משתמשים עיוורי צבעים, ולגמרי לא קיים עבור מי שמשתמש בקורא מסך.
שתי נקודות חשובות כאן. ראשית, אף פעם לא רק צבע - תמיד להוסיף גם טקסט, אייקון, או שניהם. שנית, ולזה הרבה מפתחים לא שמים לב, השגיאה צריכה להיות מקושרת תכנותית לשדה, לא רק ממוקמת ליד ה-input באופן ויזואלי. אם אתם משתמשים ב-HTML רגיל, זה אומר לקשר בין תווית השגיאה לשדה עצמו כך שקורא מסך יקריא את השגיאה כשהמשתמש מגיע לשדה, ולא רק שהיא "יושבת שם" בדף מבחינה ויזואלית.
שדה שגוי צריך גם להיות מסומן ככזה מבחינת state סמנטי, לא רק ויזואלי - כך שכלי עזר יידעו להודיע עליו כ"שדה עם שגיאה" ולא סתם כטקסט רגיל בדף.
וולידציה בצד לקוח היא נוחות, לא אבטחה¶
הנקודה הכי חשובה בכל הפוסט הזה, ולמרבה הצער הכי הרבה מפתחים מדלגים עליה: וולידציה שרצה בדפדפן היא אך ורק לטובת חוויית המשתמש. היא נותנת משוב מיידי בלי לחכות לתשובה מהשרת, וזה נהדר. אבל היא לא, ולעולם לא תהיה, שכבת הגנה.
כל בדיקה שאתם עושים ב-JavaScript אפשר לעקוף. משתמש יכול לכבות JavaScript, לשנות את הקוד בכלי הפיתוח, או פשוט לשלוח בקשה ישירות לשרת בלי לעבור דרך הטופס בכלל. אם השרת סומך על כך שהנתונים כבר "נבדקו" בצד הלקוח, זו פרצת אבטחה, לא הנחה סבירה.
לכן, כל שדה שנבדק בצד הלקוח חייב להיבדק שוב, באותה קפדנות, בצד השרת. אם אתם עובדים בצד לקוח כמו בקורס צד לקוח, חשוב לזכור שהוולידציה שאתם בונים שם היא חצי מהתמונה בלבד - החצי השני חייב לקרות בשרת, בלי יוצא מן הכלל.
לסיכום¶
וולידציה טובה היא לא עניין של "לבדוק אם השדה ריק", היא עניין של תזמון נכון, ניסוח אנושי, ונגישות אמיתית - ותמיד, תמיד, גיבוי בצד השרת. אם תשקיעו בזה מחשבה, הטופס שלכם יפסיק להרגיש כמו מכשול ויתחיל להרגיש כמו עוזר.
יש לכם שאלות או דעות על הדפוסים האלה? נשמח לשמוע בדיסקורד.