چگونه یک رابط کاربری را به شکلی اصولی مهندسی کنیم؟

در حوزهٔ طراحی UI (رابط کاربری) همواره این پرسش برای دولوپرهای فرانت‌اند پیش می‌آید که باید از کدام فناوری استفاده کرد (در اینجا منظور از فناوری زبان‌های برنامه‌نویسی، فریمورک‌ها، لایبرری‌ها و به طور کلی تِرِندهای روز صنعت است.) اما در عین حال یکسری مسائل زیرساختی وجود در این زمینه وجود دارند که، فارغ از زبان یا لایبرری انتخابی‌مان، نیاز است تا در حین توسعهٔ رابط کاربری اپلیکیشن توجه خاصی به آن‌ها صورت گیرد و این دقیقاً همان چیزی است که در این مقاله قصد داریم مورد بررسی قرار دهیم.

ایجاد ثبات در جای‌جای رابط کاربری
چیزی که در طراحی رابط کاربری بسیار حائز اهمیت می‌باشد اصطلاحاً Consistency است بدین معنی که اِعمال تغییر روی داده‌های تک‌تک کاربران می‌باید در تمامی بخش‌های اپلیکیشن صورت گیرد؛ به عبارتی، وقتی کاربری چیزی را لایک می‌کند یا امتیاز کاربران افزایش/کاهش پیدا می‌کند و کارهایی از این دست، حتماً نیاز است تا این تغییرات در هر جایی که اطلاعات کاربر نمایش داده می‌شود اِعمال گردد (در این ارتباط توصیه می‌کنیم به مقالهٔ Design Consistency به چه معنا است و چگونه کمک به UX بهتری می‌کند؟ مراجعه نمایید.)

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

مد نظر قرار دادن وضعیت کاربر در نَویگیشن
پیرو مسئلهٔ Consistency که پیش از این مورد بررسی قرار دادیم، همواره نیاز است تا وقتی کاربران در اپلیکیشن‌مان به گشت‌وگذار می‌پردازند وضعیت قبلی آن‌ها را مد نظر قرار دهیم. برای درک بهتر این موضوع، فرض کنیم صفحه‌ای در سایت خود طراحی کرده‌ایم برای جستجوی محتوا که وقتی کاربر چیزی را داخل فیلد مربوطه وارد می‌کند و فرم را سابمیت می‌کند، یکسری نتایج در معرض دیدش قرار خواهند گرفت که در چنین شرایطی کاربر احتمالاً روی یکی از نتایج کلیک کند. حال فرض کنیم کاربر مذکور تمایل دارد تا مجدد به صفحهٔ نتایج جستجو باز گشته و روی لینک دیگری کلیک کنید که در چنین شرایطی می‌باید کلیدواژگانی که در فیلد جستجو وارد شده بودند + نتایج جستجوی قبلی کماکان وجود داشته باشند.

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

استفاده اصولی از کَش
در آیتم قبل به توضیح این مسئله پرداختیم که کاربران تمایل دارند تا پس از کلیک کردن روی دکمهٔ بازگشت (Back)، بدون فوت وقت همان دیتای قبلی در معرض دیدشان قرار گیرد که در چنین شرایطی حداقل دو راه‌کار پیش‌روی ما است بدین صورت که یا دیتا را مجدد از سرور فراخوانی کنیم (که چنین چیزی خیلی مطلوب نیست.) و یا اینکه در پروسهٔ‌ نَویگیشن کاربر در اپلیکیشن، داده‌ها را کَش کنیم. 

Cache مزایای بسیاری هم برای کاربران و هم برای توسعه‌دهندگان دارا است. از دید کاربر می‌توان گفت که کَش کردن داده‌ها سرعت وب‌گردی وی را افزایش می‌دهد و از دید یک دولوپر نیز بار روی سرور کاهش می‌یابد اما فراموش نکنیم که این کار اصلاً بدون چالش هم نیست! به عبارتی، فرض کنیم کاربر از یک صفحهٔ خاص روی دکمهٔ‌ ویرایش پروفایل کلیک کرده و تغییراتی را اِعمال کرده سپس روی دکمهٔ بازگشت کلیک می‌کند که در چنین شرایطی اگر داده‌های کَش‌شده کماکان معتبر باشند، تغییرات مد نظر کاربر در معرض دیدش قرار نخواهند گرفت که این مسئله یک باگ طراحی است که در ادامه بیشتر پیرامون این موضوع بحث خواهیم کرد.

