Tab Bar | نوار تب
نوار تب کنترل ناوبری سطح‌اول اپلیکیشن است که چند مقصد اصلی را همیشه روی صفحه نگه می‌دارد تا کاربر بدون باز کردن منو یا برگشت به خانه، با یک ضربه بین بخش‌های هم‌سطح جابه‌جا شود. معمولاً در پایین صفحهٔ موبایل می‌نشیند؛ جایی که شست به‌راحتی می‌رسد. اینستاگرام، اسپاتیفای، توییتر و بیشتر اپ‌های پرتردد همین الگو را برای ساختار بالای محصول به کار می‌برند. راهنمای رابط اپل صریحاً نوار تب را برای اپ‌های چندبخشی پیشنهاد می‌کند و در اندروید همان نقش را نوار ناوبری پایین در Material Design بازی می‌کند. هزینهٔ دائمی فضای صفحه در برابر ناوبری بی‌فکر است؛ معامله‌ای که برای بیشتر محصولات چندخانه به‌صرفه تمام می‌شود. نوار تب با تب‌های درون‌صفحه‌ای یکی نیست: آنجا سوییچ بخش داخل یک زمینه است، اینجا نقشهٔ اصلی اپ است.
چرا منوی همبرگری برای مقصدهای اصلی کم می‌آورد
منوی همبرگری ساختار را پشت یک آیکون سه‌خط پنهان می‌کند. کاربر ابتدا باید منو را باز کند تا ببیند چه گزینه‌هایی هست؛ یعنی دو ضربه به‌جای یکی، و کشف ضعیف‌تر برای کسانی که هنوز همهٔ بخش‌ها را نگشته‌اند. پژوهش‌های کاربردپذیری موبایل بارها نشان داده‌اند ناوبری با نوار پایین پایدار معمولاً سریع‌تر از منوی پنهان است و بخش‌های داخل منو کمتر دیده و کمتر استفاده می‌شوند. وقتی رِدبوث از همبرگر به نوار تب پایین رفت، افزایش چشمگیر کاربران فعال روزانه و زمان نشست گزارش شد—نشانه‌ای که ساختار دیده‌شده رفتار را عوض می‌کند، نه فقط زیبایی را. همبرگر برای تنظیمات، لینک‌های کم‌استفاده و مقصدهای ثانویه هنوز جای دارد؛ مشکل وقتی است که همان الگو را برای خانه، جستجو، پیام و پروفایل به کار ببرید و بعد تعجب کنید چرا ویژگی‌های مهم کم‌مصرف مانده‌اند.
در محصول B2B هم همین منطق کار می‌کند. اگر داشبورد عملیاتی، تیکت‌ها، تقویم و گزارش‌ها چهار ستون کار روزانهٔ مدیر شیفت باشند، پنهان کردنشان در کشو یعنی هر جابه‌جایی یک اصطکاک اضافه. نوار تب نقشهٔ ذهنی اپ را روی صفحه حک می‌کند تا تیم فروش یا پشتیبانی وسط شیفت حدس نزند «کدام بخش کجاست».
سقف تعداد مقصد و فشار اولویت‌بندی
توصیهٔ رایج سه تا پنج مقصد است و پنج معمولاً سقف موبایل است. با دو مقصد، الگوی ساده‌تر اغلب کافی است؛ با بیش از پنج، هدف لمسی کوچک می‌شود، شلوغی بصری بالا می‌رود و تصمیم ناوبری سنگین‌تر می‌شود. اپل برای آیفون سقف پنج را می‌گذارد و Material هم بازهٔ سه تا پنج را برای ناوبری پایین پیشنهاد می‌کند—محدودیت فیزیکی عرض گوشی و ظرفیت حافظهٔ کاری، نه سلیقهٔ طراح. اگر محصول شش یا هفت بخش سطح‌بالا دارد، باید اولویت بدهید: پرتکرارترین و باارزش‌ترین‌ها روی نوار می‌مانند و بقیه به «بیشتر»، سرریز، یا کشوی ثانویه می‌روند. کشف‌پذیری بخش‌های جابه‌جاشده کم می‌شود؛ اگر واقعاً ثانویه باشند قابل تحمل است، اگر کاربر هر روز به آن‌ها نیاز دارد باید دوباره اولویت را بازبینی کنید نه اینکه فقط آیکون‌ها را فشرده‌تر کنید.
مثال ملموس: اپ فروشگاهی ممکن است خانه، دسته‌ها، سبد، سفارش‌ها و پروفایل را نگه دارد و «بلاگ» یا «پشتیبانی» را به منوی بیشتر بفرستد. اگر پشتیبانی تماس‌محور باشد و حجم تیکت بالا، شاید پشتیبانی جای دسته‌ها را در نوار بگیرد—تصمیم محصول است، نه کپی کور از الگوی رقبا.
داخل هر خانهٔ نوار چه می‌نشیند
هر آیتم باید بخش هم‌سطح و غیرسلسله‌مراتبی باشد: خانه، کاوش، صندوق، سبد، پروفایل. محتوای هر تب از بقیه مستقل است و جابه‌جایی نباید حالت اسکرول و پشتهٔ ناوبری داخل تب دیگر را بی‌دلیل پاک کند—مگر قرارداد پلتفرم چیز دیگری بگوید. آیکون عنصر غالب است؛ خانه، ذره‌بین، سبد و آدمک وقتی جاافتاده‌اند بدون برچسب هم کار می‌کنند، اما آیکون ناآشنا بدون متن گیج می‌کند. برچسب کوتاه تک‌کلمه‌ای خواناتر است: کاوش، صندوق، سبد. برچسب چندکلمه‌ای در عرض کم شلوغ و ناخوانا می‌شود. حالت فعال با رنگ، پُر شدن آیکون، یا خط زیر/بالا باید در یک نگاه معلوم کند کجایید. بج اعلان برای خوانده‌نشده یا اقدام معوق مفید است اگر گزینشی باشد؛ بج روی همهٔ تب‌ها هم‌زمان نویز است و هیچ‌کدام را برجسته نمی‌کند.
در اپ بانکی، تب «کارت‌ها» ممکن است بج برای قسط سررسید داشته باشد و تب «پیام» برای اعلان امنیتی. اگر هر دو همیشه قرمز باشند، کاربر بی‌تفاوت می‌شود. سیاست بج باید به شدت و تازگی رویداد گره بخورد، نه به هر رویداد تحلیلی پشت‌صحنه.
رفتار iOS و Android و صفحهٔ عریض‌تر
مفهوم یکی است، جزئیات فرق دارد. در iOS نوار بالای ناحیهٔ امن و نشانگر خانه می‌نشیند، از SF Symbols بهره می‌برد و معمولاً با جابه‌جایی تب، موقعیت اسکرول و پشتهٔ همان تب حفظ می‌شود تا برگشت حس ادامه بدهد. در اندروید نوار ناوبری پایین با ارتفاع مشخص در Material کار می‌کند و رفتار پیش‌فرض بعضی پیاده‌سازی‌ها ریست حالت تب هنگام سوییچ است—تفاوتی که انتظار کاربر را عوض می‌کند و باید در طراحی و تست آگاهانه مدیریت شود. روی تبلت و صفحه‌های عریض، هر دو اکوسیستم اغلب پیشنهاد می‌کنند از نوار افقی پایین به ریل ناوبری عمودی سمت چپ بروید تا عرض بهتر مصرف شود و با ماوس و صفحه‌کلید هم‌خوان‌تر باشد. طراحی پاسخگو یعنی همان مقصدهای اصلی را در ظرف مناسب دستگاه نگه دارید، نه اینکه نوار پایین را روی تبلت بکشید و فضای مرده بسازید.
اگر اپ شما هم گوشی و هم تبلت را پوشش می‌دهد، قرارداد یکسانی برای حفظ یا ریست حالت بنویسید و در مستند طراحی سیستم ثبت کنید تا اندروید و iOS و وب حس متفاوتی به کاربر ندهند.
دسترس‌پذیری، هدف لمسی و نام دسترس‌پذیر
هر تب باید نامی داشته باشد که صفحه‌خوان اعلام کند؛ از برچسب دیده‌شده یا aria-label اگر متن پنهان است. تب فعال باید هم بصری و هم برنامه‌ای مشخص باشد تا فناوری کمکی بگوید کدام بخش جاری است. حداقل هدف لمسی در iOS حدود چهل‌وچهار نقطه و در اندروید حدود چهل‌وهشت dp است؛ فشردن پنج آیکون در عرض کم بدون رعایت این حداقل، خطای لمسی می‌سازد. کنتراست حالت فعال و غیرفعال و کنتراست نوار با پس‌زمینه باید به آستانهٔ WCAG برسد. تکیه فقط روی رنگ برای حالت فعال، برای کوررنگی ضعیف است؛ شکل آیکون پُر در برابر خطی یا نشانگر جدا کمک می‌کند.
در تست با VoiceOver یا TalkBack بشنوید آیا ترتیب اعلام با ترتیب بصری یکی است و آیا بج فقط با رنگ فهمیده می‌شود یا متن جایگزین دارد. نوار تب بخشی از اسکلت اپ است؛ اگر اینجا دسترس‌پذیر نباشد، بقیهٔ جریان‌ها هم آسیب می‌بینند.
نقش، پلن و تغییر پویای ساختار
می‌توان برای نقش ادمین تب اضافه کرد یا برای پلن رایگان یک خانه را با ارتقا عوض کرد. اما حافظهٔ فضایی کاربر شکننده است: جابه‌جایی مداوم جای آیکون‌ها یا حذف ناگهانی مقصدی که هر روز می‌زد، سردرگمی می‌آورد. تغییر باید عمدی، کم‌تکرار و ترجیحاً افزودنی باشد نه بازآرایی هر هفته. اگر نقش‌ها خیلی متفاوت‌اند، گاهی دو پوستهٔ ناوبری پایدار بهتر از یک نوار متغیر روزانه است—به شرطی که ورود و سوئیچ نقش واضح باشد.
محصول‌منجر اینجا باید بپرسد: این تب جدید ارزش سطح‌اول دارد یا فقط صدای ذی‌نفع داخلی است؟ هر خانهٔ نوار سهمی از توجه و فضای برند است؛ پر کردنش با بخش کم‌ارزش، خانهٔ پرترافیک را تنگ می‌کند.
کی نوار تب را کنار بگذارید
نوار تب برای چند بخش هم‌سطح و پرتکرار در یک نشست ساخته شده است. برای محتوای عمیقاً سلسله‌مراتبی که نان‌خرده یا بازگشت طبیعی‌تر است، برای جریان خطی ثبت‌نام یا تسویه‌حساب که پیشرفت رو به جلو مهم‌تر از سوییچ بخش است، و برای محصول تک‌صفحه‌ای ساده، نوار تب اضافه و گیج‌کننده است. همچنین اگر مقصدها واقعاً زیرمجموعهٔ یکدیگرند، گذاشتنشان در نوار هم‌سطح، مدل ذهنی اشتباه می‌سازد. در آن حالت اطلاعات معماری را درست کنید، نه اینکه پنج آیکون تزئینی بچینید.
جمع‌بندی: نوار تب ناوبری پایدار سطح اپ است—معمولاً پایین موبایل، سه تا پنج مقصد، با آیکون و برچسب و حالت فعال روشن. با تب‌های درون‌محتوا فرق دارد، با همبرگر برای مقصد اصلی رقابت می‌کند و روی صفحهٔ بزرگ‌تر اغلب به ریل تبدیل می‌شود. وقتی ساختار محصول را خوانا می‌کند و جابه‌جایی را ارزان نگه می‌دارد، ارزش فضای دائمی‌اش را پس می‌دهد؛ وقتی نقش نقشهٔ اصلی را ندارد، فقط صفحه را کوتاه‌تر می‌کند.
در نقد طراحی بپرسید: آیا این پنج خانه داستان واقعی استفادهٔ روزانه را می‌گویند؟ آیا کاربر تازه‌وارد بدون آموزش می‌فهمد هر آیکون چیست؟ آیا برگشت به تب قبلی کار ناتمامش را حفظ می‌کند؟ پاسخ این سه سوال بیش از بحث سلیقه روی رنگ نوار، کیفیت الگو را مشخص می‌کند. تیم‌هایی که نوار را مثل منوی بازاریابی پر می‌کنند، بعداً مجبور می‌شوند با آموزش و تور ویژگی، گیجی خودساخته را جبران کنند—هزینه‌ای که با اولویت‌بندی صادقانهٔ مقصدها قابل پیشگیری است.
برای هم‌ترازی طراحی و مهندسی، مشخص کنید هر تب ریشهٔ جدا در گراف ناوبری دارد، دیپ‌لینک به تب درست فرود می‌آید، و حالت فعال با مسیر URL یا route همگام است. در وب‌اپ‌های شبیه موبایل، نوار پایین ثابت نباید روی صفحه‌کلید نرم یا ناحیهٔ gest سیستم بپرد. این جزئیات خسته‌کننده همان چیزهایی‌اند که در فروشگاه امتیاز می‌گیرند یا در اولین هفتهٔ استفاده باعث حذف اپ می‌شوند.
سوالات متداول
کنترل ناوبری پایدار که چند مقصد اصلی اپ را—معمولاً پایین صفحهٔ موبایل—همیشه در دسترس نگه می‌دارد تا با یک ضربه بین بخش‌های هم‌سطح جابه‌جا شوید.
نوار تب نقشهٔ سطح‌اول کل اپ است؛ تب‌های درون صفحه فقط بخش‌های مرتبط یک زمینه یا یک صفحه را بدون ترک آن زمینه سوییچ می‌کنند.
معمولاً سه تا پنج؛ بیش از پنج شلوغی و هدف لمسی ضعیف می‌سازد و مقصدهای کم‌اولویت باید به سرریز یا منوی ثانویه بروند.
چون ساختار را پنهان نمی‌کند، یک ضربه به‌جای دو ضربه می‌خواهد و پژوهش‌ها معمولاً سرعت و کشف بهتر را برای نوار پایدار نشان می‌دهند.
اغلب بهتر است به ریل ناوبری عمودی سمت چپ مهاجرت کنید تا از عرض بیشتر درست استفاده شود و با ورودی اشاره‌گر هم‌خوان باشد.