Про поиск
Без поиска никуда. Если вы делаете e-commerce-продукт, витрину, агрегатора — поиск нужен везде. И чем более опытная у вас целевая аудиторию, тем выше к нему требования.
Эта первая статья про поиск, и в прямом смысле про основы, базисы.
Начнем.
Сперва нужно разделить поиск, фильтрацию и сортировку на три отдельных сущности.
Поиск
Поиск чаще связан с ключевым запросом и приводит к созданию запроса на сервер с целью отдать значения с релевантными совпадениями. Итогом поиска является — SERP (Search Engine Result Page).
Фильтрация
SERP формируется через фильтрацию по заведомо определенным наборам характеристик — цвет, объем двигателя, коробка передач, количество комнат.
Фильтрация работает уже на этапе собранного SERP и позволяет вывести пользователю максимально релевантную информацию.
Сортировка
Сортировка же не является частью поискового процесса, а предоставляет пользователю удобную для него последовательности поисковых результатов.
Погнали делать поиск
Для начала нужно определиться — выводится ли пользователю полноценный SERP до поискового запроса (то есть все значения поиска в базе), либо только по итогу поискового запроса (SERP формируется по ключевому слову).
- SERP выводится сразу. В таком случае заранее стоит предусмотреть фильтрацию, которая поможет пользователю прийти к нужному результату по понятным и известным ему фильтрам
- SERP формируется по ключевому слову. Капитан очевидность говорит нам, что фильтрации до формирования SERP не нужна.
В каких случаях выбрать тот или иной способ.
- SERP выводится сразу. У вас небольшая база однотипных значений в рамках одного контекста/прикладной сферы/категории товаров (окна, колеса, планшеты)
- SERP формируется по ключевому слову. У вас огромная база разношерстных позиций. У вас нет возможности вычленить единые наборы характеристик. Ключевое действие (польза для клиента) не ясна даже вам.
Хочу заметить, что мы не говорим про списки категорий. При их наличии необходимость фильтрации очевидна.
Элементы поиска и фильтрации
Прежде чем собрать свою форму поиска, стоит определить набор базовых элементов, которые могут понадобиться для фильтрации.
Представленный набор не является каким-то каноническим и построен только на моих предпочтениях. Ибо я терпеть не могу всякий слайдеры-хуяйдеры и прочее.
Строка поиска
Чтобы сформировать поисковый запрос нужен, как это ни странно, способ указать этот поисковый запрос. И речь пойдет про строку поиска.
Строка поиска — один из старейших элементов веб-страниц, а некоторые компании и вовсе только с неё и начали. А в итоге многие годы только и говорят, купит ли одна другую.
Одно из важных правил строки поиска — не дать пользователю сформировать страшные и непонятные запросы. Сервер их не сожрет, результата не отдаст, и пользователь будет в печали.
Поэтому строка поиска и всё, что с ней связано должна всеми сила склонить пользователя указать то, что мы и правда можем найти.
Будет забавно, если кто-нибудь умудрится сделать сайт, где итогом пустой выдачи будет красная валидация строки поиски
Что же мы можем сделать для этого?
Placeholder
Placeholder — текстовый элемент внутри строки поиска, с помощью которого мы можем сообщить пользователю контекст, формат ввода и другие ограничения и подсказки.
Контекст
Если строка поиска узкоспециализированная — например, это поиск районов в городе Дубай (пример выше). Мы можем перечислить в строке некоторые настоящие запросы, которые дадут пользователю понимание того, что можно искать.
Перечисление конечных результатов поиска в более сложной базе — указать названия товаров.
Suggest в поле поиска
Как было написано выше, главное, к чему должна стремиться форма поиска — помочь пользователю указать релевантный запрос с максимальной пользой.
По мимо плейсхолдера, строка поиска в момент ввода должна сообщать пользователю о вариантах, при которых гарантировано будет положительный результат поиска.
Это крутая штука, которая помогает пользователю узнать о том, что есть в поиске, понять в каких категориях можно искать, обучает понятным системе типам запросов и тому подобное.
В то же время, это настолько сложный и непростой элемент, что требует и дополнительной разработки, да и дополнительной статьи.
Но если на ваши плечи упала такая задача — смотрите решение Amazon, которое просто космическое. Как и вообще поиск)
Строка поиска с мульти-выбором
В некоторых случаях пользователю нужно указать сразу несколько поисковых критериев, но их настолько много (подгружаются с сервера), что невозможно, либо неудобно использовать селекты.
Для этого можно использовать строку поиска с мульти-выбором. Многим известное решение по блогам и указанию тегов.
Раскрывающийся список (селект)
Когда у пользователя есть выбор из 3-х и более значений. Если есть необходимость ничего не выбирать — должно быть значение по умолчанию Any (любое).
Если же выбор этого значения обязателен для поиска — стоит в плейсхолдере указать призыв к действию. Например, “Выберите агенство”, как на примере выше.
Период, выборка значений
Для контекстно-связанных данных — период цены, размеров. В плейсхолдере должно быть указано значение «от» и «до».
Второй селект не должен давать выбирать значения меньше значений в первом. Не должно быть «От 1 000 000 до 1 000». Только если это не предусмотрено сценарием (хз каким это вообще может быть предусмотрено)
Сам размер селекта должен намекать на значения внутри. Нет смысла делать селект, если внутри значения представлены в виде “1, 2, 3” и так далее. В таких случаях либо стоит использовать Табы/триггепы (об этом позже), либо дописать названия значений в сам селект. Например: «1 спальня, 2 спальни, 3 спальни». И обратное — выбранное значение должно помещаться в селект на форме. Поэтому размер селекта должен определяться самым длинными значением в выборе.
Зависимые селекты
Селекты могут быть связаны, и значения во втором селекте ждут выбора в первом. Конечно же, их стоит сгруппировать уменьшенным отступом. И пока нет значения в первом, не давать выбирать значения во втором. Об этом можно намекнуть тем же плейсхолдером.
Табы/Триггеры
Стоит использовать в случае, если значений не больше 3–4, но никогда не использовать, если значений всегда два — вкл/выкл (чертова режимность поглотит вас).
Преимущества над селектами:
— заранее известны все значения для выбора
— выбор в один клик
Минусы:
— очень ограниченное количество значений
— ограниченная длина названия
Сгруппированный фильтр
Может потребоваться для передачи сложного значения на сервак.
Визуально оформлена, как связанная группа — отступ между фильтрами сильно меньше, чем между элементами формы.
Чекбокс
Самый низкоуровневый отбор, работает вкл/выкл и передает только одно значение.
Форма поиска
Сама форма поиска настолько контекстно-зависимая, что каких-то четких правил я для себя не вывел.
Если фильтров слишком дофига — есть смысл расположить их вертикально.
Взаимосвязанные фильтры стоит визуально объединить (сгруппировать).
Например, фильтр Price объединен не только горизонтально с целью показать связь, но и вертикально с выбором периода.
В зависимости от возможностей сервера и пряморукости команды разработки можно выбрать несколько способов отработки фильтров.
Если есть уверенность, а главное — результаты тестов на маломощных компьютерах (если такие могут оказаться у ЦА), что изменение фильтра приведет к мгновенному изменению SERP без перезагрузки страницы — вы можете убрать кнопку “Найти”.
Если же этого гарантировать никто не может — не стоит использовать автоматическое обновление поисковой выдачи. Каждое изменение фильтра приведет к задержке работы пользователя, что приведет и к негативному опыту.
Но в нашем случае кнопка находится за пределами Viewport’а, что совсем боль. Но можно использовать уже довольно устаревшее решение в виде предварительного подсчета результатов поиска.
При изменении фильтра мы подсчитываем предварительный результат и выводим рядом с фильтром пользователю сообщение, что будет найдено столько-то чего-то с кнопкой обновить SERP — обычно “Показать”.
Если же элементов поиска не так много, их можно разместить в горизонтальной форме над результатами поиска.
А вообще, как захотите, конечно.
Подтверждение поиска
Здесь всё очевидно. В случае если не используется фильтрация и каждый набор значений должен отправляться на сервер для вывода результатов самим пользователем — кнопка “Найти” должна быть последней на форме.
Если же речь идет про фильтрацию — способ был описан выше.
Если в форме есть строка с мульти-выбором, выбор значения в ней должен подтверждаться Enter. При этом, если курсор расположен в других элементах формы поиска — по Enter должна осуществляться отправка поискового запроса.
Тоже касается и фильтрации — Enter отправляет на сервак весь набор фильтров.
Приоритеты внутри формы
Вещь сложная, но как базис можно использовать просто правило — всё базовое, самое общее для пользователя идет первым в форме. Всё, что менее востребовано и то, что имеет сугубо индивидуальную значимость — после.
Например, практически всех интересует стоимость, возраст, район, марка автомобиля. Но значительно меньшую значимость имеют фильтры — можно ли курить в прокатной машине, есть ли детское кресло.
Но это базовое правило. В каждой отдельной форме поиска сценарий может быть иным.
Сортировка
Сортировка SERP не может привести к нулевой поисковой выдаче. Если же может — то вероятнее всего — это фильтр ^___^
Сортировка дает возможность пользователю настроить серп и показать результаты в том виде, который пользователю ближе и понятнее.
Сортировка может быть по цене (дешевле сверху, дороже сверху), по алфавиту (А-Я, Я-А)
Ну и пока всё
В другой раз, который вероятно никогда не наступит, расскажу, конечно же про нулевую выдачу и пустые экраны, про разницу между SERPом, который изначально известен и известен его набор фильтров, и про SERP, который формируется на основе поискового запроса, как и его набор фильтров.
Про страницы категорий, которые напрямую связаны с ключевыми словами. О том, как сформировать набор фильтров для морфологического поиска. Да и бог знает о чем я ещё могу рассказать.
Спасибо.
А вообще, смотрите, что делает Amazon и Яндекс.Маркет и не знайте проблем.
