Что хранит в себе корпоративная справочная система вики

Задачи корпоративной базы знаний

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

Для чего именно нужна корпоративная вики:

Как создать корпоративную базу знаний?

Многие строят свою базу знаний в облачных хранилищах Яндекс.Диск и Google Docs. Но в них неудобно систематизировать информацию и контролировать её изучение сотрудниками компании. Когда статей становится много, хранилище превращается в свалку.

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

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

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

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

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

Вывод

Источник

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

Программное обеспечение для вики-систем существует с 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

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

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

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

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

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

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

Шаблоны

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

Источник

Локальная база знаний организации на движке Wiki

Введение

Полтора года назад я пришел работать в техническую поддержку филиала одной крупной общероссийской компании. До этого технической поддержкой я не занимался, мог, конечно, переустановить, настроить ОС или настроить простейшую сеть, но сильно не вникал. По мере накопления знаний, возникла необходимость их систематизировать и сохранить. Сначала у меня была специальная папочка, куда я складывал обычные документы Word и Excel. Со временем в папке накопилось много документов, поиск нужной информации стал занимать довольно значительное время. Работал я не один, поэтому некоторые файлы необходимо было держать в открытом доступе, например, список пользователей, периодически приходилось искать информацию, нужную другим сотрудникам. При заведении нового пользователя администраторами, я заносил его в таблицу, где также содержались реквизиты для удаленного доступа на его компьютер (не все же время ходить на рабочие места, когда пользователей больше 300 человек). Актуальный файл всегда был только в одном экземпляре, у других сотрудников технической поддержки были копии, которые могли не совпадать, если один из сотрудников подключал человека или менял сетевые реквизиты, а потом забывал об этом сообщить.
Со временем появилась мысль о том, что надо все это объединить и сохранить в одно место, чтобы у всех сотрудников технической поддержки был доступ к информации, возможности ее редактирования и добавления.

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

Первый блин

До этого о создании сайтов я знал мало, поэтому первый шаг- установка, был для меня, наверно, самым тяжелым. Первая версия работала на движке Mediawiki и была установлена на Denwer. Но при установке возникли какие-то проблемы, так что сайт проработал недолго, примерно 2 недели и погиб после попытки создать таблицу соответствия принтеров и картриджей к ним (Один из важнейших документов, между прочим). Таблица никак не создавалась, все время были проблемы с отображением границ и содержимого, гугление и подробнейшие чтения руководства, ни к чему не привели. Со временем понял, что движок Mediawiki — это слишком для такого проекта, он был слишком мощным, требовал большого количества настроек, чего я сделать не мог из-за моего незнания.
Последующую пару месяцев я сайтом не занимался, поэтому в следующий раз я решил все сделать основательно и добить наконец проблему.

Второй блин

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

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

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

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

Созданные страницы хранятся в каталогах, которые называются “Пространства имен” (namespaces). В операционной системе каждый каталог является одной папкой, страницы хранятся в текстовых документах, так что их можно редактировать и без использования браузера (главное, чтоб права доступа не потерялись). Для каждой страницы хранится история ее изменений, как и в любом вики-сайте, можно быстро сделать откат, если текущая редакция не устраивает.

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

Источник

Почему строить базу знаний компании на основе mediawiki — недурная затея

В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне).

Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.

Сама по себе вики довольно скупа на возможности, но для нее написано огромное множество расширений. Большая часть интересного функционала кроется именно в расширениях, так что изрядная часть статьи будет именно про них. И да, не могу не отметить, что есть специальная корпоративная версия Mediawiki — BlueSpice, которой я не пользовался, а потому не могу судить об ее адекватности.

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

Сперва про фишки самой mediaiwki

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

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

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

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

В дополнение к шаблонам расширение Scribunto позволяет использовать lua-модули внутри вики. Модули вместе с шаблонами позволяют реализовать многие вещи, даже не обращаясь к написанию своих расширений.

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

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

Не могу не упомянуть Mediawiki:Common.css и Mediawiki:Common.js файлы, позволяющие добавить небольшую кастомизацию вики — для больших вещей лучше использовать расширения.

Редакторы

Одна из самых важных частей вики — это редактор. Крайне сложно внедрить вики, если в ней нет визуального редактора, потому как учить вики-разметку согласится только очень инициативный человек.

Visual Editor

Сравнительно свежее расширение — VisualEditor решает проблему с визуальным редактированием статей. У него есть свои косяки, но для большинства задач его хватает. Из самых заметных проблем — там не самая удобная вставка изображений.

Появление визуального редактора тесно свзяано с появлением Parsoid — сервиса конвертации между Mediawiki синтаксисом и html. Задача эта оказалась крайне нетривиальной в силу того, что mediawiki синтаксис развивался хаотично и не был строго определен. Подробнее можно почитать в прекрасном посте официального блога.

