Как бы вы разработали хороший интерфейс поиска?

Я хочу предоставить своим пользователям «продвинутую» поисковую систему. У меня в основном есть много критериев поиска, из которых можно выбрать:

  • некоторые из них очень простые / распространенные и будут широко использоваться (например, период времени, идентификатор элемента)
  • некоторые менее популярны
  • а некоторые будут использоваться нечасто, но я все же хочу их предоставить

В целом у меня есть около 30+ критериев на выбор

Результатом является набор данных, который я отображаю в сетке.

Я ищу вдохновение в Интернете, и даже в Google , похоже, нет хорошего решения для расширенного поиска.

Раньше я разрабатывал такие инструменты, и результат меня не особо удовлетворил, хотя в конечном итоге пользователь смог использовать их достаточно эффективно.

  • Как вы думаете, панель поиска должна быть видна все время (т.е. отображаться поверх моей сетки результатов) или быть доступной в отдельной форме (что позволило бы мне использовать больше места для всех элементов управления)

  • Как вы думаете, лучше отобразить все критерии поиска или позволить пользователю щелкнуть «дополнительно», если он хочет увидеть / использовать больше критериев

  • Как бы вы организовали критерии? по частоте использования, а точнее по области (т. е. критерии, связанные с пользователем, местоположением, временем и т. д.)

  • Где мне разместить кнопку «Поиск»? рядом с наиболее распространенными элементами управления поиском, или внизу, или и тем, и другим?

И в более общем плане, есть ли у вас советы, которыми вы хотите поделиться, как создать красивый пользовательский интерфейс поиска? Каких функций вы обычно упускаете в таких «продвинутых» поисковых системах?

Ответов (13)

  • На каждой странице сайта должно быть текстовое поле для поиска как часть шапки мачты.
  • Я предпочитаю, чтобы кнопка была помечена как «найти», а не «поиск», потому что преимущества всегда более убедительны, чем функции.
  • Изощренным должен быть алгоритм поиска, а не графический интерфейс.

Постарайтесь сделать интерфейс максимально простым. Большинству пользователей потребуется только текстовое окно и кнопка поиска. Остальные параметры можно поместить в параметр расширенного поиска.

Эта настройка более удобна для новых пользователей, а также помогает экономить ресурсы, экономя более дорогие расширенные поисковые запросы для людей, которые действительно в них нуждаются.

мои мысли:

- Показывать расширенные критерии только при желании. Поиск - отличная вещь, когда он максимально упрощен для людей, пытающихся искать.

-Если есть какой-то очень большой набор критериев для расширенного поиска: не загромождайте им результаты. Сделайте так, чтобы для пользователя было очень легко и очевидно вернуться и изменить критерии, но не пытайтесь тратить место на результаты, сразу же снова давая им свои критерии.

-Сложно сказать об организации критериев, не зная всего этого. но как говорят / говорят другие: сделайте это просто! Возможно, вам не нужно показывать все сразу: позвольте мне расширить области, если мне нужно больше, скрыть то, что я не хочу использовать. а затем поместите кнопку поиска внизу. Но опять же, я не хочу пролистывать страницу случайных критериев только для того, чтобы найти эту кнопку.

Просто общий совет: будьте проще. Большой выбор сбивает пользователя с толку и увеличивает вероятность неиспользования определенной функциональности.

Попробуйте разные прототипы на пользователях, чтобы выяснить, какие варианты ценны, а какие нет.

