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

تعامل مبتنی بر حرکت (Gesture Interaction) چیست؟

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

دکمه خودش را نشان می‌دهد. حرکت، خودش را نشان نمی‌دهد.

و همین یک جمله، بیشتر مسئله‌های طراحی با حرکت را توضیح می‌دهد.

تعریف

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

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

انواع حرکت

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

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

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

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

و این با بقیهٔ رابط فرق دارد. در یک منو، کاربر فقط دومی را دارد؛ اولی از قبل حل شده.

شش گام طراحی

یک: کاربر و بافت را بفهمید. اول تعیین کنید آیا حرکت با رفتار طبیعی انسان و محیط جور درمی‌آید.

و پرسش‌هایش مشخص است: آیا دست کاربر آزاد است؟ آیا تکلیف به دستکاری فضایی یا نگاشت طبیعی ربط دارد؟

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

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

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

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

و در همهٔ این‌ها باید تغییرپذیری را حساب کنید: اندازهٔ دست، نور، وضعیت بدن، و سرعت حرکت.

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

و یک نکتهٔ عملی هم دارد: خطای تشخیص در دو جهت اتفاق می‌افتد و هزینه‌شان یکی نیست.

منفی کاذب — یعنی حرکت انجام شد و سیستم نگرفت — کاربر را وامی‌دارد دوباره تلاش کند. آزاردهنده است و قابل‌جبران.

مثبت کاذب — یعنی حرکتی که کاربر انجام نداده ثبت شد — کاری را اجرا می‌کند که خواسته نشده. و اگر آن کار برگشت‌ناپذیر باشد، هزینه‌اش با قبلی قابل‌مقایسه نیست.

پس در تنظیم حساسیت، پیش‌فرض باید به سمت منفی کاذب بچربد، نه مثبت کاذب.

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

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

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

مسئلهٔ کشف‌پذیری

و اینجا مرکز ثقل کل بحث است. حرکت‌های پنهان یا مستندنشده — حتی ساده‌ترینشان — اغلب استفاده نمی‌شوند یا خیلی دیرتر برای کاربر آشکار می‌شوند.

و هفت راه‌حل شناخته‌شده دارد:

• - نشانهٔ دیداری یا بافتی که وجود حرکت را علامت دهد.
• - انیمیشن ظریفی که به حرکت دعوت کند.
• - آشناسازی تعاملی با نمایش کوتاه.
• - راهنمای بافتی — مثل «برای حذف بکشید» در اولین مواجهه.
• - آشکارسازی تدریجی، برای معرفی مرحله‌به‌مرحلهٔ حرکت‌ها.
• - یادآوری برای حرکت‌های کم‌استفاده.
• - و جفت‌کردن حرکت با یک عنصر دیدنی رابط.

و راه‌حل آخر مهم‌ترین است، چون بقیه آموزش می‌دهند و این یکی نیاز به آموزش را حذف می‌کند.

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

ده محدودیت

• - حرکت‌ها دیده نمی‌شوند و کاربر ممکن است کنش‌های مستندنشده را هرگز کشف نکند.
• - همین پنهانی، کشف‌پذیری و به‌خاطرسپاری را سخت می‌کند.
• - فعال‌شدن تصادفی، کاربر را کلافه می‌کند.
• - برای ناتوانی‌های حرکتی و شناختی مانع می‌سازد.
• - میان دستگاه‌ها و فرهنگ‌ها ناسازگار است.
• - خستگی فیزیکی می‌آورد، به‌ویژه در حرکت‌های هوایی و بزرگ.
• - معنای حرکت‌ها میان فرهنگ‌ها فرق می‌کند — نمونه‌اش شست بالا.
• - شلوغ‌کردن رابط با حرکت‌های زیاد.
• - نبودِ بازخورد دیداری یا پاسخ کند.
• - و حرکت‌های نااستاندارد که یادگیری زیادی می‌خواهند.

و برای جلوگیری از فعال‌شدن تصادفی، راه‌های مشخصی هست:

• - ناحیه‌های روشن تعریف کنید.
• - کنش عمدی بخواهید — فشار طولانی یا ضربهٔ دوتایی.
• - تأخیر تأییدکنندهٔ قصد بگذارید.
• - و حرکت‌های شبیه به هم را روی هم انباشته نکنید.

سه چیزی که پیش از افزودن هر حرکت باید پرسید

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

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

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

سه: «کاربر چطور می‌فهمد که کار کرد؟» بدون بازخورد، کاربر حرکت را دوباره انجام می‌دهد — و همین یکی از رایج‌ترین منشأهای کنش دوتایی ناخواسته است.

خستگی، که در آزمون کوتاه دیده نمی‌شود

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

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

و این به‌ویژه دربارهٔ حرکت هوایی صادق است، که بازو را بدون تکیه‌گاه بالا نگه می‌دارد. ولی در حرکت‌های صفحه‌ای هم هست: نیشگون مکرر، کشیدن‌های بلند، و رسیدن به گوشهٔ بالای صفحه با یک دست.

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

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

در بافت فارسی

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

و راه درستش این است که جهت را به جهت خواندن گره بزنید، نه به قرارداد جهانی. اگر متن از راست شروع می‌شود، «عقب» هم سمت راست است.

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

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

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

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

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

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

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

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

جمع‌بندی

• - تعامل مبتنی بر حرکت یعنی کنترل سیستم با حرکت فیزیکی به‌جای اتکای صرف به لمس و کلیک و صفحه‌کلید
• - لمس یعنی ضربه روی چیزی که دیده می‌شود · حرکت به آگاهی فضایی متکی است و افوردنس دیدنی ندارد
• - شش گام: فهم کاربر و بافت · انتخاب واژگان حرکتی · جورکردن حسگر با سخت‌افزار · بازخورد و افوردنس · آزمون با کاربر واقعی · و دسترس‌پذیری
• - برای تکلیف دقیق و ورود رمز و کنش حساس به حریم خصوصی، از حرکت استفاده نکنید
• - هفت راه برای کشف‌پذیری · و مهم‌ترینشان جفت‌کردن حرکت با یک عنصر دیدنی است، چون نیاز به آموزش را حذف می‌کند
• - حرکت باید میان‌بر باشد، نه در ورودی
• - ده محدودیت، از پنهانی و فعال‌شدن تصادفی تا خستگی فیزیکی و تفاوت فرهنگی
• - سه پرسش پیش از افزودن هر حرکت: اگر بلد نباشد چه از دست می‌دهد · اگر تصادفی اجرا شود چقدر بد است · و چطور می‌فهمد که کار کرد
• - و در فارسی: جهت را به جهت خواندن گره بزنید و با سیستم‌عامل تداخل نکنید · حرکت‌های «استاندارد» اینجا استاندارد نیستند · معنای فرهنگی را بررسی کنید · بازخورد را محلی و فوری بدهید · و ناحیه‌ها را بزرگ‌تر بگیرید