Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Не, я не против дерева как класса. Я против misuse. Например, когда имеем дерево с большим количеством элементов и глубокой вложенностью, получаем такую вот охренительную навигацию: ЗХ>
А может быть добавить тултип, который будет показываться при наведении на элементы дерева. Выровнять левый край тултипа по корневому списку, и в нем показывать путь к элементу, который не видна из-за большого кол-ва элементов. Если навести на черту, которая показывает вложенность — менять тултип, укорачивая пуь нужным образом.
По крайней мере путь наверх можо будет узнать.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Не, я не против дерева как класса. Я против misuse. Например, когда имеем дерево с большим количеством элементов и глубокой вложенностью, получаем такую вот охренительную навигацию: ЗХ>http://rsdn.ru/File/21481/msdn-tree.gif
По поводу конкретно этой мисюси: тут главная заподлянка в том, что слишком много элементов вытеснили контекст (т.е. путь до корня и хотя бы ближайших соседей) за пределы экрана. Чтобы увидеть контекст, нужно скроллировать.
Решением могут быть как хлебные крошки, так и хитрый скролл.
Хлебные крошки
Cover / Volume II / Section 2.5 >
----- --------- -----------
[^]
Three | |
Four |#|
Five | |
Six | |
[v]
Хитрый скролл
до и после прокрутки на 1 пункт
[^] [^]
Cover | | Cover | |
Volume II | | Volume II | |
Section 2.5 | | Section 2.5 | |
... |#| ... | | <-- индикатор того, что в ветке много элементов
Three | | Four |#| и не все они видны вместе
Four | | Five | |
Five | | Six | |
Six | | Seven | |
... | | Section 2.6 | |
[v] [v]
да и вообще, мои кривые ручки наваяли нечто вот такое (настройки пока еще не утрясены, этот диалог — просто proof of concept, но его описание выходит за рамки этого форума):
Скриншот 1
Скриншот 2
Возник вопрос, стоит ли перекидываться сразу на "дите", если в корневом элементе нет настроек? Или показывать список "детей" с возможностью клика и перехода?
1. Несмотря на то что заголовок в аналогичных интерфейсах часто используется мне кажется он лишний — ведь в дереве и так видна выбранная категория. А места он кушает немало.
2. В твоем примере при выборе Client Settings можно например показывать описание категории. Хотя везде это реализовано по-разному. Тут интересно определиться может ли родительская ветка иметь настройки или нет. С одной стороны это неочевидно, с другой... Можно еще сделать специальное дерево (как в студии или в ослике например), которое в принципе непозволит выбирать родительскую ветку — ее можно только разворачивать, но активным всегда будет именно дите.
3. Ну и наконец. Еще проблема. Если для редактирования настроек используется не контрол типа PropertyGrid, а обычный виндовый интерфейс, то рано или поздно столкнешься с проблемой что стандартного размера панельки для некоторых групп настроек маловато. И что тогда делать? В эклипсе например автоматически изменяется размер диалога, что на мой взгляд выглядит не очень изящно. А если добавлять табы или скроллинг то это может привести к излишней навороченности интерфейса.
Posted via RSDN NNTP Server 1.9
Re[2]: Конкурс: сруби дерево ;)
От:
Аноним
Дата:
09.05.05 17:35
Оценка:
M>Возник вопрос, стоит ли перекидываться сразу на "дите", если в корневом элементе нет настроек? Или показывать список "детей" с возможностью клика и перехода?
Мне кажется такой подход не очень удачным. Я бы сделал групповой элемент рабочим, перенеся туда, например, содержимое закладки User. Останется 1 "листик" Connection.
Здравствуйте, Mamut, Вы писали:
M>Возник вопрос, стоит ли перекидываться сразу на "дите", если в корневом элементе нет настроек? Или показывать список "детей" с возможностью клика и перехода?
Сделать корень обычным static'ом. Не давать его выбирать вообще.
ВВ>1. Несмотря на то что заголовок в аналогичных интерфейсах часто используется мне кажется он лишний — ведь в дереве и так видна выбранная категория. А места он кушает немало.
Дело в том, что при уходе с дерева фокусный фон или исчезает или становится очень бледным. При большом количестве настроек, найти его становится уже сложнее. Я тут подумал, может выделять элемент в дереве с помощью треугольничка этакого:
(типа концепт)
ВВ>Можно еще сделать специальное дерево (как в студии или в ослике например), которое в принципе непозволит выбирать родительскую ветку — ее можно только разворачивать, но активным всегда будет именно дите.
ВВ>3. Ну и наконец. Еще проблема. Если для редактирования настроек используется не контрол типа PropertyGrid, а обычный виндовый интерфейс, то рано или поздно столкнешься с проблемой что стандартного размера панельки для некоторых групп настроек маловато. И что тогда делать? В эклипсе например автоматически изменяется размер диалога, что на мой взгляд выглядит не очень изящно. А если добавлять табы или скроллинг то это может привести к излишней навороченности интерфейса.
Дело в том, что мне еще не приходилось видеть, чтобы в пользовательском приложении требовался проперти грид. Даже настройки в Янусе можно представить деревом с максимум двумя уровнями. Студия и Эклипс — это, конечно, случай особый, там настроек оё-ё-ёй. Но за диалог свой я буду драться Тем более, что и настроек там будет — кот наплакал.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView). ЗХ>Используют его где надо и где не надо, а контрол, между прочим, не очень хороший и далеко не всегда уместный.
ЗХ>В общем, в рамках этой ветки предполагается обсуждать следующие темы: ЗХ>1. Когда TreeView уместен ЗХ>2. Когда TreeView не уместен ЗХ>3. Какие можно найти/изобрести альтернативные контролы для представления альтернативной информации
ЗХ>Поехали!
ЗХ>Для затравки: вот очень, между прочим, неплохой контрол.
Мне кажется бенефит такого диалога именно когда настроек много — и их количество может увеличиваться, скажем, с установкой плагинов. В противном случае обычный таб-пейдж может показаться куда более естестетственным и привичным решением. ИМХО разумеется.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, <Аноним>, Вы писали:
ЗХ>>>Для затравки: вот очень, между прочим, неплохой контрол.
А>>Где?
ЗХ>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
Здравствуйте, Mamut, Вы писали:
ВВ>>1. Несмотря на то что заголовок в аналогичных интерфейсах часто используется мне кажется он лишний — ведь в дереве и так видна выбранная категория. А места он кушает немало.
M>Дело в том, что при уходе с дерева фокусный фон или исчезает или становится очень бледным. При большом количестве настроек, найти его становится уже сложнее. Я тут подумал, может выделять элемент в дереве с помощью треугольничка этакого:
M>(типа концепт) M>
Мняяя... Не знаю. Мне не очень нравится непривычностью. То ись у пользователя может возникнуть вопрос "это оно почему так выделено? какая-то особенная страничка или так, для красоты?" Тем более, красный — цвет, символизирующий "внимание!" или "ошибка!".
Я бы предпочел:
— сменить цвет неактивной строки на кастомный (по-моему, не должно быть намного сложнее добавления картинки)
— или сделать так, как я в свое время предлагал
Здравствуйте, pavel_turbin, Вы писали:
ЗХ>>>>Для затравки: вот очень, между прочим, неплохой контрол.
А>>>Где?
ЗХ>>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
_>что-то народ по google совсем стал сохнуть. Чем вам наши хуже? _>здесь каталоги нехуже: _>http://www.yandex.ru/ _>http://yaca.yandex.ru/ _>http://www.rambler.ru/ _>http://www.aport.ru/
Тут я как раз не имел в виду конкретный Гугль. Данный контрол — способ представления практически любого веб-каталога (по каковому поводу дальше в этой ветке он при обсуждении и назывался мной WebDirectory, а Славой Шевцовым — Yahoo Catalog)
ВВ>Мне кажется бенефит такого диалога именно когда настроек много — и их количество может увеличиваться, скажем, с установкой плагинов. В противном случае обычный таб-пейдж может показаться куда более естестетственным и привичным решением. ИМХО разумеется.
У меня просто была задача поднятия диалога настроек из XML файла. В текущем проекте он не осоьенно и нужен, так proof of concept, но в не столь отдаленном будущем мне как раз такое вот и понадобится
ЗХ>Мняяя... Не знаю. Мне не очень нравится непривычностью. То ись у пользователя может возникнуть вопрос "это оно почему так выделено? какая-то особенная страничка или так, для красоты?" Тем более, красный — цвет, символизирующий "внимание!" или "ошибка!".
Ну, треугольник может быть любого цвета и размера
ЗХ>Я бы предпочел: ЗХ>- сменить цвет неактивной строки на кастомный (по-моему, не должно быть намного сложнее добавления картинки) ЗХ>- или сделать так, как я в свое время предлагал
Перекуём баги на фичи!
Пришлось и мне их, родимых, использовать 
Тем более, что и настроек там будет — кот наплакал.
