Структурирование информации в автономном блоге

Структура блога или информационная архитектура - такая коварная штука, которая неожиданно может оказаться трясиной для автора. У блога и болота есть одно несомненное общее - когда понимаешь, что увяз, сделать уже ничего нельзя.

Часто автор ведёт электронный дневник довольно длительное время и вдруг ему становится очевидно, что что-то идёт не так: давнишние материалы трудно отыскать, в тегах страшная путаница, рубрикатор не влазит в экран. При этом во многих рубриках количество опубликованных материалов зашкаливает за сотню. Встаёт резонный вопрос: что со всей этой кучей материалов делать?

В системе управления содержимым (СУС)* uCoz реализован модуль "Блог", который имеет классическую архитектуру: обратный хронологический порядок, календарь и архив. Новые материалы выводятся на главной странице блога, и каждый материал имеет свою отдельную страницу с комментариями. Для поиска материалов предполагается использовать календарь, архив и теги. Точно такая же архитектура имеет место в "Живом журнале". За десять лет такое структурирование информации в блоге показало свою неэффективность - на глаза читателю попадаются только недавние записи, в то время как старые, но не менее интересные, пропадают в "небытии" архива.

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

Такая ситуация возникает из-за непонимания некоторыми авторами различий между типами информации. Блог в своём классическом архитектурном представлении предназначен для публикации записей вида "что вижу, о том и пою" - информации 1 типа. Увидел звёздочку в небе - написал в блог, наступили на ногу в троллейбусе - написал в блог и так далее. Однако некоторых авторов время от времени пробивает на "многабукав", и вот эти объёмные интересные материалы буквально тонут в бездне отрывочных злободневных постов. Эти красивые статьи представляют собой 2 тип материалов, который подразделяется на информационно-ознакомительные материалы (обзоры, рецензии, исследования) и прикладные материалы (кулинарные рецепты, инструкции, "сделай сам" и прочие). Авторы, страдающие графоманией, тягой к философствованию и подобными тяжкими недугами могут выделять отдельный, 3 тип информации - графоманские сочинения.

Сегодня очевидно для многих, что столь отличающиеся типы текстовой информации уже не могут быть эффективно структурированы в рамках традиционной архитектуры блога. При желании, что все четыре вышеозначенных типа можно уместить в uCoz'овском модуле "Блог". В этом случае я предлагаю основную ставку сделать на рубрикатор и облако тегов, а от календаря и архива отказаться вовсе.

Рубрикатор или список категорий блога - довольно коварная штука. Число категорий может определяться авторами исходя из предпочитаемых тем. Например, пишу я о коврах, следовательно, выделяю категорию "Ковры". Если я пишу на 674 различные темы, то, надо полагать, у меня будет 674 категории. При этом в некоторых из них у меня будет по три записи, а некоторые будут фактически дублировать друг друга (например, "Ковры", "Напольные покрытия" и "Половики"). То же самое происходит с метками (тегами). Пока автор почувствует неладное, категорий, меток и материалов может накопиться просто бешеное количество, а единственным выходом из положения будет оставить всё в текущем виде.

В СУС uCoz есть ещё один мощный модуль "Каталог статей". В рамках данного модуля реализуется более сложный тип структурирования, что позволяет хранить и систематизировать гораздо большее число записей. Все материалы "Каталога статей" можно разделить на разделы, а в каждом разделе создать множество категорий. Средствами данного модуля можно структурировать все типы информации, кроме 1-го, так как для него создан целый отдельный модуль "Блог". Например, в "Статьях" можно создать разделы "Сделай сам" (прикладные материалы), "Обзоры" (статьи описательного характера с множеством фотографий), "Рассказики" (графоманские сочинения). Я решил пока не использовать разделы, а дать подобные названия категориям. В модуле "Каталог статей" также реализована поддержка меток.

На площадке Polyotov.ru я реализовал разделение по двум основным типам информации. В блоге, который я назвал "Лентой" публикуется маленькое. В "Статьях" - более ценная и долгосрочная информация. Но со временем в каждой категории-типе (разделе-типе) может накопиться несколько сотен записей. Если это произойдёт, то разобраться с ними средствами СУС uCoz будет невозможно (вероятно, также как и средствами любых других СУС), так как uCoz не позволяет разом выделить все необходимые материалы и одним кликом изменить их категорию и/или метки. В связи с этим роль вторичного структурирования информации в блоге отводится меткам.

Метка вообще служит для быстрого поиска материалов одним кликом. Нажал - получил список всех материалов с данной меткой. Все отображённые таким образом материалы должны иметь безусловное общее. Это важное условие. Если пользователь зашёл на сайт по поисковому запросу и ему понравился данный материал блога, то пользователю, вероятно, захочется найти все прочие материалы автора по запрашиваемой теме. Пользователь жмёт на метку, и СУС должна выдать ему список всего, что автор написал именно по этой теме. В выданном списке не должно быть ничего лишнего.

Чтобы эффективно структурировать материалы в блоге по меткам, я решил опробовать следующие правила:
1. Оптимальное число меток - 2, максимальное число меток - 3. Например, часть постов содержит видеоклипы, следовательно я ставлю метку "видео", чтобы пользователь мог одним кликом найти все материалы с видеороликами. Но видеоклипы принадлежат к разной тематике. Если пользователь считает, что у автора отменный нюх на шокирующее видео, то блогеру следует поставить рядом с меткой "видео" метку "шок". Тогда пользователь сможет значительно сузить круг своих поисков по постам с видеоклипами и быстро отыскать интересующие его "шокирующие" ролики.
2. В материалах 1 типа ("что вижу, о том и пою") ставить единственную метку в исключительных случаях. Понятно, что это делается для избежания засорения "облака тегов".
3. Ограничить разнообразие меток. Необходимо для исключения повторяющихся по смыслу тегов. Например, "кино", "фильм", "кинолента" можно объединить в одну метку "кино".
4. Не применять меток слишком широкого или слишком узкого охвата. К "широким" относятся метки типа "инструкция", "эксплуатация", "оптимизация". К "узким" относятся названия компьютерных программ, отдельных телепередач, торговых марок и т.д. Например, автор размещает в блоге видеоклип из телепередачи "Клуб Весёлых и Находчивых" и присваивает ему тег "квн", а другому видео, теперь уже из шоу "Уральских пельменей", присваивает тег "пельмени". Целесообразнее обоим роликам присвоить одну метку, например, "шоу".
5. Метками могут быть только существительные в единственном числе на русском языке. Это очевидно, ведь метки создаются для пользователей, а не для автора. Если пользователь в незнакомом русскоязычном блоге увидит в облаке метку "assignment", то он может элементарно не понять, что это значит. Да и такое откровенное неуважение к родному языку может настроить русскоязычных пользователей против автора вне зависимости от того, знают они иностранный язык или нет.

Публикации:

1. Кириллович А. Информационная архитектура блогов. 23.03.2010 г.

* - англ. content management system, CMS.

Записи по теме: