Интерфейс интернет-каталога должен быть простым. В нем не должно быть ничего лишнего. Навигация должна быть максимально упрощена. Идеальная модель обзора каталога: клик-клик-клик-результат. Вот что пока получилось:

И, какой-то он, все-таки, ущербный, этот интерфейс. Итак, по мелочам:

Навигация по разделам: необходимо переделывать 100%. То, что сэкономили с использованием AJAX -- то и откликнулось в юзабилити -- стало затруднительно использовать наиболее частоупотребимые элементы навигации. Каждый раз для посещения дочернего раздела приходится кликать по меню "Разделы" и ждать пока отобразится вот такая вот портянка:

Все-таки часть этой портянки (блок "Структура текущего раздела") придется вернуть на страницу, без этого совершенно неудобно. Затем, хлебные крошки тоже нужно убрать из этой портянки, т.к. они и так уже есть на странице, здесь их дублировать не за чем.

Далее. Сукафлаг: британский или американский? Вы тоже не знаете? Текстом пишете?

Еще бесит: расстояние от левого края до ссылки в меню "Разделы" и то же расстояние до навигационного элемента "Раздел: Компьютеры / Интернет" (см. первый рисунок). Нужно выровнять.

Какая-то херь с margin'ами у поля контента. Тоже необходимо выровнять (думаю слева сделать больший отступ).

Далее. Сниппеты. Нужны ли они? Если да, то в каком виде? Из доступных материалов есть: Заголовок, полное описание ресурса, ключевые слова (они же теги), раздел, даты регистрации, публикации, последнего изменения, да все что угодно, вопрос в том: нужно ли это? В любом случае политика каталога в плане поиска интересующего ресурса: "пользователь сначала попадает на страницу с описанием самого ресурса, а затем уже, если ресурс его заинтересовал, то и на сам ресурс", важна обратная связь от пользователей и терять ее нельзя.

Заголовок каталога. То, что на сером фоне вверху. Я убежден, что в шапке сайта не должно быть написано, что мол так и так, каталог такой-то, а вот и логотип наш, красивый, не так ли? Подход ущербный. Нужно максимум информации о ресурсе, и, самая важная информация такого рода - это заголовок самого ресурса. Он должен быть больше на порядок самого текста описания и выделяться среди остального контента. Вот заголовок, как я считаю, здесь хорошо получился. Оспорьте, пожалуйста.

Навигационное меню. Должно быть сукапростым. Еще проще. Думаю пункт "Настройки" - в топку. Нужно перенести этот пункт в "Личный кабинет".

Хлебные крошки (обведено фиолетовым на первом рисунке). Думаю будет удобно ими пользоваться. Но, привлекают слишком много внимания.

