ایمان قاسمیان
ایمان قاسمیان
خواندن ۱۳ دقیقه·۳ سال پیش

قرینه‌سازی الگوهای رابط کاربر فارسی به روش طراحی اتمی


قرینه‌سازی پترن‌های UI فارسی به روش طراحی اتمی
قرینه‌سازی پترن‌های UI فارسی به روش طراحی اتمی


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

آمپول این نوشته:

- مقدمه

- عوامل تأثیرگذار بر انتظارات جهتی کاربر فارسی‌زبان:

  1. فارسی (غالب)
  2. ریاضی
  3. انگلیسی
  4. ساعتگرد

- استراتژی من

- نقد به یادداشت چه پترن‌هایی در زبان فارسی قرینه می‌شوند؟

- طرح مبحث طراحی اتمی برای رابط کاربر فارسی

- ارائه راه حل برای برخی مشکلات

مشکل اول: طراحی نوارهای پیشرفت (Progress bars)

مشکل دوم: اسلایدر انتخاب محدوده اعداد

مشکل سوم: راست‌چین‌سازی اعداد

مشکل چهارم: امتیازدهی ستاره‌ای


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




مقدمه

جهت نوشتاری فارسی راست به چپه و انگلیسی چپ به راست. تا اینجا ظاهراً مشکلی نیست. ولی این جهت‌ها در ارتباط با موارد دیگه مشکل‌ساز میشن. یکیش جهت نوشتاری ریاضیه. زبان انگلیسی همسو با ریاضیه اما فارسی برعکسه. همین مسأله باعث چالش‌های متعددی برای طراحان رابط کاربر فارسی زبان میشه.

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

تداخل جهت نوشتاری فارسی و ریاضی
تداخل جهت نوشتاری فارسی و ریاضی


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

جهت افقی دستگاه مختصات دکارتی چپ به راسته. فارسی و انگلیسی مهم نیست
جهت افقی دستگاه مختصات دکارتی چپ به راسته. فارسی و انگلیسی مهم نیست

عوامل تأثیرگذار بر انتظارات جهتی کاربر فارسی‌زبان

در حال حاضر به نظر من این انتظارات تحت تأثیر این چهار مدل قرار گرفته:

  1. فارسی: راست به چپ (غالب)

- ساختار اتم‌ها، مولکول‌ها، ارگانیسم‌ها و...

- جریان صفحات (User Flow)

۲. ریاضی: چپ به راست (محدود)

- اعداد

- برخی جهت‌های برداری (برخی فلش‌ها، نوارهای پیشرفت و...)

۳. انگلیسی: چپ به راست (عادت)

۴. جهت‌های دایره‌ای: ساعتگرد


استراتژی من

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

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



نقد به یادداشت چه پترن‌هایی در زبان فارسی قرینه می‌شوند؟

یکی از نقدهایی که به این یادداشت دوست خوبم «امیر تقی‌آبادی» دارم، تک بُعدی نگاه کردن به مسأله‌ی انتظار جهتی فارسی‌زبانانه که فقط جهت ریاضی رو در نظر می‌گیره. اما ریاضی اصلاً‌ در رابط‌های کاربر فارسی غالب نیست. امیر توی این یادداشت میگه:

بر اساس تحقیقات شخصی از 61 نفر که خواستم ابتدا یک فلش رو به بالا بکشند (به این دلیل که جهت مختصاتی در کاغذ مشخص شود) وسپس یک فلش رو به جلو بکشند 58 نفر فلش رو به جلو را به سمت راست کشیدند.
این به این معنی است علارقم تمامی نظریه‌های قرینه‌ی فعلی همچنان از نظر تمامی کاربران حرکت رو به جلو به سمت راست و حرکت رو به عقب به سمت چپ است.

- امیر تقی‌آبادی


این آزمایش دو مشکل عمده داره:

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


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

تطابق مدل صفحه گذاری راست به چپ وبسایت زومیت با کتب فارسی
تطابق مدل صفحه گذاری راست به چپ وبسایت زومیت با کتب فارسی


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


بذارید این نظریه رو با رویکرد «طراحی اتمی» مطرح کنم:

طرح مبحث طراحی اتمی برای رابط کاربر فارسی

روش طراحی اتمی
روش طراحی اتمی


اگه بدون هیچ پیش‌زمینه‌ای بخواین جهت حرکت هر کدوم از دو آدمک زیر رو رسم کنین، به کدوم سمت رسم می‌کنین؟


