دکمه قبل از لمس چه می‌گوید؟
دکمهٔ مفید نتیجهٔ قدم بعدی را می‌گوید و عمل فرد را تأیید می‌کنه. چیدمان، عنوان و وضعیت با هم کار می‌کنند. کنترل شروع در حالت آماده، غیرفعال یا انتظار نمایش متفاوت می‌خواهد؛ شکل تزئینی به‌تنهایی این تفاوت‌ها را توضیح نمی‌دهدد.
دکمه‌ای با عنوان «بزن بریم» ممکنه صمیمی باشد، اما اگر معلوم نباشد مسابقه شروع می‌شود یا فقط صفحهٔ دیگری باز می‌شود، کاربر حدس می‌زند. برای تمرین، دکمهٔ شروع را کنار نام بازی و توضیح کوتاه عمل قرار بده. شکل و اندازهٔ آن باید میان عناصر تزئینی قابل پیدا کردن باشد. تازه‌کارها گاهی اول سایه و درخشش را تنظیم می‌کنند و بعد به نام فکر می‌کنند؛ ترتیب مفیدتر این هست که مقصد روشن بشه، جای دکمه مناسب باشد و سپس ظاهر با فضای بازی هماهنگ بشه.
پاسخ را در همان صفحه ببین
دکمهٔ شروع را در وضعیت آماده، انتظار و ناممکن نشان دهید. از تازه‌وارد بخواهید پیش از لمس معنای هر حالت را بگوید. اگر پذیرش لمس را نمی‌فهمد، تأیید اضافه کن. اگر دلیل ناممکن بودن روشن نیست، زمینه بدهید. عنوان کوتاه و وضعیت روشن اغلب بیشتر از قاب تزئینی بزرگ جواب می‌دهند.
با اولین لمس باید واکنش قابل دیدن رخ بدهد. اگر آماده‌سازی طول می‌کشد، همان دکمه یا بخش نزدیکش وضعیت انتظار را نشان دهد تا کاربر برای اطمینان چند بار نزند. غیرفعال شدن نیز نیاز به دلیل قابل فهم داره؛ دکمهٔ خاکستری بدون توضیح می‌تواند مثل خرابی دیده بشه. در رابط یونیتی، زیبایی و هزینهٔ تازه شدن صفحه هر دو مهم‌اند. راهنمای رسمی به کار اضافی Canvas و layout توجه می‌دهد، اما برای این تمرین قبل از بهینه‌سازی حدسی، مطمئن شو خودِ عمل، انتظار و پایان برای بازیکن روشن هستند.
سه حالت برای یک کنترل
از دو نفر بخواه دکمه را پیدا کنن و بگویند انتظار دارن چه اتفاقی بیفتد. بعد حالت آماده، در حال انتظار و غیرقابل استفاده را جدا نشان بده و برداشتشان را بشنو. پاسخ‌ها را از پیشنهاد ظاهر جدا ثبت کن: «فکر کردم خرید می‌کنه» دربارهٔ معنی هست، «آبی را دوست ندارم» دربارهٔ سلیقه. فقط رنگ را برای تفکیک حالت کافی ندان؛ متن کوتاه یا نشانهٔ انتظار هم کمک می‌کنه. پایان این تمرین یک دکمهٔ قابل فهم هست که در حالت‌های مختلف وعدهٔ درست می‌دهد، نه فقط تصویری زیبا در صفحهٔ ثابت.
مطالعهٔ بیشتر: Unity: UI performance guidance
برای یک مثال مرتبط، منوی دلو؛ راه کوتاه‌تر تا میز بازی را هم بخون.
مثال عملی طراحی رابط یونیتی
اگر بخواهی طراحی رابط یونیتی را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. بازیکن باید فرق دکمهٔ آماده، غیرفعال و در حال پردازش را بفهمد. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
چیدمان زیبا بدون پاسخ روشن به لمس، حس خرابی یا چند بار کلیک ایجاد می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. رابط باید تصمیم بعدی را روشن کند و صرفاً مجموعهٔ پنل‌های تزئینی نباشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
هدف لمس، متن، وضعیت و بازخورد را با یک کاربر تازه بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن باید فرق دکمهٔ آماده، غیرفعال و در حال پردازش را بفهمد. |
| ریسک اصلی | چیدمان زیبا بدون پاسخ روشن به لمس، حس خرابی یا چند بار کلیک ایجاد می‌کند. |
| روش بررسی | هدف لمس، متن، وضعیت و بازخورد را با یک کاربر تازه بررسی کن. |
| مرز نتیجه‌گیری | رابط باید تصمیم بعدی را روشن کند و صرفاً مجموعهٔ پنل‌های تزئینی نباشد. |
پرسش‌های کاربردی دربارهٔ طراحی رابط یونیتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن باید فرق دکمهٔ آماده، غیرفعال و در حال پردازش را بفهمد. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. هدف لمس، متن، وضعیت و بازخورد را با یک کاربر تازه بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. رابط باید تصمیم بعدی را روشن کند و صرفاً مجموعهٔ پنل‌های تزئینی نباشد.
برای ادامهٔ همین موضوع، نمونهٔ اولیهٔ بازی؛ چه چیزی را باید زود امتحان کنیم؟ را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
مفاهیم چیدمان را در مستندات رسمی چیدمان uGUI بررسی کن. مثال‌های این نوشته مربوط به ساختار چیدمان هستند، نه تنظیم ثابت برای یک مدل گوشی.
