2009-02-28 3 views
21

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

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

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

результат представляет собой набор данных, который я Displ в сетке.

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

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

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

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

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

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

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

ответ

4

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

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

0

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

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

0

мои мысли:

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

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

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

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

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

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

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

              (Cancel) (Search) 

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

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

+0

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

+0

Если кнопка поиска не находится слева от кнопки «Отмена»? –

+2

Greg D: Это будет полностью зависеть от платформы, которую вы используете, не так ли? –

13

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

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

Удачи!

5

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

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

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

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

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

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

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

3

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

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

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

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

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

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

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

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

4) Где я должен положить кнопку «Поиск»?

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

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

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

а. Форма всех полей с местом для ввода значений критерия для каждого поля. Проблема с этим - поля с заданными значениями могут прокручиваться вне поля зрения, и пользователи, возможно, забыли, что они установили значение. Таким образом, вы хотите сохранить это как можно более компактным. См. Главу «Улучшение сбора данных в Alan Cooper's Face» 2.0 для одного подхода. Вы также можете предоставить сводную строку выбранных критериев рядом с кнопками поиска, которые пользователь может проверить. Щелчок по каждому критерию в строке может даже подтолкнуть пользователя к критериям его изменения.

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

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

1

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

0

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

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

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

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

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

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

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

«4) Где я должен поставить кнопку„Поиск“? Рядом с более общих элементов управления поиска, или в нижней части, или оба?»

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

0

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

1

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

Смежные вопросы