Microinteraction یک رفتار کوچک با هدف مشخص در رابط است؛ مثلاً کاربر موردی را به علاقه‌مندی اضافه می‌کند و وضعیت دکمه تغییر می‌کند. این رفتار الزاماً انیمیشن نیست. متن، رنگ، صدا یا تغییر حالت کنترل می‌تواند بخشی از بازخورد باشد. ارزش آن وقتی معلوم است که کاربر نتیجهٔ عمل را بفهمد و بداند قدم بعدی چیست. صفت‌هایی مثل لذت‌بخش و شهودی، بدون توضیح رفتار و زمینه، معیار طراحی قابل استفاده‌ای نمی‌سازند.
در یک فهرست محصول فرضی، دکمهٔ علاقه‌مندی باید روشن کند مورد ذخیره شده یا هنوز درخواست در حال انجام است. اگر فقط یک قلب لحظه‌ای بزرگ شود و بعد به حالت قبلی برگردد، معنی موفقیت معلوم نیست. طراحی را از Stateها آغاز کنید: ذخیره‌نشده، در حال ارسال، ذخیره‌شده و خطا. سپس تصمیم بگیرید چه بازخوردی برای هر حالت لازم است. افزودن حرکت قبل از تعریف این حالت‌ها، ممکن است ابهام را زیباتر نمایش دهد.
عمل، وضعیت و بازخورد را کنار هم تعریف کنید
اول معلوم کنید محرک چیست. کلیک، ورود داده، دریافت پاسخ سرور یا گذشت زمان، رفتارهای متفاوتی ایجاد می‌کنند. بعد وضعیت را بنویسید و نتیجهٔ قابل مشاهده را تعیین کنید. برای دکمهٔ ذخیره، درخواست کاربر و تأیید سرور یک مرحله نیستند. اگر سرویس پاسخ نداده، نباید ظاهر موفقیت قطعی نشان داده شود، مگر محصول قرارداد مشخصی برای نمایش خوش‌بینانه و بازیابی داشته باشد. هر مسیر باید با معنای عملیاتی خودش هماهنگ بماند.
قواعد رفتار نیز باید پایدار باشند. اگر کلیک دوم ذخیره را لغو می‌کند، نام و وضعیت دکمه باید این امکان را توضیح دهند. اگر کاربر هنگام انتظار دوباره کلیک کند، باید معلوم باشد درخواست دوم رد، صف یا جایگزین می‌شود. این تصمیم‌ها از روی keyframes در CSS ساخته نمی‌شوند. یک جدول کوچک از حالت‌ها و رویدادها می‌تواند قبل از کد، اختلاف اعضای تیم را روشن کند و مانع رفتارهای تصادفی در پیاده‌سازی شود.
نمونهٔ مستقل تغییر علاقه‌مندی محلی
مثال زیر فقط یک حالت محلی را تغییر می‌دهد و ذخیرهٔ واقعی در حساب انجام نمی‌دهد. آن را با نام favorite-feedback.html ذخیره کنید و باز کنید. همهٔ HTML، CSS و JavaScript در همان فایل قرار دارند و به API، package، فونت خارجی یا تصویر نیاز ندارند. متن وضعیت این محدودیت را بیان می‌کند. نمونه برای فهم ارتباط عمل و بازخورد است؛ اگر بعداً به سرور وصل شد، حالت انتظار و خطا باید به آن افزوده شوند.
<!doctype html>
<html lang="fa" dir="rtl">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>بازخورد علاقه‌مندی</title>
<style>
body{font-family:system-ui;max-width:36rem;margin:2rem auto;padding:1rem;line-height:1.8}
button{font:inherit;padding:.7rem 1rem;border:1px solid #777;border-radius:8px;background:#fff;color:#222}
button[aria-pressed="true"]{background:#e0f3e6;color:#17482b;border-color:#17482b}
button:focus-visible{outline:3px solid #2447a8;outline-offset:3px}
</style>
<h1>یک مورد آموزشی</h1>
<button type="button" id="favorite" aria-pressed="false">افزودن به علاقه‌مندی</button>
<p id="favorite-status" role="status">این نمونه فقط حالت محلی دارد.</p>
<script>
const button = document.getElementById('favorite');
const status = document.getElementById('favorite-status');
button.addEventListener('click', () => {
const selected = button.getAttribute('aria-pressed') !== 'true';
button.setAttribute('aria-pressed', String(selected));
button.textContent = selected ? 'حذف از علاقه‌مندی' : 'افزودن به علاقه‌مندی';
status.textContent = selected ? 'در حالت محلی انتخاب شد؛ در حساب ذخیره نمی‌شود.' : 'انتخاب محلی حذف شد.';
});
</script>
</html>
دکمهٔ واقعی با id مشخص در HTML وجود دارد و JavaScript همان عنصر را انتخاب می‌کند. aria-pressed حالت toggle را اعلام می‌کند و متن دکمه نیز متناسب با آن عوض می‌شود. CSS بر اساس همین attribute ظاهر را تغییر می‌دهد؛ بنابراین یک State مرکزی برای معنی و نمایش وجود دارد. ناحیهٔ status پیام کوتاه متنی را نشان می‌دهد. هیچ موفقیت شبکه‌ای در کد نیست و نباید متن آن به «در حساب شما ذخیره شد» تغییر کند.
این مثال حرکت نمایشی ندارد، چون تغییر متن و حالت برای توضیح نتیجه کافی است. اگر transition رنگ اضافه شود، معنی رفتار نباید به دیدن آن transition وابسته باشد. کاربری که حرکت را نمی‌بیند یا دستگاه کندی دارد باید همچنان از متن و حالت دکمه نتیجه را بفهمد. این اصل، بازخورد را از جلوهٔ تزئینی جدا می‌کند. انتخاب حرکت باید کمک به خواندن وضعیت باشد، نه شرط فهم آن.
دسترس‌پذیری پیام وضعیت
توضیح W3C دربارهٔ Status Messages به اعلام بعضی تغییرهای وضعیت بدون جابه‌جایی focus می‌پردازد. در رابط، هر تغییر کوچک نباید focus کاربر را بدزدد. اگر بعد از ذخیره، focus از دکمه به پیام بپرد، ادامهٔ کار با صفحه‌کلید ممکن است سخت شود. پیام باید متناسب با اهمیت رخداد اعلام شود. استفادهٔ بی‌حساب از ناحیه‌های زنده نیز می‌تواند تجربه را پر از اطلاع‌رسانی مزاحم کند.
رنگ تنها مسیر انتقال معنی نباشد. سبز شدن یک کنترل بدون متن، برای همهٔ کاربران نشانهٔ روشنی از موفقیت نیست. برچسب ثابت یا متغیر مناسب، آیکون با معنی قابل فهم و وضعیت قابل دسترس می‌توانند کمک کنند. اما همهٔ آنها را بدون نیاز روی هر دکمه جمع نکنید. بازخورد باید به همان عمل پاسخ دهد. تکرار چند پیام مشابه پس از یک کلیک، اطلاعات تازه‌ای نمی‌دهد و ممکن است توجه را از ادامهٔ کار بگیرد.
حرکت را با دامنهٔ وظیفه هماهنگ کنید
جابه‌جایی کوچک برای نشان دادن رابطهٔ دو بخش می‌تواند مفید باشد؛ حرکت بزرگ تمام صفحه ممکن است خواندن را مختل کند. راهنمای Animation from Interactions در W3C دربارهٔ امکان غیرفعال کردن بعضی حرکت‌های ناشی از تعامل توضیح می‌دهد. نیاز کاهش حرکت باید در طراحی دیده شود. حذف حرکت نباید وضعیت را حذف کند؛ متن و ساختار باید مستقل از آن قابل فهم باقی بمانند.
مدت مناسب نیز یک عدد ثابت برای تمام رابط‌ها نیست. بازخورد کلیک کوتاه با نمایش روند عملیات طولانی یک نقش ندارد. اگر کاربر منتظر نتیجهٔ شبکه است، یک حرکت پایان‌یافته ممکن است تصور تمام شدن کار ایجاد کند. در این حالت، نام و وضعیت انتظار باید روشن بماند و مسیر خطا نیز تعریف شود. برای جلوهٔ تزئینی، کوتاهی و دامنهٔ محدود معمولاً مزاحمت کمتری ایجاد می‌کند، ولی نتیجه را باید با همان جریان واقعی مرور کرد.
Loading و Skeleton را به انتظار واقعی وصل کنید
Skeleton نشان می‌دهد محتوایی در راه است، اما نوع و زمان آن را تضمین نمی‌کند. اگر مدت طولانی باقی بماند و پیام یا اقدام بعدی نداشته باشد، کاربر نمی‌فهمد باید صبر کند یا دوباره تلاش کند. طراحی باید میان انتظار کوتاه و شکست دریافت تفاوت بگذارد. تغییر از Skeleton به محتوا نیز باید با چیدمان مورد انتظار هماهنگ باشد تا بخش‌های صفحه بی‌دلیل جابه‌جا نشوند. ظاهر انتظار، بخشی از قرارداد دادهٔ صفحه است.
برای عملیات حساس، غیرفعال کردن دکمه می‌تواند جلوی بعضی درخواست‌های تکراری را بگیرد، اما جای کنترل تکرار در سرور را نمی‌گیرد. شبکه ممکن است درخواست را دوباره برساند یا کاربر از مسیر دیگری اقدام کند. Microinteraction مسئول توضیح وضعیت است و منطق تجاری مسئول ثبت درست عملیات. این مرز در نمونهٔ علاقه‌مندی نیز مهم است؛ اگر ذخیره به حساب اضافه شد، پیاده‌سازی باید از محدودیت حالت محلی فراتر برود.
اعتبارسنجی فرم به لحن روشن نیاز دارد
خطای فرم باید مشکل و راه اصلاح را بگوید. لرزش فیلد بدون متن ممکن است فقط نشانهٔ نامعلومی از شکست باشد. اگر شمارهٔ تماس قالب خاصی می‌خواهد، مثال و توضیح مرتبط را کنار همان فیلد نشان دهید. نمایش خطا پیش از اینکه کاربر فرصت ورود داده داشته باشد نیز ممکن است حس بی‌دلیل اشتباه کردن ایجاد کند. زمان اعتبارسنجی را با نوع ورودی و اهمیت خطا انتخاب کنید، نه با یک الگوی ثابت برای تمام فیلدها.
پیام موفقیت نیز نباید پرحرف باشد. اگر داده ذخیره شده، همان نتیجه و در صورت نیاز مسیر ادامه کافی است. جملهٔ تبلیغاتی یا جشن بزرگ بعد از هر ذخیره ممکن است در استفادهٔ روزانه آزاردهنده شود. محصولی که کاربر بارها در آن داده ثبت می‌کند، نیاز متفاوتی از تجربهٔ اولین ورود دارد. بازخورد باید تکرار استفاده را تحمل کند. برای ادامهٔ همین موضوع، راهنمای اعلان‌های وب مرتبط است.
Library را پس از تعریف رفتار انتخاب کنید
CSS transitions برای بعضی تغییرهای ساده کافی است. اگر توالی یا کنترل پیچیده لازم باشد، ابزار دیگر قابل بررسی است، اما dependency تازه باید هدف مشخصی داشته باشد. انتخاب یک library فقط برای حرکت رنگ دکمه، ممکن است هزینهٔ اضافه‌ای ایجاد کند. قبل از نصب، رفتار را با جملهٔ کوتاه و حالت‌ها تعریف کنید. سپس ببینید کدام ابزار با ساختار فعلی پروژه سازگار است. نام مشهور ابزار، کیفیت قرارداد تعامل را تضمین نمی‌کند.
در بازبینی محصول، از کاربر بخواهید یک عمل را انجام دهد و نتیجه را توضیح دهد. اگر نمی‌داند چه اتفاقی افتاده، شکل جلوه را عوض کردن کافی نیست؛ معنی State یا پیام نیاز به اصلاح دارد. برای نمونهٔ حاضر، نتیجهٔ مورد انتظار فقط تغییر علاقه‌مندی محلی است. در محصول واقعی، رفتار انتظار، شکست و لغو را هم مرور کنید. ارزش Microinteraction با روشن شدن همین مسیرها دیده می‌شود، نه با تعداد انیمیشن‌هایی که به صفحه اضافه کرده‌اید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!