اگه از نظر شناخت و تشخیص مشکلی نداشت باشیم، برای تصویر سمت راستی به سمت چپ، و برای تصویر سمت چپی به سمت راست فلش می‌کشیم. این دیگه نه کاری به جهت نوشتاری ریاضی داره، نه فارسی و نه انگلیسی. این صرفاً یه نفره که داره می‌دوه!

حالا بیاید با همین رویکرد، پترنهای فارسی رو بسازیم. فرض کنید بخوایم واسه این دو کلمه، فلشِ روو به جلو رسم کنیم:

کدام جهت برای گذاشتن فلش صحیح است؟
کدام جهت برای گذاشتن فلش صحیح است؟


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


با این حساب حالا ما یک دکمه‌ی متنی یا در واقع یک اتم داریم:

اتم: یک دکمه متنی فارسی به همراه فلشی برای جهت دهی.
اتم: یک دکمه متنی فارسی به همراه فلشی برای جهت دهی.


حالا بیاید این اتم رو به همراه یک اتم دیگه به یک مولکول تبدیل کنیم:

مولکول: یک دکمه‌ی متنی فارسی به همراه یک عنوان. از اونجایی که جهت خواندن فارسی از راست به چپه، اول باید عنوان خونده بشه و بعد دکمه (اکشن) اعمال بشه.
مولکول: یک دکمه‌ی متنی فارسی به همراه یک عنوان. از اونجایی که جهت خواندن فارسی از راست به چپه، اول باید عنوان خونده بشه و بعد دکمه (اکشن) اعمال بشه.


خیلی خب. بریم این مولکول رو با یه اتم دیگه ترکیب کنیم تا یک ارگانیسم به دست بیاد:

ارگانیسم: از اونجایی که جهت رو به جلو سمت چپه، پس باید ادامه‌ی اسلایدر هم در سمت چپ باشه
ارگانیسم: از اونجایی که جهت رو به جلو سمت چپه، پس باید ادامه‌ی اسلایدر هم در سمت چپ باشه


می‌بینیم که چون جهت مولکولمون به سمت چپه، اسلایدر تصاویر هم باید راست به چپ شه. اگه جهت اسلایدر چپ‌به‌راست بشه، با دیگر مولکول‌ها تضاد جهتی به وجود میاد. حالا بریم این ارگانیسم‌ رو با چندتا ارگانیسم دیگه به یک تمپلیت تبدیل کنیم (کاری به بی‌ربط بودن ارگانیسما نداشته باشید، صرفاً میخواستم همشونو توی یه صفحه جا بدم) :

تمپلیت: نحوه صحیح چینش ساختار و جهت الگوها (پترن‌ها) در رابط کاربر فارسی
تمپلیت: نحوه صحیح چینش ساختار و جهت الگوها (پترن‌ها) در رابط کاربر فارسی


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

صفحات: چیزی که نهایتاً کاربر تجربه می‌کنه
صفحات: چیزی که نهایتاً کاربر تجربه می‌کنه


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

مسلماً نمیشه چون توی جهت‌ها تضاد به وجود میاد. پس این نظریه‌ای که میگه فلش به سمت چپ تداعی بازگشت می‌کنه، از نظر ساختاری همینجا رد میشه.


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



حل مشکل قرینه‌سازی چند الگو (پترن) معضل‌دار!

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

اینجا شروع میکنم به دادن چند راه حل و تأکید میکنم که:

۱. این الگوها مطمئناً به مرور زمان بهبود پیدا می‌کنن.

۲. دوست دارم این یک روال بشه و علاوه بر خودم، دیگران هم راه حل‌هاشونو منتشر کنن.

۳. اگه راه‌حل‌های جدیدی پیدا کردم، در نوشته‌ی جدیدی می‌نویسم و انتهای این متن لینک میدم

مشکل اول: نوارهای پیشرفت (Progress Bars)

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

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

۲. ترازبندی (Alignment): این کار می‌تونه از نظر بصری ترازبندی رو به هم بریزه.

اگه هم بخوایم از نوار پیشرفت رو راست به چپ بذاریم، می‌تونه با انتظارات جهتی برخی کاربران که از بردارهای ریاضی و عادت انگلیسی اومده، در تضاد باشه.

معضل متون فارسی با الگوهای رابط کاربر جهت‌دار در برابر بی مشکل بودن متون انگلیسی
معضل متون فارسی با الگوهای رابط کاربر جهت‌دار در برابر بی مشکل بودن متون انگلیسی


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

