Здравствуйте, Mamut, Вы писали:
M>Кстати, за что я бы убивал — за потерю фокуса с любого scroll-контрола (listbox, treeview — не суть важно), как это происходит в индексе MSDN. Нельзя пользоваться колесом мышки
а я бы ещё стукнул бы того человека, который в hh.exe (viewer for chm) в системном меню на место пункта "Закрыть" поместил никому не нужный пункт вызова диалога "Version..."
Только что привычным движением хотел закрыть hh, а он опять мне версию показывает...
Помоему это самая страшная ошибка дизайна со времён создания первого окна...
Извините что не в тему, просто накипело
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Не, я не против дерева как класса. Я против 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]
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView). ЗХ>Используют его где надо и где не надо, а контрол, между прочим, не очень хороший и далеко не всегда уместный.
ЗХ>В общем, в рамках этой ветки предполагается обсуждать следующие темы: ЗХ>1. Когда TreeView уместен ЗХ>2. Когда TreeView не уместен ЗХ>3. Какие можно найти/изобрести альтернативные контролы для представления альтернативной информации
ЗХ>Поехали!
ЗХ>Для затравки: вот очень, между прочим, неплохой контрол.
Здравствуйте, Mamut, Вы писали:
ЗХ>>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView).
M>
M>Как я понимаю, частично эта тема навеяна вот этой
.
M>Тут я тогда рассмотрю некоторые за и против использования Дерева в диалогах настроек.
Кстати, не угадал.
Как раз диалог настроек — то место, где дереву самое место (пардон за каламбур); тут ты все очень правильно расписал.
Другое дело, что про проблемы ты тоже абсолютно правильно все расписал.
А бороться, имху, надо вот с такими штуками
ЗХ>ЗЫ: Как тебе такая мысль — только что стукнуло:
Похоже на закладки, только с боку. А с закладками сверху смотрится вообче ужасно. Бедный юзверь потеряется.
зы. Несколько раз сталкивался с таким , что юзверю не понятно что за пункт в дереве сейчас выбран (плохая селекция) или что вообще надо на дерево тыкать, что бы перейти на другую страницу настроек. Имхо, дерево в настройках надо какнить раскрашивать, не оставлять голым. Иконки около главных пунктов, что бы привлечь внимание, обязательны.
зыы.
Идём в гугль в закладки Images, пишем TreeView, смотрим. С недавних пор при кризисе мыслей начал так искать примеры интерфейсов.
ВВ>1. Несмотря на то что заголовок в аналогичных интерфейсах часто используется мне кажется он лишний — ведь в дереве и так видна выбранная категория. А места он кушает немало.
Дело в том, что при уходе с дерева фокусный фон или исчезает или становится очень бледным. При большом количестве настроек, найти его становится уже сложнее. Я тут подумал, может выделять элемент в дереве с помощью треугольничка этакого:
(типа концепт)
ВВ>Можно еще сделать специальное дерево (как в студии или в ослике например), которое в принципе непозволит выбирать родительскую ветку — ее можно только разворачивать, но активным всегда будет именно дите.
ВВ>3. Ну и наконец. Еще проблема. Если для редактирования настроек используется не контрол типа PropertyGrid, а обычный виндовый интерфейс, то рано или поздно столкнешься с проблемой что стандартного размера панельки для некоторых групп настроек маловато. И что тогда делать? В эклипсе например автоматически изменяется размер диалога, что на мой взгляд выглядит не очень изящно. А если добавлять табы или скроллинг то это может привести к излишней навороченности интерфейса.
Дело в том, что мне еще не приходилось видеть, чтобы в пользовательском приложении требовался проперти грид. Даже настройки в Янусе можно представить деревом с максимум двумя уровнями. Студия и Эклипс — это, конечно, случай особый, там настроек оё-ё-ёй. Но за диалог свой я буду драться Тем более, что и настроек там будет — кот наплакал.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView). ЗХ>Используют его где надо и где не надо, а контрол, между прочим, не очень хороший и далеко не всегда уместный.
ЗХ>В общем, в рамках этой ветки предполагается обсуждать следующие темы: ЗХ>3. Какие можно найти/изобрести альтернативные контролы для представления альтернативной информации
Здравствуйте, <Аноним>, Вы писали:
А>TreeView хорош, когда возможность навигации по дереву продублирована в других контролах. Например, в ListView справа. Иначе тупые узвери не догоняют, как пользоваться. На счёт хороший/не хороший спорить не буду. Кому то кроме командной строки больше ничего не нужно. Но, вообще, смотрится эффектно.
Не, я не против дерева как класса. Я против misuse. Например, когда имеем дерево с большим количеством элементов и глубокой вложенностью, получаем такую вот охренительную навигацию:
Итак, почему я считаю, что в этих диалогах использование TreeView оправдано? Потому что они наглядно показывают взаимоотношение настроек программы. Т.е., если мы взглянем на любой из этих диалогов, то увидим, что обычно такие настройки или выносятся в кучу раздельных диалогов или кладутся в один неудобный табконтрол:
То есть, у нас есть как бы меню, открывающее доступ к кладези информации, но меню, которое не закрывается после выбора того или иного пункта. Если случайно ткнешь (или тыцкнешь) не в тот раздел, который тебе нужен, то не придется материться и лезть в меню опять, а надо будет просто тыцкнуть в правильный пункт.
Минуса заметны сразу, причем на всех предоставленных диалогах. Единственной визуальной подсказкой о том, где мы сейчас находимся, является только подсвеченный пункт в TreeView. BSPlayer показывает название текущих настроек, но настолько неявно, что можно считать, что его там и нет.
Весьма неплохо подошли к проблеме разработчики Shareaza'ы. Они ввели дополнительные визуальные зацепки, выделив корневые узлы дерева. Скажу сразу, что Шареазовским диалогом настроек очень удобно пользоваться.
Самый неудобный из них изо всех — это Винамп. Во-первых, очень много настроек (хоть не намного больше, чем у Шареазы, например). Во-вторых, глазу не за что зацепиться. Если не знаешь, что ищешь, в настройках сложно ориентироваться. И, хуже того, на некоторых страницах существуют дополнительные элементы, которые ухудшают восприятие (TabControl в Media Library).
То есть, TreeView оправдан в диалогах настроек только если:
— Настроек мало или
— Не существует дополнительных контролей, разбивающей информацию на составные части (в случае с Винампом — достаточно было вынести Media Library в отдельный узел)
— а также существуют визуальная информация, позволяющая легко ориентироваться между страницами.
... << RSDN@Home 1.1.4 beta 4 rev. 0>> ... <<Winamp is playing "Kenji Kawai — 07 Kugutsuuta aratayo ni kamutsudo hite">> ...
M>Кстати, за что я бы убивал — за потерю фокуса с любого scroll-контрола (listbox, treeview — не суть важно), как это происходит в индексе MSDN. Нельзя пользоваться колесом мышки
Как раз в потере фокуса нет ничего необычного, должен он терятся при щелчке на элементах диалога. Другое дело что TreeView должен прокручиватся колёсиком безо всякого фокуса. Я даже специальный хук написал, чтобы поправить такое беспордонное поведение TreeView/ListView.
>То есть удобство содержания > МСДНа тебя вполне устраивает?
Кстати, если кого заинтересует, вот как выглядит хелп в яблочном XCode: 150 Kb.
Самое левое дерево больше не раскрывается — это только top-level chapters.
Список сверху — это результат поиска, обычно он закрыт.
Текущее положение отмечается голубым путем над кнопками Next/Prev. Сами кнопки — это переход по смыслу, переход по истории — маленькие треугольнички слева в заголовке.
На сером фоне — заголовки текущей темы.
Тулбар с окошком поиска раскрывается по нажатию на маленькую прозрачную кнопку справа вверху — это стандартный системный способ убирать панель инструментов.
Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView).
Используют его где надо и где не надо, а контрол, между прочим, не очень хороший и далеко не всегда уместный.
В общем, в рамках этой ветки предполагается обсуждать следующие темы:
1. Когда TreeView уместен
2. Когда TreeView не уместен
3. Какие можно найти/изобрести альтернативные контролы для представления альтернативной информации
ЗХ>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
Много места занимает
Здравствуйте, Dog, Вы писали:
ЗХ>>ЗЫ: Как тебе такая мысль — только что стукнуло: Dog>Похоже на закладки, только с боку.
Так и задумано. Это, типа, из тех соображений, что закладки понятней чем дерево, а дерево — удобней чем закладки. Я попытался совместить
Dog>А с закладками сверху смотрится вообче ужасно. Бедный юзверь потеряется.
Ну, это не ко мне претензия, а к Nullsoft, мир праху его.
Dog>зы. Несколько раз сталкивался с таким , что юзверю не понятно что за пункт в дереве сейчас выбран (плохая селекция) или что вообще надо на дерево тыкать, что бы перейти на другую страницу настроек. Имхо, дерево в настройках надо какнить раскрашивать, не оставлять голым. Иконки около главных пунктов, что бы привлечь внимание, обязательны.
К слову, мне нравится, как это сделано в диалогах настроек Firefox/Thunderbird (вот, кто не видел):
Dog>зыы. Dog>Идём в гугль в закладки Images, пишем TreeView, смотрим. С недавних пор при кризисе мыслей начал так искать примеры интерфейсов.
Здравствуйте, <Аноним>, Вы писали:
>>То есть удобство содержания >> МСДНа тебя вполне устраивает?
А>Кстати, если кого заинтересует, вот как выглядит хелп в яблочном XCode: 150 Kb.
А>Самое левое дерево больше не раскрывается — это только top-level chapters. А>Список сверху — это результат поиска, обычно он закрыт. А>Текущее положение отмечается голубым путем над кнопками Next/Prev. Сами кнопки — это переход по смыслу, переход по истории — маленькие треугольнички слева в заголовке. А>На сером фоне — заголовки текущей темы.
А>Тулбар с окошком поиска раскрывается по нажатию на маленькую прозрачную кнопку справа вверху — это стандартный системный способ убирать панель инструментов.
интересно. Визуально, конечно, мерзостно , а вот с точки зрения логики — по-моему, должно быть неплохо.
У кого-нибудь есть впечатления от регуляного, повседневного использования?
Здравствуйте, Real 3L0, Вы писали:
R3>>>1. Иногда делают автозакрытие нефокусных веток. ЗХ>>
R3>Почему? По мне так очень удобно, не болтается нунужная инфа перед глазами — это и есть самая главная проблема дерева.
Неа. Главная проблема дерева — потеря "пути". Ты перестаешь понимать где находишься, хотя изначальная цель дерева — именно "навигация с птичьего полета".
Всякие разновидности принудительного сокрытия части дерева — это уже не дерево. Это ближе к WebDirectory
Здравствуйте, Real 3L0, Вы писали:
ЗХ>>[остальное поскипал — не могу, спать хочу]
R3>Как проснешся, расскажи, почему автосворачивание — плохо.
Не само по себе плохо (хотя — это оооочень спорный вопрос). Плохо — когда стандартное с виду дерево начинает вести себя непредсказуемым способом, который разработчику этого данного дерева показался жутко удобным.
Для стандартного treeview автосворачивание неестественно, так как не вытекает из его внешнего вида, а оказывается "прилепленной сверху" функциональностью.
ЗХ>>Там было вообще-то довольно интересное обсуждение, как раз в рамках моего "древоборчества".
R3>Знаю, читал. Только обсуждаемое там относилось к деревьям форумов и януса в частности.
...что, во-первых, вполне вписывается в рамки ветки "Конкурс: сруби дерево", а во-вторых, ты первый о форумах заговорил.
Dog>>Можно автоматически сворачивать\разворачивать только корневые ветки. ЗХ>Как говаривал подполковние Тюпич, "монопенисно". Правило все равно нарушается.
Фактически это будут автоматические списки внутри которых будет дерево настроек.
Просто мне нравится идея настроек в AVP. Большинство юзеров не интересует тонкая настройка приложения. В том же Янусе вынести в общие настройки "Общие настройки", настройки пользователя, сетки, стили, может ещё надёргать чего (уже не помню) и сгруппировать внутри деревом максимум 2 уровня. Остальное всё в лес(Expert). Идея объединяет собой закладки (боковые) и деревья. Как раз 2 стиля чаще всего использующихся для форм с настройками.
... что-то я начал отвечать на "Конкурс: сруби дерево" , а закончил "И опять про настройки" уж и не знаю куда постить
Здравствуйте, Dog, Вы писали:
Dog>Просто мне нравится идея настроек в AVP. Большинство юзеров не интересует тонкая настройка приложения. В том же Янусе вынести в общие настройки "Общие настройки", настройки пользователя, сетки, стили, может ещё надёргать чего (уже не помню) и сгруппировать внутри деревом максимум 2 уровня. Остальное всё в лес(Expert). Идея объединяет собой закладки (боковые) и деревья. Как раз 2 стиля чаще всего использующихся для форм с настройками.
Хм. Насчёт АВП — я всегда иду (ходил точнее ) в лес(Expert) — настройки должны быть если они реально необходимы, и если они есть, они должны быть видны, иначе того глядишь и недонастроишь чего-то там.
А сами настройки как раз ужасно не нравятся в нём...
Необъяснимо.
Здравствуйте, Mamut, Вы писали:
ЗХ>>>Кто скажет, что это удобно — откушу ухо.
А>>Согласен, бездарно
M>Есть еще Finder для MacOS, где файлы отображаются в дереве каталогов.... Да и WinXP, где архивы отображаются в дереве каталогов
В Файндере есть чудный режим отображения каталогов в колонки. Кто скажет, что это не лучший способ отображения иерархической информации -- откушу Зверьку ухо .
Суть его в том, что первоначально корневой уровень показан в виде колонки. Когда выбираешь один из узлов -- справа появляется следующая колонка с подузлами этого узла. Выбираем среди этих подузлов -- еще правее появляется третья колонка... И так далее. При таком способе представления :
а) путь не теряется -- он перед глазами
б) ничего лишнего на вьюхе нет (типа других открытых корневых узлов).
Недостатки -- занимает довольно много места, (но это оправдано), горизонтальный скроллинг при большой глубине дерева.
Мне кажется бенефит такого диалога именно когда настроек много — и их количество может увеличиваться, скажем, с установкой плагинов. В противном случае обычный таб-пейдж может показаться куда более естестетственным и привичным решением. ИМХО разумеется.
Здравствуйте, <Аноним>, Вы писали:
ЗХ>>Для затравки: вот очень, между прочим, неплохой контрол.
А>Где?
А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
это мы, Зверьки!
FAQ — це мiй ай-кью!
Re: Конкурс: сруби дерево ;)
От:
Аноним
Дата:
06.04.05 11:36
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView). ЗХ>Используют его где надо и где не надо, а контрол, между прочим, не очень хороший и далеко не всегда уместный.
ЗХ>В общем, в рамках этой ветки предполагается обсуждать следующие темы: ЗХ>1. Когда TreeView уместен ЗХ>2. Когда TreeView не уместен ЗХ>3. Какие можно найти/изобрести альтернативные контролы для представления альтернативной информации
TreeView хорош, когда возможность навигации по дереву продублирована в других контролах. Например, в ListView справа. Иначе тупые узвери не догоняют, как пользоваться. На счёт хороший/не хороший спорить не буду. Кому то кроме командной строки больше ничего не нужно. Но, вообще, смотрится эффектно.
Здравствуйте, Dog, Вы писали:
ЗХ>>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации. Dog>Много места занимает
Ну, это всего один из вариантов. Есть случаи, когда он уместен. Ну и — не так уж и много он места занимает
это мы, Зверьки!
FAQ — це мiй ай-кью!
Re[3]: Конкурс: сруби дерево ;)
От:
Аноним
Дата:
06.04.05 11:52
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, <Аноним>, Вы писали:
А>>TreeView хорош, когда возможность навигации по дереву продублирована в других контролах. Например, в ListView справа. Иначе тупые узвери не догоняют, как пользоваться. На счёт хороший/не хороший спорить не буду. Кому то кроме командной строки больше ничего не нужно. Но, вообще, смотрится эффектно.
ЗХ>Не, я не против дерева как класса. Я против misuse. Например, когда имеем дерево с большим количеством элементов и глубокой вложенностью, получаем такую вот охренительную навигацию: ЗХ>
ЗХ>Кто скажет, что это удобно — откушу ухо.
И в Священных Войнах
ЗХ>ЗЫ: Как тебе такая мысль — только что стукнуло:
ЗХ>[skip: прикольный скриншот]
Хых. По-моему, неплохо. Но есть одно но — убивается привычный селект, что для многих может стать камнем преткновения.
Кстати, за что я бы убивал — за потерю фокуса с любого scroll-контрола (listbox, treeview — не суть важно), как это происходит в индексе MSDN. Нельзя пользоваться колесом мышки
... << RSDN@Home 1.1.4 beta 4 rev. 0>> ... <<Winamp is playing "Kenji Kawai — 10 Kugutsuuta kagirohi ha yomi ni mata muto">> ...
Здравствуйте, Mamut, Вы писали:
ЗХ>>>Кто скажет, что это удобно — откушу ухо.
А>>Согласен, бездарно
M>Есть еще Finder для MacOS, где файлы отображаются в дереве каталогов.... Да и WinXP, где архивы отображаются в дереве каталогов
Своей головой надо думать, а не на Finder для MacOS смотреть.
ЗХ>>>>Кто скажет, что это удобно — откушу ухо.
А>>>Согласен, бездарно
M>>Есть еще Finder для MacOS, где файлы отображаются в дереве каталогов.... Да и WinXP, где архивы отображаются в дереве каталогов
А>Своей головой надо думать, а не на Finder для MacOS смотреть.
Это я осуждающе говорил. В том смысле, что осуждал Finder и WinXP
... << RSDN@Home 1.1.4 beta 4 rev. 0>> ... <<Winamp is playing "Kenji Kawai — 07 Kugutsuuta aratayo ni kamutsudo hite">> ...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>>Для затравки: вот очень, между прочим, неплохой контрол.
А>>Где?
ЗХ>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
Програма не сайт, так много информации в ней редко бывает. Кроме того, TreeView даёт самую важную вещь — позволяет пользователю ориентироваться в пространстве. И здесь он луше любых "крошек" на сайте.
Здравствуйте, Слава Шевцов, Вы писали:
ЗХ>>>>Для затравки: вот очень, между прочим, неплохой контрол.
А>>>Где?
ЗХ>>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
СШ>Програма не сайт, так много информации в ней редко бывает.
Если помнишь, я тебе показывал скрин программы, где я вполне успешно использовал эту идею.
СШ>Кроме того, TreeView даёт самую важную вещь — позволяет пользователю ориентироваться в пространстве. И здесь он луше любых "крошек" на сайте. Ориентируйся на здоровье!!!
Dog>>зы. Несколько раз сталкивался с таким , что юзверю не понятно что за пункт в дереве сейчас выбран (плохая селекция) или что вообще надо на дерево тыкать, что бы перейти на другую страницу настроек. Имхо, дерево в настройках надо какнить раскрашивать, не оставлять голым. Иконки около главных пунктов, что бы привлечь внимание, обязательны. ЗХ>К слову, мне нравится, как это сделано в диалогах настроек Firefox/Thunderbird (вот, кто не видел):
Помню же что где-то видел
Ещё бывает добавляют стрелочку к выбранному узлу.
Здравствуйте, дровосек Зверёк Харьковский, Вы писали:
ЗХ>>>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации. СШ>>Програма не сайт, так много информации в ней редко бывает. ЗХ>Если помнишь, я тебе показывал скрин программы, где я вполне успешно использовал эту идею.
Помню.
СШ>>Кроме того, TreeView даёт самую важную вещь — позволяет пользователю ориентироваться в пространстве. И здесь он луше любых "крошек" на сайте. ЗХ>Ориентируйся на здоровье!!!
Ну чего здесь смешного? Доступ в данном случа а-ля контрол Yahoo будет тоже очень проблематичен. Хотя бы потому, что для отображения этого длинного списка длинный лист-бокс тебе всё равно придётся организовать. Разница лишь в скорости работы контрола: в дереве ветку можно сокрыть нажатием на минус, в Yahoo-контроле придётся подняться на этаж выше.
То есть. Yahoo — это взгляд на лабиринт изнутри. TreeView — взгляд на лабиринт с высоты. Где ориентироваться легче?
Кроме того, скорость визуального поиска в TreeView — 25 строчек в секунду. Скорость поиска в Yahoo-интерфейсе в разы медленней. Кроме того, худший для поиска случай (отсутствие информации) для Yahoo очень плохой.
Единственный существенный минус, который я вижу у TreeView, это величина (точнее мелкость) квадратика, который позволяет свернуть/развернуть ветку.
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, дровосек Зверёк Харьковский, Вы писали:
ЗХ>>>>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации. СШ>>>Програма не сайт, так много информации в ней редко бывает. ЗХ>>Если помнишь, я тебе показывал скрин программы, где я вполне успешно использовал эту идею.
СШ>Помню.
Ну?
СШ>>>Кроме того, TreeView даёт самую важную вещь — позволяет пользователю ориентироваться в пространстве. И здесь он луше любых "крошек" на сайте. ЗХ>>Ориентируйся на здоровье!!!
СШ>Ну чего здесь смешного? Доступ в данном случа а-ля контрол Yahoo будет тоже очень проблематичен.
[..и прочее в том же духе]
Слав! В этой ветке я не пытаюсь доказать, что все TreeView в мире нужно заменить на WebDirectory.
Я пытаюсь доказать, что:
а) во многих случаях TreeView подходит слабо — следует придумать что-то другое.
б) иногда в качестве этого другого можно использовать WebDirectory.
В частности для МСДНа — нет, я не считаю WebDirectory хорошим решением.
СШ>Единственный существенный минус, который я вижу у TreeView, это величина (точнее мелкость) квадратика, который позволяет свернуть/развернуть ветку.
То есть удобство содержания МСДНа тебя вполне устраивает?
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView).
Про деревья в опциях.
Всё, что показывалось и обсуждалось, как вы заметили — это 3х уровневые деревья. И это рулит! По моему, обычному челу для обхвата взглядом самое то. Причем желательно не выделять первый уровень одним элементом.
Про новые деревья. Когда дерево больше 3х уровней.
1. Иногда делают автозакрытие нефокусных веток.
2. Предложу вообще скрытие нефокусных веток, но необходимо показывать, что там что-то есть.
3. Пункт 2 плюс: первый уровень — родитель фокусного элемента, второй уровень — дети родителя, если у родителя есть дети — не раскрывать ветку, а помечать плюсом. При выборе другого элемента — перерисовка дерева начиная с начала абзаца.
Здравствуйте, Real 3L0, Вы писали:
R3>Про новые деревья. Когда дерево больше 3х уровней. R3>1. Иногда делают автозакрытие нефокусных веток.
R3>2. Предложу вообще скрытие нефокусных веток, но необходимо показывать, что там что-то есть.
Не понял. Куда скрытие?
R3>3. Пункт 2 плюс: первый уровень — родитель фокусного элемента, второй уровень — дети родителя, если у родителя есть дети — не раскрывать ветку, а помечать плюсом. При выборе другого элемента — перерисовка дерева начиная с начала абзаца.
Совсем-совсем не понял. Нарисовать можешь?
Здравствуйте, Зверёк Харьковский, Вы писали:
R3>>1. Иногда делают автозакрытие нефокусных веток. ЗХ>
Почему? По мне так очень удобно, не болтается нунужная инфа перед глазами — это и есть самая главная проблема дерева.
R3>>2. Предложу вообще скрытие нефокусных веток, но необходимо показывать, что там что-то есть. ЗХ>Не понял. Куда скрытие?
Ну удаление что ли.
Item1
- Item2
- Item3 - фокус
Хотя на самом деле дерево имеет вид
Item1
- Item2
- Item3
- Item22
Трудность — показать, что Item22 существует.
R3>>3. Пункт 2 плюс: первый уровень — родитель фокусного элемента, второй уровень — дети родителя, если у родителя есть дети — не раскрывать ветку, а помечать плюсом. При выборе другого элемента — перерисовка дерева начиная с начала абзаца. ЗХ>Совсем-совсем не понял. Нарисовать можешь?
Item1
+ Item2
- Item22
Фокус может быть на Item2 или Item22. При нажатии на + у Item2 (или даблклик) дерево превращается в:
Dog>>зы. Несколько раз сталкивался с таким , что юзверю не понятно что за пункт в дереве сейчас выбран (плохая селекция) или что вообще надо на дерево тыкать, что бы перейти на другую страницу настроек. Имхо, дерево в настройках надо какнить раскрашивать, не оставлять голым. Иконки около главных пунктов, что бы привлечь внимание, обязательны. ЗХ>К слову, мне нравится, как это сделано в диалогах настроек Firefox/Thunderbird (вот, кто не видел):
Ну, не они первые. У МС это давно есть в стандартных диалогах Сохранить/Открыть, но там эта идея очень сильно извращена, ИМХО
... << RSDN@Home 1.1.4 beta 4 rev. 0>> ... <<Winamp is playing "Kenji Kawai — 10 Kugutsuuta kagirohi ha yomi ni mata muto">> ...
Здравствуйте, Зверёк Харьковский, Вы писали:
R3>>Почему? По мне так очень удобно, не болтается нунужная инфа перед глазами — это и есть самая главная проблема дерева.
ЗХ>Неа. Главная проблема дерева — потеря "пути". Ты перестаешь понимать где находишься, хотя изначальная цель дерева — именно "навигация с птичьего полета".
В первых двух моих пунктах (особенно во втором) как раз и выделяется путь на самое видное место.
Кстати, в янусовском форуме несколько раз поднималась тема (в том числе и мной) о возможности автосокрытия подветок с прочитанными сообщениями — народ не хочет видеть, заострять внимание на ненужной инфе.
ЗХ>Всякие разновидности принудительного сокрытия части дерева — это уже не дерево. Это ближе к WebDirectory
, но мимикрирующему под дерево, что пользователей запутывает.
Ну я бы сказал не совсем. В WebDirectory путь выносится из дерева, что с одной стороны не удобно для тех, кто много лазает по всему дереву, но с другой стороны удобно тем, кто часто ходит только в одной подветке. У меня же путь остается в дереве.
Здравствуйте, Real 3L0, Вы писали:
ЗХ>>Господа, Зверёк обяъявляет неделю борьбы с деревьями (TreeView).
R3>А ты где живешь, что у тебя неделя начинается в среду?
Дома живу. Выхожу на улицу только дочку выгулять. сутки/неделя/месяц начинаются тогда, когда мне того хочется. И заканчиваются соответственно.
Поэтому прошу меня извинить — ушел спать. Вернусь утром (~23-24 по Киеву )
[остальное поскипал — не могу, спать хочу] R3>Кстати, в янусовском форуме несколько раз поднималась тема (в том числе и мной) о возможности автосокрытия подветок с прочитанными сообщениями — народ не хочет видеть, заострять внимание на ненужной инфе.
Ооооо... наш родной Янус — одна из больных тем с точки зрения деревьев. Ваш покорный Зверёк уже поднимал её в размерах Длинной телеги о деревьях
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>[остальное поскипал — не могу, спать хочу]
Как проснешся, расскажи, почему автосворачивание — плохо.
ЗХ>Там было вообще-то довольно интересное обсуждение, как раз в рамках моего "древоборчества".
Знаю, читал. Только обсуждаемое там относилось к деревьям форумов и януса в частности.
Здравствуйте, Real 3L0, Вы писали:
ЗХ>>... сутки/неделя/месяц начинаются тогда, когда мне того хочется. И заканчиваются соответственно.
R3>Господь Бог?
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Для стандартного treeview автосворачивание неестественно, так как не вытекает из его внешнего вида, а оказывается "прилепленной сверху" функциональностью.
Так, я не понял, мы тут собрались обсуждать создание нового дерева или как изменить не изменяя?
ЗХ>...что, во-первых, вполне вписывается в рамки ветки "Конкурс: сруби дерево"
+1. Тогда что мы видим: универсальное дерево мы врятли получим => надо выделить несколько типов деревьев.
Здравствуйте, Real 3L0, Вы писали:
ЗХ>>Для стандартного treeview автосворачивание неестественно, так как не вытекает из его внешнего вида, а оказывается "прилепленной сверху" функциональностью.
R3>Так, я не понял, мы тут собрались обсуждать создание нового дерева или как изменить не изменяя?
Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview
ЗХ>>...что, во-первых, вполне вписывается в рамки ветки "Конкурс: сруби дерево"
R3>+1. Тогда что мы видим: универсальное дерево мы врятли получим => надо выделить несколько типов деревьев.
ЗХ>Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview
Можно автоматически сворачивать\разворачивать только корневые ветки.
Здравствуйте, Dog, Вы писали:
ЗХ>>Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview Dog>Можно автоматически сворачивать\разворачивать только корневые ветки.
Как говаривал подполковние Тюпич, "монопенисно". Правило все равно нарушается.
F> Хм. Насчёт АВП — я всегда иду (ходил точнее ) в лес(Expert) — настройки должны быть если они реально необходимы, и если они есть, они должны быть видны, иначе того глядишь и недонастроишь чего-то там.
Загляните в Янус в настройки стиля. Кроме настройки картинок кнопок всё от лукавого. А шоркаты ? Я понимаю есть индейцы, но имхо большинство пользуются мышью.
F> А сами настройки как раз ужасно не нравятся в нём... F> Необъяснимо.
Просто вид жуткий.
F>> Хм. Насчёт АВП — я всегда иду (ходил точнее ) в лес(Expert) — настройки должны быть если они реально необходимы, и если они есть, они должны быть видны, иначе того глядишь и недонастроишь чего-то там. Dog>Загляните в Янус в настройки стиля. Кроме настройки картинок кнопок всё от лукавого. А шоркаты ? Я понимаю есть индейцы, но имхо большинство пользуются мышью.
Это от того, что некоторые жизнено необходимые шоткаты на клаве отсутствуют
... << RSDN@Home 1.1.4 beta 4 rev. 0>> ... <<Winamp is playing "Kenji Kawai — 02 Kugutsuuta ura mite chiru">> ...
Здравствуйте, Mamut, Вы писали:
А>>Секундочку — при чем здесь Finder? В OSX, по крайней мере, вроде нет древовидного представление, аналогичного эксплореру.
M>Как это нет? Папки и файлы там никто не отменял:
M>
M>Здесь видим вообще извращение:
M>
M>Ну или вообще вот такое:
M>
M>"A good idea gone terribly bad"
Во-во-во! Об этом я и говорю, это не извращение, а классная находка. Может быть, это дело вкуса, но я не видел, чтобы коллеги (рядом их куча) пользовались другим режимом Файндера, или жаловались на этот...
Здравствуйте, Зверёк Харьковский, Вы писали:
R3>>Так, я не понял, мы тут собрались обсуждать создание нового дерева или как изменить не изменяя? ЗХ>Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview
Возьмем EditBox (связанный с БД) или ComboBox, у которых есть такая "кустомная фичка": в зависимости от введенного текста подставляется окончание. В Excele это вроде называется автозаполнение. Выходит, это тоже неправильно?
ЗХ>>>...что, во-первых, вполне вписывается в рамки ветки "Конкурс: сруби дерево" R3>>+1. Тогда что мы видим: универсальное дерево мы врятли получим => надо выделить несколько типов деревьев. ЗХ>Во! О чем я толкую!!!
Следовательно вывод второй: дерево рубить надо не везде!
Здравствуйте, _wqwa, Вы писали:
_>Недостатки -- занимает довольно много места, (но это оправдано), горизонтальный скроллинг при большой глубине дерева.
Ты забыл один мега недостаток: имитируем непроизвольное движение мышью (+ клик) аля "пьяный чел за компом" и посмотрим сколько времени ты будешь выбирать элемент, расположенный на 5м уровне.
Здравствуйте, Real 3L0, Вы писали:
R3>>>Так, я не понял, мы тут собрались обсуждать создание нового дерева или как изменить не изменяя? ЗХ>>Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview
R3>Возьмем EditBox (связанный с БД) или ComboBox, у которых есть такая "кустомная фичка": в зависимости от введенного текста подставляется окончание. В Excele это вроде называется автозаполнение. Выходит, это тоже неправильно?
Для ComboBox это поведение естественно (а не "сбоку прилеплено"): есть выпадающий список, значение из которого можно выбрать мышью или клавиатурой.
Для EditBox'а — не знаю Не помню, чтобы мне такое встречалось.
ЗХ>>>>...что, во-первых, вполне вписывается в рамки ветки "Конкурс: сруби дерево" R3>>>+1. Тогда что мы видим: универсальное дерево мы врятли получим => надо выделить несколько типов деревьев. ЗХ>>Во! О чем я толкую!!!
R3>Следовательно вывод второй: дерево рубить надо не везде!
Цитирую исходное сообщение:
...в рамках этой ветки предполагается обсуждать следующие темы:
1. Когда TreeView уместен
2. Когда TreeView не уместен
3. Какие можно найти/изобрести альтернативные контролы для представления альтернативной информации
Здравствуйте, Зверёк Харьковский, Вы писали:
R3>>>>Так, я не понял, мы тут собрались обсуждать создание нового дерева или как изменить не изменяя? ЗХ>>>Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview
R3>>Возьмем EditBox (связанный с БД) или ComboBox, у которых есть такая "кустомная фичка": в зависимости от введенного текста подставляется окончание. В Excele это вроде называется автозаполнение. Выходит, это тоже неправильно?
ЗХ>Для ComboBox это поведение естественно (а не "сбоку прилеплено"): есть выпадающий список, значение из которого можно выбрать мышью или клавиатурой. ЗХ>Для EditBox'а — не знаю Не помню, чтобы мне такое встречалось.
Встречалось. Браузеры так показывают предыдущие значения в набираемом поле (см. поле поиска для Гугля). И при вводе адреса в Outlook Express такое наблюдается. В Far есть такая же настройка при вводе имени создаваемого файла. Практически новостандартная вещь.
Здравствуйте, Слава Шевцов, Вы писали:
R3>>>>>Так, я не понял, мы тут собрались обсуждать создание нового дерева или как изменить не изменяя? ЗХ>>>>Я еще раз повторяю: поведение контрола должно вытекать из его внешнего вида. Для TreeView, который самостоятельно сворачивает ветки, когда ему захочется — это правило не выполняется. То есть менять надо, но радикальнее, не прикручивая "кустомные фички" к обычному treeview
R3>>>Возьмем EditBox (связанный с БД) или ComboBox, у которых есть такая "кустомная фичка": в зависимости от введенного текста подставляется окончание. В Excele это вроде называется автозаполнение. Выходит, это тоже неправильно?
ЗХ>>Для ComboBox это поведение естественно (а не "сбоку прилеплено"): есть выпадающий список, значение из которого можно выбрать мышью или клавиатурой. ЗХ>>Для EditBox'а — не знаю Не помню, чтобы мне такое встречалось.
СШ>Встречалось. Браузеры так показывают предыдущие значения в набираемом поле (см. поле поиска для Гугля). И при вводе адреса в Outlook Express такое наблюдается. В Far есть такая же настройка при вводе имени создаваемого файла. Практически новостандартная вещь.
Согласен, облажамшись
В контесте же оригинального вопроса:
Возьмем EditBox (связанный с БД) или ComboBox, у которых есть такая "кустомная фичка": в зависимости от введенного текста подставляется окончание. В Excele это вроде называется автозаполнение. Выходит, это тоже неправильно?
Ответ — нет, это вполне правильно. Это не "фичка", это новый "контрол" — подсказка с выбором. Все в порядке.
А>>Тулбар с окошком поиска раскрывается по нажатию на маленькую прозрачную кнопку справа вверху — это стандартный системный способ убирать панель инструментов.
ЗХ>интересно. Визуально, конечно, мерзостно , а вот с точки зрения логики — по-моему, должно быть неплохо. ЗХ>У кого-нибудь есть впечатления от регуляного, повседневного использования?
Регулярно больше пользуешься поиском, чем навигацией по дереву, поэтому я его чаще всего держу скрытым.
На самом деле только верхний уровень иерархии-- это не очень практично, но с помощью этого псевдо-деревянного контрола можно сузить круг поиска (и по определениям, и полнотекстового), а это -- уже удобно . Поэтому, контролы-контролами, а думать, как их правильно использовать -- все равно приходится.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Не, я не против дерева как класса. Я против misuse. Например, когда имеем дерево с большим количеством элементов и глубокой вложенностью, получаем такую вот охренительную навигацию: ЗХ>
А может быть добавить тултип, который будет показываться при наведении на элементы дерева. Выровнять левый край тултипа по корневому списку, и в нем показывать путь к элементу, который не видна из-за большого кол-ва элементов. Если навести на черту, которая показывает вложенность — менять тултип, укорачивая пуь нужным образом.
По крайней мере путь наверх можо будет узнать.
да и вообще, мои кривые ручки наваяли нечто вот такое (настройки пока еще не утрясены, этот диалог — просто 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'ом. Не давать его выбирать вообще.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, <Аноним>, Вы писали:
ЗХ>>>Для затравки: вот очень, между прочим, неплохой контрол.
А>>Где?
ЗХ>А прямо по ссылке. Каталог Гугла — это иерархически организованная информация. По ссылке можно увидеть неплохой способ представления такой информации.
Здравствуйте, 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, но в не столь отдаленном будущем мне как раз такое вот и понадобится
ЗХ>Мняяя... Не знаю. Мне не очень нравится непривычностью. То ись у пользователя может возникнуть вопрос "это оно почему так выделено? какая-то особенная страничка или так, для красоты?" Тем более, красный — цвет, символизирующий "внимание!" или "ошибка!".
Ну, треугольник может быть любого цвета и размера
ЗХ>Я бы предпочел: ЗХ>- сменить цвет неактивной строки на кастомный (по-моему, не должно быть намного сложнее добавления картинки) ЗХ>- или сделать так, как я в свое время предлагал
Перекуём баги на фичи!
А с закладками сверху смотрится вообче ужасно. Бедный юзверь потеряется. 
Тем более, что и настроек там будет — кот наплакал.
