09357613765 - 09196607560 - 86034825

رابط کاربری خوش بین و نقش آن در طراحی سایت

بدون نظر

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

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

روزی روزگاری
در زمان های دور، وقتی که هنوز “توییت” به انگلیسی، معنی جیک جیک گنجشک را میداد و اپل یک شرکت ورشکسته بود و مردم شماره فکس شان را هنوز روی کارت ویزیتشان می نوشتند، جذابیت ظاهری وب اینترفیس ها هم مثل مرتاض های لاغرمردنی هندی بود! بیشتر اینترفیس ها حتی اسم رابط کاربری خوش بین به گوششان هم نخورده بود. در آن زمان، فشار دادن یک دکمه توی صفحه های اینترنتی برای مشاهده یک محتوای جدید اتفاقات زیر را رقم میزد:
۱- کاربر روی دکمه کلیک می کرد.
۲- دکمه بعد از کلیک شدن به حالت غیر فعال تغییر وضعیت می داد.
۳- یک درخواست به سرور ارسال می شد.
۴- یک پاسخ از سرور به صفحه برگشت داده می شد.
۵- صفحه دوباره لود می شد و کاربر پاسخ درخواستش را در صفحه جدید می دید.

رابط کاربری قدیمی
این فرایند شاید امروز و در سال ۲۰۱۶ میلادی خیلی غیر بهینه و دمده به نظر برسد، اما باعث تعجب است که هنوز در اواسط دهه اول قرن بیستم، این سناریو هنوز سناریوی غالب خیلی از وب سایت ها و اپلیکیشن هاست و در بعضی محصولات نرم افزاری در فرایندهای تعاملی کاربر و سیستم هم دیده می شود. دلیل آن هم شاید این است که این سناریو معمولا برای کاربران آشناست، احتمال خطای کمتری دارد و پیاده سازی آن هم برای برخی برنامه نویسان راحت تر است. قابل پیش بینی از آن جهت که کاربر می داند که چه زمانی درخواست به سرور ارسال شد (زمانی که رنگ دکمه به حالت غیر فعال در آمده است) و در مورد زمان پاسخ دهی سرور هم تغییر و دوباره لود شدن صفحه نشانگر خوبی برای نمایش پایان تعامل کاربر و سرور است. اما اشکالات این نحوه تعامل و interaction کاملا واضح و مشخص است:

– کاربر خیلی علاف می شود! امروز ما می دانیم که حتی کوتاه ترین تاخیر ها در پاسخ سرور به کاربر، نظر کاربر را نسبت به برند محصولی که در آن صفحه معرفی شده است تغییر می دهد و نه تنها نسبت به وب سایت، طراحی سایت یا صفحه ای که دچار تاخیر شده است.

– هر زمانی که کاربر درخواستی ارسال می کند، نتیجه درخواست وی متضمن از بین رفتن صفحه ای است (حتی چند لحظه) که کاربر در حال مشاهده آن است (یک صفحه جدید لود می شود به جای آنکه محتوای صفحه فعلی آپدیت شود). که این منجر به از دست رفتن پیوستگی کار کاربر و پاره شدن سلسله افکار او می شود؛ حتی اگر لازم نباشد در اینجا از لزوم multy task بودن صفحه صحبت کنیم! به هر حال همیشه پاره شدن سلسله افکار و جابجایی ذهنی آنی برای افراد ناخوشایند است. در هر صورت اگر عملی که کاربر انجام می دهد لزوما نیازی به عوض کردن صفحه و بالنتیجه زمینه ذهنی وی ندارد (مانند فرایند پرداخت آنلاین که ناگزیر از این موضوع باشید) بهتر است بدانیم که این روش، به هیچ عنوان روش کاربر پسندی نیست.

