Что такое корпоративное вики?

Марк Чоут

Программное обеспечение для вики-систем существует с 1995 года, но, пожалуй, последняя вариация вики – это то, что принято называть «корпоративным вики» (компания InfoWorld объявила 2004 год «Годом корпоративного вики»). Повышенный интерес к корпоративному вики появился в результате возрастающего числа таких компаний, как Disney, Nokia, и Yahoo!, которые обратились к вики как к способу повысить эффективность внутренней работы компании.

Но если мы посмотрим на вики в контексте работы предприятия, мы столкнемся с двумя важными вопросами:

●     В чем состоит разница между вики и CMS? Можем ли мы добавить к функциям существующей CMS-системы еще и обслуживание вики? 

●     Готовы ли инструменты вики для использования в компаниях? Иными словами, одобрит ли их мой IT-директор?

Ниже я постараюсь ответить на оба этих вопроса.

Вики и контент-менеджмент

Вики – это общедоступный веб-сайт, в котором пользователи могут создавать и редактировать страницы. Концепция вики подпадает под широкую концепцию управления веб-контентом, и, конечно же, для создания вики-сайта можно использовать имеющуюся CMS. Однако вики имеют уникальные характеристики, которые отличают их от обычных систем управления веб-контентом.

Вики делают акцент на простоте создания контента. Это простота является следствием многих причин:

●     язык разметки вики, который обеспечивает простоту форматирования текста и создания ссылок между документами;

●     возможность для пользователей напрямую и независимо создавать и редактировать страницы;

●     восходящий подход к структуре и навигации сайта;

●     очень простое создание шаблонов;

●     осознанное решение отказаться от рабочего процесса или даже просто от согласования страниц.

Давайте рассмотрим каждую из этих причин по очереди.

Создание и редактирование контента

Вики дает пользователям возможность создавать и редактировать свои собственные страницы, но ведь и системы управления веб-контентом также предоставляют инструменты для создания и редактирования контента. Разница состоит в подходе. Когда вики впервые появилось (в 1995 году), существовало не так уж много возможностей для редактирования того, что видишь на экране (WYSIWYG) внутри браузера, поэтому язык разметки вики (иногда называемый «викитекст») давал очень ценную и очевидную возможность форматирования текста, которой легче обучиться, чем языку HTML.

Хорошие CMS-системы предлагают интерфейс WYSIWYG, который позволяет создавать содержимое страницы почти так же, как обычный текстовый редактор. Сейчас большинство вики-систем имеют функции WYSIWYG-редактирования, поэтому язык разметки вики становится менее привлекательным в части функции форматирования, хотя он действительно обеспечивает выгоду в том смысле, что совместим со всеми браузерами на всех платформах, что обычно не относится к редакторам форматированного текста. Многие вики поддерживают как викитекст, так и редакторы форматированного текста. На рисунке ниже показан пример редактора из Wikipedia, которая поддерживает обе формы форматирования контента.

Редактирование страницы из Wikipedia

Однако существует одна область, в которой викитекст все еще удерживает свои позиции и где программное обеспечение вики отличается от CMS – это создание ссылок. В вики легче связывать страницы одну с другой. Связи создаются на основе заголовка страницы, поэтому автору не нужно использовать, запоминать или набирать длинные URL для того, чтобы связывать страницы между собой. Краткое описание того, как это работает, можно найти на странице записи о вики в Википедии.

Структура сайта и навигация

Поскольку создатели сайта могут легко создавать новые страницы и легко связывать одну страницу с другой, вики имеет уникальный подход к структуре и навигации сайта.

В CMS обычно используется формальный подход к структуре и навигации сайта, при котором сайт преобразуется разработчиком в иерархию страниц. В вики создание пользовательских страниц приводит к тому, что иерархия и структура сайта создается неупорядоченным образом. Навигация стремится к простоте, а иерархия плоская. Например, в онлайн энциклопедии Wikipedia имеются сотни тысяч статей на самые разнообразные темы, но эти темы не организованы в какую-либо концептуальную иерархию. Поиск информации о собаках служит хорошим примером. URL для статьи о собаках выглядит так: http://en.wikipedia.org/wiki/Dog