نوار وضعیت ایوند، راست‌به‌چپ و چپ‌به‌راست
نوار وضعیت ایوند، راست‌به‌چپ و چپ‌به‌راست


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


راه حل دوم: برای ویزاردها میشه مثل ایوند رفتار نکرد و برای هر مرحله از ایستگاه (Station) استفاده کرد. در این حالت میشه توی بعضی جاها نوار رو در حالت عمودی قرار داد که همه‌ی کاربران با انواع مدل‌های ذهنی باهاش راحت باشن. البته محدودیت‌های زیادی داره اما برخی جاها کارسازه:

نوار وضعیت بالا به پایین، جایگزین مناسب برخی موقعیت‌ها برای نوار راست به چپ
نوار وضعیت بالا به پایین، جایگزین مناسب برخی موقعیت‌ها برای نوار راست به چپ

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

مشکل دوم: اسلایدر انتخاب محدوده اعداد

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

راه حل دیجیکالا برای برطرف کردن بار شناختی اسلایدر محدوده قیمت
راه حل دیجیکالا برای برطرف کردن بار شناختی اسلایدر محدوده قیمت


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

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

طرح پیشنهادی اسلایدر انتخاب محدوده اعداد
طرح پیشنهادی اسلایدر انتخاب محدوده اعداد



توی این مدل، حروف فارسی روی اسلایدر قرار گرفتن و بر جهت ریاضی غلبه می‌کنن. کاربر به محض دیدن حرف اضافه‌ی «از» بر روی دایره‌ی سمت راست، بدون نیاز به فکر کردن متوجه میشه که جهت این اسلایدر از راست به چپه. برای جلوگیری از مخفی شدن اعداد زیر انگشت هم توی حالت فشرده (Pressed) باید اعداد بالا برن که به قابل مشاهده بودن وضعیت سیستم (Visibility of system status) لطمه‌ای وارد نشه و همچنین حالت نزدیکی دو گیره به همدیگه هم در نظر گرفته شده.


مشکل سوم: راست‌چین‌سازی اعداد

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

قابلیت اسکن و ترازبندی بهتر در فاکتورهای انگلیسی
قابلیت اسکن و ترازبندی بهتر در فاکتورهای انگلیسی


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

چالش قابلیت اسکن و ترازبندی بهتر در فاکتورهای فارسی
چالش قابلیت اسکن و ترازبندی بهتر در فاکتورهای فارسی


می‌بینیم که بازم به مشکل خوردیم. چرا نمیشه تو فارسی هم خرو داشته باشیم و هم خرما رو؟ فقط انگلیسی زبونا باید روی خرشون بشینن و خرما بخورن؟ این شد که راه حلی به ذهنم رسید!

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

حل مشکل قابلیت اسکن و ترازبندی در فاکتورهای فارسی
حل مشکل قابلیت اسکن و ترازبندی در فاکتورهای فارسی


مشکل چهارم: امتیازدهی ستاره‌ای

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

راهنمایی گوگل میت برای درک راحت‌تر جهت شروع امتیازدهی
راهنمایی گوگل میت برای درک راحت‌تر جهت شروع امتیازدهی


توی ایران هم اونقدر این مسأله پیچیده شده که اسنپی که کل اپلیکیشنش راست‌به‌چپه، عطاش رو به لقاش بخشیده و امتیازدهی ستاره‌ای رو چپ‌به‌راست قرار داده:

صفحه‌ی چپ‌به‌راست اسنپ برای امتیازدهی ستاره‌ای
صفحه‌ی چپ‌به‌راست اسنپ برای امتیازدهی ستاره‌ای


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

کافه بازار حداقل توی این مورد مثل من فکر می‌کنه: «باید همه چیز رو راست به ‌چپ کنیم و اگر جایی مشکلی پیش اومد، تلاش کنیم حلش کنیم». از همین روو، اومده جهت رو راست‌به‌چپ در نظر گرفته و با گذاشتن شماره زیر ستاره‌ها، کاربر رو راهنمایی کرده:

امتیازدهی ستاره‌ای کافه بازار
امتیازدهی ستاره‌ای کافه بازار


جمع‌بندی

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

رابط کاربریتجربه کاربریطراحی محصولطراحی اتمیفارسی سازی
طراح تجربه و رابط کاربر
شاید از این پست‌ها خوشتان بیاید