یاد اون نه چندان قدیما به خیر!
بعد از مدتی به اصطلاح وب ۲٫۰ از راه رسید و روش های جدیدی را برای تعامل بین کاربر و صفحات وب با خودش به عنوان سوغات آورد. گل سر سبد این سوغاتی ها البته XMLHttpRequest و تکنیک آژاکس (Ajax) بود. این روش های جدید تعامل کاربر و صفحات وب البته با چیزی به نام Spinner تکمیل می شد: ساده ترین شکل نمایانگر پردازش درخواست کاربر؛ تنها با این هدف که کاربر بداند درخواست وی در حال پردازش است، مانند این:  loading-spinnner
حالا دیگر نیازی نداشتیم منتظر لود شدن دوباره صفحه پس از پاسخ سرور بمانیم. این بروزرسانی وب را بسیار داینامیک تر یا پویاتر کرد و در همین حال تجربه کاربری دلپذیرتر و جذاب تری را برای کاربر ایجاد می کرد. حالا اگر کاربر دکمه ای را فشار می داد اتفاقات زیر می افتاد:
۱- کاربر روی دکمه کلیک می کرد.
۲- دکمه به حالت غیر فعال تغییر وضعیت می داد، یک spinner روی دکمه نمایش داده می شد که نشان می داد سیستم در حال کار است.
۳- یک درخواست به سرور ارسال می شد.
۴- یک پاسخ از سرور به صفحه برگردانده می شد.
۵- حالت بصری صفحه بر اساس نوع پاسخ درخواست کاربر از حالت spinner به نمایش پاسخ تغییر می کرد.
این روش تعاملی جدید یکی از مشکلات پیش گفته نوع قدیمی تعامل کاربر با صفحه را حل می کرد: بروزرسانی صفحه بدون اثر تخریبی لود شدن دوباره انجام می شد، بدون اینکه زمینه ذهنی کاربر را عوض کند و کاربران را بسیار بهتر از پیش درگیر این فضای تعاملی می کرد.

رابط کاربری تعاملی
این روش جدید تعاملی به سرعت گسترش یافته و به شکل وسیعی در وب و رسانه های دیجیتالی استفاده شد. اما هنوز یک مساله باقی بود: کاربران هنوز برای دریافت پاسخ از سرور باید منتظر می ماندند. درست است که ما با کار سخت و توسعه زیرساخت های سخت افزاری می توانیم سرعت سرورهایمان را افزایش دهیم و زمان انتظار را کم کنیم، اما مساله کار سخت و یا هزینه های آنچنانی نیست، مساله این است که باز هم کاربران هر چند کمتر ولی باز هم باید منتظر می ماندند، چیزی که اصلا دوست ندارند. به عنوان مثال تحقیقات نشان داده است که ۷۸% کاربران و مصرف کنندگان نسبت به یک وب سایت کند احساسی منفی داشته و آن را غیر قابل اعتماد می دانند. علاوه بر این مطابق یک بررسی که توسط موسسه Harris Interactive و به سفارش موسسه Tealeaf انجام شده است نشان می دهد که کاربران تلفن همراه در مقابل کندی وب سایت ها واکنش های زیر را از خود نشان می دهند:
– ۲۳ % از کاربران به تلفن همراه خود فحش می دهند، به آن غر میزنند!
– ۱۱% بر سر تلفن همراهشان فریاد می کشند.
– ۴% هم (می خواهید باور کنید یا نکنید) تلفنشان را به زمین می کوبند!
– از سرنوشت ۵۲% باقی مانده هم اطلاعی در دست نیست.
بله…کندی وب سایت ها را جدی بگیرید. چون فجایع فوق را به دنبال دارد!

رابط کاربری
حتی اگر شما جذابترین spinner ها را هم ایجاد کنید و همه خلاقیت و توان خود را هم برای ایجاد spinner های جذاب صرف کنید، به سادگی فقط می شود گفت که برای کاربران امروز این خلاقیت شما هم کافی نیست، چون آن ها اصلا نمی خواهند منتظر بمانند. امروز دیگر مردم با دیدن یک spinner (حتی جذاب) فقط یک تصور را خواهند داشت: این که این وب سایت کند است!

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

