Может кто-нить подсказать удобную реализацию контрола для редактирования пользователей и групп? Тот, что в винде ХР вызывает стойкое отвращение. Должно же быть что-то удобнее...
Единственный вариант, который пока пришел в голову -- дерево в узлах которого группы (соответственно могут быть и подгруппы) а листья -- пользовательи.
редактируется через драг-энд-дроп. Это единственный минус, который я вижу. Не очевидно, что он вообще есть. Может подскажете альтернативные варианты?
Здравствуйте, leska, Вы писали:
L>Единственный вариант, который пока пришел в голову -- дерево в узлах которого группы (соответственно могут быть и подгруппы) а листья -- пользовательи. L>редактируется через драг-энд-дроп. Это единственный минус, который я вижу. Не очевидно, что он вообще есть. Может подскажете альтернативные варианты?
Э. Как бы так сказать, чтоб самому не обидеться.
В общем-то, дерево не есть самый-удобный-интерфейс, а драг-н-дроп тоже имеет свои минусы. Задача редактирования прав доступа выглядит достаточно ограниченной для того чтобы скатываться в такую попсу.
в любом случае, без более-менее подробных юзкейсов сложно что-то посоветовать, но тем не менее увлекаться деревьями ябы не стал.
Здравствуйте, rlabs, Вы писали:
R>Э. Как бы так сказать, чтоб самому не обидеться. R>В общем-то, дерево не есть самый-удобный-интерфейс, а драг-н-дроп тоже имеет свои минусы. Задача редактирования прав доступа выглядит достаточно ограниченной для того чтобы скатываться в такую попсу.
А про права доступа никто не говорил.
R>в любом случае, без более-менее подробных юзкейсов сложно что-то посоветовать, но тем не менее увлекаться деревьями ябы не стал.
Попробую расписать чуть подробнее:
Планируется создать что-то типа записной книжки. По этому группы будут выполнять функцию логической группировки людей. Что-то типа:
+-friends
| |
| +-- Alex N.
| +-- Peter B.
|
+-colleagues
|
+-- Martin C.
+-- Masha R.
В общем случае людей будет достаточно много. Периодически нужно будет просматривать и редактировать информацию о них. Причем редактировать достаточно часто. Т.к. информации о каждом пользователе будет достаточно много, и не вся она может быть заполнена с первого раза.
Что посоветуете вместо дерева? Может есть смысл использовать дерево для отображения групп и пользователей, а для редактирования использовать другой интерфейс?
L>+-friends
L>| |
L>| +-- Alex N.
L>| +-- Peter B.
L>|
L>+-colleagues
L> |
L> +-- Martin C.
L> +-- Masha R.
L>
L>Что посоветуете вместо дерева? Может есть смысл использовать дерево для отображения групп и пользователей, а для редактирования использовать другой интерфейс?
Главный вопрос -- что делать, если нужно занести человека в несколько групп?
Здравствуйте, leska, Вы писали:
L>Попробую расписать чуть подробнее: L>Планируется создать что-то типа записной книжки. По этому группы будут выполнять функцию логической группировки людей. Что-то типа:
[...]
Ну вот видите, какая же запкнижка в виде дерева, это только морока. Удобно по дереву искать пользователя "быстрым поиском"? Думаю не очень. И разворачивать-сворачивать тоже.
L>Что посоветуете вместо дерева? Может есть смысл использовать дерево для отображения групп и пользователей, а для редактирования использовать другой интерфейс?
Э. Можно я немного потуплю и предложу безумную, совершенно безумную идею?
Посмотрите на такой вариант: использовать для группировки пользователей цвет фона ячеек в списке. Не умею рисовать, но должно выглядеть примерно так:
---
Друзья [фон такой розовенький]
— Петя
— Василий Иваныч
--
Коллеги [фон группы меняется на безразлично-зеленый]
— Маша тестеровщица
— Начальнег группы
---
Надеюсь идея понятна. Это явно не подойдет для многих примеров применения, но зато выгдядит прикольно.
Здравствуйте, rlabs, Вы писали:
R>Надеюсь идея понятна. Это явно не подойдет для многих примеров применения, но зато выгдядит прикольно.
Вобоще мысль прикольная, только при большом количестве будет не очень удобно мышой крутить скролл. Быстрый поиск -- это на любителя. Я думаю, рядовой юзер больше любит пользоваться мышкой. И выпускает ее из рук без особой охоты. Да и время в случае использования быстрого поиска будет скорее всего боль ше, чем при совершении аналогичных действий без него.
Последовательность:
1. Поставить фокус на списке
2. Отпустить мышку
3. Нажать хоткей для активации окна быстрого поиска
4. Ввести имя (Хорошо, если помнишь точно и пишешь без ошибок).
5. Нажать что-то типа Ентер для подтверждения выбора.
6. Взять мышку.
Конечно, если подумать, можно пару пунктов убрать, но в общем последовательность действий сохранится.
Дерево:
1. Не выпуская мышу раскрыл нужную группу.
2. При необходимости провернул скролл.
3. Выбрал запись.
Для любителей быстрый поиск можно организовать и в дереве.
Здравствуйте, leska, Вы писали:
R>>Надеюсь идея понятна. Это явно не подойдет для многих примеров применения, но зато выгдядит прикольно.
L>Вобоще мысль прикольная, только при большом количестве будет не очень удобно мышой крутить скролл. Быстрый поиск -- это на любителя. Я думаю, рядовой юзер больше любит пользоваться мышкой. И выпускает ее из рук без особой охоты. Да и время в случае использования быстрого поиска будет скорее всего боль ше, чем при совершении аналогичных действий без него.
Это зависит от того, чем пользователь занят. Если он вводит информацию, переключение между клавой и мышой — реальный такой пэйн и страдания. А, и туннельный синдром еще.
Про список еще расскажу. Что в нем может быть привлекательного:
— группы можно (в принципе) сделать сворачивающимися/минимизирующимися
— цвета групп можно показать на скроллере для удобства прокрутки (хотя, между нами говоря, прокрутка это вообще зло).
— для быстрого поиска не нужно отдельное окно (мы же в фокусе списка, зачем нам еще окно?)
— есть возможность отображать больше полей для каждого пользователя и частично in-place редактировать данные, а так же размещать разные полезняшки, типа прямой ссылки mailto для создания писма в один клик и тд и тп.
— такая красота практически сразу подходит для печати (ну мало ли)
Серьезный минус — группы развалятся, если, например, отсортировать _весь_ список по какому-то параметру без учета группировки (впрочем, дереву в этом случае тоже не позавидуешь).
Собственно дальше трудно думать, но какой-то смысл в этом есть имхо.
Здравствуйте, ZaQ, Вы писали:
ZaQ>а если Masha B., Martin C. и Alex N. еще будут и друзьями?, т.е. одни и теже люди будут состоять в нескольких группах.
Не, в ближайшее время не будут
ZaQ>IMHO если дерево использовать в данном случае, то запутаться можно очень быстро, особенно если людей много.
Можете подсказать альтернативу? А то что-то не придумывается...
Здравствуйте, rlabs, Вы писали:
R>Здравствуйте, leska, Вы писали:
R>Это зависит от того, чем пользователь занят. Если он вводит информацию, переключение между клавой и мышой — реальный такой пэйн и страдания. А, и туннельный синдром еще.
R>Про список еще расскажу. Что в нем может быть привлекательного: R>- группы можно (в принципе) сделать сворачивающимися/минимизирующимися
То же самое дерево.
R>- цвета групп можно показать на скроллере для удобства прокрутки (хотя, между нами говоря, прокрутка это вообще зло). R>- для быстрого поиска не нужно отдельное окно (мы же в фокусе списка, зачем нам еще окно?)
После ввода первой буквы информация о пользователе (справа от списка) проапдейтится. После второй и третьей, возможно, тоже. Напрягать будет.
Да и надо пользователю видеть какой текст он вводит. Может он из буфера хочет имя вставить? Окно для вввода текста может быть тултипообразным с одним только эдитбоксом.
R>- есть возможность отображать больше полей для каждого пользователя и частично in-place редактировать данные, а так же размещать разные полезняшки, типа прямой ссылки mailto для создания писма в один клик и тд и тп.
А в дереве нельзя? (Вообще мысль хорошая, спасибо)
R>- такая красота практически сразу подходит для печати (ну мало ли)
Не, печататься если и будет, то информация об одном или нескольких пользователях. Сам список распечатывать смысла нет.
R>Серьезный минус — группы развалятся, если, например, отсортировать _весь_ список по какому-то параметру без учета группировки (впрочем, дереву в этом случае тоже не позавидуешь).
R>Собственно дальше трудно думать, но какой-то смысл в этом есть имхо.
Вобщем получается, что какая-то группировка пользователей нужна. Т.е. логически получаем дерево. А вот как его отобразить, чтобы удобно было -- не понятно...
Здравствуйте, leska, Вы писали:
L>Вобщем получается, что какая-то группировка пользователей нужна. Т.е. логически получаем дерево. А вот как его отобразить, чтобы удобно было -- не понятно...
Проблема дерева в том, что оно в принципе предназначено для отображения примитивной информации (одна нода — одна не очень длинная строка текста), и когда из него пытаютя выжать больше — начинается вбивание костылей и разные хаки, что в свою очередь повышает риски.
Здравствуйте, leska, Вы писали:
ZaQ>>а если Masha B., Martin C. и Alex N. еще будут и друзьями?, т.е. одни и теже люди будут состоять в нескольких группах. L>Не, в ближайшее время не будут
Возможность пользователя быть в нескольких группах — это принципиальный архитектурный вопрос. Деление на «в первую очередь», «во вторую очередь» и «в дальнейшем» тут неуместна.
Если пользователь может быть в нескольких группах, то нужен интерфейс, умеющий показывать (а) всех пользователей, (б) все группы, (в) всех пользователей одной группы, (г) все группы одного пользователя; легко переключаться между этими четырьмя видами; и быстро включать пользователей в группы и удалять из них.
Если же пользователь железно может быть только в одной группе, тогда можно использовать дерево и сразу задуматься, позволять ли вложенные группы.
У меня в Mirand’е под две сотни контактов, раскиданных по вложенным группам. Я предпочитаю держать основные группы полностью развёрнутыми и показывать контакты, которые offline, чтобы по ним работал быстрый поиск. И да, время от времени возникает проблема, кого в какую группу определить.
Здравствуйте, Centaur, Вы писали:
C>Возможность пользователя быть в нескольких группах — это принципиальный архитектурный вопрос. Деление на «в первую очередь», «во вторую очередь» и «в дальнейшем» тут неуместна.
Это понятно. Я иммел ввиду, что в обозримом будущем такого не предвидится. Хотя, полностью исключать вероятность нельзя. (К примеру, опрос кастумеров покажет, что они хотели бы видеть несколько групп. На данный момент возможности провести такое исследование нет.)
C>У меня в Mirand’е под две сотни контактов, раскиданных по вложенным группам. Я предпочитаю держать основные группы полностью развёрнутыми и показывать контакты, которые offline, чтобы по ним работал быстрый поиск. И да, время от времени возникает проблема, кого в какую группу определить.
По вашему бы лучше использовать несколько групп? Или ограниченность интерфейса позволяет не разводить бардака в контактах? Если добавлять один контакт (в миранде) в несколько групп, то у пользователя встанет вопрос: в разных группах отображается один и тот же пользователь или два разнных с одинаковым именем? А если мы изменим инфу одного пользователся, то изменится ли она у другого? Вобщем наверное больше путанницы получилось бы. ИМХО.
Выделение в первой колонке ограничивает пользователей во второй (те кто принадлежит этой группе). Для выделенныч пользователь показывает контрол рядом со свойствами пользователей и набором чекбоксов по одному на группу (tri-state). Еще drag'n'drop множественного выделения пользователей в группу (добавить туда).
K>Выделение в первой колонке ограничивает пользователей во второй (те кто принадлежит этой группе). Для выделенныч пользователь показывает контрол рядом со свойствами пользователей и набором чекбоксов по одному на группу (tri-state). Еще drag'n'drop множественного выделения пользователей в группу (добавить туда).
А если пользователей и групп пожет быть очень много — сделать еще и quick search (дополнительно фильтровать по условию group.BeginsWithIgnoringCase(searchString) OR user.BeginsWithIgnoringCase(searchString).
Тоже столкнулся с похожей задачей. В моём случае задача несколько упрощённая: максимум полсотни пользователей, более-менее равномерно распрделённых по 10-20 группам. В процессе экспериментов пришёл к такому варианту — скриншот
Это пока так вышло — рабочий прототип. Думаю, стоит попробовать набор обычных ListBox'ов — должно стать проще и привычнее. Перенос между группами drag'n'drop-ом, редактирование кнопкой на панели или даблкликом по пользователю или группе.
