x
 
↑
Декабрь
21 •

10 •

8 •

11 •

5 •
↓
Алексей А. Евдокимов
10 декабря 2007

Здравствуйте, Артем.

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

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

Вдохновение при создании этого интерфейса мы черпали в редакторах поисковых условий из медиа-библиотеки Winamp 5, фильтров сортировщика писем TheBat! 3, и поиска тегов в MS Expression Web. Но получилось как-то не очень. Пользователи почему-то частенько не могут правильно задать условия, чтобы найти только договоры, заключенные ранее 1 октября, с Василием в контактных лицах, который платит за услуги любыми тремя из всех возможных способов, хотя нам это кажется тривиальным %)

Что ж с ним сделать, чтобы стало понятнее?

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

P. P. S. И как, по-вашему, выглядит весь остальной интерфейс? Сойдет для сельской местности? ;)

Даже для вашей модели поиска интерфейс выглядит слишком сложно.
Я предпочел бы принять решение уже после запуска. И почему элемент имеет гипертекстовый вид?
#&*@!!!

Воспринимается как заголовок к стоящему ниже списку, хотя в списке не только условия, но и формат результатов.

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

А это что за записки?
Лучше разбить на три отдельных строки (если множественный выбор вообще кому-то нужен).

Чекбоксы так использовать нельзя: без подписи и в качестве командной кнопки.

А если избавиться от списка слева, то не понадобится и вся колонка управляющих иконок.

Календарик хуже среднего, хотя можно лучше.

И тем не менее, я уверен, что любой документ можно найти в два шага: 1) ввод простого текстового запроса и 2) уточнение одного параметра в результатах с помощью фильтра. В качестве уточняющих фильтров пользователю лучше предлагать не все возможные поля договора, а наиболее значимые параметры, привязанные к специфике бизнеса. Отбирать такие фильтры мог бы аналитик при внедрении программы.

Поделиться
Отправить

Комментарии
Алексей Мельников
10 декабря 2007

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

К поиску в Windows прибегают только в самых крайних случаях, когда последняя надежда найти документ вручную пропала. А когда поиск выдает ноль документов, то всегда остается сомнение: наверное, он не во всех папках ищет или я какую-то галочку забыл поставить. Поиском в Маке пользуются все. Причем зачастую даже чаще, чем файндером. Потому что он реально удобнее и проще.

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

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

10 декабря 2007

Алексей!

Яндeкс, например, почти всегда может найти нужные мне документы. А ведь ищет он среди гораздо большего числа документов. Я думаю, усилия надо направить именно в сторону «простого» поиска.

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

Спасибо. :)

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

