Slava_BT автор
Никакая?
т.е. виноваты пользователи? ;)
автор
Если конструктивно...
Что нужно дать такому пользователю, чтобы он все-таки "хоть что-то" нашел?
Что нужно ему дать, чтобы он еще и правильно нашел?
Что нужно ему дать, чтобы он еще и вставил так, чтобы другие нашли?

пользователю нужно наглядное представление о множествах в системе.
Фильтрация такой возможности не даёт.
А что дает? Дерево?

Slava_BTСоответственно для удобного поиска ноутбуков можно сделать два\три уровня ..... Ноутбуки -> диагональ в дюймах -> тип процессора -> (в полученном списке сортировка по цене и\или другим полям)
по этому этот пример недостаков считаю притянутым за уши.
Как скажете.

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

И вот, пришёл новый работник .... и как он разберётся в этой куче сохранённых фильтров?? или будет делать свои???
Эм... Вы скорее всего невнимательно прочитали.
"могли запоминать часто используемые фильтры"
Если часто используемых фильтров будет куча, то как будет чувствовать себя иерархия?

Slava_BT
авторНеобходимо, чтобы пользователь мог выбрать значение фильтра из списка. Так, например, разрешение матрицы лучше не набивать каждый раз, а выбирать из готового списка разрешений. То же самое касается остальных фильтров.

Если все значения фильтруемых полей буду вибиратся из списка ... не проще ли для пользователей эти списки разложить в иерархию???
В каком порядке?
Вы подумайте.

grexhideИ что тут сложного ? Сделайте две (три, четыре) формы
Жалко, что вы не смогли прочитать.
Это предложение звучало уже несколько раз.

Контрвопрос - кто будет заполнять эти формы?

Кидман...что оптимальное количество всех элементов в иерархии(с ветвями не более семи) равняется, если не ошибаюсь, 960792 штукам или менее.
Угу.

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

Про Borland - совершенно не случайно.

LSVЧто касается ссылки на статью в mazzy.ru, то скриншоты, которые показывают использование фильтров (как альтернативу дереву) содержат окна с.....деревьями
И как это поможет ответить на изначальный вопрос: "должна ли современная система иметь многоуровневые справочники?"

LSV"Древовидные клиссификаторы имеют смысл в только однопользовательских системах" ... Какая чушь ! Они имеют смысл там, где есть чёткий "общеизвестный" критерий классификации.
Обожаю, когда одну вещь определяют через другую.
Давайте дальше: когда есть этот критерий?

partner_351Если не задаваться идеями построить всеобщий классификатор всего и вся типа википедии, а пытаться решить практические задачи, то ИМХО:

1. Чем больше предприятие, тем важнее для него корпоративные стандарты, включая и классификацию услуг, изделий, товаров и работ. Естественно, что работники должны знать и соблюдать эти стандарты.
Это утверждение имеет свои пределы.
Пример общедоступный - википедиа.
Пример не очень очевидный - msdn, otn.
Пример закрытых баз знаний - корпоративные интрасети в Майкрософт, ИБМ.

partner_351"Причем эти люди могут и не знать общепринятых правил (например, они могут не знать "корпоративных стандартов" :) ) Многоопльзовательская система должна быть устойчивой и должна быть эффективной при таких условиях. ".

Что сказать - таких людей надо учить, и, если не поможет - увольнять. Кроме того, есть такое замечательное средство распределение прав доступа и им надо пользоваться.
Как и другие устверждения в этой ветке, это тоже имеет свои пределы применимости.
Каковы они?

partner_351Действительно, могут возникнуть проблемы с отнесением той или иной позиции к нужной ветви справочника. Однако, это все решается в рабочем порядке.
Возмите price.ru
Возьмите прайс-лист продуктов Майкрософт.
Возьмите прайс-лист, например, Евросети.
Возмите другие прайс-листы.

При каких условиях ваше утверждение применимо?


partner_3512. Количество уровней хоть и декларируется неограниченным, но на практике например, для справочника номенклатуры редко встречал количество уровней более 3-х уровней. Кроме того, в самой ветви, имеющей подветви допускается наличие записей, которые относятся к этой ветви, но не к подветвям. Это позволяет также помогает решать проблемы по п.1. Естественно, есть возможность группового перемещения замаркированных записей из одной ветви в другую.
Вы не задумывались почему?

partner_3514."Поиск по всему множеству записей отменяет многоуровневость."
Наличие разных способов только дополняет друг друга. Дайте пользователю выбрать способ поиска по своему усмотрению. Глобальный поиск - это дополнительное средство поиска/отбора нужных записей.
Кто ж спорит.
Должна ли современная система иметь многоуровневый справочник?

partner_3515. "Никому не нужно средство работы с данными, если оно не работает.
Для того, чтобы такое средство работы заработало (извините за тавтологию), нужно чтобы кто-то наполнил иерархию и постоянно поддерживал ее в целостности.
Кто это будет, какие затраты для этого "кто-то" потребуются?
Какими свойствами должен обладать справочник и система, чтобы этот "кто-то" справился с достаточной степенью вероятности?"

Многое зависит от интерфейса, который и определяет комфортность работы пользователя. А насчет того, что "не работает" это утверждение просто голословное. Я то знаю, что работает, и пользователи это ценят.
Отлично.
Сколько у вас элементов в справочнике?
Сколько пользователей?

