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

Требования к навигации:
* быстрый переход к точно известному объекту (я точно знаю, что это за файл и где он лежит)
* удобный поиск к приблизительно известному объекту (старенькая песня группы Металлика)
* предложение выбора, когда я точно не знаю, что мне нужно (а что у нас есть по C++?)

Подходы бывают такими:

1. Плоский список (наивный подход)
Просто список вообще всех объектов, какие у нас есть. Несмотря на наивность подхода, в сочетании с дополнительными графическими средствами (выделение элементов списка цветом, шрифтом, иконками) и гибкой сортировкой может быть достаточно удобен.

2. Иерархия
Случай файловой системы. Папки, в каждой — другие папки и объекты. Система, в общем, общепринятая, но обладает некоторыми недостатками.

* если папок немного (мы предполагаем, что объектов много), то в каждой из них находится большое количество объектов — возвращаемся к случаю (1) — найди свой файлик в папке где их 10 000.
* если папок много — файлы по ним распределяются, как правило, неравномерно. Возникает множество случаев вроде

Programming
    Languages
        Scripting
            Python
                Official Manuals
                    Python.chm

(Хотя уже внутри папки Scripting всего 8 вложенных файлов, для порядка у нее еще куча подпапок)
* логика иерархии не всегда очевидна (потому как вышеозначенный Python вполне себе мог оказаться в Web-Design/Server/Languages или еще где)

3. Поиск
Тоже понятная вещь — Гугль тебе в руки и электричку навстречу. Про достоинства и недостатки, думаю, все сами понимают.
На мой вкус, поиск вещь для большой базы необходимая, но как единственный метод навигации, применяться не должен (пожалуйста, не приводите в опровержение Internet. А если приводите — пожалуйста, не пользуйтесь гиперссылками и закладками).

4. Ссылки
Ссылки. Имеем кучу объектов и ссылки между ними. Метод поиска нужного — от объекта к объекту по ссылкам, пока не придем куда шли.
Недостатки понятны: ссылки — вещь произвольная, длина и существование пути между двумя некоторыми объектами — величина случайная.

5. Отбор
Изначально имеем список всех доступных в базе объектов, но используя различные критерии фильтрации, сужаем список, до объема в котором объект комфортно "найти глазами".

Мой выбор: отбор + поиск (+ опционально ссылки).

ЗЫ: на самом деле этот пост — естественно, о том, что отбор предпочтительней иерархии

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>ЗЫ: на самом деле этот пост — естественно, о том, что отбор предпочтительней иерархии

Иерархия — это вырожденный случай фильтрации (по единственному, фиксированному пути).
В конце концов, никто не мешает выводить список всех-всех-всех файлов и подпапок данной папки; спускаясь, мы это множество сужаем
А спуск по рубрикатору может производиться по разным траекториям.
— Программирование — языки — скриптовые — питон — мануал — python.chm
— Животные — программирование — питон — мануал — python.chm
— Мануалы — python.chm (больше мануалов не нашлось )

Интересный вопрос при этом: какие пункты должны попасть в верхний уровень рубрикатора, а какие — нет.
Скажем, питон — наряду с ещё сотней языков программирования, или же питон доступен, а перл нет?..
То ли здесь важен индекс популярности, то ли ещё какие-то метрики, то ли систему надо настраивать.

Здравствуйте, Кодт, Вы писали:

ЗХ>>ЗЫ: на самом деле этот пост — естественно, о том, что отбор предпочтительней иерархии

К>Иерархия — это вырожденный случай фильтрации (по единственному, фиксированному пути).
К>В конце концов, никто не мешает выводить список всех-всех-всех файлов и подпапок данной папки; спускаясь, мы это множество сужаем

Вот когда они будут выводиться — тогда иерархия и будет частным случаем фильтрации

К>А спуск по рубрикатору может производиться по разным траекториям.
К>- Программирование — языки — скриптовые — питон — мануал — python.chm
К>- Животные — программирование — питон — мануал — python.chm
К>- Мануалы — python.chm (больше мануалов не нашлось )

К>Интересный вопрос при этом: какие пункты должны попасть в верхний уровень рубрикатора, а какие — нет.
К>Скажем, питон — наряду с ещё сотней языков программирования, или же питон доступен, а перл нет?..
К>То ли здесь важен индекс популярности, то ли ещё какие-то метрики, то ли систему надо настраивать.

Мммм... Не понял. Тут имеется в виду все же иерархический рубрикатор?

Здравствуйте, Кодт, Вы писали:

К>Интересный вопрос при этом: какие пункты должны попасть в верхний уровень рубрикатора, а какие — нет.
К>Скажем, питон — наряду с ещё сотней языков программирования, или же питон доступен, а перл нет?..
К>То ли здесь важен индекс популярности, то ли ещё какие-то метрики, то ли систему надо настраивать.

