طراحی وب

طراحی Tooltip و Popover مؤثر

تفاوت Tooltip غیرتعاملی و Popover، رفتار hover و Focus و لمس، شرط‌های WCAG و نمونه مستقل Popover با fallback ثابت.

1404/12/14 2 دقیقه مطالعه 1,653 بازدید

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

Tooltip معمولاً یک توضیح غیرتعاملی درباره کنترل است و با hover یا Focus ظاهر می‌شود. Popover می‌تواند با عمل صریح باز شود و محتوای بیش‌تری داشته باشد. این دو قرارداد یکسان ندارند. قرار دادن لینک یا فیلد در چیزی که tooltip نامیده شده، نیاز به حرکت Focus و تعامل ایجاد می‌کند و از الگوی ساده توضیح فاصله می‌گیرد.

اطلاعات لازم را قبل از انتخاب الگو بشناسید

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

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

اگر کنترل اصلی نام روشنی ندارد، Tooltip را جایگزین نام نکنید. آیکون مبهم با توضیح پنهان، برای کاربر لمس قابل حدس نیست. نام قابل دسترس و در صورت نیاز متن دیداری باید خود عمل را معرفی کنند. توضیح تکمیلی می‌تواند جزئیات بدهد، اما نباید تنها راه فهم «حذف» یا «ارسال» باشد.

Tooltip به رفتار Focus و pointer نیاز دارد

الگوی Tooltip در WAI-ARIA APG آن را توضیحی معرفی می‌کند که Focus نمی‌گیرد و کنترل آغازکننده با aria-describedby به آن مرتبط است. خود tooltip جای دکمه و لینک نیست. این راهنما درباره الگوی در حال کار هم توضیح دارد؛ استفاده از نام role به تنهایی implementation کامل آن را ایجاد نمی‌کند.

وقتی Tooltip با Focus نمایش داده می‌شود، Focus باید روی کنترل اصلی بماند. کلید Escape باید راه بستن مناسب بدهد و بسته شدن نباید کنترل را غیرقابل استفاده کند. اگر pointer روی خود محتوا می‌رود، ناپدید شدن فوری می‌تواند خواندن را قطع کند. باید محدوده آغازکننده و محتوا را به عنوان یک تعامل مرتبط مدیریت کنید، نه دو ناحیه بی‌ارتباط.

Content on Hover or Focus در WCAG شرط‌های dismissible، hoverable و persistent را با استثناهای مشخص توضیح می‌دهد. تأخیر ۳۰۰ میلی‌ثانیه یک الزام عمومی این معیار نیست. می‌توانید برای جلوگیری از بازشدن تصادفی تأخیر متناسب انتخاب کنید، ولی آن را با زمان لازم خواندن و رفتار دستگاه‌های هدف بررسی کنید.

در لمس، توضیح باید مسیر صریح داشته باشد

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

روی دستگاه دارای Keyboard و pointer هم ممکن است دو علت نمایش هم‌زمان وجود داشته باشد. خروج pointer نباید محتوایی را که به دلیل Focus لازم است بی‌توضیح ببندد. بعد از Escape نیز نمایش فوری دوباره روی همان Focus می‌تواند بستن را بی‌اثر کند. این حالت‌ها باید در قرارداد component نوشته شوند؛ چند event ساده بدون مدیریت state ممکن است با هم رقابت کنند.

اگر component library استفاده می‌کنید، رفتار واقعی نسخه انتخاب‌شده را بخوانید. نام Tooltip در کتابخانه تضمین نمی‌کند تمام قراردادهای مناسب محصول شما رعایت شده‌اند. محتوا، دستگاه و محل قرارگیری را هم باید بررسی کنید. یک wrapper با aria-describedby اشتباه یا شناسه تکراری می‌تواند حتی روی پایه خوب، ارتباط نامعتبر بسازد.

Popover API رفتار پایه می‌دهد، نه معنی کامل

راهنمای Popover API در MDN روش اعلامی popover و popovertarget را شرح می‌دهد. حالت auto امکان light dismiss و بستن با Escape را فراهم می‌کند و محتوا را در top layer قرار می‌دهد. این رفتار به معنی Modal بودن نیست. اگر کار واقعاً به Dialog محدود و متمرکز نیاز دارد، الگوی مناسب آن را جدا انتخاب کنید.

Top layer از برخی مشکلات stacking جلوگیری می‌کند، اما موقعیت مناسب کنار آغازکننده را خودکار برای هر طراحی حل نمی‌کند. قرارگیری، فاصله از لبه و اندازه محتوا هنوز تصمیم layout هستند. برای Anchor Positioning یا ویژگی‌های تازه‌تر، سازگاری مرورگرهای هدف را از مستندات جاری بررسی کنید. نمونه این مقاله عمداً پنل مرکزی ساده دارد و ادعای جایگذاری هوشمند کنار هر عنصر ندارد.

