Как Вы разработали бы хороший поисковый UI?

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

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

Всего наилучшего

Я склонен любить "список правил" подход. Вы знаете тот:

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

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

                                            (Cancel) (Search)

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

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

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

Что касается усовершенствованных средств управления, не зная точно, какие данные необходимо показать, я могу только дать обзор потенциальных организационных методов. Лично, мне нравится ФИКСАТОР:

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

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

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

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

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

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

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

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

А простая поисковая панель как простой поиск Google’s может быть на странице Results с тех пор it’s компактна. Это позволяет пользователю повторять поиск с различными критериями без напрасно тратящего время, идя в новую страницу или окно. Расширенный поиск намного больше создает помехи так there’s более важному компромиссу между легким доступом к результатам (в меньшей области) и легким доступом к исследованию, таким образом, необходимо оценить пользователей частоты, исследующих по сравнению с работой, они делают с результатами. Например, если исследование происходит, 50% времени, но включая панель Advanced Search на странице Results требуют дополнительной прокрутки 75% времени, Ваши пользователи более обеспечены без панели Advanced Search на Результатах. Как правило Расширенный поиск не должен быть на странице Results, если задачей не является действительно исследование сокращения-и-попытки данных.

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

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

2) Вы думаете, что лучше позволить пользователю нажать 'усовершенствованный' для большего количества критериев?

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

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

, Если существуют определенные критерии, которые используются особенно часто, тогда they’re обработанный посредством Простого поиска, как описано для 2, таким образом, there’s мало преимущества для критериев сортировки в Расширенном поиске частотой. Это просто мешает пользователям находить критерий they’re поиском. Обычно можно полагаться на пользователей, имеющих определенное именованное поле в виду, так отсортировать критерий в алфавитном порядке, или, если пользователи знакомы со Страницей Результатов, и ее поля размечаются способом, согласовывающимся с тем, как пользователи думают, используйте тот же порядок, как используется для столбцов Results.

4), Куда я должен поместить кнопку 'Search'?

Кнопка поиска идеально должна всегда быть видима. Лучшее решение состоит в том, чтобы иметь все критерии на области с возможностью прокрутки с кнопкой вне области. Помещение кнопки наверху и нижней части является общей, но kludgey альтернативой. Я wouldn’t помещают его по общим критериям потому что, если Ваши пользователи пошли от Основного до Расширенного поиска, they’re, вероятно, не использование общих критериев. Рассмотрите никакой Кнопка поиска, если можно сохранить время отклика, менее чем 500 мс, вместо этого обеспечивая момент - применяются как замеченный в Vista.

5), Как разработать хороший поисковый UI?

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

a. Форма всех полей с местом для ввода значений критерия для каждого поля. Проблемой с этим являются поля с установленными значениями, может прокрутить из представления, и пользователи, возможно, забыли, что they’ve устанавливают значение. Таким образом Вы хотите сохранить это максимально компактным. См., что глава Улучшает Поиск данных в Alan Cooper’s О Поверхности 2.0 для одного подхода. Можно также обеспечить сводную строку выбранных критериев около Кнопок поиска, которые может проверить пользователь. При нажатии на каждого критерии в строке могут даже перейти пользователь к критериям изменения его.

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

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

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

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

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

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

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

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

Смотрите на айву, infragistics ui сайт шаблонов: http://quince.infragistics.com .

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

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

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

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

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

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

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

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

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

"4) , Куда я должен поместить кнопку 'Search'? рядом с более общими поисковыми средствами управления, или внизу, или оба? "

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

мои мысли:

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

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

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