Navigation باید به کاربر نشان دهد چه بخش‌هایی در سایت وجود دارد، اکنون کجاست و چگونه به مقصد بعدی می‌رسد. انتخاب Mega Menu، Sidebar یا دکمهٔ باز کردن منو، بعد از فهم ساختار محتوا انجام می‌شود. اگر دسته‌ها نام نامشخص یا هم‌پوشان داشته باشند، ظاهر مرتب منو مشکل را حل نمی‌کند. عدد ثابت «حداکثر هفت آیتم» نیز قانون عمومی طراحی نیست. تعداد مناسب به نام‌ها، گروه‌بندی، عرض و وظیفهٔ کاربر بستگی دارد و باید در همان زمینه بررسی شود.
یک سایت آموزشی فرضی را در نظر بگیرید که دوره، مقاله و ابزار دارد. کاربر ممکن است با موضوع وارد شود یا دنبال نوع محتوا باشد. اگر منو هر دو محور را بدون تفکیک کنار هم بگذارد، مشخص نیست «طراحی» یک موضوع است یا صفحهٔ خدمت. قبل از رسم header، چند وظیفهٔ واقعی را بنویسید؛ مثلاً پیدا کردن آموزش CSS یا مراجعه به ابزار رنگ. ساختار باید به همین مسیرها پاسخ دهد و از واژه‌های داخلی سازمان فاصله بگیرد.
برچسب‌ها را با زبان مخاطب بنویسید
نامی که تیم فروش یا توسعه استفاده می‌کند، الزاماً نام قابل فهم برای بازدیدکننده نیست. عنوان دسته باید دامنهٔ مقصد را روشن کند. «راهکارها» بدون زمینه می‌تواند به خدمات، محصولات یا مقاله‌ها اشاره کند. اگر نام کوتاه مبهم است، افزودن یک واژهٔ توضیحی گاهی از ساخت یک آیکون تازه مفیدتر است. برچسب باید در چند محل سایت یک معنی داشته باشد؛ تغییر نام یک مقصد در header و footer، کاربر را مجبور به حدس زدن رابطهٔ آن‌ها می‌کند.
برای ارزیابی نام‌ها، از فردی که ساختار داخلی را نمی‌شناسد بخواهید مقصد یک وظیفه را انتخاب کند و دلیلش را توضیح دهد. اگر مرتب میان دو دسته مردد است، مسئله ممکن است هم‌پوشانی محتوا باشد. افزودن زیرمنو همیشه جواب نیست. شاید باید مرز دسته‌ها عوض شود یا مقصدی در چند مسیر مرتبط قابل دسترسی باشد. نتیجهٔ این بررسی را به همان مخاطبان و وظیفه‌ها محدود گزارش کنید؛ از چند مشاهده نمی‌توان درصد موفقیت جهانی ساخت.
Navigation عمومی با Application Menu متفاوت است
فهرست لینک‌های سایت معمولاً به ساختار سادهٔ nav و list نیاز دارد. استفاده از role مربوط به menu می‌تواند انتظار رفتار پیچیدهٔ دیگری برای ابزارهای کمکی ایجاد کند. مثال Disclosure Navigation در W3C این تفاوت را توضیح می‌دهد. منویی که فقط صفحه‌های سایت را معرفی می‌کند، نباید صرفاً به خاطر نام روزمرهٔ «منو» به widget منوی برنامه تبدیل شود. نقش باید با رفتار واقعی هماهنگ باشد.
اگر کنترل فقط زیرمنو را باز می‌کند، button نقش مناسبی دارد. اگر به صفحهٔ دسته می‌رود، link است. ترکیب این دو عمل در یک هدف مبهم ممکن است در لمس و صفحه‌کلید مشکل ایجاد کند. در طراحی مشخص کنید کلیک نام دسته چه می‌کند و کنترل گسترش کجاست. اگر هر دو نیاز دارند، جدایی واضح آن‌ها می‌تواند کمک کند. قرارداد یکسان در تمام دسته‌ها از رفتاری که برای هر آیتم عوض می‌شود قابل پیش‌بینی‌تر است.
زیرمنو را برای چند روش ورودی طراحی کنید
Hover به‌تنهایی برای لمس و صفحه‌کلید کافی نیست. کاربر باید راه روشن باز و بسته کردن داشته باشد. اگر حرکت mouse از یک فاصلهٔ کوچک، زیرمنو را فوری می‌بندد، رسیدن به مقصد سخت می‌شود. آموزش منو در W3C ساختار، حالت‌ها و روش ورودی را کنار هم می‌بیند. این بخش باید از ابتدا در طراحی باشد؛ اضافه کردن یک شرط CSS در پایان لزوماً رفتار کامل ایجاد نمی‌کند.
پس از باز شدن زیرمنو، focus و ترتیب پیمایش را مشخص کنید. بسته شدن نباید focus را روی عنصری پنهان رها کند. دکمهٔ بازکننده باید حالت فعلی خود را اعلام کند و ارتباطش با بخش کنترل‌شده روشن باشد. برای منوی چندلایه، پیچیدگی همین قرارداد زیاد می‌شود. پیش از افزودن لایهٔ بعدی، بررسی کنید آیا صفحهٔ دستهٔ روشن‌تر یا ساختار کم‌عمق‌تر وظیفه را ساده‌تر می‌کند. هر شاخهٔ تازه هزینهٔ تعامل و نگهداری دارد.
جای کاربر را نشان دهید
حالت فعال باید مقصد فعلی را با نشانه‌ای بیش از تفاوت رنگ توضیح دهد. زیرخط، وزن مناسب یا برچسب قابل دسترس می‌تواند بخشی از آن باشد. این وضعیت با Hover فرق دارد؛ کاربر حتی بدون حرکت نشانگر باید جای خود را بفهمد. اگر header چند گروه دارد، معلوم باشد صفحهٔ فعلی زیر کدام گروه قرار می‌گیرد. نبود این ارتباط ممکن است باعث شود کاربر برای فهم ساختار دوباره منو را از ابتدا باز کند.
Breadcrumb برای سلسله‌مراتب محتوا مفید است، اما تاریخچهٔ بازدید نیست. مسیر «خانه، آموزش، CSS» نشان می‌دهد صفحه در چه ساختاری قرار دارد؛ الزاماً نمی‌گوید کاربر از چه صفحه‌ای آمده است. در محصول، این دو معنا را مخلوط نکنید. اگر صفحه از چند دسته قابل دسترسی است، مسیر اصلی آن باید با قرارداد محتوا هماهنگ باشد. ساخت Breadcrumb بر اساس آخرین کلیک ممکن است برای یک URL ثابت، مسیرهای نامفهوم متفاوتی ایجاد کند.
موبایل را نسخهٔ فشردهٔ desktop فرض نکنید
منوی موبایل به فضای کمتر، لمس و موقعیت متفاوت کنترل‌ها پاسخ می‌دهد. انتقال همهٔ لینک‌های desktop به یک panel طولانی، ممکن است فقط تراکم را پنهان کند. اولویت مقصدها را از وظیفه‌های اصلی بگیرید. اگر کاربر بیشتر به جست‌وجو نیاز دارد، آن را در عمق چند کلیک قرار ندهید. اگر اقدام اصلی رزرو است، منو نباید تنها راه رسیدن به آن باشد. چیدمان کوچک باید مسیر استفادهٔ واقعی را حفظ کند.
هنگام باز شدن panel، رفتار پس‌زمینه و اسکرول باید مشخص باشد. اگر منو به شکل modal عمل می‌کند، قرارداد focus و بسته شدن لازم است. اگر فقط بخشی از محتوا را باز می‌کند، رفتار دیگری دارد. نام «Hamburger» چیزی دربارهٔ این قرارداد نمی‌گوید؛ فقط شکل یک کنترل را توصیف می‌کند. برای ادامهٔ این تفاوت، راهنمای Modal و Dialog به طراحی پنل‌های محدودکنندهٔ تعامل کمک می‌کند.
Mega Menu برای محتوا، نه نمایش بزرگی سایت
یک Mega Menu زمانی مفید است که دسته‌ها و مقصدهایش برای خواندن در چند گروه روشن باشند. ستون‌های هم‌اندازه با عنوان‌های نامفهوم فقط حجم بیشتری از لینک را نمایش می‌دهند. هر گروه باید هدف مستقل و انکرهای قابل فهم داشته باشد. تصویر یا متن تبلیغاتی نیز نباید مسیر اصلی را عقب براند. اگر کاربر دنبال مقصد مشخص است، تشخیص دسته باید از جلوهٔ بصری آسان‌تر باشد. نقش منو با صفحهٔ تبلیغ محصول متفاوت است.
برای محتوای گسترده، جست‌وجو می‌تواند مسیر مکمل باشد. اما جست‌وجوی خوب جای ساختار نامعلوم را کامل پر نمی‌کند؛ کاربر باید بداند چه چیزی قابل جست‌وجوست. نتیجه و دسته‌های پیشنهادی نیز باید با نام‌های منو هماهنگ باشند. راهنمای Search و فیلتر برای این بخش مرتبط است. مکمل بودن این دو مسیر یعنی کاربر بتواند با دانستن نام یا با شناخت دسته، به مقصد برسد؛ نه اینکه همیشه مجبور به یک راه باشد.
نگهداری Navigation با نگهداری محتوا پیوند دارد
وقتی صفحه حذف یا جابه‌جا می‌شود، لینک منو و نام دسته باید هم‌زمان بررسی شوند. یک مقصد بدون مالک محتوا ممکن است سال‌ها در منو باقی بماند. برای هر گروه، مسئول تغییر و معیار افزودن مقصد را ثبت کنید. درخواست هر واحد سازمانی نباید بی‌حساب به یک آیتم اصلی تازه تبدیل شود. دامنهٔ منو از نیاز مخاطب می‌آید و توسعهٔ سازمان همیشه به معنی توسعهٔ سطح اول Navigation نیست.
در مرور طرح، مسیرهای واقعی را با نام مقصد و روش ورودی بررسی کنید. به عنوان طولانی فارسی، تغییر اندازهٔ متن، وضعیت فعال و بسته شدن زیرمنو توجه کنید. این‌ها نیازهای قابل مشاهده‌اند و از شعار «ناوبری نامرئی» روشن‌ترند. اگر کاربر در هر مرحله می‌داند کنترل چه می‌کند و مقصد بعدی چه معنایی دارد، قرارداد Navigation قابل توضیح است. از همین قرارداد برای ساخت و نگهداری منو استفاده کنید، به‌جای اینکه تعداد آیتم‌ها را از یک عدد ثابت بگیرید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!