جدول داده زمانی مناسب است که کاربر بخواهد مقادیر چند رکورد را در ستون‌های مشترک بخواند و مقایسه کند. اگر فقط چند روایت مستقل دارید، شاید فهرست ساده بهتر باشد. طراحی جدول از کاری شروع می‌شود که کاربر انجام می‌دهد: پیدا کردن سفارش، مقایسه مبلغ یا انتخاب چند مورد برای اقدام. ظاهر مرتب به تنهایی این کارها را ممکن نمی‌کند. نام ستون، ترتیب، واحد و وضعیت باید روشن باشند. توصیه‌های کلی مثل راست‌چین‌کردن همه اعداد یا تبدیل همه جدول‌ها به کارت، بدون توجه به داده و نیاز مقایسه، می‌توانند نتیجه نامناسب بدهند.
کار اصلی و ستون‌های لازم را مشخص کنید
برای هر ستون دلیل داشته باشید. اگر کاربر برای پیگیری سفارش به شناسه، مشتری، وضعیت و زمان نیاز دارد، این‌ها اولویت دارند. اطلاعات کم‌استفاده می‌تواند در جزئیات رکورد باشد. با این حال، حذف ستونی که برای مقایسه لازم است کار را به بازکردن چند صفحه تبدیل می‌کند. از مشاهده مسیر واقعی کمک بگیرید و معلوم کنید کدام اطلاعات کنار هم لازم‌اند. عرض جدول را فقط با تعداد ستون بسنجید؛ طول محتوا، واحدها و اقدام‌ها هم در فضای مورد نیاز دخالت دارند.
نام ستون باید مفهوم داده را بدهد. «تاریخ» وقتی چند تاریخ دارید مبهم است؛ «زمان ثبت» دقیق‌تر است. «مبلغ» بدون واحد می‌تواند برداشت متفاوت ایجاد کند. اگر داده ناموجود است، قرارداد نمایش بنویسید و آن را با صفر برابر نگذارید. صفر یک مقدار واقعی است و نبود مقدار چیز دیگری. در گزارش و export هم همین تفاوت را حفظ کنید. جدول خوب به معنی تفسیرهای مهم توجه می‌کند، نه فقط به فاصله میان سلول‌ها.
HTML رابطه سطر و ستون را توضیح دهد
راهنمای جدول W3C استفاده از header، scope و caption را توضیح می‌دهد. برای داده جدولی، table معنای مناسب دارد و صرفاً یک layout قدیمی نیست. caption موضوع را معرفی می‌کند و th رابطه عنوان با داده را نشان می‌دهد. اگر جدول پیچیده با عنوان‌های چندسطحی دارید، روش ارتباط headerها را از همان مرجع بخوانید. بزرگ و پررنگ‌کردن یک td نقش عنوان ستون را ایجاد نمی‌کند. markup باید رابطه واقعی را به فناوری کمکی برساند.
برای یک جدول ساده، scope=col عنوان ستون و scope=row عنوان سطر را روشن می‌کند. ستون نخست ممکن است شناسه یا نام رکورد باشد و نقش عنوان سطر داشته باشد. جدول‌های پیچیده با merge متعدد می‌توانند فهم را دشوار کنند؛ پیش از افزودن spans، ببینید تقسیم به چند جدول ساده‌تر ممکن است یا نه. طراحی باید کار خواننده را آسان کند. شکل خروجی spreadsheet نباید بدون بررسی به ساختار صفحه وب تبدیل شود، چون تعامل و محیط نمایش متفاوت‌اند.
نمونه کامل جدول فارسی
فایل زیر را با نام orders-table.html ذخیره کنید و در مرورگر باز کنید. سه سفارش فرضی دارد و هیچ داده واقعی مشتری در آن نیست. وابستگی، تصویر و JavaScript ندارد. caption، عنوان‌های ستون و عنوان سطر در markup حاضرند. wrapper در عرض کم اسکرول افقی می‌دهد و نام قابل فهم دارد. این نمونه فقط نمایش داده است؛ مرتب‌سازی یا انتخاب ردیف انجام نمی‌دهد. اگر این رفتارها را اضافه می‌کنید، قرارداد کنترل و اعلام نتیجه را هم باید پیاده کنید.
<!doctype html>
<html lang="fa" dir="rtl">
<head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>جدول سفارش‌های نمونه</title>
<style>body{font-family:sans-serif;line-height:1.8;padding:1rem;color:#172333}main{max-width:60rem;margin-inline:auto}.table-scroll{overflow-x:auto}table{border-collapse:collapse;width:100%;min-width:34rem}caption{text-align:start;font-weight:bold;padding:.75rem}th,td{padding:.75rem;text-align:start;border-bottom:1px solid #b8c6d8}thead{background:#e8eef6}tbody tr:nth-child(even){background:#f5f7fa}.number{font-variant-numeric:tabular-nums;white-space:nowrap}:focus-visible{outline:3px solid #914200;outline-offset:3px}</style></head>
<body><main><h1>سفارش‌ها</h1><p>داده‌ها فرضی‌اند. در عرض کم، جدول را افقی پیمایش کنید.</p>
<div class="table-scroll" role="region" aria-label="جدول سفارش‌های نمونه با پیمایش افقی" tabindex="0">
<table><caption>سه سفارش آموزشی</caption><thead><tr><th scope="col">شناسه سفارش</th><th scope="col">نام نمونه</th><th scope="col">مبلغ (تومان)</th><th scope="col">وضعیت</th></tr></thead>
<tbody><tr><th scope="row" dir="ltr">ORD-101</th><td>مشتری الف</td><td class="number">۱٬۲۰۰٬۰۰۰</td><td>در حال آماده‌سازی</td></tr>
<tr><th scope="row" dir="ltr">ORD-102</th><td>مشتری ب</td><td class="number">۸۵۰٬۰۰۰</td><td>ارسال‌شده</td></tr>
<tr><th scope="row" dir="ltr">ORD-103</th><td>مشتری پ</td><td class="number">۲٬۱۰۰٬۰۰۰</td><td>در انتظار پرداخت</td></tr></tbody></table>
</div></main></body></html>
در نمونه، شناسه ستون LTR دارد و برای مقدارهای عددی از tabular-nums استفاده شده تا عرض رقم‌ها در فونت پشتیبانی‌شده منظم‌تر باشد. همه عددها صرفاً به دلیل عددبودن یک جهت واحد نمی‌گیرند؛ شناسه، مبلغ و تاریخ قالب متفاوت دارند. مبلغ با واحد در عنوان آمده است. سه وضعیت متن واضح دارند و فقط رنگ حامل معنی نیست. جدول حداقل عرض مشخص دارد و در wrapper اسکرول می‌شود، به جای اینکه ستون‌های ضروری بی‌توضیح ناپدید شوند.
تراکم را با کاربر هماهنگ کنید
برای کارشناس که هر روز تعداد زیادی رکورد می‌خواند، تراکم بیشتر ممکن است مفید باشد. برای کاربر تازه یا صفحه تلفن، فاصله و توضیح بیشتری لازم است. یک density عمومی برای همه محیط‌ها انتخاب نکنید. اندازه لمس و خوانایی متن را با تعداد ردیف‌های قابل مشاهده بسنجید. اگر تنظیم تراکم دارید، معنای هر حالت و اثرش روشن باشد. کاهش ارتفاع ردیف نباید پیام چندخطی یا دکمه را پنهان کند. داده واقعی طولانی را در طراحی ببینید.
Zebra Striping می‌تواند دنبال‌کردن سطر را آسان‌تر کند، اما کنتراست و مرز گروه‌ها هم مهم‌اند. رنگ‌ها نباید با وضعیت انتخاب یا خطا اشتباه شوند. اگر hover دارید، کاربر صفحه‌کلید نیز باید وضعیت focus را بفهمد. Sticky Header برای جدول بلند کاربرد دارد، اما نباید کنترل فعال یا متن را بپوشاند. هر بهبود دیداری را با محیط اسکرول و ارتفاع صفحه هماهنگ کنید. جمع‌شدن چند رفتار ثابت ممکن است بخش بزرگی از فضای کوچک را اشغال کند.
مرتب‌سازی باید وضعیت قابل فهم داشته باشد
اگر ستون قابل sort است، کنترل آن باید با صفحه‌کلید قابل استفاده و جهت مرتب‌سازی مشخص باشد. یک icon بدون نام و وضعیت کافی نیست. مرتب‌سازی عدد، تاریخ و رشته قرارداد متفاوت دارد. مبلغی که به شکل متن قالب‌بندی‌شده مقایسه می‌شود ممکن است ترتیب نادرستی بگیرد. مقدار خام را از نمایش جدا نگه دارید. اگر sort در سرور انجام می‌شود، زمان انتظار و خطا را نشان دهید. کاربر باید بداند جدول تازه شده یا هنوز ترتیب قبلی را می‌بیند.
فیلتر فعال نیز باید قابل یافتن و پاک‌کردن باشد. نبود نتیجه با نبود داده اولیه فرق دارد؛ در اولی می‌توان اصلاح یا حذف فیلتر را پیشنهاد داد. تعداد نتیجه باید با قرارداد backend هماهنگ باشد. اگر فقط صفحه حاضر بارگذاری شده، آن را با تعداد کل برابر نگیرید. مقاله Infinite Scroll درباره بارگذاری تدریجی ادامه مرتبطی دارد. انتخاب pagination یا بارگذاری بیشتر باید به امکان مقایسه، پیگیری موقعیت و حجم داده وصل شود.
انتخاب ردیف و اقدام گروهی
Checkbox هر ردیف باید نام قابل فهم داشته باشد و انتخاب همه محدوده روشن بدهد. «همه» یعنی ردیف‌های صفحه فعلی یا همه نتیجه‌های فیلتر؟ این تفاوت برای حذف یا تغییر گروهی مهم است. تعداد انتخاب‌شده و اقدام مجاز را نشان دهید. اگر بعضی ردیف‌ها مجوز متفاوت دارند، پیامد را پیش از اقدام توضیح دهید. یک کنترل عمومی که بعداً برای چند ردیف خطا می‌دهد، کاربر را درباره نتیجه کل عملیات سردرگم می‌کند. قرارداد اقدام باید از قبل معلوم باشد.
برای عملیات حساس، تأیید باید موضوع و دامنه را مشخص کند. جمله «مطمئنید؟» بدون نام کار و تعداد رکورد اطلاعات کمی می‌دهد. پس از اجرا، موفق و ناموفق را از هم جدا گزارش کنید و مسیر بازیابی بدهید، اگر سیستم آن را دارد. icon حذف نباید کنار کنترل‌های متداول بدون نام و فاصله مناسب قرار بگیرد. طراحی جدول به عملیات backend وابسته است؛ شکل button نمی‌تواند اتمیک‌بودن یا امکان بازگشت عمل را تضمین کند.
عرض کوچک و نیاز مقایسه
تبدیل ردیف‌ها به کارت برای برخی داده‌ها مناسب است، اما مقایسه ستونی را دشوار می‌کند. اگر کاربر چند مبلغ را کنار هم می‌خواهد، اسکرول افقی محدود ممکن است انتخاب بهتری باشد. اگر هر رکورد مستقل خوانده می‌شود، کارت می‌تواند معنی عنوان‌ها را با داده همراه کند. تصمیم را از کار اصلی بگیرید. ستون اولویت‌دار را هم فقط وقتی مخفی کنید که اطلاعات حذف‌شده راه دسترسی روشن داشته باشد. نسخه کوچک نباید نسخه ناقص و بی‌توضیح محصول باشد.
در RTL، محل آغاز جدول و اسکرول را با جهت محتوا هماهنگ کنید. شناسه و URL ممکن است LTR بخواهند، در حالی که نام و توضیح فارسی RTL باشند. نمایش رشته ترکیبی را با نمونه طولانی ببینید. قطع متن باید با راه دریافت کامل همراه باشد، اگر آن متن برای تصمیم لازم است. مقاله Grid و Flexbox درباره layout صفحه ادامه دارد، اما داده جدولی را صرفاً برای استفاده از Grid از semantics مناسب جدا نکنید.
Export و اطلاعات زنده
اگر export دارید، معلوم کنید کدام داده خارج می‌شود: کل نتیجه فیلتر یا صفحه فعلی. واحد، timezone و قالب تاریخ باید در فایل نیز روشن باشند. داده حساس را بدون نیاز وارد خروجی نکنید. مجوز دانلود باید با مجوز مشاهده هماهنگ باشد و صرف وجود دکمه در UI کافی نیست. اگر داده در حال تغییر است، زمان تهیه خروجی را ثبت کنید. کاربر نباید فایل را وضعیت لحظه‌ای قطعی بداند وقتی ساخت آن چند دقیقه پیش انجام شده است.
برای شروع، یک جدول مهم را با کار اصلی، ستون‌ها و معنی مقدارهای خالی مستند کنید. سپس markup، عرض کوچک، sort و وضعیت خطا را به همان قرارداد وصل کنید. مقاله دسترسی‌پذیری سایت فارسی برای بررسی مسیر صفحه‌کلید کمک می‌کند. اصلاح را از مانعی انتخاب کنید که تصمیم یا اقدام کاربر را متوقف می‌کند. یک جدول قابل نگهداری اطلاعات را با رابطه روشن نمایش می‌دهد و درباره محدوده داده و نتیجه عملیات صادق است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!