کاربر نام یک مقاله را کامل به یاد ندارد. چند کلمه وارد می‌کند، دسته‌ای را انتخاب می‌کند و با صفحه خالی روبه‌رو می‌شود. اکنون باید بفهمد عبارت نامناسب بوده، فیلتر زیادی محدود کرده یا جستجو هنوز تمام نشده است. طراحی Search و فیلتر از توضیح همین وضعیت‌ها شروع می‌شود. سرعت پاسخ مهم است، اما نتیجه سریع و مبهم هنوز کار پیدا کردن محتوا را دشوار می‌کند.
جستجو و فیلتر دو راه مکمل‌اند. جستجو به عبارت و قصد فرد تکیه می‌کند؛ فیلتر مجموعه را بر اساس ویژگی‌های مشخص محدود می‌کند. مخاطب ممکن است یکی را بدون دیگری استفاده کند یا هر دو را ترکیب کند. رابطه این دو باید در رابط قابل فهم باشد: چه عبارتی فعال است، چه محدودیت‌هایی اعمال شده و کدام تغییر باعث عوض شدن نتایج شده است.
دامنه جستجو را معلوم کنید
اگر کادر فقط در مقاله‌ها جستجو می‌کند، نام آن را «جستجو در مقاله‌ها» بگذارید. کادری با عنوان عمومی ممکن است انتظار جستجو در خدمات، حساب و فایل‌ها ایجاد کند. دامنه باید با ساختار محصول و محل کادر هماهنگ باشد. در پنل کاری، جستجوی پروژه جاری با جستجوی همه پروژه‌ها فرق دارد. توضیح کوچک و پایدار از placeholder مبهم بهتر است، چون پس از تایپ همچنان دیده می‌شود.
پیش از ساخت پیشنهادها، بدانید جستجو بر چه داده‌ای انجام می‌شود: عنوان، متن کامل، برچسب یا شناسه. نتیجه‌ای که از متن بدنه پیدا شده باید نشانه‌ای از ارتباط نشان دهد؛ نمایش تنها عنوان ممکن است برای فرد نامفهوم باشد. در محتوای محدود، جستجو نباید وجود رکوردهای خارج از دسترسی را ناخواسته فاش کند. تعداد و پیشنهادها هم بخشی از همین مرز دسترسی هستند.
فرم ساده می‌تواند نقطه شروع خوبی باشد
برای مجموعه کوچک، کادر دارای label، دکمه جستجو و یک فیلتر واضح اغلب از پیشنهادهای پیچیده قابل استفاده‌تر است. ارسال فرم با Enter باید همان رفتار دکمه را داشته باشد. اگر جستجو هنگام تایپ اجرا می‌شود، رفتار انتظار و زمان تغییر نتایج را طراحی کنید. تغییر دائم محتوا زیر دست کاربر بدون خبر روشن می‌تواند توجه و مسیر خواندن را به هم بزند.
نمونه زیر عمداً با ارسال فرم کار می‌کند. چهار مقاله آموزشی در داده محلی وجود دارد و جستجو عنوان‌ها را بررسی می‌کند. دسته، شرط دوم است و همراه عبارت اعمال می‌شود. این نمونه موتور جستجوی متن کامل، رتبه‌بندی حرفه‌ای یا اصلاح خودکار غلط املایی ندارد. محدود کردن دامنه مثال اجازه می‌دهد رفتار فرم، نتیجه خالی و بازنشانی را بدون وابستگی پنهان مشاهده کنید.
نمونه مستقل جستجو و دسته‌بندی
کد را در search.html با UTF-8 ذخیره و به صورت فایل HTML باز کنید. CSS و JavaScript داخل همان فایل هستند؛ API، تصویر یا بسته خارجی لازم نیست. نتایج به عنوان متن ساخته می‌شوند و لینک به مقاله‌های واقعی مجله دارند. دکمه «پاک کردن» هم عبارت و هم دسته را به حالت اولیه برمی‌گرداند و دوباره همه چهار نتیجه را نمایش می‌دهد.
<!doctype html>
<html lang="fa" dir="rtl"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>جستجوی مقاله‌ها</title>
<style>body{margin:0;font-family:Tahoma,Arial,sans-serif;line-height:1.9;background:#f3f5f8;color:#16233b}main{max-width:46rem;margin:auto;padding:2rem 1rem}form{display:flex;flex-wrap:wrap;gap:1rem;align-items:end}.field{display:grid;gap:.4rem}input,select,button{font:inherit;padding:.6rem;border:1px solid #76839a;border-radius:.35rem;max-width:100%;box-sizing:border-box}button{background:#183f78;color:white;cursor:pointer}:focus-visible{outline:3px solid #986000;outline-offset:3px}li{margin-block:.75rem}a{color:#163e78}#summary{min-height:2em}</style></head>
<body><main><h1>جستجو در مقاله‌ها</h1><form id="search-form"><div class="field"><label for="query">بخشی از عنوان</label><input id="query" name="query" type="search"></div><div class="field"><label for="category">موضوع</label><select id="category" name="category"><option value="all">همه موضوع‌ها</option><option value="ux">تجربه کاربری</option><option value="css">CSS</option></select></div><button type="submit">نمایش نتایج</button><button type="button" id="clear">پاک کردن</button></form>
<p id="summary" role="status" aria-atomic="true"></p><ul id="results" aria-label="نتایج مقاله‌ها"></ul></main>
<script>
const articles=[{title:'اصول طراحی Navigation و منوها',category:'ux',slug:'navigation-menu-design-principles'},{title:'طراحی صفحات خطا',category:'ux',slug:'error-page-design-keep-users'},{title:'طراحی نوتیفیکیشن و اعلان‌های وب',category:'ux',slug:'web-notification-alert-design'},{title:'طراحی واکنش‌گرا بدون Media Query',category:'css',slug:'responsive-design-without-media-queries'}];
const form=document.getElementById('search-form');
const query=document.getElementById('query');
const category=document.getElementById('category');
const results=document.getElementById('results');
const summary=document.getElementById('summary');
function normalize(value){return value.trim().replaceAll('ي','ی').replaceAll('ك','ک').toLocaleLowerCase();}
function render(){const phrase=normalize(query.value);const matches=articles.filter(article=>normalize(article.title).includes(phrase)&&(category.value==='all'||category.value===article.category));results.replaceChildren();for(const article of matches){const item=document.createElement('li');const link=document.createElement('a');link.textContent=article.title;link.href='https://tarahestan.com/magazine/'+article.slug;item.append(link);results.append(item);}summary.textContent=matches.length?matches.length+' مقاله پیدا شد.':'نتیجه‌ای پیدا نشد. عبارت یا موضوع را تغییر دهید.';}
form.addEventListener('submit',event=>{event.preventDefault();render();});
document.getElementById('clear').addEventListener('click',()=>{form.reset();render();query.focus();});
render();
</script></body></html>
در کد، تابع normalize فاصله‌های ابتدا و انتها را حذف و حروف عربی رایج را به معادل فارسی تبدیل می‌کند. این کار یک نمونه محدود از یکسان‌سازی است، نه پوشش کامل زبان فارسی. نیم‌فاصله، صورت‌های مختلف عدد و واژه‌های هم‌معنا تصمیم‌های جدا می‌خواهند. بهتر است این قواعد را بر داده واقعی تعریف کنید تا جستجو با تغییراتی که معنی را عوض می‌کنند نتیجه نامرتبط تولید نکند.
فیلترها را از ویژگی‌های قابل اعتماد انتخاب کنید
فیلتر خوب به ویژگی‌ای مربوط است که مخاطب برای انتخاب نیاز دارد و داده آن در مجموعه وجود دارد. افزودن فیلترهای زیاد بدون مقدارهای معتبر، فضای رابط را اشغال می‌کند و نتیجه را غیرقابل پیش‌بینی می‌سازد. برای فروشگاه، اندازه و موجودی ممکن است لازم باشد؛ برای مقاله، موضوع و نوع محتوا. دسته‌بندی سازمانی تیم لزوماً همان تقسیم‌بندی قابل فهم برای مخاطب نیست.
در چندانتخابی، مشخص کنید انتخاب‌ها با چه منطقی ترکیب می‌شوند. دو رنگ می‌توانند به معنی هرکدام از آن‌ها باشند، در حالی که رنگ و اندازه معمولاً دو محدودیت همزمان‌اند. متن رابط و شمارش نتایج باید این قرارداد را منعکس کند. راهنمای فیلتر محصولات درباره ترکیب ویژگی‌ها و نمایش محدودیت‌های فعال توضیح بیشتری دارد. از مخاطب انتظار نداشته باشید منطق شرط‌های داده را حدس بزند.
وضعیت فعال و مسیر پاک کردن را نشان دهید
بعد از اعمال فیلتر، انتخاب‌ها باید دیده شوند. در فرم کوتاه، مقدار خود کنترل کافی است؛ در پنل بزرگ می‌توان خلاصه‌ای از محدودیت‌ها نمایش داد. حذف یک مورد و پاک کردن همه، دو عمل متفاوت‌اند و باید برچسب جدا داشته باشند. اگر مرتب‌سازی هم فعال است، آن را با فیلتر یکی نکنید؛ ترتیب نتیجه مجموعه را محدود نمی‌کند و معمولاً قرارداد مستقل دارد.
در موبایل، بستن پنل فیلتر نباید انتخاب‌ها را بی‌خبر از بین ببرد. معلوم کنید تغییر فوراً اعمال می‌شود یا نیاز به دکمه «نمایش نتایج» دارد. حالت دوم اجازه می‌دهد چند انتخاب پیش از دریافت نتیجه انجام شوند؛ حالت اول بازخورد پیوسته‌تری دارد. انتخاب به هزینه درخواست و پیچیدگی کار مربوط است. در هر دو حالت، فرد باید بداند نتیجه جاری با کدام انتخاب‌ها ساخته شده است.
بی‌نتیجه بودن را از شکست جدا کنید
«نتیجه‌ای پیدا نشد» یعنی جستجو انجام شده و تطابقی نیست. «دریافت نتایج ناموفق بود» یعنی نمی‌توان درباره تطابق قضاوت کرد. نمایش این دو با یک صفحه خالی کاربر را به تغییر بی‌دلیل عبارت تشویق می‌کند. در خطا، عبارت و انتخاب‌ها را حفظ کنید و راه تلاش دوباره بدهید. در بی‌نتیجه، حذف یک محدودیت یا تغییر عبارت می‌تواند قدم بعدی مفیدی باشد.
پیشنهاد اصلاح نباید بی‌خبر جای عبارت اصلی را بگیرد. اگر جستجو با واژه دیگری انجام شده، آن را توضیح دهید و امکان بازگشت به عبارت فرد را بدهید. تعداد نتیجه نیز باید به مجموعه جاری مربوط باشد. شمارش تقریبی یا محدودیت صفحه‌بندی را، اگر در تصمیم اثر دارد، روشن کنید. عددی که با فهرست دیده‌شده تناقض ظاهری دارد بدون توضیح اعتماد به نتیجه را کم می‌کند.
پیشنهاد خودکار به رفتار کامل نیاز دارد
افزودن یک فهرست زیر کادر جستجو، به‌تنهایی Autocomplete قابل استفاده نمی‌سازد. حرکت با صفحه‌کلید، انتخاب، Escape، وضعیت باز بودن و ارتباط گزینه فعال با کادر باید تعریف شوند. الگوی Combobox در W3C قراردادهای تعاملی این نوع کنترل را توضیح می‌دهد. اگر این رفتارها را نیاز ندارید، فرم ساده می‌تواند انتخاب قابل نگهداری‌تری باشد.
پیشنهادها هم باید دامنه روشن داشته باشند: عبارت‌های جستجو هستند یا مقصدهای مستقیم؟ با انتخاب یک عنوان، آیا جستجو اجرا می‌شود یا صفحه باز می‌شود؟ ترکیب بی‌توضیح این دو رفتار باعث غافلگیری می‌شود. در صورت ثبت تاریخچه، کنترل حذف و محدودیت نگهداری را در نظر بگیرید. عبارت جستجو ممکن است اطلاعات شخصی داشته باشد و نباید بدون نیاز به ابزارهای عمومی تحلیل منتقل شود.
درخواست‌های همزمان را هماهنگ کنید
در جستجوی شبکه‌ای، پاسخ درخواست قدیمی ممکن است دیرتر از پاسخ تازه برسد. اگر بدون کنترل نمایش داده شود، عبارت جدید با نتیجه قبلی همراه می‌شود. لغو درخواست قبلی یا بررسی شناسه آخرین درخواست، راه‌های مدیریت این مسئله‌اند. AbortController یکی از ابزارهای لغو عملیات پشتیبانی‌شده را فراهم می‌کند. مدیریت ترتیب نتیجه همچنان باید در منطق برنامه روشن باشد.
Debounce تعداد درخواست‌ها را می‌تواند کم کند، ولی مشکل ترتیب پاسخ را به‌تنهایی حل نمی‌کند. حالت انتظار باید معلوم باشد و پیام موفقیت فقط برای نتیجه معتبر تازه نشان داده شود. اگر محتوای قبلی هنگام انتظار باقی می‌ماند، این وضعیت را طوری بیان کنید که فرد آن را نتیجه عبارت تازه نداند. برای درخواست ناموفق، کنترل‌ها را قابل استفاده نگه دارید و اطلاعات واردشده را بی‌دلیل پاک نکنید.
نتیجه را قابل خواندن و بازگشت نگه دارید
خلاصه تعداد نتایج در نمونه، ناحیه status دارد و بدون گرفتن focus به‌روزرسانی می‌شود. درباره این نوع خبر، راهنمای Status Messages توضیح دارد. اعلام کل فهرست بعد از هر تغییر معمولاً پرحرف‌تر از یک خلاصه مناسب است. خود نتایج باید heading، لینک و ترتیب واضح داشته باشند تا مخاطب بتواند آن‌ها را مرور کند.
در محصول واقعی، نگهداری عبارت و فیلترها در نشانی می‌تواند بازگشت، اشتراک‌گذاری و باز کردن نتیجه در تب تازه را آسان کند؛ داده حساس را از این مسیر جدا کنید. هنگام بازگشت از صفحه نتیجه، موقعیت و انتخاب‌های قبلی را تا حد مناسب حفظ کنید. جستجوی قابل اتکا حاصل رابطه روشن میان ورودی، محدودیت و نتیجه است؛ هیچ قابلیت موسوم به هوشمند این قرارداد را به‌تنهایی جایگزین نمی‌کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!