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

רוב טבלאות הנתונים מגיעות עם הודעה אחת בלבד: "אין נתונים".

זה נראה בסדר בסקירת עיצוב. זה יוצר פניות לתמיכה בסביבת הייצור (production).

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

להלן שלושת המקרים שעליכם לעצב בנפרד:

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

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

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

למה צוותים נכשלים בזה:

  • הם מעצבים מצבי ריק מאוחר מדי בתהליך.
  • הם בודקים רק עם נתוני דמו, ולכן הם לעולם לא רואים את המצב הריק.
  • הם מתייחסים למצבי ריק כאל מקרי קצה (edge cases).

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

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

Source: https://dev.to/137foundry/why-the-empty-states-in-a-data-table-deserve-three-separate-designs-instead-of-one-generic-message-1il4