رابط اعلامی میان دکمه و Popover به رفتار Keyboard و ارتباط برنامه‌ای کمک می‌کند. با این حال، عنوان، نوع محتوای پنل و نام دکمه همچنان باید درست باشند. یک Popover حامل منو با یک پنل توضیح فرق دارد. نقش menu را صرفاً به دلیل وجود چند لینک اضافه نکنید؛ menu قرارداد Keyboard خاصی دارد که ممکن است برای navigation معمولی مناسب نباشد.

نمونه کامل پنل توضیح با fallback ثابت

فایل زیر را با نام index.html ذخیره و در مرورگر باز کنید. HTML و CSS در همان فایل‌اند و dependency یا تصویر لازم ندارد. در مرورگر دارای پشتیبانی Popover، دکمه پنل توضیح را باز می‌کند. در محیطی که ویژگی را نمی‌شناسد، توضیح به صورت محتوای ثابت باقی می‌ماند و کنترل‌های بی‌اثر نمایش داده نمی‌شوند. این fallback برای اطلاعات کمکی انتخاب شده است.

<!doctype html>
<html lang="fa" dir="rtl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>توضیح اختیاری با Popover</title>
  <style>
    * { box-sizing:border-box; }
    body { margin:0; color:#17212b; background:#f4f6f9; font:1rem/1.9 system-ui,sans-serif; }
    main { max-inline-size:42rem; padding:2rem 1rem; margin-inline:auto; }
    button { font:inherit; padding:.4rem .8rem; background:#164ca4; color:#fff; border:0; border-radius:.3rem; }
    :focus-visible { outline:3px solid #164ca4; outline-offset:4px; }
    [popover] { max-inline-size:32rem; padding:1.5rem; border:1px solid #617083; border-radius:.6rem; background:#fff; color:#17212b; }
    .popover-control { display:none; }
    @supports selector(:popover-open) {
      .popover-control { display:inline-flex; }
      [popover] { inline-size:min(32rem,calc(100vw - 2rem)); max-block-size:calc(100dvh - 2rem); overflow:auto; box-shadow:0 .5rem 2rem #17212b33; }
    }
  </style>
</head>
<body>
  <main>
    <h1>دوره گزارش</h1>
    <p>تاریخ‌ها بر اساس منطقه زمانی انتخاب‌شده در حساب محاسبه می‌شوند.</p>
    <button class="popover-control" type="button" popovertarget="period-help">توضیح محاسبه دوره</button>
    <section id="period-help" popover="auto" aria-labelledby="help-title">
      <h2 id="help-title">محاسبه دوره گزارش</h2>
      <p>این محتوای آموزشی است. برای یک گزارش واقعی، تعریف زمان شروع و پایان را از قرارداد همان محصول بگیرید.</p>
      <p>اطلاعات ضروری در متن اصلی باقی می‌مانند؛ این پنل فقط توضیح تکمیلی دارد.</p>
      <button class="popover-control" type="button" popovertarget="period-help" popovertargetaction="hide">بستن توضیح</button>
    </section>
  </main>
</body>
</html>

در نمونه، دکمه باز کردن نام مشخص دارد و پنل دارای عنوان است. دکمه بستن به همان مقصد با popovertargetaction وصل شده است. aria-expanded دستی اضافه نشده تا مقدار ثابتی با رفتار واقعی ناسازگار نشود. محتوای پنل توضیحی است و هیچ فرم یا عملیات حساس ندارد؛ بنابراین نمونه نیاز به مدیریت تعاملی پیچیده‌تری را پنهان نمی‌کند.

Feature query در CSS فقط برای نمایش کنترل‌های مربوط استفاده می‌شود. در مرورگر قدیمی، توضیح حذف نمی‌شود. اگر تصمیم دارید fallback تعاملی با JavaScript بسازید، باید بستن، Focus و وضعیت باز را کامل تعریف کنید. نشان دادن دکمه‌ای که در بعضی مرورگرها کاری نمی‌کند، جایگزین مناسبی برای progressive enhancement نیست.

اندازه و محل باید خواندن را حفظ کنند

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

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

رنگ متن و سطح پنل باید خوانا باشند. سایه صرفاً نشانه عمق است و جای Contrast متن یا مرز لازم را نمی‌گیرد. animation ورود، اگر اضافه می‌شود، کوتاه و قابل کاهش باشد. مقاله Dark Mode برای نقش رنگی و Visual Hierarchy برای وزن پنل در صفحه ادامه‌های مرتبط‌اند.

محتوا و نگهداری component را تعریف کنید

برای نویسنده محتوا، محدوده Tooltip و Popover را بنویسید. Tooltip نباید پس از چند ویرایش به مقاله‌ای با لینک و شرط مهم تبدیل شود. اگر محتوا رشد کرده، نوع الگو را دوباره بررسی کنید. مقاله UX Writing به نام کنترل و توضیح کوتاه کمک می‌کند. تصمیم درباره نوع محتوا باید همراه تغییر متن حفظ شود.

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

واکنش به این مقاله

اشتراک‌گذاری این مقاله:
دیدگاه‌ها 0
۰ / ۲۰۰۰

هنوز دیدگاهی ثبت نشده

اولین نفری باشید که نظر می‌دهد!