Как создать удобный для пользователя фильтр - PullRequest
3 голосов
/ 12 ноября 2009

Наше приложение отображает тонны ценной информации для наших пользователей в виде таблицы. У нас есть возможность фильтрации, основанная на логических / логических поисках. Даже после коучинга пользователи все еще не понимают, как использовать фильтры, потому что AND OR>> = и т.д. им чужды. Этот фильтр прост для программистов, так как он легко переводится в код. Какие-нибудь примеры того, как это можно сделать более удобным и менее подверженным ошибкам?

Ответы [ 9 ]

2 голосов
/ 12 ноября 2009

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

Показать все книги, автором которых является [текстовое поле] и цена [меньше или больше] [текстовое поле]

[меньше / больше чем] это раскрывающийся список

[текстовое поле] - это поле ввода

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

Например: показать мне все книги, автор которых Стивен Кинг и цена на меньше 10 $

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

2 голосов
/ 12 ноября 2009

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

Этот подход напоминает пользователям Google. Все знают как гуглить.

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

1 голос
/ 12 ноября 2009

В веб-приложениях у telerik была хорошая идея с их сеткой , вы должны быть в состоянии сделать это и в настольных приложениях.

1 голос
/ 12 ноября 2009

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

Breed == "Spaniel" AND (Age == 2 OR Colour == "White")

Некоторые линейные построители запросов могут написать это:

 (  And/Or Field    Operator Value
[ ]        [Breed]  [=]      [Spaniel]
[1] [AND]  [Age]    [=]      [2]
[1] [OR]   [Colour] [=]      [White] 

Или иерархический может отображать это как:

AND
    [Breed] [Is Equal To] [Spaniel]
    OR
        [Age]    [Is Equal To] [Spaniel]
        [Colour] [Is Equal To] [White]

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

Мое решение больше похоже на:

Show ALL records where
    [Breed] [Is Equal To] [Spaniel]
    Show ANY records where
        [Age]    [Is Equal To] [Spaniel]
        [Colour] [Is Equal To] [White]

Итак, заимствуя из иерархического подхода, но меняя И и ИЛИ на ВСЕ или ЛЮБОЕ. Это означает, что его легче читать сверху вниз.

1 голос
/ 12 ноября 2009

По моему опыту, вы просто не хотите, чтобы конечные пользователи понимали разницу между условиями И и ИЛИ. Поэтому я строю свои фильтры так, чтобы были встроены ANDing или ORing. В общем, моя логика следующая:

  1. Критерии для разных полей объединяются для ограничения результатов.

  2. Множественные значения для одного и того же поля эффективно объединяются в единицу и затем помещаются в критерии для других полей. Обычно я обнаруживаю входные данные в одном поле списков, разделенных запятыми (переведенных в IN ()), диапазонов, разделенных тире (переведенных в BETWEEN), значений групповых символов (переведенных в LIKE) и любой комбинации (например, Customer ID: 1-10, 50, 52).

Я считаю, что большинство пользователей интуитивно понимают эту систему.

Конечно, время от времени требуется другой интерфейс с некоторой степенью ORing, и в этих случаях у меня обычно есть раздел пользовательского интерфейса поиска на панели или в групповой рамке с надписью «Любое из них является истинным».

1 голос
/ 12 ноября 2009

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

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

вы можете предоставить им вики-страницу с некоторыми примерами онлайн

вы можете дать им инструмент QBE

надеюсь, что это помогает удачи MikeD

0 голосов
/ 11 апреля 2010

Тереза ​​Нейл проиллюстрировала несколько подходов к построению сложных интерфейсов правил (оговорок AKA) в посте iTunes Решает вложенную статью Dillema . Там есть несколько хороших примеров. Мне действительно нравится, как Apple делает это в iTunes (хотя я не использую iTunes).

0 голосов
/ 12 ноября 2009

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

0 голосов
/ 12 ноября 2009

Я думаю, что встроенный интерфейс администратора Django имеет очень интуитивно понятный интерфейс для фильтров.

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

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

...