Блог Ярослава Витязева

Персональный комментируемый блог

Архив для рубрики ‘Интернет-каталоги

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

interface element set

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

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

click on the menu

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

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

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

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

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

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

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

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

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

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

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

Web 2.0

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

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

Элементы Дублинского ядра (Dublin core)

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

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

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

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

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

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

Фолксономия и/или таксономия

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

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

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

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

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

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

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

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

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

Снижение нагрузки на сервер при помощи AJAX

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

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

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

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

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

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

Красота...