کاربر در یک برنامه موبایل صفحه جزئیات را باز می‌کند و نمی‌داند حرکت بازگشت باید به فهرست قبلی برود یا صفحه را ببندد. آیکون‌ها زیبا هستند، اما قرارداد ناوبری با انتظار او هماهنگ نیست. طراحی UI برای iOS و Android از رفتار، ساختار و شرایط ورودی شروع می‌شود. تفاوت دو پلتفرم را نباید به چند صفت ظاهری مانند flat یا وجود یک FAB محدود کرد.
Human Interface Guidelines و راهنماهای Android منابع مهمی‌اند، ولی استفاده درست از آن‌ها به نوع محصول مربوط است. هر برنامه iOS نیاز به Tab Bar ندارد و هر برنامه Android با Drawer بهتر نمی‌شود. تعداد مقصدها، سلسله‌مراتب و مسیر کار باید مشخص باشند. هویت برند می‌تواند حفظ شود و در عین حال تعامل‌های پلتفرم قابل پیش‌بینی بمانند. کپی کامل ظاهر یکی برای دیگری همیشه نتیجه مناسب نمی‌دهد.
واحد لمس را با pixel مخلوط نکنید
راهنمای Buttons در Apple اندازه hit region را برای محیط مربوط با واحد point بیان می‌کند. راهنمای دسترس‌پذیری Android درباره هدف لمس با واحد dp توضیح دارد. عدد ۴۴ را نباید به قانون مشترک ۴۴ pixel برای همه پلتفرم‌ها تبدیل کرد. point، dp و pixel فیزیکی یک مفهوم یکسان نیستند و دامنه منبع باید حفظ شود.
ناحیه انتخاب با اندازه خود آیکون متفاوت است. یک علامت می‌تواند کوچک‌تر باشد ولی کنترل فضای لمس کافی داشته باشد. فاصله میان دکمه‌ها نیز در انتخاب درست اثر دارد. اگر دو عمل حساس بسیار نزدیک‌اند، بزرگ شدن تصویر آن‌ها لزوماً مشکل را حل نمی‌کند. درباره نقش نشانه و هدف انتخاب، راهنمای آیکون‌ها توضیح بیشتری دارد. کنترل باید هم دیداری و هم عملی قابل تشخیص باشد.
ساختار مقصدها را تعیین کنید
ناوبری اصلی برای مقصدهای پایدار محصول است و با action موقت فرق دارد. قرار دادن «ذخیره» در کنار مقصدهای اصلی می‌تواند نقش آن را مبهم کند. برای هر سطح، معلوم کنید کاربر کجاست و چگونه برمی‌گردد. اگر یک مقصد در دو جای مختلف با رفتار متفاوت وجود دارد، دلیل آن باید روشن باشد. نام‌ها و ترتیب را در صفحه‌های مرتبط ثابت نگه دارید تا یادگیری دوباره لازم نشود.
Tab، navigation rail، Drawer یا ساختار دیگر را از تعداد و اهمیت مقصد انتخاب کنید. اندازه دستگاه و حالت پنجره می‌تواند تغییر کند. یک برنامه فقط در تلفن عمودی استفاده نمی‌شود؛ tablet، split view یا پنجره بزرگ‌تر هم ممکن است مطرح باشند. راهنمای ناوبری درباره برچسب و مقصد مکمل است. الگوی انتخابی باید مسیر کار را توضیح دهد، نه صرفاً نشانه پلتفرم باشد.
بازگشت و خروج نتیجه روشن داشته باشند
بازگشت در stack با بستن یک سطح modal متفاوت است. اگر کاربر داده‌ای وارد کرده، خروج باید سیاست حفظ یا کنار گذاشتن آن را روشن کند. مسیر سیستم و دکمه داخل UI نباید نتیجه‌های متناقض داشته باشند. برای عملیات برگشت‌پذیر، امکان ادامه یا بازیابی می‌تواند مناسب باشد؛ برای اثر حساس، نتیجه هر انتخاب باید قبل از تعهد معلوم باشد.
Gestureهای پلتفرم بخشی از انتظار کاربرند، اما عمل ضروری را فقط به gesture ناشناخته وابسته نکنید. برای swipe روی یک ردیف، راه قابل کشف و نام کنترل لازم است. فردی که از صفحه‌خوان یا ورودی دیگر استفاده می‌کند باید به همان کار برسد. طراحی gesture باید از قابلیت و شرایط مخاطب بیاید، نه از تمایل به حذف تمام دکمه‌های قابل مشاهده.
Safe Area و Window Insets
راهنمای Layout در Apple مرجع رفتار چیدمان پلتفرم است. در Android، راهنمای Window Insets درباره ناحیه‌های سیستم و هماهنگی محتوا توضیح می‌دهد. بالای صفحه، indicator پایین و keyboard می‌توانند بر فضای قابل استفاده اثر بگذارند. عرض و ارتفاع اسکرین‌شات ثابت قرارداد همه دستگاه‌ها نیست.
محتوا می‌تواند تا لبه گسترش یابد، ولی کنترل و نوشته ضروری نباید پشت ناحیه سیستم پنهان شوند. insetها را با padding تزئینی یکی ندانید. هنگام باز شدن keyboard، فیلد فعال و اقدام لازم باید قابل مشاهده یا دسترسی باشند. ثابت نگه داشتن یک footer بدون توجه به فضای واقعی می‌تواند دکمه ادامه را خارج از دسترس قرار دهد. این وضعیت باید در طراحی جریان فرم دیده شود.
تایپوگرافی و متن فارسی
متن باید با تغییر اندازه قابل استفاده بماند و truncation بی‌دلیل معنی را حذف نکند. عنوان فارسی ممکن است نسبت به متن نمونه انگلیسی چندخطی شود. نام محصول، عدد و URL هم به جهت مناسب نیاز دارند. اگر فقط با چند کلمه کوتاه طراحی می‌کنید، مشکلات واقعی طول و ترکیب زبان پنهان می‌مانند. متن و فاصله خطوط را در همان نقش کاربردی انتخاب کنید.
فونت تزئینی می‌تواند در عنوان محدود باشد ولی برای فرم یا متن طولانی نیاز دیگری وجود دارد. اطلاعات مهم را فقط داخل تصویر قرار ندهید. راهنمای خوانایی برای نیازهای متفاوت به بزرگ‌نمایی و وضوح پیام می‌پردازد. سن یا نوع دستگاه به‌تنهایی توانایی خواندن را تعیین نمی‌کند. کاربر باید اختیار داشته باشد و UI با آن اختیار از هم نپاشد.
وضعیت‌های کنترل
دکمه عادی، در انتظار و غیرفعال باید معنی مشخص داشته باشند. اگر عمل در حال انجام است، جلوگیری از ارسال تکراری می‌تواند لازم باشد؛ اما علت و نتیجه باید معلوم بماند. Loading را به موفقیت تبدیل نکنید تا ظاهر سریع‌تر به نظر برسد. اگر داده قبلی هنگام دریافت تازه باقی می‌ماند، مخاطب باید بداند هنوز به‌روزرسانی کامل نشده است.
پیام خطا نزدیک محل اصلاح قرار گیرد و داده درست واردشده حفظ شود. Toast کوتاه تنها نسخه نتیجه مهم نباشد. راهنمای اعلان‌ها درباره شدت و عمر پیام توضیح دارد. Native بودن ظاهر یا استفاده از مؤلفه آماده به‌تنهایی خبر دقیق نمی‌سازد. state و منطق عمل باید با متن و وضعیت قابل مشاهده هماهنگ باشند.
Modal و Sheet
یک sheet می‌تواند اطلاعات یا انتخاب متمرکز ارائه کند، اما شکل پایین صفحه به معنی رفتار غیرmodal نیست. ارتباط با زمینه، مسیر بستن و focus باید مشخص باشند. فرم طولانی در فضای محدود ممکن است صفحه مستقل مناسب‌تری بخواهد. انتخاب را با نیاز محتوا و ادامه کار بسنجید. یک الگو را صرفاً چون در اپ‌های دیگر دیده‌اید به همه کارها تحمیل نکنید.
اگر خروج باعث از دست رفتن داده می‌شود، سیاست باید روشن باشد. swipe برای بستن و دکمه انصراف نباید بی‌خبر دو نتیجه متفاوت بدهند. راهنمای Dialog درباره قرارداد خروج و بازگشت توضیح دارد. در هر پلتفرم، رفتار سیستم و ابزارهای کمکی نیز باید در انتخاب دیده شوند تا یک لایه زیبا مسیر کاربر را به بن‌بست تبدیل نکند.
دسترس‌پذیری فراتر از اندازه
نام کنترل، ترتیب مرور و اعلام تغییر وضعیت اهمیت دارند. آیکون بدون متن ممکن است معنی مبهم داشته باشد و نام قابل دسترس باید عمل را بیان کند. رنگ تنها راه تشخیص خطا یا انتخاب نباشد. با افزایش اندازه متن، گروه‌بندی و رابطه label با کنترل حفظ شوند. راهنماهای رسمی هر پلتفرم باید با همان واحدها و ابزارهای ورودی خوانده شوند، نه به صورت جدول ساده عددهای مشترک.
حرکت باید هدف و مسیر کم‌حرکت داشته باشد. انیمیشن انتقال می‌تواند رابطه صفحه‌ها را نشان دهد، ولی اطلاعات ضروری نباید فقط از حرکت فهمیده شوند. اگر کاربر کاهش حرکت را انتخاب کرده، نتیجه کار باید همان وضوح را حفظ کند. برای ابزار مرورگر، راهنمای Web Animations نمونه‌ای دارد؛ native mobile و web API یکسان نیستند ولی نیاز به قرارداد state و motion در هر دو مهم است.
مجوز و داده
درخواست دسترسی به دوربین، مکان یا اعلان باید به کار مشخص مربوط باشد. درخواست همه مجوزها در شروع ممکن است برای فرد معنی نداشته باشد. اگر مجوز رد شد، مسیر پایه یا توضیح محدودیت را ارائه کنید. UI باید بداند کدام قابلیت ضروری است و کدام اختیاری. حالت denial نباید فقط به پیام مبهمی ختم شود که کاربر را برای ادامه بی‌دلیل متوقف می‌کند.
داده محلی و همگام‌سازی نیز به توضیح نیاز دارند. ذخیره روی دستگاه با ثبت در حساب یکسان نیست. در قطع اتصال، کاربر باید بداند چه چیزی در انتظار است و چه چیزی تأیید شده است. راهنمای ذخیره سمت client برای وب این مرز را توضیح می‌دهد؛ در native هم قرارداد عمر، خروج از حساب و داده خصوصی باید با معماری واقعی هماهنگ باشد.
تحویل چندپلتفرمی
برای هر جریان، تفاوت رفتارهای پلتفرم را ثبت کنید: navigation، بازگشت، keyboard و مجوز. هویت مشترک می‌تواند در رنگ، لحن و محتوا بماند و کنترل‌ها با انتظار محیط سازگار شوند. اندازه‌ها را با واحد درست بنویسید و از یک اسکرین‌شات به‌عنوان مرجع همه دستگاه‌ها استفاده نکنید. نمونه متن بلند، خطا و حالت باریک باید در مشخصات وجود داشته باشند.
طراحی موبایل قابل اعتماد از نقش کنترل‌ها و مسیر کار شروع می‌شود. HIG و Android guidance به این تصمیم‌ها زمینه می‌دهند، ولی عنوان یک سبک، همه تجربه را توضیح نمی‌دهد. محتوا، اندازه قابل استفاده و رفتارهای سیستم باید هماهنگ باشند. نتیجه مناسب به مخاطب اجازه می‌دهد عمل را پیش‌بینی، خطا را اصلاح و از صفحه‌های مختلف با همان قرارداد روشن ادامه دهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!