Среди расширений, интегрирующихся с VisualEditor, можно выделить Graph для редактирования графов, Math для редактирования математических формул и SyntaxHighlight для подсветки синтаксиса фрагментов кода.

WikiEditor

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

Конфликты редактирования

Кто пользовался в прошлом Mediawiki, тот помнит, какой болью становилось каждое разрешение конфликтов редактирования.

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

Можно попробовать самому на тестовой странице.

Формы для добавления однотипного контента

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

Это расширение раскрывает свою мощь при использовании Semantic Mediawiki или его аналогов. Семантическая медиавики позволяет добавлять на страницу свойства страницы или объекты со своими свойствами. Задаются свойства примерно так (на примере страницы Германия):

Эти свойства и объекты после можно получить при помощи запроса ask или через api.

Из полученных свойств можно выводить таблицы, строить графики и делать много других крутых вещей. К примеру, в моем случае на основе таблиц, добавленных через формы, строятся простейшие схемы бд. При этом схему можно строить не для всего продукта, а для конкретной категории. И в схеме можно отразить помимо очевидных FK/PK связей еще и неявные связи, которые не увидеть стандартными средствами построения диаграмм.

Дерево категорий

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

С другой стороны, когда у нас уже есть разложенные по категориям статьи, их можно отобразить на любой странице в виде дерева:

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

LDAP/AD авторизация

Расширение Ldap Authentication поддерживает авторизацию через домен, ограничение доступа для определнных групп и маппинг групп юзеров mediawiki на группы ldap. Можно настроить сразу несколько доменов. Довольно утомительная в вопросах настройки, но, к счастью, в интернетах есть очень даже неплохие инструкции.

Гранулярные права доступа

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

Есть много разных расширений, но они не решают фундаментальную проблему: mediawiki не была создана как CMS. Для поддержки прав доступ придется патчить код Mediawiki, маниакально добавляя

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

Для себя я решил проблему самодельным расширением, построенном на идее из PermissionACL и пачки патчей для разных расширений и самой mediawiki. К счастью, мне не был нужен продвинутый ACL, хватило и примитивных проверок для нескольких групп.

Для поддержки того же самого для изображений придется завернуть обращения к файлам в Img_auth.php. А последний использует стример файлов от mediawiki, который не умеет отдавать partial content (на момент mediawiki 1.31), так что для поддержки воспроизведения видео придется приделывать другой стример файлов.

Поддержка видео

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

Поиск

Одна из раздражающих меня лично вещей в Confluence — это поиск. Стандартный поиск Mediawiki еще хуже, но к счастью есть сторонние расширения. Из поисковых расширений самые популярные — это CirrusSearch и SphinxSearch. Последним я никогда не пользовался, но с первым мне довелось познакомиться очень плотно, он же, кстати, используется и в проектах фонда викимедиа

CirrusSearch работает на базе elasticsearch, для работы расширения придется еще поставить промежуточный интерфейс — расширение Elastica.

CirrusSearch поддерживает безумное число параметров и довольно активно развивается. Например, меня очень порадовало, что в ветке 1.32 заработал поиск по CamelCase.

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

Расширение не поддерживает добавление синонимов на уровне конфига LocalSettings, но это несложно решить правкой кода расширения — см AnalysisConfigBuilder.php и инструкцию по настройке синонимов elasticsearch.

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

Кстати, AdvancedSearch поможет привести в порядок вид страницы поиска, с ним она не будет выглядит как жертва любителя чекбоксов.

Аналитика

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

Для интранета есть крайне достойное расширение Matomo (ex Piwik). Соответствующее расширение для интеграции — MatomoAnalytics.

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

Прочее

Помимо перечисленного есть немало расширений, которые просто облегчают жизнь. Например, GuidedTour для обучения новичков основам работы с интерфейсами, Popups для предпросмотра статей по наведении на ссылку, MultimediaViewer для более кофмортного просмотра полноразмерных изображений и многое-многое другое.

Что в итоге?

Перечисленный джентельменский набор расширений покрывает значительную часть потребностей при создании базы знаний, но не все. Mediawiki не годится в качестве универсальной единой базы знаний. Но в качестве универсальной системы также плохо справляются и все остальные — sharepoint, confluence, олдскульные папочки outlook, поиск по которым занимает полчаса и т.д. Mediawiki же на их фоне отличается своими возможностями кастомизации и отличной масштабируемостью.

В противовес всем перечисленным плюсам mediawiki постоянно требует допиливания напильником функционала под нужды конкретной компании, так что ее администратору стоит быть морально готовым разбираться в php, js и lua коде. Но если это не пугает и если вы согласны разделять работу с офисными документами и работу с вики статьями по разным платформам, mediawiki в качестве базы знаний может оказаться весьма недурной затеей.

Источник