О гибкости интерфейсов, связанных с таксономией

13.06.2009

Версия для печати

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

На сайте medsputnik.ru подразумевалось, что информацию можно будет делить на части, свойственные заболеваниям или проблемам со здоровьем, которые имеют свои симптомы. Когда возникла необходимость выложить на сайт материал о головной боли, которая сама является не чем иным как симптомом, то возник вопрос чем заполнить соответствующий обязательный раздел? Решение было выбрано, прямо скажем, неудачное: концентрация слов «симптомы» и «головная боль» большая, да только в предлагаемых статьях пишется о другом. Например, статья «Головная боль при приеме алкоголя» лежит в подразделе «Как симптом» раздела «Симптомы». Хотя какие еще нужные дополнительные признаки тяжелой головы с похмелья?

К чем этот поток сознания пример? Любой интерфейс, завязанный на таксономию, должен быть ГИБКИМ и позволять исключать-добавлять-переименовывать, как минимум.

P.S.
А еще на медспутнике подраздел назван как раздел («Симпотомы Симптомы»). Отдельное фи.

#:-) #cookbook #интерфейсы #разработка ПО


Комментарии

Подписаться на комментарии через RSSПодписаться

Для добавления комментария необходимо авторизоваться любым из способов:



Реклама