طراحی وب

طراحی Timeline و نمایش زمانی

تفاوت تاریخچه با مرحله‌های آینده، تقویم و زمان معتبر، گروه‌بندی و دسترس‌پذیری با نمونه مستقل سه‌رویدادی بدون وابستگی.

1404/12/25 2 دقیقه مطالعه 1,369 بازدید

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

تاریخچه شرکت، سابقه تغییر یک سند و مسیر تحویل سفارش ساختارهای یکسانی نیستند. تاریخچه رویدادهای رخ‌داده را نمایش می‌دهد؛ فرایند می‌تواند قدم‌های هنوز انجام‌نشده داشته باشد. این تفاوت را از ابتدا مشخص کنید. مرحله‌ای که انتظار می‌رود اتفاق بیفتد نباید با تاریخ قطعی نمایش داده شود، مگر آنکه واقعاً برنامه زمان‌بندی معتبر وجود داشته باشد. برچسب «پیش‌بینی» یا «در انتظار» به رفع این ابهام کمک می‌کند.

ترتیب را از هدف مشاهده انتخاب کنید

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

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

تاریخ خوانا و تاریخ قابل پردازش

متن تاریخ باید برای مخاطب قابل فهم باشد و تقویم آن روشن بماند. در رابط فارسی، استفاده از تاریخ هجری شمسی می‌تواند مناسب باشد، ولی مقدار قابل پردازش باید بر اساس قالب معتبر تعیین شود. عنصر time در HTML امکان همراه کردن متن قابل مشاهده با datetime را فراهم می‌کند. نوشتن هر رشته دلخواه در datetime آن را معتبر نمی‌کند.

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

نمونه کامل سه رویدادی

فایل زیر را به نام timeline.html با UTF-8 ذخیره و به صورت HTML باز کنید. CSS در style همان فایل قرار دارد و وابستگی، تصویر یا JavaScript ندارد. سه رویداد مربوط به یک فرایند فرضی انتشار نوشته شده‌اند؛ این تاریخ‌ها داده واقعی عملکرد سایت نیستند. فهرست به ترتیب قدیمی به جدید است و هر مورد عنوان، تاریخ و توضیح دارد. نمونه مرحله آینده یا وضعیت زنده را شبیه‌سازی نمی‌کند.

<!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{margin:0;background:#f2f4f7;color:#17243b;font-family:Tahoma,Arial,sans-serif;line-height:1.9}main{width:min(40rem,calc(100% - 2rem));margin:auto;padding-block:2rem}.timeline{list-style:decimal;padding-inline-start:2rem}.event{position:relative;padding-inline-start:1.5rem;padding-block-end:1.75rem;border-inline-start:2px solid #536a8a;overflow-wrap:anywhere}.event::before{content:'';position:absolute;inset-inline-start:-.45rem;inset-block-start:.6rem;width:.75rem;height:.75rem;background:#173f78;border:2px solid #f2f4f7;border-radius:50%}.event:last-child{padding-block-end:0}.event h2{font-size:1.2rem;margin:0}.event p{margin-block:.4rem 0}.event time{color:#334968;font-size:.95rem}</style></head>
<body><main><h1>رویدادهای انتشار نمونه</h1><p>سه رویداد آموزشی با تاریخ میلادی، به ترتیب قدیمی به جدید.</p><ol class="timeline">
<li class="event"><h2>تکمیل متن</h2><time datetime="2026-10-01">۱ اکتبر ۲۰۲۶</time><p>متن آموزشی آماده مرور تحریری شد.</p></li>
<li class="event"><h2>مرور محتوا</h2><time datetime="2026-10-02">۲ اکتبر ۲۰۲۶</time><p>عنوان‌ها و ترتیب توضیح‌های نمونه مرور شد.</p></li>
<li class="event"><h2>آماده‌سازی نسخه</h2><time datetime="2026-10-03">۳ اکتبر ۲۰۲۶</time><p>نسخه فرضی برای توضیح نمایش زمانی آماده شد.</p></li>
</ol></main></body></html>

فهرست ordered list ترتیب را حفظ می‌کند و هر item یک رویداد است. خط و نقطه با pseudo-element ساخته شده‌اند و محتوای ضروری در خود متن باقی می‌ماند. اگر CSS نمایش داده نشود، سه رویداد همچنان به صورت فهرست قابل خواندن هستند. عناصر time فقط تاریخ هر رویداد را مشخص می‌کنند. نمونه از رنگ برای تمایز وضعیت‌ها استفاده نکرده چون همه موردها رویداد انجام‌شده آموزشی هستند.

چیدمان عمودی و افقی را با محتوا انتخاب کنید

چیدمان عمودی در فضای باریک می‌تواند مرور توضیح‌های چندخطی را آسان کند، اما «همیشه بهترین برای موبایل» حکم دقیقی نیست. Timeline افقی ممکن است برای تعداد محدود مرحله‌های کوتاه مناسب باشد؛ در سابقه طولانی می‌تواند اسکرول و یافتن رویداد را دشوار کند. طول عنوان، تعداد رویداد و نیاز به مقایسه زمان‌ها در انتخاب اثر دارند. شکل باید از محتوا پیروی کند.

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

وضعیت جاری را با رویداد گذشته مخلوط نکنید

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

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

گروه‌بندی و جزئیات

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

نوع رویداد می‌تواند با آیکون یا برچسب متنی نشان داده شود. رنگ تنها برای تشخیص نوع کافی نیست. درباره انتخاب نشانه‌ها، راهنمای آیکونوگرافی به تفکیک تصویر تزئینی و اطلاعات کاربردی کمک می‌کند. اگر هر رویداد شکل متفاوت دارد، تعداد شکل‌ها را قابل فهم نگه دارید؛ یک واژه دقیق اغلب از نمادی که مخاطب باید معنی آن را حفظ کند روشن‌تر است.

فیلتر، جستجو و صفحه‌بندی

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

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

دسترس‌پذیری در ساختار محتوا

راهنمای ساختار محتوا در W3C نقش عنوان‌ها و فهرست‌ها را در مرور صفحه توضیح می‌دهد. Timeline باید بدون وابستگی به خط تزئینی هم رابطه موردها را بیان کند. متن لینک‌ها مقصد را مشخص کند و دکمه جزئیات به رویداد مربوط باشد. در فهرست ایستا، نیازی به تبدیل همه موردها به کنترل قابل focus نیست؛ فقط عناصر تعاملی باید رفتار تعاملی داشته باشند.

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

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

واکنش به این مقاله

اشتراک‌گذاری این مقاله:
دیدگاه‌ها 0
۰ / ۲۰۰۰

هنوز دیدگاهی ثبت نشده

اولین نفری باشید که نظر می‌دهد!