Floating Action Button (FAB) | دکمه اقدام شناور
دکمهٔ اقدام شناور کنترل دایره‌ای برجسته‌ای است که معمولاً روی گوشهٔ پایین صفحه می‌نشیند و یک اقدام اولیهٔ صفحه را نمایندگی می‌کند: ساختن آیتم تازه، شروع گفتگو، اسکن، یا افزودن به مجموعه. برخلاف دکمهٔ درون محتوا که با اسکرول می‌رود، FAB روی لایهٔ بالاتر از محتوا شناور می‌ماند تا اقدام اصلی همیشه در دسترس انگشت باشد. این الگو در زبان متریال گوگل شناخته و استاندارد شد و از آنجا به اپ‌های موبایل و گاهی وب‌های اپ‌مانند سرایت کرد. قدرت FAB در وضوح «کار بعدی مهم» است؛ خطرش تبدیل شدن به منوی شناور شلوغ یا مانع دید محتواست.
قرارداد یک اقدام؛ نه سینی میانبرهای بی‌پایان
منطق اصلی FAB این است که در هر صفحه—یا دست‌کم در هر زمینهٔ مشخص—یک اقدام مثبت و سازنده برجسته باشد. وقتی FAB به منوی چندآیکونی بدون اولویت تبدیل می‌شود، کاربر دوباره باید بخواند و انتخاب کند و مزیت «یک هدف واضح» از بین می‌رود. اگر واقعاً چند اقدام هم‌سطح دارید، شاید نوار پایین، نوار ابزار، یا اقدام درون‌لیست مناسب‌تر باشد. FAB باید پاسخ سؤال «اگر فقط یک کار از این صفحه بخواهم چیست؟» باشد.
اقدامهای مخرب—حذف دسته‌ای، خروج، قطع ارتباط—معمولاً شایستهٔ FAB نیستند چون برجستگی شناور آن‌ها را بیش از حد آسان و خطرناک می‌کند. FAB جای دعوت به ساختن و پیش رفتن است، نه جای هشدار و تخریب.
جایگاه فضایی: شست، محتوا و تداخل لایه‌ها
گوشهٔ پایین راست در رابط‌های چپ‌به‌راست اغلب با ناحیهٔ راحت شست هم‌خوان است؛ در رابط پارسی راست‌به‌چپ باید جای‌گیری با جهت خواندن و عادت لمسی بازنگری شود تا با کنترل‌های حیاتی دیگر تداخل نکند. FAB نباید روی متن مهم، اقدامهای ردیف آخر لیست، یا نوار ناوبری بنشیند. فاصله از لبه و از سایر کنترل‌های شناور—مثل چت پشتیبانی—باید آگاهانه باشد وگرنه جنگ لایه‌ها شکل می‌گیرد.
با اسکرول لیست بلند، FAB ثابت می‌ماند و می‌تواند آخرین آیتم‌ها را بپوشاند. راه‌حل‌های رایج شامل جمع شدن موقت هنگام اسکرول پایین، پدینگ اضافه در انتهای لیست، یا جابه‌جایی هوشمند هنگام باز بودن صفحهٔ کلید است. نادیده گرفتن این تداخل یکی از شکایت‌های پرتکرار موبایل است: «دکمه روی محتواست».
شکل، برچسب و شناخت اقدام
شکل دایره و آیکون به‌علاوه یا اقدام آشنا بخشی از قراردادند. آیکون مبهم بدون برچسب، به‌ویژه برای کاربران تازه‌وارد، حدس می‌سازد. در متریال، FAB می‌تواند گسترده شود و برچسب متنی بگیرد تا معنا روشن شود—مفید وقتی آیکون به‌تنهایی کافی نیست. رنگ باید با اقدام اصلی سیستم هم‌خوان باشد و از دکمه‌های ثانویه متمایز بماند، اما تکیهٔ صرف بر رنگ برای معنا، دسترس‌پذیری را ضعیف می‌کند.
حالت‌ها مهم‌اند: فشردن، غیرفعال، و گاهی نمایش پیشرفت. اگر اقدام نیازمند مجوز یا تکمیل پیش‌نیاز است، بهتر است FAB مسیر را شروع و کمبود را توضیح دهد تا اینکه بی‌صدا کاری نکند. سکوت کنترل شناور بیشتر از دکمهٔ معمولی گیج می‌کند چون وعدهٔ اقدام برجسته داده است.
از یک دکمه تا صفحهٔ سرعت؛ گسترش با احتیاط
الگوی speed dial چند اقدام مرتبط را از FAB اصلی باز می‌کند—مثلاً افزودن عکس، فایل، یا موقعیت. این گسترش وقتی مجاز است که اقدام‌ها خانوادهٔ یک عمل «ایجاد» باشند و تعدادشان کم بماند. اگر فهرست به ده میانبر برسد، دیگر FAB نیست؛ منوی شناور نامرتب است. همچنین باز شدن باید دسترس‌پذیر و قابل بستن باشد و زمینهٔ پشت آن را قفل یا کم‌رنگ کند تا لمس اشتباه کم شود.
در وب، تقلید FAB موبایل بدون نیاز روشن اغلب اشتباه است. روی دسکتاپ با اشاره‌گر دقیق و فضای بیشتر، دکمهٔ اصلی در هدر یا نزدیک محتوا معمولاً طبیعی‌تر است. FAB را وقتی بیاورید که الگو واقعاً به دسترس دائمی انگشت و اقدام واحد کمک می‌کند، نه چون در اپ مرجع دیده شده است.
دسترس‌پذیری، فوکوس و فناوری کمکی
نام دسترس‌پذیر باید اقدام را بگوید—«ایجاد پروژه تازه»—نه فقط «دکمه». ترتیب فوکوس صفحه‌کلید باید منطقی باشد و پس از فعال‌سازی، فوکوس به جای مفیدی برود. در صفحه‌خوان، کنترل شناور نباید بدون اعلان ظاهر یا ناپدید شود. کنتراست آیکون روی رنگ پس‌زمینه و اندازهٔ هدف لمسی حداقل‌های غیرقابل مذاکره‌اند. اگر FAB هنگام اسکرول جمع می‌شود، وضعیت برای فناوری کمکی باید هم‌خوان بماند.
کاربرانی که لرزش دست یا میدان دید محدود دارند ممکن است از کنترل شناور روی محتوای در حال حرکت بیشتر آسیب ببینند. گزینهٔ کاهش حرکت و عدم پوشاندن اطلاعات حیاتی بخشی از طراحی مسئولانه است.
جایگزین‌ها وقتی FAB اشتباه الگو است
اگر صفحه چند اقدام هم‌اهمیت دارد، نوار اقدام پایین یا تب‌ها شفاف‌ترند. اگر اقدام به ردیف خاصی وابسته است، دکمهٔ درون‌خطی یا سوایپ اقدام بهتر از یک FAB عمومی است که بعد باید زمینه را دوباره انتخاب کند. اگر کاربر بیشتر مصرف‌کننده است تا سازنده، برجسته کردن دائمی «ساخت» ممکن است فشار ناخواسته یا دارک‌پترن خفیف باشد. الگوی درست تابع نقش صفحه است نه تابع عادت طراحی.
در محصولات سازمانی متراکم، FAB گاهی با میانبر صفحه‌کلید و دکمهٔ هدر جایگزین می‌شود چون کاربر قدرت به شناور دائماً روی داده حساس است. زمینه را بشنوید: موبایل مصرفی با عمل ایجاد مکرر، زیستگاه طبیعی FAB است؛ داشبورد تحلیلی شلوغ اغلب نیست.
معیار موفقیت و نشانه‌های سوءاستفاده
FAB موفق را می‌توان از نرخ استفادهٔ سالم، کاهش زمان تا ایجاد، و نبود شکایت «محتوا را پوشاند» شناخت. سوءاستفاده وقتی است که هر صفحه FAB متفاوت با اقدام مبهم دارد، یا FAB برای جبران ناوبری ضعیف اضافه شده است. اگر بدون FAB کاربر اقدام اصلی را پیدا نمی‌کند، اول معماری اطلاعات را درست کنید؛ دکمهٔ شناور نباید عصای ناوبری شکسته باشد.
در طراحی سیستم، FAB را با قواعد مصرف مستند کنید: فقط یک نمونهٔ برجسته در هر نمای اصلی، اولویت اقدام سازنده، حداقل فاصله از ناوبری، رفتار اسکرول، و نسخهٔ گستره‌دار با برچسب. بدون این قواعد، هر تیم محصول یک دایرهٔ رنگی در گوشه می‌گذارد و معنای الگو فرسوده می‌شود.
جمع‌بندی برای طراح و مدیر محصول
دکمهٔ اقدام شناور قرارداد موبایل برای برجسته کردن یک اقدام اولیهٔ مثبت است که در دسترس لمس می‌ماند. ارزشش از محدودیت می‌آید: یک پیام، یک جای مشخص، تداخل کنترل‌شده با محتوا. وقتی این محدودیت رعایت شود، FAB کوتاه‌ترین مسیر به کار اصلی صفحه است؛ وقتی شکسته شود، به مانع شناور تبدیل می‌گردد. انتخابش باید نتیجهٔ نقش صفحه باشد، نه تزئین مد روز.
اگر در تردیدید، ابتدا اقدام اصلی را در جریان محتوا روشن کنید و با آزمون پنج‌ثانیه‌ای بپرسید آیا بدون FAB هم شناخته می‌شود. سپس FAB را به‌عنوان شتاب‌دهنده اضافه کنید نه به‌عنوان تنها راه نجات کشف. الگوی شناور باید خدمت به وظیفه باشد، نه امضای بصری اجباری هر صفحهٔ اپ.
سوالات متداول
کنترل شناور معمولاً دایره‌ای در گوشهٔ صفحه که یک اقدام اولیهٔ مثبت—مثل ایجاد—را دائماً در دسترس لمس نگه می‌دارد.
وقتی صفحه یک اقدام سازندهٔ واضح دارد و دسترس دائمی موبایل به آن ارزش دارد؛ نه وقتی چند اقدام هم‌سطح یا اقدام مخرب برجسته می‌شود.
با الگوی speed dial فقط برای چند اقدام هم‌خانواده و کم‌تعداد؛ فهرست بلند میانبرها مزیت وضوح FAB را از بین می‌برد.
پوشاندن محتوا، تداخل با ناوبری، و مبهم بودن آیکون بدون برچسب؛ همچنین استفاده به‌عنوان جبران ناوبری ضعیف.
اغلب نه؛ روی دسکتاپ دکمهٔ اصلی در هدر یا نزدیک محتوا طبیعی‌تر است مگر تجربه عمداً اپ‌مانند و لمسی باشد.