Наверх ИМХО (по опыту 1С) должны попасть наиболее редкие храктеристики товара. Т.е. например есть справочник номенклутуры товаров и услуг. В нем много элементов (10к и выше у средней торговой компании). там впрос решается названием "Пиво Балтика №3" — "Балтика №3 Пиво". Т.е. если человек при локаторном поиске ткнет "балтика", он уже фактически будет стоить на продукции балтики, а как вы понимаете это значительно меньше чем фильтр по "пиво".

Наводящий вопрос: а пользователь знаком со справоником, или же он его видит в первый раз?
Дело в том что от этого изменится оптиммальный способ поиска.

Здравствуйте, wraithik, Вы писали:

W>Наводящий вопрос: а пользователь знаком со справоником, или же он его видит в первый раз?
W>Дело в том что от этого изменится оптиммальный способ поиска.

Интересно. А в какую сторону?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, wraithik, Вы писали:

W>>Наводящий вопрос: а пользователь знаком со справоником, или же он его видит в первый раз?
W>>Дело в том что от этого изменится оптиммальный способ поиска.

ЗХ>Интересно. А в какую сторону?

Ну если человек не значет структуры справочника — то поиск по не точному совпадению (релативный поиск вроде назвается, такое писал один раз).

А если знает. То дополнительные классификаторы + иерараххия + локаторный поиск рулят. Но только если справоник хоршо структуриован и пользователь это знает.

Здравствуйте, wraithik, Вы писали:

W>>>Наводящий вопрос: а пользователь знаком со справоником, или же он его видит в первый раз?
W>>>Дело в том что от этого изменится оптиммальный способ поиска.

ЗХ>>Интересно. А в какую сторону?

W>Ну если человек не значет структуры справочника — то поиск по не точному совпадению (релативный поиск вроде назвается, такое писал один раз).

W>А если знает. То дополнительные классификаторы + иерараххия + локаторный поиск рулят. Но только если справоник хоршо структуриован и пользователь это знает.

Т.е. отбор Вы отвергаете вааще?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, wraithik, Вы писали:

W>>>>Наводящий вопрос: а пользователь знаком со справоником, или же он его видит в первый раз?
W>>>>Дело в том что от этого изменится оптиммальный способ поиска.

ЗХ>>>Интересно. А в какую сторону?

W>>Ну если человек не значет структуры справочника — то поиск по не точному совпадению (релативный поиск вроде назвается, такое писал один раз).

W>>А если знает. То дополнительные классификаторы + иерараххия + локаторный поиск рулят. Но только если справоник хоршо структуриован и пользователь это знает.

ЗХ>Т.е. отбор Вы отвергаете вааще?

Нет. Вы меня не верно поняли. Есть куча элеметов. Есть Н классификаторов. Для ?каждого? классфикатора у элемента создается своство. Т.е. человек допустим сперва по свойству "Вид товара" выберет "Пиво" (т.к. классификатор видов товаров на порядки меьше классификатора товаров, то выбор будет произведен быстро) ну и т.д.

И Кодт выше заметил верно, что иерахи — частный случай отбора (от себя — это отбор по родителею).

Я просто хотел сказть — что "серебряной пули" нет. Т.е. все решается комплексно и по разному (для разных задач поиска). А сам бы рекомендовал сперва масксимально сузить количество элементов (т.е. все возможные фильтры), а потом заниматься поиском.

ЗХ>Допустим, у нас есть база "чего-то". Скажем, книжек в библиотеке, файлов на компьютере, программ на сервере, музыки и фильмов...
ЗХ>Нужно: обеспечить навигацию по этой базе (размер базы неограничен, но заведомо велик).

ЗХ>Требования к навигации:
ЗХ>* быстрый переход к точно известному объекту (я точно знаю, что это за файл и где он лежит)
ЗХ>* удобный поиск к приблизительно известному объекту (старенькая песня группы Металлика)
ЗХ>* предложение выбора, когда я точно не знаю, что мне нужно (а что у нас есть по C++?)

Есть сайт такой, corbis.com, там гигантская база изображений. Каждому изображению дается набор ключевых слов (тагов), по котороиу это изображение можно найти. Обычно ключевые слова включают в себя место, где фотография снята, все предметы на изображении, действия, совершаемые на картинке. Сами ключевые слова рядом с изображением, конечно, не выводятся, но к любой картинке можно добраться по последним двум пунктам

Здравствуйте, Зверёк Харьковский, Вы писали:

Посмотри классификатор в evernote(.com).
Имхо очень правильно сделано.

Есть категории — это тэги в простонародье. Какждая нота может принадлежать
многим категориям. Тыкаешься в списке категорий в "Питон" — он строит дерево —
по всем нотам с Питон какие еще категории есть — пересечение.

Т.е. если есть две ноты с тэгами
Питон, Программирование
и
Питон, Кормежка.

То "думатель" тебе построит автоматически дерево.

Питон
 + Программирование 
 + Кормежка

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

Имхо, категории и лента это самый "цимус" в evernote.
Думаю тебе имеет смысл перенять.