اصول طراحی رابط موبایل

رابط موبایل با رابط دسکتاپ کجا فرق می کند؟

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

رابط موبایل یعنی همان لایه دیدنی و لمسی، ولی با این سه محدودیت. بقیه چیزها از همین جا می آیند: چرا یک عمل اصلی در هر صفحه، چرا دکمه های اصلی پایین صفحه، چرا فرم کوتاه، چرا حالت بارگذاری اهمیت دارد.

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

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

شست تا کجای صفحه می رسد و هدف لمسی چقدر باشد؟

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

اندازه هدف اما جای حدس زدن نیست، چون عدد دارد و عددها منتشر شده اند. استاندارد WCAG 2.2 در معیار ۲.۵.۸ می گوید هدف ورودی اشاره گر دست کم ۲۴ در ۲۴ پیکسل CSS باشد، با استثناهایی که خودش فهرست می کند: هدف کوچک تر اگر فاصله کافی دورش باشد، یا اگر همان کار از راه دیگری در همان صفحه شدنی باشد، یا وقتی هدف داخل یک جمله است. راهنمای دسترس پذیری خود اندروید عدد بزرگ تری می دهد: دست کم ۴۸ در ۴۸ پیکسل مستقل از چگالی، با دست کم ۸ واحد فاصله بین دو هدف، و توضیح می دهد که ۴۸ واحد روی هر صفحه ای تقریبا نه میلیمتر فیزیکی می شود.

همان صفحه گوگل نکته ای دارد که بیشتر از خود عدد به کار می آید: ناحیه لمسی از مرز دیداری المان بزرگ تر است. یک آیکن که ۲۴ واحد دیده می شود، با فاصله دور خودش هدف ۴۸ واحدی می سازد. یعنی لازم نیست دکمه را زشت و بزرگ کنید؛ باید ناحیه شنیدن لمس را بزرگ کنید.

و یک هشدار درباره عددی که همه نقل می کنند. «اپل می گوید ۴۴ در ۴۴ پوینت» جمله ای است که در هر مقاله فارسی و انگلیسی طراحی موبایل تکرار می شود. ما امروز صفحه های راهنمای رابط انسانی اپل را گشتیم: صفحه چیدمان، صفحه دسترس پذیری، صفحه دکمه ها، صفحه ژست ها. این عدد در هیچ کدام به عنوان حداقل هدف لمسی نوشته نشده است. تنها جایی که ۴۴ پوینت دیدیم، جدول اندازه دکمه در visionOS بود که چیز دیگری است. پس نه اینکه عدد غلط باشد؛ منبع زنده ای برایش پیدا نکردیم و ترجیح می دهیم بگوییم نمی دانیم تا اینکه به اپل حرفی نسبت بدهیم. عددی که می شود به آن استناد کرد همان دو عدد بالاست.

قاعده پلتفرم را رعایت کنم یا طرح خودم را بگذارم؟

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

در مقابل، رنگ، تصویرسازی، لحن متن، صفحه معرفی و کارت محصول جای شماست و آنجا شبیه بقیه بودن هیچ سودی ندارد. مرز عملی ساده است: اگر عوض کردن یک چیز کاربر را مجبور کند دوباره یاد بگیرد، آن چیز را عوض نکنید.

یک نکته که پیمانکارها معمولا دیر می گویند: نگه داشتن قاعده پلتفرم گران تر نیست، ارزان تر است. کامپوننت استاندارد اندروید و iOS خودشان با تغییر اندازه فونت سیستم، با حالت تیره، با صفحه خوان و با راست چین کار می کنند. نسخه دست ساز همان کامپوننت، همه اینها را باید از نو بسازد و معمولا نمی سازد. جایی که واقعا لازم است کامپوننت اختصاصی بسازید، برای همه این حالت ها بودجه بگذارید، نه فقط برای حالت خوش.

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

رابط فارسی روی گوشی کجا می شکند؟

راست چین کردن با یک خط CSS تمام نمی شود و اینجا همان جایی است که بیشتر اپ های فارسی لنگ می زنند. راهنمای رابط انسانی اپل یک صفحه کامل درباره راست به چپ دارد و چند قاعده اش دقیقا همان چیزهایی است که ما هم در عمل به آنها می خوریم.

اول، عددها. اپل می گوید ترتیب رقم های داخل یک عدد مشخص هرگز برعکس نمی شود: شماره تلفن و شماره کارت و عدد ۵۴۱ در هر جهتی همان ترتیب را دارند. اما ترتیب عددهایی که پیشرفت یا شمارش را نشان می دهند باید برعکس شود، چون خود کنترل آینه شده است. این دو قاعده شبیه هم به نظر می رسند و در عمل خلاف هم اند.

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

سوم، آیکن ها. فلش برگشت باید در فارسی به راست اشاره کند، ولی ساعت و لوگو و تیک تایید هرگز آینه نمی شوند و آیکنی که واقعا به یک جهت فیزیکی اشاره می کند هم همین طور. اپل حتی نکته ای می گوید که کمتر جایی نوشته شده: متن عربی و عبری کنار متن لاتین بزرگ کوچک تر به نظر می رسد، چون حرف بزرگ ندارد، و حدود دو پوینت بزرگ تر کردنش تعادل را برمی گرداند. برای فارسی هم همین درست است.

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

حالت هایی که هیچ وقت در طرح اولیه کشیده نمی شوند

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

بازخورد یعنی همین. کاربر موبایل بعد از لمس، ظرف کسری از ثانیه باید نشانه ای ببیند که لمسش ثبت شده، حتی اگر پاسخ سرور دو ثانیه طول بکشد. بدون آن نشانه، همان دکمه دوباره زده می شود و شما یک سفارش تکراری دارید. حالت آفلاین هم روی گوشی یک حالت واقعی است نه یک حالت لبه: آسانسور، مترو، پارکینگ.

ثبات را هم اینجا می شود شمرد. یک الگو برای نمایش خطا در کل اپ انتخاب کنید و همه جا همان را بگذارید. اگر یک صفحه خطا را بالای فرم نشان بدهد و صفحه دیگر زیر فیلد و سومی داخل یک پیام شناور، کاربر هر بار باید دنبال خطا بگردد.

و بند آخر که در واقع اولین کاری است که باید بکنید: اپ را روی گوشی خودتان با اندازه فونت بزرگ سیستم و در نور آفتاب باز کنید. بیشتر مشکلاتی که در این درس شمردیم در همان یک دقیقه پیدا می شوند، خیلی زودتر از هر بازبینی رسمی.