Не эксперт по UI, но я видел много плохих UI.

  • Поцелуй - хорошее начало.
  • Сделайте это интуитивно понятным.
  • Продолжайте поиск как вверху, так и внизу. Мне не хотелось бы использовать что-то, что заставляет меня перемещаться вверх по странице для ввода (см. Документацию Flex, их управление разбивкой на страницы находится только вверху - жалкая боль, вы знаете, где).
  • Организация критериев должна быть двоякой:
    • базовые операторы (20%), которые 80% будут использовать аванс
    • динамически редактировать набор критериев, доступных в любое время.
  • Помогите пользователям начать работу с минимальным временем нарастания и позвольте им добавлять / удалять критерии по мере необходимости. Идея состоит в том, чтобы заставить его использовать то, что ему нужно, а не загромождать свои мысли или рабочий процесс яркостью вашего набора функций.
  • Как уже упоминали другие, и в настоящее время это тенденция к пользовательскому интерфейсу в целом, используйте элементы управления, которые скрыты до тех пор, пока пользователь явно не захочет расширенную / точную настройку (пользовательский интерфейс по требованию).
  • Хорошее практическое правило - на странице должно быть не более 5-7 функций.
  • Было бы замечательно, если бы вы могли расположить критерии таким образом, чтобы сделать из них историю, то есть пользователь может читать свой запрос, а ваши операторы извлекают из него какой-то смысл.
  • Я большой поклонник небольшого текста и простых для понимания значков, но такая настройка зависит от среды установки. Сможет ли ваш внук использовать эту могучую рабочую лошадку?
  • Хороший дизайн также требует, чтобы вы сделали свой пользовательский интерфейс доступным. Это крепкий орешек, и я понятия не имею, как вы это сделаете.

Удачи!

По умолчанию скрытые расширенные элементы управления. Ваш ввод для поиска и кнопка действия всегда должны быть видны и выделяться, независимо от того, видны ли ваши расширенные элементы управления. Убедитесь, что отображение / скрытие расширенных элементов управления не меняет расположение ни основного ввода, ни кнопки - они должны оставаться статическими, чтобы не затрагивать пространственную память пользователя.

Что касается расширенных элементов управления, я не знаю, какой именно тип данных вам нужно отображать, и могу лишь дать обзор потенциальных методов организации. Лично мне LATCH нравится:

  • Место нахождения
  • Алфавит
  • Время (временная шкала или хронология - подумайте об историческом музее)
  • Категория (думаю, универмаги)
  • Heirarchy (от самого большого до самого маленького, от самого светлого до самого темного и т. Д.)

В зависимости от ваших элементов управления, один из них будет иметь наибольший смысл. Организуйте соответственно. Если вы можете использовать ползунок или диапазон ввода (например, «самый светлый», «светлее» и т. Д.), А не список флажков / радиомодулей, это предпочтительнее, так как это уменьшает количество визуальных элементов на странице.

Забудьте о правиле «плюс / минус 7», которое было полностью вырвано из контекста людьми, которые на самом деле не читали исследование. Короче говоря, это применимо только к реакции человека на внешние раздражители, а не к параметрам, отображаемым на экране. Это не значит, что вы должны переборщить, но даже если у вас много вариантов, вы можете визуально настроить их. Беспорядок - это недостаток дизайна, а не информации.

Не забудьте использовать много пробелов и <label> элементов, чтобы дать каждому варианту целевой клик хорошего размера. Это особенно важно при работе с флажками или радио.

Убедитесь, что при возврате результатов есть четкий заголовок ( <h2> или <h3> обычно его достаточно), в котором повторяется запрос пользователя и сколько результатов было возвращено. Не забывайте о странице результатов 0! Если возможно, предложите несколько советов по расширению запроса.

Мне нравится подход «списка правил». Вы знаете одно:

Find items that match [ All |v] of these conditions:

[Name            |v]  [Contains   |v] [_____________] (-) (+)
[Start date      |v]  [Is before  |v] [_____________]     (+)

                                            (Cancel) (Search)

Благодаря этому диалог не становится слишком загроможденным, но при этом у пользователей есть все необходимые параметры.

Но это предполагает, что вам нужно что-то настолько продвинутое! Вы можете обнаружить, что подход со списком ключевых слов, составленный с умом, подойдет.

1) Как вы думаете, панель поиска должна отображаться поверх моей сетки результатов?

Простая панель поиска, такая как основной поиск Google, может находиться на странице результатов, поскольку она компактна. Это позволяет пользователю повторно попробовать поиск по другим критериям, не тратя время на переход к новой странице или окну. Расширенный поиск гораздо более загроможден, поэтому существует более важный компромисс между легким доступом к результатам (на меньшей панели) и легким доступом к повторному поиску, поэтому вам необходимо оценить частоту повторного поиска пользователями по сравнению с работой, которую они выполняют с полученные результаты. Например, если повторный поиск выполняется в 50% случаев, но включение панели расширенного поиска на страницу результатов требует дополнительной прокрутки в 75% случаев, вашим пользователям будет лучше без панели расширенного поиска в результатах. Как правило, расширенный поиск не должен отображаться на странице результатов, если только задача не заключается в пробном исследовании данных.

Другая проблема с панелью «Поиск» в верхней части результатов заключается в том, что делать, если результаты не соответствуют критериям (например, если пользователь изменяет критерий после отображения результатов, но до повторного нажатия «Поиск»). С расширенным поиском пользователям намного проще забыть или пропустить, изменили ли они критерий или нет, а затем запутаться в том, какие критерии действуют для результатов. Размещение расширенного поиска на отдельной странице предотвращает это, хотя есть другие способы избежать этой проблемы, если расширенный поиск находится на странице результатов (например, с помощью мгновенного применения «фасетного» поиска).

В любом случае на странице результатов должны отображаться критерии, использованные при поиске.

2) Считаете ли вы, что лучше разрешить пользователю нажимать «расширенный» для получения дополнительных критериев?

Для большинства приложений баз данных у пользователей определенной группы (например, должности) есть от 2 до 5 определенных наборов критериев поиска, которые позволяют им выполнять большую часть своей работы (например, поиск заказов, сделанных между двумя указанными пользователем датами) , иногда включая критерии, которые даже имеют определенные значения критерия (например, поиск всех заказов со статусом ожидания). В этой ситуации пользователи будут быстрее всех и с меньшей вероятностью будут сбиты с толку, если у вас есть кнопка Advanced для специального поиска, в то время как поиск по умолчанию имеет элементы управления, адаптированные для этих конкретных поисков. По умолчанию используется расширенный поиск, только если ваши пользователи в основном будут проводить предварительный специальный поиск.

3) Как бы вы организовали критерии?

Если есть определенные критерии, которые используются особенно часто, то они обрабатываются с помощью базового поиска, как описано для пункта 2, поэтому преимущества сортировки критериев в расширенном поиске по частоте мало. Это просто мешает пользователям найти критерий, который они ищут. Как правило, вы можете полагаться на пользователей, имеющих в виду конкретное именованное поле, поэтому отсортируйте критерий в алфавитном порядке или, если пользователи знакомы со страницей результатов и ее поля расположены в соответствии с тем, как думают пользователи, используйте тот же порядок как используется для столбцов результатов.

4) Где мне поставить кнопку «Поиск»?

В идеале кнопка поиска всегда должна быть видна. Лучшее решение - разместить все критерии на прокручиваемой панели с кнопкой за пределами панели. Размещение кнопки вверху и внизу - распространенная, но неудобная альтернатива. Я бы не стал относить это к общим критериям, потому что, если ваши пользователи перешли с базового поиска на расширенный, они, вероятно, не используют общие критерии. Считайте отсутствие кнопки поиска, если вы можете сохранить время отклика менее 500 мс, вместо этого обеспечивая мгновенное применение, как это было в Vista.

5) Как создать красивый интерфейс поиска?

Для полевого многокритериального поиска существует два основных дизайна:

а. Форма всех полей с местом для ввода значений критериев для каждого поля. Проблема заключается в том, что поля с установленными значениями могут прокручиваться вне поля зрения, и пользователи могут забыть, что они установили значение. Таким образом, вы хотите сохранить его как можно более компактным. См. Один из подходов в главе «Улучшение поиска данных» в книге Алана Купера About Face 2.0. Вы также можете предоставить сводную строку выбранных критериев рядом с кнопками поиска, которые пользователь может проверить. Щелкнув каждый критерий в строке, пользователь может даже перейти к критериям для его изменения.

б. Пользователь выбирает из списка полей те, которые будут использоваться в критериях, затем устанавливает значения критериев в консолидированном местоположении. Основная задача здесь - свести к минимуму количество «накладных» кликов при выборе поля. В идеале список полей всегда доступен, и один щелчок мыши выбирает поле, помещает его в консолидированное местоположение и помещает курсор в элемент управления значением, как показано на http://www.zuschlogin.com/content/blogimages/ 37 / FindAdvanced.gif , только для поиска, а не для поиска. (По произвольному соглашению «Найти» сильно отличается от «Поиска» для пользователей; Поиск выделяет элементы на текущей странице, соответствующие заданным критериям, в то время как Поиск извлекает элементы, соответствующие заданным критериям)

