Carousel چند آیتم را در یک قاب نمایش می‌دهد و کاربر با کنترل‌های قبلی و بعدی میان آن‌ها حرکت می‌کند. این الگو وقتی مطرح می‌شود که فضای صفحه محدود است، اما همه محتواها هم‌زمان دیده نمی‌شوند. پیش از انتخاب آن، مشخص کنید آیتم پنهان‌شده چه اهمیتی دارد. اگر اطلاعیه ضروری، شرایط خرید یا اقدام اصلی فقط در اسلاید بعدی باشد، کاربر ممکن است بدون دیدنش تصمیم بگیرد. اهمیت محتوا باید در انتخاب الگو اثر داشته باشد.
عبارت «فقط یک درصد کاربران روی اسلایدهای بعدی کلیک می‌کنند» بدون مطالعه، نمونه و زمینه قابل استفاده برای همه سایت‌ها نیست. چنین عددی را به قانون طراحی تبدیل نکنید. تعداد کلیک به هدف، نوع Carousel، جایگاه و روش اندازه‌گیری بستگی دارد. یک گالری محصول با بنر تبلیغاتی صفحه اول رفتار یکسان ندارد. طراحی باید با فرضیه مشخص و داده همان محصول بررسی شود، نه با درصدی که از زمینه اصلی جدا شده است.
نیاز واقعی به قاب متحرک را مشخص کنید
فهرست آیتم‌ها را همراه کار کاربر بنویسید. اگر قرار است چند پیشنهاد مستقل مقایسه شوند، Grid ممکن است هم‌زمانی بهتری بدهد. اگر تصاویر یک محصول مرور می‌شوند، Carousel دستی می‌تواند زمینه مشترک را حفظ کند. برای مراحل آموزشی که ترتیب اهمیت دارد، شاید نمایش متوالی در صفحه خواناتر باشد. درخواست چند بخش سازمان برای حضور در Hero به خودی خود نیاز کاربر به Carousel را ثابت نمی‌کند؛ اولویت محتوا باید پیش از طراحی حل شود.
در مثال فرضی یک فروشگاه، سه پیام درباره ارسال، تخفیف و محصول تازه وجود دارد. شرط ارسال باید نزدیک تصمیم خرید هم دیده شود و نباید فقط در بنر چرخان باشد. تخفیف می‌تواند جای مشخص خود را داشته باشد و محصول تازه در فهرست نمایش داده شود. این بررسی ممکن است نیاز به Carousel را حذف کند. اگر الگو باقی ماند، نقش هر اسلاید و ترتیب آن را مشخص کنید تا چرخش قاب جای تصمیم درباره معماری محتوا را نگیرد.
کنترل را به کاربر بدهید
برای بسیاری از مجموعه‌ها، شروع با حالت دستی مسیر ساده‌تری برای کنترل فراهم می‌کند. کاربر زمان خواندن و تغییر را تعیین می‌کند. اگر Auto-play دلیل مشخص دارد، کنترل توقف و ادامه باید واضح باشد. پنهان کردن آن در Hover برای صفحه لمسی و برخی ابزارهای کمکی مناسب نیست. راهنمای Carousel در W3C دسترسی به محتوا و کنترل حرکت را بررسی می‌کند. حرکت پیوسته نباید کاربر را وادار کند برای خواندن متن با زمان‌بندی سیستم مسابقه بدهد.
در الگوی Carousel در APG، توقف چرخش هنگام ورود Focus و عدم شروع دوباره بدون درخواست صریح کاربر توضیح داده شده است. Hover نیز باید رفتار کنترل‌شده داشته باشد. تغییر اسلاید درست وقتی کاربر می‌خواهد لینک آن را فعال کند، مقصد نامطمئن می‌سازد. دکمه توقف باید نامی داشته باشد که عمل بعدی را روشن کند و پس از تغییر حالت، وضعیت واقعی سیستم را نشان دهد.
ترجیح کاهش حرکت را در طراحی در نظر بگیرید. کم کردن مدت Transition با حذف Auto-play یک کار نیست؛ هر کدام رفتار متفاوتی دارد. برای محتواهای حساس به زمان هم باید راه مشاهده بدون حرکت فراهم باشد. توقف پس از تعامل و حفظ آن تصمیم، از شروع دوباره ناگهانی هنگام خروج نشانگر قابل پیش‌بینی‌تر است. اگر حرکت برای فهم محتوا ضروری نیست، افکت پیچیده اطلاعاتی اضافه نمی‌کند و می‌تواند مرور را کندتر کند.
قبلی، بعدی و انتخاب مستقیم را روشن کنید
دکمه‌های قبلی و بعدی باید در جای پایدار و با Contrast کافی باشند. قرار دادن فلش سفید روی هر تصویر، خوانایی یکسانی ایجاد نمی‌کند. سطح جدا پشت کنترل یا جایگاه بیرون تصویر راه قابل پیش‌بینی‌تری است. آیکون تنها به نام قابل دسترس نیاز دارد. در RTL، جهت فلش و ترتیب آیتم باید هماهنگ باشند. عبارت «بعدی» به حرکت در مجموعه اشاره می‌کند؛ موقعیت راست یا چپ را بی‌بررسی از کتابخانه دیگری کپی نکنید.
نقطه‌های انتخاب اسلاید برای مجموعه کوچک می‌توانند مفید باشند، اما تعداد زیادشان مرور و حرکت Tab را طولانی می‌کند. اگر Thumbnail یا نام آیتم معنی بیشتری می‌دهد، آن را بررسی کنید. وضعیت جاری فقط با تفاوت رنگ اندک مشخص نشود. شمارنده تعداد و جایگاه را روشن می‌کند و در مجموعه طولانی به فهم محدودیت کمک می‌کند. اگر همه نقطه‌ها نام «انتخاب» دارند، کاربر ابزار کمکی نمی‌فهمد هر کدام به کدام اسلاید می‌رود.
محتوا را با همان قاب سازگار کنید
اسلایدها نباید برای خواندن زمان‌های بسیار متفاوت بخواهند، به‌ویژه اگر حرکت خودکار وجود دارد. یک تیتر کوتاه و یک پاراگراف بلند با زمان ثابت مشترک، تجربه نامتعادل می‌سازند. اطلاعات ضروری را کوتاه و با لینک جزئیات قابل پیش‌بینی ارائه کنید. CTA هر اسلاید باید به همان موضوع مربوط باشد. چند دکمه با متن کلی «بیشتر» در اسلایدهایی متفاوت، بدون زمینه روشن برای خواننده صفحه‌خوان مبهم هستند.
تصویر و متن باید با برش موبایل سازگار باشند. قرار گرفتن نوشته داخل خود تصویر، ترجمه و تغییر اندازه را سخت می‌کند. بهتر است اطلاعات مهم در متن HTML باقی بماند و تصویر نقش بصری خود را داشته باشد. ارتفاع قاب را از پیش تعیین کنید یا با ساختار محتوا کنترل کنید تا تعویض اسلاید صفحه را جابه‌جا نکند. مقاله گالری و Lightbox درباره تفکیک Thumbnail، نسخه بزرگ و زمینه محتوا توضیح دارد.
دسترسی‌پذیری از مدیریت Focus شروع می‌شود
کنترل‌ها باید با صفحه‌کلید قابل استفاده باشند و Focus هنگام تعویض اسلاید بی‌دلیل جابه‌جا نشود. کاربر باید بتواند چند بار دکمه بعدی را فعال کند، بدون اینکه هر بار دنبال دکمه بگردد. محتوای اسلاید مخفی نباید لینک‌های نامرئی در مسیر Tab باقی بگذارد. روش پنهان کردن باید با فناوری کمکی هماهنگ باشد. فقط انتقال آیتم به بیرون قاب با CSS کافی نیست اگر لینک‌ها همچنان قابل انتخاب و قابل خواندن باشند.
نام مجموعه و جایگاه اسلاید برای فهم زمینه کمک می‌کنند. اعلان تغییر باید متناسب باشد؛ خواندن پیوسته همه اسلایدهای خودکار می‌تواند مزاحم کار جاری شود. در حالت دستی، اطلاع کوتاه از تغییر ممکن است مفید باشد. نوع Semantics به ساختار واقعی بستگی دارد: استفاده از Tab نیازمند رفتار Tab است و نباید فقط برای ظاهر نقطه‌ها اضافه شود. مقاله دسترسی‌پذیری وب درباره فاصله میان ظاهر مناسب و تعامل قابل استفاده توضیح بیشتری دارد.
موبایل و عملکرد را در تصمیم وارد کنید
Swipe می‌تواند راه تکمیلی مرور باشد، اما کنترل دکمه‌ای را حذف نکند. حرکت افقی نباید با Scroll عمودی صفحه درگیر شود. اگر بخشی از آیتم بعدی برای نشان دادن ادامه مجموعه دیده می‌شود، این نشانه با فضای محتوای اصلی اشتباه نشود. در عرض کم، متن دکمه و اندازه قابل انتخاب آن حفظ شود. یک Carousel که فقط روی مانیتور بزرگ خوب دیده می‌شود، پاسخ مناسبی برای مخاطبی که بیشتر از تلفن استفاده می‌کند نیست.
همه تصاویر حجیم را صرفاً به دلیل حضور در مجموعه از ابتدا دانلود نکنید. تصویر نخست ممکن است در نمایش اولیه مهم باشد و آیتم‌های دورتر اولویت پایین‌تری داشته باشند. کتابخانه بزرگ برای سه کارت ساده هزینه نگهداری ایجاد می‌کند؛ با نیاز واقعی مقایسه کنید. در عین حال، ساخت کنترل سفارشی بدون پوشش Focus و حالت‌های پنهان هم انتخاب ارزانی نیست. تصمیم فنی باید اندازه، دسترسی‌پذیری، نیاز به نگهداری و رفتار محصول را با هم ببیند.
فرضیه را به معیار قابل تفسیر تبدیل کنید
اگر هدف کشف محصول است، کلیک روی فلش فقط استفاده از کنترل را نشان می‌دهد. مشاهده محصول، ورود به جزئیات و اقدام بعدی زمینه بیشتری دارند. تعریف View اسلاید هم باید روشن باشد؛ قرار گرفتن فایل در DOM با دیده شدن آن یکسان نیست. داده را برای دستگاه‌ها و جایگاه‌های مختلف تفکیک کنید، اما گروه‌های بسیار کوچک را با درصد قطعی گزارش نکنید. User Research برای فهم اینکه کاربر ادامه مجموعه را پیدا می‌کند یا نه مفید است.
برای تحویل، هدف هر اسلاید، حالت شروع، رفتار توقف، انتهای مجموعه و تعامل صفحه‌کلید را ثبت کنید. سپس مسئول محتوا بداند اضافه کردن یک بنر تازه چه محدودیت متن و تصویر دارد. تغییر تعداد آیتم‌ها می‌تواند کنترل مستقیم، زمان مرور و بارگذاری را عوض کند؛ این تغییر صرفاً بارگذاری یک عکس نیست. وقتی Carousel حفظ می‌شود، دلیل آن باید با کار کاربر توضیح داده شود و اطلاعات ضروری از وابستگی به دیدن یک اسلاید خاص آزاد بماند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!