منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · شهریور ۱۴۰۵ · زمان مطالعه: حدود ۸ دقیقه

تقویم رویداد (Event Calendar) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

ورود تاریخ یکی از آن کارهای ساده است که سال‌هاست خراب می‌شود. شش تا هشت رقم، و همچنان اشتباه.

دلیلش این نیست که کاربر بی‌دقت است. دلیلش این است که یک رشتهٔ عددی، خودش به‌تنهایی معنای روشنی ندارد.

تقویم رویداد راه‌حل قدیمی و جاافتادهٔ این مسئله است. این نوشته هم دربارهٔ خودِ الگوست و هم دربارهٔ جاهایی که الگو کافی نیست.

تقویم رویداد چیست؟

تقویم رویداد یعنی به‌جای اینکه کاربر تاریخ را تایپ کند، شبکه‌ای از روزهای یک ماه را ببیند و روی یکی کلیک کند.

این الگو در کتاب‌های الگوی رابط سابقهٔ طولانی دارد. Jenifer Tidwell در «طراحی رابط‌ها» و کتابخانهٔ الگوی Martijn van Welie هر دو ثبتش کرده‌اند.

کاربرد اصلی‌اش هم جایی است که تاریخ به یک بازه یا یک موجودی وصل است: رزرو هتل، بلیت، نوبت‌دهی، و تحویل سفارش.

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

در رزرو هتل این تفاوت حیاتی است. کاربر نه‌تنها روز را انتخاب می‌کند، بلکه می‌بیند کدام شب‌ها پر است و کدام ارزان‌تر.

نکتهٔ مهم این است که تقویم فقط یک روش ورودی نیست. یک نمایش هم هست.

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

چرا کلیک از تایپ بهتر است

پاسخ کوتاه: چون قالب تاریخ در کشورهای مختلف یکی نیست.

نمودار بالای صفحه همین را نشان می‌دهد. یک رشتهٔ واحد می‌تواند در یک کشور «۴ مارس» خوانده شود و در کشور دیگر «۳ آوریل».

هیچ‌کدام از این دو خوانش غلط نیست. مسئله این است که رشته به‌تنهایی نمی‌گوید کدام قرارداد را باید به کار برد.

وقتی کاربر روی یک خانه کلیک می‌کند، این ابهام کلاً از معادله حذف می‌شود. خانه فقط یک روز است.

کنارش یک صرفه‌جویی هم هست. کلیک کردن از تایپ کردن سریع‌تر است، مخصوصاً روی موبایل که صفحه‌کلید عددی و جداکننده‌ها دردسر دارند.

و هزینهٔ خطا در این حوزه بالاست. تاریخ اشتباه یعنی پرواز از دست رفته یا هتلی که شب اشتباه رزرو شده — از آن خطاهای انسانی که بعداً جبرانشان گران است.

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

این همان منطق قالب‌های بخشنده است: ورودی را به چند شکل بپذیرید و خودتان تمیزش کنید.

هفت قاعدهٔ پیاده‌سازی

منبع اصلی هفت قاعدهٔ عملی می‌دهد که تقریباً همه‌شان از شکست‌های واقعی درآمده‌اند:

• - ۱. پیش‌فرض پنهان باشد: تقویم با کلیک روی فیلد یا آیکون باز شود، نه اینکه همیشه بخشی از صفحه را اشغال کند.
• - ۲. فقط بازهٔ معنادار را نشان دهید: روزهای غیرقابل انتخاب را خاکستری کنید تا کاربر وقتش را روی گزینهٔ ناموجود تلف نکند.
• - ۳. میان‌بر پیمایش بگذارید: جابه‌جایی ماه و سال و یک دکمهٔ «امروز» لازم است، وگرنه رسیدن به تاریخ دور کلافه‌کننده می‌شود.
• - ۴. فیلد را بلافاصله پر کنید: با انتخاب هر روز، مقدار در فیلد بنشیند تا کاربر بازخورد ببیند.
• - ۵. بازه را معتبر نگه دارید: اجازه ندهید تاریخ پایان جلوتر از تاریخ شروع انتخاب شود.
• - ۶. هفته‌های کامل را نشان دهید: روزهای ابتدا و انتهای ماه‌های مجاور را هم بیاورید تا هفته نصفه نماند.
• - ۷. خانه‌ها به‌قدر کافی بزرگ باشند: این مستقیماً از قانون فیتس می‌آید؛ هدف کوچک یعنی خطای بیشتر، مخصوصاً با انگشت.

قاعدهٔ دوم بیشتر از آنکه دربارهٔ راحتی باشد، دربارهٔ صداقت است. روزی که خاکستری نشده، یک وعده است.

قاعدهٔ سوم هم جزئیاتی دارد که معمولاً فراموش می‌شود: پرش سال. تقویمی که فقط دکمهٔ ماه بعد و ماه قبل دارد، برای تاریخی یک سال بعدتر دوازده کلیک می‌خواهد.

قاعدهٔ هفتم روی موبایل از همه مهم‌تر است و از همه بیشتر نادیده گرفته می‌شود. شبکه‌ای که روی دسکتاپ مرتب است، روی گوشی می‌تواند به خانه‌های بیست‌پیکسلی تبدیل شود.

کجا نباید سراغ تقویم رفت

این الگو یک محدودهٔ مشخص دارد و بیرون از آن به ضد خودش تبدیل می‌شود.