عکس‌العمل نشان دادن به رفتار کاربر
لازم به یادآوری است که انجام برخی محاسبات در سمت سرور از یکسو و همچنین ردوبدل شدن داده در فضای اینترنت از سوی دیگر نیازمند صرف زمان است و مشکل اصلی از زمانی شکل می‌گیرد که زمان اختصاص‌یافته به این دو مورد هم‌افزایی پیدا کنند (در چنین شرایطی فرض را بر این می‌گذاریم که کد بهینه است و در غیر این صورت، به دو مورد فوق باید مفهومی تحت عنوان Big O Notation را نیز بیفزاییم که به کلام ساده عبارت است از زمانی که اجرای یک الگوریتم به خود اختصاص می‌دهد.)

کمتر کاربری را می‌توان یافت که اَکشن خاصی را انجام داده و از طرف اپلیکیشن فیدبک لازم را دریافت نکند اما کماکان وفادار بماند. فرض کنیم دکمه‌ای در معرض دید کاربر قرار داده‌ایم که با کلیک بر روی آن داده‌های بیشتری از سرور فراخوانی شده و نمایش داده می‌شوند که در چنین شرایطی نیاز است تا حتماً از یک اِلِمان بصری کمک بگیریم تا به وی نشان دهیم که سیستم در حال پردازش درخواست وی است که در چنین شرایطی معمولاً از یک تصویر گیف که در حال چرخش است استفاده می‌شود (گرچه در نظر گرفتن اِلِمان‌های بصری بدین شکل تا حد قابل‌توجهی آستانهٔ تحمل کاربران را بالا می‌برند، اما نشان دادن مثلاً یک تصویر گیف هرگز بدان معنا نیست که کاربر مثلاً بیش از ۳ تا ۵ ثانیه تحمل خواهد کرد!)

غیرقابل‌پیش‌بینی بودن رفتار کاربران
نیاز به توضیح نیست که هر چه‌قدر هم حالات مختلفی که کاربران می‌توانند از آن طریق به تعامل با اپلیکیشن‌مان بپردازند را پیش‌بینی کنیم، کماکان ممکن است حالات احتمالی دیگری نیز وجود داشته باشند که از قلم افتاده باشند (مثلاً‌ اگر کاربر به طور مکرر روی دکمه‌ای که مسئول فراخوانی ای‌جکسی داده‌ها است کلیک کند چه اتفاقی خواهد افتاد.)

توجه به اولویت و جایگاه سلسله‌مراتبی عناصر رابط کاربری
در زبان سی‌اس‌اس پراپرتی z-index به راحتی این امکان را در اختیارمان قرار می‌دهد تا اولویت اِلِمان‌های قرار گرفته در سمت کاربر را مشخص سازیم اما در عین حال چیزی که به مراتب مهم‌تر بوده و هرگز نباید نادیده گرفته شود این است که بررسی کنیم ببینیم بر اساس چه منطقی مثلاً یک اِلِمان خاص را روی دیگری قرار داده‌ایم.

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

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

پشتیبانی از زبان‌های زندهٔ مختلف
چنانچه اپلیکیشنی طراحی نموده‌ایم که مخاطبش کاربران در کشورهای مختلف است، می‌باید حداقل دو نکتهٔ زیر را مد نظر قرار دهیم:

- اول اینکه زبان‌های زندهٔ مختلف به خوبی ساپورت شوند.
- دوم اینکه لی‌اوت «چپ به راست» و «راست به چپ» به درستی هندل گردد.

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

هندل کردن اصولی باگ‌های نرم‌افزاری
باگ‌ها بخش جدایی‌ناپذیر فرآیند توسعهٔ نرم‌افزار هستند اما در عین حال دولوپرها می‌باید تمام تلاش خود را به کار گیرند که تا حد ممکن از رخداد آن‌ها در محیط Production جلوگیری کنند (به طور کلی، منظور از این اصطلاح حالتی است که کدها روی سرور دیپلوی شده و نتایج، خواه مثبت و خواه منفی، در معرض دید کاربران واقعی قرار می‌گیرند.) که در این ارتباط توصیه می‌کنیم به مقالات زیر مراجعه نمایید:

- Grace Murray Hopper: کسی که برای اولین بار اصطلاح Bug را باب کرد!
- درآمدی بر انوع باگ‌ها در صنعت توسعهٔ نرم‌افزار
- چگونه اجازه ندهیم هیچ‌گونه باگی از دیدمان پنهان بماند؟
- Performance Bugs: یکی از بدترین انواع باگ‌های برنامه‌نویسی
- نکات یوایکسی برای طراحی صفحه‌های خطای 404

به طور کلی، برخی باگ‌ها هستند که بواسطهٔ آن‌ها اپلیکیشن هرگز کِرش نمی‌کند بلکه در منطق اپلیکیشن مشکلی وجود دارد که به موجب آن داده‌های اشتباهی در معرض دید کاربران قرار می‌گیرد که به نظر می‌رسد آگاهی پیدا کردن نسبت به این دست باگ‌ها کمی دشوار باشد.

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