منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مهر ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

رابط‌های کاربری شیءگرا (Object-Oriented User Interfaces) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

اپ بانکی‌تان را باز کنید. احتمالاً صفحهٔ اولش شبکه‌ای از دکمه است: کارت‌به‌کارت، پرداخت قبض، خرید شارژ، انتقال وجه. هر دکمه یک فعل است.

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

رابط شیءگرا این ترتیب را برعکس می‌کند. اول کارت را نشانتان می‌دهد و بعد کارهایی را که با همان کارت می‌شود کرد.

رابط کاربری شیءگرا چیست؟

رابط کاربری شیءگرا دور «چیزها» ساخته می‌شود، نه دور «کارها». چیزها همان اسم‌هایی‌اند که کاربر وقتی از کارش حرف می‌زند به زبان می‌آورد: پیام، سفارش، پرونده، نوبت، کارت بانکی.

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

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

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

اسم اول، بعد فعل

تفاوت اصلی در ترتیب است. در رابط فعل‌محور کاربر اول کار را انتخاب می‌کند و بعد چیزی را که کار روی آن انجام می‌شود. در رابط شیءگرا اول شیء را انتخاب می‌کند و بعد کار را. به اولی ترتیب «فعل ـ اسم» می‌گویند و به دومی «اسم ـ فعل» یا «شیء ـ کنش».

نمودار بالای صفحه هر دو ترتیب را برای یک کار ساده کنار هم گذاشته است: مسدود کردن کارتی که گم شده. در مسیر فعل‌محور کاربر باید اول بداند این کار در منو چه نامی دارد. «مسدودسازی» زیر «خدمات کارت» است یا زیر «امنیت»؟ بعد تازه باید کارت را از فهرست انتخاب کند.

در مسیر شیءگرا کاربر کارت را می‌بیند، چون شیء همیشه روی صفحه است. با لمس کارت، کنش‌های همان کارت باز می‌شوند و مسدودسازی یکی از آن‌هاست. لازم نیست اسم کار را حفظ باشد. کافی است شیء را بشناسد.

مزیت پنهانش این است که تا شیئی انتخاب نشده، کنشی هم نیست که اشتباهی اجرا شود. وقتی هم انتخاب شد، رابط فقط کنش‌هایی را نشان می‌دهد که برای همان شیء معنا دارند. پس بخشی از خطاها پیش از وقوع حذف می‌شوند.

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

از زیراکس استار تا OOUX

این بخش در منبع نیست. ترتیب شیء ـ کنش در سال ۱۹۸۱ با رایانهٔ Xerox Star به یک محصول تجاری رسید. صفحه‌کلید استار چند کلید ثابت داشت، از جمله جابه‌جایی، کپی، باز کردن، حذف و نمایش ویژگی‌ها.

نکتهٔ درخشان استار همین «فرمان‌های عام» بود. کلید کپی روی سند و پوشه و کلمه یکسان کار می‌کرد. به‌جای صدها فرمان، چند فعل عام کافی بود، چون بار معنا را خود شیء می‌برد.

شش سال بعد، IBM در راهنمای Common User Access یا CUA ترتیب شیء ـ کنش را قاعدهٔ نرم‌افزارهایش کرد. ویرایش ۱۹۹۱ این راهنما یک قدم جلوتر رفت و «میز کار شیءگرا» را معرفی کرد. در آن مدل مرکز کار سندها و داده‌ها بودند، نه برنامه‌ها. ویندوز ۹۵ هم از همین ویرایش پیروی کرد. برای تاریخچهٔ کلی‌تر، سراغ رابط گرافیکی کاربر بروید.

موج تازه در سال ۲۰۱۵ آمد. Sophia Prater در مقاله‌ای در A List Apart نام «تجربهٔ کاربری شیءگرا» یا OOUX را پیش کشید. آن زمان با نام خانوادگی Voychehovski می‌نوشت. حرف اصلی‌اش این بود که پیش از کشیدن هر صفحه‌ای، اشیا را فهرست کنید.

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

پنج قاعده‌ای که رابط شیءگرا را می‌سازد

منبع پنج اصل را برمی‌شمارد که هر کدام جلوی یک خطای رایج را می‌گیرد.

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

