Tabs | تب‌ها

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

زمینهٔ واحد؛ مرز با منو و ناوبری سراسری

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

مثال: در پنل فروشگاهی، تب‌های صفحهٔ کالا برای «عمومی»، «موجودی»، «سئو» منطقی‌اند چون همه ویرایش یک موجودیت‌اند. گذاشتن «لیست سفارش‌ها» به‌عنوان تب همان صفحه اشتباه معماری است—سفارش زمینهٔ دیگری است.

برچسب، تعداد و بار شناختی

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

در نرم‌افزار حسابداری، اگر تب پیش‌فرض «تنظیمات مالیاتی» باشد و کاربر هر روز «اسناد» می‌خواهد، هر ورود یک کلیک اضافه و یک حس محصول ناهماهنگ می‌سازد. دادهٔ استفاده باید ترتیب و پیش‌فرض را تغذیه کند.

افقی، عمودی و سازگاری با عرض

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

داشبورد تحلیل با برچسب‌های «Retention نود روزه» ممکن است افقی جا نشود؛ عمودی یا کوتاه‌سازی با عنوان کامل در tooltip—یا بهتر، بازنویسی برچسب—راهکار است. مراقب باشید tooltip تنها راه فهم برچسب نباشد.

صفحه‌کلید، فوکوس و قرارداد دسترس‌پذیری

تب‌ها باید با صفحه‌کلید کامل کار کنند: حرکت بین برچسب‌ها، فعال‌سازی، و رفتن فوکوس به محتوای پنل. نشانگر فوکوس واضح ضروری است. برای صفحه‌خوان، نقش‌های تب و پنل، ارتباط aria-controls، و حالت انتخاب‌شده باید اعلام شود تا کاربر بفهمد چند تب هست و کدام فعال است. برچسب مبهم برای فناوری کمکی همان‌قدر مضر است که برای چشم. اگر محتوا سنگین است، بارگذاری تنبل پنل‌های نادیده اشکالی ندارد به شرطی که وضعیت بارگذاری اعلام شود و فوکوس گم نشود. تست با صفحه‌کلید alone بسیاری از تب‌های «زیبا اما شکسته» را لو می‌دهد.

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

حفظ حالت، URL و بازگشت

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

در ابزار CRM، فروشنده فیلتر «این هفته» را روی تب فرصت‌ها می‌گذارد، به تب تماس‌ها می‌رود و برمی‌گردد؛ اگر فیلتر پریده باشد، الگوی تب شکست خورده حتی اگر انیمیشن سوییچ لطیف باشد.

تب مرورگر در برابر تب داخل محصول

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

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

سرریز، خطای رایج و سنجش

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

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

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

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