x
 
Георгий Иванкин
20 июня 2011

Здравствуйте, Артём и уважаемые советчики!

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

За основу решили взять интерфейс выборки тикетов из системы управления проектами trac — нам он кажется удобным и понятным, хотя, возможно, мы просто к нему привыкли за месяцы использования. Однако этот интерфейс не в состоянии полностью решить стоящую задачу (также, как и аналоги, которые нам известны, например Яндекс.Маркет). А именно: поля в фильтре объединяются логическим оператором ИЛИ (повседневным «и»), т. е. каждый добавленный фильтр сужает выборку. А в нашей системе возможны ситуации, когда, скажем, нужно выбрать «все телефоны nokia, а также все телефоны в корпусе синего цвета» (телефоны, естественно, просто как пример). В траке или у Яндекса это решается только последовательным созданием двух выборок. Единственная идея, которая пока у нас есть — дать пользователю возможность продублировать фильтр целиком и объединить результат двух выборок (вариант запроса, когда потребуется объединять больше двух выборок, попадает в 0,1% и не считается).

Скажите пожалуйста, что вы думаете о таком решении, есть ли какие-то альтернативы, или, может быть, траковский фильтр изначально не лучший вариант?

Спасибо.



Георгий!

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

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

Даже упрощённый интерфейс почтовых правил макинтоша стоит на грани понимания пользователя — не программиста:

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


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

Комментарии

Алексей Егоров
20 июня 2011

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

Николай Новик
23 июня 2011

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

Кстати, такой интерфейс вполне решает проблему Георгия по выборке «телефонов Нокия» или «синих телефонов».

Женя Бакст
24 июня 2011

Хочу обратить ваше внимание на книгу Мартина Фаулера Domain-Specific Language (http://www.amazon.com/…/0321712943/ref=sr_1_1?ie=UTF8&qid=1308862605&sr=8-1 (http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Fowler/dp/0321712943/ref=sr_1_1?ie=UTF8&qid=1308862605&sr=8-1) )

Domain-Specific Language (DSL) — это такой ограниченный узконаправленный язык, который создаётся в качестве надстройки над моделью. DSL очень подходит для коммуникации со специалистами предметной области. Примерами DSL являются регулярные выражения, XML-конфиги, SQL, флюент-интерфейсы. В своей книге Фаулер говорит, что модель может получать свой ввод как из форм, так и из DSL. Только вот если требуется создать какой-то сложный ввод, то DSL гораздо больше для этого подходит, нежели ввод из форм.

Первую главу книги можно прочитать бесплатно у Фаулера на сайте: http://martinfowler.com/dsl.html


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

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

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

Вот такой веб 2.0.

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