رابط کاربری خوش بین (Optimistic UI)
همانطور که گفته شد یک رابط کاربری خوش بین چیزی بیش از راهی برای مدیریت رابطه و تعامل (interaction) بین انسان و کامپیوتر نیست. برای درک بهتر موضوع روی همان مثال “کلیک کردن بر روی دکمه” موضوع را ادامه می دهیم. اما قبل از آن، معنی optimistic چیست؟ مطابق با دیکشنری انگلیسی به انگلیسی آکسفورد:
Op-ti-mis-tic, adj. hopeful and confident about the future.
بیایید با این بخش از معنی optimistic شروع کنیم: confident about the future ؛ مطمئن از اتفاقات آینده! اما این دقیقا یعنی چه؟
بیایید یک محاسبه ای بکنیم: چقدر ممکن است سرور شما در بازگرداندن پاسخ به یک کاربر دچار خطا شود؟ به عنوان مثال برنامه شما اغلب اوقات بعد از کلیک کردن کاربران بر روی دکمه یا لینک مد نظرشان دچار خطا می شود؟ احتمالا اینطور نیست، اما این بسیار به نوع برنامه نویسی شما، میزان بار روی سرور و عوامل بسیار دیگری بستگی دارد که شما به عنوان برنامه نویس و یا متخصص UX تمایل به درگیر شدن با آن را ندارید. اما تا زمانی که برنامه شما به شکلی صحیح و قابل پیش بینی تولید شده باشد، احتمال بروز خطاهای خارج از کنترل شما، پس از ارائه یک درخواست از سوی کاربران بسیار کم خواهد بود و من احتمال خواهم داد میزان خطاهایی که در این حالت رخ خواهند داد حدود ۱% تا ۳% خواهند بود. و این به این معنی است که ۹۷% تا ۹۹% درخواست های کاربران بدون خطا اجرا خواهند شد.

رابط کاربری خوش بین
خوب یک لحظه به آن چیزی که گفتیم دوباره فکر کنید: اگر ما ۹۷% تا ۹۹% از پاسخ صحیح و موفقیت آمیز به کاربر مطمئن هستیم، می توانیم تقریبا به همه پاسخ هایی هم که در آینده به کاربر ارسال می شوند اعتماد داشته باشیم. یعنی اعتماد ما به آینده در این حالت چیزی بیشتر از آزمایش گربه شرودینگر خواهد بود! خوب برگردیم به سناریوی کلیک کردن بر روی دکمه:
۱- کاربر روی دکمه کلیک می کند.
۲- وضعیت دکمه بلافاصله پس از کلیک به وضعیت موفقیت آمیز تغییر وضعیت می دهد.
همین! تمام! لااقل از نقطه نظر کاربر که کار تمام است. دیگر از دکمه ای که به وضعیت غیر فعال تغییر می دهد و منتظر پاسخ سرور است خبری نیست. از spinner های آزار دهنده هم خبری نیست. نوع تعامل و اینتر اکشن به گونه ای است که مو لای درزش نمی رود.

رابط کاربری
اما از نقطه نظر برنامه نویسان و توسعه دهندگان سیستم، فرایند بالا کمی کامل تر دیده می شود، چیزی شبیه به این:
۱- کاربر بر روی دکمه کلیک می کند.
۲- وضعیت دکمه بلافاصله پس از کلیک به وضعیت موفقیت آمیز تغییر وضعیت می دهد.
۳- یک درخواست به سرور ارسال می شود.
۴- پاسخ سرور به درخواست کاربر، به صفحه و یا به وب سایت بازگشت داده می شود.
۵- در ۹۷% تا ۹۹% موارد ما مطمئن هستیم که خطایی رخ نمی دهد و لازم نیست دوباره به کاربر زحمت دهیم.
۶- فقط ۳% باقی می مماند. که در مورد آن ها هم در ادامه صحبت می کنیم!

خوب! فکر می کنم تا اینجای کار متوجه فلسفه رابط کاربری خوش بین یا همان Optimistic UI شده اید. این فلسفه این است: چرا تا زمانی که مطمئنیم ۹۷% پاسخ های سرور صحیح است، ۹۷% کاربران را قربانی آن ۳% کنیم؟! علی الحساب همه موفقند مگر اینکه خلافش ثابت شود، و به خاطر همین هم هست که اسمش خوش بین است!
حالا بیایید نگاهی به نمونه هایی از تعاملات خوش بینانه یا Optimistic interaction ها داشته باشیم که حتما برای شما هم آشنا هستند. شما حتما با دکمه های لایک در فیسبوک، توییتر و یا اینستاگرام آشنا هستید؟ اجازه دهید یک نگاهی هم به این ها بیندازیم.

خب! شروع می کنیم! همین قدر کافی است که روی یک دکمه کلیک کنیم. نه دکمه به حالت انتظار می رود و نه هیچ اتفاق دیگری؛ دکمه فورا به حالت موفقیت آمیز تغییر شکل می دهد.

رابط کاربری
حالا بیایید یک نگاهی بکنیم به تب نتوورک (Network Tab) ابزار توسعه برنامه نویس ها ببینیم در این لحظات کوتاه چه اتفاقاتی می افتد.

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

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

نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *