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

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

Не эксперт по пользовательскому интерфейсу, но я видел много плохого пользовательского интерфейса.

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

Удачи!

Answer 2

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

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

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

                                            (Cancel) (Search)

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

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

Answer 3

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

Что касается расширенных элементов управления, не зная точно, какой тип данных вам нужно показать, я могу лишь дать обзор потенциальных методов организации. Лично мне нравится ЗАДВИЖКА:

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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

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

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

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

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

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

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