فرض کن برای دکمه‌ها سه مدل ظاهری، سه اندازه، پنج حالت تعامل و سه نوع چیدمان آیکن در نظر گرفته‌ای. اگر برای هر ترکیب یک Variant جدا بسازی، همین چند انتخاب به ۱۳۵ نسخه می‌رسند. حالا هر بار که چیزی را اصلاح می‌کنی، باید حواست به همهٔ این نسخه‌ها باشد.
این عدد از یک مثال فرضی می‌آید و تعداد دکمه‌های رایتل نیست. قبل از ساختن این همه نسخه، باید ببینیم کدام تفاوت‌ها به Variant جدا نیاز دارند و کدام را می‌توان از تنظیمات همان کامپوننت تغییر داد.
می‌خواهم طراح مدل مناسب را انتخاب کند، متن و آیکن را عوض کند و دکمه همچنان درست نمایش داده شود. اگر برای این کار مجبور باشد لایه‌ها را دستی اصلاح کند، هنوز باید روی ساختار کامپوننت کار کنیم.
از دکمه‌های داخل صفحه‌ها شروع کن
در کتابخانهٔ قبلی رایتل، شعاع گوشهٔ دکمهٔ Large برابر با ۴ پیکسل بود، ولی Medium شعاع ۱۶ پیکسلی داشت. بعضی حالت‌های تعامل هم طراحی نشده بودند. برای اصلاح کتابخانه، لازم بود دلیل این تفاوت‌ها را بفهمیم و مشخص کنیم دکمه‌ها در اندازه‌ها و حالت‌های مختلف چه ظاهری باید داشته باشند.
ما به‌خاطر محدودیت زمان و پیاده‌سازی از متریال شروع کرده بودیم. برای ساختن کامپوننت‌های موردنیاز محصول، باید ساختار و قواعد آن را می‌شناختیم. اما اینکه چه مدل‌ها و تنظیماتی لازم داریم، از بررسی صفحه‌های خودمان مشخص می‌شد.
برای شروع، چند دکمه از صفحه‌هایی که هنوز استفاده می‌شوند کنار هم بگذار؛ مثلاً «ثبت تغییرات» و «انصراف» در یک فرم، یا دکمهٔ دانلود که آیکن دارد. بعد ببین تفاوتشان از کجا آمده است.
تغییر نوشتهٔ «ذخیره» به «ادامه» معمولاً به یک کامپوننت جدا نیاز ندارد. ولی «ثبت تغییرات» و «انصراف» ممکن است لازم باشد ظاهر متفاوتی داشته باشند تا کار اصلی صفحه واضح‌تر دیده شود. اگر برای هر دو نوع تغییر، فقط از کامپوننت کپی بگیریم، کتابخانه خیلی زود پر از نسخه‌هایی می‌شود که تفاوتشان معلوم نیست.
هر تغییر را با ابزار مناسبش انجام بده
در فیگما، Properties همان تنظیماتی هستند که برای استفاده‌کنندهٔ کامپوننت در دسترس می‌گذاریم. Variant هم یکی از انواع آن‌هاست. پس لازم نیست برای هر تغییری، یک Variant تازه بسازیم.
برای دکمه، این چند انتخاب نقطهٔ شروع خوبی‌اند:
| چه چیزی قرار است تغییر کند؟ | از چه تنظیمی استفاده کنیم؟ |
|---|---|
| نوشتهٔ روی دکمه | Text Property |
| نمایش یا مخفی‌کردن آیکن | Boolean Property |
| عوض‌کردن آیکن با یک آیکن دیگر | Instance Swap Property |
| انتخاب مدل ظاهری، اندازه یا حالت دکمه | Variant Property |
راهنمای Component Properties فیگما کاربرد این تنظیمات را توضیح می‌دهد. اینجا فقط گزینه‌هایی را آورده‌ام که برای مثال دکمه لازم داریم.
هدفم این است که طراح بتواند از پنل تنظیمات، متن «ذخیرهٔ تغییرات» را بنویسد و آیکن دلخواه را انتخاب کند. برای این کار نباید مجبور باشد لایه‌ها را باز کند یا ارتباط نمونه را با کامپوننت اصلی قطع کند.
با این حال، یک کلید نمایش و مخفی‌کردن آیکن همیشه کافی نیست. ممکن است دکمهٔ بدون آیکن به فاصلهٔ متفاوتی از لبه‌ها نیاز داشته باشد. Boolean فقط لایه را نشان می‌دهد یا مخفی می‌کند؛ فاصلهٔ داخلی جدیدی برای دکمه تعیین نمی‌کند. اگر چیدمان واقعاً فرق دارد، ساختن Variant جدا برای آن منطقی است.
اول مطمئن شو یک دکمه درست کار می‌کند
قبل از ساختن اندازه‌ها و مدل‌های مختلف، یک دکمهٔ ساده را داخل فیگما لایه‌به‌لایه بررسی می‌کنم: کادر اصلی، متن، آیکن و فاصلهٔ بین آن‌ها. برای رنگ و فاصله و استایل متن هم از همان توکن‌ها و استایل‌هایی استفاده می‌کنم که در قسمت قبل مشخص کرده‌ایم.
بعد متن کوتاه «ذخیره» را به «ذخیرهٔ تغییرات و ادامه» تبدیل می‌کنم. آیکن را مخفی می‌کنم و دوباره با آیکن دیگری امتحان می‌کنم. دکمه را در یک صفحهٔ کم‌عرض می‌گذارم تا ببینم وقتی فضا محدود است چه اتفاقی می‌افتد.
اینجا باید دربارهٔ عرض دکمه تصمیم بگیریم. قرار است با طول متن بزرگ‌تر شود یا تمام عرض کادر را بگیرد؟ اگر متن طولانی شد، می‌تواند دوخطی شود؟ این تصمیم‌ها به محل استفادهٔ دکمه بستگی دارند. تا وقتی تکلیفشان روشن نشده، اضافه‌کردن اندازه‌های Small و Large فقط مسئله را در چند نسخه تکرار می‌کند.
برای فارسی و انگلیسی، ترتیب آیکن و متن را هم جدا بررسی کن. آیکنی که قبل از متن می‌آید، در فارسی معمولاً سمت راست است و در انگلیسی سمت چپ. این ترتیب باید هم در فایل طراحی درست باشد و هم در محصول پیاده شود.
وقتی این نمونه در موقعیت‌های مختلف درست کار کرد، سراغ نسخه‌های دیگر می‌روم.
فقط انتخاب‌هایی را اضافه کن که کاربرد دارند
فرض کن برای یک محصول کوچک، دکمه‌های Filled و Outlined در دو اندازهٔ Small و Medium کافی‌اند. بعضی دکمه‌ها آیکن دارند و بعضی ندارند. در نمونه‌هایی که بررسی کرده‌ایم هم آیکن همیشه قبل از متن قرار می‌گیرد.
برای شروع، همین نیازها را پوشش می‌دهم. اگر بعداً صفحه‌ای به آیکن انتهای متن یا دکمهٔ بدون متن نیاز داشت، آن را بررسی می‌کنم و در صورت نیاز به کتابخانه اضافه می‌کنم.
دکمه‌ای که فقط آیکن دارد، صرفاً همان دکمه با متن مخفی‌شده نیست. باید اندازه و فاصله‌هایش را بررسی کنیم و مشخص باشد صفحه‌خوان چه نامی برای آن می‌خواند؛ چون متن قابل‌مشاهده‌ای ندارد که کاربردش را توضیح بدهد.
خودِ تنظیمات هم ممکن است ترکیب ناخواسته بسازند. مثلاً اگر دو کلید مستقل برای آیکن ابتدا و انتهای متن بگذاریم، طراح می‌تواند هر دو را روشن کند. اگر دکمهٔ دوآیکنه در محصول لازم نیست، بهتر است امکان انتخابش را بی‌دلیل ایجاد نکنیم. وقتی به هر دو جای آیکن نیاز داریم، یک انتخاب سه‌حالتهٔ «بدون آیکن، آیکن ابتدا، آیکن انتها» می‌تواند واضح‌تر باشد.
این موارد را با توسعه‌دهنده هم مرور کن. آنچه در فیگما اجازهٔ انتخابش را می‌دهیم باید با گزینه‌های موجود در کد هماهنگ باشد. اگر ترکیبی مجاز نیست، صرف نوشتن یک جمله در راهنما جلوی انتخاب اشتباه را نمی‌گیرد.
ترجیح می‌دهم یک گزینه را برای نیاز مشخصی اضافه کنم تا اینکه از ابتدا برای تمام موقعیت‌های احتمالی نسخه بسازم.
حالت‌های ضروری را فدای کم‌کردن Variantها نکن
دکمه فقط در حالت عادی دیده نمی‌شود. کاربر با صفحه‌کلید به آن می‌رسد، نشانگر ماوس را روی آن می‌برد، آن را فشار می‌دهد یا با دکمه‌ای غیرفعال روبه‌رو می‌شود. طراحی این حالت‌ها بخشی از کار است.
در فیگما معمولاً هر حالت را جدا نشان می‌دهیم، اما در محصول بعضی حالت‌ها هم‌زمان اتفاق می‌افتند. مثلاً دکمه می‌تواند فوکوس داشته باشد و ماوس هم روی آن باشد. باید مشخص کنیم در این موقعیت چه چیزی دیده می‌شود؛ وجود دو تصویر جدا برای Focus و Hover به‌تنهایی جواب نمی‌دهد.
برای حالت در حال پردازش هم فقط گذاشتن یک نشانگر چرخان کافی نیست. بعد از کلیک، نوشتهٔ دکمه باقی می‌ماند یا عوض می‌شود؟ عرض دکمه ثابت می‌ماند؟ کاربر می‌تواند دوباره کلیک کند؟ وقتی کار تمام شد، نتیجه را کجا می‌بیند؟ این‌ها تصمیم‌هایی هستند که باید همراه با ظاهر دکمه مشخص شوند.
در مورد تم روشن و تیره، اگر فقط رنگ‌ها فرق دارند، می‌توان از Variables و Modeها استفاده کرد تا برای هر تم یک مجموعهٔ جدا نسازیم. یک متغیر می‌تواند در تم روشن یک رنگ داشته باشد و در تم تیره رنگ دیگری. راهنمای متغیرهای فیگما این قابلیت را توضیح می‌دهد. بعد از تنظیم آن هم باید دکمه‌ها را در هر دو تم ببینیم و بررسی کنیم.
صفحهٔ پر از دکمه لزوماً مشکل ندارد
در نسخهٔ بازطراحی‌شدهٔ رایتل، مدل‌های مختلف دکمه را کنار حالت‌های تعامل و چیدمان آیکن‌ها قرار داده بودیم تا بتوانیم آن‌ها را با هم مقایسه کنیم.
این تصویر دکمه‌های Filled، Outlined، Text، Elevated و Filled tonal را نشان می‌دهد. نیازهای رایتل از مثال کوچک این نوشته بیشتر بود.
تعداد زیاد نمونه‌ها در چنین صفحه‌ای، به‌خودی‌خود ایراد نیست. باید ببینیم چرا هر مدل وجود دارد، انتخابش چقدر راحت است و اگر چیزی را تغییر بدهیم، چه نسخه‌هایی نیاز به بررسی دارند.
از طرف دیگر، اگر برای کم‌کردن تعداد Variantها طراح را مجبور کنیم هر بار لایه‌ها را دستی تغییر بدهد، فقط کار را از سازندهٔ کتابخانه به استفاده‌کننده منتقل کرده‌ایم.
کامپوننت را به یک طراح دیگر بده
برای بررسی کاربردپذیری کامپوننت، از یک طراح دیگر بخواه دکمهٔ «انصراف» را کنار «ثبت تغییرات» در یک فرم بگذارد، متن را تغییر بدهد و برای یکی از دکمه‌ها آیکن انتخاب کند. اجازه بده بدون راهنمایی قدم‌به‌قدم تو این کار را انجام بدهد.
ببین کجا مکث می‌کند، کدام اسم برایش واضح نیست و برای چه کاری مجبور می‌شود لایه‌ها را باز کند. بعد اندازه و حالت دکمه را تغییر بدهید و ببینید متن و آیکن انتخاب‌شده حفظ می‌شوند یا نه. فاصله‌ها را هم دوباره بررسی کنید.
همین چند کار ساده معمولاً جاهایی را نشان می‌دهد که باید در تنظیمات یا راهنما اصلاح کنیم؛ قبل از اینکه کامپوننت در تعداد زیادی صفحه استفاده شود.
نمونه‌ها را با توسعه‌دهنده هم مرور کن. برای دکمهٔ Disabled، دربارهٔ امکان کلیک و رفتار موردانتظار توافق کنید. برای دکمه‌ای که تمام عرض فرم را می‌گیرد، مشخص کنید در کد چطور اندازه‌گذاری می‌شود. این جزئیات را بهتر است وقتی روشن کنیم که هنوز صفحه‌های زیادی به کامپوننت وابسته نشده‌اند.
در قسمت بعد، «کامپوننت با طراحی حالت اولیه‌اش کامل نمی‌شود»، بیشتر به همین رفتارها می‌پردازیم: فوکوس، خطا، انتظار برای پاسخ و محتوای خالی؛ موقعیت‌هایی که هنگام استفاده پیش می‌آیند، ولی در تصویر اولیهٔ طراحی همیشه دیده نمی‌شوند.