UI для редактирования групп

[skiperski]

Вопрос или опрос по поводу реализации интерфейса пользователя. Если не в тот форум, то RayShade поправит.

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

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

Например так: На форме с табами на первой вкладке в гриде отображаются клиенты, а на второй - группы. При выборе группы в модальной форме в лабелах название и описание группы, ниже в гриде клиенты, входящие в эту группу. Кнопки добавить/удалить клиента, редактировать свойства группы. При нажатии на добавить клиента появляется модальная форма с клиентами ещё не вошедшими в эту группу с возможностью поиска или фильтра. При выборе клиента не входящего в группу...

И т.д.

[Алексей К.]

Имхо сделать слева дерево групп, потом сплит, потом грид - клиенты.
Ниже вышеуказанных элементов управления кнопки: Добавить, Удалить, Свойства. Caption кнопок будет меняться в зависимости то того где фокус (Добавить группу/Добавить клиента).Либо две группы кнопок - для дерева и для грида. Реализовать drag&drop клиента в группу (в дерево), контекстное меню над каждым элем. управления с пунктами добавить, удалить, свойства.

[Sebas]

Открой аналогичный в ХП или 2000 и посмотри))))

[alibek]

Соглашусь с Sebasом.
Как вариант, можно сделать что-то типа окна Explorer'а; слева будет TreeView с группами (корневой элемент "Все записи" и дочерние группы), справа ListView с юзерами. Выделяешь группу "Все записи" и перетаскиваешь юзеров на нужный пункт в TreeView.

Код: Выделить всё

+-----------------------+----------------------------------+
| Все группы (27)       | Иван Иваныч (Админы, Менеджеры)  |
|   Админы (1)          | Петр Петрович (Начальство)       |
|   Менеджеры (7)       | Василий Васильевич               |
|   Юзеры (12)          | ...                              |
|   Начальство (3)      |                                  |
|                       |                                  |
|                       |                                  |
|                       |                                  |
|                       |                                  |
|                       |                                  |
|                       |                                  |
|                       |                                  |
|                       |                                  |
+-----------------------+----------------------------------+


[skiperski]

Эхехех... А где же крИатиФ? Где творчество, я спрашиваю? Всё таки профессиональная деформация накладывает свой отпечаток на видение мира. Само-собой разумеющееся для программиста может стать непреодолимым барьером для пользователя. Честно говоря, я тоже не нахожу стандарт от вынь (в данном конкретном случае) интуитивно понятным пользователю. Теперь о подводных камнях.

Из логики предложенных вариантов следует, что обработка клиентов вне групп и в группах должна быть идентичной. Но... не зря я поминал поле описания (и оно может быть не едиственным). Оно принадлежит не группе и не клиенту, а именно связи клиент-группа. Следовательно формат отображения клиента в группе уже будет отличаться от формата клиента вне группы. Кроме того что должна делать кнопка просмотреть/редактировать клиента? Толи редактирование данных клиента, толи редактирование вот того самого дополнительного поля. Идеи есть? То же самое и с удалением клиента: вне группы понятно - удаляется сам клиент, а в группе? сам клиент (если логика на всех одна) или только линк из группы?

Кроме того в клиентах работает фильтр (клиентов более 4-х тысяч). Должны ли установки фильтра распространяться на клиентов в группах? По-моему - нет, но как объяснить пользователю почему в одной и той же форме фильтр то работает то нет? Если же фильтр работает, то он видит в группе каждый раз разное кол-во клиентов, тоже будет масса вопросов.

Кроме локального фильтра, есть ещё и глобальный, завязанный на пользователя, т.е. некоторые операторы видят только клиентов с определёнными телефонами или адресами. Для них некоторые группы будут пусты и оператор может решить удалить пустую группу, которая на самом деле не пуста. Можно скрывать пустые, но в момент создания группа всегда пуста. В общем бардак. По-моему, здесь проще всего лишить операторов с ограниченными правами возможности редактирования/удаления групп. Или есть варианты?

[GSerg]

Может спросить операторов - люди, а вы бы как предпочли?..

[skiperski]

Может спросить операторов - люди, а вы бы как предпочли?..

Они предпочли, чтобы всё само делалось, а они только бумагу в принтер вставляли. Месяц осваивали блокировку/разблокировку клиента. В продукции добавил составные продукты: набор формируется из уже имеющихся, так через две недели сказали, что этого им не надо (не потому что не надо, а потому что тетеньки не понимают как с этим работать). и они будут просто заводить новые атрикли переписывая данные старых. Больше у них ничего не спрашиваю. Тем более, здесь интерфейс очень прост в словесном описании (чего там: разбить клиентов про группам, всё понятно). Но, как мною давно замечено, чем проще описание, тем сложнее реализация. К формам списка клиентов и добавления/просмотра/редактирования клиента добавляются, как минимум, список групп (даже если в виде дерева), добавления/просмотра/редактирования группы, список клиентов в группе, добавления/просмотра/редактирования клиента в группе. И всё это должно быть не страшным

ЗЫ: ещё небольшое уточнение: всё реализуется на web-интерфейсе, а потому драги и дропы не катят, гридов тоже нет, а вываливать на страницу 4 тыс. строк - издевательство над юзером, потому нежен пэйджинг и т.д. Потому и хотел услышать идеи, а не технические реализации, чтобы подобрать что-гибудь подходящее.

[Ennor]

MSF рекомендует начинать любое проектирование со сбора требований заказчика, а RUP - с построения сценариев использования (Use Cases). Начнем?

Группы: список, ACED-функционал (add, copy, edit, delete). Навскидку сейчас пришло в голову добавить возможность копирования / переноса всех пользователей группы в другую группу, но не факт, что это будет реально необходимо - тебе виднее. Поскольку группа может быть членом другой группы, то в общем случае список групп есть список древовидный. Если же не может, то конечно все гораздо проще.

Клиенты: полный список, аналогичный функционал, разве что копирование не столь актуально, думаю. Гораздо более актуальной лично мне видится операция включения пользователя(-ей) в группу. Можно это сделать на манер Яндекса - "Отмеченных клиентов включить в группу <комбик со списком групп>". Дальше уже зависит от предметной области - если клиент может состоять в нескольких группах, значит, реализовать отображение списка этих групп. Если же не может, то и не надо.

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

[skiperski]

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