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

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

Архив от февраля 2007 г.

Здесь сайту быть!

Приобрел домен для каталога: Internet Resource Directory. Публичная русскоязычная бета-версия каталога ожидается в середине марта 2007 года.

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

Вебмастер регистрирует ресурс. При управлении сайтом, в личном кабинете, нажимает на кнопку (указывает пункт) "Я бы хотел, чтобы реклама не отображалась на страницах с описаниями моего сайта в течение месяца". И реклама действительно не отображается в течение данного периода. Щедро. Двояко приятно. Думаю вебмастеры оценят данную функцию. Обязательно реализую.

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

Объясняю. Регистрация пользователей на интернет-ресурсе доступна только через других пользователей (Бррр... бред? Не уверен, нужно лишь подумать над этой проблемой, наверняка есть альтернативные пути ее решения).

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

Корневой пользователь при этом подтверждает или опровергает возможность регистрации (реализовать это можно более удачным способом). Если пользователь подтверждает его регистрацию - то он доверяет вновь зарегистрированному пользователю и несет ответственность за его действия.

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

Если рассматривать техническую сторону модели: сам уровень доверия - число в диапазоне от нуля до единицы. Уровень доверия пользователя не может быть выше, чем уровень доверия у пользователя, под которым он зарегистрирован. Таким образом, если один из пользователей, "запортачивших" что-то на ресурсе регистрирует под собой некоторых других пользователей, их уровень доверия не может быть высоким, а может и оказаться вовсе нулевым.

Мораль: лучше выбирайте друзей.

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

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

Еще недомыслено: понижение уровня доверия пользователя, одобрившего регистрацию пользователя-хулигана.

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

interface element set

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

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

click on the menu

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

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

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

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

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

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

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

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

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

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

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

Иногда на крупных проектах встречаются сообщения подобные этому:

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

(more...)

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 копии, одну из них относит специалисту по анализу гипертекстовых документов - Николаю Анатольевичу, а вторую - Алексею Данилычу, специалисту по цензуре. После проведения анализа Анатолич и Данилыч формируют соответствующие заключения о доступности сайта, показатели его релевантности, содержании бранных выражений и относят их назад - Петровичу. Петрович формирует заключение и сообщает пользователю о возможности публикации ресурса: регистрирует его или отклоняет заявочку.

Красота...