مثال روشنش تاریخ تولد است. تقویمی که ماه‌به‌ماه جلو و عقب می‌رود، برای رسیدن به سالی سی سال قبل، ده‌ها بار پیمایش می‌خواهد.

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

تقویم وقتی خوب است که تاریخ موردنظر نزدیک باشد و بافت هفته اهمیت داشته باشد. وقتی تاریخ دور است و بافت بی‌اهمیت، تقویم فقط یک مانع تزئینی است.

نشانهٔ تشخیصش هم ساده است. اگر کاربر برای رسیدن به تاریخ موردنظر باید بیش از دو بار ماه را عوض کند، تقویم ابزار درستی نیست.

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

خطاهایی که تقویم نمی‌گیرد

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

• - ۱. منطقهٔ زمانی: کاربر روی «۱۲ مهر» کلیک می‌کند و سرور آن را در منطقهٔ زمانی دیگری ذخیره می‌کند. نتیجه‌اش یک روز جابه‌جایی است که فقط نزدیک نیمه‌شب خودش را نشان می‌دهد.
• - ۲. بازهٔ نیمه‌تمام: کاربر تاریخ شروع را زده و حالا می‌خواهد عوضش کند. بیشتر تقویم‌ها این حالت را پیش‌بینی نکرده‌اند و کاربر گیر می‌کند.
• - ۳. موجودی کهنه: روزی که خاکستری نیست، لزوماً هنوز موجود نیست. فاصلهٔ میان باز شدن تقویم و ثبت نهایی، جایی است که رزروها به هم می‌خورند.
• - ۴. صفحه‌کلید و صفحه‌خوان: شبکه‌ای که فقط با ماوس کار می‌کند، برای بخشی از کاربران عملاً وجود ندارد.

مورد اول را با یک مثال روشن‌تر می‌شود دید. کاربری در تهران روز تحویل را «۱۲ مهر» می‌زند و سامانه آن را به‌صورت نیمه‌شب به وقت جهانی ذخیره می‌کند.

نتیجه در پایگاه داده «۱۱ مهر» می‌شود. تا وقتی همه در یک منطقهٔ زمانی باشند، کسی متوجه نمی‌شود.

مورد دوم از همه رایج‌تر است و راه‌حلش هم ساده است. کلیک دوم روی تاریخ شروع باید انتخاب را ریست کند، نه اینکه نادیده گرفته شود.

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

جمع این چهار مورد یک نکتهٔ کلی‌تر می‌سازد. تقویم یک ویجت ورودی است و درستیِ داده را تضمین نمی‌کند؛ اعتبارسنجی همچنان کار سمت سرور است.

در بافت فارسی: مسئلهٔ تقویم شمسی

برای کاربر ایرانی، این بحث یک لایهٔ اضافه دارد که در منبع اصلی فقط با عبارت «تفاوت‌های فرهنگی» به آن اشاره شده است.

رایج‌ترین اشتباه این است که تیم یک تقویم میلادی آماده برمی‌دارد و فقط نام ماه‌ها و ارقامش را فارسی می‌کند. نتیجه، تقویمی است که فارسی به نظر می‌رسد و شمسی نیست.

نمودار بالا نشان می‌دهد چرا این کار جواب نمی‌دهد. دو شبکه از سه جهت با هم فرق دارند.

اول اینکه ستون اول در تقویم شمسی شنبه است و در میلادی یک‌شنبه یا دوشنبه. دوم اینکه شبکهٔ شمسی از راست پر می‌شود و میلادی از چپ.

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

طول ماه‌ها هم یکسان نیست. شش ماه اول سال ۳۱ روز دارند، پنج ماه بعد ۳۰ روز، و اسفند بسته به کبیسه ۲۹ یا ۳۰ روز.

این یعنی محاسبهٔ کبیسه در تقویم شمسی قاعدهٔ خودش را دارد و با قاعدهٔ میلادی یکی نیست. اگر کتابخانه‌ای که استفاده می‌کنید این را درست پیاده نکرده باشد، خطایش سالی یک بار و دقیقاً در بدترین زمان بیرون می‌زند.

یک نکتهٔ کاربردی هم بماند: تعطیلات رسمی را علامت بزنید. برای رزرو، تحویل سفارش و نوبت‌دهی، تعطیل بودن یک روز به‌اندازهٔ خود تاریخ اهمیت دارد.

یک تصمیم دیگر هم هست که زیاد از آن غفلت می‌شود: نمایش همزمان هر دو تقویم.

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

لازم نیست این کار همه‌جا انجام شود. فقط جایی که تاریخ قرار است با کسی بیرون از ایران رد و بدل شود.

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

جمع‌بندی

تقویم رویداد یکی از معدود الگوهایی است که مسئله‌اش کاملاً روشن است: ابهام قالب تاریخ را با یک انتخاب بصری حذف می‌کند.

ولی مثل هر الگو، محدوده دارد. برای تاریخ نزدیک عالی است و برای تاریخ دور مثل تاریخ تولد، مانع است.

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

برای محصول فارسی هم یک قاعدهٔ ساده کافی است: تقویم شمسی را تبدیل کنید، نه ترجمه. شبکهٔ میلادی با نام ماه فارسی، همچنان تقویم میلادی است.

و اگر بخواهم یک پرسش بگذارم: آخرین بار کِی انتخابگر تاریخ محصولتان را با صفحه‌کلید و بدون ماوس امتحان کردید؟