Еще: индикатор "степени важности" ресурса - так называемый "взвешенный рейтинг" - показатель, по которому ресурсы ранжируются в каталоге. Его нужно как-то отображать: или графически или числом. Числом хуже воспринимается. Графически: не совсем понятно как это сделать (в DMOZ'е он отображается зеленой полоской - смотрится это рвотно, воспринимается... да непонятно как воспринимается, не помню чтобы я эти полоски когда-либо воспринимал как полезную информацию).

В красном кружке: мегарвотный элемент, которого не должно быть в каталоге. Совсем. Думаю над этой проблемой, решить пока не могу. Постраничная навигация... Ненавижу.

Это todo-список к интерфейсу в режиме обзора раздела. Про режим просмотра описания ресурса я пока вообще молчу. Там тихий ужас. Адская избыточность информации на "квадратный пиксель" вашего монитора.

Вот пишу я тут про семантику, синдикацию, Дублинское ядро; думаю о возможности интеграции каталога с другими интернет-сервисами, (полу)автоматизированном управлении каталогом при помощи интеллектуальных модулей, о возможности работы с пользователями, комментируемыми записями.

Это что, простите, ресурс Web 2.0 получается?

Очень хотелось бы применить Dublin core в создаваемом в настоящее время каталоге ресурсов интернет.

Встал вопрос:

А как лучше использовать DC? Использовать элементы DC в мета-тегах страницы или же вынести их в отдельный документ http://somehost.com/dir-resource/7/dc/ и там отображать XML/RDF с Дублинским ядром?

Наверное, нужно копать глубже. Нужно, прежде всего, понять каким образом DC-элементы будут использоваться потребителями. А кто такие потребители? Пользователи, у которых есть специальное ПО, которое может читать Дублинское ядро (надстройка в браузере)? Или все же это интеллектуальные роботы, которые "бороздят" просторы сети, ищут в документах какой-то смысл? А есть ли такие интеллектуальные агенты? Будут ли они в ближайшем будущем? Вот в чем вопрос.

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

PS: Всем известно, что некоторые роботы-агенты поисковых систем получают и используют мета-элемент страницы "description", а будут ли они понимать и использовать мета-элемент "DC.description", входящий в стандарт Dublin Core?

Как часто в последнее время приходится читать фразы в стиле:

"[...] И, все-таки, мы решили перейти от иерархических классификаторов к облакам тегов. Это позволит нашим пользователям [...]"

Закономерность? Эволюция? Заблуждение?

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

• Фолксономическая категоризация: блог, топка, интернет, каталог, поисковые системы.
• Таксономическая категоризация: Интернет - Персональные страницы - Блоги - Блоги о поисковых системах.

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

Фолксономический подход лишен этого недостатка: можете привязать объект к любым узлам. Однако, в последнем подходе отсутствует всяческая структура, т.е. нет элементарных отношений (род-вид) между узлами. Таким образом, нельзя выявить объекты, носящие более общий или более частный характер.

В каждом из подходов есть свои плюсы. Так почему бы их не объединить и не использовать одновременно? Я не вижу ничего плохого в том, что, например, в каталоге, помимо строго определенных иерархических рубрик, пользователи, регистрирующие сайты, указывали бы и некоторые метки (теги, ключевые слова - назовите это как угодно).

В результате использования такого фолксо-таксономического подхода можно было бы организовать более удобную, семантическую навигацию. По моему, это будет достаточно удобно.

Недавно взглянул на график загрузки процессора хостинговой компании приложениями моего аккаунта и оказалось, что я отъедаю в среднем 5% времени процессора.

Думал каким образом лучше/проще снизить нагрузку на сервер на котором будет работать новый каталог. Одни из наиболее трудных и тяжелых запросов: получение дерева разделов каталога. Можно, конечно, реализовать иначе: уйти от структуры "id-parentid" и перейти к вложенным множествам (nested sets), но было решено все же оставить id-pid, т.к. уж слишком много на этом завязано.

Нагрузку же снижать следующим образом: подгружать иерархическое дерево разделов по требованию (ведь, если задуматься, действительно: "Зачем пользователю постоянно видеть иерархию разделов? Если она ему нужна, пусть перейдет по ссылке и получит необходимую информацию.")

Таким образом сэкономил 3 операции: получение backStack'а разделов (хлебных крошек), получение подразделов текущего раздела, получение корневых разделов. Думаю что бы еще на AJAX-запросы по требованию перенести.

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

Заходит пользователь в каталог. Переходит на страницу регистрации ресурса. Его встречает некий интеллектуальный модуль Порфирий Петрович, специалист по регистрации интернет-ресурсов, и предлагает оформить заявочку на регистрацию сайта. Заявочка заполняется, Порфирий "снимает" 2 копии, одну из них относит специалисту по анализу гипертекстовых документов - Николаю Анатольевичу, а вторую - Алексею Данилычу, специалисту по цензуре. После проведения анализа Анатолич и Данилыч формируют соответствующие заключения о доступности сайта, показатели его релевантности, содержании бранных выражений и относят их назад - Петровичу. Петрович формирует заключение и сообщает пользователю о возможности публикации ресурса: регистрирует его или отклоняет заявочку.

Красота...