Обе эти схемы связывают критерий для каждого поля с помощью логического И и ограничены в соединениях между базовыми таблицами базы данных, но это, вероятно, удовлетворит почти всех ваших пользователей. Если задачи требуют более сложных объединений и логических комбинаций, изучите графические конструкции запросов (например, Badre AN, Catarci T, Massari A и Santucci G 1996. Сравнительная простота использования диаграммного языка и языка запросов с иконками. В Дж. Кеннеди & P Barclay (Eds) Интерфейсы к базам данных (IDS-3): материалы 3-го Международного семинара по интерфейсам к базам данных, Университет Напьера, Эдинбург, 8-10 июля) и проекты запросов по примерам.

Найдите мои ответы (обычным текстом) на каждый из заданных вопросов (курсивом).

«1) Как вы думаете, панель поиска должна быть видна все время (т.е. отображаться поверх моей таблицы результатов) или быть доступной в отдельной форме (что позволило бы мне использовать больше места для всех элементов управления) »

Отображать поверх сетки результатов, поскольку при этом остается дополнительное горизонтальное пространство для отображения результатов поиска и, таким образом, для отображения большего количества столбцов данных поиска без горизонтальной прокрутки.

«2) Считаете ли вы, что лучше отобразить все критерии поиска или позволить пользователю щелкнуть« дополнительно », если он хочет увидеть / использовать больше критериев »

Отображать все доступные критерии, но в виде вкладок. т.е. разделить поля поиска ввода по категориям и иметь вкладку для каждой категории.

«3) Как бы вы организовали критерии? По частоте использования или, скорее, по области (т. Е. Критерии, связанные с пользователем, местоположением, временем и т. Д.) »

Организуйте «по областям», потому что разным людям нравится использовать разные критерии. У каждого критерия будет своя вкладка. Но, как вы думаете, расположите вкладки в порядке от «более популярных» к «менее популярным». В вашем случае вкладки могут быть «По имени» (содержащие поля имя, отчество, фамилия, девичья фамилия, псевдоним, имя отца и т. Д.), «По местоположению» (название места, название округа, название района, название штата. , название страны и т. д.) и так далее, пока не появится вкладка «Дополнительно» (где вы поместите наименее используемые поля).

«4) Где мне разместить кнопку« Поиск »? Рядом с наиболее распространенными элементами управления поиском, внизу или и там, и там? »

Поместите поля ввода для поиска, как описано выше, в виде вкладок, классифицируя их на основе «типа поля» (я буду называть эту область сеткой поиска). Затем поместите кнопки действий, такие как «Поиск», «Очистить / Сброс», чуть ниже сетки поиска, выровняв ее по центру (я буду называть эту область сеткой кнопок). Затем поместите панель результатов поиска под сеткой кнопок как более горизонтальную. область доступна для отображения, поэтому одновременно может отображаться максимальное количество столбцов.

Взгляните на айву, сайт шаблонов пользовательского интерфейса для инфраструктуры: http://quince.infragistics.com .

Лично я бы посмотрел на использование фильтруемой сетки, такой как xtragrid от DevExpress: http://www.devexpress.com/Products/NET/Controls/WinForms/Grid/datafiltering.xml

вместе с панелью поиска над ним для первоначального заполнения сетки.

Шаблон проектирования по умолчанию, который я использую, - это таблица фильтров . Это покрывает примерно 90% случаев использования. Для более сложных поисков мне потребуется более конкретная информация о целях и вариантах использования пользователей, чтобы можно было разработать более оптимальное решение для таких ситуаций.

Не думайте, что об этом еще упоминалось, но не забывайте, что вам также нужно будет инициировать поиск, когда пользователь нажимает клавишу ввода в любом из полей поиска. Наверное, об этом уже известно, но все равно стоит упомянуть.

Просто хорошо. Я бы порекомендовал итеративный подход, при котором вы медленно наращиваете функциональность после выполнения пользовательского приемочного тестирования и просмотра журналов, чтобы увидеть, какие функции они используют (или не используют). Единственный способ узнать, что нужно улучшить, - это наблюдать за своими пользователями.