کنش در زمان نیاز: کنش‌ها وقتی ظاهر می‌شوند که شیئی انتخاب شده باشد. این همان افشای تدریجی است، با یک قاعدهٔ روشن برای اینکه چه چیزی کی پیدا شود. شیء ساختار را می‌دهد و افشای تدریجی زمان‌بندی را.

رفتار یکسان: یک نوع شیء همه‌جا یک‌جور رفتار می‌کند. پیام در صندوق ورودی، در پیش‌نویس‌ها و در بایگانی همان کنش‌ها را دارد. کاربر یک بار یاد می‌گیرد و همه‌جا به کار می‌برد.

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

رابطه‌ها مسیر حرکت‌اند: کاربر از یک شیء به شیء مرتبطش می‌رود. از پروژه به وظیفه‌هایش، از آلبوم به عکس‌هایش، از رزرو به مسافرانش. این نوع ناوبری با شکلی که ذهن کاربر چیزها را به هم وصل می‌کند جور است.

فایدهٔ بلندمدت‌تر، به گفتهٔ منبع، این است که قابلیت تازه به یک شیء آشنا می‌چسبد و صفحهٔ تازه‌ای نمی‌سازد. «ارسال زمان‌دار» گزینه‌ای روی پیام می‌شود و «واگذاری به همکار» گزینه‌ای روی وظیفه. محصول بزرگ می‌شود، ولی نقشه‌اش عوض نمی‌شود.

از اسم‌ها تا صفحه‌ها

منبع پنج قدم برای ساختن چنین رابطی پیشنهاد می‌کند که در عمل با ORCA هم‌پوشانی دارند.

قدم اول، اسم‌ها را پیدا کنید: در مصاحبه و مشاهده به اسم‌هایی گوش بدهید که کاربر مدام تکرار می‌کند. پرستار از «بیمار» و «نوبت» و «پرونده» حرف می‌زند، نه از «ماژول پذیرش». این اسم‌ها پنجره‌ای به مدل ذهنی کاربرند. اسمی که فقط تیم فنی به کار می‌برد، احتمالاً شیء کاربر نیست.

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

قدم سوم، کنش هر شیء: برای هر نوع شیء فهرست کنید با آن چه می‌شود کرد. همهٔ کنش‌ها به همهٔ اشیا نمی‌خورند. پروژه بایگانی می‌شود و وظیفه تیک می‌خورد.

قدم چهارم، شکل دادن: تصمیم بگیرید هر شیء کجا و به چه شکلی دیده شود. داشبورد پروژه‌ها را کارت می‌کند و صفحهٔ جزئیات یک پروژه را با وظیفه‌هایش نشان می‌دهد. در این رویکرد صفحه‌ها نمایی از یک شیء‌اند، نه مقصدهایی جدا از هم.

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

کجا مسیر خطی بهتر است

منبع تقریباً هیچ محدودیتی برای این رویکرد نمی‌شمارد. این بخش افزودهٔ من است، چون به نظرم رابط شیءگرا همه‌جا جواب نمی‌دهد.

نمودار بالا دو پرسش را روی دو محور گذاشته است: کار چند بار انجام می‌شود، و آنچه از آن می‌ماند چقدر عمر دارد؟

وقتی کار تکراری است و شیء ماندگار، رابط شیءگرا رقیب ندارد. صندوق نامه و حساب بانکی هر روز باز می‌شوند و نقشه‌شان یک بار یاد گرفته می‌شود.

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

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

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

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

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

در بافت فارسی

چند نکته در طراحی شیءگرا به فارسی خاص است و در منبع نیامده.

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

دو: جمع برای فهرست، مفرد برای شیء. زبانهٔ فهرست جمع است: «سفارش‌ها». کارت و صفحهٔ جزئیات مفرد است: «سفارش ۴۲۱۷». این جفت باید از یک ریشه باشد. زبانهٔ «خریدهای من» که به صفحهٔ «جزئیات سفارش» می‌رسد، دو اسم برای یک شیء گذاشته است.

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

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

جمع‌بندی

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

از استار تا OOUX حرف ثابت این بوده است: اشیا را از زبان کاربر پیدا کنید و صفحه‌ها را نمایی از همین اشیا بسازید.

ولی همه‌جا جواب نمی‌دهد. کار یک‌باره مسیر خطی می‌خواهد. اشیایی هم که از پایگاه داده آمده‌اند، فقط ظاهر شیءگرایی دارند.

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