Selection Controls | کنترل‌های انتخاب

کنترل‌های انتخاب (Selection Controls) خانوادهٔ اجزای رابط‌اند که به کاربر اجازه می‌دهند گزینه انتخاب کند یا یک وضعیت را روشن/خاموش کند. هستهٔ این خانواده معمولاً دکمهٔ رادیویی، چک‌باکس و سوییچ (toggle) است. آن‌ها در فرم‌ها، فیلترها، تنظیمات و هر جای تصمیم‌گیری ظاهر می‌شوند و اگر درست انتخاب نشوند، خطا، تردید و رها کردن جریان را بالا می‌برند. این مدخل دربارهٔ اسلایدر بازه‌ای، نوار اسکرول، اسنک‌بار یا صفحهٔ تنظیمات به‌عنوان الگو نیست؛ تمرکز دقیقاً روی خانوادهٔ انتخاب گزینه‌ای و وضعیت دودویی استاندارد است.

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

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

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

انحصار انتخاب را صریح کنید

رادیوها باید در یک گروه با نام مشترک عمل کنند؛ انتخاب یکی بقیه را بردارد. برچسب گروه («سرعت تحویل») به اندازهٔ برچسب گزینه‌ها مهم است. اگر گزینه‌ها زیاد شدند، گاهی الگوی دیگر مثل select لازم است—اما آن دیگر خارج از این خانوادهٔ پایه است و نباید رادیو را تا بیست ردیف کش داد بدون بازنگری چیدمان. برای چک‌باکس، حالت نامعین (indeterminate) در درخت دسترسی یا «انتخاب همه» معنی دارد و باید با دقت پیاده و اعلام شود.

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

بازخورد فوری، حالت‌ها و خطای ورودی

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

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

دسترس‌پذیری: صفحه‌خوان، کیبورد و نام دسترس‌پذیر

کنترل انتخاب بدون نام و نقش درست، برای فناوری کمکی ناقص است. صفحه‌خوان باید برچسب، نقش (checkbox/radio/switch) و حالت (انتخاب‌شده/نشده) را بگوید. پیمایش کیبورد بین رادیوهای یک گروه و تغییر حالت با کلید استاندارد باید کار کند. کنتراست حالت انتخاب‌شده فقط با رنگ کافی نیست؛ شکل هم باید فرق را نشان دهد. برای سوییچ، همارزی معنایی با چک‌باکس در بعضی پلتفرم‌ها بحث دارد—مستند سیستم طراحی و الگوی بومی OS را دنبال کنید و در وب از نقش و state درست ARIA در صورت نیاز استفاده کنید، بدون افراط و تداخل با HTML بومی.

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

کجا از کنترل‌های نزدیک استفاده نکنید

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

دکمه هم انتخاب نیست؛ دکمه عمل را اجرا می‌کند. اگر دو دکمه مثل «ماهانه / سالانه» دارید که یکی همیشه «فشرده» می‌ماند، در واقع الگوی segmented control یا رادیوی بصری دارید—رفتار باید با انحصار تک‌انتخابی سازگار باشد و در دسترس‌پذیری درست مدل شود.

ثبات در سیستم طراحی و بومی پلتفرم

کاربر از iOS و Android و وب قراردادهایی بلداست. سوییچ در تنظیمات سیستم معمولاً اثر فوری دارد؛ شکستن این انتظار در اپ شما بدون توضیح، خطا می‌زاید. اندازه، رنگ حالت on، انیمیشن، و مکان برچسب (چپ/راست در RTL) را یک‌بار تصمیم بگیرید و تکرار کنید. در فارسی و RTL، هم‌ترازی گروه رادیو و چک‌باکس را با جهت متن تست کنید؛ برچسب نباید از کنترل جدا بیفتد.

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

کاربرد در فرم، فیلتر و تنظیمات روزمره

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

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

خطاهای پرتکرار در نقد طراحی و توسعه

یک خطای کلاسیک این است که برای سؤال بله/خیر از دو چک‌باکس جدا استفاده شود؛ کاربر ممکن است هر دو یا هیچ‌کدام را بزند و منطق بک‌اند گیج شود. خطای دیگر رادیو بدون گزینهٔ پیش‌فرض در فیلد اجباری است، بدون اینکه UI بگوید انتخاب لازم است. سوییچ‌هایی که فقط رنگ عوض می‌کنند و موقعیت اهرم ثابت می‌ماند در حالت کوررنگی یا کنتراست پایین شکست می‌خورند. در فرم‌های چندستونه، تراز عمودی کنترل‌ها و برچسب‌های بلند فارسی گاه برچسب را از کنترل جدا می‌کند—قبل از انتشار روی عرض‌های میانی هم نگاه کنید.

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

جمع‌بندی برای ساخت UI روزانه

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