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

Ответ 1

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

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

Удачи!

Ответ 2

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

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

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

                                            (Cancel) (Search)

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

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

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

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

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

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

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

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

а. Форма всех полей с местом для ввода значений критерия для каждого поля. Проблема с этим - поля с заданными значениями могут прокручиваться вне поля зрения, и пользователи, возможно, забыли, что они установили значение. Таким образом, вы хотите сохранить это как можно более компактным. См. Главу "Улучшение поиска данных в Alan Coopers About Face 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 июля) и Query by Example.

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

мои мысли:

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

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

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

Ответ 10

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

Ответ 11

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

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

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

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

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

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

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

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

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

Ответ 12

Взгляните на айву, сайт infragistics ui patterns: http://quince.infragistics.com.

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

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

Ответ 13

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