Toggle Switch | سوئیچ تغییر وضعیت

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

قرارداد فوری بودن؛ قلب معنایی Toggle

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

اگر عمل پرریسک است—حذف همگانی، قطع دسترسی تیم، انتشار عمومی—یا باید قبل از رسیدن به toggle پیامدها روشن شده باشد، یا اصلاً از الگوی دیگری با تأیید صریح استفاده کنید. دیالوگ تأیید روی هر toggle معمولاً قرارداد فوری بودن را باطل می‌کند و بهتر است استثنا بماند نه قاعده.

مرز با چک‌باکس، رادیو و آیکون انتهایی

چک‌باکس برای انتخاب‌هایی است که اغلب با هم در فرم جمع می‌شوند و بعداً submit می‌شوند. رادیو یا سگمنت برای دو یا چند گزینهٔ متقابل وقتی برچسب‌ها هم‌عرض‌اند و مقایسه مهم است—مثل روشن، تاریک، سیستم. toggle برای یک ویژگی منفرد با معنای روشن/خاموش است. آیکون انتهایی یا trailing icon فقط محل قرارگیری افوردنس کنار فیلد است—جستجو، پاک کردن، نمایش رمز—و خودش مدل دوحالتهٔ تنظیمات نیست. قاطی کردن این‌ها در نقد UI باعث می‌شود تیم دربارهٔ شکل حرف بزند و دربارهٔ زمان اعمال اثر سکوت کند.

دو رادیو با برچسب‌های «فعال» و «غیرفعال» گاهی با یک toggle جایگزین می‌شوند؛ فقط وقتی زبان واقعاً باینری و فوری است. اگر گزینه‌ها «هفتگی / ماهانه / خاموش» باشند، toggle جای اشتباهی است.

چطور وضعیت را بدون ابهام نشان دهیم

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

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

وقتی درخواست شبکه شکست می‌خورد

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

تأخیر محسوس را هم طراحی کنید. اگر تغییر چند ثانیه طول می‌کشد، کاربر نباید فکر کند کلیک کار نکرده و چندبار بزند. وضعیت pending مشخص، از دوبار اعمال و race condition کم می‌کند.

دسترس‌پذیری؛ نقش Switch نه دکمهٔ گنگ

بسیاری از toggleها کامپوننت سفارشی‌اند و دسترسی بومی چک‌باکس را به ارث نمی‌برند. نام دسترس‌پذیر، نقش switch، و اعلام وضعیت چک‌شده یا نشده برای صفحه‌خوان ضروری است. فوکوس صفحه‌کلید باید دیده شود؛ Space و Enter هر دو باید عمل کنند. هدف لمسی را با پدینگ به حداقل توصیه‌شده برسانید حتی اگر شستی کوچک رسم شده باشد.

گروه‌های تنظیمات را با عنوان بخش و فهرست معنادار بسازید تا کاربر صفحه‌خوان در جنگلی از «سوئیچ» بدون زمینه گیر نکند. فاصلهٔ برچسب و کنترل نباید آن‌قدر زیاد باشد که ارتباط معنایی از بین برود.

چیدمان در صفحهٔ تنظیمات

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

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

چند حالت، تأیید و موارد ممنوع

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

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

آزمون و معیار سلامت الگو

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

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

جمع‌بندی برای طراح و محصول‌منجر

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

یک ممیزی سریع تنظیمات محصول: هر toggle را که کنار دکمهٔ ذخیره نشسته جدا کنید و یا رفتارش را فوری کنید یا به چک‌باکس تبدیل کنید. همین تمیزکاری کوچک، فهم وضعیت سیستم را برای کاربر و پشتیبانی یک پله بالا می‌برد.