версия для печатиОт редакции: Пять лет назад автор этой статьи и его читатели (в комментариях) неплохо пофантазировали о будущих инструментах для создания персональных информационных сред, вырастающих из личных блогов. Нам показалось, что именно сейчас, в связи с очередной волной бегства из "Живого Журнала", будет интересно поднять из архива эти прогнозы 2006 года - и сравнить с реальностью.
Интернет-среда хороша тем, что в ней неплохо уживаются два противоположных тренда: с одной стороны, пользователи сбиваются в стаи (комьюнити) на блог-платформах, а с другой - уходят из комьюнити в "одиночное плавание". Единство и борьба этих противоположностей, наверное, и определяют дальнейшее развитие блогосферы.
Блог-платформы (блогарии) и hosted blogs - это уже готовые технологические решения, где пользователю остается только писать, не задумываясь над техническими вопросами. Кроме того, уровень социализации очень высок. Для новичка это очень удобный выбор, чем и объясняется высокая популярность блогариев и дневниковых сервисов.
Но готовое технологическое решение, как правило, не дает пользователю свободы маневра (в техническом плане как минимум). Поэтому те, - на stand-alone ("отдельно стоящие") блоги.
Хорошим аналогом, наверное будет "деревня vs. хутор". На хуторе надеяться можно только на себя и свои силы - зато можно делать все, что угодно (в пределах разумного). Как минус - недостаток социальных связей.
Если развитие блогариев определяется трендами и обкатанными технологиями (то есть путь мейнстрима), то со stand-alone блогами все сложнее, поскольку в них все упирается только в технологические пределы и богатство фантазии. Но реализованные в них новинки возвращаются, как бумеранг, в блогарии (блог-платформы), чтобы стать мейнстримом.
Поэтому дальше мы рассмотрим один из путей развития stand-alone блогов. Но сначала немного о сервисах.
Сервисы общие и частные
Ситуация с блогами повторяет ситуацию с веб-сервисами в целом. С одной стороны, концентрация сервисов на портале (в интегрированной среде) удобнее для пользователя - все в одном месте и друг с другом может взаимодействовать. А с другой стороны - 150 сервисов под разные задачи в портал не впихнешь. Кроме того, stand-alone сервис, как правило, функционально богаче и действует по принципу "если программа решает только одну задачу, то решать должна ее хорошо".
Обратная сторона этого принципа - пользователю приходится регистрироваться на множестве сервисов и держать их (точнее, их адреса) под рукой. Взаимодействие этих сервисов между собой тоже под вопросом. Понятно, что это неудобно. Поэтому пользователю приходится решать нетривиальную задачу: или идти на портал и пользоваться "простыми" сервисами (которые всегда "под рукой"), или бегать между мощными stand-alone сервисами. Кроме того, нередкой будет ситуация, когда возможностей портального сервиса будет недостаточно, или нужный сервис просто отсутствует на портале. А ведь запросы пользователя растут быстрее, чем за ними может поспеть портал.
Получается, что с точки зрения пользователя, надо сделать все наоборот ("избушка, повернись к лесу задом, а ко мне передом"): это не пользователь должен приходить на сервис, а сервис должен приходить к нему и предлагать свои услуги. Вопрос, однако, в том, куда должен приходить сервис.
Блог как информационная система
Некоторые пессимисты полагают, что stand-alone блогам (далее SAB) развиваться некуда - за прошедший год, например, Wordpress ничего нового и революционного не принес (кроме разве что многопользовательской версии ). На самом же деле, отдельно стоящим блогам есть куда эволюционировать. Качественно эволюционировать.
Предпосылок к этому три:
- для посетителя важна не сама информация "as is", а то, как она представлена, и какую пользу из нее можно извлечь (семантический путь использования)
- развитие различных форм контента (аудио, видео, микроконтент), развитие сервисов и социализация пользователей Сети
- возможности хостинга, на которых стоят SAB, кроме самого SAB позволяют реализовать все, что угодно в рамках имеющихся ресурсов.
Поэтому следующим логичным шагом будет превращение (как из гусеницы в бабочку) блога из "просто блога" в персональную информационную систему, сокращенно PIFS (personal information system). Это означает, что информация не только представлена в различных формах (аудио, видео, текст, графика, микроформаты), не только упорядочена и систематизирована, но и взаимосвязана - ничего в информационной системе не валяется "просто так".
Написать текст (статью, заметку) или разместить фотку - это только начало. Основное - эффективно и органично встроить ("вплести") его в персональную инфосеть, а не просто понатыкать как иголок тагов или ключевых слов. В результате вся информация оказывается вплетенной в паутину, потянул на ниточку - вытянулись все связанные ресурсы. Подробнее о работе с такой информационной Тканью будущего можно почитать в "", в главах о Вэри.
В инфосеть удобно встраивать внутренние сервисы, например органайзер, мини-вики и различные подсистемы для работы с микроконтентом. Не только для себя, любимого, но и делегировать права доступа другим. Это позволит, например, планировать и синхронизировать встречи, сообщать друзьям "график занятости" и т.д.
К PIFS можно "прикрутить" и внешние сервисы, если внутренние не дают нужной функциональности. Либо на основе доверительной передачи управления, либо на основе двустороннего API. Это так же позволит делать импорт-экспорт данных с сервисов и обратно. Либо в качестве резервных (рабочих) копий, либо в качестве промежуточных результатов, если обработка идет по цепочке сервисов.
Кстати, наличие API позволяет развернуть распределенную многоуровневую социальную сеть между разными PIFS.
Фактически пользователь получает не только персональную информационную систему, но и опорную точку присутствия, без необходимости распылять внимание на несколько ресурсов.
Проблема управления: не просто поток
Но как управлять этим "хозяйством"? То, что раньше легко укладывалось в достаточно простую "админку", потребует сложных и нетривиальных подходов к обработке и связыванию информации. В обычном браузере это будет не так легко сделать (хотя это будет сильным стимулом для разработки ajax-приложений нового поколения), поэтому потребуются более продвинутые методы управления контентом со стороны "производителя" - ICDE (integrated content development system) вместо блог-клиента. Такие системы уже существуют (например, ), но для PIFS потребуется серьезная адаптация и модернизация (для работы в условиях постоянной динамики).
Интересно, что не так давно компания Six Apart, владелец "Живого журнала", пыталась сделать нечто подобное информационой сети. Но то, что ожидалось от Project Comet в качестве первого серьезного шага, разработчик "не осилил". Сервис , который получился в результате этой затеи, не оправдал возложенных на него надежд. Скорее всего, причина этого - в подходе. Вместо создания расширяемой архитектуры на микроядре Six Apart пошел по более простому пути - "пути Лего", когда система собирается из готовых (и уже опробованых) блоков.
Тем не менее, отдельные элементы PIFS уже внедряются в некоторые движки SAB. Например, проектировался так, что способен поддерживать любой тип и любой вид (presentation) документа. Кроме того, там есть встроенный органайзер и средства работы с микроконтентом. , после небольших доработок, позволяет вести вполне функциональную персональную wiki. А распределенная социальная сеть не реализована пока только потому, что разработчикам SAB лень этим заниматься.
Следует заметить, что переход к PIFS будет не слишком простым, так как потребует изменения сознания автора в самом подходе к информации. Ведь "разработка контента (content development)" - это не "обмен потоками сознания" (как это обычно происходит в блогах и дневниках), а серьезное приложение мозгов.
Но это будет потом - когда мы будем жить в обществе, победившем Web 2.0.