partner_3516. "Предположим я ваш пользователь. Расскажите какие задачи я смогу выполнять более эффективно и более удобно при помощи маркировки."
На эту тему можно написать много, но я думаю, что это есть во многих системах. Это и динамический пересчет итоговой строки, и возможность вывода на экран только маркированных записей (фильтр), и способ выделения записей для их дальнейшей групповой обработки (например, групповой замены, автоформирования документов, распределения сумм по колонки, печати, выгрузки в другие форматы, запуска расчетов, добавления маркированных записей справочника в предметы документа и многое другое.
Угу. Вы продемонстрировали замечательный подход настоящего программиста.
Вы привели задачи программиста: Пересчет... Вывод на экран... групповая обработка... автоформирования документов...

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

Я полностью согласен, что маркировка точно поможет решить программистские задачи.
Вы точно уверены, что маркировка поможет пользователям решить ИХ задачи?
Я точно уверен, что маркировка НЕ поможет решить задачу пользователя.
Маркировка - один из способов общения с комьюптерными сущностями.
И не самый удобный надо отметить... (Посмотрите вокруг - где вы еще видите маркировку?)

partner_3517. "И снова возвращаемся к исходному вопросу: должны ли современные системы содержать многоуровневые справочники в обязательном порядке? "

Я смотрю на этот вопрос исключительно с практической, а не теоретической стороны. И для себя этот вопрос давно решил. Дайте в руки пользователя необходимые инструменты и он будет вам благодарен.
Не спорю.
Какие инструменты являются необходимыми и в каких случаях?

partner_351Кстати, я забыл отметить такое удобство иерархического справочника, как задание различной видомости колонок по различным ветвям. Только не спрашивайте, в чем удобство. Подумайте над этим сами на примере ветвей номенклатуры "Часы", "Трусы" и "Ювелирные изделия".
Это не иерархия.
Различную видимость можно настроить на признаки классификации.
Классификация не обязательно должна быть иерархией.

СисойА в 1С трудоемкость оформления классификаций по одному признаку нисколько не напрягает программиста.
Ну... готов поспорить насчет не напрягает...
Но это не главное.

Прозвучал критерий - ОДНОМУ признаку.
Иерархия "не напрягает" только при ОДНОМ признаке?
Сколько признаков все еще будут ненапряжными?

СисойИ с точки зрения пользователя, выглядит очень удобно и вполне естественно.
Я устал задавать вопрос "чем удобно?"
и приводить ссылку на раздел "Являются ли иерархические справочники удобными"
http://axapta.mazzy.ru/lib/tree/

СисойПо крайней мере, для небольших и нечасто изменяющихся классификаторов.
А вот с этим не спорю.

А для больших справочников?
Где граница применимости?

СисойЯ понимаю, что достали уже с вопросами типа "Почему в Аксапте аналитики "плоские""? "Почему не как в 1С"?
Ты неправильно понимаешь.
1. Аналитики в Аксапте иерархические http://axapta.mazzy.ru/lib/dimension_hierarchy/
2. Слава богу, что не как в 1С.

В Аксапте как и в другой системе деревьев дохрена.
Здесь уже показывали скриншоты. Есть еще много.
Закончим про Аксапту? Закончим про 1С?

Пожалуйста, не скатывайтесь в частные системы.

=========================
Вот уже на седьмой ветке вижу только ответы
= "а в Аксапте тоже есть дерево",
= "неужели в Аксапте сложно сделать",
= "А в 1С трудоемкость оформления классификаций по одному признаку нисколько не напрягает программиста",
= "удобно - потому что удобно всегда",
= "потому что даже в корпоративных стандартах пишут"...
За очень редким исключением...
Стоит совсем отчаятся?

И если кто-нибудь даже
Захочет, чтоб было иначе,
Опустит слабые руки,
Не зная, где сердце спрута
И есть ли у спрута сердце...
(С) Стругацкие

=========================
Может наконец кто-нибудь четко привести в чем состоит удобство дерева и границы применимости дерева для современных систем?

Кто не согласен с этим тезисом и почему?

iscrafm mazzyЯ устал задавать вопрос "чем удобно?"
и приводить ссылку на раздел "Являются ли иерархические справочники удобными"

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

-- To improve usability, the customer tree (hierarchy) is provided.

-- It further enhances its previous strong usability features by providing quick drill-down capabilities through Explorer (or tree-type) navigation.

-- Consistent tree structures improve the usability of information, especially for non-technical users.

Но вот в чем беда, mazzy, они немного портят ваши рассуждения и лучший способ, конечно, их игнорировать
Угу. Перевожу вслух.

-- Чтобы улучшить юзабилити, было добавлено дерево (иерархия) клиентов
-- Эта замечательная хреновина добавила зашибательскую юзабилити за счет возможности навигации как в Explorer
-- Охренительная иерархическая структура улучшила юзабилити информации, особенно для пользователей без технического образования...

iscrafm, эти фразы ничуть не лучше "удобно, потому что удобно всегда" и других заклинаний.

Еще раз спасибо за ваше конструктивное и полезное участие.

iscrafmА вообще, с иерархией нужно уметь работать, чтобы не наживать геммороя на ровном месте, тогда и вопросов лишних не будет возникать. И конечно не сувать ее где не попадя.
Угу. Все участники только эти критерии и привели.
"не сувать где ни попадя", "со здравым смыслом", "уметь работать"...

Но никто кроме меня и George Nordic не привел критериев (или я пропустил?).
А критерии простые - дерево удобно только для небольших справочников и небольшого количества пользователей...

Абсолютно нераскрытыми остались темы группировки в отчетах, поиска в иерархиях, принадлежности к нескольким группам, можно ли оптимально работаьт с иерархическими структурами в реляционных СУБД... и другие...

Вопрос - а есть ли лучшее представление - участниками, похоже, даже не осознан.

Я, пожалуй, пойду в read only...
Cпасибо всем.