Мопс (англ. pug) - это порода собак, и URL на статью о мопсах выглядит следующим образом: http://en.wikipedia.org/wiki/Pug

Поскольку мопс - это порода собак, то можно ожидать, что URL для поиска информации о мопсах будет выглядеть так: http://en.wikipedia.org/wiki/Dog/Pug

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

Хранилище контента и API

Опытные системные администраторы или архитекторы всегда зададут вопрос о любой предлагаемой технологии управления контентом: «Как выглядит хранилище данных?». Они должны думать о совместимости, эффективности, резервном копировании и массе подобных проблем.

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

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

Этот вопрос приводит к вопросу об API. Большинство вики его не имеют. Хотите получить доступ к вики через ваш портал или интегрировать с CMS для интранета? Сейчас приходится обращаться к поставщику системы. В дальнейшем, я надеюсь, что большее количество вики откроют свои системы для интеграции с другими корпоративными пакетами.

Шаблоны

Когда запрашивается страница викитекста, она преобразуется в HTML двухступенчатым процессом. Сначала разметка вики преобразуется в HTML и создаются связи между страницами. Затем на данный контент накладывается шаблон, который обеспечивает единообразный вид всех страниц вики.

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

Рабочий процесс

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

Тот факт, что вики децентрализованы и не имеют сложных механизмов workflow и процессов согласования, считается характерной чертой вики, а не недостатком. Это противоречит базовой философии многих систем управления контентом, в которых сделан акцент на контроль через разграничение полномочий.

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

Контроль против гибкости

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

Но что, если компания действительно хочет иметь хоть какой-то контроль? При отсутствии традиционных схем контроля, встроенных в рабочий процесс, создание контента в вики управляется путем отслеживания изменений, автоматизированной защитой от спама и контролем доступа пользователей. Давайте рассмотрим каждый из методов по очереди.

Отслеживание изменений

Как следует из названия, один из уровней защиты - это просто отслеживание изменений, которые были сделаны в вики. Это больше всего подходит для вики, которые постоянно находятся под защитой брандмауэра.

Кроме отслеживания изменений может потребоваться сделать что-то с нежелательными изменениями, например, возврат к предыдущей версии.

В двух словах, подход «отслеживание изменений» опирается на две основные функции – возможность отслеживать последние изменения плюс что-то типа контроля версии.

Последние изменения могут отслеживаться следующим образом:

●     большинство вики имеет страницу «последние изменения», на которой перечислены все страницы, которые были изменены. Если вики поддерживает регистрацию, то также отобразится имя пользователя, внесшего изменения;

●     уведомления по электронной почте – это просто e-mail-версия страницы с последними изменениями, которая удобнее с точки зрения уведомления;

●     вариация на тему уведомления по электронной почте – это rss-синдикация, дающая возможность отслеживать последние изменения в вики, использую привычный rss-ридер;

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

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

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

●     возможность вернуть изменения к предыдущей версии;

●     возможность сравнить разные версии друг с другом;

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

Защита от спама

Другой подход к отслеживанию изменений заключается в том, чтобы отслеживать изменения контента программными средствами. Иногда это называют защитой от спама. Такой метод отличается от контроля доступа пользователей тем, что редактирование вики отслеживается на основе самого контента или шаблонов поведения пользователя. Некоторые системы могут блокировать доступ к IP-адресам и URL или блокировать публикацию индивидуальных изменений на основе следующего:

●     ограничение использования определенных слов или фраз, использование списков слов или обычных выражений;

●     блокировка доступа по причине излишней активности пользователя.

Контроль доступа пользователя

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

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

Самые сложные корпоративные вики работают с такими системами безопасности единой регистрации, как Siteminder, или предлагают интеграцию сети и директории (LDAP и Active Directory) для отождествления и авторизации пользователя.

Вывод

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

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