از یک حالت خالی کلی برای جداول داده خود استفاده نکنید

بیشتر جداول داده تنها با یک پیام عرضه می‌شوند: «داده‌ای وجود ندارد.»

این موضوع در بررسی‌های طراحی خوب به نظر می‌رسد، اما در محیط عملیاتی (production) باعث ایجاد تیکت‌های پشتیبانی می‌شود.

یک جدول خالی می‌تواند به سه معنای متفاوت باشد. هر مورد به طراحی، متن و اقدام (action) خاص خود نیاز دارد.

در اینجا سه موردی که باید به‌صورت جداگانه طراحی کنید آورده شده است:

۱. اولین استفاده (هنوز داده‌ای وجود ندارد) کاربر تازه‌وارد است. او می‌خواهد بداند این جدول چه کاری انجام می‌دهد و چگونه باید شروع کند. • هدف: آشناسازی کاربر (Onboarding). • متن: توضیح هدف جدول. • اقدام: ارائه دکمه‌ای برای ایجاد اولین آیتم یا وارد کردن (import) داده‌ها. • پرهیز از: پیام‌های بن‌بست مانند «داده‌ای وجود ندارد».

۲. خالیِ فیلتر شده (داده‌ها وجود دارند اما فیلترها آن‌ها را پنهان کرده‌اند) کاربر فیلترهایی را اعمال کرده که هیچ نتیجه‌ای ندارند. آن‌ها اغلب فکر می‌کنند ابزار خراب شده است. • هدف: کمک به کاربر برای یافتن داده‌هایش. • متن: به‌طور صریح ذکر کنید که کدام فیلترها فعال هستند. • اقدام: ارائه دکمه‌ای برای پاک کردن تمام فیلترها یا ویرایش آن‌ها. • پرهیز از: یک پیام کلی که فیلترهای فعال را نادیده می‌گیرد.

۳. شکست در بارگذاری (درخواست با خطا مواجه شده است) سرور خطایی برگردانده یا شبکه قطع شده است. • هدف: کمک به کاربر برای بازیابی وضعیت. • متن: توضیح دهید که بارگذاری با شکست مواجه شده و یک برچسب زمانی یا کد خطا را نمایش دهید. • اقدام: ارائه دکمه تلاش مجدد (retry). • پرهیز از: گفتن «داده‌ای وجود ندارد» به کاربر، در حالی که مشکل در واقع یک خطای فنی است.

چرا تیم‌ها در این زمینه شکست می‌خورند:

  • آن‌ها حالت‌های خالی را خیلی دیر در فرآیند طراحی می‌کنند.
  • آن‌ها فقط با داده‌های آزمایشی (demo data) تست می‌کنند، بنابراین هرگز حالت خالی را نمی‌بینند.
  • آن‌ها با حالت‌های خالی مانند موارد استثنایی (edge cases) برخورد می‌کنند.

در واقعیت، حالت‌های خالی لحظاتی با تاثیرگذاری بالا هستند. یک حالت خالی خوب، کاربر را در عرض چند دقیقه از نقطه صفر به مرحله بهره‌مندی از ارزش محصول می‌رساند. یک حالت خالی بد، کاربر را گیج و ناامید می‌کند.

کامپوننت جدول خود را به‌گونه‌ای بسازید که این شرایط را به‌طور جداگانه مدیریت کند. طراحی آن‌ها در حال حاضر هزینه کمی دارد، اما در آینده باعث صرفه‌جویی در حجم عظیمی از زمان پشتیبانی می‌شود.

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