Во-первых, интерфейс построен на MSHTA (HTML Application), поэтому и выглядит он гипертекстово. Мы, конечно, сначала постарались заточить его под нативное приложение Windows, но уши все равно торчали. В итоге мы перестали с гипертекстовостью бороться, и попытались ее использовать. Ссылка с пунктирным подчеркиванием (а-ля «веб 2.0») переключает закладки формы без обращения к серверу. И строчка с браузерными контролями (я согласен, это #&*@!!!) появилась по той же причине: пользователям очень хотелось, чтобы можно было уйти назад по ALT+влево, посмотреть историю переходов по экранам, и быстро попасть на свой домашний экран, ткнув в кнопочку с домиком, — как в обычном браузере.

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

В-третьих, запрос на сохранение действительно перекочевал на отдельную закладку формы с результатами поиска. Так оно логичнее.

В-четвертых, спасибо за пример календаря. Если мы сможем сделать такой календарь клавиатурно-управляемым, будет круто. Если не сможем — оставим свой. Вообще, обработка клавиатуры в HTML Application — это отдельная песня, http://aleske.livejournal.com/106060.html — как-то так поется.

В-пятых, множественный выбор нужен, хоть и проблемный он. HTML'ный SELECT MULTIPLE — невероятно неудобная гадость, а все чекбоксы разом (особенно если их 15 штук, есть у нас такие поля) в одну ячейку запихивать… Уж лучше так, как на скриншоте, чем никак. Ничего другого нам в головы не приходит.

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

P. S. Записки снизу — журнал работы. Вместо того, чтобы невежливо кидать пользователю в лицо диалоговое окно с сообщением «Договор №12/59-Ё успешно заблокирован» и единственной кнопкой ОК, сообщение об успехе действия тихо пишется в журнал. Ну, то есть, будет писаться по-русски (или по-английски, или на какой там еще язык переведем), когда систему доделаем, а пока там пишется contract.locked. О неудачном действии тоже пишется туда же, но вдобавок под строкой заголовка всплывает goldbar, как в IE.
Павел Власов
11 декабря 2007

Мне не нравится отделенность палитры фильтров от собственно активных фильтров — приходится искать между ними соответствие. Объединив их, мы также устраняем сложное перетаскивание фильтров из палитры — все будет уже на своем месте. Неактивные (еще) фильтры, будучи в «свернутом» состоянии, могут занимать совсем мало места.

Мне непонятно назначение чекбокса у групп («По умолчанию», «Контактные данные») — вряд ли функциональность «отметить всех в группе» будет востребована, а вот возможность свернуть некоторые группы не помешает.

Насчет стандартного select'а «содержит/не содержит»: мне гораздо симпатичнее подход использованный в «Поиске по блогам» Яндекса — там предоставляется текстовое поле и _подним checkbox для инвертации поиска — очень удобно, учитывая что обычно используются неинвертированные фильтры. Такой подход также меньше засоряет пространство — взгляд не спотыкается об checkbox чтоящий ниже основного текстового поля в отличии от нынешнего подхода, к тому же checkbox проще для восприятия, если значения всего два — вкл/выкл. (Смотри среднюю часть рисунка).

Еще активированные фильтры можно отображать по-человечески, т. е. выводя лишь формулировку, которая часто займет места меньше, чем универсальная форма ввода. (Смотри нижнюю часть рисунка).
Алексей А. Евдокимов
11 декабря 2007

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

«Простой» поиск по структурированным данным работает хуже, чем по плоскому тексту, и с Яндексом данную ситуацию сравнивать некорректно. Скажем, у нужного нам договора «Василий Михайлович» контактная персона, а у другого «Василий Иванов» — доверенное лицо, у третьего «ООО Василий» — название юрлица. «Простой» поиск возвращает все три договора. Фильтровать потом результаты можно, но это отнимает время и повышает вероятность ошибки. И сохранить условия поиска, чтобы потом его можно было быстро вызвать, толком не получится.

Придумывать же язык запросов типа $subject like Василий && $date before 01-10-2007 && $payment_type in (1,6,7) ничем не лучше, чем учить телефонных барышень SQL'ю. Мы наших красавиц слишком любим, чтобы проводить над ними столь изуверские эксперименты. :) С запросами на естественном, то есть, русском, языке, мы не справимся, вот и приходится выбирать из всех зол меньшее.

Да, мы тут еще немного подумали, и в результате набросали вот такой макет интерфейса, который еще предстоит довести до ума:
Алексей Мельников
11 декабря 2007

Набросок поиска, с отображением результатов по мере ввода. Если находятся данные из других областей, среди номеров договоров, например, то добавляется соответствующая колонка. Словом, показываются только те колонки, в которых найдено совпадение.
Юрий Хан
11 декабря 2007

Формулировка «содержит любой из вариантов (Выбрано: 3)» — активно не нравится. Перечислите все, через запятую, я не верю, что их там может быть 317. «Способ оплаты услуг: наличными, VISA или WebMoney» — всяко человечнее.
Алексей А. Евдокимов
13 декабря 2007

Павлу Власову:
[Насчет стандартного select'а «содержит/не содержит»…]

Там больше вариантов. «содержит/НЕ содержит/начинается на/заканчивается на/начинается НЕ с/заканчивается НЕ на» — это для строковых полей. Для дат условия такие — «ранее/позднее/точно». Для чисел — «больше/меньше/равно/НЕ равно». Ну и так далее. Поэтому SELECT.

[Мне непонятно назначение чекбокса у групп…]

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

[Еще активированные фильтры можно отображать по-человечески…]

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


Алексею Мельникову:
Примерно так система себя и ведет в случае «простого» поиска.


Юрию Хану:
Согласен. Сделаем.

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.
3 • 4 • 5 • Иногда люди, когда пытаются оценить, насколько выгодно расположены элементы на форме, рисуют линию, по которой якобы глаз скользит 2 •




Недавно всплыло

Почему в переписке нельзя использовать «Доброго времени суток»? 2 • 1 • Почему дизайнер должен уметь писать текст? 8 • Правдивость 4 •