Web Content

Перевод: английский - русский - www.onlinedoctranslator.
com
Мыб
Содержание
Управление
СИСТЕМЫ,ФУНКЦИИ,ИЛУЧШИЕ ПРАКТИКИ
Дин Баркер
www.allitebooks.com
Управление веб-контентом
Смотрящийвыбрать систему управления веб-контентом (CMS),
но не знаете обещаний, терминологии и модных словечек?
Хотите разобраться в управлении контентом, не углубляясь в
«назрелаи
Эта книга давно
очень
базовое программирование? В этой книге представлен четкий нужный
и объективный обзор всей экосистемы CMS — от платформ до противоядие от
реализаций — независимо от языка и платформы, как для индустрииотчеты и
менеджеров проектов, руководителей, так и для новых
разработчиков.
поставщикофициальн
Автор Дин Баркер, консультант по CMS с почти
ые документы, которые
двадцатилетним опытом, помогает вам изучить множество имеюттак долго
различных систем, технологий и платформ. К концу книги у вас
будут знания, необходимые для принятия решений о функциях,
доминировал в
дискуссии КМ. Ура
»
архитектуре и методах реализации, чтобы гарантировать, что
ваш проект решает правильные проблемы.
Дину!
—БобБойко
авторБиблия управления контентом(Уайли)
■ Узнайте, что такое контент, как сравнивать разные
системы икаковы роли команды CMS
■ Понять, как современная CMS моделирует и
объединяетконтент, координирует рабочий
процесс и управляет активами
■ Изучите масштаб и структуру проекта внедрения
CMS.
■ Изучите процесс и лучшие практики для успешной
работываша реализация CMS
■ Изучите практику переноса веб-контента и узнайте,
какдля работы с внешним интегратором CMS
Дин Баркер, партнер-учредительи директор по стратегии в Blend

Interactive, работает в области управления веб-контентом с середины
90-х годов, еще до того, как эта дисциплина получила свое название.
С тех пор он работал над сотнями реализаций CMS, от небольших
маркетинговых сайтов до крупных издательских операций.
УПРАВЛЕНИЕ СОДЕРЖАНИЕМ
НАС$39,99 МОЖЕТ$45,99
ISBN: 978-1-491-90812-9.
www.allitebooks.com Твиттер:
@oreillymedia
facebook.com/
oreilly
Системы, функции и лучшие практики
Дин Баркер
Пекин Бостон Фарнем Севастополь Токио
www.allitebooks.com
Дин Баркер
Авторские права © 2016 Дин Баркер. Все права
защищены.Напечатано в Соединенных Штатах
Америки.
Опубликовано O'Reilly Media, Inc., 1005 Gravenstein Highway North, Севастополь, Калифорния 95472.
Книги О'Рейли можно приобрести для образовательных, деловых или рекламных целей. Для
большинства изданий также доступны онлайн-версии (http://safaribooksonline.com). Для
получения дополнительной информации свяжитесь с нашим отделом
корпоративных/институциональных продаж: 800-998-9938 илиCorporate@oreilly.com.
Редактор:Эллисон
МакдональдРедактор Индексатор:WordCoСлужбы индексирования
производства:Коллин Коул Дизайнер интерьера:Дэвид
Редактор:Рэйчел Хед Футато Дизайнер
Корректор:Сьюзан Мориц обложки:РэндиуголИллюст
ратор:Ребекка Демарест
Март 2016 г.: ПервыйВерсия
Редакция История для тот ПервыйВерсия

09.03.2016: Первый выпуск
Видетьhttp://oreilly.com/catalog/errata.csp?isbn=9781491908129 для получения подробной информации о выпуске.
Логотип O'Reilly является зарегистрированным товарным знаком O'Reilly Media, Inc. Web Content
Management, изображение на обложке и соответствующий фирменный стиль являются товарными
знаками O'Reilly Media, Inc.
Хотя издатель и автор приложили добросовестные усилия для обеспечения точности информации
и инструкций, содержащихся в этой работе, издатель и автор отказываются от любой
ответственности за ошибки или упущения, включая, помимо прочего, ответственность за ущерб,
возникший в результате использования или полагаться на эту работу. Использование информации
и инструкций, содержащихся в данной работе, осуществляется на свой страх и риск. Если какие-
либо образцы кода или другие технологии, содержащиеся или описываемые в этой работе,
подпадают под действие лицензий с открытым исходным кодом или прав интеллектуальной
собственности других лиц, вы несете ответственность за обеспечение того, чтобы их
использование вами соответствовало таким лицензиям и/или правам.
978-1-491-90812-9
[ЛСИ]
www.allitebooks.com
ДляМама.
Я наконец-то понял, кем хочу стать, когда вырасту.
www.allitebooks.com
www.allitebooks.com
Стол изСодержание
Предисловие.................................................................xiii
Предисловие.................................................................xv
Часть I. Основы
1. Что Содержание Управление Является (иНет)...............................1
Что такое контент? 3
Создано людьми посредством редакционного процесса 3
Предназначено для потребления человеком посредством публикации для аудитории.4
Определение содержания 5
Что такое система управления контентом? 5
Дисциплина против программного обеспечения 6
Типы систем управления контентом 7
Что делает CMS 9
Управление контентом 9
Разрешить повторное использование контента 10
Разрешить автоматизацию и агрегирование контента 11
Повысьте редакционную эффективность 11
Чего не делает CMS 12
Создать контент 12
Создавайте маркетинговые планы 12
Эффективно форматируйте контент 13
Обеспечить управление 13
2. Точки сравнения...........................................................15
Тип целевого сайта 16
www.allitebooks.com
Системы и реализации 17
Платформа против продукта 18
Открытый исходный код против коммерческого 20
Технологический стек 23
Управление против доставки 25
Связанные и разделенные 26
Установленное и программное обеспечение как услуга (SaaS) 27
Код против контента 28
Код против конфигурации 29
Однонаправленная и двунаправленная публикация 30
Практичность против элегантности и проблема технического долга 32
3. Приобретение CMS.........................................................35
CMS с открытым исходным кодом 36
Бизнес-модели компаний с открытым исходным кодом 37
Коммерческие CMS 39
Модели лицензирования 40
Подписка на программное обеспечение 42
Программное обеспечение как сервис 45
Построй свой собственный 47
Вопросы, которые стоит задать 49
4. The Содержание УправлениеКоманда....................................53

Редакторы 54
Планировщики сайтов 56
Разработчики 57
Администраторы 58
Заинтересованные стороны 59
Часть II. The Компоненты из Содержание УправлениеСистемы

5. Анализ функций CMS.......................................................65
Трудности анализа объектов 65
«Соответствие цели» 66
Синдром «делай все» 67
Целое больше, чем сумма его частей 68
Детали реализации имеют значение 69
Обзор возможностей CMS 71
6. Моделирование контента...................................................75
Моделирование данных 101 76
ви | Оглавление
www.allitebooks.com
Моделирование данных и управление контентом 80
Разделение контента и представления 81
«Постраничная» CMS 84
Определение модели контента 85
Типы контента 85
Атрибуты и типы данных 88
Встроенные атрибуты 90
Проверка атрибута 91
Использование атрибутов для редакционных метаданных 92
Наследование типа контента 93
Встраивание контента 97
Отношения 103
Состав контента 104
Управляемость модели контента 105
Краткое изложение функций моделирования контента 107
7. Агрегация контента.......................................................109
Форма контента 111
География контента 114
Редакционные ограничения по географии 117
Вторичные географические регионы: категории, таксономии, теги, списки, коллекции,
и меню 118
Тирания Дерева 119
Модели агрегации: неявные и явные 120
Должна ли ваша агрегация быть объектом контента? 121
Адресуемость URL-адресов агрегатов 122
Агрегационная функциональность 122
Статический и динамический 123
Переменная или фиксированная 125
Ручной заказ в сравнении с производным заказом 125
Ограничения типа 127
Ограничения количества 128
Фильтры разрешений и статуса публикации 128
Плоский или иерархический 129
Межстраничные агрегаты 129
По конфигурации или по коду 130
Краткое изложение функций агрегирования контента 133
8. Редакционные инструменты и рабочий процесс............................135

Жизненный цикл контента 136
Интерфейс редактирования 138
Находимость и обход контента 138
Оглавление| VII
www.allitebooks.com
Выбор типа 140
Предварительный просмотр контента 142
Редактирование элементов интерфейса 144
Управление версиями,Контроль версий и метки версий 151
Управление зависимостями 153
Планирование и срок действия контента 155
Публикация набора изменений 156
Срок действия контента 156
Рабочий процесс и утверждения 157
Разрешения 157
Рабочий процесс 157
Сотрудничество 160
Управление файлами контента 162
Добавление файлов содержимого 162
Ассоциация контента 163
Обработка изображений 164
Обзор редакционных инструментов 170
Обход контента и навигация 170
Выбор типа 170
Предварительный просмотр контента 170
Интерфейс редактирования 171
Управление версиями, контроль версий, планирование и срок действия 171
Рабочий процесс и утверждения 171
Управление файлами контента 172
9. Управление выводами и публикациями.....................................173

Разница между контентом и презентацией 173
Шаблонизация 175
Философия шаблонов 177
Функциональность языка шаблонов 179
Окружение 185
ШаблонВыбор 190
Абстракция и включение шаблонов 193
Разработка шаблонов и управление ими 195
Адаптивный дизайн и агностицизм вывода 195
Публикация контента 196
Связанное и разделенное управление контентом 196
Разделенные цели публикации 199
Краткое описание функций управления выводом и публикации 201
Архитектура 201
viii | Оглавление
www.allitebooks.com
Отдельная публикация 202
10............................................................Другие особенности. 203

Многоязычная обработка 204
Номенклатура 205
Обнаружение и выбор языка 206
Языковые правила 208
Языковые варианты 209
За пределами текста 210
Редакционный рабочий процесс и поддержка интерфейса 211
Служба внешнего переводаПоддерживать 211
Персонализация, аналитика и автоматизация маркетинга 213
Анонимная персонализация 214
Интеграция аналитики 218
Автоматизация маркетинга и интеграция CRM 218
Формирование здания 220
Интерфейсы редактирования форм 221
Обработка данных формы 223
Управление URL-адресами 224
Исторические URL-адреса, персональные URL-адреса и пользовательские
перенаправления 225
Управление несколькими объектами 226
Инструменты отчетности и информационные панели 228
Поиск контента 229
Экосистема пользователей и разработчиков 233
11.......................................................API иРасширяемость. 235

API кода 236
Модели событий 239
Плагины Архитектуры 243
Настройка редакционного интерфейса 245
Настройка редакторов форматированного текста 246
Абстракция репозитория 246
Подключаемая аутентификация 247
Веб-сервисы 248
Запланированные задания или задания по требованию 249
Часть III. Реализации

12..............................................................Реализация CMS. 253
Принцип построения против всего остального 254
Оглавление| ix
Типы реализаций 255

Предварительная реализация 257
Артефакты обнаружения и предварительной реализации 257
Разработка технического плана 260
Процесс реализации 268
Настройка среды 268
Установка, настройка и согласование контента 269
Моделирование контента, моделирование агрегации и черновая обработка 271
Ранняя миграция контента 273
Неконтентная интеграция и развитие 277
Планирование и настройка производственной среды 278
Планирование обучения и поддержки 280
Окончательная миграция контента, контроль качества и запуск 281
13...........................................................Миграция контента. 285

Редакционный вызов 286
Автоматизированный или ручной? 287
Процесс миграции 288
Добыча 289
Трансформация 291
Сборка 292
Импортировать 294
Разрешение 295
контроль качества 297
Разработка сценария миграции 298
Скорость контента и сроки миграции 300
Последнее слово предупреждения 301
14.............................................Работа с внешними интеграторами. 305

Модели взаимодействия 306
Профессиональные услуги поставщика CMS 307
Продажи и определение объема 309
Артефакты до реализации 310
Расходы 313
Письменные соглашения 314
Заявление о работе 315
Производство 319
Близость и преданность команды 319
Инфраструктура разработки и тестирования 320
Коммуникация и регистрация проекта 320
Приемка работ и контроль качества 321
Икс | Оглавление
Разработка контента 323
Обучение и поддержка 324
Последнее слово 326
15..............................Где Содержание Управление ЯвляетсяИдущий. 329

Меньше CMS с открытым исходным кодом получат поддержку 330
Развязка вернется 331
Фокус на маркетинговых инструментах и интеграции будет возрастать 333
SaaS начального уровня съест нижнюю часть рынка 335
Многоканальная дистрибуция увеличится 336
Потребление распределенного контента начнет расти 337
Послесловие................................................................339
Индекс......................................................................341
Оглавление| xi
Предисловие
Индустрия управления веб-контентом существенно изменилась за последние

два десятилетия. Сегодня поставщики CMS и отраслевые эксперты уделяют
большое внимание «управлению клиентским опытом» — идее о том, что
успешное взаимодействие с клиентами должно стимулировать все ваши
инвестиции в цифровые технологии. Это полезная расстановка приоритетов,
поскольку мы все должны думать «сначала экран» (т. е. как клиенты
воспринимают наши цифровые воплощения?). В конце концов, зачем
производить цифровой контент, если люди на самом деле не хотят его
потреблять?
Но такой акцент на управлении опытом иногда отодвигает процесс
производства и публикации высококачественной информации на второй план.
Мы все можем понять, почему маркетологи уделяют больше внимания дизайну
внешнего интерфейса, мобильным стратегиям и социальным
микросообщениям, но при этом они рискуют потерять фокус на более глубокие
формы взаимодействия, основанного на информации.
Рассмотрим почти повсеместное желание создавать более
персонализированные цифровые взаимодействия. Многие стратегии
персонализации начинаются с предпосылки: «предполагать наличие
подходящего контента для каждого взаимодействия». Это вызывает много
вопросов. Подходящий контент откуда? Как это будет управляться? Как оно
будет разбито на части? Как мы будем варьировать его для каждой аудитории?
Как он будет собираться? Как мы будем моделировать все перестановки? За
этими вопросами скрываются некоторые непростые проблемы управления
контентом.
С другой стороны, в последние несколько лет «контент-стратегия» стала
важной цифровой дисциплиной. То, что именно люди подразумевают под
стратегией контента, будет разным, но общая идея заключается в том, что вам
необходимо привести в порядок свой контент-центр, прежде чем вы начнете
реализовывать бизнес-стратегии по различным цифровым каналам.
Появление нового поколения стратегов цифрового контента является
долгожданным событием, хотя иногда мне хотелось бы, чтобы они лучше
понимали организационную среду, в которой должны реализовываться их
стратегии. Контент-стратегии, которые выглядят великолепно в первый день,
могут оказаться беспорядочными к дню 365, не говоря уже о дне 730. Вам
нужно разобраться с простыми режимами создания и утверждения; вам нужно
найти и изменить предыдущие версии cam.
xiii
боли; вам необходимо интегрировать аналитику в последующие итерации; вам
необходимо заархивировать старую информацию, чтобы она не засоряла
результаты вашей поисковой системы. И так далее.
Итак, сегодня индустрия WCM испытывает некоторые ключевые пробелы, и
нам нужны люди, которые смогут эффективно устранить эти пробелы.
Например, разрыв между созданием контента и его потреблением. Разрыв
между контент-стратегиями и реализациями CMS. Между потребностями
бизнеса и архитектурными шаблонами. Между авторами и маркетологами.
Между разработчиками и менеджерами кампаний. Между стратегами и
исполнителями. Дин Баркер — редкий человек, который может рассказать обо
всех этих проблемах.
Будучи новозеландцем, счастливо переехавшим в Северную Америку, Дин
обладает способностью страстно заниматься делом, но в то же время
принимать критическую точку зрения стороннего наблюдателя. На первый
взгляд эта книга представляет собой введение в основные темы CMS, но если
вы прочитаете глубже, вы обнаружите, что это действительно аргумент —
страстный призыв относиться к веб-контенту и процессам, связанным с ним,
так же серьезно, как вы относитесь к любому другому активу бизнеса или
маркетинга. .
Итак, вам следует прочитать книгу от корки до корки, но я особенно
рекомендую вам добавить в закладки главы, посвященные команде CMS,
моделированию и агрегированию контента, миграции и реализации. Это
сложные темы, которые консультанты и поставщики часто не любят
обсуждать, но они могут улучшить или разрушить вашу программу CMS. Дин
описывает их с правильным сочетанием широты и эффективности, которое
может дать только тот, кто прошел через них много-много раз.
Хотя эта книга написана для бизнес-специалистов, если вы разработчик или
архитектор, ее очень стоит прочитать, и она была бы таковой, даже если бы
Дин не включил все полезные фрагменты кода (хотя он их включил, к моему
удовольствию и надеюсь, ваш). Прочтите первую главу «Точки сравнения»,
чтобы узнать о некоторых ключевых логических различиях, которым ваша
команда должна следовать.
Если бы существовала волшебная машина, которая могла бы создать
идеальную CMS, я бы поставил за штурвал Дина. В отсутствие такой машины
остальным из нас приходится выявлять лучшие практики старомодным
способом: путем тестирования и опыта. Я надеюсь, что у вас будет
возможность протестировать многие инструменты CMS, просто чтобы воочию
почувствовать удивительные различия в подходах между ними. Но если вы
ищете единый источник знаний и опыта в области лучших практик CMS,
оставьте все, что вы делаете, и прочитайте эту книгу.
— Тони Бирн,
основатель Real Story
Groupwww.realstorygrou
p.com
декабрь 2015 г.
xiv | Предисловие
Предисловие
Примерно в 1995 году я написал свой первый HTML-документ.

Я написал его в Блокноте на своем процессоре Pentium Tower с частотой 90
МГц от Gateway 2000. Я до сих пор помню, как добавлял тег TITLE, обновлял
страницу в Internet Explorer и с трепетом наблюдал, как заголовок моего
документа заполнял строку заголовка окна браузера (идея браузеры с
вкладками были еще годами позже, поэтому тег TITLE документа стал
заголовком всего окна).
Эта первая веб-страница быстро превратилась в целый веб-сайт (тему и смысл
которого я, честно говоря, не помню — подозреваю, что это был просто список
ссылок на другие сайты). До массового внедрения CSS и JavaScript оставалось
еще несколько лет, поэтому у меня не было скриптов или таблиц стилей, но у
меня было несколько HTML-файлов и куча изображений (вы были бы никем,
если бы у вас не было мозаичного, текстурированного фон на вашей странице
ссылок).
Быстро я столкнулся с первой проблемой веб-мастеров во всем мире: как мне
отслеживать все это? Я даже не думаю, что слово «контент» еще широко
применялось — это были просто «материалы».
По мере того как веб-сайты неизбежно росли, росло и все остальное. Поскольку
мы в значительной степени были привязаны к файловой системе, у нас на
локальных компьютерах были копии всего, что мы пересылали по FTP на наши
серверы. Если у вас было более одного редактора, возникали огромные
проблемы. Если два человека попытаются управлять файлами, они неизбежно
рассинхронизируются, и изменения будут непреднамеренно перезаписаны.
Иногда вам приходилось синхронизироваться с сервером, загружая все и
перезаписывая локальную копию, просто чтобы убедиться, что у вас
установлена последняя версия всего сайта.
Процесс управления веб-сайтом был чрезвычайно утомительным. Ссылки с
одной страницы на другую предполагали, что эти две страницы будут
существовать всегда. Неработающие ссылки были обычным явлением, и если
вы решили реорганизовать структуру своего сайта или переименовать
страницы, вам приходилось просматривать все файлы, чтобы найти, где могло
использоваться предыдущее имя.
xv
Самым ценным в моем наборе инструментов, возможно, была утилита
глобального поиска и замены, которая позволяла мне искать и исправлять
ссылки в сотнях файлов одновременно.1
Это была история веб-мастера в середине 90-х, еще до появления управления
контентом. Это был утомительный опыт ручного управления сотнями файлов,
создания нескольких резервных копий всего и попыток собрать воедино набор
инструментов, который давал бы вам хоть капельку контроля.
Перенесемся почти на 20 лет вперед, и веб-технологии эволюционировали,
избавив от большей части утомительной работы. Сегодняшний веб-менеджер в
основном работает с абстрактными понятиями контента, а не с реальными
файлами, без необходимости понимать лежащую в его основе технологию,
файловую систему или языки программирования.
Но даже абстрагирование контента от технологий по-прежнему оставляет нам
вечные проблемы, которые нужно решить: как нам структурировать или
«моделировать» наш контент? Как мы можем обеспечить его организацию?
Как мы его ищем? Как нам работать вместе над контентом, не вызывая
конфликтов?
Короче говоря, как мы управляем контентом?
Для кого эта книга?

Эта книга представляет собой попытку подойти к управлению веб-контентом
со стороны, не продвигая какую-либо конкретную технологию или
методологию. Он предназначен для читателей, которые хотят понять более
широкий контекст, в котором может работать конкретная система управления
контентом (CMS), или понять основные проблемы управления контентом,
которые должна будет решить любая конкретная система.
Этими читателями могут быть:
• Менеджерам проектов поручено управлять внедрением новой CMS.

• Опытные разработчики, которые могут быть новичками в управлении контентом, в
частности.
• Веб-менеджеры приступают к оценочному проекту по приобретению новой CMS
• Производители контента переходят от оффлайн-контента к управлению
веб-контентом
• Существующие разработчики CMS, желающие выйти за пределы
выбранной ими платформы и взглянуть на свою дисциплину с новой точки
зрения.
• Дизайнеры или контент-стратеги, желающие больше понять
технологический контекст своей работы.
1 В компании Funduc Software она называлась (соответственно) «Поиск и замена» и на самом деле
существует до сих пор.делиться- посуда. К сожалению, в то время у него не было функций
резервного копирования или отмены. Напомни мне как-нибудь рассказать историю о том, как я
случайно совершил необратимую находку и замену на букве «е».
xvi | Предисловие
• Любой, кто пытается понять и оправдать новый проект, связанный с CMS.
Чего нет в этой книге?

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

Главы книги сгруппированы в три части:
Часть I, «Основы»
Эта часть заложит основу для более широкого обсуждения управления
контентом. Мы поговорим о том, что такое контент, о парадигмах
сравнения различных систем, о ролях, составляющих команду CMS, и о
том, как ваша организация может приобрести CMS.
Часть II, «Компоненты контента».Системы управления"
В этой части будут проанализированы основные функциональные области
современных CMS — как они моделируют контент, агрегируют контент,
координируют рабочий процесс, управляют активами и т. д.
Часть III, «Реализации»
В заключительной части будут обсуждаться масштабы и структура проекта
внедрения CMS, а также лучшие практики и процесс его успешного
запуска (или даже просто выживания). Кроме того, мы поговорим о часто
упускаемой из виду практике миграции веб-контента и о том, как вы
можете работать с внешним интегратором CMS, если он вам нужен.
Примечание об общих чертах

Большая часть этой книги посвящена системам управления контентом, а не
какой-то конкретной системе. Это означает, что я буду пытаться обсуждать все
разновидности систем управления контентом одновременно, что является
семантически сложной задачей.
Одной из задач написания этой книги было придумать разные формулировки
для разделения всей области CMS на группы. На следующих страницах вы
встретите бесчисленное количество фраз, таких как «большинство систем»,
«некоторые системы» и «почти все».
Предисловие | XVII
системы», а также множество уточнений, таких как «редко», «редко», «часто»,
«иногда» и «обычно».
Очевидно, что ни одна из этих фраз не поддается количественной оценке; 2 они
просто лучшие из множества неоптимальных способов справиться с общими
понятиями. Разные фразы будут означать разные вещи для разных людей. Если
вы не согласны с уточнением, заранее приношу извинения.
Примечание по номенклатуре
Как мы обсудим в самой первой главе, «контент» может означать множество
разных вещей: от файлов HTML до изображений и документов Word.
Для удобства я буду использовать термины «контент» и «CMS». Однако
помните, что эта книга посвящена конкретно управлению веб-контентом,
поэтому я говорю конкретно о «веб-контенте», «WCM» и «WCMS».
Отказываясь от квалификаторов «Интернет» и «W», я не претендую на контент
как на чисто веб-актив или проблему. Скорее, я просто склоняюсь перед
условностями и краткостью.
Примечание о боковых панелях

На протяжении всей книги вы найдете дюжину боковых панелей от других
профессионалов, работающих в индустрии CMS. Я благодарен этим друзьям и
коллегам за то, что они нашли время поделиться здесь своим опытом.
Для каждой врезки был предоставлен черновой вариант главы, и автору
предлагалось высказать мнение о чем-либо в ней. Они могли не согласиться,
указать на то, что было упущено, или по-другому взглянуть на все, что они
прочитали. Никаких попыток изменить их мнение не предпринималось.
Как я много раз говорю в следующих главах, управление контентом — это не
только наука, но и искусство, и, без сомнения, найдется бесчисленное
множество людей, которые не согласятся с одним или несколькими вещами,
которые я здесь написал. Я благодарен, что мои приглашенные авторы были
готовы дать представление о том, как разный опыт часто приводит к разным
выводам.
Примечание о предвзятости
Как консультант, проработавший в этой сфере почти два десятилетия, уверяю
вас, что у меня много предпочтений. Однако я также понимаю, что даже
система, которую я ненавижу, все еще
2 Хотя ЦРУ пыталось еще в 1960-е годы. Оказывается, «почти наверняка» — 93%, а «вероятно» —
75%. См. раздел «Слова об оценочной вероятности» на страницесайт ЦРУ.
восемнадцатый | Предисловие
есть поклонники. Мои предпочтения, несомненно, проявятся, но я сделал все
возможное, чтобы быть объективным и предоставить адекватное обоснование
своих выводов.
Я также понимаю, что, как и у любого консультанта, мой опыт, скорее всего,
ориентирован на один тип проекта или проблемы таким образом, что я могу
даже этого не заметить. Точно так же, как вы не можете пройти милю в шкуре
другого человека, я не могу полностью относиться к проблемам, которые мне
никогда не приходилось решать. Системы, которых, как мне кажется, крайне не
хватает для проектов, над которыми я работал, могут полностью подойти для
решения стоящей перед вами задачи.
Наконец, мой опыт работы с конкретными системами, парадигмами и
методологиями облегчил мне создание примеров и снимков экрана этих
систем. За это я прошу прощения, но существует множество негативных
практических моментов, связанных с начальной загрузкой системы, с которой я
не знаком, для получения изображения или примера. Я благодарю тех, кто
работает в отрасли, кому я удосужился поделиться своим опытом работы с
некоторыми системами, которые, по моему мнению, было важно обсудить, но к
которым у меня не было доступа или доступа.
Конвенции Использовал в ЭтотКнига

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

Предисловие | XIX
Этот элемент указывает на предупреждение или предостережение.
Сафари® КнигиВ сети

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

дизайнеры, а также представители бизнеса и творческих профессий используют
Safari Books Online в качестве основного ресурса для исследований, решения
проблем, обучения и сертификации.
Safari Books Online предлагает широкий выборпланы и цены
дляпредприятие,правительство,образование, и частные лица.
Участники имеют доступ к тысячам книг, обучающих видеороликов и
предварительных рукописей в одной базе данных с возможностью поиска от
таких издателей, как O'Reilly Media, Prentice Hall Professional, Addison-Wesley
Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco. Press,
John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe
Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett,
Course Technology и сотни других.более. Для получения дополнительной
информации о Safari Books Online посетите нас.В сети.
Как связаться с нами

Пожалуйста, направляйте комментарии и вопросы по поводу этой книги издателю:
О'Рейли Медиа, Инк.

1005 Gravenstein Highway, Северный
Севастополь, Калифорния 95472
800-998-9938 (в США или Канаде) 707-
829-0515 (международный или местный)
707-829-0104 (факс)
У нас есть веб-страница этой книги, на которой мы перечисляем ошибки,

примеры и любую дополнительную информацию. Вы можете получить доступ
к этой странице по адресуhttp://www.oreilly.com/catalog/ 0636920034186.до.
Чтобы прокомментировать или задать технические вопросы об этой книге,
отправьте электронное письмо по адресукнижки- tions@oreilly.com.
хх | Предисловие
Дополнительную информацию о наших книгах, курсах, конференциях и
новостях можно найти на нашем веб-сайте по адресу:http://www.oreilly.com.
Найдите нас на Фейсбуке:http://facebook.com/oreilly
Следуйте за нами на Twitter:http://twitter.com/oreillymedia
Смотрите нас на YouTube:http://www.youtube.com/oreillymedia
Благодарности
Прежде всего, я хотел бы поблагодарить эту отрасль. Отойдя от этой книги,
когда она пришла к выводу, я понял, что ничто из того, что я здесь написал, не
является особенно оригинальным. Я просто курирую, сопоставляю, ремиксую и
развиваю концепции и идеи, которые каждый день воплощают в жизнь тысячи
людей по всему миру.
Я узнал, что на самом базовом уровне именно это и делает писатель: мы
обрабатываем информацию. Если мы не сообщаем об оригинальном
исследовании или не пишем полностью оригинальное художественное
произведение, мы просто потребляем информацию из других источников,
собираем ее, фильтруем, анализируем, реорганизуем, объясняем, а затем
распространяем. С этой точки зрения этот процесс мало чем отличается от
самого процесса управления контентом, обсуждению которого мы уделим
следующие 300 страниц.
Однако явно необходимы некоторые более конкретные признания.
Спасибо моей жене Энни, моим детям Алеку, Габриэль и Изабелле, а также
моей крестнице Бруклин за то, что терпели меня, пока я писал первоначальный
вариант, и особенно после того, как я поклялся, что он «готов»… но потом
продолжал писать. в любом случае.
Спасибо моим деловым партнерам Джо Кепли, Карле Санти и Деннису Бреске
за то, что дали мне время написать это.
Спасибо непревзойденным сотрудникам Blend Interactive за помощь в
построении бизнеса, который дает мне возможность проводить дни, думая об
управлении контентом. Я надеюсь, что эта книга представляет собой хотя бы
смутную тень того богатого опыта и знаний, которые существуют в офисе
Blend.
Спасибо моему редактору Элли Макдональд за то, что рискнула выбрать
случайного парня, заполнившего онлайн-форму О'Рейли.
Спасибо команде докладчиков конференции Now What 2014, которые сидели за
столом в гриль-баре Crawford's в Су-Фолс, Южная Дакота, и в первую очередь
уговорили меня написать эту книгу: Карен Макгрейн, Кристина Халворсон,
Джефф Итон, Джаррод Гинграс, Джефф Зауэр, Кори Вилхауэр и Джефф Крам.
Спасибо моим техническим редакторам Арильду Хенрихсену, Линси Струтерс,
Сету Готлибу и Кори Вилхауэру. Любой из них мог бы положить конец этому,
просто сказав мне, что книга плоха. Тот факт, что они этого не сделали, был
первым препятствием, которое мне пришлось преодолеть.
Предисловие | XXI
Спасибо моей помощнице Керри Вилхауэр, которая сначала редактировала
каждую главу и потратила слишком много времени, меняя «то» на «который» и
вычеркивая мои беспорядочные расстановки переносов. 3 Ее
головокружительная решимость разъяснять непонятные правила английского
языка одновременно ценилась и порой пугала.
Спасибо Тони Бирну, моему близкому другу и наставнику на протяжении
многих лет, который очень помог мне, неоднократно помещая этот бизнес и
практику в контекст, и который оказал мне честь написать предисловие.
Наконец, спасибо Бобу Бойко за написание «Библии управления контентом». В
конце концов я закончил ее, находясь в самолете, который был перенаправлен в
Канзас-Сити примерно в 2006 году. Я до сих пор отчетливо помню, как закрыл
1122-страничное чудовище и плюхнулся на свое место, чтобы все это
осмыслить.
Думаю, я действительно вспотел.
3 Стоит отметить, что слово «редактирование» в этом предложении было записано через дефис в
первом варианте этого предисловия.
XXII | Предисловие
ЧАСТЬя
Основы
ГЛАВА1
Что Содержание Управление Является
(иНет)
Мы склонны рассматривать управление контентом как цифровую концепцию,

но оно существует столько же, сколько и контент. Пока люди создавали
контент, мы искали решения для управления им.
Александрийская библиотека (от 300 г. до н. э. до примерно 273 г. н. э.) была
ранней попыткой управления контентом. Он сохранял контент в виде свитков
папируса и кодексов и, по-видимому, контролировал доступ к ним.
Библиотекари были первыми контент-менеджерами.
Перенесемся на пару тысяч лет вперед: промышленная революция и развитие
технологий увеличили накопление информации в геометрической прогрессии.
Проблема управления ею стала более острой. Начало 20-го века было полно
великих мыслителей, исследовавших проблему передачи информации и
управления ею: С.Р. Раганатан, Ванневар Буш,1 Пол Отле, Клод Шеннон и даже
Мелвил Дьюи, отец почтенной десятичной системы Дьюи.
Итак, потребность в управлении контентом возникла не с появлением
Всемирной паутины, а просто перенеслась вперед, когда в начале 90-х годов
зародилась Сеть. В этот момент возможность создавать и публиковать контент
упала из башни из слоновой кости в руки масс. Практически каждый может
создать веб-страницу практически обо всем.
Впоследствии контент взорвался. В то время я был студентом колледжа и был
слегка одержим Джеймсом Бондом. Внезапно я смог найти массу информации
о
1 В 1945 году Буш написал невероятно влиятельное эссе под названием «Как мы можем думать», в
котором сетовал на отсутствие необходимых инструментов управления информацией и представлял
себе будущее, которое оказалось удивительно похожим на то, что на самом деле произошло через 70
лет после его публикации. По сути, Буш описал Всемирную паутину примерно за 50 лет до того, как
Тим Бернерс-Ли сделал это возможным.
1
007. Количество мелочей ошеломляло. Конечно, я попытался распечатать
большую часть этого, потому что, если бы этого не было на бумаге, как бы я с
этим справился?
Вскоре я стал соредактором популярного веб-сайта о Джеймсе Бонде — Mr.
Поцелуй, поцелуй, Bang Bang.2 Я узнал, что отслеживание контента было
непростой задачей. В любой момент времени статья существовала только в
виде HTML-файла в корневом каталоге веб-сервера. В то время я не был ИТ-
специалистом, поэтому единственная резервная копия за пределами этого
файла была на моем локальном компьютере. Не было никакого управления
версиями или контроля доступа — одна ошибка, и все могло исчезнуть.
Мне это показалось опасным. Даже тогда я знал, что веб-сайт — это, по сути,
бизнес, основанный на контенте, и, имея не что иное, как кучу файлов, я
эффективно работал без сети. Контент был нашим единственным активом в
бизнесе, и я помню, что думал, что он очень хрупкий; одна непредвиденная
проблема и ее может просто «сдуть», как одуванчик ветром.
Кроме того, каждый HTML-файл представлял собой массу разметки середины
90-х годов, дополненную повсюду вложенными тегами TABLE и FONT. Не
было возможности отделить контент от презентации, и каждый редизайн сайта
(а их было много) включал в себя ручную переработку этих файлов. Серверные
включения в определенной степени помогли, но каждый файл по-прежнему
представлял собой огромный комок смешанного контента и кода
форматирования.
Некоторое время спустя я работал в Microsoft Network менеджером форума
«Мир Джеймса Бонда». Мы все еще писали HTML-файлы в текстовых
редакторах, но Microsoft познакомила своих контент-менеджеров с чудесами
Visual Source Safe, давно устаревшей системы управления исходным кодом. Он
обеспечивал резервное копирование, управление версиями и блокировку
файлов.
Это явно сделало нас безопаснее с точки зрения управления рисками, но
произошел и ментальный сдвиг. Теперь у нас была сеть безопасности. Контент,
который мы создавали, был солидным. Была история и контекст. Мы
редактировали и дорабатывали постоянный контент, а не просто меняли его на
месте. Содержимое существовало не только в простых файлах, оно
существовало внутри более крупной системы, которая предоставляла набор
сервисов для его защиты. Мы перешли от того, чтобы прятать деньги в
матрасах, к хранению их в финансовом учреждении, застрахованном
Федеральной корпорацией по страхованию вкладов (FDIC).
Наконец, на каком-то грубом уровне, моим контентом удалось управлять. Все
еще было запутано с его представлением и, вероятно, имело массу других
проблем, но я был по крайней мере на пару шагов безопаснее, чем был раньше.
Я даже не осознавал этого, но Visual Source Safe фактически стал моей первой
системой управления контентом.
2 Хотя сайт уже не существует, он находился наhttp://ianfleming.org на протяжении многих лет. Есть
архив скринов вобщедоступная группа в Facebook, для интересующихся.
2 | Глава 1: Что такое управление контентом (и чем оно не является)

С тех пор многое изменилось, но давайте начнем с самого начала. Попутно мы
надеемся ответить на все следующие вопросы:
• Что такое контент?

• Что такое управление контентом?
• Что такое система управления контентом?
• Какие существуют типы систем управления контентом?
• Что делает система управления контентом?
• Чего не делает система управления контентом?
ЧтоСодержание?
Многие люди пытались провести различие между нечеткими понятиями
«данные», «информация», «содержание» и даже «знания». Боб Бойко посвятил
этому вопросу всю первую часть своей плодотворной работы «Библия
управления контентом» (Wiley) — около 5 глав и 61 страницы.
Мы не собираемся заходить так далеко, но подведем итоги, просто разграничив
контент и необработанные данные, что, вероятно, является самой высокой
отдачей, которую мы можем получить. Чем управление контентом отличается
от управления любым другим типом данных?
Есть два ключевых различия:
• Контент создается по-другому.

• Контент используется по-разному.
Сделано Люди через Редакционный процесс

Контент создается посредством «редакционного процесса». Этот процесс
представляет собой то, что люди делают, чтобы подготовить информацию для
публикации аудитории. Он включает в себя моделирование, создание,
редактирование, рецензирование, утверждение, управление версиями,
сравнение и контроль.
Например, создание новостной статьи очень субъективно. Две редакционные
группы, получив одну и ту же информацию, могут подготовить две совершенно
разные новостные статьи из-за человеческого фактора, вовлеченного в
редакционный процесс. В то время как вычислительная функция каждый раз
стремится получить один и тот же результат из одних и тех же входных
данных, редакционный процесс никогда этого не делает.
Что такое контент? | 3
Создание контента во многом зависит от мнения редакторов:
• Какова должна быть тематика контента?

• Кто является целевой аудиторией контента?
• С какой стороны следует подходить к предмету?
• Какой длины должен быть контент?
• Нужна ли поддержка СМИ?
Несмотря на значительные достижения в области вычислений, компьютер не

будет принимать такие решения. Это беспорядочные, субъективные,
несовершенные решения, исходящие из головы редактора-человека, сидящего
за клавиатурой. Небольшое отклонение в любом из них (пресловутое
хлопаньекрылья бабочки) может повернуть часть контента в совершенно
другом направлении. Содержание субъективно и открыто для оценки и
интерпретации. В этом есть нюанс. Это кустарное производство.
Редакционный процесс является итеративным: контент редко создается один
раз идеально, а затем больше к нему не прикасается. Скорее, контент
обрабатывается и совершенствуется снова и снова, как глина на гончарном
круге, часто даже после публикации. Содержание может меняться с течением
времени и в зависимости от обстоятельств. То, что было актуальным в какой-то
момент, возможно, позже придется изменить или отозвать.
Контент постоянно находится в состоянии изменения и оборота. Это никогда
не бывает «правильным». Это просто «прямо сейчас».
Сравните этот процесс с созданием записи о розничной продаже. Проведение
кредитной карты через терминал не требует никакого редакционного процесса.
Кроме того, созданные данные не подвергаются какой-либо другой обработке,
не будут проверены и утверждены. Оно не субъективно, оно детерминировано.
Транзакция произошла в одно мгновение, была создана историческая запись, и
все.
Сделка купли-продажи спроектирована так, чтобы быть максимально
повторяемой и лишенной субъективного мнения. Он никогда не будет
отредактирован (на самом деле, это может привести к нарушению политики
или закона). По своей конструкции он холодный, стерильный и инертный.
Следовательно, управление этими двумя типами информации совершенно различно.
Намеревался для Человек Потребление с помощью Публикация к

аАудитория
Контент — это данные, которые мы создаем для определенной цели:
распространять их с намерением, чтобы они в конечном итоге были
использованы другими людьми. Конечно, она может быть получена другим
компьютером через API, перекомпонована и опубликована где-то еще, но в
конечном итоге информация где-то доберется до человека.
www.allitebooks.com
Боб Бойко пишет:
Если убрать все технологии и терминологию, которые мы используем для
описания информационных систем, что у вас останется? Простая и совершенно
банальная идея: информационные системы помогают вам разговаривать с
людьми, которых нет рядом с вами.3
Наша сделка купли-продажи из предыдущего раздела не имеет такой судьбы.
Он был создан как ретроспективная запись исторического события. Скорее
всего, в будущем он не будет потреблен кем-либо, кроме как в совокупности
посредством какой-либо отчетности. Его можно получить и просмотреть
индивидуально, но только по необходимости и, скорее всего, в виде
исключения.
Наша новостная статья, напротив, создавалась как перспективная статья,
которая будет опубликована в будущем и использована людьми по любому
каналу (возможно, по нескольким). Его можно перепрофилировать, сокращать,
переставлять и переформатировать, но конечная цель — быть употребленным и
оцененным другим человеком.
Наш контент имеет ценность в будущем. Он может потребляться годами (даже
веками или тысячелетиями) и может продолжать приносить пользу
организации еще в далеком будущем. Каждый раз, когда читается наша статья
или каждый раз, когда новый сотрудник читает политику расчета заработной
платы, создатель контента получает выгоду.
Контент — это инвестиция в будущее, а не запись прошлого.
Определение содержания
Объединив эти две концепции вместе, мы приходим к лучшей попытке дать
краткое определение:
Контент — это информация, созданная в ходе редакционного процесса и в
конечном итоге предназначенная для потребления человеком посредством
публикации.
Это определение также указывает на основную дихотомию управления
контентом: разницу между (1) управлением и (2) доставкой. Контент создается
и управляется, затем он публикуется и доставляется. Эти две дисциплины
требуют разных навыков и мышления, а состояние современных технологий с
каждым днем создает все больше и больше различий.
В этой книге мы еще вернемся к этому двустороннему подходу к управлению контентом.
Что Является а Содержание УправлениеСистема?

Система управления контентом (CMS) — это пакет программного обеспечения,
который обеспечивает определенный уровень автоматизации задач,
необходимых для эффективного управления контентом.
3 Боб Бойко, Смеясь над ИТ-директором (Медфорд: CyberAge Books, 2007), 99–100.
Что такое система управления контентом? | 5

CMS обычно базируется на сервере,4 многопользовательское программное
обеспечение, которое взаимодействует с контентом, хранящимся в
репозитории. Этот репозиторий может располагаться на том же сервере, как
часть того же программного пакета или полностью в отдельном хранилище.
CMS позволяет редакторам создавать новый контент, редактировать
существующий контент, выполнять редакционные процессы над контентом и, в
конечном итоге, делать этот контент доступным для использования другими
людьми.
Логично, что CMS состоит из множества частей. Интерфейс редактирования,
репозиторий, механизмы публикации и т. д. могут быть отдельными,
автономными частями системы. Однако для нетехнического редактора все эти
части обычно рассматриваются как единое монолитное целое: «CMS».
Дисциплина против программного обеспечения

Важно отметить, что «система управления контентом» — это специфическое
проявление программного обеспечения, разработанное для обеспечения
дисциплины управления контентом. Подобно тому, как Ford Taurus является
конкретным проявлением устройства, обеспечивающего личный транспорт,
Drupal, WordPress и Episerver являются конкретными проявлениями
программного обеспечения, позволяющего управлять контентом.
Дисциплина управления контентом — накопленные теории, лучшие практики и
общепринятые модели в этой области — превосходит любую конкретную
систему. В этом смысле это платоновский идеал: абстрактное, субъективное
представление о том, как следует управлять контентом.
Специфика этого идеала может сильно различаться в зависимости от опыта,
предпочтений и потребностей наблюдателя. Это означает, что не существует
единого общепринятого определения управления контентом как дисциплины, а
есть лишь набор спорных лучших практик. Хотя люди могут попытаться
претендовать на существование Великой единой теории управления контентом,
такой вещи не существует.
К счастью, это означает, что навыки работы с конкретной системой управления
контентом можно в некоторой степени передать другим. Даже если система А
сильно отличается от системы Б, им обеим все равно необходимо решать
трансцендентные проблемы дисциплины, такие как рабочий процесс,
управление версиями, публикация и т. д. Хотя конкретные технические навыки
могут не передаваться, работа с системой управления контентом требует
применение и развитие навыков в области управления контентом.
4 Ранние CMS не были серверными. Некоторые из первых CMS представляли собой инструменты
создания шаблонов на стороне клиента, такие как CityDesk, MarsEdit и Radio UserLand. Это были
устанавливаемые пакеты программного обеспечения, которые позволяли редакторам работать с
контентом в интерфейсе рабочего стола. Затем системы шаблонизировали этот контент и
передавали полученный HTML-код на сервер, обычно через FTP. Сегодня их часто называют
инструментами «управления контентом рабочего стола». Лишь немногие из этих платформ активно
разрабатываются, но большинство все еще существует для покупки.

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

Мы определили контент как «информацию, созданную в процессе
редактирования и предназначенную для потребления человеком». Обратите
внимание, что в этом определении не было упоминания о Сети (как и о самом
Интернете).
Однако, учитывая, что эта книга посвящена управлению веб-контентом,
вероятно, лучше всего будет дать определение нескольким различным
вариантам управления контентом, а не сваливать их в одну большую корзину.
«Большую четверку» управления контентом можно определить как:
Управление веб-контентом (WCM)
Управление контентом, предназначенным в первую очередь для массовой
доставки через веб-сайт. WCM превосходно отделяет контент от
представления и публикации по нескольким каналам.
Управление корпоративным контентом (ECM)
Управление общим бизнес-контентом, не обязательно предназначенным
для массовой доставки или потребления (например, резюме сотрудников,
отчеты об инцидентах, заметки и т. д.). Традиционно этот вариант был
известен как «управление документами», но с годами этот термин получил
широкое распространение. ECM превосходно работает в области
совместной работы, контроля доступа и управления файлами.
Управление цифровыми активами (DAM)
Управление и манипулирование богатыми цифровыми активами, такими
как изображения, аудио и видео, для использования в других медиа. DAM
превосходно справляется с метаданными и их воспроизведением.
Управление записями (RM)
Управление информацией о транзакциях и другими записями, которые
создаются как побочный продукт бизнес-операций (например, записи о
продажах, записи о доступе, контракты и т. д.). RM превосходно
справляется с хранением и контролем доступа.
Очевидно, что грань здесь несколько размывается. плотина 6 Система часто
используется для предоставления контента веб-сайту посредством интеграции
с WCM. Более того, некоторые системы ECM имеют системы, с помощью
которых они могут публиковать часть своей информации в Интернете.
5 «Пламя» было первоначальным термином для обозначения двух людей, оскорбляющих друг
друга перед виртуальной аудиторией с помощью анонимной магии Интернета. Кажется, теперь
это называется «Facebook».
6 Аббревиатура, ставшая источником бесчисленных шуток, которые, вопреки мнению некоторых,
никогда не устареют.
Типы систем управления контентом |7

Программные системы известны только благодаря их предполагаемому
использованию и восприятию в отрасли. Drupal хорошо известен как система
WCM, но, несомненно, существуют организации, использующие ее для
управления внутренним контентом предприятия. И наоборот, Documentum —
это ECM-система, но некоторые организации могут использовать ее для
доставки всех или части своих веб-сайтов.
DAM интересен тем, что он различается в первую очередь на основе того, что
он делает с контентом. В то время как практически любая система управления
контентом может хранить файлы видео и изображений, и ECM действительно
превосходит ее, DAM идет еще дальше, предоставляя уникальные инструменты
для рендеринга и преобразования цифровых активов. Размер изображений
можно масштабировать, а видео можно объединять и редактировать
непосредственно внутри системы, что делает систему DAM отличительной
чертой одного из процессов, которые можно применять к контенту. Таким
образом, основные функции управления системы DAM во многом совпадают с
функциями системы ECM, при этом система DAM имеет уровень
функциональности сверху. (Действительно, многие системы DAM продаются
просто как дополнения к системам ECM.)
Есть и другие, еще более размытые оттенки серого. Некоторые примеры:
Системы управления контентом компонентов (CCMS)
Используется для управления очень детальным контентом (абзацы,
предложения и даже отдельные слова), часто для сборки документации или
высокотехнологичного контента.
Системы управления обучением (LMS)
Используется для управления учебными ресурсами и взаимодействия
студентов; большинство колледжей и университетов управляют учебными
программами и процессом обучения через LMS.
Порталы
Используется для управления, представления и агрегирования нескольких
потоков информации в единую систему.
Опять же, линии здесь очень размыты.
Лишь часть того, что делает LMS, специфична и уникальна для нее. Например,
многие различные системы WCM имеют надстройки и расширения, которые
претендуют на то, чтобы превратить их в LMS, а многие другие просто
используются как таковые «из коробки».
В конце концов, данная программная система мысленно классифицируется
среди общественности на основе нескольких факторов:
• Рынок, на котором он продвигает себя и на котором он конкурирует.

• Варианты использования и примеры, которые создает и продвигает сообщество
пользователей.
• Конкретные функции, предназначенные для удовлетворения потребностей
конкретного пользователя или типа контента.
Программное обеспечение CMS ориентировано на определенные рынки или
сценарии использования. Это никогда не мешало никому использовать его
способами, выходящими за рамки того, для которого его разработал
поставщик.
Для целей этой книги мы сосредоточимся на распространенном WCM —
программном обеспечении, предназначенном для управления веб-сайтом,
предназначенным для публичного распространения и потребления.
(И, рискуя забить эту тему до смерти, даже это обозначение размыто.
Организации обычно управляют платформами социальных сетей из своих
систем WCM, управляя контентом, который в конечном итоге превращается в
обновления Facebook, твиты или даже электронные письма. Хотя это
технически это не «контент веб-сайта», нашего определения будет достаточно.)
Что Делает "Предприятие"Иметь в виду?

Это слово часто встречается в составе таких фраз, как «корпоративное
программное обеспечение» или «корпоративный контент». У него нет точного
определения, но обычно оно означает «большой» или «предназначенный для
крупных организаций».
Это расплывчатый термин, и не существует его полной противоположности:
немногие CMS называют себя «провинциальными» или «бутиковыми». И
ничто не мешает самой маленькой в мире CMS называть себя «корпоративной».
Это очень субъективно: то, что велико для одного человека, мало для другого.
Поставщики CMS используют этот термин, чтобы указать, что их системы
могут обрабатывать большие объемы контента или вписываться в очень
распределенную, сложную среду (например, несколько серверов с
балансировкой нагрузки в нескольких центрах обработки данных). Его также
часто используют для определения ожиданий относительно цен:
«корпоративный» обычно означает «дорогой».
«Корпоративный контент» часто используется для обозначения внутреннего
контента, который не публикуется за пределами организации. Используя это
определение, выпуск новостной статьи не является «корпоративным
контентом», в отличие от внутренних протоколов собрания руководителей.
Под «системой управления корпоративным контентом» расплывчато понимают
Что делает CMS
Давайте разберем основные функции CMS. В общих чертах, каково ценностное
предложение? Почему нам лучше с CMS, чем без нее?
Управление контентом
CMS позволяет нам получить контроль над нашим контентом, и вы это хорошо
поймете, если ваш контент выйдет из-под контроля. CMS отслеживает контент.
Он «знает», где находится наш контент, в каком он состоянии, кто может
получить к нему доступ и как он связан с другим контентом. Более того, он
стремится предотвратить возникновение плохих вещей с нашим контентом.
Что делает CMS | 9

В частности, CMS обеспечивает основные функции управления, такие как:
Разрешения
Кто может видеть этот контент? Кто может это изменить? Кто может удалить его?
Управление состоянием и рабочий процесс
Опубликован ли этот контент? Это в черновике? Было ли оно
заархивировано и удалено от общественности?
Управление версиями
Сколько раз менялся этот контент? Как это выглядело три месяца назад?
Чем эта версия отличается от текущей? Могу ли я восстановить или
повторно опубликовать старую версию?
Управление зависимостями
Какой контент используется каким другим контентом? Если я удалю этот
контент, как это повлияет на другой контент? Какой контент в настоящее
время «осиротеет» и не используется?
Поиск и организация
Как найти конкретный фрагмент контента? Как мне найти весь контент,
относящийся к X? Как мне группировать и связывать контент, чтобы им
было легче управлять?
Каждый из этих пунктов повышает наш уровень контроля над нашим
контентом и снижает риск — снижается вероятность того, что отчет для
акционеров будет опубликован раньше времени или что единственная копия
нашего руководства по процедурам будет случайно удалена.
Позволять Содержаниеповторное использование

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

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

просто извлекается и отображается из общего места.
Повторное использование контента было одной из первоначальных проблем,
беспокоивших первых веб-разработчиков. Помните сайт о Джеймсе Бонде, о
котором я говорил ранее? Одним из самых больших разочарований было
создание статьи, а затем добавление ее на все индексные страницы, где она
должна была появиться. Если бы мы когда-нибудь удалили статью или
изменили заголовок, нам пришлось бы найти все ссылки и удалить или
изменить их.
Эта проблема была несколько смягчена благодаря включению на стороне
сервера, которое позволяло редакторам страниц вставлять фрагмент HTML,
просто ссылаясь на отдельный файл — файлы были объединены на сервере
перед доставкой. Более поздние платформы пытались автоматизировать это
еще больше; Например, в Microsoft FrontPage была функция, названная «Общие
границы».
Возможность повторного использования контента во многом зависит от
структуры этого контента. Ваша способность точно структурировать контент
для оптимального повторного использования во многом зависит от функций,
которые предоставляет вам ваша CMS.
Позволять Содержание Автоматизация иАгрегация

Расположение всего нашего контента в одном месте упрощает его запрос и
манипулирование им. Если мы хотим найти все новостные статьи, написанные
на прошлой неделе, и в которых упоминается слово «СПЕКТР», мы можем это
сделать, потому что есть одна система, которая «знает» все о нашем контенте.
Если наш контент структурирован правильно, мы можем манипулировать им
для отображения в разных форматах, публиковать его в разных местах и
оперативно переупорядочивать, чтобы более эффективно удовлетворять
потребности наших посетителей:
• Мы можем разрешить пользователям использовать контент в других

форматах, таких как PDF или другие форматы электронных книг.
• Мы можем автоматически создавать списки и навигацию (в более общем
смысле, «агрегации контента» — см.Глава 7) для нашего сайта.
• Мы можем создать несколько переводов контента, чтобы обеспечить язык,
наиболее подходящий текущему пользователю.
• Мы можем изменять публикуемый контент в режиме реального времени в
зависимости от конкретного поведения и условий наших посетителей.
CMS позволяет это сделать, структурируя, храня, проверяя и предоставляя

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

Способность редакторов быстро и точно создавать и редактировать контент во
многом зависит от используемой платформы. Редко можно найти редактора,
который безоговорочно любит CMS, но альтернатива — редактирование веб-
сайта вручную — явно гораздо менее желательна.
Эффективность редактора повышается за счет системы, которая контролирует,
какой тип контента редакторы могут и не могут добавлять, какие инструменты
форматирования им доступны, как обрабатывается их контент.
Что делает CMS | 11
структурированы в интерфейсе редактирования, как управляется редакционный
рабочий процесс и совместная работа, а также что происходит с их контентом
после публикации.
Хорошая CMS позволяет редакторам публиковать больше контента в более
короткие сроки (она увеличивает «пропускную способность редактирования»),
а также контролировать и управлять опубликованным контентом с меньшими
трудностями и задержками в процессе.
Редакционная эффективность оказывает огромное влияние на моральный дух,
который неосязаем, но имеет решающее значение. У многих редакторов
исторически сложились антагонистические отношения со своими CMS, и ничто
не разрушает редакционную эффективность быстрее, чем неуклюжий
редакционный интерфейс и порядок работы.
Чего не делает CMS

Теперь о плохих новостях: есть вещи, которые CMS не делает. Точнее, есть
вещи, которые CMS не делает, но люди ошибочно полагают, что они делают,
что приводит к проблемам и несбывшимся ожиданиям.
СоздаватьСодержание
CMS просто управляет контентом, а не создает его. Он не пишет ваши
новостные статьи, процедурные документы или сообщения в блогах. Вы все
равно должны предоставить редакционную мощь для создания контента,
которым она должна управлять.
Много раз внедрение CMS заканчивалось тем, что группа людей смотрела друг
на друга и думала: «Ну и что теперь?» Каждый магазин веб-разработки в
стране может рассказать вам истории о новой блестящей CMS, которую клиент
ни разу не использовал, потому что они никогда не меняли свой сайт со дня его
запуска. Время от времени моя компания принимала звонки от клиентов спустя
годы после запуска их сайтов, которые хотели узнать, как впервые войти в
свою CMS.
В связи с этим CMS также не гарантирует, что ваш контент будет хорошим.
Хотя CMS может предлагать несколько инструментов для минимизации
некачественного контента с технической точки зрения (например, гарантируя,
что гиперссылки действительны или что все изображения имеют теги ALT),
CMS не может редактировать ваш контент, чтобы убедиться, что он имеет
смысл и соответствует требованиям. потребности вашей аудитории.
Хорошо продуманные планы по созданию огромных объемов качественного
контента часто терпят неудачу, когда сталкиваются с суровой реальностью
жесткого графика и сроков работы. Вам необходимо убедиться, что процесс
создания контента существует отдельно от вашей CMS.
Создавать МаркетингПланы
Даже если предположить, что ваш контент создается последовательно и
хорошо управляется, это не означает, что он действительно представляет
какую-либо ценность для вашей организации.

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

Хотя CMS может структурировать контент и автоматически форматировать его
во время публикации, у редактора-человека все еще остается мало места, чтобы
все испортить. Большинство CMS имеют редактор форматированного текста
или какой-либо другой элемент интерфейса, который позволяет редакторам
форматировать текст и изображения. Это может привести к таким вещам, как:
• Слишком частое использование жирного шрифта и курсива

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

они не хотели бы нажимать. Кажется, единственный способ ограничить это —
удалить как можно больше параметров редактирования, а затем попытаться
противостоять граду жалоб редакторов, который неизбежно последует.
Обеспечить управление
«Управление» описывает доступ к вашему контенту и процессы, связанные с
ним: кто к чему имеет доступ и какие процессы/шаги они выполняют, чтобы
внести в него изменения. Например:
• Если Боб добавит новостную статью, кто должен ее утвердить и как будет
выглядеть это одобрение? Кто-то редактирует, а кто-то другой редактирует
качество, голос и тон? Можете ли вы изобразить этот процесс на листе
бумаги?
• Если Джон хочет изменить организацию архивов новостей, и CMS
позволяет ему это сделать… сможет ли он? Какой процесс ему придется
пройти, чтобы это сделать?
• Если Дженнифер хочет создать учетную запись на CMS, чтобы начать
создавать контент, как она это получит? Кто решает, кому разрешено стать
редактором?
Чего не делает CMS | 13
В каждой CMS есть метод ограничения действий, которые может совершать
пользователь, но эти ограничения необходимо определить заранее. CMS просто
выполнит то, что прикажет ей ваша организация. Эти планы должны быть
созданы посредством человеческого взаимодействия и суждений, а затем
преобразованы в разрешения и ограничения доступа, которые может
обеспечить CMS.
Управление – это прежде всего человеческая дисциплина. Вы определяете
процессы и политики, которых люди будут придерживаться при работе с
вашим контентом. CMS — это всего лишь основа для обеспечения соблюдения
требований.
А ДомостроениеАналогия
Дом, в котором вы живете, представляет собой грубое сочетание трех вещей:
• Сырье для строительства (дерево, гвозди, стекло)

• Инструменты и строительное оборудование (молотки, пилы)
• Человеческая сила, чтобы все это осуществить (Тед, ваш подрядчик)
Ни одна из этих вещей сама по себе не строит дом.Куча дров остается просто
кучей дров, пока Тед не берет молоток и не заставляет что-нибудь произойти.
Тед здесь ключевой персонаж. Материалы и инструменты неодушевлены. Тед
— главный двигатель.
Что касается управления контентом:
• Сырье = ваш контент

• Инструменты и оборудование = ваша CMS
• Тед = ты
Весь контент в мире бесполезен, если им не управлять. И весь менеджмент в

мире мало что сделает, если нет контента. Ни один из них ничего не делает без
человеческих процессов и усилий, заставляющих их работать вместе, точно так
же, как куча дерева и молоток не могут волшебным образом построить дом.
Вы — то, что связывает все это воедино.Ты тот, кто заставляет все это идти.
CMS — это всего лишь инструмент.
ГЛАВА2
Точки сравнения
В медицине определенные состояния известны как «расстройства спектра»,

поскольку они не являются простыми бинарными состояниями, от которых вы
страдаете или не страдаете. Скорее, эти состояния существуют в различной
степени тяжести. Человек может страдать от этого заболевания незначительно
или сильно, и разница может проявляться в виде совершенно разных
симптомов и требовать совершенно разного лечения.
Управление веб-контентом может осуществляться таким же образом.
Чтобы продемонстрировать это, было бы полезно рассмотреть аспекты
управления контентом как серию сравнений или дихотомий. Понимая диапазон
доступных вариантов по определенной оси и границы с обеих сторон, мы
можем начать понимать всю широту вариантов.
Существует множество аспектов систем, реализаций и практик, которые не
являются черно-белыми. На самом деле, в управлении контентом есть
несколько абсолютов. То, что правильно в одной ситуации, явно неправильно в
другой. То, что хорошо для одной организации, будет катастрофой для другой.
Ключом к работе CMS является принятие правильных решений для вашей
ситуации, из-за чего это часто кажется скорее искусством, чем наукой.
Более того, фундаментальные различия, которые мы собираемся здесь изучить,
затрудняют точное сравнение CMS. Вместо яблок к яблокам вы получаете
яблоки и жаркое в горшочке. Например:
• Drupal Gardens — это размещенный сервис, созданный на PHP с

использованием связанной модели, предлагающий мало маркетинговых
инструментов и мало возможностей для настройки или реализации.
• Ingenuix — это установленная система, построенная на ASP.NET с
использованием несвязанной модели, предлагающая автоматизацию
маркетинга и глубокую настройку и требующая значительного внедрения.
15
Техническое сравнение этих двух систем затруднено, поскольку они лежат на
противоположных концах нескольких осей сравнения:
• Один размещен, другой установлен.

• Один из них построен на PHP, другой — на .NET (а поскольку один из них
размещен на хостинге, часто пользователей просто не волнует, что он
построен на каком-то конкретном языке).
• Один связан, другой развязан.
• Один коммерческий, другой с открытым исходным кодом.
Правильное решение для любого конкретного аспекта вашей ситуации

находится где-то между двумя концами шкалы. Поэтому нам необходимо
понять, как выглядит каждый конец этой шкалы.
Тип целевого сайта

Разные CMS ориентированы на разные типы сайтов. Диапазон предполагаемых
конечных результатов огромен. «Веб-сайт» может быть любым из следующих:
• Небольшой статический маркетинговый сайт для стоматологического кабинета.

• Многонациональная газета, публикующая сотни статей в день.
• Единый авторский блог для автора, пишущего о технологиях.
• Интранет для бухгалтерской фирмы среднего размера
• Экстранет для дилеров производителей сельхозтехники
• Библиотека документации продукта для разработчика программного обеспечения
• Материалы курса и программы для небольшого университета
• Интернет-сообщество и социальная сеть для владельцев автомобилей Porsche.
Не существует простого способа провести жесткие границы вокруг того, что

мы имеем в виду, когда говорим «веб-сайт». Управление контентом является
проблемой для всех приведенных здесь примеров, и существуют CMS,
специализирующиеся на каждом из них. CMS, используемая в
стоматологическом кабинете, предположительно может быть использована для
работы веб-сайта газеты, хотя, скорее всего, она будет работать не очень
хорошо.
CMS очень редко позиционируется как универсальная система, решающая все
проблемы любого типа сайта. Конкретная CMS обычно нацелена на решение
определенного типа проблем. Некоторые проблемы могут быть широкими,
некоторые — узкими, но архитекторы CMS преследуют целевую проблему,
которую необходимо решить. Обычно в ваших интересах максимально
приблизить назначение вашей CMS к вашей проблеме.
16 | Глава 2: Точки сравнения
Системы и реализации
Важно отделить систему управления контентом от реализации CMS.
Реализация — это процесс, посредством которого CMS устанавливается,
настраивается, шаблонизируется и расширяется для создания желаемого веб-
сайта.
Если вы не создадите свою CMS с нуля, вы не единственный, кто ее
использует. Другие организации используют одно и то же программное
обеспечение для решения разных задач и создания разных типов веб-сайтов,
поэтому его не нужно предварительно настраивать для выполнения какой-то
одной задачи особенно хорошо. Это означает, что необходимым шагом
является первоначальная попытка адаптировать CMS так, чтобы она делала
именно то, что требует от нее ваша организация и обстоятельства.
«Первоначальные усилия» — это сильное упрощение. Дело в

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

можно сказать, что куча дров и набор инструментов — это не тот дом, который
вам нужен. Тед-подрядчик прилагает все усилия, чтобы использовать
инструменты для постройки дома. Это разовая работа, а конечным продуктом
является готовый дом. Более того, Майк-Подрядчик может использовать те же
материалы, чтобы построить совершенно другой дом.
Реализация — это значительный программный проект. Требуемый набор
навыков мало чем отличается от набора других навыков разработки: вам
нужны дизайнеры, разработчики, специалисты по интерфейсу, менеджеры
проектов и эксперты по самой CMS. Организации иногда реализуют свои
собственные реализации, но часто это поручается фирме-разработчику, которая
специализируется на внедрении CMS.
Расходы на внедрение обычно являются крупнейшими расходами в бюджете,
намного превосходящими даже лицензионные сборы за коммерческую CMS.
Эмпирическое правило различается в зависимости от того, кто его утверждает,
но плата за внедрение обычно в несколько раз превышает стоимость лицензии
на программное обеспечение.
Мой друг, когда его спросили, должна ли организация

«покупать или строить», ответил: «Не существует такого
понятия, как «покупай или строй». Всегда нужно покупать и
строить».
Реализация должна рассматриваться как минимум столь же важная для успеха
проекта, как и само программное обеспечение CMS. Во время реализации
необходимо принять множество решений, и две разные реализации одного и
того же веб-сайта с использованием
Системы и реализации |1 7
та же самая CMS может иметь мало общего. Любое из этих решений может
быть реализовано хорошо или плохо, и эти результаты окажут огромное
влияние на конечный результат.
Самая совершенная CMS в мире может стать практически бесполезной из-за
плохой реализации. И хотя я признаю, что некоторые CMS являются
непоправимо плохими или неподходящими для конкретной ситуации, я видел
множество блестящих реализаций, которые могли заставить посредственные
CMS работать для конкретного проекта.
Платформа против продукта

Если мы рассматриваем CMS как диапазон функциональной «полноты»,
крайности могут выглядеть так:
• Никакой функциональности CMS, просто сырая платформа программирования.

• Полнофункциональная CMS, готовая к использованию «из коробки»,
оснащенная готовыми функциями для решения всех ваших проблем с
контентом без каких-либо изменений.
«Из коробки» — фраза, часто используемая в мире CMS. Это

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

общим функциям и функциям управления контентом, которые можно
использовать для разработки собственного решения, а также
пользовательский интерфейс по умолчанию и конфигурацию для
поддержки общих потребностей.
Тони Бирн из Real Story Group назвал этот тип CMS «платформой», а
противоположный вариант — «продуктом».1
Платформенный стиль2 Системы спроектированы таким образом, чтобы их
можно было перекомпоновывать и настраивать в ходе реализации. Системы
стилей продукта созданы для быстрого и без значительных усилий решения
конкретных задач.
1 «Как дебаты о новых платформах и продуктах влияют на ваш успех» 23 февраля 2010 г.
2 Обратите внимание на намеренное использование термина «платформенный стиль» в качестве
уточнения. Трудно однозначно сказать, является ли что-то платформой или нет. Вернитесь к
комментарию о расстройствах спектра в начале главы. Некоторые системы являются
«платформенными» в некоторых аспектах, но не в других, а некоторые системы в целом более
«платформенны», чем другие. Быть платформой, а не продуктом, во многом зависит от степени.

Системы платформенного типа являются гибкими, но трудоемкими. Системы
продуктового стиля являются жесткими, но предположительно простыми в
реализации.
Это естественный компромисс. Приобретая продукт, вы обмениваете снижение
затрат на внедрение на согласие принять то, как работает система. Используя
платформу, вы обмениваете повышенные затраты на внедрение на большую
гибкость и контроль.
Многие поставщики позиционируют свои системы как продукты, готовые
решить все проблемы с контентом «из коробки» с минимальными усилиями.
Обратное встречается реже: очень немногие поставщики хотят прослыть
поставщиками систем, требующих героической настройки и программирования
для создания веб-сайта. Хотя это может понравиться хардкорным
разработчикам, обычно они не принимают решения о покупке.
Платформенная ориентация системы может использоваться для объяснения
степени и ожиданий от расширяемости и настраиваемости системы. Некоторые
CMS обладают широкими возможностями настройки, и это абсолютно
ожидаемо в каждой реализации. Другие CMS предназначены для
использования в том же виде, в каком они были приобретены, и предоставляют
мало возможностей для настройки.
Это просто связано с тем, что каждый поставщик CMS или сообщество
разработчиков учитывает варианты использования (буквально «случаи
использования») при разработке своей системы. Независимо от того, записаны
ли эти варианты использования где-то явно или нет, каждая CMS создается для
решения набора теоретических задач. Одна система может быть предназначена
для управления блогом, другая — для управления интрасетью.
Ваша способность использовать CMS в стиле продукта для решения ваших
проблем во многом зависит от того, насколько близко ваша ситуация
напоминает эти теоретические проблемы. Если они не совпадают, то ваша
способность использовать эту CMS для целей, выходящих за рамки ее
первоначального замысла, во многом зависит от расширяемости CMS.
Часто система в стиле продукта предоставляет готовые функциональные
возможности, которые очень близки к желаемому решению одной из ваших
проблем. В ситуациях, когда 90% недостаточно, продукт придется
адаптировать, чтобы восполнить этот пробел. Некоторые системы
предназначены для такой возможности, а другие нет.
ДействительныйПо сравнению с
теоретическими преимуществами
При обсуждении преимуществ любого типа программного обеспечения важно
различать фактические и теоретические преимущества:
• Реальные преимущества— это преимущества, которые ваша организация

использует и извлекает из них выгоду.
• Теоретические преимуществаЭто преимущества, которые существуют и
Платформа против продукта |1 9
и негативная картина того, что могло бы случиться с вашей организацией (и
вами в профессиональном плане), если бы вас поймали без этой теоретической
выгоды.
Было выбрано более одной CMS исключительно на основе функций, которые
организация не планировала использовать в ближайшем будущем (и обычно
никогда не планирует). Идея создания многофункционального продукта по
своей сути не является ошибочной, но она становится проблематичной, когда
стремление к определенной функции приводит к отказу или минимизации
более значимой функции.
Я называю это «синдромом Феррари» в честь покупателя автомобиля, который
никогда не будет ездить со скоростью более 80 миль в час, но, тем не менее,
ему нравится идея, что он мог бы проехать 200, если бы он действительно этого
хотел, и он отказывается от столь необходимого заднего сиденья в погоне за
этой идеей. . Воодушевление преимуществами, «возможными, но никогда не
реализованными», определяло решения о покупке с самого начала коммерции.
Как потребителям, нам нравится видеть себя компетентными, опытными
профессионалами, решающими сложные проблемы. Нас естественным образом
привлекают мощные инструменты, которые обещают помочь нам решать
сложные проблемы, поскольку они укрепляют это видение.
Будьте реалистичны в отношении функций, которые вы действительно будете
использовать. Определите те основные функции, без которых вы абсолютно не
можете функционировать («необходимые»), и убедитесь, что они хорошо
обслуживаются, прежде чем переходить к функциям, которые, по вашему
мнению, могут хорошо вам подойти и которые вы просто надеетесь
использовать однажды («приятно использовать»). -имеет»).
Обязательно оцените то, что, по вашему мнению, является «необходимым» по
этому критерию: если вы найдете систему, которая делает все идеально, кроме
этой одной вещи, отвергнете ли вы ее из-за этого единственного упущения?
Если нет, то это не «must-have».
Открыть Источник ПротивКоммерческий

Для большинства программного обеспечения существуют как коммерческие
(платные лицензии), так и варианты с открытым исходным кодом. Вероятно,
это более справедливо для управления контентом, чем для любого другого
жанра. Существуют буквально тысячи вариантов, и чрезвычайно
распространенные платформы CMS с открытым исходным кодом, такие как
WordPress и Drupal, используются на значительном проценте веб-сайтов по
всему миру.
Учитывая установленную базу и глубину использования, CMS с открытым
исходным кодом, как правило, хорошо протестированы, многофункциональны
и имеют большой объем кода и модулей. Доступность, оперативность и
точность поддержки сообщества обычно довольно высоки, но варьируются в
широких пределах.
Проект CMS с открытым исходным кодом обычно уходит корнями к
разработчику, который изначально создал его для решения конкретной личной
или профессиональной проблемы. Очень немногие системы представляют
собой проекты «с чистого листа», созданные с нуля и предназначенные для
распространения. Скорее, они начинаются как небольшие внутренние проекты
и растут до тех пор, пока не достигнут критической массы и не будут переданы
сообществу открытого исходного кода для дальнейшего развития.

Это приводит к изрядному разработчикоцентризму — некоторые из них
написаны разработчиками для разработчиков. Большинство проектов с
открытым исходным кодом подсознательно становятся интересными и
желанными в первую очередь для разработчиков, а затем для всех остальных.
Редакторы и маркетологи в таких случаях часто оказываются людьми второго
сорта.
В результате возникает общая закономерность — «синдром открытого
исходного кода», если хотите, — характеризующаяся:
• Системы платформенного типа с расширяемыми API-интерфейсами.

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

значительному демонтажу и реконструкции. Для многих разработчиков код и
процесс решения проблем с контентом сами по себе являются конечной целью.
Перестройка системы, чтобы сделать ее более элегантной, эффективной или
обобщаемой, считается стоящим усилием.
Более десяти лет назад Джоэл Спольски из Fog Creek Software жаловался
именно на эту проблему:
Мы программисты. Программисты в душе архитекторы, и первое, что они
хотят сделать, попав на объект, — это снести его бульдозером и построить что-
то грандиозное. Нас не в восторге от постепенного ремонта: мастерить,
улучшать, сажать клумбы.3
С другой стороны, коммерческие системы имеют встроенное ограничение —
им нужна лицензионная плата, поэтому конечной целью является продажа
программного обеспечения, а не его разработка. Очевидно, что это может
привести к принятию неправильных решений и замалчиванию реальных
технических проблем, но это также приводит к более ориентированной на
конечного пользователя разработке, поскольку функции для конечного
пользователя — это то, что продает лицензии. В конце концов, чтобы компания
могла оставаться в бизнесе, ей необходимо выпустить коммерческое
программное обеспечение.
Новые системы с открытым исходным кодом довольно распространены, хотя,
поскольку рынок сейчас более переполнен, любой новой системе становится
все труднее и труднее набирать обороты и достигать значительных успехов.
3 «Чего никогда не следует делать, часть I» 6 апреля 2000 г.
Открытый исходный код против коммерческого | 21

Хорошая установленная база. Следовательно, наиболее успешные CMS с
открытым исходным кодом являются также одними из самых старых.
Системы на основе PHP составляют львиную долю CMS с открытым исходным
кодом. Три наиболее распространенные CMS любого типа лицензирования
(WordPress, Drupal и Joomla!4) — все системы PHP.
Системы теряют популярность и поддержку разработчиков в первую очередь
из-за неспособности лежащего в их основе технологического стека привлекать
новых разработчиков — существуют десятки систем середины 90-х,
написанных на Perl, ColdFusion и (иногда) C++, которые медленно вымирают.
Новые системы с открытым исходным кодом на основе Java также становятся
все более редкими, поскольку Java становится менее популярной веб-
инфраструктурой.
Использование CMS с открытым исходным кодом дает множество преимуществ:
• Программное обеспечение бесплатное.

• Поддержка сообщества часто бывает многочисленной.
• Внесенный код часто доступен для решения распространенных проблем.
• Разработчики и подрядчики обычно очень
доступны. Но есть и некоторые недостатки:
• «Синдром открытого исходного кода», который мы обсуждали, имеет

тенденцию делать эти системы менее привлекательными для тех, кто не
является редактором.
• Повсеместное использование приводит к большому количеству
вредоносных программ, попыткам проникновения и исправлениям
безопасности (большое количество установок WordPress делает его
привлекательной целью для хакеров).
• Поддержка сообщества в особо сложных проблемах часто бывает недостаточной.
• Профессиональная поддержка на уровне обслуживания может быть недоступна.
• Использование программного обеспечения с открытым исходным кодом может нарушить
ИТ-политику организации.
• Программное обеспечение с открытым исходным кодом (не только CMS) в
значительной степени ориентировано на стеки технологий PHP и Java.
Некоторые из этих моментов мы обсудим более подробно вГлава 3.
4 Я не возбудимый человек по натуре. Восклицательный знак на самом делеофициальная часть

названия система управления контентом.
Перспектива:Синдром коммерческого программного обеспечения
Ларри Гарфилд
В то время как многие CMS с открытым исходным кодом
начинались как проекты инженеров-любителей, успешные
из них превратились в то, чтобы поставить во главу угла
пользовательский опыт. В частности, «большая тройка»
(Drupal, WordPress и Joomla!) приложила немало усилий,
чтобы сделать сложный по своей сути мир
структурированного контента более доступным для
конечных пользователей.
Кроме того, поскольку они, как правило, более сложны для инженеров, OSS
проекты не страдают «синдромом коммерческого ПО»; Многие проприетарные
CMS имеют очень отточенные демо-версии, но эта доработка лишь
поверхностна. За красивым пользовательским интерфейсом скрывается
недостаток базовой мощности и гибкости — решающей мощности и гибкости,
над которыми интересно работать разработчикам с открытым исходным кодом.
В результате ведущие проекты OSS часто обладают гораздо более мощной
функциональностью, чем их собственные аналоги, даже если для их
использования может потребоваться немного больше обучения и
документации. И это при том, что использование остается бесплатным, что
часто может быть большим преимуществом.
Ларри Гарфилд — старший архитектор и руководитель сообщества
Palantir.net, цифрового агентства полного цикла услуг в Чикаго, а также один
из ведущих разработчиков Drupal 8.
Технологический стек
Все программное обеспечение работает на «стеке» вспомогательного
программного обеспечения, баз данных и языков. CMS всегда реализуется на
определенном языке и платформе хранения (которая может быть
«заменяемой», а может и не быть «заменяемой»). Этот язык и структура
хранения сильно влияют на то, какая среда хостинга должна работать CMS.
В стек входит следующее:
• Сама система управления контентом

• Структура программирования
• Язык программирования
• Сервер базы данных
• Веб-сервер
• Операционная система
Технологический стек |2 3
Вы можете представить это как кучу технологий, над которыми находится
CMS, требующая для правильной работы всего, что находится под ней.Таблица
2-1 показывает пример сравнения стека для двух очень разных систем:
Episerver и eZ Platform.
Таблица 2-1. Сравнение технологических стеков Episerver

иПлатформа eZ
Элемент стека Эписервер Платформа eZ
Фреймворк программирования ASP.NET MVC Симфония
Язык программированияС # PHP
Сервер базы данных SQL-сервер Несколько (обычно
MySQL) Веб-сервер Интернет Информация Сервер (ИИС) Несколько
(обычно Apache) Операционная система ОкнаНесколько
(обычно Linux)
Самая грубая классификация CMS может быть по стеку технологий.5 Наиболее

распространенные стеки:
• LAMP (Linux, Apache, MySQL и PHP/Python/Perl; хотя почти всегда PHP)

• АСП.NET (Windows)
• Java/J2EE (Linux или
Windows)Менее
распространенные стеки
включают в себя:
• Рубин на рельсах
• Python (обычно фреймворк Django)
• Node.js
Системы не могут быть переключены на разные языки выполнения, но среды

хостинга могут незначительно отличаться. Например, хотя PHP обычно
работает на Apache и Linux, он может достаточно хорошо работать и на
Windows. ASP.NET почти всегда работает в Windows, но иногда может
работать и в Linux через платформу Mono.
Это имеет значение в первую очередь, если ваша организация ограничивает
набор поддерживаемых технологий. Хотя было бы идеально выбрать CMS,
основываясь исключительно на функциях и ее пригодности для вашей
конкретной ситуации, CMS все равно необходимо где-то установить и
разместить. Если ваша организация размещает его, они могут диктовать весь
стек или его часть. То же ограничение применяется, если ваша организация
собирается внедрить ее собственными силами – если ваша разработка
5 Для разработчиков, конечно, это обычно определяющая характеристика. Когда разработчики
описывают CMS, они всегда начинают с дескриптора стека: «Ну, это система PHP…» или «Она
встроена в .NET…».
www.allitebooks.com
В группе поддержки полно Java-программистов, то велика вероятность, что вы
ограничитесь этим стеком.
ИТ-отдел довольно часто поддерживает только определенные комбинации
технологий. Серверы Windows являются общим требованием в корпоративных
ИТ, как и конкретные платформы баз данных. Некоторые компании диктуют
Oracle как свою единственную официально поддерживаемую базу данных, в то
время как другие могут быть более либеральными. Если эти ограничения
существуют в вашей организации, они обязательно сократят количество
возможных CMS, которые вы можете внедрить.
Желательность того или иного конкретного стека является предметом
серьезных дискуссий и выходит далеко за рамки этой книги. Важным
моментом является то, что ограничения технологического стека — если они
существуют — обычно очень жесткие. Если ваша организация требует, чтобы в
ее центре обработки данных могли работать только серверы Windows, это вам
обязательно нужно знать, прежде чем выбирать CMS.
Конечно, размещение вашей CMS за пределами ИТ-политики

вашей организации — это широко используемая тактика,
позволяющая обойти наложенные ограничения. Многие
отделы маркетинга добавили услуги хостинга в запрос
предложений, чтобы не соблюдать ограничения, налагаемые
ИТ-отделом.
Управление ПротивДоставка
Хотя почти все, что делает CMS, по умолчанию относится к категории
«управление», жизненный цикл части контента можно эффективно разделить с
помощью гипотетической кнопки «Опубликовать».
Все, что происходит с контентом с момента его создания и до момента его
смерти, — это «менеджмент». Подмножество всего, что происходит с
опубликованной версией этого контента с момента его публикации, — это
«доставка». Эти две дисциплины совершенно разные.
Управление – это безопасность, контроль и эффективность. Он состоит из
таких функций, как моделирование контента, разрешения, управление
версиями и рабочий процесс. Это функции, которые упрощают создание
контента, обеспечивают совместную работу редакторов и обеспечивают
безопасность контента.
Доставка — это оптимизация и производительность. Функции,
задействованные в доставке, во многом зависят от возможностей CMS. Эти
возможности в настоящее время быстро развиваются на рынке. До недавнего
времени доставка просто означала предоставление контента в публичном
месте. Сегодня современные CMS очень озабочены производительностью и
оптимизацией предоставляемого контента.
В коммерческом пространстве мы видели множество инструментов, которые
позволяют осуществлять расширенный маркетинг во время доставки. Такие
функции, как персонализация, A/B-тестирование и аналитика, имеют
Управление против доставки |2 5

увеличивается, поскольку разные поставщики пытаются разделить свои
системы. Раньше эти функции предоставлялись отдельными пакетами
программного обеспечения для «автоматизации маркетинга», которые работали
исключительно в среде доставки. Эти инструменты все чаще встраиваются в
CMS.
Непреднамеренным результатом является то, что основные инструменты
управления мало изменились за последние полдесятилетия. Во многих случаях
эти инструменты достигли зрелости, и в настоящее время основное внимание
уделяется инструментам маркетинга и оптимизации во время поставки.
Управление обычно считается «достаточно хорошим».
Связанный ПротивРазвязанный
Дихотомия «управление и доставка» проявляется технически при
рассмотрении уровня связи CMS. Какие отношения между хостингом и средой
управления CMS имеет среда доставки?
В связанной системе управление и доставка происходят на одном сервере (или
ферме серверов). Редакторы управляют контентом в той же системе, где его
потребляют посетители. Управление и доставка — это просто две стороны
одного и того же программного обеспечения.
Это чрезвычайно распространенная парадигма. Многие разработчики и
редакторы больше ничего не знают.
В несвязанной системе управление и доставка (подождите) отделены друг от
друга. Содержимое управляется в одной среде (один сервер или ферма), а затем
публикуется в отдельной среде (другой сервер или ферма). В таких ситуациях
функции управления иногда называют «сервером репозитория», а доставка
контента происходит на «сервер публикации» или «сервер доставки». В этих
случаях опубликованный контент переносится в совершенно отдельную среду,
которая может иметь или не иметь никаких сведений о том, как контент был
создан или как им управляют.
Все меньше и меньше систем поддерживают эту парадигму, и это обычно
наблюдается в высокодоступных или распределенных средах публикации,
например, когда веб-сайт доставляется с нескольких серверов, распределенных
по нескольким центрам обработки данных (хотя это может измениться, как мы
обсудим). в конце книги). Он имеет предполагаемые преимущества
безопасности, стабильности и некоторых редакционных преимуществ,
поскольку редакторы могут вносить крупномасштабные изменения в контент,
не затрагивая среду публикации, только для того, чтобы «внести» все
изменения как один пакет, когда контент будет готов ( хотя это преимущество
постепенно находит свое применение во все более и более связанных
системах).
Фактические технические преимущества разделения включают возможность
публикации на нескольких серверах без необходимости установки CMS на
каждом (что снижает лицензионные сборы в случае коммерческих CMS), а
также возможность публикации в сильно распределенных средах
(множественные данные). центры на нескольких континентах, например).
Кроме того,

Среда доставки может работать на совершенно другом технологическом стеке,
чем среда управления, поскольку некоторые системы публикуют «инертные»
ресурсы, такие как простые файлы HTML или записи базы данных, которые
имеют мало ограничений среды.
Основным недостатком разделения является то, что опубликованный контент
отделен от репозитория, что усложняет «живые» функции, такие как
персонализация и пользовательский контент. Например, принимать
комментарии пользователей сложнее, когда эти комментарии необходимо
переносить «назад» с сервера доставки на сервер репозитория, а затем
сообщение в блоге, в котором они появляются, необходимо повторно
опубликовать (с отображением новых комментариев) «вперед». » на сервер
доставки.
Чтобы противостоять этому, разделенные CMS переходят к публикации
контента непосредственно в сопутствующем программном обеспечении,
работающем на серверах доставки, которое имеет определенный уровень
знаний об управляющей CMS и может включать функции доставки контента. В
результате получается CMS, разделенная пополам: функции управления
выполняются в одной среде, а функции доставки — в другой.
Разделенные системы, как правило, группируются в стеке технологий Java.
Некоторые системы ASP.NET существуют, но практически ни одна система
PHP не использует эту парадигму.
Мы обсудим различия между двумя моделями публикации вГлава 9.
Установленное и программное обеспечение как услуга (SaaS)

Все больше и больше ИТ-инфраструктуры перемещается в «облако», и CMS не
являются исключением. Раньше нормой была установка и настройка серверной
инфраструктуры, но сейчас поставщики все чаще предлагают хостинговые
решения или SaaS-решения. Нередко программное обеспечение арендуется у
поставщика и размещается в его среде.
Преимущество подразумевает использование CMS, которая размещается и
поддерживается поставщиком, который ее разработал. Приносит ли это
реальную пользу или нет, остается предметом споров. Для многих «хостинг»
или «SaaS» означает просто «чужую головную боль», и существует множество
других способов добиться этого за пределами самих поставщиков.
С дебатами об установленном и SaaS тесно связан вопрос о том, поддерживает
ли CMS несколько изолированных пользователей в одной и той же среде. Так
называемые «одноквартирные» и «многоквартирные» системы очень похожи
на жизнь в доме или в многоквартирном доме. Пользователи мультитенантной
системы существуют в одной и той же общей среде выполнения,
изолированной только посредством входа в систему. Они занимают
переполненную комнату, но кажется, что каждый там единственный.
Предполагаемым преимуществом здесь является подход «невмешательства» к
технологиям. Эти системы рекламируются как дающие вам мгновенный доступ
и позволяющие вам сосредоточиться на своем контенте, а не на технологии,
которая его использует. Компромисс — это ограничение ваших возможностей
настройки, поскольку вы делитесь системой с другими клиентами.
Мы обсудим эту дихотомию более подробно вГлава 3.
Установленное и программное обеспечение как услуга (SaaS) |2 7

Код ПротивСодержание
Реализация CMS почти всегда на каком-то уровне включает два типа
программного кода. Система будет иметь (1) настройки, разработанные в
собственном коде системы (например, PHP, Java или C#), и (2)
пользовательские шаблоны и связанные с ними HTML, CSS и JavaScript.
Этот код обычно управляется в системе управления исходным кодом, такой как
Git или Team Foundation Server. Обычно перед запуском он тестируется в
отдельной среде (тестовом или интеграционном сервере). Запуск нового кода
обычно является запланированным событием. В зависимости от вашей ИТ-
политики новый код может иметь утвержденные планы тестирования и
изменений, а также планы сбоев и отступлений на случай, если что-то пойдет
не так.
Когда код находится под контролем исходного кода, всегда есть «другое
место», где он живет. Установка CMS, в которой она выполняется и
представляет ценность, не является ее домом; он просто развернут там на
данный момент. Если эта копия когда-либо будет уничтожена по какой-либо
причине, ее можно будет повторно развернуть из системы контроля версий.
Контент, с другой стороны, разрабатывается редакторами и хранится в CMS. В
связанных системах он часто разрабатывается в производственной CMS и
просто не публикуется до тех пор, пока не будет готов к запуску. Он может
быть проверен в рамках формального или неформального рабочего процесса,
но часто не «проверяется» иным образом. Если у редактора есть достаточные
разрешения, можно внести изменения в контент, просмотреть его и
опубликовать в течение нескольких минут без какого-либо контроля.
Контент почти всегда будет меняться гораздо чаще, чем код. Организация
может публиковать и изменять контент несколько десятков раз в день, но
корректировать программный код веб-сайта только раз в несколько месяцев.
Когда это происходит, нужно исправить ошибку или фундаментально изменить
работу чего-либо на веб-сайте, а не просто изменить информацию,
предоставляемую посетителям.
Код и контент иногда путают из-за наследия статических веб-сайтов HTML.
Для организации, которая создала свой веб-сайт с использованием
статического HTML, файл HTML должен был быть изменен, чтобы измениться
одно слово. Таким образом, изменение кода и изменение контента — это одно
и то же.
Разделенное управление контентом также может стирать грань между кодом и
контентом. В изолированной системе измененный контент часто публикуется в
тестовой изолированной программной среде, где он проверяется на точность, а
затем публикуется в производственной среде. Существование совершенно
отдельной среды аналогично управлению кодом. Контент начинает
действовать как код.
В таких ситуациях иногда бывает сложно отделить тестовую среду для
контента от тестовой среды для кода. У вас есть две разные парадигмы
тестирования, каждая со своей собственной средой, каждая из которых вносит
изменения в производственную среду.

Это меняется с появлением CMS, особенно спаренной CMS. В рамках этой
парадигмы контент меняется без изменения кода. Набор слов в пресс-релизе
может быть полностью изменен, но шаблон, по которому он будет
отображаться, останется прежним.
Организациям, переходящим со статических веб-сайтов или изолированных
систем, иногда трудно приспособиться к идее «виртуальной»
тестовой/промежуточной среды — неопубликованный контент создается на
рабочем сервере и просто невидим, пока он ожидает публикации.
Их прошлые корреляции с кодом побуждают их относиться к контенту
одинаково и смешивать эти две концепции.
Код ПротивКонфигурация
Многие функции CMS могут быть реализованы посредством (1) разработчиков,
пишущих код (либо основной код, либо код шаблона), или (2) редакторов и
администраторов, работающих через интерфейс.
Разработчики имеют полную свободу, вплоть до пределов самой системы.
Обычно не существует функциональности, которая была бы недоступна из
кода, поскольку сам код является основной основой системы. Единственное
ограничение для разработчика — это то, насколько хорошо спроектирован API,
обеспечивающий доступ и манипуляции. Но даже при плохо реализованном
API разработчик имеет все возможности языка программирования,
позволяющие обойти недостатки.
Редакторы, с другой стороны, имеют доступ лишь к части того, что
разработчик может сделать из кода. Они ограничены функциональностью,
доступной из интерфейса, которая сильно различается в зависимости от
системы. Некоторые системы позволяют устанавливать незначительные
параметры конфигурации, в то время как другие имеют сложную архитектуру
модулей и подключаемых модулей, которые позволяют создавать новые
функциональные возможности из интерфейса работающей производственной
системы.
Почему бы системе не предоставить все функции интерфейса? Иногда это
происходит потому, что конкретный параметр или часть функциональности
изменяются слишком редко, чтобы оправдать усилия по созданию для него
интерфейса. В других случаях это происходит потому, что человек,
использующий его, скорее всего, будет разработчиком, который хотел бы
изменить его из кода, чтобы гарантировать, что он будет версионирован как
исходный код и развернут, как и другие изменения кода.
Однако наиболее распространенной причиной является то, что эта функция
слишком сложна для управления через интерфейс. Умение писать код
позволяет четко выражать чрезвычайно сложные концепции. Разработчики
привыкли абстрактно мыслить об информации.
Код и конфигурация |2 9
кодирования и кодирования его в коде.6 Некоторые функции слишком сложны,
чтобы можно было легко построить на их основе интерфейс управления.
Хотя создание функций на основе конфигурации звучит заманчиво, это может
стать проблемой для управления и обслуживания. Когда редакторы могут
внедрять новые модули и функциональные возможности в производственную
среду, это может затруднить разработку нового кода для разработчиков. В
настоящее время веб-сайт совместно разрабатывают две группы: одна через
код, другая через конфигурацию. Эти две группы подчиняются разным
парадигмам тестирования и развертывания, и они могут не сообщать о том, что
они делают. Результатом могут стать загадочные, а иногда и катастрофические
проблемы.
Уни-По сравнению с двунаправленной

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

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

(UGC). Некоторые системы предназначены для ограниченного
пользовательского контента, а другие построены вокруг него. Некоторые могут
6 Это не была преднамеренная попытка аллитерации — корень слова «кодифицировать» — «код».
7 Комментирование даже не было обычным явлением до «революции блогов», примерно в 2002 году или около того.

в первую очередь это будут платформы для управления пользовательским
контентом, а не для управления контентом, созданным редактором.
За последнее десятилетие все изменилось, и в наши дни такие инструменты
распространены и ожидаемы. Это означает, что старые CMS (из 90-х годов)
должны были поддерживать эту функциональность, тогда как в более новых
CMS она встроена.
Для обработки пользовательского контента требуются инструменты, отличные
от однонаправленной публикации. Если ваша CMS не предоставляет их, то их
необходимо разработать или обработать с помощью других сервисов
(например, Disqus или Facebook для комментирования).
Кроме того, пользовательский контент стирает грань между редакторами и
другими пользователями, которые могут предоставлять контент: если
посетители могут создавать блоги на вашем сайте и публиковать сообщения в
блогах, являются ли они редакторами? Что отличает их от «настоящих»
редакторов внутри вашей организации? Если весь ваш веб-сайт построен на
основе пользовательского контента, нужна ли вам CMS или вам действительно
нужна социальная сеть или инструмент для создания сообщества? А как насчет
программного обеспечения, которое обеспечивает и то, и другое?
Пользовательский контент создает дополнительные технические проблемы для
разделенных CMS, как мы обсуждали в предыдущем разделе. По сути, теперь
контент можно создавать в обоих направлениях, что затрудняет изолирование
таких понятий, как репозиторий. В некоторых случаях комментарии, подобные
пользовательскому контенту, фактически хранятся непосредственно в среде
доставки, а не в репозитории, поскольку они считаются «меньшим» контентом,
чем тот, который создается внутренними редакторами, и с меньшей
вероятностью требуют редакционного процесса или управления.
Есть несколько CMS, которые позиционируют себя в этой сфере и продвигают
многофункциональные инструменты сообщества. Другим системам, не
имеющим этих функций, приходится догонять их, либо добавляя их с помощью
расширений и дополнительного программного обеспечения, либо интегрируя с
другими сервисами.
Когда я впервые столкнулся с Drupal примерно в 2005 году, я

подумал: «Это вообще не система управления контентом. Это
система управления сообществом». Наличие инструментов
управления сообществом немного дезориентировало.
В своей статье в октябре 2004 г.«Создание лучшей CMS с
открытым исходным кодом», Джеффри Вин был почти
недоверчив, когда сказал следующее: «Пользователям
общедоступного веб-сайта никогда — никогда — не следует
предлагать способ входа в CMS».
Переход от односторонней к двусторонней публикации застал
многих из нас врасплох, и потребовалось некоторое время,
чтобы осознать, что это естественный прогресс. Теперь можно
ожидать, что контент будет поступать с любого направления, и
системы проектируются с учетом этой реальности.
Однонаправленная и двунаправленная публикация |3 1

Практичность против элегантности и проблема
технического долга
Это последнее сравнение касается не только CMS, но и применимо к
разработке программного обеспечения в целом. Тем не менее, это важно
понимать при обсуждении контекста разработки CMS с течением времени и
конкретно реализации вашей CMS.
При рассмотрении новой функциональности идет постоянная борьба между (1)
«просто сделать это» и (2) сделать шаг назад и рационально рассмотреть
лучший способ вписать эту функциональность в более широкую картину.
Первый быстрее и получает новые функции, но второй более устойчив с
течением времени.
Простое внедрение новых функций в программное обеспечение создает то, что
стало известно кактехнический долг. Это небольшие проблемы и
несовместимости, которые накапливаются со временем. Вы платите
«проценты» по этому долгу в виде обходных путей, хаков и дополнительной
работы, которую вам придется проделать в будущем, чтобы учесть
неправильный выбор, сделанный при реализации функций. В конце концов,
вам придется остановиться и «погасить» этот долг путем повторной реализации
функций, иначе процентные расходы раздавят вас.
Продолжая наше обсуждение пользовательского контента, начатое ранее,
рассмотрим необходимость добавления функции комментирования в
существующую CMS. Нетерпеливый разработчик может посмотреть на это и
подумать: «Ну, это легко. Я просто создам новую систему для обработки
комментариев с собственным хранилищем, вызовами API и т. д.».
Это практичное и быстрое решение. Разработчик может реализовать это во второй половине
дня.
Однако где-то в будущем, предположим, редакторы обеспокоятся
подстрекательскими комментариями и решат, что им нужна возможность
скрывать определенные комментарии. Ладно, говорит наш бесстрашный
разработчик, это можно добавить.
Позже редакторы захотят пойти еще дальше и получить возможность
редактировать комментарии. Это поднимает более серьезные архитектурные
проблемы разрешений и управления версиями. Наш разработчик с трудом
сглатывает и заявляет, что его также можно добавить в систему
комментирования.
Наконец, у редакторов начались пламенные войны в ветках комментариев, и
они решили, что хотят реализовать полноценный рабочий процесс и одобрение
комментариев.
Именно в этот момент наш разработчик понимает, что комментарии — это
тоже контент, и, возможно, их следовало реализовать таким образом. Это
потребовало бы немного больше работы и размышлений, но долгосрочная
устойчивость и стабильность функции были бы улучшены. Если рассматривать
комментарии как реальный контент, а не как отдельную концептуальную
систему, то в них будет встроено множество основных функций, о которых
просят редакторы.
Это всего лишь иллюстрация, и очевидно, что существуют ситуации, когда
отдельная система комментариев может быть уместна. Но более важным
является то, что иногда

быстрое исправление — не лучший способ что-то сделать, а разработка
программного обеспечения — это постоянная битва между умиротворением
пользователей, которые хотят чего-то прямо сейчас, и обеспечением того,
чтобы они оставались довольными в долгосрочной перспективе.
Вы можете увидеть эту дихотомию на разных платформах CMS. Некоторые из
них представляют собой смесь парадигм и архитектур программирования, в то
время как другие хорошо продуманы и централизованно спланированы для
гармоничной работы в долгосрочной перспективе. Первые развиваются быстро,
тогда как вторые медленнее, но более стабильны и их легче изучить,
поскольку, как правило, существуют основные принципы и философии с
меньшим количеством исключений и одноразовых обходных путей.
Хотя «анализ параличом» может привести к остановке разработки платформы,
более медленная и вдумчивая разработка, как правило, со временем полезнее
для платформы. Не все то золото, что блестит, и то, что вы получили функцию
быстро, не означает, что она была сделана правильно. Если это не так, то
лучшим сценарием будет признать это раньше, прежде чем вы слишком
глубоко вложитесь в это.
Практичность против элегантности и проблема технического долга |3 3
ГЛАВА3
Приобретение CMS
Прежде чем мы обсудим функции и углубимся в особенности архитектуры

CMS, давайте совершим небольшой экскурс в бизнес программного
обеспечения. Чтобы начать работать с CMS, вам необходимо ее освоить.
Ваш поиск обычно начинается с одной из трех отправных точек:
Программное обеспечение
Если вы начнете свой поиск с поиска программного обеспечения CMS,
поставщики, скорее всего, познакомят вас с одним из своих «партнеров»,
чтобы помочь в определении объема внедрения, или они могут предложить
для этого свою собственную группу профессиональных услуг (при
условии, что она у них есть).
Интегратор
Если вы начнете свой поиск с поиска интегратора CMS (разработчика или
фирмы, которая устанавливает и настраивает CMS), он обычно будет
специализироваться на одной или нескольких CMS и обязательно
попытается направить вас к этим системам. Они, очевидно, хотели бы
внедрить систему, с которой им будет комфортно и/или за которую они
будут получать наценку, скидку или откат от поставщика.1
Консультант по подбору
Если вы начнете свой поиск с помощью независимого консультанта по
выбору CMS, они помогут вам выбрать систему на основе ваших
требований и желаемых функций, предположительно свободную от
влияния или предвзятости. Недостатком являются дополнительные
расходы и, вероятно, дополнительное время, но, как участник многих
формальных процессов выбора CMS, я могу подтвердить, что деньги и
время потрачены не зря.
1 Или по другой причине, о которой никто не говорит: внедрение дорогого программного обеспечения
часто рассматривается коллегами по отрасли как знак значимости. Людям нравится, когда на
конференциях к ним относятся серьезно, а имена систем случаются чаще, чем кто-либо может себе
представить.
35
Эти три типа поиска должны выявить одного или нескольких поставщиков
CMS, каждый из которых представляет одну из следующих парадигм
приобретения:
Открытый источник
Вы скачиваете и устанавливаете.
Коммерческий
Вы лицензируете (покупаете) и устанавливаете.
Программное обеспечение как сервис(SaaS)
Вы «арендуете» и пользуетесь.
Построй свой собственный
Вы развиваетесь с нуля, внутри своей организации.
Любой из них предоставит вам работающую CMS, с которой можно начать
внедрение. Однако в каждом из этих, казалось бы, простых вариантов
скрывается бесчисленное множество вариаций, особенностей и парадигм.
Открыть ИсточникCMS
Вероятно, в CMS доступно больше вариантов с открытым исходным кодом,
чем в любом другом жанре программного обеспечения. Наиболее часто
используемые платформы в мире — такие системы, как Wordpress, Drupal и
Joomla! — имеют открытый исходный код. (Фактически, почти все системы
стека LAMP имеют открытый исходный код, что демонстрирует тесную связь
между этим стеком технологий и философией открытого исходного кода.)
Изучение тонкостей открытого исходного кода выходит за рамки этой книги. 2
но ключевым моментом является то, что CMS с открытым исходным кодом
обычно можно использовать бесплатно без уплаты лицензионного сбора. У
всех этих систем есть веб-сайт, на котором вы можете загрузить программное
обеспечение, а затем установить его в своей среде и использовать.
При этом помните, что стоимость лицензии не является суммой ваших
расходов. Вам все равно потребуется:
1. Разместите программное обеспечение.

2. Интегрируйте программное обеспечение.
Некоторые CMS с открытым исходным кодом очень легко разместить на

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

настоятельно рекомендуюСобор и Базар Эрик Рэймонд (О'Рейли).
36 | Глава 3: Приобретение CMS
Открыть Источник против. Коммерческий против. Собственный против. ЗакрытоИсточник
При обсуждении программного обеспечения с открытым
исходным кодом может быть сложно определить, что называть
программным обеспечением с закрытым исходным кодом.
Некоторые называют это «коммерческим», но другие
утверждают, что правильнее сказать «собственнический» или
«с закрытым исходным кодом».
Для целей этой главы мы пожертвуем невероятной точностью
ради простоты и просто будем использовать дескриптор
«коммерческого» для обозначения программного обеспечения,
которое не является бесплатным для использования. Права на
коммерческую CMS принадлежат коммерческой организации,
которая занимается продажей лицензий.
Кроме того, мы не собираемся спорить о различных вариантах
лицензирования открытого исходного кода. Существует
несколько способов лицензирования программного
обеспечения с открытым исходным кодом, наиболее
популярным из которых является GPL (GNU General Public
License). Обсуждение открытого исходного кода в этой книге
предполагает лицензию GPL.
Что касается простоты интеграции, программное обеспечение с открытым

исходным кодом также сильно различается. Некоторые проекты достаточно
зрелы, чтобы иметь подробную документацию и установщики начальной
загрузки, которые помогут вам быстро приступить к работе. Но эти функции
часто разрабатываются на поздних стадиях жизненного цикла программного
обеспечения с открытым исходным кодом, поэтому многие более молодые
системы в этих областях совершенно не справляются. Кроме того, в
программном обеспечении с открытым исходным кодом часто наблюдается
явная предвзятость разработчиков («написанное разработчиками для
разработчиков», как упоминалось вГлава 2), и общее ощущение, что, поскольку
за это никто не платит, пользователи могут просто во всем разобраться.
Учитывая отсутствие лицензионной платы, системы с открытым исходным
кодом довольно часто используются в небольших проектах, у которых нет
средств на оплату лицензии. Это означает, что применимость к гораздо более
крупным проектам может быть сомнительной. На каждый Drupal приходится
сотня других систем, которые никогда не требовали масштабирования больше,
чем небольшой или средний маркетинговый сайт или блог.
Повсеместное использование действительно дает огромные преимущества в
плане поддержки сообщества. Многие системы с открытым исходным кодом
имеют процветающие сообщества пользователей, которые готовы быстро и
точно ответить на вопросы. Однако это может быть компенсировано
отсутствием профессиональной поддержки (которая иногда оказывается
платной — см. следующий раздел), а также отсутствием способности или
желания сообщества решать более сложные вопросы.
И, как упоминалось ранее, CMS с открытым исходным кодом сильно зависят от
платформы. Системы LAMP почти всегда имеют открытый исходный код,
тогда как систем .NET и Java сравнительно меньше.
Бизнес Модели из Открыть ИсточникКомпании

За многими продуктами CMS с открытым исходным кодом стоят полноценные
компании, которые либо активно разрабатывают программное обеспечение
внутри себя (например, eZ и ее eZ Platform
CMS с открытым исходным кодом |3 7

CMS) или направлять и управлять развитием сообщества (например, Drupal
Association). Кроме того, во многих системах с открытым исходным кодом есть
коммерческие компании, скрывающиеся по краям сообщества и
предоставляющие платные услуги для этих систем (например, Acquia — это
компания, предоставляющая корпоративный хостинг Drupal, и которая была
основана Дрисом Байтартом, создателем самого Drupal). ).
Чтобы оплачивать счета, компании, разрабатывающие программное
обеспечение с открытым исходным кодом, используют одну или несколько из
следующих моделей:
Консалтинг и интеграция
Никто не знает CMS лучше, чем компания, которая ее создала, и
поставщики довольно часто интегрируют свое собственное программное
обеспечение от начала до конца или, по крайней мере, предоставляют
некоторые консультационные услуги более высокого уровня, с помощью
которых можно помочь клиентам в его интеграции. сами себя.
Фримиум
Базовое программное обеспечение бесплатное, но существует платная
опция, которая обеспечивает доступ к большему функционалу, большему
объему управляемого контента или опциям масштабирования, таким как
возможность балансировки нагрузки. Иногда бесплатный продукт вполне
работоспособен, а иногда это просто упрощенная пробная версия,
призванная побудить пользователей платить за полную версию продукта.3
Хостинг
Многие поставщики предлагают платформы «управляемого хостинга» для
разрабатываемых ими систем с открытым исходным кодом.
Предполагаемым преимуществом является среда хостинга, разработанная
специально для этой системы, и/или эксперты по системе, готовые помочь
в случае возникновения проблем с хостингом. Обратите внимание, что
реальная ценность здесь немного сомнительна, поскольку редко бывает
секретная информация, известная только поставщику, которая позволяет
ему адаптировать платформу хостинга для одной CMS вместо другой.
Любые доступные улучшения производительности или настройки
конфигурации могут быть легко реализованы опытным клиентом.
Ценность зачастую заключается просто в душевном спокойствии, что за
дело отвечает «эксперт».
Обучение и документация
Программному обеспечению с открытым исходным кодом часто не хватает
документации, а предвзятость разработчиков может привести к созданию
своеобразных систем с большим количеством API. По этим причинам
профессиональная подготовка может быть полезной. Многие поставщики
предлагают варианты платного обучения, как удаленного, так и очного.
Реже некоторые предлагают платный доступ к документации более
высокого качества.
3 Это поднимает вопрос о том, являются ли эти компании открытым исходным кодом или
коммерческими организациями. eZ распространяет eZ Platform, которая представляет собой среду
управления контентом с открытым исходным кодом. Она также продает eZ Studio, коммерческий
интерфейс и систему редакционного управления — надстройку, которая улучшает работу eZ
Platform. Делает ли это eZ коммерческой компанией или компанией с открытым исходным кодом?

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

большинство организаций просто сохраняют конфиденциальность своего исходного кода, тихо
нарушая лицензию и философию открытого исходного кода. Поэтому этот вариант обычно
привлекателен только для компаний со строгой политикой, регулирующей выпуск изменений с
открытым исходным кодом.
Коммерческие CMS |3 9
они должны продолжать платить клиентам, а также получать доходы от
лицензионных сборов для финансирования профессионального развития.
Как и любое обобщение, это не всегда верно, поскольку некоторые системы с
открытым исходным кодом достаточно зрелы и широко используются, чтобы
конкурировать с любыми коммерческими предложениями. И наоборот,
некоторые коммерческие поставщики плохо справляются с контролем качества
и продают продукты, полные ошибок. Но, как правило, оно имеет место.
Кроме того, за последние пять лет произошло четкое разделение между
открытым исходным кодом и коммерческими CMS по признаку маркетинговых
функций. В то время как сообщество разработчиков открытого исходного кода
одержимо решением проблем управления контентом, коммерческий мир
перешел к контент-маркетингу, который представляет собой инструменты и
функции, которые помогают улучшить ваш контент после его публикации.
Говорят, что CMS с открытым исходным кодом созданы для директора по
информационным технологиям (директора по информационным технологиям),
тогда как коммерческие CMS созданы для директора по маркетингу (директора
по маркетингу). Это во многом справедливо и в отношении того, как системы
продаются: коммерческий сектор концентрирует свои продажи исключительно
на маркетинговых отделах своих клиентов, в то время как поставщики ПО с
открытым исходным кодом больше заинтересованы в попытках завоевать
сердца и умы ИТ-персонала.
Как и в случае с предложениями с открытым исходным кодом, различия
платформ очевидны. Очень немногие системы LAMP являются
коммерческими, в то время как многие системы .NET и Java имеют свою цену.
Наконец, помните, что цифры, обсуждаемые в этом разделе, относятся только к
стоимости лицензий. Покупка коммерческой CMS не освобождает вас от затрат
на ее внедрение — вам все равно придется найти (и заплатить) кого-то, кто
установит, настроит и шаблонизирует вашу систему. В некоторых случаях
коммерческие поставщики предоставляют такую возможность (так называемые
«профессиональные услуги»), а в других случаях у них есть «партнерская сеть»
интеграционных фирм, которые являются экспертами в своих системах и
готовы интегрироваться за платеж.
Модели лицензирования
Коммерческие системы редко имеют единую и простую цену. У продавцов
обычно есть запутанная система формул и таблиц для определения
окончательной цены с общей целью заставить состоятельных клиентов платить
больше, не теряя при этом меньшие продажи для клиентов с более скромными
бюджетами.
На момент написания этой статьи «средний рынок» грубо определяется как
системы с прейскурантной ценой (заявленной «официальной» ценой) от 20 000
до 80 000 долларов США, и почти все оценивается в соответствии с этой ценой
— поставщики классифицируются как выше или выше ниже среднего рынка.
Диапазон коммерческих цен огромен.Окунь5 продается за 79 долларов, в то
время как Adobe CQ нельзя купить менее чем за 250 000 долларов, а стоимость
крупных установок легко превысит семизначную сумму.
Вот наиболее распространенные способы определения цены:
Редактор/пользователь
Цена системы определяется количеством пользователей, редактирующих
данные, либо за рабочее место, либо одновременно. Реже цена системы
определяется количеством зарегистрированных общедоступных
пользователей, но обычно это применимо только к системам сообщества
или интрасети/экстранети, где ожидается, что посетители будут
зарегистрированы.
По серверу
Цена системы определяется количеством серверов, на которых она
работает (или, реже, количеством ядер ЦП). Это довольно
распространенная ситуация, поскольку для более крупных установок
потребуется больше серверов, что приведет к более высокой цене. В
разделенных системах, где среда доставки отделена от среды репозитория,
может возникнуть путаница: платите ли вы за серверы репозитория или за
серверы доставки? Или оба?
По сайту
Цена системы зависит от количества различных веб-сайтов, работающих на
ней. Это может быть размыто неопределенностью того, что представляет
собой «веб-сайт». Если мы переместим наш контент с
«microsite.domain.com» на «domain.com/microsite», останется ли у нас тот
же веб-сайт и лицензионная плата? А как насчет веб-сайтов с разными
доменными именами, которые обслуживают один и тот же контент
(например, фирменные сайты по интересам)? А как насчет альтернативных
доменов для разных языков («en.domain.com» для английского и
«de.domain.com» для немецкого)?
По характеристикам
Цена системы указана с учетом дополнительных пакетов, устанавливаемых
в дополнение к основному. Почти каждый коммерческий поставщик имеет
множество функций или пакетов, которые можно добавить к базовой
системе, чтобы повысить ценность и цену. Они варьируются от подсистем
электронной коммерции до инструментов маркетинга. Обратите внимание,
что каждая из этих функций также может лицензироваться пользователем,
сервером или сайтом, что также делает их цены переменными.
По объему контента
Цена системы зависит от количества контента, находящегося под
управлением. Это менее распространено, чем другие модели, поскольку
количество управляемых объектов контента сильно зависит от реализации.
Например, следует ли вам управлять комментариями в блоге? Или вы
можете переместить их в сопутствующую базу данных (или внешний
сервис, например Disqus) и уменьшить объем контента на 80 % и более?
5 На самом деле рекламируетсякак «Действительно маленькая CMS».
Стоимость большинства систем оценивается по нескольким осям, например, по
сочетанию редакторов, серверов и сайтов. Окончательную цену зачастую
невозможно определить без тщательной консультации с отделом продаж
поставщика.
Продавцы пытаются установить цену с учетом предоставленной ценности и
платежеспособности покупателя. Перечисленные здесь методы, по сути,
представляют собой прокси-модели того, что на самом деле может предпочесть
продавец: иметь внутреннюю информацию о том, сколько клиент может
заплатить, и устанавливать цену на свой продукт по этой цифре. Поскольку ни
один клиент никогда не позволит этого, поставщики используют такие
показатели, как количество редакторов или сайтов, чтобы дать
приблизительную оценку.
Когда покупать CMS

Реалии бизнеса диктуют, что конец квартала обычно является
очень подходящим временем для переговоров о продаже
лицензии. В это время поставщики должны сообщать о своих
квартальных показателях Уолл-стрит или совету директоров, и
поэтому у них есть большой стимул делать скидки, чтобы
увеличить свои доходы.
Учитывая, что предельные издержки производства
программного обеспечения по сути статичны (создание 100 000
копий обходится не дороже, чем создание 1), единственным
сдерживающим фактором, который у них есть для
дисконтирования, является то, что, делая это, они увеличивают
ожидания среди будущих клиентов, что прейскурантная цена
подлежит обсуждению.
Программное обеспечениеПодписка
Одна вещь, на которую вы всегда можете рассчитывать при обращении к
коммерческим поставщикам, — это необходимость платить за подписку на
программное обеспечение, которая представляет собой постоянную ежегодную
плату, зависящую от покупной цены. Это вовсе не уникально для CMS —
почти все корпоративное программное обеспечение стоит одинаково.
Подписка обычно составляет процент от покупной цены — обычно от 18% до
22%. Первый год часто включается в покупку, но каждый последующий год
клиенту будет выставляться счет в годовщину покупки.
В среднем 20% в год, это быстро складывается. Простая математика подскажет
вам, что вы будете эффективно «перекупать» свою CMS каждые 4–6 лет.
Необходимость платить этот сбор зависит от поставщика. В большинстве
случаев вы можете просто прекратить оплату подписки в любое время и
продолжить использовать продукт, но вы потеряете все дополнительные
преимущества, которые дает плата за подписку. У большинства поставщиков
эти преимущества представляют собой комбинацию следующих факторов:
• Поддержка по требованию
• Обновления и исправления по мере их выпуска
• Бесплатные лицензии для серверов разработки или тестирования.

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

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

Другая реальность бизнеса программного обеспечения
заключается в том, что компании часто находятся в процессе
приобретения другой компании или сами становятся
поглощенными. Постоянный/регулярный доход абсолютно
важен для их оценки — цена, которую они собираются платить
или будут платить.
То, какую часть этого вида дохода имеет компания, является
одним из первыхвопросы, которые ему задаст
потенциальный поклонник. Единовременная выплата в
размере 10 долларов может оказаться не столь ценной, как
постоянная выплата в размере 2 долларов каждый год.
По этим причинам компании, занимающиеся коммерческим
программным обеспечением, часто пытаются направить
клиентов к определенному регулярному потоку дохода.
Продажи одной лицензии без повторяющихся компонентов —
это не то, что им нужно.
Перспектива: ЭТО Является Только ОдинАкционер
Кэти Макнайт
Контент и его воспринимаемая ценность радикально
изменились за последние несколько лет: простой онлайн-
контент теперь рассматривается как ценный цифровой
актив, имеющий множество применений и целей.
Соответственно, развивались и технологии, связанные с
контентом: каждый год на рынок выводятся новые решения
и их подмножества. Итак, прежде чем приступить к
решению, какой тип CMS — с открытым исходным кодом
(OSS), коммерческая, программное обеспечение как…
Сервис (SaaS) или отечественный — чтобы приобрести, сначала нужно
ответить на вопрос: «Является ли новая CMS правильным решением решаемых
бизнес-задач?»
Во многих организациях решение о том, покупать ли CMS (или любую другую
корпоративную технологию) и какую именно, часто откладывается на
усмотрение технологической группы — в конце концов, именно они лучше
всего понимают системы и технологический ландшафт компании. Верно?
Возможно. Но это верный способ найти технологию, отвечающую
потребностям ИТ-отдела, а не организации. ИТ-специалисты должны быть
вовлечены, но только как одна из многих заинтересованных сторон. Если
оставить их в покое только им, их близорукий взгляд обычно приводит к тому,
что потребности конечных пользователей и бизнеса — текущие и будущие —
не удовлетворяются (или даже не учитываются), что в конечном итоге
оставляет проблему бизнеса нерешенной.
Безусловно, внимание необходимо уделить техническим соображениям (хост
или локальная среда, совместимость с задействованными существующими
системами, собственным набором навыков), а также связанным с ними затратам
на технологию и внедрение (партнер/команда по внедрению,
лицензирование/подписка, обслуживание, и общая совокупная стоимость
владения). Но не менее важным, если не более важным, является выявление и
понимание текущих и обозримых будущих потребностей владельцев контента
и заинтересованных сторон в управлении контентом.
Чтобы гарантировать, что приобретенная технология отвечает потребностям
организации, представители затронутых заинтересованных сторон должны
быть вовлечены в процесс с самого начала — от подтверждения необходимости
CMS до определения требований, на основании которых CMS будет быть
выбранным. Сосредоточение внимания на потребностях бизнеса (планируемые
бизнес-цели и задачи каналов, поддерживаемых CMS), а не на функциях,
поможет определить не только какой тип CMS (OSS, SaaS, коммерческая или
отечественная разработка) является лучшим подходом, но и какое решение
необходимо предложить, чтобы гарантировать, что контентом организации
можно успешно управлять по мере того, как она и сама организация
развиваются и взрослеют.
Если ответ «да» на необходимость CMS, тогда проект выбора CMS может
начаться всерьез и должен начинаться с тщательного (не ИТ-
ориентированного) сбора требований.

Кэти Макнайт, вице-президент по консалтингу и операциям и партнер-
основатель компании
Digital Clarity Group помогает клиентам осуществлять цифровую
трансформацию посредством стратегического консультирования и
консультирования, включая выбор технологий.
Программное обеспечение как сервис

Программное обеспечение как услуга (SaaS; произносится «дерзость») раньше
было довольно ясным и простым предложением: вместо того, чтобы покупать и
устанавливать CMS, вы просто платили ежемесячную плату и запускали свой
веб-сайт в более крупной системе, управляемой продавец. Вы стали одним из
многих клиентов, использующих свои веб-сайты в этой же системе.
Это известно как «многопользовательское» программное обеспечение. В то
время как приобретенное и установленное программное обеспечение является
«единственным арендатором» — вы являетесь единственным жильцом, как в
доме на одну семью, который вы построили самостоятельно, — многоарендное
программное обеспечение похоже на многоквартирный дом, в котором живет
много людей.
Предполагаемые преимущества — быстрое время запуска и отсутствие
проблем с хостингом. Действительно, система уже работает и просто ждет вас,
а поскольку она работает на серверах поставщика, вам не нужно беспокоиться
ни о каких головных болях, связанных с управлением инфраструктурой. 6 SaaS
называлось «облачным» до того, как этот термин стал общепринятым.
Еще одно заявленное преимущество — всегда быть в курсе последних версий.
Поскольку поставщик управляет средой хостинга, когда он выпускает новую
версию, клиент получает ее сразу. Действительно, «выпуск новой версии»
является синонимом обновления своих клиентов, поскольку именно это и
должно произойти, чтобы считаться «выпуском».
Компании, занимающиеся CMS, одними из первых вошли в облачную
парадигму, и когда примерно в 2000 году на сцену вышли такие поставщики,
как Clickability и CrownPeak, эта модель была новой и оригинальной и давала
явные преимущества клиентам, которые не хотели устанавливать программное
обеспечение и управлять им самостоятельно. За прошедшие годы рынок
изменился, и разница между настоящим мультиарендным SaaS и всем
остальным стала очень размытой.
Сегодня «приобретение и установка» (часто называемая «локальной» или
«локальной» по сравнению с SaaS) — это всего лишь один из способов
получить программное обеспечение с открытым исходным кодом или
коммерческое (не SaaS) программное обеспечение. Если вам нужен любой из
этих вариантов, но вы не хотите размещать себя самостоятельно, существует
большая экосистема поставщиков, готовых установить и разместить что-либо
для вас. По сути, многие поставщики станут поставщиками SaaS, если вы этого
захотите.
6 За исключением моделей «отдельного SaaS». В этих архитектурах (которые не являются
распространенными) часть управления CMS принадлежит и размещается поставщиком, но она
публикует контент удаленно в среду доставки, принадлежащую клиенту, через FTP, rsync, веб-
службы или другие методы.
Программное обеспечение как услуга | 45

Функция «мгновенного включения» SaaS еще больше вытеснилась с
появлением виртуализации серверов и вычислительных сетей, таких как
Amazon EC2 и Microsoft Azure. Теперь вы можете установить практически
любую CMS менее чем за час. Эти системы не являются многоарендными, но
предлагают те же преимущества: минимальное время развертывания и
сторонний хостинг.
Возникает вопрос: что такое SaaS? Означает ли SaaS просто то, что поставщик
может немедленно предоставить вам экземпляр, а также предоставить среду
хостинга? Если да, то практически любую CMS можно приобрести и управлять
ею таким образом, чтобы она соответствовала этим критериям.
Или SaaS относится только к настоящим мультиарендным системам, которые
мы обсуждали ранее? Если это так, то эти системы становятся менее
распространенными на верхних границах рынка (с точки зрения цены,
возможностей и сложности интеграции) и более распространенными на
нижних границах. Такие поставщики, как WordPress.com, Drupal Gardens и
Squarespace, предлагают «автономные» мультиарендные CMS, где вы можете
получить полностью управляемую контентом платформу за считанные минуты,
используя только кредитную карту и без какого-либо человеческого
взаимодействия. Если вы можете жить в рамках функциональных ограничений
и не нуждаетесь в значительной настройке, эти системы могут оказаться
именно тем, что вам нужно.
Однако на уровне предприятия, где клиентам требуется значительная
настройка, поставщики SaaS CMS испытывают трудности. Некоторые из них
все еще существуют, но их ценностное предложение резко сократилось.
Многие поставщики корпоративных SaaS предлагают более низкую
ежемесячную плату, сравнивая ее с шестизначными и семизначными затратами
на лицензирование приобретенных систем. Традиционные коммерческие
поставщики в ответ предложили «арендовать» лицензии, при которых клиенты
платят за лицензию ежемесячную плату и теряют ее, когда перестают платить.
(Это также полезно для клиентов, которым может потребоваться подключить
дополнительные сайты или серверы на ограниченное время в связи с
временной нагрузкой.)
ЕслиЕсли вы рассматриваете мультитенантное SaaS, становятся важными несколько вопросов:
• Подходит ли это для вашей отрасли?Системы SaaS, как правило,

группируются по вертикали, в которой они обслуживаются. Например,
OmniUpdate традиционно обслуживает высшее образование, а HubSpot
специализируется на небольших, насыщенных маркетингом веб-сайтах.
Это позволяет этим поставщикам разрабатывать функции, общие для этих
отраслей, которые будут использоваться несколькими арендаторами их
систем.
• Насколько вы контролируете систему?В какой степени вы можете
интегрироваться с другими системами или внедрить собственную бизнес-
логику? Поскольку эти системы являются многоарендными, поставщики с
подозрением относятся к значительной настройке, чтобы не
дестабилизировать более крупную систему для других клиентов.
Некоторые поставщики предлагают специальную «песочницу», в которой у
вас больше контроля, но это поднимает вопрос о том, насколько ваше
положение теперь лучше, чем если бы вы установили CMS самостоятельно.

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

Как и любое другое программное обеспечение, CMS может быть создана
внутри вашей организации вашей собственной командой разработчиков. В
некотором смысле CMS напоминает любое другое приложение, управляемое
данными, и довольно быстро создать простую CMS несложно.
Для этого есть несколько распространенных оправданий, в том числе:
• Собственная CMS не требует лицензионной платы (очевидно, это

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

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

ally приходится перестраивать большие части основных функций CMS,
которые другие системы уже давно решили.
Внешне CMS выглядит как простое упражнение по редактированию и
публикации контента. Но стоит углубиться в проект, и редакторы начинают
запрашивать такие функции, как управление версиями, несколько языков,
рабочий процесс, управление несколькими сайтами и т. д. Разработка этих
функций может оказаться обманчиво сложной — тем более, когда их
приходится обратно портировать в проект. работающая система.
Разработка CMS со временем имеет тенденцию «хоккейной клюшки». Все
начинается очень быстро, и команды разработчиков заранее добиваются
огромных успехов, часто получая простое и работоспособное доказательство
концепции в течение нескольких недель или даже дней. Простые операции
CRUD (CReate, Update, Delete) реализуются очень быстро, особенно в
современных средах разработки.
Однако другие функции, такие как агрегирование контента, редакционное
удобство использования и особенно продвинутые маркетинговые функции,
приведут к тому, что время разработки резко увеличится, а прогресс упадет до
черепашьих темпов. Неудивительно, что вы потратите столько же времени на
реализацию незначительной маркетинговой функции, сколько на создание
всего интерфейса редактирования контента.
Несколько лет назад, создавая CMS с нуля вместе со своим

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

скорее логический и поведенческий, чем технический характер. Поставщики,
работающие в этой сфере, имеют многолетний опыт работы с редакторами и их
работы с контентом. Часто приходится платить «вступительный взнос» за
неправильную реализацию функции два или три раза, прежде чем, наконец, она
будет сделана правильно. Если вы создаете что-то с нуля, вам часто придется
платить эту плату каждый раз, когда вы расширяете систему.
За годы работы разработчики существующих CMS узнали, как думают
редакторы и что они хотят делать. Это очень важно, потому что знание того,
как выполнить что-то технически, часто не является настоящей проблемой.
Скорее, проблема в том, почему редактор хочет это сделать. Основные
причины этого могут влиять на решения в области развития, и это покажет
только опыт.
Кроме того, внутренние усилия по CMS часто возглавляются разработчиками, а
разработчики склонны рассматривать контент как данные, а не как бизнес-
актив. Для разработчика страница контента — это просто запись в базе данных,
как и любая другая, а не маркетинговый актив, предназначенный для
получения прибыли.

нуэ. Таким образом, функции маркетинга, оптимизации и улучшения часто
отходят на второй план по сравнению с функциями, ориентированными на
разработчиков, такими как управление данными.
В конце концов, разработка самой CMS начинает занимать больше времени,
чем решение основных проблем организации с контентом, для решения
которых изначально была необходима CMS. Кроме того, организация осознает,
что потратила гораздо больше времени на разработку CMS, чем когда-либо
потратила бы на то, чтобы стать экспертом в существующей CMS.
Полученное программное обеспечение может быть своеобразным и
нестабильным. Это также неизвестно за пределами организации, что приводит
к невозможности найти внешних подрядчиков и создает значительную
потребность в обучении новых сотрудников.
Наконец, система «заблокирована», то есть она была разработана для
удовлетворения заявленных требований и не более того. Хотя это звучит как
разумная практика разработки, некоторые дополнительные функции, помимо
тех, которые нужны редакторам немедленно, часто полезны для экспериментов
и понимания масштабов возможных возможностей.
Обычно большинство организаций пересекают «линию сожаления», когда им
хочется перемотать назад и выбрать готовый вариант. Нечасто можно увидеть
положительный результат от собственных усилий в долгосрочной перспективе.
Однако есть ситуации, когда это может быть правильным выбором:
• Когда модель контента — подробнее об этом см.Глава 6— очень

специфичен для организации. (Если вы публикуете только видеоролики с
кошками, создание платформы управления может оказаться несложным.)
• Когда потребности управления очень просты, а планы будущего развития
абсолютно заведомо ограничены.
• Когда CMS создается с использованием существующих платформ, чтобы
избежать как можно большего количества переделок (например, Symfony
для PHP, Django для Python, Entity Framework и MVC для ASP.NET).
Если ваша организация настаивает на использовании собственной CMS, не

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

При рассмотрении вопроса о приобретении CMS сочетание переменных делает
ваши возможности практически безграничными. Следующие вопросы могут
помочь вам взглянуть на ситуацию со стороны:
Вопросы, которые стоит задать | 49
• Где будет находиться финальная версия CMS? Мы сами размещаем его или
поручим его разместить кому-то другому?
• Если мы размещаем его самостоятельно, есть ли у нашего ИТ-отдела
ограничения платформы, которые мы должны соблюдать?
• Какова наша способность взимать лицензионный сбор? Какую часть
бюджета проекта мы можем выделить на это? Нужно ли нам рассмотреть
более низкую комиссию, выплачиваемую постепенно, а не всю сразу?
• Запланировали ли мы постоянные расходы на подписку в течение нескольких лет после
запуска?
• Собираемся ли мы интегрировать CMS самостоятельно или нам нужно
найти для этого фирму-партнера?
• Есть ли у нас навыки и возможности для создания CMS собственными
силами? Можем ли мы управлять обслуживанием и обновлением функций
вместе с другой нашей рабочей нагрузкой?
Наконец, важно отметить, что ни один из этих вопросов, возможно, не является

самым важным из всех: будет ли рассматриваемая система отвечать
функциональным потребностям нашей организации?
Не инвестируйте в систему только потому, что метод приобретения кажется
простым. Система с открытым исходным кодом, которая бесплатна, но не
предлагает маркетологам нужные им инструменты, не является хорошей
ценностью: вы сэкономите на лицензионном сборе, но вложите деньги в
реализацию, которая не даст желаемого результата. Точно так же
коммерческий поставщик, предлагающий хорошие инструменты, которые вы
никогда не будете использовать, просто помогает вам выбрасывать деньги на
ветер.
Способ приобретения CMS — это всего лишь один аспект гораздо более
широкого вопроса соответствия требованиям платформы. Эту тему мы
обсудим вГлава 5.
Процесс выбора CMS и неизвестные неизвестные
Выбор подходящей CMS для вашего конкретного набора задач может быть
очень сложным. Принятие правильного решения имеет решающее значение, и
это особенно проблематично, потому что вы часто «не знаете того, чего не
знаете».
Я процитирую бывшего министра обороны, говорящего о поисках спрятанного
оружия в Ираке еще в 2002 году:
Есть известные известные; есть вещи, которые мы знаем, что мы знаем. Мы
также знаем, что есть известные неизвестные; то есть мы знаем, что есть
некоторые вещи, которых мы не знаем. Но есть и неизвестные неизвестные, те,
которых мы не знаем, которых мы не знаем.
—Дональд Рамсфельд
Каким бы глупым это ни казалось, Рамсфелд делает критический вывод: если
вы не понимаете всю широту возможных сценариев, могут остаться вопросы
без ответа, которые вы даже не знаете, что задавать. Трудно выбрать
правильный вариант, если вы даже не знаете, что набор вариантов существует.
Например, я не знаю химического обозначения бора навскидку. Моя маленькая
дочь тоже. Ключевое отличие: я знаю, что эта вещь существует, а она нет. Если
мне нужен ответ, я знаю, что нужно его искать, а она этого не делает. Для меня
символ бора — известное неизвестное; для нее это неизвестное неизвестное.
По этой причине, как правило, лучше всего выделить процесс выбора CMS в
отдельный проект, управляемый кем-то, кто знает, какие вопросы задавать.
Есть консультанты, которые специализируются именно на таких решениях.
Крупные технологические аналитические фирмы, такие как Forrester и Gartner,
предоставляют общий анализ и помощь в этой области, а небольшие фирмы,
специализирующиеся на CMS, такие как Real Story Group и Digital Clarity
Group, проводят консультации по процессу выбора CMS как большой сегмент
своего бизнеса.
Вопросы, которые стоит задать | 51
ГЛАВА4
The Содержание
УправлениеКоманда
С момента создания, запуска и дальнейшего использования проект управления

контентом может повлиять на многих людей в вашей организации, каждый из
которых имеет разные роли и обязанности.
Хотя всесторонний взгляд на веб-операции и управление выходит за рамки
этой книги,1 будет полезно обсудить эти роли, прежде чем углубляться в
функции CMS, чтобы мы могли иметь некоторую ясность относительно того,
на каких именно людей может повлиять тот или иной аспект CMS.
В первую очередь членов команды управления контентом можно разделить на:
• Редакторы
• Планировщики сайтов
• Разработчики
• Администраторы
• Заинтересованные стороны
Обратите внимание, что эти ярлыки представляют собой роли, а не людей. Возможно, вам
будет неприятно взглянуть на этот список.
— вы можете подумать, что ваш проект в чем-то несовершенен, потому что
вокруг вас не слоняются все эти люди. Однако следует понимать, что границы
между ролями не являются абсолютными, и редко можно увидеть проект, в
котором каждая описанная здесь роль была укомплектована отдельным
человеком.
1Для получения дополнительной информации по этой теме я рекомендую книгу Лизы с метким названием
«Управление хаосом: цифровое управление посредством дизайна».Уэлчман (Розенфельд Медиа).
53
Члены команды обычно выполняют несколько ролей, и в каждом разделе будут
отмечены часто пересекающиеся роли. А пока просто знайте, что для очень
небольшого проекта вся команда может состоять из одного разработчика и
одного редактора (а проект-хобби разработчика может представлять собой
шоу, полностью состоящее из одного человека).
Тем не менее, команда управления контентом обычно состоит из комбинации
следующих лиц.
Редакторы
Редакторы несут ответственность за создание, редактирование и управление
контентом внутри CMS. В этой книге мы будем много говорить о редакторах,
поскольку именно они будут наиболее тесно взаимодействовать с CMS после
запуска.
Редакторы имеют тенденцию объединяться в одну группу, но роль «редактора»
— это грубое обобщение: не все редакторы созданы равными, и у них могут
быть самые разные возможности.
То, что характеризует «нормального» или «основного» редактора, зависит от
проекта. Поэтому было бы полезно обсудить, как редакторы могут быть
ограничены в своих возможностях по уточнению своих подролей:
По разделу/филиалу/локации
Редакторы могут иметь возможность редактировать только определенную
часть контента на веб-сайте, будь то раздел или ветвь дерева контента (мы
поговорим о деревьях в разделеГлава 7), или какой-либо другой метод
локализации. Они могут иметь полный контроль над контентом в этой
области (например, раздел прессы или отдел английского языка), но не
иметь контроля над контентом в других областях.
По типу контента
Редакторы могут иметь возможность редактировать только определенные
типы контента (подробнее о типах контента мы поговорим в разделеГлава
6). Они могут управлять профилями сотрудников, которые появляются на
сайтах нескольких отделов, или управлять новостными статьями компании
независимо от их местоположения. Фактически, некоторым редакторам
может быть лучше определить, какие типы контента им не разрешено
создавать — например, некоторым редакторам может быть запрещено
создавать расширенный контент, такой как агрегаты или карусели
изображений.
Редактируя интерфейс
Редакторы могут быть ограничены интерфейсом, который им разрешено
использовать. В более крупных проектах нередко некоторые редакторы
направляются через специализированные, специально созданные
интерфейсы, предназначенные для того, чтобы позволить им управлять
только тем контентом, который находится под их контролем. Например,
если администратор вашей компании отвечает за обновление обеденного
меню в интранете и ничего больше, то ему не нужно понимание более
широкого интерфейса CMS и всех тонкостей, которые с ним связаны.
54 | Глава 4: Команда управления контентом

это. Вместо этого, возможно, было бы целесообразно создать для этого
человека специальный интерфейс редактирования, позволяющий управлять
обеденным меню и ничем больше.
В отличие от этих ограничений существует так называемый «мощный
редактор», который может выполнять все операции с контентом на веб-сайте.
Иногда этот человек выполняет несколько обязанностей администратора сайта,
тренера, эксперта по предметам и всестороннего защитника CMS внутри
организации.
Распространены несколько других конкретных редакционных ролей:
Утверждающие
Эта роль отвечает за проверку отправленного контента, обеспечение его
достоверности, точности и приемлемого качества, а также за последующую
публикацию этого контента. То есть утверждающие выполняют шаги в
одном или нескольких рабочих процессах. Многие редакторы также
являются утверждающими лицами и отвечают за проверку контента,
представленного более младшими редакторами. Эти редакторы также
могут иметь право утверждать свой собственный контент. Некоторые
утверждающие могут иметь возможность редактировать отправленный
контент перед публикацией (например, главный редактор), в то время как
другие утверждающие могут иметь возможность только утверждать или
отклонять (например, сотрудники юридического отдела или отдела
соответствия). Этой роли может потребоваться только понимание функций
утверждения контента CMS.
Маркетологи
Эта роль отвечает за анализ контента на предмет маркетингового
воздействия и управление маркетинговой ценностью всего веб-сайта. Это
требует понимания маркетинговых и аналитических особенностей CMS.
Для некоторых сайтов это доминирующая роль, поскольку новый контент
создается не так часто, как существующий контент необходимо
оптимизировать, продвигать и анализировать.
Пользовательский контент/менеджеры сообщества
Эта роль отвечает за проверку уместности контента, отправленного
пользователями (пользовательский контент или UGC), такого как
информация профиля пользователя и комментарии в блогах. Эти
менеджеры аналогичны утверждающим, но они контролируют только
пользовательский контент, а не основной редакционный контент (в
некоторых случаях это может быть большая часть контента на сайте).
Кроме того, учитывая, что объем отправляемого пользовательского
контента часто высок, обычно им управляют после публикации —
неуместный контент просматривается и удаляется после публикации (или
после получения жалобы), а не задерживается с момента публикации до
проверки. Этой роли необходимо будет понимать CMS только в той
степени, которая позволит им модерировать пользовательский контент. В
некоторых случаях CMS предоставляет для этого отдельные инструменты,
а в других это обрабатывается как обычный контент.
Переводчики
Эта роль отвечает за перевод контента с одного языка на другой.
Переводчикам необходимо понимать редакционные функции CMS только в
той степени, в которой это необходимо для добавления переводов
конкретных объектов контента (по каждому).
Редакторы | 55
случается даже только с конкретными атрибутами контента, в случае, если
объекты контента переведены лишь частично). Подробнее о вопросах
локализации мы поговорим вГлава 10.
Не все роли в этом списке будут заполнены. Сайтам без пользовательского
контента не потребуется роль для управления им. Организации, управляющие
документацией по продукту или содержимым библиотеки, могут не заниматься
маркетингом/оптимизацией. Редакция из одного человека не нуждается в
утверждающих. Контент, представленный на одном языке, не потребует
переводчиков.
Некоторые роли также могут быть заполнены извне. Менеджеры
пользовательского контента/сообщества могут не работать в организации. На
сайтах сообществ принято полагаться на самоконтроль самого сообщества,
предоставляя конкретным участникам возможность модерировать контент. В
таких ситуациях пользователи сайта будут выполнять квази-редакционную
роль, обычно обеспечиваемую разрешениями или, возможно, полностью
отдельной пользователем и системой управления.
Переводом контента часто занимаются сторонние организации. В этих случаях
переводчик будет работать удаленно и может вообще не работать с CMS,
вместо этого перемещая контент внутрь и наружу с помощью рабочего
процесса и формата обмена, специфичного для перевода, например XLIFF.2
Планировщики сайтов
Планировщики сайта несут ответственность за разработку веб-сайта, которым
будет управлять CMS. Большая часть их участия будет осуществляться до
запуска, а дальнейшее участие будет спорадическим по мере развития и
изменений сайта с течением времени.
Существует несколько подролей:
Контент-стратеги
Эта роль отвечает за разработку контента как целостно, так и тактически. В
качестве побочного продукта процесса планирования контента
специалисты по контент-стратегии определяют типы контента и
взаимодействия, которые должен поддерживать веб-сайт. Эта роль
потребует знаний о том, как CMS моделирует и агрегирует контент, чтобы
понимать любые ограничения дизайна. Дополнительные знания
особенностей маркетинга потребуются, если специалист по контент-
стратегии отвечает за оптимизацию маркетинговой ценности сайта перед
его запуском.
Дизайнеры пользовательского опыта (UX) и информационные архитекторы
Эти роли отвечают за организацию контента и проектирование
взаимодействия пользователей с веб-сайтом. Им необходимо будет понять,
как CMS организует контент и какие средства доступны для агрегирования
и представления контента конечным пользователям.
2Формат файла обмена локализацией XML — языковой стандарт для автоматического
импорта/экспорта для перевода контента. XLIFF обсуждается далее вГлава 10.

Визуальные дизайнеры
Эта роль отвечает за окончательный, высококачественный дизайн веб-
сайта (в отличие от прототипов и пользовательских потоков с более низкой
точностью, обеспечиваемых предыдущими ролями). Визуальным
дизайнерам не нужны глубокие знания CMS, поскольку ограничения,
связанные с CMS, будут направлять процесс вплоть до их участия. (В
некоторых случаях эта роль пересекается с разработкой шаблонов, которую
мы обсудим в следующем разделе.)
Разработчики
Разработчики несут ответственность за установку, настройку, интеграцию и
создание шаблонов CMS в соответствии с требованиями проекта.
Сколько усилий это потребует, зависит от сложности требований и от того,
насколько хорошо CMS соответствует этим требованиям «из коробки». Для
развертывания простого блога на базе WordPress потребуется совсем немного
разработки (а возможно, и вообще ничего), а создание корпоративной
интрасети с нуля — это огромная задача.
Как и редакторы, не все разработчики одинаковы. В рамках разработки
существует несколько категорий задач, которые определяют разные роли:
Конфигурация CMS
Эта роль отвечает за установку и настройку самой CMS, включая создание
модели контента, создание рабочих процессов и других инструментов
редактирования, создание групп пользователей, ролей и разрешений и т. д.
Эта работа выполняется на достаточно высоком уровне. уровне,
посредством средств и интерфейсов, предоставляемых CMS.
Бэкенд (серверная) разработка
Эта роль отвечает за более низкоуровневую разработку, выполняемую на
традиционном языке программирования (PHP, C#, Java и т. д.) для
выполнения более сложных задач управления контентом или для
интеграции CMS с другими системами. Этот разработчик должен иметь
опыт работы (1) с требуемым языком программирования и
(2) API CMS.
Разработка фронтенда (клиента) или шаблонизация
Эта роль отвечает за создание HTML, CSS, JavaScript, логики шаблонов и
другого кода, необходимого для представления управляемого контента в
браузере. Этому разработчику нужно только знать язык шаблонов и
архитектуру, предоставляемые CMS, а также то, как они интегрируются с
HTML, CSS и JavaScript. (Различные архитектуры шаблонов и парадигмы
могут существенно изменить обязанности этой роли, как мы увидим вГлава
9.)
Во многих случаях все три роли в разработке выполняются одним и тем же
человеком. В качестве альтернативы, очень распространенное разделение
заключается в том, что разработка внешнего интерфейса осуществляется
отдельно.
Разработчики | 57
формируется одним разработчиком, а разработка CMS и серверной части
выполняется другим разработчиком. В этих случаях разработчик внешнего
интерфейса отвечает за шаблонирование контента, которым внутренний
разработчик настроил CMS для управления и предоставления.
Визуальные дизайнеры все чаще пишут код своих собственных реализаций
внешнего интерфейса. Таким образом, один и тот же человек может
спроектировать полный интерфейс на основе каркаса, а затем в конечном итоге
создать шаблон CMS, отражающий этот дизайн.
Разделение между CMS и серверной разработкой зависит от CMS. Некоторые
системы позволяют выполнять огромный объем разработки из интерфейса, и
написание программного кода считается скорее исключением, чем правилом. 3
(и помните, что в мультитенантных средах SaaS возможность написания
программного кода может быть недоступна).
Другие системы спроектированы в первую очередь как платформы
программирования, а это означает, что большая часть конфигурации состоит в
основном из написания, компиляции и развертывания программного кода. В
этих случаях настройка CMS и разработка серверной части — это во многом
одно и то же.
Администраторы
Администраторы несут ответственность за непрерывную работу CMS и
связанной инфраструктуры. В этой группе есть несколько подролей:
• Администратор системы управления контентом:Эта роль отвечает за

управление самой CMS, что включает в себя управление пользователями и
разрешениями, создание и управление рабочими процессами, управление
лицензированием и все другие задачи, не связанные с созданием контента.
• Администратор сервера:Эта роль отвечает за обслуживание и поддержку
серверов, на которых CMS работает и/или развертывает контент. Это
традиционная ИТ-роль, и администратор сервера часто не имеет никакого
представления о самой CMS, кроме базовой архитектуры, необходимой для
ее безошибочной работы (операционная система, среда выполнения, веб-
сервер и т. д.). Эта роль обеспечивает поддержку при возникновении
основной проблемы с сервером, которая препятствует правильной работе
CMS.
• Администратор базы данных/хранилища:Эта роль отвечает за
управление сервером базы данных и сетями хранения, в которых хранится
контент CMS. Этот администратор
3Drupal славится этим. Вы можете реализовать значительный объем функций в этой CMS, даже не
написав ни строчки кода. Таким образом, некоторые сайты Drupal могут быть созданы вообще без
необходимости в бэкэнд-разработчике, хотя, как мы обсуждали в«Код и конфигурация» на странице
29, это может привести к другим осложнениям.

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

Очень часто роли администратора сервера и администратора базы
данных/хранилища совмещаются в одном человеке (иногда разработчик даже
выполняет обе эти роли). Однако во многих крупных организациях есть
отдельные группы администраторов данных, отвечающих за управление
хранилищем и ничего больше.
Заинтересованные стороны
Заинтересованные стороны проекта CMS — это аморфная группа,
представляющая людей, ответственных за результаты, которых призвана
достичь CMS. Заинтересованными сторонами обычно являются представители
бизнеса или маркетинга (в отличие от сотрудников редакции или ИТ-
специалистов), которые рассматривают CMS просто как средство для
достижения цели.
В целом заинтересованные стороны ожидают от CMS выполнения одной из двух задач:
• Увеличить доход.
• Сокращение затрат и/или рисков.
Этих целей можно достичь разными способами, и CMS является одним из них.
Заинтересованные стороны часто не имеют прямого контакта с CMS, и их
могут не волновать конкретные функции, которые обеспечивает CMS: их
единственной целью является результат, который может обеспечить CMS.
Например:
• Директор по маркетингу недоволен процентом посетителей, заполнивших

форму «Получить предложение» после просмотра сайта. Она убеждена, что
стратегия персонализации — изменение содержания сайта для конкретного
посетителя — увеличит коэффициент конверсии и, следовательно,
увеличит доход.
• Менеджер отдела поддержки считает, что компания принимает слишком
много звонков в службу поддержки из-за плачевного состояния онлайн-
документации по продукту. Попытки улучшить документацию были
пресечены техническими ограничениями, которые могла бы решить новая
CMS, что, как мы надеемся, приведет к меньшему количеству входящих
обращений в службу поддержки и, следовательно, к снижению затрат.
• Главный редактор пытается увеличить объем статьи, но текущая система
управления контентом требует многих часов редакционных накладных
расходов и доработок, чтобы опубликовать статью. Редактор надеется
увеличить пропускную способность контента с помощью CMS, которая
имеет оптимизированный рабочий процесс редактирования. Цель здесь —
продвигать больше контента, что увеличивает доходы, и делать это более
эффективно с меньшими затратами редакционного труда, что снижает
затраты.
Заинтересованные стороны |5 9
Обратите внимание, что в каждом случае конечной целью не была установка
новой CMS. CMS — это просто средство достижения более крупной
заявленной бизнес-цели.
В каждом из этих трех примеров есть кто-то, кто (1) не собирается напрямую
использовать CMS и (2) не собирается разрабатывать или интегрировать CMS.
Итак, почему заинтересованные стороны так важны? Потому что обычно
именно они принимают решения о покупке CMS и контролируют бюджет, из
которого будет финансироваться проект.
Они включены в это обсуждение команды CMS, потому что иногда за
деревьями легко потерять из виду лес. Чем ближе вы подходите к проекту CMS
— как редактор, администратор, планировщик сайта или разработчик — тем
легче вам зацикливаться на мелких деталях.
Никогда не упускайте из виду тот факт, что заинтересованные стороны мало
заботятся о чем-либо, кроме важного вопроса: приведут ли эти расходы к
достижению бизнес-цели, к которой мы стремимся? Особенности того, как
CMS это делает, — это просто детали.
Перспектива: управление контентом — это часть гораздо большей головоломки

Джефф Крэм
Роль управления контентом значительно изменилась за
последние годы. То, что когда-то было относительно
отдельной частью корпоративного программного
обеспечения, используемого для управления веб-сайтом,
стало неотъемлемой частью цифрового бизнеса
организации. Системы управления контентом теперь
выступают в качестве центрального узла в предоставлении
цифрового опыта, который выходит за рамки маркетинга,
— опыта, который является важнейшей связью между
бизнесом и его клиентами.
Эта реальность фундаментально меняет то, как организации инвестируют в
цифровые возможности, организуют команды и полагаются на внешних
партнеров.
К сожалению, многие организации по-прежнему смотрят на CMS изнутри —
как на часть программного обеспечения, которую необходимо установить и
настроить, прежде чем переходить к следующему ИТ-проекту на дорожной
карте. Возможно, вам удалось обойтись этим подходом 3–5 лет назад. Не
сегодня.
Элементы, необходимые для успеха с CMS, не могут быть помещены в
диаграмму Ганта одного проекта. И все же мы снова и снова видим, как
организации пытаются, а затем обвиняют технологию или внешнего партнера,
когда она терпит неудачу.
Однако есть множество организаций, которые правильно используют CMS.
Это организации, которые осознают, что путь к устойчивому успеху означает
инвестирование в новые внутренние компетенции, создание более
ориентированной на клиента культуры и ориентацию организации на значимые
изменения.

Это организации, которые внедряют постоянные практики контент-стратегии,
правительство
производительность, понимание клиентов и измерение — и активно работать
над ними независимо от установки новой CMS.
Это организации, которые нанимают внешних партнеров не только из-за их
технологических навыков, но и из-за их способности привнести связанный
опыт, необходимый для успеха технологии.
Это организации, которые понимают, что CMS находится в гораздо более
крупной (и расширяющейся) экосистеме маркетинговых технологий, и
работают над пониманием того, как ей необходимо интегрироваться,
поддерживать и часто уходить с дороги других систем.
Станьте одной из этих организаций. Это намного больше работы, но и намного
веселее, чем альтернативный вариант.
ДжеффКрэм — сооснователь и директор по стратегии компании Connective
Заинтересованные стороны |6 1
ЧАСТЬ II
Компоненты систем управления
контентом
ГЛАВА5
Анализ функций CMS
Этот раздел книги посвящен описанию компонентов распространенных систем

управления контентом. Я начну с предупреждения, чтобы сформулировать
ваши ожидания, а затем дам вам обзор того, что будет дальше.
Не желая показаться слишком пессимистичным, цель этой главы — определить
ваши ожидания от оценки управления контентом на уровне функций. Поймите,
что это не точная наука, и если граница вокруг какой-либо особенности
кажется размытой и расплывчатой, скорее всего, это так.
The Сложности из ОсобенностьАнализ

Прежде чем мы приступим к подробному анализу функций управления
контентом, нам необходимо отметить важный момент: анализ и сравнение
функций по функциям сложны. Как бы мы ни хотели, чтобы это была ясная
наука, она запутанна и несовершенна.
Математика – очень объективная наука. У вас не будет особых споров по
поводу ответа на вопрос два плюс два. Существует Великая Единая теория
базовой математики, которая была принята и усовершенствована на
протяжении тысячелетий и касалась того, как работает математика. Эту истину
математики могут исключить из дискуссий.
Управление контентом не такое. Не существует Великой единой теории
управления контентом. Вы можете задать архитектурный вопрос пяти разным
добросовестным экспертам и получить пять разных ответов (может быть,
шесть), каждый из которых послужит решению проблемы.
65
проблема, поставленная вопросом, и поэтому может считаться в некоторой
степени «правильной».1
Почему это?
«Фитнес кЦель"
Оценивая что-либо, мы склонны мыслить в терминах относительности.
Если мы говорим, что какая-то вещь находится «слева», мы подразумеваем, что
какая-то другая вещь находится справа от нее. В конце концов, вы не можете
быть на левой стороне ничего, поэтому концепция левости существует только
потому, что что-то еще находится справа.
Аналогично, системы управления контентом существуют только в четкой связи
с проблемой, которую они должны решить. Их компетентность можно оценить
только с точки зрения их отдаленности от того, что необходимо для вашей
конкретной ситуации.
Правильный ответ на вопрос управления контентом лежит в пересечении
десятков факторов, в том числе:
• Тип и цели сайта.

• Форма управляемого контента (см.Глава 6)
• Требования к выходу и публикации (см.Глава 9)
• Мастерство редакторов (см.Глава 8)
• Деловая среда, процесс принятия решений и бюджет
Это всего лишь пять факторов. Вероятно, их еще сотни, и вес отдельных
факторов будет разным для каждой организации.
Сравнивая системы, легко взглянуть на две функции и сказать: «Эта лучше».
При этом негласное окончание этого предложения звучит так: «для конкретных
требований, о которых я сейчас думаю». То, что подходит для одного набора
требований, может быть явно неправильным для другого.
Более того, некоторым приложениям просто не нужны определенные функции.
Если вы единственный редактор своего веб-контента и точно знаете, что в
будущем не будет других редакторов (это встречается чаще, чем вы думаете),
то концепции работы…
1 То же самое в некоторой степени справедливо и в отношении экономики, области, в которой многое

оставлено для интерпретации и теории. Экономист Дэни Родрик сказал: «Дело не в том, чтобы
прийти к консенсусу относительно того, какая модель правильная… а в том, чтобы выяснить, какая
модель лучше всего применима в данной ситуации. И делать это всегда будет ремеслом, а не наукой,
особенно когда выбор приходится делать в реальном времени». По той же теме Пол Ромер ввел
термин «матичность», чтобы описать иррациональное и потенциально разрушительное желание
принудительно количественно оценить нечеткую дисциплину. См. статью Родрика«Экономисты
против экономики» для большего.
66 | Глава 5: Анализ функций CMS
поток, сотрудничество и разрешения становятся по большей части
бессмысленными. Заявление о том, что система плоха в этих вещах, может
быть точным наблюдением, но оно не имеет значения.
Эксперт по управлению контентом однажды заявил, что единственным
критерием выбора CMS должно быть «соответствие цели». Эта фраза
описывает пересечение между:
• Возможности системы («фитнес»)

• Рассматриваемые требования («цель») Я
сомневаюсь, что существует лучший стандарт
оценки.
"ДелатьСиндром «всего»
Системы управления контентом, как и другое программное обеспечение,
стремятся включить в один пакет как можно больше функций. Ни один
поставщик (или сообщество открытого исходного кода) не хочет сказать: «Мы
не предлагаем эту функцию», поэтому они заинтересованы в том, чтобы
справиться с каждой возможной ситуацией или непредвиденным
обстоятельством. Если редактору приходится выйти за пределы системы, это
считается провалом.2
В результате системы управления контентом с каждым годом становятся все
более сложными. Отрасль неуклонно отходила от четко определенного ядра,
существовавшего 15 лет назад. Мы уже обсуждали переход от контента к
управлению сообществом, и теперь у нас есть системы, управляющие
социальными сетями, предлагающие мощные маркетинговые пакеты и даже
пытающиеся выступать в качестве общих сред разработки приложений.
Цена, которую мы платим за это, — сложность. Список функций, которые вы
собираетесь игнорировать и пытаться найти способы отключить, может легко
оказаться длиннее, чем список функций, которые вы действительно
собираетесь использовать.
По мере усложнения систем они имеют тенденцию становиться более
универсальными. Разработчики, работающие над любой системой слишком
долго, скатываются к более крупным архитектурным концепциям и
структурам. Они становятся тем, кого Джоэл Спольски назвал
«архитектурными астронавтами»:
Когда вы поднимаетесь слишком далеко, с точки зрения абстракции, у вас
кончается кислород. Иногда умные мыслители просто не знают, когда
остановиться, и создают эти абсурдные, всеобъемлющие, высокоуровневые
картины Вселенной, которые хороши и прекрасны, но на самом деле вообще
ничего не значат.3
Подобные гипотетические разговоры действительно случаются при
обсуждении управления контентом:
2 Напротив, компания Basecamp (ранее 37 Signals) сказала о своем популярном инструменте
управления проектами: «Наш ответ по умолчанию на каждый запрос функции — нет». Функции
должны найти свое место в продукте. Планка для включения в продукт значительно высока. , и
разработчики на самом деле гордятся тем, чего не делает их программное обеспечение.
3 «Не позволяйте астронавтам-архитекторам напугать вас», 21 апреля 2001 г.
Трудности анализа объектов | 67

Если мы можем управлять веб-страницами, то мы можем управлять и общим
контентом! Фактически, давайте просто управлять случайными строками текста —
если пользователь захочет создать из них веб-страницу, он сможет это сделать! И
зачем вообще текст? В конечном итоге все состоит из байтов, так что давайте
просто управлять последовательностями байтов и позволим редакторам выбирать
дополнительную кодировку текста или тип файла! Насколько это элегантно?!
Помните: система, предназначенная для того, чтобы делать все, обычно не
делает ничего хорошо, и вам следует оценивать только те функции, которые
вам действительно нужны.
Когда добавляются расширенные функции, выходящие за рамки основного
управления контентом, они часто добавляются плохо. Во многих случаях
поставщик пытается «отметить флажок», который он видит в списках
требований клиентов. Тот факт, что функция существует, не означает, что она
сделана хорошо.
Инструменты для построения форм — классический пример (подробнее об
этом см.Глава 10). Они есть во многих системах, поскольку они стали де-факто
требованием для конкуренции на рынке. Однако я никогда не оценивал
систему построения форм, разработанную на том же уровне, что и основные
инструменты управления контентом. Почти во всех случаях это была
дополнительная функция, которая должна была существовать только до тех
пор, пока была демонстрационная версия.
У нас есть естественное желание думать, что одна система может решить все
наши проблемы. Однако решение может заключаться в использовании
нескольких изолированных систем и их совместном использовании. Вам
нравятся функции совместной работы в Документах Google? Почему вы не
можете использовать это для работы с контентом, а затем просто вставить
результат в свою CMS для доставки? Очевидно, что это немного грубовато и
имеет некоторые недостатки, но многим организациям этот план принесет
больше пользы, чем полномасштабное внедрение CMS для решения одной
проблемы.
Но мы часто смотрим на простоту свысока. Нам нравится думать, что мы
обременены очень сложными проблемами, требующими сложных решений, и
что сложность решения является прямым отражением сложности основной
проблемы. Избавиться от этой привычки сложно.
Выход за рамки вашей новой блестящей CMS не обязательно является
неудачей. Это может быть совершенно правильное решение, вместо того,
чтобы страдать из-за использования плохо реализованной функции из ничего,
кроме желания, чтобы один продукт «делал все».
Целое больше, чем сумма его частей

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

Это может быть вызвано плохим удобством использования на пересечениях
между функциями — система рабочего процесса, которая предлагает
потрясающий набор функций, но просто плохо взаимодействует с редакторами,
когда они создают контент, никому не нужна.
Другая проблема может заключаться в неправильной расстановке приоритетов,
когда одна функция слишком развита по сравнению с другими. Идеальная
система шаблонов для контента, который невозможно точно смоделировать,
вам не сильно поможет, а конечный результат подобен Феррари в пробке:
много энергии, но некуда деваться.
Единственный способ эффективно оценить целое — это подвергнуть его как
можно более длительному сценарию использования. Не просто выбирайте для
сравнения небольшие фрагменты функциональности («Можем ли мы выбрать
утверждающего при запуске рабочего процесса?»), а завершите полный цикл
взаимодействия («Давайте опубликуем пресс-релиз от первоначальной
концепции до конца». распределение"). Подобные сценарии могут пробить
неожиданные дыры в системах, которые с точки зрения функций казались
надежными.
ВыполнениеДетали имеют значение

Ценность функции CMS заключается не только в конечном результате. Также
важно, как вы туда доберетесь. Тот факт, что разные системы могут поставить
галочку в списке функций, не означает, что эта функция была реализована
одинаково хорошо в обеих системах.
Юзабилити имеет значение. Многие функции задуманы, спроектированы и
созданы разработчиками, и это может привести к тому, что интерфейсы и
пользовательские модели будут иметь мало смысла для редакторов.
Разработчики, как правило, более снисходительны к шероховатостям и больше
озабочены максимальной гибкостью, а не удобством использования.
Имеет ли смысл мысленная модель этой функции, помимо интерфейса? Когда с
ним работает редактор, легко ли описать, как он работает, и теоретизировать
способы его использования? Простые функции могут быть затуманены
своеобразными философиями и идеями, которые имели смысл только для
человека, который их разработал, и ни для кого другого.
Некоторые функции могут быть безнадежно сложными либо из-за плохого
дизайна, либо просто потому, что они на самом деле очень сложны.
Рассмотрим модуль Drupal Views — это система, позволяющая редакторам
создавать агрегаты контента. Эта, казалось бы, простая цель на практике
чрезвычайно сложна, и даже несмотря на то, что интерфейс разрабатывался
годами и доводился до чрезвычайно высокой степени, он все равно будет в
некоторой степени ошеломляющим (см.Рисунок 7-10 вГлава 7).
Другие функции могут быть созданы специально для разработчиков. Система
рабочих процессов может быть очень мощной, но если ее необходимо
настроить в коде, затем скомпилировать и развернуть, это резко ограничивает
ее полезность для кого-либо, кроме разработчика или команд, у которых есть
разработчики для будущих изменений. Точно так же системы шаблонов,
которые невозможно извлечь из основного кода системы, ограничивают свою
полезность только теми людьми, которые имеют доступ к этому коду.
Трудности анализа объектов | 69

Для некоторых функций может потребоваться дополнительное программное
обеспечение. Поставщики очень часто «сотрудничают» с другими фирмами для
предоставления подключаемых модулей. Эта функциональность отлично
смотрится в демонстрационной версии, но требует дополнительных затрат и
часто отдельной покупки и лицензии у сторонней компании.4
Урок здесь заключается в том, что наличие какой-либо функции еще не
означает, что она хороша. Когда у вас есть список флажков, которые вы
пытаетесь проверить (реальный список или мысленный список), редко остается
возможность сказать: «Да, эта функция существует, но работает она не очень
хорошо». В большинстве таблиц с матрицами функций есть столбец для «да» и
столбец для «нет», и ничего между ними.
Это очень циничное замечание, но продавцы это знают. Они понимают, что
кто-то, оценивающий их программное обеспечение, задается вопросом о
функциональности и просто предполагает, что оно работает хорошо. Очень
сложно погрузиться в демо-версию программного обеспечения настолько
глубоко, чтобы выявить все недостатки. Возможно, продавец на это
рассчитывает, поэтому часто можно услышать: «Конечно, мы так делаем. А
теперь позвольте мне показать вам еще одну вещь, которую мы делаем…»
Не оценивайте функции, основываясь только на их существовании или на
основе беглого изучения результата. Узнайте, как именно реализована эта
функция, и убедитесь, что вы сможете использовать ее для достижения того же
результата.
Решает ли функция нужную проблему?

Гораздо важнее, чем дискуссии о том, насколько хорошо работает функция,
невысказанный вопрос о том, действительно ли вам нужна определенная
функция для решения вашей основной проблемы.
Возвращаясь к цитате Дональда Рамсфельда о «неизвестных
неизвестных»Глава- тер 3, часто не до конца понимают основную проблему и
вместо этого переходят к решению, которое может служить неправильной
проблеме.
Например, многие клиенты CMS ищут системы, способные поддерживать
сложные рабочие процессы. Однако более глубокий анализ их ситуации
показывает, что их реальная проблема заключается просто в разрешениях: если
бы они могли разделить разрешения на «редактирование» и «публикацию» и
изолировать редакторов по подразделам репозитория контента, то это решило
бы все проблемы, с которыми они сталкиваются. убеждены, что нуждаются в
усовершенствованном рабочем процессе.
На еще более базовом уровне некоторые проблемы, которые пытается решить
клиент, на самом деле имеют нетехническое происхождение. Многие проблемы
4 Я помню, как около 20 лет назад видел отличную демонстрацию рабочего процесса от одной ECM-
компании. Разработчик рабочего процесса может просто перетаскивать прямоугольники и соединять
их стрелками для обозначения состояний и переходов. Это было элегантно и просто. Забыли
упомянуть, что это была еще и надстройка в 15 000 долларов (и это в долларах 1997 года).

К сожалению, часто можно встретить клиентов CMS, которые абсолютно
убеждены, что им нужна
особенность X, и что это панацея, которая решит все их проблемы. Они
завершают большой, дорогой, разрушительный проект, который дает им
функцию X. К сожалению, затем они обнаруживают, что просто прогнали
проблему назад, сняв один или два внешних слоя, а настоящая проблема
заключалась в чем-то большем и более фундаментальном. В конце концов,
признак Х просто наложил повязку на один из симптомов.
Бывший аналитик ЦРУ Филип Мадд пропагандировал то, что он называет
«мышлением назад», имея в виду, что мы должны начать с размышлений о
основной проблеме или вопросе, а не о наборе фактов (особенностей, в нашем
случае), имеющихся в нашем распоряжении:
Когда мы работаем над анализом проблемы, нам не следует начинать с
известных нам данных или информации, а затем на их основе строить дело.
Вместо этого нам следует начать с вопроса о том, что нам нужно знать…
чтобы решить проблему.5
Начните с проблемы. Изучите эту проблему и проработайте возможные
решения в обратном направлении. Вероятно, существует несколько вариантов,
и, начав с проблемы и продолжив работу, у вас будет больше шансов на то, что
Обзор возможностей CMS

Мы начнем с рассмотрения «Большой четверки» управления контентом. Это
четыре функции, которые в той или иной форме необходимы для управления
контентом на самом базовом уровне. Они есть:
Моделирование контента
Вам необходимо описать структуру контента и хранить его как точное
представление этой структуры.
Агрегация контента
Вам необходимо логически организовать контент по группам и
относительно другого контента.
Редакционный рабочий процесс и удобство использования
Вам необходимо разрешить и помочь в создании, редактировании и
управлении контентом в определенных границах.
Издательскийи управление выводом
Вам необходимо различными способами преобразовать контент для
публикации и доставить подготовленный контент в издательские каналы.
5 Филип Мадд, Игра HEAD: Высокоэффективное аналитическое принятие решений – искусство решения
сложных проблемБыстро(Издательская корпорация Liveright, 2015).
Обзор возможностей CMS |7 1

Это основные принципы управления контентом. Если система дает сбой в
одном или нескольких из этих четырех пунктов, трудно эффективно управлять
каким-либо контентом.
Далее мы рассмотрим расширенную функциональность:
• Несколько языковумение обращаться

• Персонализация, аналитика и оптимизация маркетинга
• Формирование здания
• Управление файлами контента
• Обработка изображений
• Управление URL-адресами
• Управление несколькими объектами
• API и расширяемость
• Плагинные архитектуры
• Инструменты отчетности и информационные панели
• Поиск контента
• Поддержка сообщества пользователей и разработчиков (да, это тоже функция)
Перспектива: The Правда О Покупка асистема управления

контентом
Дэвид Маффеи
Вы хотите купить решение WCM. Вы только что
присутствовали на четырех демонстрациях поставщиков.
Похоже, вы находитесь на пути к решению о выборе
платформы цифрового опыта, которая выведет ваш бизнес
на новый уровень. Дела идут так, как вы планировали.
Чего вы не знаете, так это того, что более 50% того, что вы
только что видели, — фейк. Это верно. Решение, которое
вы собираетесь купить
может сделать, возможно, половину того, что вы только что видели —
остальное было комбинацией творческого написания кода и «стратегического»
видения действительно хорошей команды предпродажной подготовки.
Демонстрации поставщиков проводят не столь смелую грань между
«демонстрационным миром» и «реальностью» с точки зрения демонстрации
вам своих решений.
Вопрос в том, как разобраться, что реально, а что нет, и какие решения
максимально приближают вас к окончательному решению?
Реальность такова, что 100 % инструментов, доступных на рынке, выполняют

Это может показаться одновременно логичным и простым, но это не так. Успех
WCM
Реализация зависит от выбора инструмента — не на основе самого
инструмента, а на основе ваших конкретных и уникальных требований. В этих
20% скрыты все тонкости и детали, которые определяют или препятствуют
внедрению и фактическому использованию вашего инструмента в
производстве. Эти 20% — это разница между решением, обеспечивающим
операционную эффективность, стабильность и надежность, и решением,
которое в конечном итоге оказывается заброшенным. Что хуже? Уникальный
процент, который вас определяет, чаще всего демонстрировался вам через
призму «демо-мира», а не реальности.
Организации всегда фокусируются на 80%. Они создают запросы предложений
из тысяч строк и просматривают демо-версии сотен инструментов — каждый
из которых демонстрирует свои сильные стороны и ограничивает видимость
своих слабых сторон. Чтобы стать успешным конечным пользователем, вам
следует тратить меньше времени на разговоры с аналитиками о поставщиках,
меньше времени на просмотр демонстраций и меньше времени на чтение
ответов на запросы предложений, а все сэкономленное время потратить на
понимание двух вещей: каковы ваши стратегические цели. (и тактика,
необходимая для их достижения), и может ли продукт, который вы хотите
Обзор возможностей CMS |7 3

www.allitebooks.com
ГЛАВА6
Моделирование контента
Рискуя вызвать плохие воспоминания, рассмотрите форму, которую вы должны

заполнить в местном Департаменте транспортных средств при продлении
водительских прав. Вы представляете себе лист бумаги с крошечными
квадратиками, не так ли?
Но что, если бы всё было не так? Представьте, что вместо формы вы получили
чистый лист бумаги, на котором вам нужно написать эссе в свободной форме,
идентифицируя себя и предоставляя всю информацию, которую вы можете
придумать. Затем кто-то из DMV садится читать ваше эссе и извлекать всю
конкретную информацию, необходимую DMV. Если информации там нет
(например, вы забыли указать дату своего рождения, потому что никто не
сказал вам указать ее в эссе), вас отправят обратно, чтобы попытаться еще раз.
Возможно, вы подумали, что невозможно ухудшить процесс продления
водительских прав, но я готов поспорить, что этот процесс может привести к
именно этому.
К счастью, в DMV есть формы с отдельными полями для ввода различной
информации: вашего имени, даты рождения и т. д. В этих полях даже есть
описывающие их метки и подсказки, позволяющие убедиться, что вы вводите
информацию в правильном формате: там может быть « мм/дд/гггг» в поле даты
рождения, два тире в поле номера социального страхования и флажки для
«мужского» или «женского».
Люди, разработавшие эту форму, рассмотрели диапазон информации, которая
им нужна от людей, а затем структурировали ее. Они разбили его в отдельные
поля в форме и приняли меры, чтобы убедиться, что он введен правильно.
Другими словами, кто-то «смоделировал» информацию, которую требует
DMV. Они извлекли явную структуру из аморфного куска информации,
необходимой DMV, разбили ее на более мелкие части и предоставили
интерфейс для управления ею (саму форму).
75
Аналогичным образом, основная цель любой CMS — точное представление
вашего контента и управление им. Для этого он должен знать, что представляет
собой ваш контент. Точно так же, как вы не можете построить коробку для
чего-либо, не зная размеров этой вещи, ваша CMS должна знать размеры
вашего контента, чтобы точно хранить его и управлять им.
В большинстве случаев вы начинаете с логического представления о контенте,
которым вам необходимо управлять, чтобы выполнить требования проекта.
Например, вы знаете, что вам нужно отобразить выпуск новостей. Это общее
понятие содержания. Но что такое пресс-релиз? Как это выглядит? Как он
структурирован? Спросите пять разных людей, и вы можете получить пять
разных ответов.
CMS не может читать ваши мысли (а тем более мысли пяти разных людей) и
поэтому понятия не имеет, что вы думаете о выпуске новостей. Итак, это
логическое понятие пресс-релиза необходимо перевести в конкретную форму,
которой действительно сможет управлять ваша CMS.
Для этого вам нужно объяснить CMS, что такое пресс-релиз: какие фрагменты
информации составляют пресс-релиз и каковы правила и ограничения в
отношении этой информации? Только зная это, ваша CMS сможет хранить,
управлять, искать и предоставлять инструменты редактирования, подходящие
для этого контента.
Этот процесс называется моделированием контента. Результатом является
описание всего контента, которым должна управлять ваша CMS. Это ваша
модель контента.
Моделирование контента часто выполняется плохо либо из-за ошибок в
суждениях, либо из-за встроенных ограничений конкретной CMS. К
сожалению, ставки могут быть очень высоки. Моделирование контента — это
основа, на которой строится реализация CMS. Ошибки, допущенные здесь,
порождают множество будущих проблем, от которых может быть трудно
избавиться.
Предупреждение: впереди теория

Эта глава (и последующие) может показаться немного
абстрактной или технической, в зависимости от вашего опыта.
Мы собираемся обсудить основные характеристики контента в
целом, отдельно от конкретных его представлений, таких как
интерфейс, в котором редакторы создают контент, или веб-
страницы, генерируемые CMS.
Даже если что-то из этого кажется теоретическим,
постарайтесь придерживаться этого. Основа, заложенная в этих
главах, облегчит вам понимание более конкретных тем далее в
книге.
Данные Моделирование101
Моделирование не является чем-то уникальным для управления контентом.
«Моделирование данных» существует столько же, сколько и базы данных. На
протяжении десятилетий разработчикам баз данных приходилось переводить
логические
76 | Глава 6: Моделирование контента

идеи информации в представления базы данных, которые находятся в
оптимальном для поиска, хранения и манипулирования формате.
Сходство между традиционными базами данных и управлением контентом
очевидно: обе системы представляют собой системы управления информацией
на определенном уровне. Фактически, CMS обычно создаются на основе
реляционной базы данных. Почти каждая CMS имеет базу данных, в которой
хранится большая часть информации.
В этом смысле CMS можно рассматривать как «супербазу данных», под
которой мы подразумеваем базу данных, расширенную для предоставления
функций, специфичных для управления контентом. Фактически, друг однажды
назвал CMS «системой управления реляционной базой данных», чтобы
отразить идею о том, что CMS объединяет основные функции управления
данными базы данных на другом уровне функциональности. Таким образом,
многие из тех же концепций, парадигм, преимуществ и недостатков
реляционных баз данных в той или иной степени применимы и к системам
управления контентом.1
Другое слово, обозначающее процесс преобразования логических идей в
конкретные структуры данных, — это овеществление, которое происходит от
латинского префикса res, что означает «вещь». Овеществить что-либо —
значит буквально «сделать это вещью».
Компьютеры не понимают неопределенности. Им нужны точные, конкретные и
ограниченные данные, чтобы они точно знали, с чем работают. Реификация —
это процесс перехода от абстрактной и неограниченной идеи чего-либо к
конкретному представлению этого, полный ограничений и ограничений,
которые это влечет за собой.
Классическим примером проблемы моделирования является почтовый адрес:
123 Мейн-стрит
Люкс 1
Нью-Йорк, штат Нью-Йорк 10001
Это довольно просто сохранить как большой кусок текста, но это ограничивает
вашу возможность задавать вопросы:
• Вы в каком городе?
• На каком этаже вы находитесь?
• Какие еще предприятия находятся поблизости?
• На какой стороне улицы вы находитесь?
1 Если вы думаете, что, возможно, вам будет полезен опыт проектирования баз данных, вы абсолютно
правы. С этой целью я рекомендую книгу «Проектирование баз данных для простых смертных»
Майкла Эрнандеса (Addion-Wesley). Даже если вам никогда не приходилось проектировать
традиционную базу данных, способность отделять модель данных от хранящейся в ней информации
является ключевым профессиональным навыком.
Моделирование данных 101 | 77

Чтобы ответить на эти вопросы, вам придется проанализировать (или разбить)
этот адрес на более мелкие части. Эти меньшие части имеют смысл только
тогда, когда они правильно помечены, чтобы машина знала, что они
представляют. Например, цифра «1» во второй строке имеет смысл, когда она
относится к номеру подразделения, но не работает как почтовый индекс.
Рассмотрим альтернативную модель предыдущего адреса:
• номер улицы: 123

• Направление улицы: [никто]
• название улицы: Основной
• Суффикс улицы: Улица
• Этикетка устройства: Люкс
• Номер устройства: 1
• Город: Нью-Йорк
• Состояние: Нью-Йорк
• Почтовый Код:10001
Сохраняя эту информацию в более мелких фрагментах и присваивая этим

фрагментам метки, мы можем манипулировать и запрашивать большие группы
адресов одновременно. Здесь мы воплотили общую идею адреса в конкретное
представление, с которым может работать наша CMS.
Не могли бы вы просто анализировать адрес каждый раз, когда захотите с ним
поработать? Конечно. Но гораздо эффективнее делать это один раз при
создании контента, а не каждый раз, когда вы хотите что-то из него прочитать.
Здравый смысл подсказывает, что вы будете читать контент гораздо чаще, чем
создавать или изменять его. Кроме того, после его создания человек-редактор
может принимать упреждающие решения о том, что и где будет происходить,
вместо того, чтобы алгоритм синтаксического анализа делал предположения.
Стоит отметить, что создав модель адреса, мы фактически сделали ее менее
гибкой. Каким бы неэффективным ни было хранение больших объемов текста,
оно, безусловно, гибкое. Большой кусок текста без каких-либо правил может
хранить что угодно, даже такой адрес:
123 Main Street
South Suite 200
Почтовая
остановка 456
от Боба
Джонсона
Нью-Йорк, штат Нью-Йорк,
10001-0001.АПО АП 12345-
1234
Этот адрес не вписывается в модель, которую мы создали ранее. Чтобы эта
модель работала для этого контента, нам нужно расширить нашу модель, чтобы
она подошла. Например, нам нужно будет создать пространство для номеров
APO/FPO/DPO.2
Адреса в этом формате могут быть относительно редкими, но при создании
модели контента ваше мнение является неизбежной частью процесса. Является
ли эта ситуация достаточно распространенной, чтобы оправдать усложнение
модели для ее учета? Исключение становится правилом? На этот вопрос могут
ответить только ваши конкретные требования.
Хотя большинство проблем, наблюдаемых при плохих реализациях, связаны с
недостаточно структурированным контентом, знайте, что вы можете пойти и в
другом направлении. Слишком сильное структурирование контента может
испортить редакционный опыт.
Бывший архитектор CMS и нынешний автор UX3 Вот что сказал Джош Кларк
по поводу решения о том, насколько структурировать тот или иной тип
контента:
Большим преимуществом структурирования контента, конечно же, является то,
что оно позволяет вам переупаковывать его и представлять в разных формах и
контекстах. Обратной стороной является то, что редакторы вынуждены
подходить к своему контенту как машины, думая в терминах абстрактных
полей, которые в дальнейшем могут смешиваться и совмещаться.
Преимущества часто перевешивают затраты на удобство использования, если
вы собираетесь представлять элементы контента в нескольких контекстах и/или
предлагать различные варианты сортировки с большим количеством
элементов. Если нет, то я обычно использую [меньше структуры].4
Ключом, как всегда, является баланс, основанный на четком понимании вашего
контента, ваших требований и ваших редакторов.
Краевые случаи
В разработке программного обеспечения наш сложный адрес
называется «крайним случаем», поскольку это вариант
использования на границе основного направления.
Проектирование программного обеспечения изобилует такими
ситуациями, и вы не сможете учесть их все. Попытки
справиться со всем приведут к раздутому программному
обеспечению, которое станет настолько универсальным и
сложным, что даже не сможет выполнить свою
первоначальную задачу.
Только опыт и знание ваших пользователей и требований
могут помочь вам решить, какие крайние случаи следует
учитывать.
2 Это методы отправки почты военным и государственным служащим, проходящим службу в
отдаленных местах. Это аббревиатуры от авиапочты, почтового отделения флота и
дипломатического почтового отделения.
3 Джош много лет разрабатывал Big Medium CMS, а недавно написалПроектирование для сенсорного
управления (Книга отдельно).
4 Личное общение с автором, декабрь 2007 г.
Моделирование данных 101 | 79

Данные Моделирование и СодержаниеУправление
Каждая CMS имеет модель контента. Даже самая простая CMS имеет
внутреннее, конкретное представление о том, как она определяет контент.
Простейшей моделью может быть вики, где нет ничего, кроме заголовка и
основного текста. Каким бы упрощенным и жестким это ни было, это явно
предопределенная модель контента.
Исходные платформы для ведения блогов — ранние WordPress, Movable Type,
Blogger и т. д. —работало практически одинаково: все, что вы вводили в
систему, имело заголовок, тело, отрывок и дату. Поскольку единственное, чем
им нужно было управлять, — это серия сообщений в блоге, по сути это была
встроенная модель контента, разработанная специально с учетом требований
этого контента.
В большинстве случаев вам потребуется больше гибкости. Вам необходимо
хранить информацию помимо той, которая предлагается по умолчанию. В этом
случае вы ограничены возможностями моделирования контента вашей CMS.
Некоторые системы предлагают ограниченное количество «настраиваемых
полей» в дополнение к встроенной модели (платформы для ведения блогов,
такие как WordPress, продвинулись в этом направлении; см.Рисунок 6-1), в то
время как другие системы ничего не предполагают и зависят от вас в создании
модели контента с нуля. С этой целью они могут предложить ошеломляющий
набор инструментов, помогающих определить модель контента.
Рисунок 6-1. Интерфейс настраиваемых полей произвольной формы в WordPress.
Негласный стандарт, которому следует большинство CMS, — это

настраиваемая реляционная база данных, которая была традиционным
способом моделирования данных и информации с начала 1970-х годов. 5 CMS
имеют разную степень приверженности этому идеалу — некоторые заставляют
вас
5 Видеть«Реляционная модель данных для больших общих банков данных», Э.Ф. Кодд.
упрощайте больше, чем хотелось бы, в то время как другие, по сути, являются
тонкой оболочкой вашей собственной реляционной базы данных.6
Почему не все CMS такие? Потому что зачастую это больше, чем вам нужно.
Индустрия CMS развивалась вокруг общих проблем с контентом и создала
шаблоны для решения ситуаций, которые возникают снова и снова.
Большинство проблем управления веб-контентом попадают в диапазон,
охватываемый этими шаблонами — исключениями являются… подождите…
крайние случаи, — поэтому их достаточно для нормального функционирования
при большинстве требований.
То, попадает ли конкретная CMS в диапазон возможностей моделирования,
оказывает огромное влияние на успех или провал вашего проекта. Некоторые
проекты имеют сложные модели контента и полностью зависят от способности
CMS точно их представлять. В этих случаях ограничения моделирования
контента может быть трудно обойти.
Разделение контента и представления

Соблазнительно взглянуть на какую-то форму вашего контента — например, на
ваш выпуск новостей, отображаемый в браузере, — и сказать: «Это мой
контент».
Но так ли это? В чистом смысле ваш реальный контент — это структура и
слова, из которых состоит пресс-релиз. Информация в вашем браузере — это
просто веб-страница. Итак, вы управляете контентом или веб-страницами?
Я утверждаю, что это первое. Ваш контент максимально приближен к чистой
информации. Веб-страница на самом деле представляет собой медиафайл,
созданный вашим контентом. Другими словами, это просто представление
вашего контента.
Ваш контент был объединен с презентационной информацией (в данном случае
преобразован в HTML-теги) и опубликован в определенном месте. В идеале вы
могли бы взять те же самые слова и использовать их для создания PDF-файла,
или после публикации веб-страницы вы могли бы использовать заголовок
вашего пресс-релиза и URL-адрес для создания обновления Facebook.
Эти места публикации (электронная почта, Интернет, Facebook и т. д.) часто
называются каналами. Медиаматериалы, публикуемые на канале, можно
назвать воспроизведением или презентацией контента на конкретном канале.
Отношение контента к опубликованным средствам массовой информации
является одним ко многим: один фрагмент контента может привести к
множеству презентаций. В этом смысле презентация применяется к контенту,
чтобы получить некую часть опубликованного медиа.
Мы сможем сделать это только в том случае, если разделим наш контент и
нашу презентацию, что означает максимально «чистое» моделирование нашего
основного контента. В идеале мы делаем это безотносительно
6 Некоторые избранные системы представляют собой буквально тонкую обертку вокруг
пользовательской базы данных. Некоторые CMS просто добавляют несколько полей и таблиц в
базу данных, созданную вами, чтобы добавить расширенную функциональность CMS.
Разделение контента и представления |8 1

к какому-либо конкретному формату представления. (Возможно, нам
потребуется добавить некоторую дополнительную информацию, чтобы
облегчить применение конкретной презентации, но эта информация не будет
использоваться в других контекстах презентации.)
Эта концепция не нова. Гидеон Бертон, профессор английского языка в
Университете Бригама Янга, проследил это вплоть до древних греков.
Аристотель сформулировал это как разницу между логосом (логическим
содержанием речи) и лексикой (стилем и подачей речи). Римские авторы, такие
как Квинтилиан, проводили такое же различие, отделяя рассмотрение вещей
или субстанции, res, от рассмотрения словесного выражения, verba.7
Наш контент — это логотипы, а метод представления — лексика.
Привязка вашего контента к конкретной презентации резко ограничивает то,
что вы можете делать с этим контентом. Если ваши требования просты и не
изменятся, возможно, это не является большим недостатком. Но когда контент
хорошо структурирован, его полезность возрастает:
Шаблонизациялегче
Разбивка контента на более мелкие фрагменты позволяет использовать его
более конкретным образом при создании шаблонов. Хотите, чтобы на
странице биографии первой отображалась фамилия автора? Это гораздо
проще сделать, если фамилия хранится отдельно от имени.
Возможны массовые изменения презентации
Должны ли фотографии и биография авторов теперь отображаться на левой
боковой панели, а не внизу статьи? Если эта информация отделена от
основной части контента, это простое изменение шаблона, независимо от
того, 10 или 10 000 статей у вас.
Контент можно легко представить в других контекстах.
Если на ваших страницах есть изолированные сводки, их можно
публиковать в других контекстах с меньшими требованиями к длине или
контент можно сокращать с учетом ограничений окружающей среды,
например мобильных устройств.
Удобство редакционного использования улучшено
Детализированные модели контента часто позволяют настраивать
редакционный интерфейс с помощью определенных элементов, чтобы
редакторы могли точно работать с конкретными фрагментами информации,
составляющими ваш контент. Следует ли ограничить количество HTML-
тегов, которые редакторы могут использовать при написании аннотаций
статей? Если «Сводка» является отдельным атрибутом, это сделать проще.
Возвращаясь к аристотелевскому примеру Бертона, Аристотель мог бы иметь
теорию о положении человека во Вселенной. Эта теория является его
содержанием. Он может «передать» эту ситуацию
7 Гидеон Бертон,«Сильва Риторика».

превратить в эссе, пьесу, речь и даже рисунок. Эти элементы — медиа,
созданные на основе его контента. Это всего лишь презентации — в основе
всех них лежат основные понятия теории Аристотеля.
Много шума из ничего: содержание и презентация

Недавно я прочитал «Много шума из ничего», пьесу Уильяма Шекспира,
написанную где-то в конце 16 века. Это одно из его самых популярных
произведений, и с тех пор оно исполнялось, переиздавалось и адаптировалось
тысячи раз.
Я отслеживаю все свое чтение в сервисе под названиемГудриддс, и я пошел
туда, чтобы записать свои мысли по этому поводу. Однако меня немного
расстроил тот факт, что Goodreads ориентирован на презентации, а не на
контент. Когда я попытался найти «Много шума из ничего», чтобы добавить ее
в свой список, я столкнулся с 222 различными опубликованными работами.
Мой экземпляр был напечатан в 2007 году издательством Modern Library. Но
это было не то, что я хотел рассмотреть. Я хотел сделать рецензию на саму
пьесу. Я хотел обсудить концепции и идеи, написанные Шекспиром около 400
лет назад, а не книгу в мягкой обложке, которую я держал в руке.
Моя книга была всего лишь средством передачи пьесы в данном конкретном
случае. Содержанием была пьеса. Моя книга в мягкой обложке была одной из
возможных презентаций.
Если уж на то пошло, то на самом деле это был конкретный экземпляр
определенного типа презентации. «Много шума из ничего» было напечатано во
многих книгах; это был только один из них. Это тоже был фильм в 1993 и 2011
годах. Это конкретные примеры разных типов подачи.
В каждом случае детали менялись, но суть пьесы Шекспира оставалась
прежней. Сама пьеса была изображена в декорациях от Британской
колониальной Индии до Кубы 1950-х годов. Фильм Джосса Уидона 2011 года
даже переносит его в наши дни. Все эти разные презентации работали по
одному и тому же сценарию, представляли одно и то же шекспировское
содержание и часто использовали одни и те же диалоги.
Путаница в содержании и представлении иногда очевидна при чтении
негативных обзоров творческих работ. Некоторые рецензенты обсуждают не
саму работу, а скорее среду, в которой она была представлена. У них нет
проблем с концепциями книги, которую они читают, но они расстроены тем,
что размер шрифта был слишком маленьким. Фильм на DVD, который они
смотрели, на самом деле был великолепен, но они поставили ему одну звезду,
потому что меню заголовков сбивало с толку. Я даже видел плохие отзывы об
упаковке, в которой что-то было доставлено, что на самом деле является всего
лишь средством презентации — оберткой вокруг оболочки контента.
Ваш контент — это абстрактный идеал. Его необходимо обернуть какой-то
презентацией, но в этом мире цифровых манипуляций эта презентация не
является неотъемлемой частью работы.
Разделение контента и представления |8 3
Через несколько дней после знакомства с Goodreads я посмотрел экранизацию
книги 1993 года.
Много шума из ничегов главных ролях Дензел Вашингтон и Кеннет Брана. Это
вызвало у меня те же мурашки, что и пьеса. Идеи, которые исследовал
Шекспир, были так же хороши на экране, как и на бумаге. Независимо от
конкретного представления, содержание было универсальным.
«Постраничная» CMS
Основной вопрос заключается в том, управляет ли ваша CMS контентом или
страницами. Предполагает ли ваша CMS, что каждая часть контента в
репозитории должна создавать веб-страницу? Или это чистые объекты
контента, которые затем можно встроить в страницы?
Объединение объекта контента и страницы привело к тому, что фраза «CMS на
основе страниц» используется для описания CMS, которая явно управляет веб-
страницами, а не более абстрактных понятий контента без представления. Эта
фраза обычно всплывает при сравнении двух систем и обычно подразумевается
уничижительно, поскольку предполагается, что управление простыми
страницами менее благородно и сложно, чем управление чистым контентом.
Это справедливое замечание, но оно может быть неуместным по нескольким причинам.
Во-первых, хотя многоканальная публикация и повторное использование
контента очень ценны, не во всех случаях они нужны. Во многих случаях 99%
просмотров контента приходится на просмотры страниц в браузере, поэтому
управление страницей имеет первостепенное значение.
Во-вторых, тот факт, что страницами управляет CMS, не означает, что
содержимое этих страниц нельзя использовать другими способами. Даже если
ваша CMS предлагает вам тип контента под названием «Страница статьи
новостей», это не означает, что контент нельзя извлечь и перепрофилировать в
такие вещи, как RSS-каналы и веб-API.
Хотя настоящая CMS на основе страниц, скорее всего, будет содержать
некоторые свойства, специфичные для веб-страницы — мета-теги, метки меню,
выбор шаблонов и т. д. — она также будет включать более нейтральную, не
требующую представления информацию, которую можно использовать
другими способами.
В конце концов, разница между «страницей» и более общим «элементом
контента», похоже, заключается в возможности адресации URL. Страницы
получают URL-адреса и предназначены для просмотра изолированно, как
основной объект контента, полученный в результате одного веб-запроса.
Элементы контента (не страницы) предназначены для поддержки другого
контента посредством ссылок или встраивания (см.«Внедрение контента» на
странице 97.), и не будет иметь индивидуальной URL-адресации.
Когда производный контент является собственным контентом?
В какой момент твит о новостной статье сам по себе
становится контентом? Чтобы создать твит из нашей CMS, мы
можем просто добавить некоторые атрибуты к типу контента
новостной статьи — например, «Текст Twitter». Это означает,
что твит «прикрепляется» к той же модели контента, что и
сама новостная статья.
Но в какой момент имеет смысл отделить информацию,
необходимую для твита, и опубликовать ее как отдельный
объект контента? Мы могли бы создать еще один тип
контента — «Твит». У него будет атрибут для текста и,
возможно, еще один атрибут для ссылки на статью, которую
мы с его помощью продвигаем.
В таком виде он будет жить своей жизнью в нашей CMS. Это
будет объект со своим собственным жизненным циклом
контента, разрешениями, рабочим процессом и даже
интерфейсом редактирования. Необходимость или
преимущество этого зависит от ваших требований.
Определение модели контента

Модель контента определяется тремя вещами:
• Типы
• Атрибуты
• Отношения
Эти три вещи, используемые в сочетании, могут определять почти бесконечное

разнообразие контента.
Типы контента
Тип контента — это логическое разделение контента по структуре и
назначению. Каждый тип выполняет свою роль в модели и содержит разную
информацию.
Люди каждый день мыслят типами. Вы маркируете конкретные вещи в
зависимости от того, к какому типу они относятся — с точки зрения «есть»:
• Это колониальное здание с тремя спальнями и двумя ванными комнатами.

• Colnago AC-R Ultegra Complete 2015 года выпуска — это велосипед.
• Этот «футдлинный огнедышащий» — это буррито.
Думая таким образом, мы мысленно определяем типы. Мы понимаем, что в

мире существует множество велосипедов, буррито и зданий, и все они
бетонные.
Определение модели контента | 85
представления какого-либо предмета. Мы мысленно отделили тип вещи от
конкретного экземпляра вещи.
Редакторы, работающие с контентом, думают так же. Редактор хочет создать
новый выпуск новостей или новую биографию сотрудника. 8 Или этот
существующий контент является выпуском новостей или биографией
сотрудника. В голове вашего редактора идея общей страницы отделена от
реального представления страниц «О нас» или «Продукты».
Независимо от того, признается это явно или нет, всякий раз, когда вы
работаете с контентом, у вас есть некое мысленное представление о типе
контента, которым вы хотите управлять. Вы мысленно помещаете свой контент
в коробки в зависимости от того, что это за контент.
Тип контента заранее определен для вашей CMS. Большинство CMS допускают
несколько типов контента, но они сильно различаются с точки зрения того,
насколько детальными и конкретными могут быть определения этих типов.
Весь контент, хранящийся в CMS, будет иметь тип. Этот тип почти всегда
будет выбран при создании контента — действительно, большинство CMS не
будут знать, какой интерфейс редактирования показывать редактору, если они
не знают, с каким типом контента редактор пытается работать. Обычно сложно
изменить тип объекта контента после его создания (подробнее об этом в
следующем разделе).
Важно провести четкую грань между типом контента и объектом контента. Тип
контента — это шаблон объекта — велосипеда, буррито или здания из
предыдущего примера. У вас может быть один тип контента, на основе
которого создаются тысячи объектов контента.
Подумайте о том, чтобы приготовить рождественское печенье. У вас есть
формочка для печенья в форме рождественской елки, леденца, снеговика или
чего-то еще. С его помощью вы нарезаете тесто для печенья. У вас есть одна
формочка для печенья, из которой вы создаёте десятки печенек. Форма для
печенья — это ваш тип контента. Фактические файлы cookie представляют
собой объекты контента.
Тип контента можно рассматривать как «шаблон» для части контента или
определение информации, которая требуется для того, чтобы конкретный тип
контента считался действительным. Например, в биографии сотрудника может
потребоваться следующая информация:
• Имя
• Фамилия
• Должность
• Дата приема на работу
8 В оставшейся части книги я буду писать названия типов контента с заглавной буквы как имена
собственные. Я буду писать объекты контента строчными буквами (например, конкретная статья
является объектом типа Article).

• Био
• Менеджер
• Изображение
(Это атрибуты, о которых мы вскоре поговорим.)

Вы должны создать это определение заранее, чтобы ваша CMS знала, какую
информацию вы будете помещать в какие места.
Организация контента по типам дает множество преимуществ:
Состав
Разные типы контента требуют разной информации, чтобы считаться
действительным. Человеку требуется Имя. Это не имеет смысла для
страницы.
Удобство использования
Большинство CMS автоматически создают интерфейс редактирования,
соответствующий типу контента, с которым вы работаете. Например, при
редактировании даты приема на работу в биографии сотрудника CMS
может отображать раскрывающийся список выбора даты.
Поиск
Найти все сообщения в блоге довольно просто, если все они имеют один и тот же тип.
Шаблонизация
Наши страницы биографии сотрудников будут явно отличаться от страниц
наших выпусков новостей. Поскольку эти два типа хранят разную
информацию, они, очевидно, имеют разные методы вывода этой
информации.
Возможно, только отдел кадров может редактировать биографии
сотрудников. В зависимости от CMS вы можете ограничить разрешения в
зависимости от типа.
Таким образом, типы контента в реализации CMS образуют границы вокруг
логически различных типов контента, позволяя вам применять
функциональные возможности и функции управления только к тем типам, к
которым они применимы.
Переключениетипы
Переключение базового типа контента после того, как на его основе был создан
объект контента, может оказаться логически проблематичным.
Предположим, мы создали часть контента на основе типа контента «Биография
сотрудников». Теперь, по какой-то причине, мы хотим преобразовать это в
пресс-релиз. У нас есть проблема, потому что у нас есть информация,
специфичная для типа «Биография сотрудника», которой нет в типе «Выпуск
новостей» (например, «Имя»), а это означает, что когда мы переключаем типы,
этой информации некуда идти. Что с этим происходит?
По этой причине переключение типов контента после его создания часто не
допускается. Если это так, вам придется принять трудные решения о том, что
произойдет с информацией, которой нет логического места в будущем типе
(Рисунок 6-2).
Рисунок 6-2. Преобразование типов контента в Episerver — если новый тип не

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

просто выбросить эту информацию. Таким образом, переключение типов —
занятие не для слабонервных, особенно если у вас есть сотни или даже тысячи
объектов контента, основанных на определенном типе.
Атрибуты иТипы данных

Типы контента — это оболочки небольших фрагментов информации.
Вернитесь к нашему предыдущему определению биографии сотрудника.
Биография сотрудника — это просто набор небольших фрагментов
информации (имя, фамилия и т. д.).
Номенклатура различается, но эти более мелкие фрагменты информации
обычно называются атрибутами, полями или свойствами (мы будем
использовать «атрибут»). Атрибут — это наименьшая единица информации в
вашей модели контента, которая представляет собой единственную часть
информации об объекте контента.
Каждому атрибуту будет присвоен тип данных, который ограничивает
информацию, которая может храниться в нем. Распространенными базовыми
типами данных являются:
• Текст (разной длины)

• Число
• Дата
• Изображение или файл
• Ссылка на другой контент
В зависимости от CMS могут существовать десятки возможных типов данных,

которые вы можете использовать для описания типов контента, и вы даже
можете создавать свои собственные типы данных.

которые специфичны для вашей модели контента и никакой другой.Рисунок 6-
3 показаны некоторые опции, доступные в CMS eZ Platform.
Рисунок 6-3. Предопределенные типы атрибутов, доступные для eZ Platform
Возвращаясь к нашей предыдущей модели, мы можем применить следующие типы данных:
• Имя: краткий текст

• Фамилия: короткий текст
• Название вакансии: краткий текст
• Дата найма: дата
• Биография: форматированный текст
• Менеджер: ссылка на другой объект «Биография сотрудника».
• Изображение: ссылка на файл изображения.
Указывая типы данных, вы позволяете вашей CMS делать несколько вещей:

Проверка
CMS может гарантировать, что введенная вами информация действительна.
Например, Manager должен быть допустимой ссылкой на другой объект
«Биография сотрудника». Кроме того, CMS может предостеречь вас от
удаления этого другого объекта, пока на него еще имеются необработанные
ссылки.

Редактирование генерации интерфейса
CMS может отображать различные элементы интерфейса, чтобы вы могли
легко работать с разными атрибутами. Вы можете разрешить
форматированный текст9 в атрибуте «Биография», что означает
отображение WYSIWYG10 редактор с элементами управления
редактированием.
Сортировка и фильтрация
CMS понимает, как использовать разные типы данных для сортировки и
фильтрации контента. Фильтруя и сортируя по дате приема на работу, вы
можете найти всех сотрудников, нанятых между двумя датами, и
упорядочить их по старшинству.
Некоторые CMS не позволяют типизировать данные атрибутов, но это
случается редко. В таких случаях CMS обычно позволяет вам просто объявлять
«настраиваемые поля», которые сохраняются в виде простого текста.
Полезность этих полей крайне ограничена, так как вы должны убедиться, что
редакторы вводят значения правильно (обеспечить соблюдение формата даты в
простом текстовом поле сложно), и вы должны пройти через все препятствия,
чтобы использовать эти значения при сортировке и фильтрации.
ВстроенныйАтрибуты
Большинство CMS имеют несколько встроенных атрибутов, которые
автоматически существуют в каждом типе контента и их не нужно явно
добавлять в модель контента. К ним относятся:
ИДЕНТИФИКАТОР
Каждый без исключения объект контента имеет идентификатор
определенного типа, который однозначно идентифицирует этот контент,
мало чем отличаясь от первичного ключа в таблице базы данных
(фактически, за кулисами, это часто является первичным ключом таблицы
базы данных). Большинство систем имеют числовые инкрементальные
идентификаторы. Некоторые другие используют GUID,11 что полезно при
перемещении контента между установками, поскольку они гарантированно
будут глобально уникальными.
Титул или имя
В большинстве систем есть какой-то способ назвать объект контента.
Обычно это явное поле «Заголовок», которое либо используется только как
внутренний заголовок, либо имеет двойное назначение в качестве
отображаемого заголовка объекта (заголовок пресс-релиза, например).
9 «Форматированный текст» часто используется для обозначения любого текста, который допускает
встроенное форматирование, например, полужирный, курсив и т. д. В большинстве случаев это
означает HTML. Таким образом, предполагается, что «редактор форматированного текста» — это
визуальный редактор, который генерирует HTML в фоновом режиме. Однако в некоторых системах
термин «форматированный текст» используется для обозначения полей обычного текста, которые
позволяют вручную вставлять теги HTML или даже сокращенные форматы, такие как Markdown.
10 «Что видишь, то и получаешь». Редактор WYSIWYG — это интерфейс редактирования расширенного
текста, который генерирует HTML, нопозволяет редактировать текст визуально, вместо использования
тегов или другой разметки.
11 Глобальные уникальные идентификаторы. GUID — это последовательность случайных чисел и
символов, достаточно длинная, чтобы практически гарантировать уникальность. Общая длина
составляет 32 цифры, что достаточно для того, чтобы гарантировать, что если бы каждый человек на
Земле обладал 600 миллионами различных GUID, вероятность существования нового GUID все
равно была бы только 50%.

пример). В некоторых случаях система позволит вам получить это значение
из других атрибутов, используя токены, которые заменяются значениями.
Например, если указать имя биографии сотрудника как $LastName,
$FirstName, то имя всегда будет иметь значение вроде «Джонс, Боб» при
каждом сохранении объекта.
Тело
Очень часто поле форматированного текста автоматически доступно для
«тела» объекта, что бы это ни значило для конкретного типа. При этом
предполагается, что большинство объектов будут иметь поле Body
свободной формы, которое допустимо во многих случаях. Некоторые типы
этого не делают, и в этих системах обычно есть способ скрыть поля для
этих типов, когда это необходимо.
Тизер или резюме
Хотя это менее распространенное поле, чем поле «Тело», некоторые
системы предоставляют поле «Сводка» меньшего размера. Это довольно
часто встречается в системах, имеющих корни блогов, таких как WordPress.
Эти встроенные атрибуты, если они доступны, автоматически присутствуют во
всех типах, а ваша модель контента состоит из атрибутов, существующих в
дополнение к ним.
Проверка атрибута
Чтобы гарантировать, что информация введена правильно, ее необходимо
проверить, что означает ее отклонение, если она не имеет правильного формата
или значения для своей цели.
Базовая проверка осуществляется через тип данных. Если что-то должно быть
числом, то оно должно быть введено как действительное число. Кроме того,
интерфейс редактирования может обеспечить это, отображая только небольшое
текстовое поле, позволяющее вводить только числовые символы.
Однако тип данных не рассказывает всей истории. Что, если наше число
представляет собой всего лишь число по формату, но мы хотим, чтобы это
число было годом? Тогда нам потенциально потребуется проверить его
другими способами: по значению, шаблону или с помощью какого-либо
специального метода.
Мы можем проверять значения через диапазоны. В нашем примере с годом,
скорее всего, это должно быть четырехзначное положительное целое число (в
зависимости от того, разрешены ли мы даты до нашей эры или даты после 9999
года нашей эры), и оно, скорее всего, должно находиться в определенном
диапазоне. Например, мы можем потребовать, чтобы это было в прошлом или в
течение определенного определенного периода (например, от 100 лет в
прошлом до текущего года).Рисунок 6-4 показывает пример указания
допустимого диапазона для поля в Drupal.
Рисунок 6-4. Варианты числовой проверки в Drupal
В качестве альтернативы, возможно, мы храним единицу хранения продукта

(SKU) и знаем, что это всегда должен быть шаблон из трех букв, за которыми
следует тире и четыре цифры. Регулярное выражение (подробнее обсуждается
вГлава 8) из «[AZ]{3}-[0-9]{4}» может гарантировать, что мы принимаем
только данные, соответствующие этому шаблону.
Помимо простой проверки, иногда возникает необходимость проверить
вводимые данные посредством пользовательской интеграции. Возможно, наш
артикул продукта необходимо сверить с нашей базой данных продуктов, чтобы
убедиться в его существовании. В этом случае, когда редактор сохраняет
объект контента, CMS выполняет запрос к базе данных продуктов, чтобы
убедиться, что SKU продукта существует, и отклоняет контент, если его нет.
Запрос к базе данных продуктов — это требование, которое не требуется ни
одному другому пользователю вашей CMS, поэтому она явно не будет
поддерживать это «из коробки». Лучшее, что может сделать система, — это
предоставить вам возможность программировать ее с помощью API.
Значение, шаблон и пользовательские возможности проверки сильно
различаются. Если подходящие методы недоступны, единственное решение —
хорошо обучить редакторов и обеспечить корректную обработку ошибок, если
они введут что-то неправильно.
С использованием Атрибуты для РедакционныйМетаданные

Атрибуты обычно хранят информацию, которая либо отображается
потребителю информации, либо используется для непосредственного влияния
на представление контента. Однако существует обоснованный случай
использования атрибутов для хранения административной или «служебной»
Метаданныеозначает «данные о данных», что означает данные, которые не
являются основной целью объекта контента, но служат некоторой
второстепенной цели. Идея метаданных в управлении веб-контентом немного
абстрактна — системы обычно ничего не называют метаданными, а вместо
этого просто обрабатывают все атрибуты одинаково — но ее можно точно
использовать для ссылки на данные, которые не связаны с контентом.
непосредственно объект, а скорее касается управления этим объектом.
Например:
• Текстовый атрибут под названием To Do может использоваться для
создания заметок в стиле вики о том, что необходимо сделать с этим
контентом. Отчет может генерировать весь контент

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

Если типы контента — это просто оболочки наборов атрибутов, то из этого
следует, что мы должны создать новый тип контента для каждой возможной
комбинации атрибутов в нашей модели контента. Это имеет смысл, поскольку
в пресс-релизе используется принципиально другой набор информации, чем в
биографии сотрудника.
Но что, если два типа контента очень похожи? Часто у вас будет тип контента,
точно такой же, как другой тип, за исключением добавления одного или двух
дополнительных атрибутов.
Рассмотрим базовый тип контента страницы, который представляет собой
самый простой контент, который мы можем придумать, — базовую страницу с
форматированным текстом и заголовком. Он состоит ни из чего, кроме:
• Заголовок
• Тело
Как упоминалось ранее, зачастую это просто встроенные атрибуты.

Для нашего блога нам нужен другой тип публикации в блоге. Это
необходимо:
• Тело
• Краткое содержание
• Дата публикации
Вы видите сходство? Сообщение в блоге — это просто страница с двумя

дополнительными атрибутами. Вы можете сделать это для разных типов
контента. Например, тема справки может быть такой:
12 Однажды я читал об интранете, который использовал подобные атрибуты, чтобы «пристыдить»

владельцев контента. Если страница отображалась с датой проверки более 30 дней назад, вверху
страницы отображалось уведомление: «Боб Джонс несет ответственность за этот контент, но не
просматривал его в течение 14 месяцев. Свяжитесь с Бобом по номеру 1234, чтобы проверить, верен
ли этот контент».

Страница с добавлением версии программного обеспечения и ключевых слов.
Событие может представлять собой страницу с указанием даты начала и места.
Теперь предположим, что через некоторое время после запуска вашего сайта
ваш менеджер по маркетингу просит вас добавить SEO-описание ко всем
страницам сайта. Вы столкнулись с перспективой добавить еще один атрибут
ко всем типам вашей модели контента (а затем удалить его, когда менеджер по
маркетингу решит, что он ему больше не нужен).
Разве не было бы полезно, если бы вы могли наследовать определение атрибута
Page и просто указать, какие атрибуты доступны помимо него?
Таким образом, определением публикации в блоге будет «все, что есть на
странице, плюс краткое описание и дата публикации». Сделав это, вы
гарантируете, что при каждом изменении типа контента страницы (в данном
случае посредством добавления SEO-описания) тип публикации в блоге — и
все другие типы, унаследованные от страницы, — также будут
меняться.Рисунок 6-5 показывает, как это будет работать для наших примеров
типов контента.
Рисунок 6-5. Базовый тип страницы предоставляет заголовок и тело для каждого
типа, который его наследует: запись в блоге, событие и тема справки получают
заголовок и тело, а затем добавляют к ним определенныеатрибуты свои
Для объектно-ориентированного программиста это не новая

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

Что еще более редко, чем простое наследование, так это возможность
комбинировать несколько типов (или частичных типов) для создания нового
типа. Например, мы могли бы определить тип заголовка контента как:
• Субтитры
Имеет ли это смысл как отдельный тип? Вероятно, нет — какой контент имеет
только заголовок и подзаголовок? Однако, когда он определен как часть более
крупного типа, это имеет больше смысла. Многие типы могут использовать
заголовок и подзаголовок как часть своего определения.
С этой целью мы могли бы определить тело статьи как:
• Тело
• Подпись к изображению
И мы могли бы определить биографию автора как:
• Имя автора
• Биография автора
• Изображение автора
Затем мы могли бы определить тип статьи как просто комбинацию всех трех:
• Субтитры
• Тело
• Подпись к изображению
• Имя автора
• Биография автора
• Изображение автора
Рисунок 6-6 иллюстрирует идею частичной композиции типов.

Рисунок 6-6. Тип контента «Статья» состоит из трех частичных типов,
которые также можно использовать для создания других типов; любые
изменения частичного типа отражаются в любом типе, которыйиспользует его
Чем нам будет лучше в этой ситуации? Потому что мы можем повторно
использовать части для определения других типов. Например, мы могли бы
использовать наш тип заголовка контента в типе галереи изображений,
поскольку заголовок и подзаголовок являются общими как для него, так и для
статьи. Затем, если мы добавим что-то в заголовок контента, это будет
добавлено ко всем типам, использующим этот тип.13
Опять же, эта возможность встречается редко, но там, где она доступна, она
значительно повышает управляемость сложной модели контента.Рисунок 6-7
показывает, как можно добиться частичной композиции типов в Sitecore CMS.
13 Обратите внимание на использование слова «использовать», а не «наследовать». Вы можете «наследовать» от одного другого типа. Вы
«используете» несколько типов.
При составлении типов отношения являются составными, а не родительскими.

Рисунок 6-7. Состав нескольких типов в Sitecore — частичные типы (называемые
в этой системе «шаблонами») можно просматривать и выбирать на левой
панели, а затем добавлять на правую.панель для формирования типа,
состоящего из нескольких частичных типов
Встраивание контента
Некоторые системы допускают встраивание одного элемента контента в другой
элемент либо в форматированный текстовый контент, либо в структуры
данных, которые отображают списки ссылочного контента. Встроенный
контент часто называют «блоками» или «виджетами».14
Если следующее звучит очень расплывчато, так оно и есть. Это

очень изменчивый тип функциональности с несколькими
универсальными реализациями. Лучшее, что мы можем здесь
сделать, — это предоставить несколько примеров схожей
функциональности в попытке связать ее воедино.
Богатый текствстраивание
Рассмотрим проект, для которого требуется страница фотогалереи. Вы можете
легко смоделировать тип фотогалереи с заголовком, например, вводным
абзацем текста вверху (описание), и изображениями для галереи под ним.
Затем предположим, что редакторы говорят: «Ну, нам бы хотелось разместить
еще один абзац текста внизу страницы, под галереей». Вы можете справиться с
этим, изменив атрибут «Описание» на «Верхнее описание» и «Нижнее
описание», а затем изменив шаблон для отображения как над, так и под
галереей.
Вернемся к редакторам: «Теперь у нас есть ситуации, когда нам нужно более
одной галереи на странице».
14 Обратите внимание, что блоки или виджеты часто ссылаются на управляемый контент, но это не
обязательно. Они могут просто отображать на странице функции, не связанные с контентом,
например, прогноз погоды.
Что теперь?
Возможно, лучшим решением будет смоделировать тип «Фотогалерея» как
элемент, который можно встроить в форматированный текст. Это означает, что
фотогалерея больше не может быть страницей с URL-адресом, а скорее
встраиваемым элементом контента (опять же во многих случаях «блоком» или
«виджетом»), который заключен в страницу. Используя это, редакторы могли
записать свою страницу контента в виде форматированного текста и встроить в
нее объект этого типа контента (Рисунок 6-8).
Рисунок 6-8. Содержимое внедряется в форматированный текст путем

размещения ссылки или токена, идентифицирующего внедренный объект; во
время шаблонизации этот токен обнаруживается и заменяется
некоторымшаблонное представление внедренного объекта
Помимо включения того, что требуется редакторам для этого конкретного

экземпляра, это имеет еще два преимущества:
• Объекты фотогалереи можно использовать на нескольких страницах. Одна

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

сложных интерфейсов перетаскивания.
В WordPress, например, есть так называемые «короткие коды» — фрагменты
текста, обрабатываемые во время вывода. Например:
[photo_galleryfolder="images/2015-christmas-party"]
Этот код можно сопоставить с функцией PHP, которая отображает все
изображения из указанного каталога. Очевидно, что это не объект
управляемого контента; это просто функция PHP, сопоставленная с текстовой
строкой. «Содержимое» — это просто каталог изображений в файловой
системе.
Если вам нужен более жесткий контроль над галереей, вы можете
смоделировать ее как тип контента, а затем использовать шорткод для ссылки
на идентификатор этого контента:
[photo_gallery id="1234"]
Соответствующая функция PHP получит объект контента № 1234 и будет
использовать данные для отображения фотогалереи.
Некоторые системы заходят так далеко, что создают HTML-подобный
синтаксис, который позволяет редакторам писать встроенную разметку. Плагин
Articles Anywhere дляДжумла!, например, предоставляет такой синтаксис для
встраивания трех последних статей из определенной категории (категория № 9
в этом примере):
{категория статей: 1-3: 9}
{заголовок}
{текст: 20 слов: полоска}
{подробнее:Подробнее...|читать}
{/статьи}
Эта разметка обнаруживается и обрабатывается во время вывода.
Очевидно, что такой уровень разметки создает проблемы с

обучением. Редакторам необходимо будет понимать все
доступные им варианты и, вероятно, им понадобится доступ к
некоторым типам справочных материалов.
Платформа eZ использует структуру под названием Custom Tags, которая

позволяет встраивать данные через проверенную форму. ВидетьРисунок 6-9
для примера встраивания значков социальных сетей между двумя абзацами в
тексте форматированного текста. Хотя это внедрение не использует никакого
контента, подумайте о моделировании контента, которого мы могли бы
избежать, используя эту функцию. Если бы не этот метод, тип контента,
возможно, пришлось бы моделировать с помощью атрибутов «Показать значок
Twitter», «Показать значок YouTube» и т. д. И даже тогда, как бы автор указал,
где на странице их следует встроить?
Рисунок 6-9. Встраивание пользовательских тегов в eZ Platform: данные из
формы инкапсулируются.указывается в пользовательском теге, встроенном
между двумя абзацами
Меньшее количество систем предоставляют графические интерфейсы для

встраивания контента (см.Рисунок 6-10). Содержимое можно создать, а затем
перетащить в редакторы форматированного текста для размещения.
Рисунок 6-10. Пользовательский блок фотогалереи, перетаскиваемый между

абзацами в Episerv‐редактор WYSIWYG пользователя — это управляемый
объект контента, который будет отображаться как фотогалерея во время
вывода контента.
Блоки, виджеты и регионы

Блоки или виджеты иногда могут быть объединены в структуры, которые мы
будем называть списками. Эти списки содержат один или несколько элементов,
которые отображаются индивидуально сверху вниз в определенных местах
шаблона.
Типы контента могут иметь списки элементов в качестве атрибутов, а шаблон
может иметь «области» или «зоны перетаскивания», в которые можно
добавлять или удалять элементы. Эти регионы могут быть специфичными для
контента («Правая боковая панель для контента № 1234») или глобальными
(нижний колонтитул всего сайта).
Например, Episerver позволит использовать тип атрибута «Область
содержимого» (см.Рисунок 7-6 вГлава 7). Это позволяет «складывать»
элементы контента внутри него. Таким образом, атрибут Right Sidebar Content
может позволить редакторам добавлять различные элементы контента, которые
затем отображаются в указанном месте шаблона типа контента.
Drupal имеет обширную функциональность для «блоков», которые можно
добавлять в регионы шаблона. Аналогично, WordPress предлагает «виджеты»,
которые можно размещать в определенных областях шаблона (см.Рисунок 6-
11).
Рисунок 6-11. Список виджетов, размещенных в области шаблона под названием

«Боковая панель» в Wordpress. Порядок виджетов можно изменить по желанию.
Подразумеваемое для страницасостав

Оба метода внедрения позволяют создавать динамическую композицию
страницы. Можно представить себе редакторов как художников, рисующих на
холсте из палитры вариантов элементов.
Идея соблазнительная. Вспомните наш пример с фотогалереей ранее: мы
значительно увеличили полезность этого контента, превратив его во
встраиваемый объект. Вместо того, чтобы быть «пунктом назначения», он стал
контентом, который теперь поддерживает и обогащает другой контент.
Так почему бы нам не сделать это для всего? Мы могли бы создать один
главный тип страницы, а все остальные типы контента могли бы быть
встраиваемыми типами, которые входили бы в ее регионы.
— либо списки, либо форматированный текст.
Подобные системы существуют. У них часто есть простые страницы с URL-
адресом, которые представляют собой не что иное, как набор списков или зон
сброса, к которым добавляются блоки или виджеты.

Другие системы рассматривают страницы почти как папки, содержащие
отдельные элементы контента, назначенные областям шаблона — страница —
это просто контейнер отдельных элементов контента, которые закольцованы, и
каждый элемент отображается индивидуально, образуя страницу.
Хотя на первый взгляд это кажется в конечном итоге гибким, в больших
масштабах, похоже, оно никогда не работает так хорошо, как можно было бы
надеяться.
Во-первых, эта парадигма вводит больше шагов в редакционный процесс. Если
вы хотите опубликовать сообщение в блоге, теперь вам нужно создать
страницу, затем найти тип контента «Сообщение в блоге» и поместить его на
страницу. Чтобы обойти эту проблему, некоторые из этих систем реализуют
шаблоны или даже макросы, которые автоматически предоставляют часто
используемые комбинации страниц и виджетов.
Независимо от того, как началась страница, эта модель также позволяет
редакторам иметь эстетический контроль над страницей, который, возможно,
не был предназначен для этого. Если наш макрос или шаблон по умолчанию
разместил виджет «Похожий контент» на боковой панели, может ли редактор
удалить его?
Дело в том, что большая часть контента была просто создана по шаблонам.
Если на вашем веб-сайте размещено 10 000 технических заметок, вы, скорее
всего, не захотите, чтобы редакторы имели какой-либо контроль над их
представлением. Разрешение редакторам изменять макет страницы для одного
из них по прихоти — это проблема управления, которая только и ждет своего
часа.
Кроме того, встроенный контент не так легко доступен, как другой контент,
среди прочего, из-за отсутствия URL-адресации. Что, если мы захотим
отправить ссылку на нашу фотогалерею? Помните, это не страница, это просто
встроено в страницу. И помните также, что оно может быть размещено на 100
страницах, так какая из них является для него канонической? Вы можете
сказать, что мы просто поместим его на одну страницу и укажем, что это
единственная страница, на которой он появляется, но тогда возникает вопрос,
является ли это вообще отдельным объектом контента. Когда виджет
безвозвратно привязан к одному контейнеру, является ли он действительно
виджетом или просто частью модели этого типа?
Это также усложняет API и миграцию контента. Содержимое теперь скрыто на
один или несколько уровней в другой конструкции. Связь виджетов с
областями (и их порядковым номером), а затем, наконец, со страницами — это
то, что необходимо учитывать при каждом манипулировании контентом из
кода.
Наконец, он поднимает несколько интересных логических вопросов о
взаимосвязи между содержанием и представлением. Если редактор
перетаскивает определенный виджет на страницу, имеет ли этот виджет какое-
либо отношение к самому контенту или он связан со страницей, на которую
встроен контент? Содержит ли объект новостной статьи этот виджет или сама
страница является объектом более высокого уровня, содержащим и новостную
статью, и виджет?

Виджет, который сообщает мне текущую температуру, может быть полезен, но
имеет ли он какое-либо отношение к новостной статье на той же странице,
представляющей нового генерального директора? Нужно ли управлять ею в
том же логическом «пространстве», что и новостную статью? Если я удалю
статью, что произойдет с виджетом? Нужно ли одному заботиться о другом или
даже знать о нем? Является ли их появление на одной странице просто
случайным?
Сравните это с виджетом, в котором отображается дополнительная
информация о новом генеральном директоре. Можно утверждать, что это имеет
логическую связь с новостной статьей, поэтому должно быть каким-то образом
связано с ней. Таким образом, наш виджет «Похожий контент» связан с
контентом, а не со страницей.
На практике кустарная компоновка страниц менее необходима, чем вы думаете,
и это далеко не панацея, на которую вы могли бы надеяться. Если эта идея вам
нравится, правильным решением, скорее всего, будет система, которая
предлагает возможность компоновать страницы в порядке исключения, когда
это необходимо, но поддерживает надежное моделирование контента и
шаблоны в качестве своей основной предполагаемой архитектуры.
Горизонтальный против. ВертикальныйУкладка

Веб-страницы естественным образом движутся сверху вниз.
Жесткое ограничение высоты веб-страницы редко бывает, и
два десятилетия опыта работы в Интернете научили нас тому,
что элементы — абзацы, изображения, таблицы и т. д. — могут
располагаться вертикально без ограничений.
Горизонтальная укладка — это не то же самое. Горизонтально
расположенные элементы обычно необходимо группировать в
контейнере, где ширина или количество элементов ограничены
— «половинная ширина», «3 ширины» или «60/40». Возможно,
также потребуется указать ширину элементов внутри
контейнера — например, занимают ли они один столбец или
два столбца — иначе они будут перенесены неправильно.
Как правило, вертикальное штабелирование является простым
и не вызывает никаких сложностей. Горизонтальная укладка
гораздо менее эффективна.
Отношения
Содержание моделирования бывает двух основных разновидностей:
Дискретный
Описание типа внутреннего контента
Реляционный
Описание типа контента по тому, как он соотносится с другим контентом.
В нашем примере с биографией сотрудника есть обе разновидности. Такие
атрибуты, как имя и фамилия, относятся только к одному объекту контента.
Тот факт, что имя одного человека
Отношения |1 0 3
«Джо Смит» не имеет никакого отношения к какому-либо другому контенту.
Это дискретные, автономные данные этого контента.
Однако атрибут Manager является ссылкой на другой объект контента, что
означает, что он реляционный или определяет, как объект контента
«относится» к другому объекту контента.
Рисунок 6-12 показан пример реляционного моделирования в Episerver, где
свойство под названием «Ссылка на страницу» позволяет редакторам выбирать
другую страницу в CMS в качестве целевой.
Рисунок 6-12. Атрибут может быть ссылкой на другой объект контента.
Реляционное моделирование контента открывает ряд новых задач. Снова

рассмотрим атрибут Manager:
• Вы должны убедиться, что объект контента, на который ссылается этот

атрибут, является другой биографией сотрудника, а не, например,
страницей «Свяжитесь с нами».
• Может ли у сотрудника быть несколько руководителей? Конечно, это
крайний случай, но если это произойдет, вам придется либо игнорировать
это, либо изменить модель, чтобы приспособить ее. Это означает, что ваш
атрибут Manager должен иметь возможность хранить несколько значений.
• Как убедиться, что ссылка действительна? Что, если кто-то удалит объект
Manager? Готовы ли вы справиться с сотрудником без менеджера?
• Как разрешить редакторам работать с этим атрибутом? Поскольку это
ссылка, вашим редакторам, скорее всего, придется искать другого
сотрудника, чтобы указать его, что может усложнить интерфейс.
Высокореляционные модели контента могут быть очень сложными и во

многом зависят от возможностей CMS. Спектр возможностей в этом плане
широк. Небольшое подмножество CMS хорошо справляется с реляционным
моделированием, и реляционная сложность вашей запланированной модели
контента может и должна оказать существенное влияние на выбор вашей CMS.
Мы обсудим реляционное моделирование более подробно вГлава 7.
Состав контента
Некоторый контент не прост, и его лучше всего моделировать как группу
объектов контента, работающих вместе в структуре. Таким образом,
логический фрагмент контента состоит из нескольких объектов контента.
Классическим примером может быть журнал. У нас есть тип контента
«Проблема», но он состоит из следующего:
• Одна избранная статья

• Несколько других статей
Мы могли бы поддержать это, присвоив нашему типу контента «Проблема» следующие

атрибуты:
• Рекомендованная статья (ссылка на статью)

• Статьи (ссылка на несколько статей)
Мы можем создавать наши статьи как отдельные объекты контента, а проблема

— это, по сути, просто коллекция («агрегат») статей в определенной структуре.
Наш выпуск содержит очень мало собственной информации (например, он
может иметь один атрибут для даты публикации и, возможно, еще один для
изображения обложки) и существует исключительно для организации
нескольких статей в единое целое.
Это надуманный пример. Гораздо более распространенный пример требует
агрегирования контента в «географической» структуре, о которой мы
поговорим в следующем разделе.Глава 7.
Содержание МодельУправляемость
Любая модель контента — это баланс между сложностью, гибкостью и
полнотой. У вас может возникнуть соблазн учесть каждую возможную
ситуацию, но это почти всегда будет иметь побочный эффект в виде
ограничения гибкости или увеличения сложности.
Например, при работе с типами контента редакторы должны иметь
возможность понимать различные доступные типы, чем они отличаются и
когда использовать один вместо другого. В некоторых ситуациях может иметь
смысл объединить два типа для простоты и просто учесть различия в
представлении.
Может ли тип контента «Страница» использоваться в качестве публикации в
блоге? Если на странице также есть поля «Сводка», «Автор» и «Дата
публикации», не проще ли просто отображать их в шаблоне только тогда, когда
они заполнены? Если Страница создана внутри типа контента «Сообщение в
блоге», можем ли мы рассматривать эту страницу как сообщение в блоге и
предоставить редакторам на один тип меньше, который нужно понимать?
Упростит это или усложнит задачу, зависит от ситуации и редакторов. Если
они часто работают с CMS для создания очень требовательного контента, то им
могут быть полезны два отдельных типа. Если они создают контент настолько
редко, что их почти каждый раз приходится переобучать, то лучше
использовать один тип.
Если у вас нет возможности наследовать типы контента, то в ваших интересах
ограничить типы контента настолько, насколько это разумно. Имея модель
контента с 50 различными
Управляемость модели контента | 105

типами становится очень сложно управлять, когда кто-то хочет внести
изменения в масштабе модели.
Трудно сформулировать общие правила в отношении управляемости, но
ограничение типов контента до необходимого минимума обычно является
хорошей идеей. Больше типов означает больше обучения редакторов, больше
шаблонов и повышенную вероятность необходимости переключения типов
после создания (что, как мы видели ранее, является проблематичным).
Лучшее, что вы можете сделать, — это помнить об управляемости при
создании или настройке модели. Изучите каждый запрос и требование с точки
зрения того, как это повлияет на модель с течением времени. Почти каждое
изменение увеличивает сложность модели, и стоит ли оно того?
Перспектива: моделирование контента — редакционная проблема

Сара Вахтер-Беттчер
Моя любовь к моделированию контента началась еще в
2009 году, когда я руководил практикой контент-стратегии
в агентстве, работавшем над государственным
туристическим веб-сайтом Аризоны. Только сначала я не
знал, как это назвать. Я просто хотел, чтобы контент
работал на реальных людей.
Если вы планировали отправиться в поход во Флагстафф,
вам не хотелось бы просто узнать о походах или просто
узнать о Флагстаффе. Вы хотели бы узнать о походах возле
Флагстаффа. Если вы
Если вы проводите выходные в Тусоне, вам не захочется просматривать тысячи
списков мероприятий со всего штата. Вы хотели бы знать, что происходило, где
и когда вы будете в гостях. Но ничего из этого было невозможно. Несмотря на
наличие тысяч статей, руководств, списков, событий и другого контента
(большая часть которого действительно хороша), все на сайте было
разрозненным, каждый элемент представлял собой островок информации.
До этого проекта я не особо занимался системами управления контентом, на
которых работают наши сайты. Конечно, я знал, как ими пользоваться: как
правильно форматировать текст и удалять всякую ерунду; Я знал, как
управлять версиями и говорить о рабочем процессе. Но как решить, как
структурировать и планировать саму CMS? Я всегда предполагал, что это
работа наших разработчиков.
Просматривая весь этот контент, группируя элементы, рисуя стрелки и
устанавливая таксономии, я понял, что ни один разработчик не может создать
лучшие модели контента в одиночку. Чтобы распознать закономерности и
убедиться, что фрагменты контента имеют смысл, а не просто модульность,
требуются редакционные навыки. Требуется опыт UX, чтобы определить, какие
связи между контентом будут наиболее ценными для пользователей и когда. И
чтобы решить, какие структуры контента и отношения помогут вашей
организации достичь своих целей, необходим стратегический подход.
Сегодня я рассматриваю моделирование контента как основной набор навыков
для всех практиков. Потому что
Чем больше команда глубоко задумывается о том, из чего состоит ее контент и
почему, тем лучшие решения мы будем принимать на каждом этапе: дизайн,
разработка CMS, миграция и многое другое.
Сара Вахтер-Бетчер руководит консалтинговой компанией по контент-
стратегии и является авторомContent Everywhere (Rosenfeld Media) и соавтор
книги «Дизайн для реальной жизни» (A Book Apart).
Краткое изложение моделирования контентаФункции

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

Насколько это соответствует вашим требованиям?
• Насколько эта модель может быть кастомизирована?
• Допускает ли система несколько типов?
• Разрешает ли система наследование типов контента? Допускает ли это
множественное наследование?
• Позволяет ли система типизировать данные атрибутов?
• Какие типы данных доступны для добавления атрибутов к типам?
• Какие значения, шаблоны и пользовательские методы проверки доступны?
• Можете ли вы добавить в систему собственные типы данных в
соответствии с вашими конкретными требованиями?
• Допускает ли система несколько значений атрибутов?
• Какие редакционные интерфейсы доступны для каждого типа данных?
• Позволяет ли система атрибуту быть ссылкой на другой объект контента?
Может ли ссылка относиться к нескольким объектам? Может ли оно быть
ограничено только объектами определенного типа?
• Какие параметры доступны для встраивания контента и композиции страниц?
• Предоставляет ли система разрешения на основе типов?
• Позволяет ли система создавать шаблоны на основе типов?
• Насколько близко эта система может подойти к (обычно недостижимому)
идеалу собственной реляционной базы данных?
Краткое изложение функций моделирования контента |1 0 7

Примечание о списках функций
Мы обсуждали это вГлава 5, но стоит повторить:
Оценивая этот список (и любой другой список функций в этой книге), помните,
что цель состоит не в том, чтобы просто отметить каждый пункт в списке по
трем причинам:
• Сомнительно, что какая-либо система будет обеспечивать все функции.

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

ГЛАВА7
Агрегация контента
В своей книге «Почему информация растет: эволюция порядка: от атомов к

экономике»1 Сезар Идальго обсуждает суперкар: Bugatti Veyron.
Автор подсчитал, что Bugatti, стартовая цена которого составляет 2,5 миллиона
долларов, стоит 600 долларов за фунт. Это немного больше, чем 10 долларов за
фунт Hyundai или даже 60 долларов за фунт BMW.
А теперь представьте, что вы врезались Bugatti в стену на скорости 100 миль в
час. Если предположить, что вы выжили в аварии и затем собрали все остатки
машины, она все равно будет весить так же, как и в момент, когда она
врезалась в стену. Но он уже не будет стоить почти 600 долларов за фунт. Это
та же сталь, резина и стекло, что и были, только в другой форме.
Вот ключ:
Долларовая стоимость автомобиля испарилась за те секунды, которые
потребовались вам, чтобы врезаться им в стену, но его вес не изменился. Так
куда же делась ценность? В результате аварии долларовая стоимость
автомобиля испарилась не потому, что авария разрушила атомы, из которых
состоял Bugatti, а потому, что авария изменила способ расположения этих
частей. Поскольку детали, из которых состоял Bugatti, были разобраны и
скручены, информация, воплощенная в Bugatti, была в значительной степени
уничтожена.
Последнее предложение является ключевым: ценность Bugatti заключалась не в
сырье для автомобиля, а в том, как эти материалы были расположены и
заказаны. Ценность создается путем объединения мелких частей в единое
целое. Выбор, сочетание и упорядочение деталей более ценны, чем сами
детали.
1 Почему информация растет: эволюция порядка: от атома к экономике Сезара Идальго (Basic Books).
109
Аналогично, контент часто становится более ценным в сочетании с другим
контентом. Эти комбинации называются агрегатами. В некотором смысле
совокупность контента сама становится контентом. «Содержимое» в данном
случае заключается в выборе, сочетании и упорядочении более мелких
элементов контента, которые собираются вместе и образуют новое целое.
Агрегация контента — это способность CMS группировать контент. Обратите
внимание, что мы не слишком конкретны: существует множество типов
агрегаций и множество способов, с помощью которых CMS может это сделать.
Более того, эта способность настолько очевидна, что ее можно воспринимать
как нечто само собой разумеющееся. Мы склонны просто предполагать, что
каждая CMS делает это в той степени, которая нам нужна.
Например:
• Отображение навигационных ссылок — это агрегирование. В какой-то

момент вам нужно указать вашей CMS отображать серию страниц в
определенном порядке, чтобы сформировать верхнее меню каждой
страницы (статическое агрегирование, которое упорядочивается вручную).
• Страницы индекса представляют собой агрегаты. Страница, на которой
перечислены ваши последние пресс-релизы (Рисунок 7-1) часто
представляет собой просто стандартный поиск по определенному типу
контента, ограниченный примерно 10 первыми и отображаемый в
хронологическом порядке по убыванию (динамическое агрегирование с
производным порядком).
• Поиск — это агрегирование. Когда пользователь вводит поисковый запрос
и получает результаты, это группировка определенного контента
(динамическая агрегация переменных).
Рисунок 7-1. Совокупность пресс-релизов на веб-сайте IBM по состоянию на декабрь 2014 г.

110 | Глава 7: Агрегация контента
Агрегация является настолько важной частью большинства систем, что ее
часто даже не выделяют как отдельную подсистему или дисциплину. Но
диапазон функциональности в этом плане широк, и сбои в этой области крайне
расстраивают.
Нет ничего более раздражающего, чем наличие нужного контента, но
невозможность получить его в нужном формате. Работая с несколькими
системами, я сталкивался с многочисленными ситуациями, когда редакторы в
отчаянии разводили руками и говорили: «Все, что я хочу, — это чтобы этот
контент появился в этом месте!» Почему это так сложно!?"
Ответ на этот вопрос заключается в сложном пересечении формы контента,
функциональности агрегирования и удобства использования.
Форма контента
Форма контента относится к общим характеристикам модели контента, если
рассматривать их в совокупности и сравнивать с моделями использования
потребителей вашего контента. Различные шаблоны и модели использования
приводят к явным различиям между контентом и требованиями к его
агрегированию. Контент может быть:
Серийный
Этот тип контента организован в виде последовательной «строки»,
упорядоченной по некоторому параметру. Очевидным примером является
блог, который представляет собой агрегацию постов в обратном
хронологическом порядке. Очень похоже на это обновления в социальных
сетях — например, поток твитов.
— или ленту новостей. Этот контент не обязательно должен быть
организован в какую-либо более крупную конструкцию, кроме того, где он
расположен в хронологическом порядке относительно другого контента.
Глоссарий также можно считать серийным изданием — это простой список
терминов, упорядоченных по названиям в алфавитном порядке.
Иерархический
Этот тип контента организован в виде дерева. В дереве есть корневой
объект содержимого, имеющий несколько дочерних элементов, каждый из
которых сам может иметь одного или более дочерних элементов и так
далее. Одноуровневые элементы контента (элементы одного родителя)
могут иметь произвольный порядок. Деревья могут быть широкими (много
дочерних элементов под каждым родителем), узкими (меньше дочерних
элементов), мелкими (меньше уровней) или глубокими (больше уровней).
Примером этого являются основные страницы многих простых
информационных веб-сайтов. Веб-сайты обычно организованы в виде
деревьев: есть основная навигация («Продукты», «О нас», «Контакты»),
которая ведет к вторичной навигации (Продукт А, Продукт Б и т. д.).
Навигационные агрегаты для этих сайтов часто можно получить на основе
положения объектов контента в дереве.
Форма контента |1 1 1
Табличный2
Этот тип контента имеет четко определенную структуру одного
доминирующего типа и обычно оптимизирован для поиска, а не просмотра.
Представьте себе большую электронную таблицу Excel с помеченными
столбцами заголовков и тысячами строк. Примером может служить база
данных местоположений компаний. Там может быть 1000 мест, четко
организованных в столбцы (адрес, город, штат, номер телефона, часы
работы и т. д.). Пользователи не будут просматривать эту информацию.
Скорее, они ищут его по параметрам.
Сеть
Этот тип контента не имеет более крупной структуры, кроме связей между
отдельными объектами контента. Весь контент является равным, плоским и
неупорядоченным по отношению к другому контенту, и нет ничего, кроме
связей между контентом, связывающих его вместе. Очевидным примером
этого является Wiki. Вики-страницы не имеют структуры (некоторые
допускают иерархическую организацию страниц, но большинство — нет),
и весь контент удерживается вместе только за счет связей между
страницами. Социальная сеть, если ею управлять как контентом, может
быть еще одним примером. Контент («люди») равноправен в сети и
произвольно связан («друзья») с другим контентом.
Этот тип контента имеет четко определенные структурные отношения
между несколькими высокоструктурированными типами контента, подобно
типичной реляционной базе данных. В базе данных фильмов в Интернете,
например, есть фильмы, в которых есть один или несколько актеров, ноль
или более сиквелов, ноль или более элементов викторины и т. д. Эти связи
обязательны — например, вы не можете добавить элемент викторины для
фильма, который не имеет не существует. Элемент викторины должен быть
связан с фильмом и не может быть добавлен, пока фильм не существует.
Различные CMS имеют разные уровни возможностей обработки различных
форм контента. Например:
• WordPress хорошо подходит для управления последовательным контентом

(сообщениями в блогах), но с его помощью невозможно легко запустить
высокоиерархическую базу данных справочных разделов.
• MediaWiki предназначен для обработки сетевого контента, но было бы
крайне неэффективно пытаться вести с его помощью блог.
• Webnodes идеально подходит для определения и управления табличным и
реляционным контентом. Интересно, что это также дает ему возможность
хорошо управлять последовательным контентом (блог — это, по сути,
таблица базы данных, упорядоченная по полю даты), но не имеет смысла
2 «Табличный» означает наличие характеристик таблиц, а не вкладок.

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

правда в том, что разные разделы одного и того же веб-сайта моделируют
контент по-разному. Среднестатистический корпоративный веб-сайт может
иметь множество маркетинговых страниц, организованных в виде дерева
(иерархически), списка дилеров (табличного) и ленты новостей
(последовательного). Содержимое, управляемое в каждом разделе, имеет
разную форму.
Кроме того, когда мы говорим, что конкретная система не подходит для
определенной формы контента, мы имеем в виду, что эта система не лучше
всего подходит для работы с этой формой контента. Важно отметить, что
практически любую систему можно настроить для работы с любым типом
контента, хотя это либо требует героических усилий по разработке, либо
приводит к очень сложному и запутанному процессу редактирования (часто и
то, и другое).
Большинство основных CMS идут по середине пути. Обычно они особенно
хорошо подходят для одной или нескольких из перечисленных фигур, но
имеют некоторую способность обрабатывать любую из них.
Форма контента |1 1 3
География контента
Почти каждая система имеет какой-то основной метод организации контента.
Очень редко редакторы просто бросают контент в большую корзину — обычно
контент где-то создается, а это значит, что он существует в определенном
месте относительно другого контента.
Подобно тому, как география относится к пространственным отношениям
стран, география контента относится к пространственной природе контента –
где он существует «в пространстве» или как он организован относительно
контента «вокруг» него.
Цитаты в последнем абзаце подчеркивают идею о том, что мы пытаемся
придать некую физическую характеристику абстрактному понятию. География
пытается рассматривать контент как физическую вещь, которая существует в
каком-то месте теоретического пространства, представляющего область всего
вашего контента.
Наиболее распространенным примером географии является «дерево контента»,
где контент организован как родительская/дочерняя структура (см.Рисунок 7-
3). Все объекты контента могут быть родительскими для одного или
нескольких других объектов контента. Кроме того, у каждого объекта есть свой
родительский и дочерние элементы (если только это не корневой объект, что
означает, что он находится на самой вершине дерева).
Рисунок 7-3. Типичное дерево контента на веб-сайте на платформе eZ.
В этом смысле весь контент создается в каком-то месте. Вы добавляете контент

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

В географии дерева контента контент часто обсуждается с точки зрения
«уровней». Наиболее важными страницами вашего сайта являются страницы
верхнего или первого уровня. Под этим у нас есть страницы второго уровня,
затем страницы третьего уровня.
The ГлобальныйДерево
Иерархическое дерево — это естественный способ
организации информации для людей, поскольку оно имеет
тенденцию отражать то, как мы думаем об информации и
работаем с ней — настолько, что некоторые системы
используют дерево глобально, а не только для контента. Эти
системы хранят все в виде дерева, при этом содержимое веб-
сайта представляет собой всего лишь один узел. Пользователи,
группы, шаблоны, настройки, даже иногда вплоть до надписей
кнопок в редакторах форматированного текста — все это
хранится в виде объектов в дереве, и доступ ко всем данным
осуществляется через один и тот же API. ВидетьРисунок 7-4
для примера из Sitecore.
Рисунок 7-4. Пример глобального дерева от Sitecore — эта система хранит почти
каждый битданных в древовидной структуре, включая шаблоны и настройки
системы
Менее распространенной является структура папок для организации контента.

Системы, использующие эту модель, имеют «папки», в которые можно
поместить контент, подобно файлам в операционной системе.
Это может показаться очень похожим на дерево контента, поскольку оно
иерархично, но есть важное отличие: папка сама по себе не является объектом
контента. Это просто административная структура, которую редакторы могут
использовать для организации своего контента. Объекты контента не являются
дочерними объектами других объектов контента и не имеют дочерних
элементов. Вместо этого у нас есть папки и подпапки, в которых размещаются
объекты контента.
Хотя эта структура в целом ясна для редакторов — мы годами используем
файлы и папки в каждой операционной системе — на практике она может быть
ограничена. Невозможность напрямую связать контент по происхождению
лишает его ценного инструмента для агрегирования контента.
География контента |1 1 5
Если у страницы не может быть дочерних элементов, то нам придется найти
другой способ связать эти страницы вместе. Единственное содержимое
пространственных отношений в этих системах — это родственные отношения с
содержимым в той же папке. (Что усложняет ситуацию, так это то, что папки
часто рассматриваются как простые сегменты, которые не позволяют
произвольно упорядочивать содержимое внутри них — подробнее об этом
позже в этой главе.)
Другие системы могут зависеть от простой модели разделения типов контента,
в которой тип контента определенной части контента является основным
географическим регионом.3 Вы можете легко разделить весь домен контента по
типу контента и, возможно, по некоторым другим параметрам, но иногда не
более того. Например, мы можем легко просмотреть все выпуски новостей, но
мы не создаем контент в каком-то конкретном месте, и он не существует в
пространственном отношении к какому-либо другому контенту.Рисунок 7-5
показывает инструменты разделения типов в Drupal.
Рисунок 7-5. Перечисление контента по типу в Drupal
Как и структура папок, это может значительно ограничить наши возможности,

но во многих случаях может быть уместным. Например, если ваш веб-сайт
представляет собой блог большого объема, вашим редакторам, возможно, не
придется «размещать» свой контент где-либо. Возможно, им просто нужно
создать публикацию в блоге или обзор фильма и позволить системе самой
разобраться, как ее организовать. В таких ситуациях редакторы создают
серийный, изолированный контент, который не нуждается в каких-либо
пространственных отношениях (или, скорее, его пространственное отношение
к другому контенту автоматически определяется по дате).
Важно понимать, что география контента — это просто основной метод
организации, который демонстрирует система. Системы обычно предлагают
несколько способов агрегирования контента,
3 Это почти можно рассматривать как отсутствие какой-либо географии, поскольку поиск по типу не
подразумевает какой-либо пространственной связи с контентом. Тем не менее, он довольно
распространен в качестве основного метода организации.

поэтому, когда основная география не соответствует требованиям, обычно
существует несколько путей достижения желаемого агрегирования.
Географическая предвзятость
Как я уже упоминал, в колледже я был большим поклонником Джеймса Бонда.
На заре Интернета я часами проводил в группе Usenet alt.fan.james-bond,
обсуждая одну из самых распространенных тем для поклонников Бонда: кто из
актеров лучше всего справился бы с этой ролью? 4 Эти дебаты часто сводились
к следующему: первый актер, которого вы когда-либо видели в роли агента
007, вероятно, ваш любимый.
То же самое и с географией. Первый стиль географии, с которым вы работали,
часто воспринимается как «правильный» способ организации контента. Это
важно, потому что географическое положение системы абсолютно определяет
то, как с ней работают разработчики и редакторы. География играет огромную
роль в формировании концептуальной модели системы и ее содержания.
Большую часть своей карьеры я провёл, работая с системами с сильными
деревьями контента. Таким образом, мои мысли о CMS развивались вокруг
организации контента в иерархию. По сей день Drupal в этом отношении меня
озадачивает. Я понимаю, что он чрезвычайно популярен и имеет тысячи
приверженцев, но я борюсь со всем, что не имеет в своей основе дерева
контента. Я открыто признаю, что это просто предвзятость, вытекающая из
большей части моего профессионального опыта.
Разрушить подобные предубеждения может быть сложно. Из-за этого
интеграторы могут испытывать трудности при переходе с одной платформы на
другую. Они часто пытаются принудительно вписать новую платформу в
старую парадигму, с которой им комфортно, и это редко срабатывает хорошо.
Редакционный Ограничения наГеография

Если редакторы намеренно «размещают» контент в определенном месте в
географическом регионе, это может быть не идеально. Как мы обсуждали
вГлава 4, существуют разные способы ограничения возможностей редакторов.
Есть некоторые редакторы, которые имеют ограниченные обязанности и могут
создавать только определенные типы контента, которые могут вписаться в
географию одним строго контролируемым способом. В этих случаях вы можете
ограничить их разрешениями, но вместо этого вы можете создать очень
простой интерфейс для работы этих редакторов с контентом.
Например, администратор, который управляет обеденным меню в вашей
интрасети, может видеть только простое текстовое поле, позволяющее ему
ввести текст для меню на следующий день.
4 Для справки, это был Тимоти Далтон. Это было окончательно и окончательно решено на всю
вечность и теперь является просто неоспоримым фактом. Если кто-то не согласен, покажите ему эту
сноску и медленно отступите.
За кулисами этот интерфейс размещает контент в правильном месте
относительно более широкой географии, при этом редактор не знает об этом и
не может каким-либо образом на него повлиять.
Вторичные географические регионы: категории, таксономии,

теги, списки, коллекции и меню.
Когда мы говорим о географии контента, мы обычно говорим об основном
способе организации контента CMS. Однако во многих системах есть
дополнительные способы группировки контента, которые могут быть
достаточно распространенными, чтобы их можно было считать
второстепенными географическими объектами.
Многие системы имеют явное меню, что означает наличие подсистем меню, в
которых вы создаете организационные структуры и назначаете им контент.
Системы меню, как правило, очень практичны, поскольку в какой-то момент
им приходится напрямую генерировать структуру HTML. Они не столько
посвящены чистому контенту, сколько предоставлению интерфейса для
создания определенного фрагмента HTML. Таким образом, вы можете
назначить контент меню, но вы также обычно назначаете внешние URL-адреса,
а иногда даже указываете презентационную информацию, например, открывать
ли ссылку в новом окне или использовать изображение вместо текста. Иногда
вы даже доходите до классов CSS и других деталей.
Меню почти всегда иерархичны. Это приводит к иногда странной ситуации,
когда имеется несколько деревьев. Если ваша система использует дерево
контента в качестве основной географии, у вас могут быть меню, в которых
отношения обратные. Объект B может быть дочерним объектом объекта A в
реальном дереве контента, но объект A может быть дочерним объектом
объекта B в одном или нескольких деревьях меню. Это может быть либо
удобно, либо сбивать с толку, в зависимости от ситуации.
Некоторые системы имеют плоские структуры, которые они называют
списками или коллекциями. Это просто упорядоченные списки контента,
которые можно использовать десятками способов для объединения контента на
веб-сайте. (Конечно, одноуровневое меню, в котором элементы верхнего
уровня не имеют дочерних элементов, по сути, выполняет то же самое.)
Категории, таксономии и теги — другие популярные способы организации
контента. Объекты контента могут быть назначены категории или тегу, что
придает им некоторую связь с другим контентом в этой категории или теге,
подобно контенту в папке или дочернему контенту родительского элемента.
Отношения в этих вторичных структурах не обязательно должны иметь какое-
либо сходство с тем, как контент организован в первичной структуре.
Редакторам может быть проще организовать или связать контент таким
образом, и существует множество способов использовать эти дополнительные
географические регионы для отображения контента конечному пользователю.
Есть ли разница между категориями и тегами?
Если вы реализуете и категории, и теги на одном веб-сайте,
убедитесь, что вы четко разграничиваете их использование.
Логическая архитектура этих двух методов одинакова: контент
присваивается более крупной структуре (категории или тегу) и
извлекается по ссылке на эту структуру.
Самая большая разница заключается в том, что категории
имеют тенденцию быть иерархическими и фиксированными, а
теги более плоскими и динамичными. Редакторы часто могут
создавать теги на лету, вводить их как простые текстовые
строки и, как правило, обращаться с ними более
непринужденно, чем с жестким деревом категорий.
Однако во многих случаях редакторы путают категории и теги.
Мне еще предстоит увидеть реализацию, которая бы
эффективно использовала их оба, с четким разграничением
того, когда один из них уместен, а когда другой.
Функциональное совпадение настолько велико, что не так уж
много ситуаций, когда веб-сайту нужно и то, и другое.
В одном случае мы завершили весь проект с категориями и
тегами только для того, чтобы обнаружить, что редакторы все
время думали, что это одно и то же, и не понимали, почему на
готовом веб-сайте есть и то, и другое.
В общем, география контента — это всего лишь административные концепции.

Посетители веб-сайта обычно не знают о его географии. Они могут смутно
осознавать, что страницы упорядочены иерархически или что новости
упорядочены по дате. Однако средний веб-сайт никогда не будет привлекать
внимание к дереву контента (за возможным исключением карты сайта) или
явно называть страницы «родительскими» или «дочерними».
Тирания Дерева
Деревья контента очень распространены в CMS, но они могут быть
проблематичными, когда большая часть функциональности привязана к одному
дереву. В этих случаях вы можете обнаружить, что дерево тиранически
контролирует ваш контент, и простые проблемы становится труднее решить.
Например, в различных системах следующая функциональность может быть
каким-то образом связана с тем, где в дереве находится часть контента:
• Разрешения
• Разрешенные типы контента
• Рабочий процесс
• URL-адрес
• Шаблоннастройки
Если есть только одно дерево, то дерево может показаться «тираническим»,
навязывающим всю эту функциональность контенту исключительно на основе
его положения. Например, вы можете сгруппировать контент в одном месте в
дереве, чтобы упростить назначение разрешений, но хотите более детальный
контроль над выбором шаблона, чем позволяет положение в дереве.
В этих случаях система должна позволять настройкам и конфигурации каким-
то образом отклоняться от дерева. Применение этой информации на основе
положения дерева, безусловно, может быть эффективным, но оно может
перейти черту ограничения, и система должна иметь интеллектуальный и
интуитивно понятный способ обойти это, когда это необходимо.
Кроме того, привязка навигации к положению объекта контента в дереве может
стать проблематичной, если одна и та же ссылка должна появиться в двух
местах сайта. Если навигация по веб-сайту создается путем обхода дерева, вы
ограничены тем, что присутствует в дереве. Если контент должен быть в двух
местах, как с этим справиться?
К счастью, большинство систем, использующих дерево контента, имеют
некоторый механизм, позволяющий контенту появляться более чем в одном
месте. Обычно один из обликов обозначается как «основная» локация, а второй
— это просто заполнитель, ссылающийся на первый. Навигация может
осуществляться одним из двух способов: второе местоположение фактически
отправляет пользователя «по дереву» в первое местоположение или отображает
контент «на месте», по сути предоставляя одному и тому же контенту два URL-
адреса. На практике обычно отдается предпочтение первому варианту.
При отображении внешних навигационных ссылок (на другой веб-сайт) они
обычно должны быть представлены объектом контента. Тип с именем
«Внешний URL-адрес» или что-то подобное моделируется так, чтобы
содержать URL-адрес, на который редактор хочет создать ссылку. При
отображении в навигации этот объект отображает гиперссылку за пределами
сайта.
Агрегация Модели: Скрытый иЯвный

Существует две основные модели построения агрегатов:
• Неявный/внутренний
• Явный/внешний
Контент может неявно создаваться как часть более крупной структуры. Это
часто встречается в дереве контента и моделях разделения типов. Когда вы
создаете страницу для продукта X на странице «Продукты», вы создаете связь.
Эти две страницы неразрывно связаны друг с другом как родительская и
дочерняя.
Другими словами, их отношения являются внутренними (или «неявными») —
каждый объект контента знает, где он находится в структуре. Тот факт, что
Продукт X является дочерним продуктом Продуктов или что ваш Пресс-релиз
является частью более крупной совокупности всех Пресс-релизов, является
характеристикой, неотделимой от содержания.
И наоборот, явная агрегация означает, что связь между этими двумя объектами
контента не находится в самих объектах. Если мы свяжем два объекта в Main

Меню, тот факт, что Продукт X является дочерним элементом Продуктов,
справедлив только в отношении созданного нами главного меню. Взятые
изолированно, два объекта контента ничего не знают друг о друге или об их
отношениях в этом меню. Структура в этих случаях является внешней (или
«явной»). Структура существует не внутри самого контента, а в отдельном
объекте — меню. Если это меню исчезнет, исчезнут и отношения.
Одним из преимуществ явного создания структур агрегации является то, что
контент может участвовать более чем в одной структуре. На вашем сайте
может использоваться дюжина различных меню, и страница «Продукты»
может отображаться во всех из них.
Должен Твой Агрегация Быть а СодержаниеОбъект?

В некоторых случаях ваша совокупность на самом деле представляет собой
управляемый объект контента, имеющий связи с другим контентом. Однако
большинство систем не рассматривают агрегаты как основные объекты
контента, а это означает, что они лишены многих функций, которые мы
считаем присущими управлению контентом. Иногда преобразование агрегации
в объект контента — правильный путь.
Подумайте о своей команде технических писателей. Они хотели бы вести
несколько списков тем помощи, посвященных определенным темам — темы,
посвященные общению с трудными клиентами, темы, касающиеся телефонной
системы и т. д. Эти списки всегда будут составляться и упорядочиваться
вручную, и каждый список должен иметь заголовок, несколько предложений
вводного текста и дата, показывающая, когда список был создан и последний
раз просматривался.
Очевидно, что это не агрегация, а полноценный объект контента. Возвращаясь
к концепциям, обсуждавшимся вГлава 6, в этой ситуации потребуется новый
тип контента: список тем. Он будет иметь атрибуты «Название», «Введение»,
«Дата создания», «Дата рассмотрения» и «Темы». Этот последний атрибут
будет ссылкой на несколько объектов раздела справки из других мест в
географическом регионе.
Сделав эту агрегацию объектом контента, мы получаем несколько присущих
контенту особенностей:
Мы могли разрешить только определенным редакторам управлять определенным списком
тем.
Рабочий процесс
Изменения в списке тем, возможно, придется утвердить.
Управление версиями
Возможно, мы сможем фиксировать и сравнивать все изменения с определенным списком
тем.
URL-адресация
Теперь у этой агрегации есть URL-адрес, по которому ее можно получить
(подробнее об этом в следующем разделе).
Модели агрегации: неявные и явные |1 2 1

При реляционном моделировании контента грань между объектами контента и
агрегатами контента стирается, поскольку ссылочный атрибут, допускающий
множественные ссылки, сам по себе является небольшим агрегатом. Таким
образом, агрегаты можно «переносить» на обратной стороне объектов
контента.
Учтите, что состав совокупности на самом деле является содержанием сам по
себе. Список курируемых объектов контента, расположенных в определенном
порядке, соответствует двум тестам контента:Глава 1: он (1) создан в процессе
редактирования и (2) предназначен для потребления человеком. Если не
рассматривать эту совокупность как контент, это может привести к проблемам.
Допустим, ваша организация по закону обязана размещать во внутренней сети
компании список опасных материалов, используемых в ее производственном
процессе. Кто-то может случайно удалить все позиции из этого списка, тем
самым поставив организацию в нарушение закона. Как редактор получил на
это разрешение? Разве это изменение не вызвало одобрения? Может ли
организация не вернуться к предыдущей версии списка?
Не каждая агрегация так важна, как в этом примере, но во многих случаях
агрегации не поддерживаются средствами защиты, связанными с другими
объектами контента. При планировании и проектировании агрегатов ваши
требования могут диктовать, чтобы их рассматривали скорее как контент.
Адресуемость URL-адресов агрегатов

Во многих системах единственными структурами данных, которым назначены
URL-адреса, являются полноценные объекты контента. Это означает, что
агрегаты, такие как меню, списки и теги, не доступны по URL-адресу —
например, ни один посетитель не может ввести URL-адрес и просмотреть
меню.
В этих случаях агрегаты необходимо «обернуть» объектами контента, чтобы их
можно было отображать. Например, чтобы создать список контента, редактору
может потребоваться создать объект Page, а затем каким-то образом встроить
эту совокупность внутрь страницы. Тогда посетитель не столько просматривает
агрегирование, сколько просматривает конкретный объект контента, в котором
отображается агрегирование. Отображение агрегации становится косвенным.
Однако не все системы работают таким образом. Некоторые системы имеют
разные механизмы назначения URL-адресов явным агрегатам и позволяют
напрямую отображать их в качестве цели URL-адреса.
АгрегацияФункциональность
Агрегации контента могут иметь множество функций, наличие или отсутствие
которых радикально повлияет на способность редактора получить желаемый
результат.
Статический и динамический
Конкретная агрегация может быть статической, что означает, что редактор
произвольно выбрал определенные объекты контента для включения в
агрегацию, или динамической, что означает, что содержимое агрегации
определяется в любой конкретный момент по заданным критериям:
• Статическая агрегация может представлять собой указатель страниц из

справочника вашего сотрудника, который должны просмотреть новые
сотрудники. В этом случае вы специально нашли эти страницы и включили
их в это объединение посредством редактирования. Чтобы новая страница
оказалась в этом списке, вам необходимо включить ее вручную
(см.Рисунок 7-6).
• Динамическое агрегирование может представлять собой просто список
всех страниц справочника сотрудника. Чтобы новая страница оказалась в
этом списке, ее достаточно добавить в справочник сотрудника. Его
появление в этом списке является побочным продуктом этого действия.
Динамическое агрегирование — это, по сути, «стандартный поиск» —
набор критериев поиска, которые выполняются в любой момент времени
для возврата соответствующего контента.
Рисунок 7-6. Статически созданный список контента для карусели изображений в Episerver.
Динамические агрегации часто являются побочным продуктом географии

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

При создании динамической агрегации редакторы будут зависеть от критериев,
которые CMS позволяет им использовать для поиска контента, и от
интерфейса, который CMS позволяет им использовать.
Агрегационная функциональность |1 2 3
дает им возможность настроить его. Они могут иметь возможность поиска по
типу, дате публикации, автору и, возможно, по стоимости свойства.
Когда эти методы терпят неудачу, это может быть крайне неприятно. Либо
CMS несовершенна, либо редактор просто хочет агрегировать контент,
используя такую эзотерическую комбинацию критериев, от которой нельзя
разумно ожидать, что ни одна CMS обеспечит такой уровень специфичности.
Например, предположим, что ваш редактор хочет отобразить совокупность
всех объектов «Выпуск новостей» за 2015 год, отнесенных к категории
«Африка», но только тогда, когда текст не содержит фразу «AFRICON 2015»
(поскольку идет подготовка к конкретной конференции). в Африке могут
исказить результаты). Также должно быть включено все, что содержит слово
«Африка» из любой категории, а также любой пресс-релиз, написанный
автором, назначенным для места в Африке в течение 2015 года.
Возможно, существуют некоторые CMS, которые позволяют редакторам
настраивать этот уровень специфичности из интерфейса, но их очень мало. В
таких ситуациях обычно необходимо обратиться к разработчику за помощью,
создав на основе кода пользовательскую агрегацию.
ДополнительныйИндексирование
Я прочитал несколько книг об организации и продуктивности, которые
сводились к одному и тому же совету: экстернализировать память. 5 Запишите
что-нибудь. Конечно, это непривлекательный совет, но он эффективен.
В управлении данными это процесс «индексации» данных. Базы данных хранят
данные в таблицах, но предоставляют возможность индексировать данные,
используя другие методы организации, чтобы сократить время выполнения
запросов. Точно так же, как индекс книги дает вам альтернативный метод
поиска информации (в отличие от оглавления или просто просмотра страниц),
индекс предоставляет другой и более эффективный способ поиска конкретных
данных в более крупном хранилище.
При управлении контентом иногда бывает полезно создать дополнительные
индексы для помощи в тайном поиске. Например, в предыдущем примере
разработчик мог написать код, который выполнялся при каждом сохранении
выпуска новостей. Если он соответствовал указанным критериям, уникальный
идентификатор этого объекта контента можно было добавить в текстовый файл
(или удалить, если он не соответствовал). Когда нужно было отобразить
агрегацию, все идентификаторы соответствующих объектов контента
находились в одном месте.
5 Прямой призыв «экстернализировать память» исходил из «Организованного разума» Дэниела

Левитана («Пингвин»). Дэвид Аллен говорил об этом же, обсуждая «системы сбора данных» в своей
книге «Как привести дела в порядок» (Penguin).

любой контент будет создан или обновлен, становится очевидным, что
сложность вычислений в те времена гораздо более эффективна.
Возможно, если CMS позволяет осуществлять поиск по критериям,
разработчик мог бы добавить скрытый атрибут true/false к типу контента:
«Связано с Африкой». Этот атрибут может быть найден, но не установлен
редактором. При сохранении содержимого содержимое может быть оценено с
помощью кода, и этому атрибуту будет присвоено значение true или false.
Затем редактор мог выполнить простой поиск по этому атрибуту и быть
уверенным, что ему будет присвоено значение true только в том случае, если
содержимое соответствует критериям.
Такое размещение более глубокой информации в более потребляемых
структурах («экстернализация памяти») является приемлемой стратегией,
позволяющей обойти ограничения критериев агрегации и снизить накладные
Переменная ПротивЗафиксированный
Подмножеством динамических агрегатов являются те, которые могут
варьироваться в зависимости от переменных среды. Даже если домен контента
не меняется и контент не добавляется и не изменяется, то, что появляется в
динамическом агрегировании, может отличаться изо дня в день или от
пользователя к пользователю.
Поиск — классический пример динамического агрегирования переменных. То,
что отображается на странице результатов поиска, в первую очередь зависит от
ввода пользователя — того, что он ищет. Вы можете указать некоторые другие
критерии, например, какой контент ищется и как контент взвешивается или
упорядочивается, но поиск по-прежнему создается в реальном времени на
основе пользовательского ввода.
Другие агрегаты также могут основываться на поведении пользователей.
Например, виджет боковой панели, отображающий рекомендуемые статьи,
может проверять контент, использованный этим посетителем во время
текущего сеанса, чтобы определить аналогичный интересующий его контент.
Агрегации могут быть основаны и на других переменных — например, боковая
панель «Этот день в истории», перечисляющая события, явно опирается на
текущую дату для агрегирования своего содержимого. Аналогично, список
«События рядом с вами» зависит от геолокации широты и долготы посетителя.
Руководство Заказ Против ПолученныйЗаказ

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

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

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

вручную, — логически невозможен. Это выглядит немного абстрактно, но если
агрегация является динамической, то ее содержимое неизвестно во время
создания (действительно, вы не столько создаете агрегацию, сколько просто
настраиваете параметры поиска), поэтому эта агрегация никоим образом не
может заказывать вручную. Вы не сможете вручную заказать группу вещей,
если ее содержимое неизвестно.
Ручное упорядочение динамических агрегатов можно аппроксимировать
«взвешиванием» или «индексацией сортировки», при этом тип контента имеет
свойство, специально разработанное для использования при сортировке.
Это работает в большинстве случаев, но может быть довольно свободным.
Если одна страница имеет индекс сортировки 2, а другая — 4, то ничто не
мешает редактору вставить что-то с индексом 3. Действительно, во многих
случаях именно это и хочет сделать редактор, но в других случаях редакторы
могут делайте это, не зная о последствиях (помните, они редактируют сам
контент, а не включают его в более крупную совокупность
— они могут даже не знать о более крупной совокупности).
Более того, чтобы разрешить этот тип упорядочения, вам необходимо иметь
разные индексы сортировки для каждого отдельного динамического
агрегирования, в котором может появляться контент. Вам понадобится какой-
то способ сказать: «Взвешивайте этот результат по X, когда Боб ищет
вечеринку, но взвешивайте по Y, когда Алиса ищет собрание».
Очевидно, что это практически невозможно. Динамические агрегаты по
определению могут быть созданы для выполнения произвольного поиска,
поэтому невозможно строить предположения о сумме всех агрегатов, в
которых может появиться объект контента, а также невозможно спекулировать
о другом контенте в каком-либо конкретном случае. агрегирование, чтобы
вручную настроить индекс сортировки.
Достаточно сказать, что в очень редких случаях можно заказать динамическую
агрегацию контента вручную.
Отсутствие возможности произвольно упорядочивать контент

— одно из ограничений агрегирования с использованием
категорий или тегов. Обычно невозможно отнести контент к
категории или тегу в определенном порядке. Содержимое,
агрегированное этими методами, по сути, хранится в большом
контейнере, который можно динамически упорядочивать при
извлечении.
ТипОграничения
Нередко разрешается использовать только определенные типы контента в
определенных агрегатах. Если агрегация динамическая и мы указываем тип в
критериях поиска («покажи мне все выпуски новостей»), то это естественно.
Однако в других ситуациях нам может потребоваться ограничить типы,
поскольку содержимое должно соответствовать определенному формату,
чтобы его можно было использовать в выходных данных.
Например, рассмотрим кадр карусели изображений, изображенный на
рисунке.Рисунок 7-8. Это один кадр мультикадровой галереи, основанный на
агрегировании (плоском списке или коллекции) нескольких объектов контента.
Этот список создан и упорядочен вручную.
Рисунок 7-8. Кадр карусели изображений. Карусель изображений сама по себе

представляет собой совокупность,зависит от того, относится ли все его
содержимое к определенному типу.
Для корректного отображения каждый элемент в этом агрегате должен иметь:
• Некоторый текст ссылки (текст «Читать статью»)
• Постоянный URL-адрес (на который перенаправляются посетители, когда они нажимают
на текст ссылки)
В это объединение можно включить только контент, соответствующий этому

шаблону. Это означает, например, что биография сотрудника отсутствует,
поскольку в ней нет краткого описания.
Поскольку эта агрегация, скорее всего, является статической (карусели
изображений всегда представляют собой тщательно подобранные списки
контента), нам нужен способ ограничить редакторов выбором только контента
того типа, который нам нужен. Если мы не можем ограничить тип, то мы
рискуем сломать нашу карусель изображений, если она встретит контент не
того типа, который ей нужен.
Разработчик умных шаблонов учтет это и просто проигнорирует и пропустит
контент, который не работает. Это предотвращает ошибки, но, скорее всего,
запутает редактора, который не понимает ограничений типа, и может привести
к паническому телефонному звонку: «Мое новое изображение не появляется в
карусели на первой странице!»
Эти ограничения не являются редкостью в географических регионах дерева
контента. Довольно часто можно указать тип контента, который может быть
создан как дочерний элемент другого контента. Например, мы могли бы
указать, что тип контента «Комментарий» может быть создан только как
дочерний тип контента «Сообщение в блоге», и наоборот — сообщения в блоге
могут принимать только дочерние элементы, которые являются
комментариями.
Ограничения количества
Это менее распространено, но некоторые агрегаты могут хранить больше
контента, чем другие, а некоторые системы позволяют требовать определенное
количество объектов контента или не позволяют превышать максимальное
количество.
Рассмотрим нашу карусель изображений — в ней может потребоваться как
минимум два элемента (иначе это не карусель), а их число может быть
ограничено максимум пятью (иначе форматирование пейджера нарушится).
Будет полезно, если интерфейс сможет ограничить редакторов добавлением
элементов только в этих границах.
Разрешения и Публикация Положение делФильтры

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

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

Многие агрегаты просто плоские — например, наш список страниц
справочника сотрудников или карусель изображений. Но другие агрегаты часто
представляют собой иерархические структуры контента.
В этих случаях у нас есть несколько плоских агрегатов, связанных друг с
другом. Иерархический список — это, по сути, несколько плоских списков,
вложенных друг в друга. Верхний уровень представляет собой один плоский
список, а каждый последующий уровень может представлять собой либо один
объект контента, либо другой плоский список, и так далее до конца.
Единственное различие (и оно важное) состоит в том, что эти плоские агрегаты
знают друг о друге — любой из них знает, что у него есть дочерние элементы
или родительский элемент.
Ярким примером является главное меню веб-сайта. Веб-сайты часто имеют
верхнюю строку меню, содержащую либо раскрывающиеся подменю для
страниц второго уровня, либо вторичную навигацию, которая появляется в
меню боковой панели.6
МежстраничныйАгрегации
В некоторых ситуациях включение контента в агрегацию требует
дополнительной информации, чтобы иметь смысл. В этих случаях включение
контента само по себе становится объектом контента.
Например, предположим, что мы объединяем группу объектов контента
«Биографии сотрудников», чтобы представить команду, планирующую
рождественскую вечеринку компании. Для этого мы создадим статическую
агрегацию контента.
Однако, помимо простого включения в эту агрегацию, мы хотим указать,
какую роль играет каждый сотрудник в группе, представляемой агрегацией.
Итак, в случае с Мэри Джонс мы хотим указать, что она является
председателем комитета. Мария
6 И я надеюсь, что к этому моменту становится очевидным, что география дерева контента
представляет собой одну большую иерархическую совокупность контента. Просто это основная
совокупность для многих CMS.
на самом деле администратор в компании, и это звание смоделировано в ее
объекте «Биография сотрудника».
Титул председателя комитета имеет смысл только в связи с ее включением в
эту совокупность, и больше нигде. Следовательно, этот атрибут отсутствует ни
в агрегировании, ни в биографии сотрудника. КакРисунок 7-9 показывает, что
этот атрибут по праву принадлежит точке присоединения между ними; там
описывается назначение Мэри в этот комитет.
Рисунок 7-9. звание «Председатель комитета» не принадлежит ни Марии,

ни комитету; скорее, он правильно принадлежит пересечению двух
В этом смысле ее включение в эту агрегацию само по себе является объектом

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

Как мы кратко обсуждали вГлава 2, некоторые задачи в среде CMS могут
выполняться нетехническими редакторами, работающими через интерфейс, а
другие задачи должны решаться разработчиками, работающими с шаблонами
или основным кодом системы.
Агрегации ничем не отличаются. Как правило, разработчики могут
агрегировать контент любым способом, который позволяет API — у них есть
полная свобода. Подмножество этих возможностей предоставляется
редакторам для создания и отображения агрегатов в рамках создания контента.
Насколько велико это совпадение, во многом зависит от системы и частично от
сложности ваших редакторов.

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

• Откуда следует получить этот контент?
• Сколько должно быть постов?
• Будет ли агрегация разбита на страницы?
• Как следует располагать посты? Должен ли быть предусмотрен контроль,
позволяющий посетителям делать заказы по другим критериям?
• Должны ли сообщения относиться к одной категории? Из одного тега? Из
более чем одного тега?
• Должны ли они фильтроваться по разрешениям?
• Должны ли они фильтроваться по дате?
• Есть ли какие-либо другие критерии, по которым их следует фильтровать?
Эти переменные обычно довольно просты для разработчика, но их очень

сложно настроить редактору через интерфейс.
Модуль Drupal Views представляет собой прекрасный пример этой базовой
сложности. Views — это модуль, который позволяет редакторам создавать
динамические агрегаты контента путем настройки параметров поиска и
форматирования информации. Он предоставляет огромное количество опций,
предоставляя редакторам максимальную гибкость.
Представления разрабатывались в течение многих лет, и интерфейс несколько
раз переписывался с целью сделать его максимально простым и удобным.
Однако сложность остается. Просто существует базовый, неразрешимый
уровень сложности, который сочетается с гибкостью, которую предлагает
Views. Фишер-Прайс не создает «Игровой набор по ядерному делению» по той
же причине: все яркие основные цвета в мире не сделают расщепление атома
менее сложным.
Рассмотрим интерфейс, представленный вРисунок 7-10. Вы можете легко
потратить целый день на обучение редакторов только тем функциям, которые
предлагает Views.
По конфигурации или по коду |1 3 1
Рисунок 7-10. Конфигурация модуля Drupal Views — обратите внимание, что
многие кнопки и гиперссылки скрывают совершенно разныесубинтерфейсы для
этих конкретных аспектов агрегации
Разработчикам легче, поскольку код более краток и точен, и они более

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

Обучение и повторение
Они говорят, что практика ведет к совершенству, и то же самое
можно сказать и о редактировании контента. Редакторы будут
помнить то, что они делают часто, и забывать то, что делают
редко. Редактирование контента — это то, чем они занимаются
часто. Создание агрегатов контента обычно выполняется
гораздо реже.
Это означает, что независимо от того, насколько хорошо они
были обучены изначально, редакторы будут склонны забывать
о тех редко используемых функциях, которые требуют
сложных функциональных знаний, и конфигурация
агрегирования контента явно соответствует этому описанию.
Следовательно, система, предназначенная для того, чтобы дать
редакторам контроль над агрегированным контентом, часто
более эффективна для создания звонка в службу поддержки
каждый раз, когда редактор пытается ее использовать.
Разработчикам нередко приходится настраивать агрегаты для
редакторов, используя интерфейс, который, по иронии судьбы,
был создан, чтобы позволить им делать это без разработчиков.
А Краткое содержание из Содержание АгрегацияФункции

Вот несколько вопросов о функциях агрегирования контента любой CMS:
• Какова основная география контента, используемая системой? Есть ли у

него основная модель агрегирования, в которой структурирован весь
контент?
• Можно ли легко представить отношения родитель/потомок?
• Какими возможностями обладают разработчики для агрегирования контента по коду?
• Какими возможностями обладают редакторы для агрегирования контента
по конфигурации в интерфейсе?
• Какие вторичные агрегаты, такие как категории, теги, меню и списки,
доступны?
• Могут ли редакторы создавать статические агрегаты?
• Являются ли эти агрегаты плоскими или иерархическими?
• Можно ли упорядочить статические агрегаты вручную?
• Могут ли статические агрегаты быть ограничены по типу?
• Могут ли редакторы настраивать динамические агрегаты? На основании каких имеющихся
критериев?
Краткое изложение функций агрегирования контента |1 3 3
ГЛАВА8
Редакционные инструменты и
рабочий процесс
Ведущие телешоу «Разрушители мифов» однажды провели эксперимент,

переложив страницы двух телефонных книг. По сути, они соединили две
телефонные книги вместе, а затем вставили их друг в друга так, что их
страницы чередовались, и каждая страница одной телефонной книги лежала
между двумя страницами другой.1 Единственное, что удерживало вместе две
телефонные книги, — это трение страниц друг о друга.
Затем они попытались разъединить две телефонные книги.
Пытались тянуть с десятком человек, потом подвешивали человека к одному из
них, потом поднимали машину с земли, потом пытались использовать силовое
оборудование в цехе, потом пробовали две машины, движущиеся в
противоположных направлениях. Ничто не могло разъединить две книги, пока
они не получили две бронемашины времен Второй мировой войны.
Телефонные книги наконец развалились под действием силы в 8000 фунтов.
Не стоит недооценивать трение. Он может подкрасться к вам и полностью
остановить все.
Ваша CMS обязательно вносит некоторую степень редакционных разногласий.
Чтобы выполнять свою работу, вашим редакторам придется взаимодействовать
с CMS, использовать предлагаемые ею инструменты и страдать без
инструментов, которых у нее нет. CMS может либо позволить им эффективно
выполнять свою работу, либо создавать трудности из-за плохого удобства
использования, ненужного повторения, подверженных ошибкам интерфейсов и
плохих концептуальных моделей.
Возможности CMS, которые редакторы используют для выполнения
редакционного процесса, в совокупности известны как редакционные
инструменты или редакционный рабочий процесс (буквально означает «поток
1 На самом деле все было не так просто. Им приходилось индивидуально переворачивать тысячи
страниц телефонной книги друг над другом. Эта часть скучна, но остальноеВидео это невероятно
увлекательно.
135
работа», а не рабочий процесс как конкретная концепция CMS, которую мы
обсудим далее в этой главе).
Это действительно «управление» системами управления контентом. Это
инструменты, которые расширяют возможности редакторов создавать более
качественный контент и получать больший контроль над контентом,
находящимся под их контролем. Это та часть CMS, которую редакторы будут
использовать изо дня в день.
Это критически важная область функциональности, поскольку плохие
инструменты и рабочий процесс могут нанести вред редакторам и подорвать
моральный дух. К сожалению, редакционное удобство использования — это
одна из областей разработки CMS, которую слишком часто упускают из виду.
Как мы уже говорили, CMS создаются разработчиками, но часто они также
создаются в первую очередь для разработчиков. Разработчик понимает вещи
иначе, чем средний редактор контента, и при разработке редакционных
интерфейсов и инструментов разработчики часто идут на скачки и вольности,
которые имеют смысл для них, но не обязательно для людей с другими
точками зрения.
В коммерческих системах и более крупных системах с открытым исходным
кодом эти недостатки юзабилити исправляются за счет давления рынка и
широкого редакционного использования. Однако в небольших системах с
открытым исходным кодом, которым не нужно взимать лицензионные сборы и
которые могут не иметь большого сообщества редакторов, проблемы с
удобством редакционного использования могут сохраняться годами без
исправления.
Хотя редакционные разногласия напрямую снижают производительность
редакторов в краткосрочной перспективе, более разрушительным аспектом
является хроническое воздействие, которое они оказывают на моральный дух в
долгосрочной перспективе. Многие редакционные коллективы с течением
времени все больше разочаровываются и возмущаются плохо
спроектированной или реализованной CMS. Я не раз сталкивался с командами,
которые терпели крах и теряли персонал, потому что устали от дополнительной
нагрузки, налагаемой на них системой, которую они были вынуждены
использовать.
Надежные, хорошо реализованные редакционные инструменты улучшают
редакционный процесс. Плохие или несуществующие инструменты со
временем разрушат его. Как минимум, CMS должна оставаться в стороне и не
создавать каких-либо препятствий сверх того, что абсолютно необходимо.
The СодержаниеЖизненный цикл

С момента создания до момента безвозвратного удаления контент проходит
несколько стадий «жизни». Стадия, на которой информация фактически
публикуется на веб-сайте и может быть использована посетителем, является
лишь одной из многих (и иногда может быть довольно короткой — может быть
создан выпуск новостей, объявляющий о событии, а затем удален через
неделю).
Эти этапы в совокупности называются «жизненным циклом» контента. Не
существует общепринятого определения точных стадий и их порядка, но я
попытаюсь представить здесь определение, охватывающее многие из
общепринятых стадий.
136 | Глава 8: Редакционные инструменты и рабочий процесс

Здесь не представлена неформальная фаза «Концепции»
жизненного цикла контента, когда кто-то придумывает идею
нового контента, обсуждает ее с коллегами и, возможно,
начинает что-то писать в Microsoft Word или Google Docs. Мы
пропускаем это и учитываем только то, что происходит внутри
самой CMS.
Жизненный цикл контента можно описать как состоящий из следующих этапов:

Создавать
Контент инициируется в CMS. Он не является полным, но существует как
объект управляемого контента. Он не виден потребителю контента.
Редактируйте и сотрудничайте
Контент активно редактируется и/или над ним совместно работают один
или несколько редакторов. Содержимое по-прежнему не видно.
Отправить и одобрить
Содержимое создается, редактируется и отправляется на одно или
несколько утверждений. Контент по-прежнему не виден.
Публиковать
Контент одобрен и опубликован на сайте. Контент в этом состоянии виден
потребителю контента.
Архив
Контент удален из публичного доступа, но не удален. Обычно его уже не
видно.
Удалить
Контент безвозвратно удаляется из CMS.
Некоторые из этих этапов являются итеративными и могут применяться
одновременно к разным версиям одного и того же контента.
Например, часть контента может публиковаться некоторое время, затем ее
необходимо изменить. В это время (и в зависимости от CMS) новая версия
создается в виде черновика («Редактирование и совместная работа»),
отправляется на утверждение («Отправить и утверждать»), а затем
окончательно публикуется, в результате чего предыдущая версия помещается в
архив. Сейчас существуют две версии этого контента, находящиеся на разных
стадиях жизненного цикла: одна заархивирована, другая опубликована.
Это не единственный способ описания жизненного цикла контента, и
используемый язык во многом зависит от точки зрения и профессиональной
роли наблюдателя. Маркетологи, например, склонны описывать контент с
точки зрения «создания, распространения и анализа», не вдаваясь в
подробности редактирования, утверждения и архивирования, которыми
занимается контент-менеджер.
Жизненный цикл контента | 137
Стадия «Архив» особенно туманна, и очень немногие практики полностью
согласны с ее определением. Для некоторых архивировать контент просто
означает сделать его невидимым для конечного потребителя, не удаляя его. Для
других это означает перемещение его «куда-нибудь еще» в CMS, подальше от
неархивированного контента, но, возможно, по-прежнему оставляя его
доступным для посетителей другим способом. Для других это может означать
перемещение его в другое хранилище — даже в автономный архивный
носитель.2
Независимо от конкретных этапов жизненного цикла, хорошая CMS
обеспечивает функциональность на всем протяжении существования объекта
контента на вашем веб-сайте.
Одной из неизбежных констант жизненного цикла контента

является его цикличность. Поищите в Google Картинки по
запросу «жизненный цикл контента», и вы всегда увидите
браузер, полный кругов. Хотя это и несколько забавно, но это
также демонстрирует циклический характер контента. Его, как
правило, создают, оценивают, редактируют и переиздают в
цикле, снова и снова.
Интерфейс редактирования
Первая задача среды редактирования — сделать ее удобной для использования
и предоставить редакторам контента компетентный и функциональный
интерфейс для создания и редактирования контента. Если CMS не справляется
с этим, восстановить ее будет сложно. Редакторам, которые ненавидят работать
с контентом в своих CMS, будет сложно создать что-то ценное в долгосрочной
перспективе.
Содержание Находимость иОбход

Чтобы редактировать контент, редактор сначала должен его найти. На
некоторых веб-сайтах это просто: если на веб-сайте 20 страниц, найти нужную
нетрудно. Однако, когда на сайте тысячи и тысячи страниц, это становится
сложнее. Как вы уследите за ними всеми?
Традиционно веб-сайты предлагали специальные интерфейсы управления,
предназначенные для использования редакторами исключительно для
просмотра контента в репозитории. Содержимое будет представлено в простой
таблице с инструментами поиска, которые помогут его найти.
По мере того как все больше и больше CMS охватывали географию дерева
контента, интерфейсы управления перемещались в свертываемую древовидную
структуру, в которой редакторы могли просматривать родительские и дочерние
отношения для идентификации контента.
Сегодня эти интерфейсы все чаще уступают место контекстному управлению,
когда редакторы просто просматривают свои веб-сайты, как это делают
потребители контента. Когда редакторы
2 В LinkedIn группа контент-менеджеров попыталась дать определение понятию «архивирование».
Диапазон ответов был значительным, и они были собраны в«Взгляд на то, что означает
«архивирование» в управлении контентом».

однако они прошли аутентификацию в CMS и имеют доступные инструменты
редактирования, начиная от простой ссылки «Редактировать эту страницу» и
заканчивая более сложными всплывающими/наложенными интерфейсами,
которые позволяют им войти в режим редактирования.
Я до сих пор помню, как посетил торговый зал Intranets 2001 в

Санта-Кларе, Калифорния, и увидел демо-версию RedDot, где
продавец воскликнул: «Когда вы вошли в систему как
редактор, все, что вы можете редактировать, будет отмечено
маленькой красной точкой. к этому!» (Отсюда и название
продукта, очевидно.) Мы все были впечатлены. В то время это
было похоже на волшебство.
Такой стиль поиска контента может оказаться затруднительным для

изолированных систем. Когда сервер публикации/доставки отделен от сервера
управления/репозитория, он часто не имеет возможности аутентифицировать
кого-либо в качестве редактора и, следовательно, не имеет возможности
показать этим пользователям инструменты редактирования на странице.
Многие системы обходят эту проблему, генерируя прокси-версию сайта:
редакторы просматривают интерфейс управления, который отображает веб-
сайт в IFRAME, или пересылают весь веб-сайт через прокси на другой сервер,
на котором редактор проходит аутентификацию.
Этот метод обхода контента стал распространенным, потому что по мере
повышения удобства использования веб-сайта инструменты, доступные
потребителям контента для поиска контента, стали более похожими на
инструменты, которые используют редакторы. Зачем создавать набор
инструментов редактора, если CMS уже предоставила конечному пользователю
множество функций сортировки и поиска? По мере того, как мы придумываем
все более совершенные технологии поиска и интерфейсы для наших
посетителей, нам становится все труднее улучшить их для редакторов. И было
бы сложно объяснить, если бы вашим редакторам приходилось использовать
инструменты, которые на самом деле были хуже, чем те, которые использовали
посетители сайта.
Однако все еще существуют инструменты фильтрации контента, которые
можно считать специфичными для редактора. Это инструменты, которые
позволяют фильтровать.
• По рабочему процессу или статусу публикации

• По статусу административной задачи
• По владельцу контента
• По статусу архивирования или удаления
• С помощью пользовательских редакционных метаданных (например, поиск
контента с пометкой «требует проверки»)
Во всех этих ситуациях критерием поиска контента не является то, что будет
видно потребителю контента, и поэтому CMS может иметь специальные
инструменты редактирования, с помощью которых можно обрабатывать такие
ситуации.
Интерфейс редактирования | 139

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

Если для CMS есть специальный интерфейс администратора
или редактирования, убедитесь, что при необходимости он
масштабируется для большого объема контента. Многие
интерфейсы прекрасно работают с несколькими сотнями
объектов контента, но перестают работать, когда количество
объектов достигает, скажем, 100 000.
Деревья контента с большим количеством объектов под одним
родителем могут быть особенно проблематичными. Если у вас
есть 10 000 новостных статей под одним родителем, как с этим
справится древовидный интерфейс? Прокручивать 10 000
статей по сути бессмысленно, а расширение этого узла в
дереве, скорее всего, замедлит работу интерфейса или
полностью его сломает. Может ли дерево разбить этот список
на страницы? Может ли он предоставить вам интерфейс с
возможностью поиска только для этого узла дерева?
Разработчики, пишущие эти интерфейсы, часто не тестируют
большие объемы контента. Если управление большим объемом
контента является одним из ваших требований, убедитесь, что
интерфейс справится с этим.
ТипВыбор
При создании нового объекта контента первой задачей редактора обычно
является выбор типа контента, на котором он будет основываться (см.Глава 6).
CMS должна гарантировать, что редактор может выбрать подходящий тип
контента для конкретной ситуации, а не тот тип контента, который работает не
совсем правильно или сломает веб-сайт в случае его публикации.
Во многих случаях целостность дерева контента обеспечивается за счет
ограничений на происхождение типа. У нас может быть тип «Проблема»,
который содержит один или несколько типов категорий статей, каждый из
которых содержит один или несколько объектов «Статьи». Иерархия логична и
необходима для правильного моделирования и рендеринга контента.
Если бы редактору было разрешено создавать контент на основе типа
«Проблема» как дочернего элемента статьи, что бы произошло? Код в шаблоне
не ожидает содержимого этого конкретного типа в этом месте. В лучшем
случае, если бы разработчик проверял тип всего, шаблон просто
проигнорировал бы это. Однако во многих ситуациях шаблонизация будет
нарушаться — разработчик, вероятно, предположит, что CMS будет
обеспечивать соблюдение иерархии типов, и, таким образом, будет полагать,
что Проблема никогда не будет найдена как дочерний элемент Статьи.3
3 Да, очевидно, что это будет означать сбой в проверке ошибок. Но при работе с CMS разработчики
часто доверяют ей соблюдение определенных стандартов и отказываются от исчерпывающей
проверки ошибок ради практичности.

В таких ситуациях CMS должна иметь возможность определять правильную
связь между типами. Редакторы создают контент в определенных местах
географии контента, и CMS должна иметь возможность диктовать, какой
контент они могут создавать в каждом конкретном месте. Поэтому типы
контента должны указывать, какие типы могут быть созданы как дочерние
элементы определенного типа.
Кроме того, доступ к некоторым типам контента может быть ограничен в
определенных редакторах. Обычно некоторые типы более изменчивы и
продвинуты, чем другие. Как мы обсуждали вГлава 4, не все редакторы
одинаковы. Опытному редактору может быть предоставлена большая свобода,
чем другим, и типы контента, к которым эти редакторы имеют доступ, должны
это отражать.
Например, в некоторых установках мощный редактор может иметь доступ к
типу контента, который допускает включение необработанного HTML —
редактор может иметь возможность вводить необработанный код
HTML/JavaScript, который включается в страницу, без изменений. Понятно,
что это может быть опасно
— Можно ввести HTML для преждевременного закрытия тегов или добавить
JavaScript, открывающий сайт для атак с использованием межсайтовых
сценариев.
Другие элементы, такие как карусели изображений, могут потребовать
большей осторожности и опыта, чем позволяет обучение обычного редактора.
Редакторам может потребоваться понять, как выбирать и редактировать
изображения, решать проблемы доступности при включении изображений и
решать другие проблемы с удобством использования.
В таких случаях эти типы контента должны быть доступны только редакторам,
обученным правильно их использовать.
Наконец, в некоторых установках список доступных типов контента может
стать довольно большим, иногда исчисляясь десятками. Несколько различных
функций могут облегчить редакторам выбор шрифта:
• Интеллектуальное именование может помочь в выборе типа контента.

Типы часто имеют «системное имя» для ссылки из кода и «отображаемое
имя», которое можно расширить, чтобы сделать его более понятным для
редакторов.
• Некоторые CMS допускают одно или два предложения о том, что делает
этот тип, для дальнейшего объяснения его использования.
• Другие позволяют использовать миниатюрное изображение примера
полностью визуализированного типа, что может подтолкнуть редактора к
правильному использованию.
• Некоторые CMS со временем даже обучаются и предоставляют редакторам
наиболее часто используемые типы или типы, наиболее часто
используемые в аналогичных ситуациях — в качестве дочерних элементов
родительского типа или примера (см.Рисунок 8-1).
Рисунок 8-1. Интерфейс выбора типа в Episerver
Во всех случаях цель состоит в том, чтобы предоставить редакторам список

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

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

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

что-то, что очень похоже на готовую страницу со стилем. Например, когда
он набирает заголовок, буквы выделяются шрифтом Arial Bold размером 24
pt, как и при публикации страницы. Цель — попытаться замаскировать, что
это вообще интерфейс редактирования, и создать впечатление, будто
редактор просто работает над готовой страницей. Предварительный
просмотр фактически становится в режиме реального времени.
Хотя контекстное редактирование на первый взгляд кажется выгодным (кто не

хотел бы видеть предварительный просмотр в реальном времени?), есть
несколько смягчающих обстоятельств:
• Редактирование в контексте не обрабатывает невизуальные свойства,

напримерМЕТАсодержимое тега или содержимое конфигурации, например
флажок «Показать боковую панель». Если контент предназначен для
изменения поведения страницы, а не для использования в качестве самого
контента, работать с контекстным интерфейсом сложнее.
• Редактирование в контексте часто представляет собой только одно
представление контента — представление одной веб-страницы. В
современном многоканальном мире контент может публиковаться во
многих местах Интернета и использоваться множеством различных
устройств, поэтому возникает вопрос: какой предварительный просмотр вы
просматриваете?
Марк Бултон рассмотрел эту проблему в своем блоге:

Проблема в следующем: люди, завершающие добавление контента в CMS,
задают вопрос: «Как это выглядит?». И это уже не тот вопрос, на который CMS
может ответить – даже с предварительным просмотром. То, как мы используем
Интернет сегодня, означает, что ответ на эти вопросы звучит так: «В чем?»4
Более современные CMS имеют функции множественного просмотра, где
редактор может выбрать вид для предварительного просмотра контента —
например, веб-страницы, твита или элемента RSS. Однако такая функция
предварительного просмотра не является распространенной и обычно требует
дополнительной настройки, разработки и создания шаблонов для обеспечения
точного представления всех возможных каналов контента.
Поймите, что многоканальный предварительный просмотр — это не просто
техническая проблема. Предоставленные самим себе, редакторы будут
склоняться к основному предполагаемому формату вывода, которым, скорее
всего, будет HTML. Не стоит недооценивать проблемы рабочего процесса,
обучения и управления, связанные с обязательным многоканальным
предварительным просмотром перед публикацией.5
4 «ВИСИВТФФТВОМГ!», 3 сентября 2013 г.

5 Я написал эту книгу на платформе редактирования Atlas О'Рейли. Я писал в текстовом формате под
названием AsciiDoc и мог «встраивать» в несколько форматов в любой момент времени. Я был
одержим форматированием печатной версии книги (PDF), демонстрируя явную предвзятость к тому,
как она будет выглядеть в печатном виде. Лишь позже в процессе написания я начал рассматривать
варианты вывода EPUB, MOBI и HTML. Часто форматирование, которое работало в одном, было
проблематичным в другом.

Проблема персонализации и предварительного просмотра
Одним из новых направлений в управлении контентом за последние пять лет
стала персонализация (подробнее об этом говорится вГлава 10), или
использование поведения и контекстной информации для персонализации
работы в Интернете для каждого посетителя.
К сожалению, это еще больше усложняет предварительный просмотр. Как при
предварительном просмотре контента учесть все возможные варианты и
комбинации факторов, которые могут повлиять на этот контент?
Например, если посетитель просмотрел три страницы в разделе веб-сайта
университета, посвященном программе медсестер, то на странице «Приемная
комиссия» должно отображаться стандартное изображение студентки-
медсестры, а не более общее изображение.
Как вы можете просмотреть это? Придется ли вам вручную просматривать три
страницы, чтобы смоделировать поведение, требуемое вашей CMS? Или в
вашей CMS есть инструменты, позволяющие «подделать» ваше членство в
группе персонализации?
Объедините это с устройствами и каналами распространения, и возможные
результаты могут быть бесконечными. Для одной веб-страницы редактор мог
бы создать сотни различных комбинаций поведения посетителей, устройств
потребления и каналов распространения, и все со своим собственным
предварительным просмотром.
Редактирование ИнтерфейсЭлементы
Редакционная резина сочетается с дорогой в интерфейсе. Наступает момент,
когда редактор действительно печатает или щелкает что-то и создает
некоторый контент. Вообще говоря, CMS должна предоставлять редакторам
правильный элемент редактирования для информации, которую они пытаются
редактировать. Хороший интерфейс редактирования помогает редакторам
принимать правильные решения и защищает их от ущерба.
Представьте, что интерфейс редактирования представляет собой просто список
пустых текстовых полей для всех атрибутов. Для текста это может быть
уместно, но как насчет значения да/нет? Должен ли редактор просто ввести
«да» или «нет»? А как насчет «истина» или «ложь»? Имеет ли значение
капитализация? Очевидно, что в этом случае подходящим элементом
интерфейса является флажок, который отмечен для «да» и снят для «нет».
CMS должна отображать интерфейс редактирования в соответствии с моделью
контента, делая разумные предположения при выборе правильного элемента
для представления редакторам (и допуская административные изменения, где
это необходимо). Цель состоит в том, чтобы создать высокопродуктивную
рабочую среду, избегая ненужных ошибок и догадок.
Помимо вышеупомянутого флажка, есть еще несколько вариантов выбора элементов:
• Простое текстовое поле или текстовая область для ввода длинного или короткого текста.
• Список флажков для атрибута, который может поддерживать несколько
значений из предопределенного списка.

• Список переключателей или раскрывающийся список для атрибута,
который допускает только одно значение из предопределенного списка.
• Редактор форматированного текста (WYSIWYG) для редактирования HTML.
• Раскрывающийся список календаря для выбора даты
• Интерфейс Google Maps для выбора географической точки на карте.
• Пользовательский интерфейс, предоставляющий инструмент поиска для
нахождения SKU в вашем каталоге продукции.
Проверка
Помимо приема входных данных, интерфейс редактирования контента должен
гарантировать корректность введенных данных, чтобы ошибки не могли
поставить под угрозу контент. Проверка может проводиться с использованием
элементов интерфейса редактирования, как обсуждалось в предыдущем
разделе; однако CMS всегда должна проверять данные независимо от
интерфейса в случае, если данные вводятся через API или службу (и,
следовательно, не подпадают под ограничения интерфейса редактирования).
Поймите, что проверка контента связана с его логическим значением, а не
обязательно с его чистым типом данных. Типы данных не понимают контекст;
они понимают только чистые данные, полностью отделенные от того, как эти
данные будут использоваться.
Как мы обсуждали вГлава 6, если атрибут представляет год, то базовый тип
данных может быть числом (или целым числом). Однако логическая идея года
предполагает и ряд других ограничений:
• Он должен состоять из четырех цифр.

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

необходимых ограничений вокруг типа логического значения года.
Необходимо будет провести дополнительную проверку.
Некоторые системы предлагают расширенные типы проверки для этих
экземпляров. Например, в случае числа можно разрешить диапазон, чтобы
гарантировать допустимость числа. То же самое можно сказать и о датах,
чтобы обеспечить ввод даты в будущем, в прошлом или между двумя
знаменательными датами.
Регулярные выражения («регулярные выражения») можно использовать во
многих случаях для проверки текстовых шаблонов. Хотя обсуждение
регулярных выражений выходит далеко за рамки этой книги, 6 на высоком
уровне регулярное выражение — это определение текстового шаблона,
достоверность которого можно проверить.
Например, в случае даты выхода нашего фильма мы можем определить
регулярное выражение для обеспечения соблюдения:
(19|20)\d{2}
При применении этого шаблона к введенному тексту первые две цифры будут
«19» или «20», а за ними последуют две дополнительные цифры. Это
ограничит данные годами между 1900 и 2099 годами.
Если мы знаем, что номера наших продуктов начинаются с буквы «А», за
которой следуют еще два буквенных символа, затем тире и четыре цифры, мы
можем написать такой шаблон:
А[AZ]{2}-\d{4}
Несомненно, некоторые потребности в проверке просто не могут быть заранее
определены CMS и должны быть реализованы с помощью специального кода.
В этом примере мы, конечно, можем применить формат номера продукта, но не
можем гарантировать, что этот продукт существует в нашем каталоге.
Чтобы подтвердить этот факт, нам нужно будет написать собственный код для
подключения к нашей базе данных продуктов, проверить введенный номер
продукта, а затем сообщить интерфейсу, следует ли принять введенные данные
или отобразить ошибку в редакторе. В этом отношении разные CMS
предлагают разные уровни функциональности.
Богатый текстредактирование
Большинство CMS включают в себя расширенный текстовый интерфейс,
позволяющий редакторам создавать HTML-контент как атрибут объекта
контента.
Например, почти все реализации будут иметь тип контента «Текстовая
страница» или «Стандартная страница». Этот тип контента может быть таким
же простым, как заголовок и тело, которые часто представляют собой
форматированный текст. Внутри интерфейса редактирования тела редактор
будет иметь кнопки для форматирования таких элементов, как полужирный
текст, курсив, маркированные и нумерованные списки, вставка изображений,
создание гиперссылок и т. д. «Так же, как Microsoft Word» — это
распространенная фраза, используемая для опишите эти редакторы.
Использование форматированного текста может вызвать разногласия.
Редакторы наслаждаются контролем, но разработчики и дизайнеры могут
нервничать из-за свободы, которую он предоставляет. Известно, что редакторы
широко используют форматирование, часто игнорируя руководства по стилю и
соглашения. Кроме того, если у них есть доступ к исходному коду HTML, они
могут редактировать HTML вручную, что может вызвать проблемы с
рендерингом шаблона, в котором размещается контент.
6 Освоение регулярных выраженийДжеффри Э. Ф. Фридла (О'Рейли), в настоящее время вышло его третье
издание, является основополагающим иавторитетный текст о регулярных выражениях.

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

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

текста и вместо этого пытаться «структурировать» проблему, разбивая контент
на достаточно мелкие атрибуты, чтобы вообще не нуждаться в
форматированном тексте. Хотя это может порадовать разработчиков, это,
вероятно, не совсем реалистично. Большинству редакторов всегда нужны
инструменты форматирования.
Альтернативно, некоторые реализации переходят к очень легким языкам
разметки, а не к HTML. Эти языки можно редактировать внутри простых
элементов текстовой области и использовать комбинации символов, которые
позже преобразуются в HTML на этапе рендеринга страницы. Самый
распространенный пример — Markdown, который выглядит следующим
образом:
Этот текст выделен _курсивом_ и выделен *жирным
шрифтом*. Это [aссылка](http://oreilly.com/).
Другими примерами альтернативных языков разметки являются Textile, PanDoc
и WikiText.7 Некоторые CMS, например Ghost, предлагают предварительный
просмотр этих языков в режиме реального времени в параллельном
интерфейсе, при этом изменения на одной панели отражаются на другой
(см.Рисунок 8-2 для примера).
7 Как упоминалось ранее, я написал всю эту книгу в варианте Markdown под названием AsciiDoc.

Рисунок 8-2. Редактирование в Ghost с использованием синтаксиса Markdown
на левой панели в режиме реального времени.предварительный просмотр
времени на правой панели
Ссылкавыбор контента
В большинстве реализаций контент необходимо будет связать вместе одним
или несколькими способами:
• Форматированный текст в одном объекте контента может содержать

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

контента из интерфейса редактирования. Способы сделать это различаются, но
обычно редактору открывается всплывающее окно, предлагающее несколько
способов поиска контента — редакторы обычно имеют возможность
просматривать его и, возможно, смогут его искать. Это становится все более
важным по мере увеличения количества объектов контента. Попытка найти
конкретную статью среди тысяч может оказаться удручающе сложной.
Что становится критическим, так это способы ограничения этого интерфейса.
Например:
• Ссылка на атрибут может быть разрешена только для определенного типа

контента. Атрибут Manager объекта контента «Сотрудник» должен быть
связан только с другим объектом контента «Сотрудник».
• Ссылка на атрибут может быть ограничена определенным географическим
местоположением. Возможно, редактор может выбрать для избранной
статьи только дочерние элементы текущего выпуска.
Кроме того, тонкий, но критический момент заключается в том, привязана ли

ссылка на объект к самому объекту или к текущему URL-адресу объекта.
Последнее всегда будет проблематичным. Если CMS требует, чтобы редактор
просто нашел URL-адрес другой страницы и вставил его в поле гиперссылки,
что произойдет, если URL-адрес этого второго объекта контента изменится?
URL-адреса могут меняться, поэтому связи между контентом следует
разрешать как можно позже в цикле доставки контента. Любая вставленная
ссылка должна быть просто ссылкой на контент, а не его фактический текущий
URL-адрес. Затем ссылку следует заменить правильным и текущим URL-
адресом этого контента при его отображении.
Контекстная помощь и документация

Нельзя просто предполагать, что редакторы всегда будут понимать все нюансы
модели контента. Изменения содержания могут иметь малозаметные
последствия, которые им может быть трудно отследить после сеанса обучения.
Особенно это касается редко используемых свойств и возможностей.
Системы различаются по своей способности предоставлять редакторам помощь
в самом интерфейсе редактирования. По крайней мере, свойства должны быть
четко обозначены. Возможность предоставить несколько предложений
документации иногда имеет решающее значение.
Например, при представлении сводного поля эти несколько предложений могут
оказаться неоценимыми:
Содержимое, введенное в сводку, будет использоваться вместе с заголовком,
когда на этот контент ссылаются из других мест на веб-сайте. Если оставить
пустым (не рекомендуется), для резюме будет использоваться первый абзац
основного текста.
Если есть что-то, что ненавидит редактор, так это незнание, что делать, и
застревание. Еще хуже, если вы что-то делаете, и это вызывает
непредвиденные побочные эффекты или даже ошибку. Контекстная
документация значительно снижает неопределенность, а также связанные с
этим вопросы и разочарование.
Перспектива: Редакторы Воля Обойти БедныйИнструменты
Рахель Энн Бэйли
Великая ирония систем управления контентом заключается
в том, что они фактически не управляют контентом. Как
отмечает Дин, они управляют редакционным потоком
работы. В этом и заключается проблема.
Потому что инженеры, разрабатывающие интерфейсы
редактирования, на самом деле не понимают, с какими
трудностями сталкиваются редакторы контента при
создании контента для нескольких продуктов, аудиторий,
каналов и т. д.
рынках и регионах, интерфейсы редактирования, как правило, недостаточно
развиты. Интерфейсы полагаются на рабочий процесс, чтобы компенсировать
недостатки фактического управления контентом.
Я видел, как писательница «ломала» схему, потому что знала, что, сколько
махинаций потребуется для завершения ее задачи, это будет означать, что она
опоздает на поезд домой. Писатели будут работать в автономном режиме и
копировать и вставлять из Word в интерфейс редактирования. Они будут
избегать ввода метаданных, которые им не понятны, или делегируют «ввод
данных в CMS» самому низкооплачиваемому человеку в команде. Этот человек
будет плохо понимать, какова конечная цель, и будет с удовольствием
выполнять механическую работу по копированию и вставке. Даже когда есть
желание работать внутри системы, обычно приходится много
экспериментировать, чтобы выяснить, какие поля где отображаются и в каких
шаблонах, поскольку предоставляемая документация, как правило, менее чем
полезна.
Дело в том, что если среда редактирования контента не облегчит работу
авторов, они будут делать все, что в их силах, чтобы обойти систему. А почему
бы и нет? Разработчики регулярно говорят мне, что они пишут код, имея в виду
самое простое решение — для них, а не для контента или авторов, которые
используют систему. Это заставляет редакторов контента «работать усерднее, а
не умнее» в течение многих лет после этого.
Единственное предостережение относительно того, как контент создается в
CMS, заключается в том, что эта книга посвящена классу программного
обеспечения, обычно известному как веб-CMS. Класс программного
обеспечения, называемый компонентом (CCMS), на самом деле управляет
контентом, а также рабочим процессом, и больше подходит для использования
разработчиками контента — разрыв между авторами или редакторами и
разработчиками контента так же велик, как разница между визуальными
дизайнерами и проектировщиками программного обеспечения. - эр. В CCMS
публикация набора изменений просто не является проблемой; разработчикам
контента не требуется форматирование для эффективной работы, а среда
редактирования позволяет им структурировать, разбивать на части и помечать
контент весьма сложными способами.
Рахель Энн Бэйли объединяет лучшее из нескольких дисциплин, чтобы
разработать контент-стратегию по-своему. Она была соавторомСтратегия
контента: соединяя точки между бизнесом, брендом и преимуществами (XML
Press).

Управление версиями,Контроль версий и метки
версий
Управление версиями— это действие, при котором содержимое не
перезаписывается изменениями, а вместо этого сохраняется в новой версии
существующего объекта содержимого. Это означает, что отредактированные
объекты контента имеют несколько версий (на самом деле их могут иметь
сотни версий), каждая из которых представляет, как этот объект контента
выглядел в определенный момент времени.
Редакторы могут использовать управление версиями несколькими способами:
• В качестве защиты от неправомерных или злонамеренных изменений.

Управление версиями похоже на резервное копирование в реальном
времени для одного объекта контента.
• В качестве контрольного журнала, чтобы гарантировать, что у них всегда
есть запись о том, какой контент был представлен публике в любой момент
времени, возможно, по юридическим причинам и по соображениям
соответствия.
• Чтобы отделить изменения в контенте от опубликованного в данный
момент контента, чтобы изменения можно было утверждать и планировать
независимо от контента, который в настоящее время отображается для
публики.
• Чтобы можно было сравнить одну версию с другой, чтобы определить, что
изменилось, что полезно для утверждений (обсуждается далее в этой
главе).
Некоторые системы делают управление версиями автоматическим, в то время

как другие требуют, чтобы оно указывалось по типу контента. Некоторые
системы версионируют только контент, а другие — все — контент,
пользователей, медиа и настройки.
В любой момент времени редактор должен иметь возможность просматривать
график изменений содержимого объекта и видеть, кто и когда изменил
содержимое. Некоторые системы идут еще дальше, позволяя редакторам
сравнивать версии либо в параллельных окнах, либо иногда в стиле
«Отслеживание изменений», где добавления, удаления и изменения
отображаются в строке.
Концептуально версии становятся «стеком», уходящим в прошлое. Исходная
версия контента находится в нижней части стека, а новые версии — поверх нее.
Версии обычно помечаются статусом, причем одна из версий считается
«опубликованной».
Вы можете представить себе стрелку, указывающую на одну версию в стеке,
которая является опубликованной версией. Это гипотетически, и фактическая
реализация концепции может отличаться, но это удобная метафора,
позволяющая представить взаимосвязь между стеком версий и различными
состояниями содержимого внутри него.
Изменение опубликованной версии означает «откат» к предыдущей версии.
Разные системы справляются с этим по-разному: некоторые просто
перемещают стрелку «опубликовано» на другую версию, а другие копируют
нужную старую версию и делают ее новой.
Управление версиями, контроль версий и метки версий |1 5 1

черновая версия находится на вершине стека (таким образом гарантируя, что
опубликованная версия контента всегда будет последней версией).
Изменения в содержимом считаются новой неопубликованной версией (с
меткой «Черновик» или «Ожидание публикации»), находящейся на вершине
стека. Когда публикуется новая версия, стрелка публикации просто
перемещается. В некоторых системах вы можете редактировать предыдущую
версию, а в других — нет; любое изменение любой версии становится новой
версией на вершине стека.
Логично, что одновременно может быть опубликована только одна версия
контента.Рисунок 8-3 показывает визуальное представление этой концепции.
Рисунок 8-3. Стек версий концептуально представляет собой кучу версий, от

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

по существу вернуться во времени и просмотреть весь сайт так, как если бы
весь контент был откачен до его версии на данный момент.
Почти все версии в управлении веб-контентом являются «последовательными»,
то есть версии объекта контента просто располагаются в порядке датировки.
Однако некоторые более продвинутые системы управления документами
предлагают ветвление, при котором контент может быть разделен на несколько
ветвей: версия 1 может иметь версии 1.1 и 1.2, которая далее делится на 1.2.1 и
т. д. Это очень сбивает с толку большинство редакторов. и требуется только в
сценариях с строго контролируемым документооборотом (например, это часто
встречается при управлении технической документацией).
Даже если вы никогда не используете управление версиями, это удобная
функция, которую можно скрывать в фоновом режиме. Единственной
причиной против использования управления версиями может быть хранилище,
поскольку несколько версий, очевидно, будут занимать больше дискового
пространства.
Управление версиями предназначено для обеспечения безопасности контента,
поэтому возможность удаления или очистки версий обычно недоступна по
умолчанию. Часто можно установить ограничение, и запланированное задание
удалит лишние версии, превышающие этот предел (в случае, если существуют
ограничения на объем хранилища), или разрешение на удаление отдельных
версий может быть предоставлено в виде исключения конкретным редакторам.

Рассматривая управление версиями, помните, что без него право редактировать
— это, по сути, право удалять. Невинная ошибка редактора, который слишком
быстро нажмет кнопку «Сохранить», может иметь катастрофические
последствия.
Даже если вы управляете версиями контента, удаление все

равно остается удалением. Если вы удаляете объект контента,
он обычно исчезает со всеми своими версиями. Когда что-то
удаляется, часто не остается следа версии. Многие системы
выполняют «мягкое удаление» в корзину или корзину, но как
только объект исчезнет оттуда, поймите, что объект и вся его
история версий исчезли.
Контроль
версий
Контроль версий — это управление версиями контента между несколькими
редакторами, работающими одновременно. Если два редактора хотят работать
над одним и тем же контентом, как это сделать? Есть несколько вариантов:
• Создает ли система версию для каждого, называя обе «Черновиком»? Это

может немного расстраивать, поскольку два редактора могут не осознавать,
что кто-то еще работает над тем же контентом. Когда они приступят к
публикации, они поймут, что им необходимо согласовать изменения между
двумя версиями, чтобы контент был правильным.
• Позволяет ли система редактору «заблокировать» объект контента, чтобы
никто другой не мог над ним работать? Это, безусловно, эффективно, но по
сути блокирует рабочий процесс других редакторов, а при случайном
использовании может привести к тому, что часть контента будет
заблокирована дольше, чем необходимо, возможно, даже когда нерадивый
редактор уходит в отпуск.
• Позволяет ли система двум редакторам одновременно работать над одной и
той же версией, как в Google Docs?
По крайней мере, CMS должна иметь некоторую индикацию того, что объект
контента редактируется или что черновая версия этого объекта контента
находится над опубликованной версией в стеке версий. Редактор должен быть
уведомлен об этом и ему предоставлена возможность работать с
существующим черновиком (который может быть заблокирован) или создать
новый черновик (что может потребовать согласования изменений с
существующим черновиком в какой-то момент в будущем).
Управление зависимостями
Два объекта контента могут быть связаны несколькими способами:
• HTML атрибута может содержать гиперссылку на другой объект контента.

• Ссылка на атрибут может ссылаться на другой объект контента.
Управление зависимостями | 153
• Объект контента может быть встроен в форматированный текст другого объекта контента.
• HTML атрибута может содержать встроенный медиафайл, который
является отдельным объектом контента.
Многие CMS отслеживают эти ссылки и их назначение (ссылка HTML, ссылка

на атрибут, вставка мультимедиа и т. д.), поэтому можно узнать, какой контент
зависит от другого контента. Это обеспечивает некоторые полезные функции:
• Проверка перед удалением может сообщить редактору, что контент,

который он собирается удалить, ссылается на другой контент (см.Рисунок
8-4).
• Отчеты о неработающих ссылках могут идентифицировать контент,
который ссылается на цель, которая больше не доступна из-за
принудительного удаления, истечения срока действия контента или
изменения разрешений.
• Отчет об потерянном контенте может идентифицировать контент, не
используемый каким-либо другим контентом.
• Зависимости можно использовать для определения каскадной области
изменений. Например, когда контент публикуется, система может знать,
какой еще контент необходимо повторно опубликовать (в случае
отделенной CMS) или переиндексировать для поиска.
• Поисковая оптимизация может использовать зависимости при взвешивании
страниц результатов, предполагая, что популярный контент упоминается
чаще и должен иметь более высокий вес. Другие функции информационной
архитектуры могут использовать граф ссылок для извлечения информации
из отношений контента.
Рисунок 8-4. Предупреждение об удалении в Sitecore — содержимое, ожидающее
удаления, зависит отдругим контентом, и система должна знать, как
редактор хочет обрабатывать нарушенные зависимости.
Планирование и срок действия контента

Часто редактор не хочет, чтобы контент был опубликован немедленно. Скорее,
контент должен быть запланирован к публикации в будущем.
Это переплетено с управлением версиями, поскольку по сути редактор
занимается планированием изменения меток версий. Содержимое, которое она
планирует, считается черновиком, а метка версии в будущем будет изменена на
«Опубликовано». (Помните нашу концептуальную «стрелку публикации»? Все,
что делает редактор, — это планирует время, когда он переходит к другой
версии в стеке.)
Планирование публикаций имеет две основные формы:
Планированиенового контента
Объект контента не отображается нигде на сайте до момента его
появления.
Планирование новой версии
Объект контента отображается в своей текущей форме до момента, когда
его место займет новая версия.
В некоторых случаях это может быть немного сложно, когда редакторы
начинают работать над новой версией контента до того, как последняя версия
контента будет опубликована. В этих случаях у вас есть опубликованная версия
на несколько уровней назад, затем ожидается одна или несколько версий.
Планирование и срок действия контента |1 5 5

публикации, затем на одну или несколько версий раньше тех, что находятся в
черновиках, и которые затем могут быть запланированы.
А что произойдет, если редактор решит опубликовать новую версию
напрямую? Или планирует его публикацию раньше одной из последующих
версий в стеке версий? Некоторые системы могут этого не допускать, другие
могут запрещать запланированную публикацию всего, что находится за ним в
стеке, а третьи могут просто слепо следовать инструкциям, что означает, что
запланированная публикация фактически переместит стрелку публикации
назад в стеке, а не вперед. .
К счастью, это почти никогда не становится настолько сложным, но плохая
связь между редакторами иногда может привести к сложным логическим
проблемам планирования, в которых бывает сложно разобраться.
Набор измененийПубликация
Часто редакторы работают над проектом контента, который требует внесения
изменений в несколько объектов контента по отдельности. Редакторы хотели
бы, чтобы эти изменения отслеживались как группа, а также планировались,
утверждались и публиковались вместе.
Он известен под несколькими названиями, но чаще всего как набор изменений
(другие распространенные названия — «проект», «выпуск» и «пакет»). Набор
изменений создается со всем связанным с ним контентом. Планируется сам
набор изменений, а не отдельные версии контента. Когда набор изменений
достигает публикации, все объекты контента публикуются одновременно.
Срок действия контента

К счастью, срок действия контента немного проще. В определенный момент
времени контент просто удаляется из публикации. Это означает, что наша
воображаемая стрелка полностью исчезает из стека, и ни одна версия контента
не считается опубликованной. Это не удаление. Контент все еще существует,
просто его нельзя просмотреть.
Единственное предостережение здесь заключается в том, что автоматическое
удаление контента с сайта может вызвать некоторые проблемы, когда редактор
недоступен для уведомления. Например, при попытке удалить контент
напрямую редактор может быть уведомлен о том, что контент связан с
несколькими другими объектами контента и что его удаление приведет к
разрыву этих связей. Если срок действия контента истекает без присмотра,
ссылки могут сломаться автоматически и без предупреждения.8
8 Однажды у меня был клиент, которого беспокоил именно этот сценарий. Хотя логическую проблему
нельзя было решить, если не считать простого запрета истечения срока действия для объектов, на
которые были направлены ссылки, мы создали запланированное задание, которое каждую ночь
отправляло веб-мастеру электронное письмо, если оно обнаруживало контент, который (1) был
целью одного или более ссылок, и (2) срок действия истекает в течение следующих 72 часов. По
крайней мере, это дало клиенту некоторое предупреждение, чтобы он мог разрешить ситуацию
изящно, а не допустить разрыва ссылок.

Рабочий процесс и утверждения
Рабочий процесс — это логическое движение объекта контента через
различные шаги или этапы (хотя в дальнейшем мы не будем использовать
слово «этап», чтобы не путать его с жизненным циклом контента,
обсуждавшимся ранее). Рабочий процесс часто путают с утверждениями, и они
сильно пересекаются, поэтому мы обсудим оба.
После того как редактор внесет изменение в контент, он может опубликовать
его напрямую или ему, возможно, придется отправить изменение на
утверждение. Многие системы разделяют разрешения на редактирование и
публикацию. Если редактор может редактировать, но не публиковать, он может
внести изменения, но опубликовать их может только тот, у кого есть такое
разрешение.
Концептуально редактору нужен способ сообщить: «Я закончил работу над
этим контентом, но не могу опубликовать его напрямую. Кто-то, кто может
опубликовать его напрямую, должен просмотреть контент и опубликовать его
для меня».
Необходимо решить два вопроса:
• Кто получает уведомление?

• Как они уведомляются?
В первом случае можно указать «пользователя-владельца» (или группу

пользователей) для получения уведомлений об изменениях или материалах. В
других случаях любой редактор, имеющий разрешение на публикацию, может
быть уведомлен. В других случаях создаются конкретные рабочие процессы
(см. следующий раздел), в которых определяется ответственная сторона.
Уведомление обычно обрабатывается по простой электронной почте или через
систему управления задачами CMS (обсуждается в разделе«Сотрудничество»
на странице 160.), что также может создать электронное письмо.
Рабочий процесс
Как правило, рабочий процесс — это более масштабное и абстрактное понятие,
чем простое утверждение. Утверждение контента может быть разновидностью
рабочего процесса, но многие рабочие процессы не имеют ничего общего с
утверждением контента. Рабочий процесс шире, чем простое утверждение.
Рабочий процесс — это перемещение контента по карте или сети отдельных
шагов. Шагом рабочего процесса может быть практически любой процесс,
который выполняет какое-либо действие перед перемещением содержимого на
другой шаг. Как правило, контент может находиться только на одном этапе в
любой момент данного рабочего процесса. Шаг рабочего процесса (иногда
называемый «действием» или «задачой») — это четкая граница, определяющая
состояние, в котором находится контент в определенный момент времени.
Рабочий процесс и утверждения |1 5 7

Некоторые примеры:
• Контент на каком-то этапе ожидает, пока редактор одобрит его переход к

следующему этапу, на котором он будет опубликован. На этом этапе он
может ждать три минуты или три дня, в зависимости от того, сколько
времени потребуется редактору, чтобы выполнить действие, необходимое
для продолжения работы.
• Содержимое перемещается на этап, который запускает выполнение кода
для публикации сводки содержимого в Twitter. Когда это будет завершено,
содержимое автоматически перейдет на следующий шаг.
• Контент ожидает, пока переводчик завершит перевод контента на
испанский язык. Когда это будет сделано, переводчик обозначит это
завершение и перенесет контент на следующий шаг, что создаст задачу для
рецензента.
Во всех случаях один или несколько шагов не будут иметь последующего шага,
что завершает рабочий процесс. Любой контент, находящийся в данный
момент на этапе, находится в активном рабочем процессе, и когда контент
проходит последний шаг, рабочий процесс завершается.
Важно различать шаблон рабочего процесса и фактически запущенный
рабочий процесс. Номенклатура различается, но, как и контент, рабочие
процессы имеют типы (шаблоны) и фактические экземпляры этих шаблонов,
которые в настоящее время работают с контентом.9
Например, организация, публикующая новости, может иметь рабочий процесс
утверждения новостей, который перемещает контент из состояния
«Отправлено» в состояние «Опубликовано». Это шаблон, определяющий, как
должен работать рабочий процесс. В загруженном отделе новостей статьи
могут отправляться на публикацию каждые 5 минут, поэтому, хотя существует
один шаблон рабочего процесса утверждения новостей, в любой момент
времени может быть 20–30 активных экземпляров этого рабочего процесса,
каждый из которых перемещает отдельные элементы контента через этапы к
публикации. .
Многие системы имеют интерфейсы отчетов для просмотра всех запущенных
экземпляров определенного рабочего процесса, включая этап, на котором в
данный момент находится контент. В некоторых случаях контент может
«застревать» на этапе рабочего процесса, что означает, что он ожидает
действия. этого никогда не произойдет по какой-либо причине. Контент,
застрявший в рабочем процессе, обычно можно доработать вручную или
принудительно завершить рабочий процесс.
Хотя это не является обычным явлением для большинства организаций,
контент может даже использоваться более чем в одном рабочем процессе
одновременно. Например, новостная статья может находиться в рабочем
процессе «Утверждение новостей» и в то же время находиться в рабочем
процессе «Запрос СМИ» в ожидании фотографии.
Что представляет собой этап рабочего процесса, может быть неясно и во
многом зависит от того, что позволяет конкретная система. В некоторых
случаях этапы рабочего процесса представляют собой только утверждения,
выполняемые человеком.
9 Хотя было бы удобно называть их «типами рабочих процессов» вместо «типов контента»,
похоже, в отрасли принято называть их «шаблонами рабочих процессов».

(одна система даже называет рабочие процессы «цепочками одобрения»), в то
время как в других случаях может происходить множество заранее
подготовленных действий и действий, и многие из них допускают выполнение
произвольного кода.
Внешний СобытиеДвигатели
Есть некоторые интересные вещи, происходящие в мире
внешних механизмов событий, которые представляют собой
коммерческие службы, которые могут уведомляться о
событиях, а затем выполнять действия в других системах. Эти
системы, такие какЗапир иЕсли это, то то, может быть вызван
такими вещами, как веб-перехватчики (форматированный
HTTP-запрос) или появлением нового элемента в RSS-канале,
и в ответ может выполнять сотни возможных действий в
других системах.
В некотором смысле эти системы определяют общий API
событий для самого Интернета и служат «связующим звеном»
между автономными программными платформами.
Традиционно сложную и дорогостоящую системную
интеграцию можно значительно упростить.
Хотя редакторы склонны рассматривать рабочие процессы как процессы,

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

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

«рабочие действия». По сути, инициатор говорит: «Выполните это действие
над этим контентом», и это действие может не состоять из нескольких шагов.
Скорее, может существовать одно концептуальное действие, которое
происходит в определенный момент времени и затем заканчивается.
Очевидно, что рабочий процесс — это широкое и расплывчатое понятие,
которое не поддается попыткам дать четкое определение. 10 То, что в одной
системе называется «рабочим процессом», может быть простыми
утверждениями в другой или событиями уровня кода в третьей. Кроме того,
объем и функциональность события рабочего процесса сильно различаются.
Некоторые системы позволяют использовать рабочий процесс только для
утверждений, другие
10 Если вас интересует рабочий процесс как общий процесс,Веб-сайт шаблонов рабочих процессов —
это проект двух университетов, «предлагающий концептуальную основу для технологических
процессов». По крайней мере, сайт демонстрирует, что рабочий процесс — это дисциплина, которая
возникла и практикуется далеко за пределами управления контентом.
Рабочий процесс и утверждения |1 5 9

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

Сложные утверждения контента — это белый кит в управлении контентом. На
этапах планирования и продаж проекта редакторы часто обсуждают свою
острую потребность в длительных и сложных рабочих процессах, полных
критически важных утверждений и процессов, со сложной логикой ветвления и
автоматизированным сотрудничеством и аудитом.
В действительности такие сценарии практически никогда не случаются. Я
полностью уверен, что 95% утверждений контента — это простые
последовательные рабочие процессы, и 95% из них состоят из одного шага.
Редактор отправляет контент для публикации, а утверждающий публикует его.
Фактически, в большинстве случаев рабочий процесс даже не участвует в
процессе, а утверждение полностью осуществляется с помощью разрешений.
Удаление разрешения на публикацию у одного редактора и предоставление его
другому фактически приводит к одноэтапному последовательному
утверждению рабочего процесса.
В других случаях неформальный рабочий процесс происходит за пределами
CMS и состоит из того, что редактор кричит своему менеджеру: «Эй, можешь
прийти посмотреть на это и сказать мне, могу ли я это опубликовать?» Нет, это
не сложно, но часто именно так и происходит.
Я даже знаю CMS, которая изменила свою архитектуру, чтобы гарантировать,
что неопубликованному контенту будет присвоен частный URL-адрес
специально для учета повсеместного сценария, когда редактор отправляет
кому-то ссылку по электронной почте с пометкой: «Можете ли вы посмотреть
это и убедиться все нормально?" По сути, это одобрение по электронной почте.
Хотя я признаю, что существуют ситуации, когда рабочий процесс и
утверждение могут усложняться и действительно усложняются (юристы могут
сделать это с организацией), я утверждаю, что рабочий процесс — это
единственный наиболее переоцененный аспект любой CMS. Поразительная
сумма денег была потрачена впустую на реализацию гипотетических фантазий
о рабочих процессах, которые просто никогда не увидят свет. И в случае, если
они когда-либо действительно будут реализованы, объем контента,
проталкиваемого через них, должен будет быть очень большим и
продолжительным, чтобы оправдать затраты на их реализацию.
Если вы не сотрудник New York Times, лучше всего, чтобы ваши цели в рабочем процессе были
скромными.
Сотрудничество
В сценариях с несколькими редакторами часто возникает необходимость
указать единицу работы или провести сеанс обсуждения или совместной
работы, конкретно связанный с частью контента.

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

объекту контента или набору изменений. Редактор может создать задачу
под названием «Обновление политики конфиденциальности», затем
прикрепить этот объект контента к задаче и назначить его другому
редактору. Это часто вписывается в рабочий процесс, поскольку сам
процесс создания задачи мог бы создать рабочий процесс. Альтернативно,
рабочий процесс может активно использовать подсистему задач при
уведомлении редакторов об ожидающих утверждениях. В некоторых
случаях задачи, прикрепленные к объекту контента, можно просмотреть в
административном интерфейсе этого объекта.
• Возможность оставлять заметки для других редакторов относительно
конкретного контента; предоставлять примечания к конкретным версиям с
объяснением того, что было изменено; или проводить
многопользовательские обсуждения контента.
• Возможность хранить редакционные метаданные (в случае, если вы хотите,
чтобы эти данные были отделены от фактической модели контента).
• Возможность вести групповые чаты в режиме реального времени в интерфейсе CMS.
Очевидно, что эта функциональность во многом пересекается с инструментами,

не относящимися к CMS, которые могут использовать редакторы, такими как
Slack, Skype, Exchange и даже электронная почта. Конкретным отличием
является возможность привязывать эти обсуждения и задачи к конкретному
контенту и вносить изменения в него, а также отображать эту информацию в
интерфейсе CMS. В контексте CMS эти функции учитывают контент и могут
быть направлены в отношении него.
Однако, как и в случае с рабочим процессом, стоит отметить, что эти функции
используются нечасто. Инструменты для совместной работы внутри CMS не
являются основной целью программного обеспечения, и их функциональность
не сможет конкурировать со специальными инструментами для совместной
работы, которые ваша организация, вероятно, использует каждый день.
Предоставленные самим себе, редакторы обычно обращаются к таким вещам,
как электронная почта и групповой чат, чтобы работать над контентом с
другими редакторами.
Ключом к оценке полезности системы совместной работы CMS является
определение преимуществ, которые она дает при внедрении в CMS. Иногда
близость к контенту приносит хорошие преимущества. Но во многих случаях
преимущества не стоят разрушения еще одной среды совместной работы.
Сотрудничество |1 6 1
Содержание ФайлУправление
Файлы содержимого — это файлы (обычно двоичные 11), которые
поддерживают редакционный процесс. Это изображения, файлы PDF,
документы Word или другие загрузки, которые не представляют собой
структурированный, смоделированный контент, но доставляются CMS в виде
полностью неповрежденных файлов.
Во многих системах файлы представляют собой контент «второго сорта». Вы
можете управлять ими, но более элементарно, чем «первоклассным» контентом
(смоделированными типами контента). В таких случаях в двоичных файлах
часто отсутствуют следующие функции:
• Детализированные разрешения
• Рабочий процесс
• Языковой перевод
• Метаданные или дополнительные смоделированные данные
• Персонализация
В более чистой и функциональной реализации двоичные файлы представляют

собой просто управляемые типы контента, как и любые другие, с одним
дополнительным свойством — содержимым самого двоичного файла. Таким
образом, файл «заворачивается» в полноценный объект контента, позволяющий
моделировать дополнительную информацию (уведомление об авторских
правах, подпись к изображению и т. д.), рабочий процесс, разрешения и т. д.
Добавление СодержаниеФайлы
До последних нескольких лет браузеры никогда не были лучшими в загрузке
файлов, и веб-CMS были связаны этими ограничениями. Загрузка десятков
файлов была утомительным занятием: редакторам приходилось вручную
переносить один файл за другим.
Простая загрузка файлов по-прежнему работает и доступна, но теперь
существуют более эффективные методы загрузки файлов в вашу CMS. К ним
относятся:
Перетащите
Многие системы позволяют редакторам просто перетащить один или
несколько файлов в окно браузера в указанное место интерфейса. Все
файлы будут загружены одновременно.
Псевдо файловая системадо ст у п
Некоторые системы поддерживают протоколы, позволяющие обращаться к
хранилищу как к файловой системе. Пользователи могут иметь
возможность «сопоставить диск» с CMS или получить доступ к системе.
11 Многие системы называют файлы содержимого «двоичными файлами», хотя технически они не обязаны быть двоичными.
Например, ничто не мешает редактору загрузить текстовый файл в CMS (и даже текстовый файл на
каком-то уровне можно считать «двоичным файлом»).

через FTP-клиенты или клиенты WebDAV. Кроме того, когда репозиторий
доступен изначально для файловой системы, автоматизированным
процессам гораздо проще загружать файлы содержимого — например,
запланированный сценарий может копировать файлы в систему каждую
ночь.
Интеграция внешнего репозитория
Многие системы имеют «коннекторы», которые предоставляют доступ к
другим репозиториям CMS, таким как системы DAM, системы ECM или
даже удаленные сервисы, такие как Amazon S3 или Dropbox. Редакторы,
работающие с контентом, могут, например, иметь возможность вставлять
изображения непосредственно из библиотеки SharePoint без необходимости
предварительной их загрузки.
Ассоциация контента
Файлы отличаются от другого контента тем, что они редко существуют
изолированно. Чтобы получить доступ к файлу, пользователю необходимо
перейти к другому контенту, а загрузка файла почти всегда представлена
ссылкой на HTML-странице (которая, скорее всего, представлена объектом
контента).
Рассмотрим, как вы обычно загружаете файлы. Если кто-то не отправил вам
прямую ссылку по электронной почте, как часто вы переходите
непосредственно к загрузке файла, не касаясь других страниц веб-сайта?
Обычно вы заходите на страницу загрузки, а затем нажимаете ссылку для
скачивания.
Кроме того, многие файлы контента служат исключительно для поддержки
определенного контента. Фотогалерея будет содержать несколько
изображений, которые она отображает. Эти изображения не могут
использоваться где-либо еще на сайте и служат только для поддержки этой
единственной фотогалереи.
Это означает, что файлы часто связаны с конкретным содержимым — они
«привязаны» к этому содержимому и работают под одной и той же защитой. В
этих случаях объектами контента и поддерживающими их файлами следует
управлять как пакетом.
Например:
• Файлу, связанному со страницей контента, возможно, потребуется отразить

разрешения этой страницы. Если страница доступна только вошедшим в
систему пользователям, файл должен иметь такое же ограничение. Если
разрешения страницы изменяются, права доступа к файлам также должны
измениться.
• При выборе файлов для связывания или вставки редакторы должны иметь
возможность изолировать этот выбор от файлов, связанных с этой
страницей, а не просматривать все файлы в системе.
• Когда страница контента удаляется или архивируется, все связанные с ней
файлы должны постичь та же участь. Отсутствие этой функции неизбежно
приводит к созданию огромного архива старых файлов контента,
подавляющее большинство из которых больше не используется CMS.
Управление файлами контента | 163

Многие системы обеспечивают это, имея файлы, которые специально связаны с
другим объектом контента и доступны для использования только этим
объектом, а также допускают глобальные файлы, доступные для всего контента
в системе.
Обработка изображений
Существует разница между самим изображением (оригиналом) и конкретным
файловым представлением этого изображения. Изображение парусника может
потребоваться преобразовать в несколько файлов с разным разрешением и
размером файла для вставки в контент в разных местах.
Многие системы сохраняют исходное загруженное изображение, но создают
его дополнительные версии на основе набора настраиваемых правил, которые
позволяют редакторам и разработчикам шаблонов иметь доступ к нескольким
стилям изображения. Например, после загрузки изображения CMS может
изменить его размер до трех разных размеров.
Это проявляется двумя основными способами:
• При доставке изображения система шаблонов может иметь конструкции

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

предоставляют возможность редактирования изображений вручную (негласная
цель — «Фотошоп в браузере») — с разной степенью эффективности. Простое
редактирование изображений, такое как изменение размера и обрезка, является
обычным явлением, но более глубокие преобразования обычно требуют
редактирования изображений в автономном режиме и могут потребовать
дополнительного обучения редакторов.
Управление изображениями — это одна из областей, в которой

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

отказ редактора от изменения домашней страницы является одновременно
хорошей редакционной политикой и полезен для редактора, который может
случайно вносить глобальные изменения, даже не осознавая этого.
Концепция разрешений в CMS тесно связана (и в значительной степени
заимствована) с системами разрешений, которые использовались в файловых
системах в течение многих лет. Файловые системы Windows и Linux имеют
глобальные модели разрешений с момента их изобретения, и многие
концепции современных CMS основаны на них.
Например, «список контроля доступа» или ACL — это общая концепция
вычислений. Определение из Википедии:
Список управления доступом (ACL) по отношению к файловой системе
компьютера представляет собой список разрешений, прикрепленных к объекту.
ACL определяет, каким пользователям или системным процессам предоставляется
доступ к объектам, а также какие операции разрешены над данными объектами.
В случае CMS «объектом» обычно является объект контента, а не файл на
жестком диске. Многие CMS используют как концепцию, так и номенклатуру
ACL для управления собственными разрешениями.
Разрешение — или, технически, запись управления доступом (ACE), ACL —
это набор ACE, — это пересечение трех вещей:
• Пользователь
• Действие
• Объект
В любой ситуации, связанной с разрешениями, мы должны спросить себя: (1) кто пытается,
(2) какое действие совершить, (3) над каким объектом? ACE, включенный в
ACL, определяет, что разрешено.
Авторизацияпротив аутентификации
Разрешения технически представляют собой авторизацию, то
есть предоставление пользователям возможностей. Это не то
же самое, что аутентификация, которая представляет собой
процесс проверки того, кто является тем, кем он себя называет.
Мы могли бы целый день говорить о том, чтобы разрешить
Мишель предпринять какие-то действия, но на самом деле мы
этим не занимаемся. Фактически мы разрешаем учетной записи
пользователя Мишель предпринять некоторые действия. Мы
просто надеемся, что учетная запись пользователя, которую мы
знаем как Мишель, в любой момент времени контролируется
человеком, которого мы знаем как Мишель.
Процесс аутентификации этого пользователя и подтверждения
его личности путем входа в CMS — это совершенно отдельная
система и дисциплина, отличная от той, которая разрешает ему
делать что-то, когда он находится внутри.
Разрешения |1 6 5
Пользователи
Во-первых, мы должны определить пользовательский контекст, в котором
будет происходить действие. Для этого мы должны учитывать роли и
разрешения. Например:
• Редактору Фреду предоставлено разрешение на редактирование политики

конфиденциальности, но не разрешение на публикацию.
• Корпоративный юрисконсульт Мэри получила разрешение на публикацию
политики конфиденциальности.
Пользователей можно идентифицировать напрямую (Мэри и Фред в

предыдущих примерах) или по группам. Группа или роль — это совокупность
пользователей. Пользователи назначаются группе или считаются «входящими»
в эту группу. Если группе предоставлено разрешение, то это разрешение
получает любой пользователь, являющийся членом этой группы.
Таким образом, мы можем скорректировать наши предыдущие примеры следующим образом:
• Любой из группы «Редакторы»было предоставлено разрешение на

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

Как правило, разрешения всегда следует назначать по группам, даже если в
этой группе находится только один пользователь. Разрешения обычно связаны
с ролью, которую кто-то выполняет, а не с этим пользователем как конкретным
человеком.
Например, если публикации в блоге генерального директора должны быть
одобрены генеральным директором Джессикой, это потому, что она… ну,
Джессика? Нет, очевидно, это потому, что она генеральный директор, и если
она когда-нибудь перестанет быть генеральным директором, то она должна
лишиться этого разрешения. Разрешение принадлежит роли генерального
директора, а не лицу, выполняющему эту роль.
В этой ситуации было бы вполне уместно создать группу под названием
«CEO», поместить в нее Джессику в качестве единственного участника и
назначить группе права доступа. Когда Тилли свергает Джессику в результате
переворота и берет на себя контроль над компанией, мы просто удаляем
Джессику из группы генеральных директоров и добавляем Тилли в группу, и
Тилли принимает на себя все полномочия Джессики. [Здесь вставьте
маниакальный смех.]
Обычно существует группа «Анонимные» или «Все», которая

представляет всех посетителей, не прошедших
аутентификацию в системе. Защита контента обычно
заключается в настройке разрешений для этой группы —
например, удаление доступа на чтение из группы
«Анонимные» и предоставление его только группе
«Прошедшие проверку пользователи».

Управление группой может оказаться сложным. В некоторых случаях группы
могут содержать другие группы. Таким образом, группа корпоративных
юристов может содержать подгруппу под названием «Действительно важные
юристы». Членство в группе «Действительно важные юристы» дает вам все
права и роли более крупной группы корпоративных юристов, а также,
возможно, некоторые дополнительные права.
Кроме того, в некоторых системах существует различие между группами и
ролями. Группы идентифицируют пользователей как участников, а роли
указывают, что они делают.
Например, у вас может быть группа редакторов, в которую вы помещаете всех
своих редакторов, а затем иметь несколько ролей для редактора новостных
статей, редактора мультимедиа и т. д. Разрешения назначаются ролям, которые
затем назначаются группам. Пользователи объединяются в группы, разрешения
объединяются в роли, а затем роли и группы встречаются, чтобы разрешить
выполнение действий.
Да, это может сбить с толку. На самом деле существует целая дисциплина и
теория, называемая управлением идентификацией. Опять же из Википедии:
В вычислительной технике управление идентификацией (IdM) описывает
управление отдельными участниками, их аутентификацией, авторизацией и
привилегиями внутри или за пределами границ системы и предприятия.
Однако в большинстве ситуаций группы и роли просто смешиваются. Даже в
ситуациях, когда они разделены, выгода в большинстве случаев является
просто гипотетической и семантической. Несомненно, существуют сценарии, в
которых дифференциация важна, но она встречается нечасто. В большинстве
систем есть метод агрегирования пользователей и назначения разрешений этим
агрегациям, называются ли они «группами», «ролями» или чем-то еще.
Объекты
В абстрактном смысле «объект» — это все в системе, над чем необходимо
воздействовать. Это включает в себя:
• Объекты контента
• Пользователи
• Типы контента
• Настройки
• Шаблоны
Разные системы имеют разную степень детализации при назначении и

управлении разрешениями на воздействие на разные объекты. Вполне
возможно, что CMS будет иметь сложную структуру групповых/ролевых ACL
для всего. Во многих других случаях разрешения в стиле ACL зарезервированы
для контента, а разрешения на управление другими элементами в
система, как и шаблоны или пользователи, просто бинарна: назначенные люди
могут это делать, а другие — нет.
В большинстве случаев разрешения применяются к контенту. Эти разрешения
предоставляются или запрещаются для определенных объектов, но они редко
назначаются этим объектам напрямую. Разрешения обычно выводятся либо из
типа контента, либо из его местоположения в более широкой географии
контента. Например:
• Пользователь имеет полные права на любой выпуск новостей в любой точке системы.
• Пользователь может создать любой разрешенный объект в разделе «Новости» дерева
содержимого.
Бывают случаи, когда определенный объект контента имеет разрешения,

отличные от другого контента того же типа или в том же месте, но это
случается редко. Определение этих объектов как таковых в долгосрочной
перспективе станет неуправляемым. Поэтому управление разрешениями в
совокупности становится единственным разумным методом.
Во многих случаях разрешения наследуются от какого-либо другого объекта —
часто родительского объекта или папки. Изменение разрешения объекта также
изменит разрешения всех его объектов-потомков, если только этот потомок не
был специально объявлен с целью «разорвать» это наследование и управлять
своими собственными разрешениями (в этот момент он может стать целью
наследования объекта). его дочерние объекты). Это уместно, поскольку
разрешения часто основаны на местоположении, и это эффективно
распределяет разрешения по ветвям дерева.
Это пример моделей разрешений CMS, часто имитирующих файловые
системы. Например, в Windows новый файл наследует разрешения
содержащейся в нем папки, если только это соединение не разорвано
специально. Многие CMS используют одну и ту же логическую модель.
Действия
Как только мы узнаем пользователя и объект, над которым нужно действовать,
нам нужно разрешить или запретить определенные действия. Хотя
пользователь может иметь так называемый «полный контроль» над объектом
(фраза, заимствованная из модели разрешений Windows), существует большая
вероятность того, что возможности редактора будут ограничены.
Некоторые из наиболее распространенных разрешений в отношении объекта контента:
• Создание контента определенного типа

• Редактирование объекта контента
• Публикация объекта контента
• Просмотр неопубликованного объекта контента
• Откат к предыдущей версии объекта контента
• Инициирование определенного рабочего процесса для типа объекта контента
• Редактирование одной спецификации объекта определенного типа
• Так называемое «мягкое удаление» объекта путем перемещения его в корзину или корзину.
• Безвозвратное «жесткое удаление» объекта контента
В разных системах разная степень детализации разрешений, которые могут

быть назначены объекту. Некоторые имеют только двоичный доступ — вы
либо можете создавать/редактировать/публиковать контент, либо нет. Другие
имеют чрезвычайно детальный контроль над конкретными действиями.
Некоторые действия могут предполагать другие действия. Возможно, право на
публикацию контента также дает право на его создание и редактирование, хотя
можно представить себе ситуации, когда это неприменимо. Аналогично,
редактору может быть предоставлено право удалять контент, но ничего с ним
не делать, хотя представить реалистичный сценарий использования для этого
сложнее.
Некоторые системы также являются расширяемыми, что позволяет
разработчикам создавать свои собственные разрешения для управления
настройками и расширениями, которые они записывают в CMS.Рисунок 8-5
показывает один из интерфейсов разрешений в Sitecore CMS, который
обеспечивает детальный контроль.
Рисунок 8-5. Один из нескольких интерфейсов разрешений в Sitecore —

разрешения могут быть разрешены или запрещены как для контента, так и для
административных объектов, а разрешения «каскадируются».вниз по дереву к
дочерним объектам, если не переопределено
РазрешениеРешение конфликта
Разрешения могут быть сложными, особенно когда разные правила вступают в
конфликт. В этих случаях каждая система будет иметь определенный метод
разрешения.
Например, некоторые системы упрощаются, предлагая только разрешения
«Разрешить», но другие также имеют явные разрешения «Запретить», которые
часто имеют приоритет над «Разрешить». Кроме того, могут вступить в силу
правила наследования. Имеет ли унаследованное разрешение приоритет над
явным разрешением? Обычно нет; однако, поскольку Deny часто имеет
приоритет над Allow, унаследованный Deny может отменять явное Allow.
Все зависит от системы и от того, как эта система реализует свою модель
безопасности. Чем проще вы сможете сохранить свою модель разрешений, тем
лучше. Более распределенная редакционная база требует более сложных
разрешений, что может привести к созданию некоторых сложных моделей и
иногда к расширенной отладке, когда редактор не может делать то, что он
должен делать.
Последствия ошибок разрешений могут быть быстрыми и

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

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

• Есть ли выделенный административный интерфейс?
• Существуют ли контекстные инструменты редактирования для проверенных редакторов?
• Как контент представлен и организован для просмотра и выбора?
• Как можно организовать и сгруппировать контент для редакторов?
ТипВыбор
• Как редакторам предоставляются типы для создания? Является ли
интерфейс удобным и полезным? Как он будет масштабироваться для
потенциально десятков различных типов контента?
• Могут ли доступные типы быть ограничены ролью редактора?
• Могут ли доступные типы быть ограничены по происхождению или местоположению в
географическом регионе?
Предварительный просмотр контента

• Можно ли просмотреть контент перед публикацией?

• Можно ли редактировать контент в режиме предварительного просмотра?
• Может ли редактор выбрать несколько режимов предварительного
просмотра, чтобы увидеть, как контент будет выглядеть в разных каналах?
• Может ли редактор подделать демографическую информацию или
информацию о сеансе, чтобы вызвать различные состояния
персонализации?
Интерфейс редактирования
• Насколько удобны элементы редакционного интерфейса?
• Какие элементы интерфейса можно выбрать и настроить для каждого типа недвижимости?
• Как можно проверить контент во время входа? Какой уровень контроля
доступен для сообщений об ошибках?
• Доступна ли контекстная справка, помогающая редакторам во время создания контента?
• Как можно настроить интерфейс редакции? Можно ли удалить
функциональность на основе роли? Можно ли добавлять ссылки, кнопки и
другой функционал?
Управление версиями, Версия Контроль, Планирование, иСрок действия

• Содержит ли вообще версию системы? Это необязательно или обязательно?
• Является ли управление версиями последовательным или ветвящимся?
• Можно ли откатить контент до предыдущей версии?
• Как можно сравнивать версии?
• Можно ли запланировать публикацию нового контента?
• Можно ли запланировать публикацию новой версии существующего контента?
• Можно ли запланировать срок действия контента?
• Существует ли понятие архивирования и что оно означает? Действительно
ли контент перемещается в другое географическое место? Оно удалено?
Можно ли его вернуть?
Рабочий процесс иРазрешения

• Каков процесс утверждения контента?
• Можно ли получить одобрение путем простого манипулирования разрешениями?
• Как определяются утверждающие лица для конкретного контента?
• Как утверждающие уведомляются о том, что есть контент, ожидающий их рассмотрения?
• Есть ли механизм рабочего процесса?
Обзор редакционных инструментов |1 7 1
• Как создаются рабочие процессы? Из интерфейса? Из кода? По конфигурации?
• Что представляет собой этап рабочего процесса? Существуют ли заранее
определенные действия, которые можно выполнить на этапе? Можно ли
настроить эти шаги?
• Есть ли система управления задачами? Чем это отличается от инструментов
совместной работы, не относящихся к CMS, которые ваша организация
использует сегодня?
Управление файлами контента

• Можно ли управлять файлами контента из CMS?
• Могут ли эти файлы быть связаны с определенным контентом?
• Можно ли синхронизировать их разрешения, а также архивирование/удаление с
контентом?
• Как загружаются файлы? Есть ли функция массовой загрузки?
• Можно ли подключить внешние файловые хранилища к CMS?
• Какие функции автоматической обработки изображений доступны?
• Какое редактирование изображений в браузере доступно?
• Какой уровень разрешений предлагает система, помимо двоичного доступа
«полного контроля»?
• Как можно агрегировать пользователей? Предлагает ли система как группы, так и роли?
• Как можно идентифицировать контент для применения разрешений? По
местоположению в географии? По типу контента?
• Может ли контент наследовать разрешения из другого места или объекта
или ссылаться на них, или все разрешения применяются напрямую?
• Какие типы разрешений доступны?
ГЛАВА9
Выход и ПубликацияУправление
Есть забавный мультфильм «Дальняя сторона», показывающий группу людей в

студии каратэ. Из окна видно, как на улице приземлилась летающая тарелка, а
по пандусу спускаются «инопланетяне», сделанные из кирпичей и досок,
готовящиеся терроризировать город.
Подпись гласит:
Класс внезапно прекратил занятия. Здесь появилась возможность не только
применить свои навыки, но и спасти весь город.
Подразумевается, что ученики каратэ были очень искусны в разбивании досок
и кирпичей и никогда не ожидали, что у них будет шанс использовать эти
навыки, чтобы действительно сделать что-то продуктивное в реальном мире.
То же самое касается и нашей CMS. Теперь мы подошли к моменту, когда нам
нужно вывести некоторый контент для потребления посетителем. До этого
момента мы в основном тренировались. Мы смоделировали наш контент,
определили, как объединить его в группы, и определили редакционные
инструменты, необходимые для того, чтобы наши редакторы могли с ним
работать.
Единственное, чего мы не сделали, так это не опубликовали это. Чтобы
обеспечить ценность, система управления веб-контентом должна в какой-то
момент генерировать веб-контент. Нам нужно вывести абстрактное понятие
контента из нашей CMS в такую форму и место, где оно принесет пользу.
Другими словами, пришло время выбраться из студии, сломать несколько
досок и спасти город.
The Разница Между Содержание иПрезентация

Как я уже говорил ранее, существует тенденция взглянуть на новостную
статью, которую вы смоделировали с помощью своей CMS и вывели в окно
браузера, и сказать: «Это мой контент».
173
Но это не так. Это веб-страница. Просто случайно отображается ваша
новостная статья. Ваша новостная статья и веб-страница, на которой она
находится, — это не одно и то же.
Что, если вы опубликуете ту же статью (в сокращенном виде) в Твиттере? Это
будет ваша новостная статья? Нет, это будет твит, просто отображающий
информацию, отличную от вашей статьи.
Дело в том, что одна и та же статья может быть опубликована в 20 различных
каналах распространения, и ваш веб-сайт будет лишь одним из многих. В
каждом из них создается новый артефакт презентации с использованием
информации из вашей новостной статьи. Эти артефакты не являются вашей
новостной статьей; это просто вещи, созданные из этого.
Статья может даже быть представлена на одном сайте по-разному. Например,
хотя статья имеет «основной» вид, в котором читатель может просмотреть ее
целиком, она, скорее всего, появится в какой-то другой форме на нескольких
страницах со списком новостей, где используются только заголовок, краткое
содержание и, возможно, изображение. А что будет, когда статья появится в
результатах поиска? Это еще одна презентация той же статьи.
Ключевым моментом здесь является отделение вашего контента в чистом виде
— его необработанных, голых данных — от способов его использования. Ваша
статья может состоять из следующей информации (атрибутов в модели
контента):
• автор
• Тело
Это чистый контент, из которого состоит статья. Также может потребоваться

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

значения для «духа» или сути новостной статьи. Он существует просто для
того, чтобы помочь перевести вашу новостную статью в формат, необходимый
для одного или нескольких каналов.
В конце концов, имеет ли это значение? Во многих случаях нет, это всего лишь
академический аргумент. Но продолжая, важно отметить разницу между
контентом и презентацией, в которой он отображается. Некоторые практики
универсальны для обоих, тогда как другие имеют смысл только в контексте
одного или другого.
174 | Глава 9: Управление выводом и публикациями

Шаблонизация— это процесс генерации результатов на основе управляемого
контента. В самом общем смысле вывод будет представлять собой строку
текстовых символов, обычно HTML. Реже CMS генерирует двоичный контент,
например PDF-файлы.
Номенклатура:Шаблон против типа

Имейте в виду, что некоторые системы используют «шаблон»
для обозначения того, что мы называем типами контента.
Например, в Sitecore ваша модель новостной статьи называется
шаблоном, а шаблоны (которые мы обсуждаем здесь)
называются рендерингами.
Такое использование не соответствует номенклатуре данной
книги. Я не говорю, что это неправильно; он просто другой,
менее распространенный и мог бы вызвать значительную
путаницу на следующих нескольких дюжинах страниц, если
бы вы об этом не знали.
Для целей этой книги шаблон — это набор кода, применяемый
к объекту контента для генерации выходных данных.
CMS объединяет две вещи для получения результата:
• Код шаблона или текст, введенный разработчиком, обычно создается и

хранится в файле. Различные шаблоны создают разные выходные данные.
Один шаблон может создать веб-страницу, а другой — твит (см.Рисунок 9-
1).
• Управляемый контент или текст, управляемый редактором, созданный и
сохраненный в CMS. Комбинация того и другого представляет собой
окончательный визуализированный результат.
Рисунок 9-1. Для одного и того же объекта контента предоставляется

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

то, в чем заключается эта дихотомия. Какая часть визуализированного вывода
должна создаваться и управляться разработчиком в шаблоне, а какая часть
должна создаваться и управляться редактором в шаблоне?
Шаблонизация |1 7 5
CMS как контент? Ответ на этот вопрос оказывает огромное влияние на
удобство использования и управляемость конечной системы.
НесущаяСтены
Дом может быть изменен его владельцами. Они могут его покрасить,
переставить мебель и, возможно, даже снести пару стен.
Однако со временем домовладельцы упрутся в несущие стены. Эти стены
удерживают крышу, поэтому их нельзя переместить или снять. Владельцам
просто придется обойти их или вызвать подрядчика для выполнения серьезных
структурных изменений. Архитекторы, спроектировавшие дом, могут повлиять
на его будущую стоимость тем, где они разместит несущие стены, поскольку
они высечены из камня (иногда в буквальном смысле).
То же самое касается реализации CMS. Хотя редактор может изменить макет,
цвета и другие поверхностные аспекты страницы, в конечном итоге он
наткнется на несущие стены. Эти стены — это то, что редакторы не могут
изменить. Им придется либо обойти их, либо вызвать разработчика для
внесения серьезных изменений.
Многие из этих аспектов существуют на уровне шаблона. Разработчик
встраивает в шаблон элементы, которыми нельзя управлять с помощью
контента или интерфейса CMS. Это несущие стены. Сколько их существует и
где они образно расположены, со временем окажет огромное влияние на
Некоторые могут возразить, что редакторы должны иметь как можно больший
контроль над дизайном и макетом страницы, чего можно добиться либо путем
предоставления опций конфигурации для каждого возможного бита вывода,
либо путем предоставления редакторам свободного доступа к шаблонам (часто
из интерфейс CMS). Это редко работает хорошо. Технологии HTML/CSS
продвинулись до такой степени, что неподготовленный человек может нанести
реальный ущерб, если проявит неосторожность.
Кроме того, в большинстве случаев шаблонный контент является
преимуществом, а не ограничением. Как я упоминал ранее при обсуждении
динамической композиции страниц, разрешение редактору изменять страницу
только по эстетическим предпочтениям может нарушить правила стиля сайта, а
также иметь дело с исключениями (например, когда весь контент устроен
определенным образом, за исключением выпуска новостей X). , очень редко
бывает хорошей вещью.
В целом желательно четкое разделение ответственности между кодом
шаблонов и редакционным контентом.
Предупреждение: код вперед
Если вы разработчик, большая часть информации в этом
разделе будет лишней. Несмотря на некоторые отличия,
шаблонизация тесно связана с основным веб-
программированием. Большая часть информации в этом
разделе представляет собой просто краткое введение в эти
концепции.
Если вы не разработчик, вы увидите вымышленный код. Он
вымышленный в том смысле, что это не какой-то реальный
язык, а представитель основных концепций языков
программирования/шаблонов.
Идея здесь не в том, чтобы попытаться превратить вас в
разработчика. Цель состоит в том, чтобы просто дать
представление о некоторых проблемах, с которыми
сталкиваются разработчики при создании веб-сайта с
управляемым контентом.
Не смотрите на это как на практическое руководство. Вместо
этого просто бегло просмотрите концепции и попытайтесь
понять более масштабные логические проблемы, о которых
идет речь.
ШаблонизацияФилософия
Существуют различные школы мысли о сфере применения шаблонов, которые
вращаются вокруг того, какой силой должны обладать шаблоны. Две стороны
спора выглядят следующим образом:
• Шаблоны не должны содержать никаких данных, которые им не

предоставлены напрямую. Шаблонам должен быть предоставлен
определенный набор данных, и они могут форматировать только эти
данные.
• Шаблоны должны иметь возможность извлекать и генерировать данные по
мере необходимости. Это должны быть небольшие инкапсулированные
блоки кода, которые могут при необходимости выйти «вне» самих себя.
Первый вариант явно более ограничивающий. CMS «предоставит» шаблону

некоторые данные, и это все, с чем шаблон должен работать. Аргументом в
пользу этого является ремонтопригодность. Разработчикам шаблонов не
следует разрешать неограниченную логику, иначе это приведет к путанице,
потому что теперь есть еще одно место, где что-то может пойти не так.
Теренс Парр, создатель шаблонизатора StringTemplate, написал на эту тему
целый технический документ. В нем он говорит:
Мантра каждого опытного разработчика веб-приложений одна и та же: ты
долженанализировать бизнес-логику с дисплея. По иронии судьбы, почти все
шаблонизаторы допускают нарушение этого принципа разделения, что и является
стимулом для развития шаблонизаторов HTML.1
1 «Обеспечение строгого разделения модели и представления в шаблонизаторах». Май 2004 года.
Это верная точка зрения. Если шаблон может все, то в каком смысле он вообще
является «шаблоном» и чем он отличается от любого другого кода?
Другая сторона дебатов может возразить, что это ограничивает и что логика,
связанная с представлением, вполне приемлема. Если шаблону необходимо
представить определенный набор данных, шаблону проще получить эти
данные, а не зависеть от вызывающего кода или системы для их
предоставления. Шаблоны существуют только для того, чтобы упростить
включение кода в презентационную разметку, а не для выделения кода по
какой-либо другой причине.
Независимо от вашей позиции, факт заключается в том, что разные системы
применяют разные модели, и многие придерживаются гибридного подхода:
шаблону предоставляется набор данных, но он может выполнять другие
операции по мере необходимости, если это явно не запрещено конфигурацией.
На практике это означает, что большинство шаблонов будут выполняться в
контексте известного набора данных. Данные будут предоставлены, и
большинство операций в шаблоне будут предназначены специально для
форматирования этих данных.
Например, в языке шаблонов Razor ASP.NET MVC структура данных обычно
называется «моделью».2 Эта модель передается шаблону и называется таковой.
Например, чтобы отобразить тег TITLE страницы, этот фрагмент данных
извлекается из модели:
<title>@Model.PageTitle</title>
В Symfony определено несколько переменных, которые передаются в шаблон,
откуда они извлекаются по имени:
<title>{{title}}</title>
Целью здесь является не обзор языков шаблонов, а просто демонстрация того,
что в большинстве ситуаций шаблоны «глупы» и предназначены для действий
на основе предоставленных данных.
Сопоставление URL-адресов и объект оперативного контента

С архитектурной концепцией работы механизма шаблонов тесно связано то,
как CMS определяет, какую информацию предоставить шаблону для работы. В
связанной системе это обычно достигается путем сопоставления URL-адреса с
объектом контента, с которым нужно работать — то, что мы будем называть
оперативным объектом контента.
Рассмотрим входящий URL-адрес:
/politics/2015/debate-report
2 Это и философское, и практическое решение. С философской точки зрения «Модель» — это буква «М»
в слове «MVC». Практически эти данныеупоминается в шаблоне как переменная с именемМодель.
В связанной системе нет каталога «politics» или «2015», а также нет файла с
именем «debate-report». Скорее, этот URL-адрес отображается на объект
оперативного контента. Когда запрос URL-адреса получен, этот объект
контента извлекается, и CMS определяет, какой шаблон должен его
отображать. Этому шаблону передается объект контента (и часто
дополнительные данные) и он выполняется для предоставления вывода,
возвращаемого клиенту.
В предыдущем разделе я сказал, что шаблоны работают в контексте
определенного набора данных. В частности, в отношении управления
контентом можно сказать, что шаблоны обычно выполняются в контексте
оперативного объекта контента.
В Episerver (с использованием Razor) рабочий объект предоставляется как
часть модели в свойстве CurrentPage:
<title>@Model.CurrentPage.Name</title>
В Sitecore (также Razor):
<title>@Html.Sitecore().Field("Title", Sitecore.Context.Item)</title>
В платформе eZ (Symfony и Twig):
<title>{{ ez_field_value(content, 'title') }}</title>
В WordPress (сырой PHP):
<title><?php wp_title(); ?></title>
Обратите внимание, что в WordPress заголовок сообщения определяется до
такой степени, что вам даже не нужно передавать ему объект. Когда вы
вызываете эту функцию, шаблон просто предполагает, что вы имеете в виду
объект оперативного контента.
Дело в том, что объект оперативного контента будет известен и предоставлен
шаблону. В предыдущих примерах этот объект был известен шаблону и
упоминался как Model, Sitecore.Context.Item, content и wp_title()
соответственно.
В отдельной системе, которая записывает файлы в файловую систему, модель
сопоставления URL-адресов меняется на противоположную. Вместо того,
чтобы URL-адрес был получен и сопоставлен с объектом, этот URL-адрес
указывается в объекте и просто используется для создания файла в
соответствующем месте. Другими словами, файл существует до запроса. Когда
запрос получен, он обрабатывается базовым веб-сервером вообще без вызова
CMS.
ШаблонизацияЯзыковая функциональность
Все системы неизменно имеют язык для генерации текстового вывода. Когда
приходит время объединить контент и шаблоны, всегда есть какой-то способ
сделать это. Он состоит из шаблонного кода с маркерами, указывающими, куда
должен идти управляемый контент и как он должен себя вести.
Очень немногие CMS реализуют свои собственные языки шаблонов.
Большинство современных CMS используют существующий
общеупотребительный язык шаблонов в сочетании с некоторыми
пользовательскими расширениями и структурами данных, специфичными для
этой CMS.
В ASP.NET это веб-формы или Razor для проектов MVC. В PHP в настоящее
время очень популярен Twig, а в прошлом активно использовался Smarty (не
говоря уже о простом использовании самого PHP). Для Java популярны
FreeMarker и Velocity.
В языках шаблонов существует три основных «уровня» функциональности. Мы
рассмотрим их дальше.
Простая замена токена

По определению, система всегда будет иметь возможность заменять «токены»
(или «переменные») в коде шаблона управляемым содержимым. Токен — это
просто заполнитель, который заменяется информацией, специфичной для
шаблонируемого объекта оперативного контента.
Рассмотрим следующий полностью гипотетический код:
Название этой статьи — «{article.title}»,
автор — {article.author}.
В этом случае токены представляют собой текст, окруженный разделителями
{ и } (управляющие символы, идентифицирующие код шаблона). 3 Система
знает, что нужно изучить этот код, найти эту конкретную комбинацию
символов и заменить их атрибутами «Название» и «Автор» отображаемой
статьи, например:
Эта статья называется «Схемы миграции птицы додо», ее
написал Боб Джонс.
Помимо простой замены токенов, код шаблона может иметь базовую
фильтрацию вывода, позволяющую влиять на содержимое, заменяющее
токены. Для этого обычно используется символ вертикальной черты (|) (взятый
из старой практики Unix по «перекачиванию» вывода командной строки из
одной программы в другую).
Например:
Эта статья была написана {article.date|"МММ ДД, ГГГГ"}.
В этом случае дата статьи выводится в определенном формате. В зависимости
от платформы «МММ ДД, ГГГГ» может означать «3 сентября 2015 г.». Формат
этой даты определяется тем, что помещается в шаблон редактором шаблона.
3 Опять же, это фикция. В разных языках встраивание кода определяется по-разному, но во всех
случаях в основном будет некоторая комбинация символов, которая определяет содержимое кода, а
не маркетинговое содержимое.

Другие распространенные потребности в фильтрации включают в себя:
• Приведение вывода в денежном формате с двумя десятичными знаками:

Товар стоит {product.price|"$#.##"}.
• В результате вывода будет указано «5 дней назад», а не конкретная дата.
Опубликовано {article.publish_date|relative} назад.
• Это может привести к появлению слова «результат» или «результаты», в
зависимости от того, сколько результатов поиска было доступно.
Есть {search.result_count|pluralize:"result"}.
Замена токенов является основой любого языка шаблонов. Без этого

шаблонизация была бы фактически невозможна.
Ограниченные структуры контроля

Замены токенов не хватает, когда шаблонам необходимо выполнять более
сложную логику, например, повторять действия для нескольких элементов или
решать, выводить ли что-либо на основе критериев. Эти концепции лежат в
основе программирования в целом и известны под общим названием
«структуры управления» или «управление потоком».
Обратите внимание, что существование структур управления в языке шаблонов
никогда не заменяет замену токенов — языки со структурами управления и
логической обработкой, как описано в этом разделе, также всегда будут иметь
возможности замены токенов, описанные в предыдущем разделе. Структуры
управления являются расширением замены токенов.
Двумя основными структурами управления являются:
• Зацикливание
• Ветвление
Рассмотрим этот (опять же гипотетический) код шаблона:

Другие статьи на эту тему включают {article.related_articles}.
Это проблематично, потому что что выводит item.related_articles? Очевидно,
что ему необходимо вывести ссылку на более чем одну статью, но он может
сделать это разными способами — например, в виде маркированного списка
или строки, разделенной запятыми, — и где находится код шаблона, который
диктует это?
На самом деле нам хотелось бы сделать что-то вроде этого:
Другие статьи на эту тему включают:
{foreach связанная_статья в статье.связанные_статьи}
* "{related_article.title}" автора: { linked_article.author}
{endforeach}
Здесь мы создали цикл «для каждого», который представляет собой структуру
управления программированием. Предполагая, что linked_articles является
ссылочным атрибутом для нескольких других статей, этот код будет проходить
через них, и внутри цикла токен linked_article будет полностью заполнен как
объект содержимого статьи, из которого мы сможем выводить информацию.
Мы говорим: «Для каждой статьи в коллекции linked_articles сделайте это…»
Обычно мы можем ссылаться на linked_article только внутри цикла. Вне цикла
— перед foreach или послетокен endforeach — токен linked_article не имеет
значения. Это называется «в объеме». Токен связанной_статьи находится в
области действия только внутри цикла и имеет другое значение во время
каждого прохода или итерации цикла. Вне цикла он не имеет значения (он «вне
области видимости»), и обращение к нему может даже привести к ошибке.
Цикл foreach — это очень распространенная программная конструкция и один
из нескольких способов перебора коллекции элементов. Фактическая
реализация будет варьироваться от системы к системе.
Помимо циклов, нам часто приходится принимать решения о выводе
информации на основе критериев внутри объекта контента. Например, что,
если в статье нет связанных статей? В этом случае свойство linked_articles
будет пустым, и в цикле не будет ничего, и в выводе останется только это:
Другие статьи на эту тему включают:
Это выглядело бы странно и заставило бы посетителей задуматься, не
пропустили ли они что-нибудь. Нужно удалить все, что относится к
соответствующим статьям, если их нет.
В этом случае мы могли бы попытаться сделать что-то вроде этого:
{ifarticle.lated_articles.count > 0}
Другие статьи по этой теме:
{foreach связанная_статья в статье.связанные_статьи}
* "{related_article.title}" автора: { linked_article.author}
{endforeach}
{/endif}
Здесь мы используем структуру управления «если… то». Мы говорим: «Если
количество элементов в атрибуте linked_articles нашей статьи больше нуля,
выполните цикл и отобразите связанные статьи. Если это не так, ничего не
делайте между if и endif». Если в нашей статье нет связанных статей, ничего не
будет выведено, и это то, что нам нужно.
Почти все языки шаблонов имеют возможность использовать, по крайней мере,
примитивные структуры управления. Без них вы ограничены базовой заменой
токенов, которая быстро не сможет справиться даже с базовыми задачами по
созданию шаблонов.

Родной программированиеязык
Код шаблона часто может оказаться сложным. Когда вводятся ветвления и
циклы, шаблоны фактически превращаются в небольшие процедурные
компьютерные программы. Граница между кодом шаблона и реальным кодом
CMS может стать размытой.
Это заставляет некоторых задаваться вопросом: почему вообще существуют
языки шаблонов? Если доступны родные компьютерные языки, почему бы
просто не использовать их? Может показаться глупым или даже
несправедливым заставлять разработчика использовать более примитивный
язык. Базовый язык вашей CMS — например, PHP, C# или Ruby — без
сомнения, может делать очень многое, так почему бы вам просто не создавать
шаблоны на этом языке?
В некоторых случаях это возможно, и это часто вообще устраняет
необходимость в отдельном языке шаблонов. Например, наш исходный пример
замены токена можно было бы записать на PHP следующим образом:
Название этой статьи: «<?php print $article->title; ?>», и она
была написана <?php print $article->author; ?>
Если предположить, что «статья» — это заполненный объект PHP,
представляющий объект оперативного контента, это приведет к тому же
результату, что и предыдущий пример замены токена. На самом деле, многие
системы позволяют это. Фактически, WordPress — самая распространенная
CMS в настоящее время — использует PHP в качестве языка шаблонов.4 Вот
несколько реальных шаблонов WordPress из моего собственного блога:
<a href="<?php the_permalink(); ?>">
<?php the_title(); ?>
</а>
<p class="date"><?php echo get_the_date(); ?></p>
<?php the_excerpt(); ?>
Код между <?php и ?> выполняется интерпретатором PHP.

Так почему же создание шаблонов не осуществляется на полноценном языке
программирования, а не имеется доступ к языку шаблонов?
Вспомни еще разГлава 4, мы определили группу разработчиков, ответственных
за интерфейс веб-сайта — в основном за HTML/CSS и шаблоны. Этот
разработчик шаблона может отличаться от разработчика серверной части или
сервера, ответственного за полную интеграцию CMS. Роли и обязанности
разные. В то время как разработчик серверной части озабочен грандиозной
архитектурой
4 PHP может быть уникален тем, что изначально он был создан с основной целью создания веб-
страниц. Один из моих технических рецензентов заметил: «Я бы сказал, что PHP — это синтаксис
шаблонов, который превратился в язык программирования». В этом есть правда. На корни PHP как
языка веб-шаблонов намекает основная функция под названиемнл2бр, который преобразует
символы разрыва строки в<br/>HTML-тег. Эта функция не имеет никакой цели, кроме генерации
HTML, и присутствует в языке с версии 4, выпущенной в 2000 году.
всей системы, разработчика шаблона интересует только то, как все
отображается.
Таким образом, разработчику шаблонов обычно желательно работать только с
подмножеством функциональных возможностей программирования, а не иметь
доступ ко всему объему и возможностям базового языка программирования,
используемого CMS. Предоставление разработчику шаблонов неограниченного
доступа ко всему языку программирования порождает три проблемы:
• Осложнение
• Безопасность
• Стабильность
Во-первых, языки программирования могут быть фундаментально сложными.

Часто программисту необходимо понимать множество неинтуитивных вещей,
таких как область видимости переменных, разница между ссылочными типами
и типами значений, а также рекурсия. Эти концепции выходят далеко за рамки
того, что необходимо для отображения простой страницы контента.
В 2006 году Тим Бернерс-Ли (основатель самой Всемирной паутины) и Ной
Мендельсон редактировали статью под названием«Правило наименьшей
мощности». Их аннотация гласит:
При проектировании компьютерных систем часто приходится выбирать между
использованием более или менее мощного языка… «Правило наименьшей
мощности» предлагает выбирать наименее мощный язык, подходящий для данной
цели.
Большая мощность почти всегда предполагает большее усложнение, и
большинство языков программирования предназначены для решения задач,
более сложных, чем использование шаблонов.
Выделенный язык шаблонов может быть специфичным для предметной
области, то есть он знает о своем предполагаемом использовании и может
содержать конструкции и концепции, предназначенные исключительно для
облегчения достижения этой цели — в большинстве случаев для генерации
текстового вывода (обычно HTML). Полный язык программирования,
напротив, предназначен для выполнения всего, что может быть поручено
программисту.
Во-вторых, и тесно связанный с этим, это вопрос безопасности. Если
разработчику шаблонов доступен полный язык программирования, этому
шаблону можно будет позволить делать практически все, что позволяет язык
программирования. Тот факт, что код выполняется в контексте шаблона, не
делает его менее опасным.
Что-то вроде этого может вызвать ошибку во время рендеринга:
Вот что происходит, когда вы делите что-то на ноль: <?php print 1/0; ?>.
Это довольно безопасно по сравнению с более потенциально разрушительными
практиками, такими как доступ к необработанным данным. Если бы
разработчику шаблона был предоставлен такой доступ, он мог бы обойти
функции безопасности CMS, обратившись за контентом напрямую к базе
данных, возможно, из-за искреннего разочарования по поводу ограничений
CMS.

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

Многие поставщики CMS неустанно продвигают готовые
элементы интерфейса, которые, по их утверждениям,
автоматически генерируют HTML для общих нужд
интерфейса, например фотогалереи, карусели изображений,
формы комментариев и т. д.
Будьте здесь очень осторожны. Они, безусловно, будут
генерировать HTML, но обычно вам приходится просто брать
то, что получаете. Вероятность того, что они сгенерируют
правильный HTML-код для вашего проекта, библиотеки
стилей, запланированных адаптивных точек останова и
стандартов кодирования, ниже, чем вы думаете.
Эти элементы часто не экономят время, поскольку для работы
с ними необходимо адаптировать другой код (обычно CSS и
JavaScript). А иногда они становятся чистой потерей времени,
поскольку вы изо всех сил пытаетесь получить нужные вам
HTML-структуры, пока, наконец, просто не выбрасываете их и
не создаете шаблоны с нуля.
Окружение
При рассмотрении отображаемой HTML-страницы необходимо разделить
управляемое содержимое страницы и «окружающее пространство». Окружение
— это все, что (подождите) окружает объект контента на странице.
Концепция объемного звучания возникла у нас задолго до управления
контентом. Включения на стороне сервера уже давно позволяют веб-
разработчикам предоставлять общую разметку для верхних и нижних
колонтитулов, а некоторые системы редактирования на стороне клиента
предоставляют явную поддержку этой концепции, например, функция
Microsoft Front Page «Shared Borders».
Рассмотрим новостную статью вРисунок 9-2. Некоторые элементы на этой
странице являются прямым результатом отображения на странице
оперативного объекта контента:
• Название
• Авторство
• Тело
Затем есть все остальное выше, ниже и по бокам новостной статьи. «Все
остальное» — это окружение.
Рисунок 9-2. Новостная статья из «Нью-Йорк Таймс»: все изложено —

заголовок,подпись и тело статьи — это контент из фактического
(оперативного) объекта контента, а все остальное — окружение
В большинстве систем эти элементы обрабатываются двумя разными

шаблонами. Окружение — это внешняя оболочка HTML-документа, общая для
всего контента, а объект контента имеет собственный шаблон. Объект контента
визуализируется по его шаблону и помещается внутри шаблона объемного
звучания.
Вот пример окружения из языка шаблонов Razor ASP.NET MVC:
<html>
<тело>
<h1>Название сайта</h1>
@RenderBody()

</тело>
</html>
@RenderBody() — это вызов метода, который визуализирует подшаблон для

содержимого в этом месте. Вот пример этого шаблона:
<h2>@Article.Title</h2>
<р>
от @Article.Author
</p>
@Article.Body
Как и в наших предыдущих примерах, @Article.Body и @Article.Title — это
токены, которые заменяются управляемым контентом. Весь результат затем
встраивается в более крупный объем и доставляется конечному пользователю.
Окончательный результат выглядит так:
<html>
<тело>
<h2>Схемы миграции птицы додо</h2>
<р>
Боб Джонс
</p>
<p>Lorem ipsum dolar...</p>
<p>Больше абзацев контента здесь...</p>
</тело>
</html>
Окружение ценно тем, что часто существует инфраструктурный HTML, общий
для каждой отдельной страницы веб-сайта. Для каждой страницы может
потребоваться ссылка на одну и ту же таблицу стилей в теге HEAD или
открыть ее с помощью одного и того же содержащего DIV. Хранение этого
кода в одном месте — это просто хорошая практика проектирования.
Шаблоны часто отличаются друг от друга при рендеринге разных типов
контента. Ваш тип контента «Биография сотрудника» содержит принципиально
другую информацию, чем ваш тип контента «Выпуск новостей». Каждый из
этих типов, вероятно, будет иметь свой собственный шаблон, хотя выходные
данные этих шаблонов будут помещены в одно и то же окружение для
окончательной доставки.
Вполне возможно, что разные типы контента могут иметь совершенно разное
окружение, но это встречается реже, чем вы думаете. Иногда тип контента
«целевая страница» может иметь очень пустое окружение или определенный
контент, предназначенный для машинного потребления (например, RSS-канал),
вообще не будет иметь окружения. Однако подавляющее большинство типов в
средней установке управления контентом будут отображаться в одном и том же
пространстве.
Контекст в тотокружать
В только что представленных примерах окружение совершенно не знает о
содержимом, которое в конечном итоге отображается внутри него. Наш
образец окружения каждый раз будет отображаться одинаково, независимо от
типа контента.
Но давайте добавим теги HEAD и TITLE к текущему окружению:
<html>
<голова>
<title>...</title>
<тело>
{object_template}
</тело>
</html>
Теперь возникает вопрос: что мы помещаем в тег TITLE и как его туда
получить? Сам шаблон статьи («внутренний» шаблон) явно умеет это делать с
токеном {article.title}, а как насчет окружения? Что он «знает» о рендеринге
контента внутри себя?
Помните, что все шаблоны, которые мы обсуждали до сих пор, знали об
объекте оперативного контента. Все они выполняются в контексте
определенного объекта контента, на который они могут ссылаться. Есть ли в
окружении такая же роскошь? Или он совершенно не знает, что происходит
внутри помещенного в него внутреннего шаблона?
Это вопрос контекста или способности окружения предпринимать действия,
основанные на понимании контента, который в конечном итоге отображается.
В нашем примере мы могли бы сделать это:
<title>{article.title}</title>
Но помните, что наше окружение универсально для всех типов контента. Будет
ли тип контента «Биография сотрудника» иметь атрибут «title»? (Ну, возможно,
но это, скорее всего, будет относиться к названию должности, а это не то, что
нам нужно.)
Кроме того, будет ли язык шаблонов вообще понимать токен {article}? Мы
больше не обязательно отображаем статью. Окружение должно быть
достаточно универсальным, чтобы обрабатывать любой тип контента, который
мы в него добавляем.
Вот метод грубой силы для решения этой проблемы:
<название>
{if object.type == "Статья") {
{название статьи}
}
{if object.type == "СотрудникБио") {
{employee.first_name} {employee.last_name}
}
</title>
Это могло бы сработать — и я уверен, что это было сделано — но это не очень
масштабируемо. Нам придетсядобавьте к этому беспорядку кода для каждого
возможного типа контента.
Возможно, есть лучший способ решить эту проблему. Назад вГлава 6 когда мы
обсуждали моделирование контента, мы говорили о наследовании, при котором
типы контента могут наследовать от более общих типов и в процессе получать
все их свойства.
Используя это, мы могли бы создать тип контента веб-страницы с текстовым
атрибутом Title Tag. Тогда наши типы «Новостная статья» и «Биография
сотрудника» могут наследовать тип «Веб-страница» и в процессе получить
атрибут «Тег заголовка». Тогда мы могли бы сделать что-то вроде этого:
<title>{object.title_tag}</title>
Обратите внимание, что мы используем токен {object} в коде шаблона
окружения. Это чисто гипотетически, но распространено. Окружение обычно
имеет доступ к части контента в форме, содержащей информацию, общую для
всего контента. Возможно, он не сможет вникнуть в особенности объекта
контента, но он может иметь дело с общими понятиями.
Об абстракциях и полиморфизме
Предыдущий пример известен в программировании как
«абстракция» (точнее, он называется «полиморфизмом»). Да,
новостная статья — это особая вещь, но в то же время это
более абстрактная вещь: веб-страница с тегом заголовка. В то
же время это может быть еще более абстрактный тип: объект
контента, имеющий такие атрибуты, как дата публикации и
автор.
Работа с контентом – и особенно его шаблонирование – часто
означает размышление о нем на разных уровнях абстракции и
специфичности.
На самом деле, большинство веб-CMS имеют особые способы обработки тега

TITLE, но это всего лишь один пример того, как окружению часто приходится
иметь дело с функциями, специфичными для отображаемого контента.
Учитывайте общее требование «Похожий контент». Интеграторы CMS
постоянно видят это в каркасах — идею о том, что контент, связанный с
просматриваемым контентом, может быть волшебным образом создан из
воздуха.5 Независимо от технических проблем, этот элемент интерфейса
обычно появляется на боковой панели или где-нибудь в ее окружении.
5 Если это звучит немного цинично, то это так. Не существует Великой единой теории связанного
контента, хотя дизайнеры вайрфреймов обычно предполагают, что это происходит каким-то
волшебным образом, поэтому они регулярно добавляют ее в каждую боковую панель.
Чтобы отобразить это, окружение должно знать достаточно о конкретном
просматриваемом контенте — контенте во «внутреннем» шаблоне. Будет ли он
располагать этой информацией достаточно подробно, чтобы принять меры?
Навигация — еще одно очень распространенное контекстное требование. Часто
окружению необходимо знать, где находится контент в более широкой
географии контента. Для левого навигационного меню сайта ваш план,
возможно, состоит в том, чтобы отображать ссылки на все «родственные»
страницы просматриваемой страницы или просто отформатировать ссылку на
текущую страницу по-другому. Для этого окружение должно знать, какой
контент в данный момент отображается. Следы крошек — еще один пример:
следы крошек имеют смысл только тогда, когда известно положение текущего
контента по отношению к другому контенту.
Будет ли у вашего окружения доступ к этой информации? Сможет ли он
получить ссылки на текущий объект, чтобы запросить в репозитории
одноуровневые страницы?
Отсутствие контекста в окружении иногда может сильно расстраивать. Хотя
шаблон для конкретного объекта контента относительно прост, другие вещи
могут быть излишне сложными из-за отсутствия абстракции и недостаточной
осведомленности при рендеринге окружения.
ШаблонВыбор
Для отображения объектов контента необходим шаблон. Как выбирается этот
шаблон? Как объекты и шаблоны сопоставляются для рендеринга?
В большинстве случаев шаблоны подбираются исходя из типа контента. Это
естественно, поскольку тип контента является наиболее очевидным
определяющим фактором того, что должен делать шаблон. Код шаблона,
необходимый для отображения биографии сотрудника, почти всегда будет
сильно отличаться от кода, необходимого для отображения пресс-релиза.
Однако в некоторых случаях шаблон, выбранный для отображения объекта
контента, может отличаться в зависимости от других факторов, помимо типа.
Редакторы могут иметь выбор шаблонов, обычно для изменения макета.
Например, редактор может выбрать шаблон с двумя столбцами для
отображения боковой панели.
В этих случаях путаница может возникнуть из-за того, что для отображения
другого шаблона может потребоваться другой контент, и наличие этого
контента может быть лучшим способом автоматического выбора.
В случае нашего шаблона с двумя столбцами контент должен существовать для
этого столбца боковой панели. Имеет ли объект контента атрибут
«Содержимое боковой панели»? И если да, может ли обычный шаблон просто
отображать или скрывать боковую панель в зависимости от того, заполнено ли
это свойство? Редактору было бы сложно заполнить атрибут «Содержимое
боковой панели», но при этом не увидеть боковую панель просто потому, что
он не смог выбрать шаблон, который ее поддерживает.
В других случаях нам может потребоваться предоставить другой шаблон для
конкретного объекта контента, чтобы обеспечить некоторые расширенные
функции. Если бы, например, у нас был специально запрограммированный
ипотечный калькулятор, мы могли бы создать тип контента «Ипотечный
калькулятор» со своим собственным шаблоном на основе этого типа. Однако в
зависимости от требуемых усилий это может оказаться напрасной тратой для
типа контента, который будет использоваться только один раз — на основе
этого типа будет создан ровно один объект контента.
Возможно, было бы проще просто создать объект Page и назвать его
«Ипотечный калькулятор», а затем использовать другой шаблон для этого
конкретного объекта, содержащий код для отображения нашего калькулятора.
Это может быть сделано путем редакционного выбора, но это сопряжено с
риском того, что редактор выберет этот шаблон и для других страниц.
Вероятно, было бы лучше принудительно использовать этот шаблон для этого
объекта контента на уровне кода или конфигурации. (Видеть«Прокси Кон-
Палаточные объекты» на странице 192..)
Некоторые системы делают это по стандартам именования файлов с
определенным «резервным» списком того, как будет отображаться объект
контента. Система будет искать шаблон от наиболее к наименее конкретному.
Например, предположим, что у нас есть объект контента «Биография
сотрудника» с уникальным идентификатором #632. Наша система может
искать в каталоге шаблонов файлы с именами:
• контент-id-632.tpl6
• контент-сотрудник-bio.tpl
• контент.tpl
Система сначала будет искать шаблон, соответствующий идентификатору

(content-id-632.tpl). Если он этого не находит, он будет искать шаблон,
специфичный для типа контента (content-employee-bio.tpl). Если он этого не
обнаружит, он будет использовать общий шаблон (content.tpl) для всего
контента (что в большинстве случаев было бы крайне нежелательно — можно
было бы надеяться, что для каждого типа контента будет существовать шаблон
по адресу: по крайней мере; как мы сможем отображать совершенно разные
типы контента из одного и того же шаблона?).
Хотя откат на основе именования файлов является обычным явлением, другие
системы имеют гораздо более сложные способы определения выбора шаблона,
включая оценку конкретных свойств или определенных географических мест, и
даже расширенные механизмы правил, включающие эзотерические
комбинации переменных среды и контента.
6 Опять же, это гипотетически, но «.tpl» — очень распространенное расширение для файлов
шаблонов. Файлы представляют собой простые текстовые файлы и могут с таким же успехом
использовать расширение «.html» или «.txt», но расширение «.tpl» определяет их назначение по
имени, что может быть полезно.
Наконец, многие системы также предоставляют инструменты разработчика для
отмены выбора шаблона на уровне кода. Разработчик может написать код,
который учитывает любые переменные при назначении шаблона объекту
контента для рендеринга.
ПроксиОбъекты контента
Ипотечный калькулятор, который мы обсуждали в этом разделе, является
хорошим примером «прокси-объекта». В нашем примере ипотечный
калькулятор полностью управлялся кодом — все функции находились в
шаблоне, а часть внутреннего кода была написана разработчиком. Фактически,
код мог быть написан как отдельная исполняемая страница и просто связан с
файловой системой как Calculator.aspx или Calculator.php.
Однако в этом случае эта страница станет «сиротой». CMS, вероятно, ничего об
этом не знает, что ограничивает или исключает любую расширенную
функциональность, которую может предложить CMS. В идеале мы могли бы
найти способ «обернуть» эту пользовательскую функциональность в
конструкцию, о которой знает CMS и которую она может предоставить.
Объект контента в нашем примере сделал именно это. Это была «обертка» или
«прокси» вокруг этого шаблона. Мы создали объект контента, а затем
присвоили этому объекту определенный шаблон. Этот шаблон содержал весь
функционал, необходимый для нашего калькулятора.
Создав прокси-объект в CMS для обертывания этого кода, мы фактически
сообщили нашей CMS, что этот контент существует, и, следовательно,
включили в него значительные редакционные функции. Например:
• Мы можем предоставить абзац справочного текста или введение, которым

может управлять редактор (возможно, как атрибут Main Body страницы).
• Калькулятор может быть представлен в том же оформлении, что и остальная часть сайта.
• Калькулятор может использовать нашу модель разрешений, возможно,
предоставляя доступ только вошедшим в систему посетителям.
• Мы можем настроить калькулятор в зависимости от его связи с другим
контентом (если он отображается в разделе «Коммерческая ипотека»,
назовите его так; в противном случае назовите его «калькулятор жилищной
ипотеки»).
• Мы можем настроить элементы навигации (особенно обломки) в
зависимости от местоположения контента в географическом пространстве.
• Если редактор пишет еще одну страницу и хочет создать ссылку на
калькулятор, он может выбрать калькулятор в качестве другой страницы в
CMS, вместо того чтобы копировать и вставлять URL-адрес. Тогда, если
URL-адрес калькулятора изменится, нам не придется отслеживать все эти
ссылки.
• Мы можем получить чистый URL-адрес, предоставленный CMS.
Шаблон Абстракция иВключение
Помимо связи между шаблоном и его окружением, шаблон довольно часто
содержит «подшаблоны» или «включенные шаблоны», которые представляют
собой отдельные шаблоны, внедренные в определенные места «содержащего»
шаблона.
Это продолжение очень распространенной техники языков веб-
программирования. Серверные включения уже много лет используются для
вставки фрагментов HTML и программного кода на таких языках, как PHP,
Classic ASP и ColdFusion. И это само по себе является продолжением принципа
программирования DRY («Не повторяйте себя»), который побуждает
программистов поднимать общий код в центральные «библиотеки», на которые
ссылаются во многих местах.
Цель этой модели — избежать повторения и упростить обслуживание
шаблонов по мере необходимости внесения изменений. Если общий код
шаблона сосредоточен в одном месте, его можно изменить один раз с
потенциально далеко идущими последствиями.
Например, в нескольких местах веб-сайта нам может потребоваться создать
такую HTML-структуру:
<ул>
<li><a href="/article1">Статья №1</a></li>
</ul>
Это простой маркированный список из трех статей и их названий. Мы можем
использовать это на боковой панели «Похожий контент», в меню «Последние
новости» и в рекламном блоке «Другие статьи этой серии». В каждом случае
будут отображаться разные статьи, но общая структура представления списка
статей и заголовков будет применяться во всех случаях.
Код для генерации этого вывода может выглядеть следующим образом:
<ул>
{foreach статья в list_list}
<li><a href="{article.url}">{article.title}"</a></li>
{endforeach}
</ul>
Мы могли бы, конечно, просто включить этот код шаблона во все три места
наших шаблонов. Но что, если мы захотим это изменить? Вместо того, чтобы
включать его три раза, было бы более эффективно хранить код в одном месте и
просто ссылаться на него.
Возможно, вместо этого мы могли бы вставить следующий код:
{include:article_list.tpl}
Этот код найдет файлarticle_list.tpl, в котором находится наш код, и вставит его
содержимое в это место. При использовании в нескольких местах этот код
позволит централизовать структуру шаблона и позволит нам хранить ее в
одном месте.
Помните, что фактические статьи будут разными в каждом из трех наших
вариантов использования, поэтому нам нужен способ указать, что означает
переменнаяarticle_list внутри подшаблона. Обычно это достигается путем
указания значения при вызове шаблона:
{include:article_list.tplarticle_list=article.related_articles}
В этом случае мы вызываем подшаблон и сообщаем ему, что (только в этом
случае) список статей состоит из атрибута linked_articles статьи, которую мы
отображаем.
Включение шаблонов довольно распространено (как в CMS, так и в веб-
разработке в целом) и чрезвычайно полезно для уменьшения сложности
шаблонов путем абстрагирования общих выходных структур в их собственные
шаблоны и управления ими там.
Шаблонизация наизнанку
Если мы рассматриваем шаблон оперативного объекта контента как
«основной» шаблон, окружение часто описывается как оболочка этого
основного шаблона. Концептуально это выглядит так:
объемный.tpl
контент-объект.tpl
Однако есть небольшая разница, и я хочу убедиться, что вы понимаете, что
создание шаблонов обычно осуществляется изнутри наружу, а не снаружи
внутрь. Окружение не выбирает внутренний шаблон; скорее, внутренний
шаблон выбирает окружение.
Помните, что шаблон content-object.tpl является основным шаблоном — это
шаблон, который вызывается напрямую. По сути, он командует и иногда может
контролировать, какое объемное звучание применяется. Таким образом, он
«включает себя» в шаблон объемного звучания, что выворачивает концепцию
наизнанку.
Например, шаблон Razor в ASP.NET MVC включает этот код вверху:
@{
макет = "/путь/к/макет/шаблон.cshtml";
}
По сути, это говорит: «Казните меня, а затем поместите меня внутрь этого
конкретного окружения». Основной шаблон определяет желаемое окружение и
сохраняет контроль над потоком рендеринга.
Объект оперативного контента во многом похож на подготовку к вечеринке.
Во-первых, они приводят себя в порядок, красиво одеваются и прекрасно
выглядят. Затем, в последнюю секунду, они просматривают шкаф в прихожей в
поисках подходящего пальто, которое дополняет их наряд, надевают его и
направляются к двери. Они подбирали пальто по своему наряду, а не по пальто.
Окружающий шаблон — это оболочка, которую оперативный шаблон надевает
в последнюю секунду.
Шаблон Разработка иУправление
Мы много говорили о шаблонах, но что они собой представляют и чем они
отличаются от самого контента?
Шаблоны почти всегда основаны на файлах. В то время как контент
существует в CMS как нечто, с чем редакторы работают через интерфейс,
шаблоны существуют в файловой системе как файлы, над которыми
разработчики работают, используя свои стандартные инструменты разработки.
(Видеть«Версия кода наше содержание» на странице 28.)
Некоторые системы также позволяют редактировать шаблоны через интерфейс,
хотя это происходит редко и обычно делается только в экстренных случаях,
когда доступ к базовому коду недоступен. Текстовая область на HTML-
странице предлагает очень мало возможностей для поддержки кодирования,
даже самые элементарные инструменты редактирования кода — нумерация
строк, подсветка синтаксиса, автозаполнение и т. д.7
Существование шаблонов на основе файлов подчеркивает еще одно различие
между шаблонами и контентом: шаблоны являются активом кода, а не активом
контента. Изменение шаблона обычно рассматривается как изменение на
уровне кода и зависит от рабочего процесса разработчика, а не от редактора.
Эти два рабочих процесса совершенно различны.
Шаблоны обычно хранятся в системе управления исходным кодом, такой как
Git или Team Foundation Server. Иногда они хранятся вместе с самим кодом
CMS, а иногда и отдельно. Изменения в шаблонах часто тестируются и
развертываются с помощью известных инструментов сборки, таких как Jenkins
или Cruise Control (подробнее об инструментах разработки мы поговорим в
разделеГлава 12).
Взаимосвязь между кодом и контентом часто понимается неправильно, и их
часто смешивают. Редакторы могут ожидать, что контент будет обрабатываться
как код, а код будет обрабатываться как контент. Понимание разницы между
ними и границ между ними имеет решающее значение для общего понимания
самой CMS.
Отзывчивый Дизайн и ВыходАгностицизм

Все больше и больше потенциальных клиентов CMS задаются вопросом, в
какой степени CMS обеспечивает или препятствует адаптивному дизайну.
Ответ на любой вопрос должен быть «совсем нет». Адаптивный дизайн во
многом является побочным продуктом разметки HTML и CSS, а также CMS.
7 Очень немногие другие системы требуют разработки шаблонов исключительно через интерфейс.
Такое случается редко, но случается время от времени, и это часто приводит разработчиков в
замешательство. Файлы — это универсальный контейнер веб-разработки, это то, на чем разработчики
основывают свою работу и используют их в качестве механизма инкапсуляции и транспортировки
кода. Почти все процессы и методологии программирования предполагают, что код существует в
файлах, а не в записях базы данных, и без управления файловыми артефактами многие методологии и
рабочие процессы программирования полностью перестанут работать.
не должен ни включать, ни запрещать какую-либо конкретную парадигму
вывода. В идеале CMS должна стремиться быть «независимой от выходных
данных».
Некоторые CMS обеспечивают обнаружение устройств и используют эту
информацию для выбора шаблона (технически это адаптивный дизайн, а не
отзывчивый), но даже в системах, которые этого не делают, эта
функциональность может предоставляться веб-сервером или каким-либо
другим элементом в технологический стек.
Здесь можно увидеть предыдущее предупреждение о готовых виджетах
интерфейса. Стандартная HTML-структура, предоставляемая «функцией»
CMS, будет бросаться в глаза, как больной палец, если она является
единственным неотзывчивым элементом на странице или не реагирует так, как
все остальное. А учитывая, что HTML-код вашего адаптивного дизайна будет
сильно зависеть от выбранной вами платформы CSS, как эти готовые виджеты
будут решать, какой HTML-код выводить?
В более широком смысле этот вопрос говорит о разделении ответственности.
Входит ли в обязанности CMS управление обнаружением устройств и
генерацией адаптивного HTML? Большинство разработчиков скажут «нет»:
этим должны заниматься другие компоненты технологического стека. Пока
CMS не препятствует генерации любого HTML-кода, который желает
разработчик шаблона, оперативность вывода не является заботой CMS.
Когда CMS становится слишком удобной с HTML, который

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

Одним из наиболее важных архитектурных принципов, лежащих в основе
CMS, является модель связи между средами управления и доставки. Под
«менеджментом» я подразумеваю систему, в которой контент создается,
редактируется и управляется. Под «доставкой» я подразумеваю систему, из
которой контент потребляется посетителем.

Во многих случаях это одна и та же система. Редакторы управляют контентом,
а посетители потребляют его с одного и того же сервера, используя одну и ту
же среду выполнения. Например, редактор, работающий над контентом в
Sitecore, и посетитель, читающий этот контент, общаются с одной и той же
установкой Sitecore, только с разных сторон.
Такие системы называются «связанными». Управление и доставка неразрывно
связаны в одной и той же среде.
Сравните это с системой, в которой среда разработки и управления находится
на одном сервере, а среда доставки — на совершенно другом сервере,
возможно, в другом центре обработки данных и даже в совершенно другом
географическом положении. Контент создается и управляется в одном месте, а
затем передается в другое место, где его потребляют посетители.
Среда реализации может лишь смутно знать о существовании среды
управления. Если контент размещается на нем через FTP или копирование
файла, веб-сервер в среде доставки будет послушно обслуживать контент, не
зная и не заботясь о том, откуда он взялся.
Говорят, что эти системы «развязаны». Управление и доставка разделены на
две среды.
Когда дело доходит до фактической публикации контента, эти два варианта
обрабатываются совершенно по-разному:
• В связанной системе публикация контента просто означает изменение

настроек контента, чтобы сделать его общедоступным. С момента своего
создания контент уже находится в среде доставки; оно просто скрыто от
всеобщего обозрения. Возвращаясь к обсуждению версий в последней
главе: чтобы сделать ее доступной для публичного просмотра, мы просто
помечаем одну из версий как «опубликованную». Это почти
разочаровывает.
• В разделенной системе нам приходится фактически перемещать данные из
одной среды в другую. Весь контент, предназначенный для публикации,
собирается из среды управления, а затем полностью передается на другой
сервер.8
Эти две модели часто приводят к путанице в понятии «промежуточной среды».

В связанной системе промежуточная среда является виртуальной: если у вас
есть разрешение на просмотр чернового содержимого и вы, возможно,
находитесь в «режиме предварительного просмотра», то вы фактически
просматриваете промежуточную среду на том же сервере, что и
производственная среда. В разделенной системе промежуточная среда может
быть буквально другой средой, в которую передается контент для
предварительного просмотра.
8 Обычно. Некоторые установки могут просто публиковать контент в другом месте на том же сервере.
Публикация контента | 197
Какая архитектура по умолчанию?
На заре управления контентом разделение было архитектурой по умолчанию.
Системы управления контентом в основном представляли собой генераторы
статических файлов, которые просто помогали менеджерам веб-сайтов
преобразовывать данные в форматированные HTML-файлы, которые затем
копировались в корень веб-сайта.
Но по мере того, как языки веб-программирования и веб-сайты становились все
более сложными, модель разделения начала давать трещины. Наличие простых
статических HTML-файлов хорошо работало, когда контент не сильно менялся
и не требовалось ничего делать, но рынок начинал требовать, чтобы контент
становился активным.
Менеджеры веб-сайтов хотели, чтобы пользователи взаимодействовали с
контентом контекстуально: они хотели скрыть часть контента от
пользователей, которые не вошли в систему, или они хотели изменить способ
организации контента в зависимости от пользователя, или они хотели включить
режим реального времени. поиск контента. Статические HTML-файлы плохо
адаптировались к этим потребностям.
Постепенно CMS и контент, которым она управляет, стали более связанными.
Зачем писать HTML-файл, если PHP-скрипт может просто запрашивать и
получать содержимое из базы данных в режиме реального времени? С тех пор
связанная CMS стала моделью по умолчанию, а несвязанные системы
становится все труднее найти (хотя ситуация может измениться; мы поговорим
об этом немного позже).Глава 15).
В ситуациях, когда развязка все еще используется, CMS обычно либо
публикует веб-страницы со сценариями (например, PHP-файлы), которые
выполняются по запросу, либо не публикует файлы вообще. Некоторые
системы публикуют чистые записи данных в базе данных. 9 и веб-сайт создан
так, чтобы отображать их в реальном времени (как ни странно, теперь у вас
есть как бы две CMS: отдельная, заполняющая базу данных в качестве места
назначения, и связанная, использующая эту базу данных в качестве источника).
Аргумент в пользу разделения

Хотя развязка не подходит для многих ситуаций, она имеет неоспоримые
преимущества:
• Это позволяет вашей системе репозитория и системе публикации

использовать разные архитектуры. У вас может быть CMS на основе Java,
передающая контент на сервер Windows, на котором работает .NET. Ваша
среда доставки не ограничивается вашей средой управления.
9 Я даже работал над узкоспециализированной сборкой, которая просто заполняла всю базу данных
SQLite содержимым и отправляла его в среду доставки. Таким образом, CMS заменяла весь источник
данных работающего веб-сайта при каждой публикации контента. Хотя он явно не подходит для
многих ситуаций, он оказался правильным выбором для этих конкретных требований и
демонстрирует, что несвязанные данные могут публиковаться во многих различных форматах,
помимо статических файлов.

• Обычно это приводит к созданию более безопасной среды доставки.
Потенциальные точки взлома на урезанном веб-сервере ничтожны по
сравнению с полноценной CMS.
• Вы можете публиковать контент в нескольких средах доставки. Крупное
медиапредприятие может иметь сотни серверов в десятках стран на разных
континентах. В таких ситуациях развертывание контента намного сложнее,
чем просто манипулирование стеком версий. Необходимо обновить
кэширующие серверы, необходимо отправить медиафайлы в CDN,
необходимо сбросить обратные прокси-серверы, необходимо обновить
отказоустойчивые серверы и т. д.
• Поскольку вам не нужно устанавливать CMS на все серверы доставки,
возможно, вам не потребуется их лицензировать. В зависимости от размера
вашей среды доставки это может сэкономить вам огромные суммы денег.
• Возможно, будет проще масштабировать несвязанный уровень доставки.
Добавить простой веб-сервер в балансировщик нагрузки намного проще,
чем устанавливать новую установку CMS и каким-то образом
синхронизировать ее с другими. Ваша среда управления на самом деле
может быть довольно скромной, но она может публиковать контент в
гигантской архитектуре доставки.
• Надежность обычно выше. Отсутствие CMS в среде доставки означает
меньшее количество движущихся частей. При обслуживании статических
HTML-файлов вероятность ошибки меньше.
• Вы можете публиковать контент из нескольких репозиториев и систем.
Ваша CMS может быть лишь одной из многих систем, генерирующих
контент, поэтому вашему уровню доставки может потребоваться
публиковать контент, не зная (или не заботясь) о том, откуда он взялся. В
изолированной среде легче смешивать контент из нескольких точек
происхождения.
• В некоторых случаях контент CMS является вторичным по отношению к
основной цели веб-сайта. Например, система онлайн-банкинга может
представлять собой огромную, специально созданную банковскую
платформу, которая, кстати, также отображает некоторый контент. Вы не
можете просто добавить к этому связанную CMS — CMS не может
«владеть» средой доставки. Вместо этого CMS должна подчиняться ей,
существовать где-то еще и помещать в нее контент.
• Некоторым редакторам требуется настоящая «промежуточная среда», на
основе которой можно разрабатывать контент. Им нужна «песочница», в
которой можно публиковать контент для предварительного просмотра
перед публичной публикацией.
Развязанный ИздательскийЦели
В несвязанных средах CMS передает контент «целям публикации», то есть
средам, предназначенным для доставки контента. Большинство систем могут
поддерживать более одной среды публикации и публиковать в них контент
одновременно.
Публикация контента | 199

Фактический метод передачи часто является одним из следующих:
• FTP или SFTP

• Копия файла (очевидно, две системы должны находиться в одной сети или
VPN)
• ВебДАВ
• rsync
• SCP
• веб-сервис
Некоторые методы передачи универсальны (почти каждый сервер

поддерживает FTP), тогда как другим для получения контента требуется что-то
на другом конце. Например, не существует универсального веб-сервиса,
который мог бы получать контент от любой CMS. Таким образом, CMS может
предоставлять веб-службу для запуска в среде доставки, которая будет
использоваться для передачи контента из одной среды в другую.
Как только это произойдет, нейтральность разделенной модели будет
нарушена. Если среда доставки требует, чтобы внутри нее что-то работало, то
эта среда в некоторой степени становится расширением CMS. CMS больше не
публикует информацию в нейтральной среде, а вместо этого публикует ее в
известной конечной точке, которая готова получать от нее контент.
Некоторые системы еще более специфичны: в них используется проприетарное
программное обеспечение для получения контента в среде доставки. CMS
фактически состоит из двух частей, в результате чего получается система, в
которой программное обеспечение управления передает контент в
программное обеспечение доставки, необходимое на каждом сервере
доставки.10
Синхронизация среды доставки

Вот, казалось бы, простой вопрос: как разделенная система удаляет
опубликованный контент из среды доставки? Предположим, ваша отделенная
CMS отправляет HTML-файл (запись базы данных или что-то еще) на сервер
доставки. Позже содержимое этого файла удаляется из репозитория. Удаляет
ли затем отделенная система выходной файл с сервера доставки?
Некоторые так и делают, но другие могут обновлять среду доставки только при
публикации, а это означает, что при удалении там остается потерянный файл.
Со временем они накапливаются, и вы получаете смесь активных файлов,
которые представляют собой
10 Очевидно, что еще одним преимуществом этой модели для коммерческих компаний CMS является
то, что все серверы доставки необходимо учитывать и впоследствии лицензировать. Стоимость
лицензирования среды доставки может составлять наибольшую часть общей стоимости
поставщика.
Палатка и потерянные файлы, не имеющие соответствующего содержимого.
Как вы можете отличить эти два понятия друг от друга?
Можете ли вы просто удалить среду доставки и заново опубликовать весь
репозиторий с нуля? Только если все для вашего сайта есть в CMS. Некоторые
решения управляются лишь частично: вспомогательные файлы находятся в
среде доставки (или развертываются там из системы управления версиями), а
файлы контента публикуются из CMS, и все эти файлы перемешиваются в
одних и тех же местах на сервере доставки. Как определить, какие файлы были
опубликованы из CMS, а какие существуют только в среде доставки?
Это поднимает более серьезный вопрос: как отделенная CMS обеспечивает
идеальную синхронизацию с опубликованной средой? «Владеет» ли он средой
доставки и осуществляет ли над ней железный контроль? Или он предназначен
для того, чтобы «вносить вклад» в среду доставки, а не нарушать работу уже
имеющихся файлов? Ответ на этот вопрос зависит от системы.
Краткое описание функций управления выводом и

публикации
Следующие контрольные списки дадут вам некоторые рекомендации по
вопросам, которые следует учитывать при оценке ваших результатов и
потребностей в публикациях.
Архитектура
• Является ли система связанной или разделенной?
• Управляет ли система контентом без привязки к доставке в Интернете или
в нее встроены веб-ориентированные функции?
• Создание шаблонов выполняется на предметно-ориентированном языке
или на базовом языке программирования самой CMS?
• Позволяет ли язык замену токенов? Разрешает ли он фильтрацию и
форматирование заменяемых значений?
• Какие структуры управления доступны для логики шаблона?
• Как система шаблонов позволяет вам управлять объемным звуком и
включать его? Как окружение может получить правильный контекст
отображаемого объекта контента?
• Как система шаблонов позволяет абстрагировать и включать другие
шаблоны?
Краткое описание функций управления выводом и публикации |2 0 1

• Как выбираются шаблоны для контента? Как вы можете повлиять на этот выбор?
• Как разработчики шаблонов разрабатывают и управляют шаблонами?
Отдельная публикация
• Как контент передается издательским объектам?
• Как настраиваются и управляются цели публикации? Требуются ли они для
запуска программного обеспечения, специфичного для CMS?
• Может ли CMS фиксировать события публикации? Могут ли процессы
запускаться до или после того, как контент будет отправлен в среду
доставки?
• Какие артефакты данных на самом деле публикуются? Только файлы, или
система может публиковать записи в базе данных или другом методе
хранения, не являющемся файловой системой?
• Как CMS обеспечивает синхронизацию среды доставки с репозиторием?
• Ожидается ли, что CMS также будет управлять файлами, не относящимися
к содержимому, или вспомогательные файлы должны находиться в среде
доставки, и из CMS будут публиковаться только файлы содержимого?
• Что необходимо установить на серверах доставки, чтобы они могли
получать контент из среды управления?
• Как лицензируются серверы доставки?

ГЛАВА10
ДругойФункции
В предыдущих главах мы обсуждали крайние случаи, которые представляют

собой шаблоны использования, находящиеся за пределами того, что может
делать типичный пользователь. Пограничные случаи — это проклятие
разработчиков программного обеспечения, поскольку их приходится
учитывать, хотя они случаются нечасто. А иногда уровень работы,
необходимый для обработки пограничных случаев, будет равен или
превосходить уровень работы, необходимый для разработки чего-то, что
постоянно делает каждый пользователь.
Одна из проблем написания сложного, многофункционального программного
обеспечения заключается в том, что любой отдельный пользователь
программного обеспечения может использовать только 25% всех его функций.
Но каждый использует разные 25%. Это означает, что помимо базовой,
основной функциональности, все в некоторой степени становится пограничным
случаем.
Как только база пользователей платформы достигает значительного размера,
каждый крайний случай может стать огромной проблемой. Если вашим
программным обеспечением пользуются 30 000 человек, а какую-то функцию
использует только 1% из них, то это все равно 300 человек, которые ожидают,
что она будет работать с таким же уровнем отшлифовки, как и все остальное.
Эти пользователи не знают, что это крайний случай. Они не знают, что очень
немногие люди используют эту функцию. Просто спросите любого
поставщика, который попытался удалить функцию, которую, по его мнению,
никто не использовал, но был встречен воплями протеста со стороны
небольшой группы пользователей, которые зависели от нее.
В предыдущих четырех главах мы обсудили основные функции управления
веб-контентом:
• Моделирование контента
• Агрегация контента
• Редакционный рабочий процесс
203
• Управление выводом
Можно с уверенностью предположить, что каждая реализация будет в той или

иной степени использовать эти четыре функции. Если система дает сбой по
одному или нескольким из этих факторов, трудно добиться многого.
Однако в этой главе мы поговорим об особенностях по краям. Это вещи,
которые могут использоваться в некоторых реализациях и не использоваться в
других. Некоторые системы не будут реализовывать некоторые из этих
функций, потому что у них нет пользователей, требующих их.
Функции, относящиеся к крайним вариантам использования, часто вызывают
ощущение «заводи». Они находятся где-то в стороне от мейнстрима и могут
предлагать функциональные возможности, о существовании которых забыли
даже опытные интеграторы (или члены самой команды разработчиков
продукта!) или о существовании которых вообще никогда не знали.
Backwater-функции — это те, которым не уделяется столько внимания, как
основным функциям, и иногда они создаются только для того, чтобы
поставщик мог отметить несколько флажков в запросе предложений и заявить,
что он их предлагает. Следовательно, их ценность имеет тенденцию
ограничиваться узкими моделями использования.
Обратите внимание, что не все, что обсуждается в этой главе, является
«заброшенной функцией», но все функции, которые мы здесь рассмотрим,
представляют собой функциональность, которая может присутствовать не во
всех системах.
К сожалению, распространенный сценарий — это когда

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

Локализация контента — глубокая и богатая тема. Авторы технической
документации десятилетиями разрабатывали методы управления
многочисленными переводами своего контента. Веб-сайты только что сделали
проблему более актуальной и детальной.1
1 Управление многоязычным контентом изначально было гораздо более продвинутым в системах,

пришедших из Европы, поскольку его нужно было встроено с самого начала. Европейцы более
многоязычны, чем остальной мир, из-за огромного количества разных языков, на которых говорят в
непосредственной близости. Таким образом, CMS, пришедшие из Европы десять лет назад, имели
тенденцию быть многоязычными с самого начала, в то время как системам из остального мира часто
приходилось модифицировать эту функцию на более позднем этапе своего жизненного цикла.
204 | Глава 10: Другие функции

Наличие контента вашего веб-сайта на нескольких языках часто является не
бинарным вопросом, а, скорее, вопросом степеней. В некоторых случаях у вас
может быть просто две версии вашего веб-сайта, и весь контент будет
переведен на оба языка. Однако в других случаях у вас может быть некоторый
контент на вашем основном языке,2 и некоторый контент переведен на
дополнительный язык. Неперевод всего вашего контента на другой язык может
быть связан с расходами или отсутствием нормативных требований в
ситуациях, когда от организации требуется только иметь определенный
контент на нескольких языках.
Несколько языков добавляют дополнительное измерение вашей CMS. С точки
зрения вашей модели контента, каждый атрибут может требовать или не
требовать дополнительных версий самого себя. Атрибут Title вашего типа
контента News Release явно должен существовать в нескольких версиях, по
одной для каждого языка, но другие атрибуты не будут переведены. Например,
флажок «Показать правую боковую панель» является универсальным. Чтобы
учесть необязательный перевод при моделировании контента, вам может
потребоваться указать, является ли конкретный атрибут «переводимым» или
нет.
Конечным результатом является не простое дублирование типа контента, а
скорее более сложное выборочное дублирование отдельных атрибутов
контента. Объекты контента заполняются необходимой комбинацией
универсальных атрибутов, переведенных атрибутов на правильный язык и
«запасных» переводов для атрибутов без правильного языка.
Номенклатура
При обсуждении многоязычного контента некоторые термины могут вызывать
затруднения. Вот несколько определений, которые следует иметь в виду:
• Локализацияэто перевод контента на другой язык.

• Интернационализацияэто разработка программного обеспечения таким
образом, чтобы оно поддерживало локализацию.
Например, «интернационализированная» CMS была создана таким образом,

что можно поддерживать несколько языков либо в управляемом контенте, либо
в самом интерфейсе CMS.
Последний момент стоит отметить: существует разница между CMS, которая
управляет контентом на нескольких языках, и системой, которая представляет
себя на нескольких языках. Если ваш китайский переводчик не говорит по-
английски (предположим, он переводит контент, скажем, со шведского),
наличие интерфейса CMS, который может быть представлен только на
английском языке, может стать проблемой.
2 Для целей этой главы я буду использовать английский язык, хотя прошу прощения за этноцентризм.
Многоязычная обработка | 205
Язык Обнаружение иВыбор
Язык, на котором ваш посетитель хочет потреблять контент, можно сообщить
тремя распространенными способами:
• Доменное имя, с которого осуществляется доступ к контенту

• URL-сегмент локального пути к содержимому
• Настройки браузера посетителя, передаваемые через HTTP-заголовок.
В первом случае контент доставляется в совершенно отдельный домен или

поддомен, например:
www.mywebsite.sese
.mywebsite.com
В этих случаях «se» — это ISO-639.3 сокращение от шведского. Хотя эти два
домена выглядят одинаково, на самом деле между ними есть заметная разница.
В первом примере требуется, чтобы ваша организация владела доменным
именем для конкретной страны. Это может быть сложно, если страна налагает
ограничения на то, кто может приобретать эти домены (например, вам,
возможно, придется быть зарегистрированы или находиться в рассматриваемой
стране). Во втором примере используется субдомен, который доступен
бесплатно для организации, владеющей доменом «mywebsite.com».
Дополнительным соображением является то, что «mywebsite.se» считается
«принадлежащим» стране, и ходят слухи, что при использовании поисковых
систем в этих странах необходимо уделять больше внимания поисковой
оптимизации (SEO). В этом случае контент, размещаемый в домене
«mywebsite.se», может работать лучше при использованииGoogle Швеция.
Возможность сопоставления языков по имени домена может поддерживаться
или не поддерживаться CMS. В некоторых случаях альтернативный домен
будет считаться другим веб-сайтом, в то время как другие позволят
сопоставить несколько доменов с одним сайтом с целью сопоставления языков
с конкретными доменами.
Если вы не хотите менять доменные имена, многие системы позволяют указать
язык в первом сегменте URL. Например:
www.mywebsite.com/se/my-news-release
3 «ISO» означает Международную организацию по стандартизации. Это всемирная организация,

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

В этом случае обнаруживается «se» в начале локального пути и обслуживается
контент на шведском языке. В системах, где URL-адреса генерируются
автоматически на основе структуры сайта, этот сегмент URL-адреса обычно
добавляется автоматически, прозрачен для редактора и не сопоставляется с
каким-либо конкретным объектом контента. (Пока мы проигнорируем тот
факт, что остальная часть URL-адреса должна фактически читаться как «mitt-
pressmeddelande»; мы поговорим об этом подробнее в следующем разделе.)
Наконец, многие системы поддерживают автоматическое определение
языковых предпочтений во входящем запросе. В веб-запросах скрыты
фрагменты информации, называемые «заголовками», которые ваш браузер
отправляет для указания предпочтений. Один из таких заголовков выглядит
так:
Accept-Language: se, en;q=0.9, fr;q=0.8
В этом случае браузер пользователя говорит: «Отправьте мне контент на
шведском языке, если он у вас есть. Если нет, я возьму английский. Если нет,
то используйте французский в крайнем случае».4
Эта языковая настройка встроена в ваш браузер и может быть изменена в
настройках браузера (возможно, вам придется внимательно поискать, потому
что она редко меняется, но я обещаю вам, что она где-то там есть) —
см.Рисунок 10-1 для примера. Для большинства пользователей это значение
устанавливается (и никогда не изменяется) вашей операционной системой в
зависимости от приобретенной вами версии. Если вы купили копию Windows в
Швеции, то языком операционной системы, вероятно, по умолчанию будет
шведский, а Internet Explorer будет автоматически настроен на передачу
заголовка Accept-Language с предпочтением шведского языка.
Рисунок 10-1. Диалог настроек языка в Chrome — эти настройки привели к

появлению заголовка «Accept-Language: en-US,en;q=0.8,sv;q=0.6,fi;q=0.4».
4 Хотя имело бы смысл просто перечислить языки в порядке предпочтения, «q=» указывает на
«коэффициент качества», который представляет собой порядок предпочтения языков. Почему такое
осложнение? Это связано с более широкой концепцией «согласования контента», встроенной в
спецификацию HTTP. Другие варианты контента, такие как качество или тип, могут более детально
основываться на факторе качества. Однако на практике согласование содержания на этом уровне
используется редко.
Многоязычная обработка | 207

ЯзыкПравила
Что, если пользователь выберет язык, для которого у вас нет контента? Ваш
сайт может предлагать контент только на английском и шведском языках. Что
делать, если браузер запрашивает финский?
Во-первых, вам необходимо понимать, что информация в заголовке Accept-
Language, имени домена или сегменте URL-адреса — это просто запрос.
Пользователь запрашивает контент на этом языке. Очевидно, что вы не можете
служить языку, которого у вас нет. В этих случаях ничего ломать не требуется;
вам просто нужно сделать выбор относительно того, как вы хотите поступить.
У вас есть несколько вариантов:
• Вернуть «404 не найдено».который сообщает посетителю, что у вас нет контента.5

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

как вы обрабатываете запросы на контент на определенном языке при
рендеринге остальной части страницы, особенно контента в ее окружении?
Если у вас переведено 100% контента, то это не проблема, но что делать, если
сайт переведен лишь частично?
В большинстве случаев CMS потребует указания языка «по умолчанию» (в
нашем примере английского), на котором существует весь контент. Это
базовый язык, а любой другой язык считается переводом контента на язык по
умолчанию. Этот
5 Технически правильный код статуса должен быть «406 Not Acceptable», что означает, что контент
может быть создан только с «характеристиками, неприемлемыми в соответствии с заголовками
принятия, отправленными в запросе». Однако это используется редко и может сбивать с толку,
поэтому большинство сайтов возвращают ошибку 404 Not Found.
6 Это характерно для «языковых семей» или «праязыков», которые представляют собой группы
схожих региональных языков. Например, норвежский, шведский, датский, фарерский и исландский
языки имеют отдаленное отношение к историческому языку, называемому древнескандинавским.
Большинство европейских языков также считаются германскими и имеют много общих черт
(большие части алфавита, пунктуация и форматирование, например направление чтения слева
направо).

для некоторых систем может означать, что контент не может существовать на
другом языке, если он сначала не существует на языке по умолчанию.7
На частично переведенном сайте часть контента может быть переведена на
другие языки. Если кто-то запрашивает один из этих языков (например,
шведский), и вам удается создать желаемый контент на этом языке, у вас все
равно остается проблема с отображением другого контента на странице —
например, меню навигации — когда части для этого может потребоваться
контент, который не был переведен.
Здесь у вас есть два варианта:
• Просто удалите весь непереведенный контент.

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

шведский переведено только 30% сайта, то навигация будет значительно
меньше. Во втором примере весь контент будет доступен, но некоторые ссылки
будут на шведском языке, а другие — на английском (по умолчанию).
Языковые варианты
В каждой стране также могут быть определенные диалекты языка. В этих
случаях в соответствии со стандартом ISO-639 коды языков пишутся через
дефис. Например, «fr-ca» означает «французский язык, на котором говорят в
Канаде», а «en-nz» означает «английский язык, на котором говорят в Новой
Зеландии».
Некоторые страны требуют дифференциации. Например, в Норвегии
существует два официальных варианта письменного и устного языка:
Букмол
«no-nb», официальный вариант
Нюнорск
«нет-нн»,буквально «новый норвежский»
Все органы власти по закону обязаны публиковать/передавать 25% своего
контента в Нюнорске. В таких случаях обычно применяются резервные
правила. Для 75% контента, который не обязательно должен находиться в
Nynorsk, запрос контента в «no-nn», скорее всего, будет настроен на возврат к
«no-nb».
7 Хотя это и не связано строго с вашей CMS, это малоиспользуемый вариантСВЯЗЬТег можно
использовать для указания на эквивалентный контент на других языках:<link rel="alternate"
hreflang="se"href="http://se.mywebсайт.com/" />. Некоторые индексаторы поисковых систем
используют это для идентификации одного и того же контента на нескольких языках.
Языковые правила | 209
ВнеТекст
Хотя текст — это контент, на который чаще всего влияет локализация, это не
единственный контент:
• Изображения и другие медиаможет иметь несколько переводов в

зависимости от языка или культуры. Посетителей из некоторых стран легко
непреднамеренно обидеть, показав изображения, выходящие за рамки их
культурных норм. Например, в течение многих лет при доставке
китайского контента было принято избегать показа изображений семей, в
которых более одного ребенка. Точно так же в преимущественно
мусульманских странах Красный Крест известен как Красный Полумесяц с
другим логотипом, соответствующим названию.8
• URL-адресакак мы отмечали ранее, могут быть специфичными для каждого
языка. Это приводит к дополнительной сложности: контент больше нельзя
перевести на другой язык, просто изменив индикатор языка (будь то имя
домена, сегмент URL или заголовок запроса), поскольку фактический путь
к контент на другом языке отличается. Если кто-то изменит индикатор
языка «se» на «en», он может получить ошибку 404 «Не найдено»,
поскольку «/en/min-nyheter-releasen» не является допустимым путем, даже
если этот контент существует на английском языке по другому пути
( «/en/my-news-release»).
• Текст шаблонанужно будет изменить. Слово «Поиск» на HTML-кнопке
часто не контролируется содержимым, а встроено в шаблон. При
сопровождении шведского контента его необходимо будет отображать как
«Sök». В зависимости от платформы и языка шаблонов эти текстовые
фрагменты часто хранятся в файлах ресурсов, управляемых вместе с
шаблонами, а затем извлекаются и включаются во время рендеринга.
• Форматирование шаблоначасто зависит от культуры. Например, «$1,000,00»
на английском языке.«$1 000,00» на итальянском языке и «$1 000,00» на
шведском языке. Очевидно, что «$» тоже проблематичен, но замена его на
символ евро или кроны фундаментально меняет ценность. Эта информация
о форматировании часто доступна в виде параметра шаблона, хотя этот
параметр должен быть обнаружен и установлен разработчиком шаблона.9
• Структура шаблонаиногда приходится меняться в зависимости от
структурных характеристик языка. Французский, например, занимает в
среднем на 30% больше места, чем английский. Немецкий, как известно,
также длинный.10 Кроме того, некоторые языки читаются справа налево
(например, иврит и арабский), а другие — вертикально.
8 Это точнее называть «переводом культуры», а не «переводом языка».

9 Эти настройки часто называют «локальными настройками» пользователя.
10 Что, кстати, может быть одной из причин, почему немцы используют Twitter заметно реже, чем
другие страны. Гораздо сложнее уместить немецкий язык в 140 символов, чем в других языках.
(несколько восточноазиатских языков). Эти языки могут потребовать
серьезных изменений шаблонов, а иногда даже создания собственных
шаблонов.
Редакционный Рабочий процесс и ИнтерфейсПоддерживать

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

параллельного представления контента, который необходимо перевести.
Это позволяет переводчику просматривать контент на одном языке и
одновременно переписывать контент на другом на одном и том же экране.
• Редактирование языков может быть ограничено разрешениями, чтобы
гарантировать, что носитель английского языка, говорящий только на
одном языке, не попытается «сделать это» и внести изменения в шведскую
версию страницы.
• Переводы могут быть заблокированы и сгруппированы по языку по
умолчанию, поэтому новый контент не может быть опубликован до тех
пор, пока не будут добавлены или обновлены переводы на все другие
необходимые языки.
• Многие системы поставляются с предварительно настроенными рабочими
процессами и группами пользователей для добавления дополнительных
переводов. Группы пользователей могут зависеть от языка, и начало
рабочего процесса для определенной группы может автоматически
добавить новый перевод и направить задачу квалифицированному
переводчику.
• Редакторы форматированного текста имеют различную поддержку
нескольких языков, особенно негерманских языков, таких как арабский и
японский. Вставка символов может потребоваться для добавления
символов, специфичных для языка, для пользователей, у которых нет
правильных раскладок клавиатуры. «О» — это не «Ø», и если у вас ее нет
на клавиатуре, вам придется найти способ вставить ее.
• Ссылки от одного объекта контента к другому могут зависеть от языка. В
некоторых случаях вы можете захотеть дать ссылку на конкретную часть
контента на определенном языке. По умолчанию ссылки, скорее всего,
будут ориентированы на тот же язык, который используется на странице,
на которой они появляются (например, со шведского на шведский), но если
контент, на который имеется ссылка, недоступен на этом языке,
необходимо будет указать другой язык. выбрано.
Поддержка внешних переводческих услуг

Многие организации предоставляют коммерческую поддержку перевода, и
ваша CMS может напрямую взаимодействовать со службой перевода
посредством автоматизации.
XLIFF (формат файла обмена локализацией XML; обычно произносится как
«ex-lif») — это стандартная XML-спецификация OASIS для передачи контента
для перевода.
Языковые правила | 211

ция. Контент можно преобразовать в XLIFF и доставить в переводческую
фирму, и тот же файл будет возвращен с включенным переведенным
контентом. Многие системы допускают прямой импорт этого контента,
добавляя предоставленный языковой перевод (или обновляя существующую
версию).
Идя еще дальше, многие поставщики переводов предлагают плагины для
распространенных платформ CMS, которые позволяют инициировать внешний
рабочий процесс перевода, который автоматически передает контент в службу
перевода. Содержимое переводится и возвращается в CMS, а объект
содержимого обновляется и либо публикуется автоматически, либо
представляется редактору на проверку. Некоторые из этих плагинов
предоставляются бесплатно в качестве стимула использовать службу перевода,
которая их предлагает.
Перспектива: The Сложность изИнтернационализация

Сет Готлиб
Когда я слышу, как кто-то жалуется на сложность
управления одноязычным веб-сайтом, я чувствую себя
отцом десяти детей, посмеивающимся над истерикой
родителя-новичка. Я помню это ударение, но в масштабе
одного языка оно кажется настолько тривиальным, что я не
могу понять, как я из-за этого разволновался. Особенно
приятно, когда я вижу «поддерживает локализацию» в
сочетании с другими требованиями, такими как «редактор
WYSIWYG».
Правда в том, что интернационализация не является особенностью; это аспект,
который умножает сложность всех остальных функций и аспектов платформы.
Чтобы проиллюстрировать этот момент, давайте рассмотрим некоторые
проблемы управления контентом и то, как они усугубляются при публикации
на нескольких языках:
Достижение консенсуса
Одна из самых сложных частей веб-проектов — обнаружение скрытых
точек разногласий и достижение консенсуса среди заинтересованных
сторон. Имея многоязычный веб-сайт, вы привносите совершенно разные
точки зрения и потребности. Возможно, вы даже попросите другие группы
отказаться от автономии и контроля.
Дизайн
Помните, сколько усилий было потрачено на разработку дизайна? Кнопки
должны быть достаточно большими, чтобы поместиться на них слова,
заголовки не должны переноситься и т. д. Многоязычные веб-сайты
должны обеспечивать расширение текста (например, в немецких переводах
английского языка используется до 40% больше символов). Кроме того, тот
изящный шрифт, который вы выбрали, вероятно, не поддерживает все
нужные вам символы.
Разработка
Вы будете удивлены, сколько контента управляется в самих шаблонах.
Например, слово «поиск» на кнопке поиска, вероятно, было жестко
запрограммировано в файле шаблона. Хуже того, разработчик мог бы
срезать угол,

поместив это слово в изображение, чтобы получить правильный макет.
Чтобы обеспечить локализацию, все эти строки следует хранить в
отдельных файлах, которые можно отправить переводчику. Перемещение
этих строк из шаблонов невероятно трудоемко и чревато ошибками.
Вырезать новые изображения с переведенным текстом и поддерживать их
актуальность практически невозможно.
Обзор
Помните, как вы были смущены, когда эта опечатка прошла проверку? Ну
и как вы думаете, сколько опечаток в этом тексте, который вы даже
прочитать не сможете? Учитывали ли вы разочарование от того, что не
собираетесь публиковать контент на исходном языке до тех пор, пока он не
будет переведен и эти переводы не будут проверены?
Хранениеконтент свежий
Я не могу сказать вам, сколько компаний обещают обновлять домашнюю
страницу каждую неделю — «просто для того, чтобы контент оставался
свежим». Вы ожидали, что CMS практически обновится сама, и, вероятно,
не учли стоимость перевода всего этого контента. Просто передать контент
переводчикам и обратно — это практически полный рабочий день на
регулярно обновляемом веб-сайте.
Горькая ирония заключается в том, что большинство организаций
заинтересованы в внедрении (или повторном внедрении) CMS, потому что
считают, что управлять веб-сайтом слишком сложно. Они добавляют
интернационализацию в качестве требования «пока мы этим занимаемся» (или
для того, чтобы оправдать бюджет), и в итоге им приходится делать больше
работы, чем вначале.
Итак, если вас интересует идея многоязычной публикации, сделайте
обслуживание этих рынков основой вашего бизнес-кейса и приготовьтесь
вложить деньги и усилия, необходимые для того, чтобы сделать это правильно.
Сет Готлиб — вице-президент по разработке продуктов в Lionbridge
Technologies.крупнейшая в мире фирма по локализации.
Персонализация, аналитика и автоматизация маркетинга

В нынешнем конкурентном бизнес-климате многие организации покупают не
столько систему управления контентом, сколько систему контент-маркетинга.
Чтобы объяснить, почему, требуется немного истории.
Где-то в последнее десятилетие поставщики CMS внезапно догнали клиентов.
В течение многих лет клиенты требовали все большего количества
редакционных и управленческих функций, а поставщики постоянно догоняли
их. Однако внезапно наступил момент, когда поставщики достигли примерного
паритета с тем, что просили редакторы, и, наконец, предоставили большую
часть функциональности, которую хотели редакторы и контент-менеджеры.
Постоянно пытаясь выделиться среди конкурентов, коммерческие поставщики
искали другую аудиторию с неудовлетворенными потребностями и нашли
рынок.
Персонализация, аналитика и автоматизация маркетинга |2 1 3

эр. С этого момента началась гонка за включение в свои CMS все большего и
большего количества маркетинговых функций.
Индустрия контент-маркетинга существовала уже много лет — такие
компании, как Adobe, HubSpot, eTrigue и Exact Target, уже давно предоставляли
услуги по таргетингу и персонализации контента, — но поставщики CMS
устремились на этот рынок. Связь между управлением контентом и
маркетингом была очевидна, поэтому коммерческие поставщики попытались
усилить свои предложения с помощью этих инструментов.
Результатом стали наборы маркетинговых инструментов с различной
функциональностью и применимостью, построенные на базе CMS и часто
поставляемые в комплекте с ней (или доступные в виде надстройки или модуля
за дополнительную плату).11).
АнонимныйПерсонализация
Цель любого веб-сайта, ориентированного на маркетинг, — индивидуально
адаптироваться к каждому посетителю. Теоретически один веб-сайт может
меняться в ответ на информацию о посетителе и предоставлять контент и
функциональность, необходимые конкретному посетителю в данный
конкретный момент, чтобы более эффективно побудить посетителей к
действию.
Эта функция известна под общим названием «персонализация». Существуют
два совершенно разных типа:
• Известная персонализация, где личность посетителя будет окончательно

известна с течением времени. Очевидно, что это работает только тогда,
когда посетители активно идентифицируют себя, обычно путем входа в
систему. Таким образом, каждый пользователь имеет постоянную
идентификацию на веб-сайте, а действия и предпочтения могут
отслеживаться и сохраняться конкретно для этого пользователя. У
пользователей может быть «панель управления» или другой интерфейс, где
они могут изменять свои собственные настройки.
• Анонимная персонализация, где посетитель неизвестен веб-сайту. В этих
случаях веб-сайт должен получить информацию о личности или
демографической группе посетителя на основе подсказок, полученных
через поведение или другую информацию, такую как геолокация,
ссылающийся веб-сайт или даже время суток.
Известная персонализация доступна уже много лет. В этих случаях

пользователи четко знают, что веб-сайт имеет их личность, и часто ожидают,
что смогут изменить способ взаимодействия веб-сайта с ними. Веб-сайт New
York Times, например, имеет целый интерфейс, позволяющий подписавшимся
пользователям выбирать предпочтительные разделы новостей, и эта
информация пронизывает их взаимодействие со службой (даже за пределами
веб-сайта, включая мобильные приложения New York Times).
11 Несколько лет назад система с прейскурантной ценой 4999 долларов США выпустила
дополнительный модуль для маркетинга и персонализации по прейскурантной цене 14 999 долларов
США — в три раза дороже самой CMS.

Но анонимная персонализация стала большой тенденцией последних пяти лет.12
Это по-прежнему в основном ограничивается коммерческими поставщиками,
которые как группа, как правило, более ориентированы на маркетинг.
Первый шаг анонимной персонализации требует от маркетологов создания
демографических групп, на которые они смогут сегментировать посетителей.
Создание этих групп требует идентификации и настройки нескольких
критериев для оценки посетителя. Критерии делятся на три основных типа:
Сессия
Факторы, специфичные для текущего сеанса посетителя (например,
местоположение, входящие поисковые запросы, технические параметры
веб-запроса и т. д.).
Глобальный
Факторы, связанные с внешними критериями и универсальные для всех
посетителей и сеансов (например, время суток, доступный контент и т. д.).
Поведение
Факторы, связанные с накопленным контентом, который потреблял
конкретный посетитель, и действиями, предпринятыми посетителем на веб-
сайте (обычно в текущем сеансе, но необязательно включая и предыдущие
сеансы), при условии, что выбор пользователями этого контента
способствует идентификация их аудитории13
Например, для веб-сайта туристического агентства мы могли бы решить
применить дополнительный маркетинг к нашим туристическим пакетам по
Карибскому морю, ориентируясь на посетителей, которые могут ощутить на
себе влияние зимы. Для этого мы определим демографическую группу,
которую назовем «Жители ледника». Наши критерии для этой группы:
• Местоположение посетителя должно находиться к северу от 40-й широты,

или текущая температура в его месте должна быть ниже 50 градусов по
Фаренгейту.14
• Текущая дата должна быть между 15 октября и 15 марта.
• Посетитель должен был просмотреть хотя бы одну путёвку в место,
которое мы отнесли к категории «Тёплая погода».
12 Общий термин «персонализация» когда-то относился исключительно к известной персонализации,

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

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

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

специальный рекламный элемент в боковую панель для «Жителей ледника»,
подчеркивающий температуру на Бора-Бора и наши фантастические пакеты
отдыха там. Кроме того, мы могли бы загрузить дополнительную таблицу
стилей, чтобы постепенно изменить цветовую палитру веб-сайта на более
теплые цвета.
Реализованный на практическом уровне, это позволяет маркетологу выделить
релевантный контент для пользователей, которые, по его мнению, отреагируют
на него. В самом абсурдном варианте это позволит управлять меньшими
отдельными элементами контента, которые затем динамически объединяются
во время запроса для создания уникального, индивидуального веб-сайта для
каждого пользователя.15
Очевидно, что с большой силой приходит и большая ответственность.
Довольно легко создать проблемы с юзабилити, изменяя структуру или контент
веб-сайта в реальном времени. Если пользователь просмотрел
персонализированный контент и отправил URL-адрес другу, этот друг может
не увидеть то же самое при посещении. Первоначальный пользователь может
даже не увидеть то же самое при следующем посещении сайта или даже во
второй раз, когда он перейдет на ту же страницу в том же сеансе.
Это также поднимает вопрос о том, как обрабатывать индексацию поисковыми
системами. Когда робот Googlebot (или даже собственный индексатор сайта)
посещает сайт, какой контент он индексирует? Оставляете ли вы
неперсонализированный контент по умолчанию или создаете группу
персонализации специально для индексаторов поисковых систем и отображаете
весь контент в виде
15 Если вас интересует персонализация, я настоятельно рекомендую «Пузырь фильтров» Эли Паризера
(Пингвин), который глубоко углубляется в порой зловещие способы, которыми веб-сайты и
компании используют персонализацию, и вытекающие из этого изменения в нашей культуре и
мнениях.

попытаться проиндексировать как можно больше? Но что тогда происходит,
когда страница возвращается в результате поиска Google на основе контента,
которого нет, если только поведение пользователя не поместило его в
определенную группу персонализации?
Персонализация, конечно, интересная функция, но она ставит под сомнение
один из основных принципов Всемирной паутины: контент идентифицируется
исключительно по URL-адресу. На сильно персонализированном сайте URL-
адрес — это всего лишь «предложение» контента. Фактический контент,
доставляемый в ответ на URL-адрес, может сильно различаться.
Перспектива: Персонализация: The Идея Против TheРеальность

Джаррод Гинграс
Всем нравится идея настоящей персонализации. Доставить
нужный контент нужному пользователю в нужное время —
цель каждого маркетолога. В демонстрациях поставщики
CMS любят впечатлять команды отборщиков
способностью своего продукта обеспечивать столь
сложный уровень доставки контента. Однако реальность
такова, что, хотя многие предприятия покупают CMS,
которые технически способны обеспечить эту
функциональность, очень немногие предприятия имеют
внутренние возможности для правильной реализации
стратегии персонализации такого типа.
Разработка стратегии персонализации или сегментации выходит за рамки
проектирования базы данных и кода для подачи динамического
персонализированного контента пользователям. Во многих случаях вам
необходимо убедиться, что CMS имеет интерфейс для управления аудиторией,
позволяющий вводить пользовательскую информацию, управлять группами и
профилями или переопределять автоматические процессы. Вероятно, вам
понадобится отчетность на основе пользователей и групп, которую не смогут
предоставить обычные инструменты анализа веб-журналов. Усилия по
внедрению и адаптации этих инструментов администрирования и отчетности не
следует недооценивать.
В зависимости от того, насколько детализировано ваше профилирование,
управлять большими группами может быть проще, но при этом может
пострадать глубина персонализации, поскольку таргетинг на конкретный
контент на уровне отдельного пользователя может быть очень
непредсказуемым. Хотя CMS может помочь вам, предоставив набор функций
для стимулирования ваших усилий по персонализации, более серьезные усилия
заключаются в разработке вашей стратегии и выборе эффективного и
осуществимого подхода.
Любая эффективная стратегия персонализации требует значительных
предварительных и постоянных инвестиций. Необходимые требования к
ресурсам делают этот тип персонализации непомерно дорогим для
большинства предприятий. К сожалению, многие амбициозные предприятия
осознают, что им не по силам, только тогда, когда уже слишком поздно.
Сообразительные покупатели CMS не будут увлечены привлекательными
демонстрациями персонализации от поставщиков. Скорее, они будут
реалистичны в отношении своих внутренних способностей и ресурсов. Обычно
это означает, что нужно начинать с малого, с более широкой сегментации,
большого количества тестов и доработок, пока они не достигнут нужного
уровня персонализации для них и их потребителей.

Джаррод Гинграс — управляющий директор и аналитик Real Story Group,
исследовательской и
консультационная фирма, специализирующаяся на оказании помощи
предприятиям в улучшении цифрового маркетинга и цифровых
технологий.Тальные технологические решения на рабочем месте.
Интеграция аналитики
Системы аналитики веб-сайтов не новы, но несколько лет назад появился
стимул начать включать эту функциональность в CMS. В результате появились
аналитические пакеты, которые не предлагали особых новых функций, а
просто предлагали их внутри интерфейса CMS.
Ключевой вопрос: какие новые функции дает интеграция с CMS? Ответ, судя
по всему, невелик. Аналитика в основном основана на двух вещах:
• Сам входящий запрос

• События, связанные с активностью, происходящей при загрузке страницы.
Входящий запрос обычно фиксируется еще до того, как CMS вступит в игру, а
события на стороне клиента отслеживаются с помощью кода, разработанного в
процессе создания шаблонов. Учитывая это, ценность интеграции аналитики
сомнительна.
С тех пор тенденцией стала интеграция аналитических пакетов от других
поставщиков, наиболее распространенным из которых является Google
Analytics. Многие системы теперь предлагают возможность подключаться к
специальной учетной записи Google Analytics для сайта, которым управляет
CMS, и отображать эту информацию внутри интерфейса, сопоставленную с
самим контентом.
Редакторы могут иметь возможность просмотреть часть контента в CMS, а
затем перейти на другую вкладку или виджет боковой панели в том же
интерфейсе, чтобы просмотреть аналитическую информацию конкретно по
этому контенту.
Благодаря функциям персонализации, описанным в последнем разделе,
некоторые аналитические отчеты могут иметь ценность с точки зрения
информации о том, сколько посетителей соответствует критериям для
конкретной демографической группы. Это даст редакторам некоторое
представление о том, насколько распространена или редка определенная
комбинация посетителей.
Маркетинг Автоматизация и CRMИнтеграция

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

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

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

этой области, при этом CMS включает в себя все больше и больше функций
CRM и автоматизации маркетинга. Некоторые заходят так далеко, что
предлагают управление кампанией по электронной почте непосредственно из
CMS, дополненное отслеживанием ссылок и кликов, и даже прямое управление
клиентами.
Однако по мере того, как поставщики средств автоматизации маркетинга, такие
как HubSpot, Marketo, Pardot и другие, становятся все более и более
искушенными, отрасль понимает, что заранее созданные интеграции с этими
системами с большей вероятностью привлекут клиентов. Таким образом,
поставщики средств автоматизации маркетинга создают интеграцию между
своими системами и поставщиками CMS, стремясь представить единую
платформу, обеспечивающую более желательный продукт для обеих сторон.
Перспектива: переход к цифровому опыту

Боб Эгнер
Системы управления веб-контентом (WCM) уже давно
предлагают преимущества как ИТ-пользователям, так и
бизнес-пользователям. Имея WCM, бизнес-пользователи
могут управлять контентом и отображать его в Интернете,
меньше полагаясь на помощь своих ИТ-отделов, а ИТ-
отделы, в свою очередь, могут уделять больше времени
другим инициативам после первоначального внедрения. В
эпоху, когда Интернет служил формой вещательных
средств массовой информации (аналогично рекламным
щитам или радиорекламе), эти системы предоставляли
информационные технологии, предназначенные для
решения внутренних проблем.
Но, как и в случае с Интернетом, времена меняются. Компании,
транслирующие идею «один размер подходит всем», теряют свое конкурентное
преимущество. Это возраст клиентов и компаний, которые, как выразились
технология, которую они когда-то использовали, чтобы сделать жизнь своих
сотрудников более удобной, как средство
передавая это удобство своим клиентам.
Этот сдвиг превращает информационные технологии в бизнес-технологии,
превращая WCM в цифровой опыт (DX). Смещая фокус с массового
маркетинга на индивидуальный цифровой опыт, такие компании, как Amazon,
Target и Pizza Hut, адаптируют свое сообщение в соответствии с
взаимодействием: это первый посетитель? Или этот посетитель уже что-то
купил? Что они купили? Насколько близко посетитель к определенному месту
и что мы можем ему предложить, чтобы побудить его посетить?
В эпоху клиентов потребители требуют контекстной актуальности в сочетании
с оперативностью. Они готовы рассказать вам больше о себе, чтобы вы могли
облегчить им жизнь. Руководители ИТ-отделов и бизнеса должны работать
вместе, чтобы обеспечить переход от WCM к DX и повысить ценность бизнеса.
Пришло время перестать сосредотачиваться на том, что делают ваши
технологии, и вместо этого сосредоточиться на том, как вы можете
использовать их, чтобы найти способы дифференцировать свою компанию на
ФормаЗдание
Управление контентом обычно связано с выводом контента; однако в
большинстве систем есть некоторые методы обработки приема контента
посредством создания форм.
При создании форм у редактора есть две основные проблемы:
• Генерация интерфейса формы

• Обработка данных формы после ее отправки
В обоих случаях диапазон возможных функций широк, и крайних случаев

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

формы для ввода контента.
• Тип «обратного управления контентом», при котором собираемый контент
моделируется как тип контента, а интерфейс, представленный
пользователю, по сути, «перевернут», когда пользователь видит интерфейс
редактирования/создания, а не интерфейс. выход. Неосознанно
пользователи создают объекты управляемого контента с помощью ввода
формы. (например, мы могли бы создать тип контента для «Данные
обратной связи», и посетитель увидит форму создания для этого и
фактически создаст объект контента из этого типа, заполнив форму).
Первое гораздо более распространено, чем второе, и гораздо более полезно.

Генерация форм ввода обычно является задачей редактирования, а
моделирование контента — задачей разработчика. Ожидать, что редакторы
будут моделировать контент, отражающий потребление посетителей, может
быть слишком много.
Редакторы форм работают на разных уровнях структуры:
• Меньшинство основано на редакторах форматированного текста, которые

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

«Добавить поле формы» и указать информацию, подобную следующей:
• Тип поля (текстовое поле, многострочное текстовое поле, выбор даты,

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

Мы не часто обращаем внимание на тот факт, что формы могут
быть визуально сложными. Для каждого элемента часто
имеется (1) метка, (2) входной элемент, (3) дополнительные
инструкции по вводу и (4) сообщение проверки/ошибки. И это
повторяется для каждого поля формы. Кроме того, все эти
элементы должны хорошо работать вместе (что часто означает
группировку полей по концептуальному назначению),
корректно работать и в конечном итоге иметь смысл для
конечного пользователя.
Нет особых споров о том, как читать серию абзацев текста. Для
сравнения, каждая форма — это своего рода UX-проблема,
которую необходимо решить. Имеют ли ваши редакторы право
решить эту проблему?
Всякий раз, когда вы имеете дело с пользовательским контентом, возникают

проблемы с пограничными случаями и очисткой/проверкой данных. Как мы
обсуждали вГлава 6, возможные требования к форматам данных, а также
способы их обхода и иного злоупотребления пользователями практически
безграничны.
Вот некоторые общие спецификации проверки:
• Требуется ввод.
• Входные данные должны соответствовать указанному формату (числовому,
определенному количеству цифр или шаблону регулярного выражения).
• Ввод даты (или числовой ввод) должен находиться в пределах указанного диапазона.
• Входные данные должны быть из указанного списка опций.
(Похоже ли это на моделирование контента? Так и должно быть. По сути, вы

моделируете получение данных. Это реификация на самом базовом уровне.)
Редакторы обычно запрашивают три дополнительные области
функциональности, но они плохо поддерживаются на рынке. Они есть:
• Условные поля, которые отображают, скрывают или изменяют параметры

выбора на основе предыдущего ввода. Классическим примером являются
два раскрывающихся меню, где параметры второго раскрываются в
зависимости от выбора, сделанного в первом (например, выбор
производителя автомобиля в одном раскрывающемся списке приводит к
изменению второго раскрывающегося списка, в котором отображаются все
модели, предлагаемые этого производителя).

• Многочастные формы, которые позволяют пользователям заполнить один
раздел формы, а затем каким-то образом перейти ко второму разделу,
который дополняет данные, собранные первым. Еще сложнее то, что
разделы могут быть условными, так что значения, выбранные в первом
разделе, будут определять, какие параметры предлагаются в последующих
разделах (или предлагаются ли последующие разделы вообще).
• Элементы формы, настроенные по содержимому, где параметры,
предлагаемые в раскрывающихся меню, переключателях или списках
флажков, управляются данными контента. Например, форма регистрации
класса может отображать список классов, извлеченный из объектов
контента, хранящихся в CMS.
Эти параметры снова подчеркивают (или еще больше размывают) грань между
редакционным контролем и контролем разработчиков. В какой момент
сложность формы переходит от того, с чем может справиться редактор, к тому,
что должен реализовать разработчик? Граница нечеткая, но она достаточно
твердая — редакторы обычно не знают, где находятся границы, пока не
наткнутся на требование, которое невозможно реализовать.
Форма ДанныеУмение обращаться

После того как форма соберет данные и проверит их, необходимо принять
решение о том, что с ними делать. Общие варианты включают в себя:
• Данные могут быть отправлены по электронной почте на указанный набор адресов.

• Данные могут храниться в CMS для поиска, просмотра и экспорта.
• Данные могут быть отправлены по указанному URL-адресу, обычно в виде
запроса HTTP POST или, реже, в виде полезных данных веб-службы.
Большинство систем позволят вам выбрать первые два параллельно.

Третий вариант, хотя и предлагает безграничные возможности интеграции,
снова приводит к тому, что процесс создания форм и управления ими
разделяется между редакторами и разработчиками. Хотя редактор может
создать форму и отправить данные в веб-службу, разработанную для нее, это в
первую очередь ограничивает ценность создания формы в редакционном
порядке. Веб-сервис, скорее всего, ожидает данные в определенном формате, и
если редактор меняет форму и результирующие данные, которые он передает,
существует большая вероятность того, что веб-сервис не будет работать
правильно, если разработчику не придется его модифицировать. .
Лучший совет по работе со строителями и обработчиками форм — просто
снизить свои ожидания. Вашей целью должен быть простой сбор и обработка
данных и не более того. Слишком многие редакторы полагают, что
конструкторы форм позволят им создавать приложения или иным образом
участвовать в сложной интеграции корпоративных данных без какого-либо
надзора или помощи со стороны разработчиков. Это необоснованное
предположение, которое всегда приводит к неоправданным ожиданиям.
Формирование здания | 223
Простой сбор данных вполне возможен, но платформа разработки приложений,
которая полностью устраняет необходимость в индивидуальной разработке в
будущем, — это просто не то ожидание, которое можно разумно оправдать.
Интеграция внешних ФормаДвигатели

Существует ряд широко распространенных сервисов
механизма форм, таких какВуфу иФормаСайт, и даже Google
Docs можно адаптировать для этой цели. Все эти сервисы
предлагают способы встраивания форм в существующие
сайты.
Возможно, лучший способ создания форм — использовать
внешний сервис и отображать формы как некий тип
встроенного контента. Редакторы могут создавать свои формы
в другом сервисе, а затем встраивать ссылку на идентификатор
формы в управляемый контент, который будет отображать
необходимый JavaScript для отображения формы.
Управление URL-адресами
На заре существования CMS URL-адреса контента обычно были «уродливыми»
и выдавали внутреннюю работу системы. Например:
/articles/two_column_layout.asp?article_id=354
Это отличалось от «дружественных» или «красивых» URL-адресов, которые
выглядели так, будто были созданы вручную из имен файлов и папок и
придавали некоторую семантику.16 ценность для содержания. Например:
/articles/2015/05/politics/валютный кризис в Китае
Сегодня довольно редко можно найти CMS, которая не реализует тот или иной
метод семантических URL-адресов. В случае систем с деревом контента
(обсуждаемым вГлава 7), эти URL-адреса обычно формируются путем
назначения сегмента каждому объекту контента, а затем объединения
сегментов для формирования полного URL-адреса (и, возможно, добавления
индикатора языка в начало).
Итак, если ваше дерево выглядело вот так:
• Статьи(сегмент: «статьи»)
• 2015 («2015»)
• Мэй («05»)
• Политика («политика»)
16 «Семантика» — это изучение значения. Описать что-то как «семантическое» — значит сказать, что
оно несет в себе какое-то большее значение, выходящее за рамки его первоначальной или очевидной
цели. Фактическая цель URL-адреса — просто идентифицировать контент. Семантический URL-
адрес не только идентифицирует контент, но и дает некоторое представление о нем.
• Валютный кризис в Китае («валютный кризис в Китае»)
это приведет к тому, что URL-адрес будет отображаться вторым.

Другие системы без дерева контента всегда имеют некоторую логику для
формирования URL-адресов, будь то по типу контента, положению меню или
расположению папки. Редко можно найти CMS, которая в той или иной форме
не учитывает семантические URL-адреса.
В большинстве систем URL-сегмент для конкретного объекта контента
формируется автоматически на основе имени или заголовка объекта, но также
доступен для редактирования как вручную, так и из кода. Редактор может по
какой-то причине вручную изменить сегмент URL-адреса, а разработчик может
написать код для его изменения в зависимости от других факторов (например,
для вставки даты для обеспечения уникальности).
Формирование URL-адреса на основе положения объекта контента в
географическом пространстве удобно, эффективно и в большинстве случаев
приводит к правильному URL-адресу (или, по крайней мере, к тому, который
не вызывает возражений). Однако и здесь действует «тирания дерева» — URL-
адрес формируется деревом, но объект может находиться в каком-то
положении в дереве по причинам, отличным от URL-адреса, что делает
проблематичным формирование URL-адреса из его позиция.
Например, наш пример новостной статьи мог быть организован таким образом
(под объектом года, затем объектом месяца, затем объектом темы) для удобства
административного поиска контента или по другим причинам, связанным с
разрешениями или выбор шаблона. Однако эта организация использует
структуру URL-адресов в качестве побочного продукта, а что, если вам нужно
что-то другое? Например:
/статьи/валютный-кризис-в-китайском-0515
В этом случае по какой-то причине вы хотите, чтобы заголовок статьи
составлял большую часть URL-адреса с добавлением года и месяца в конце. По
сути, год и месяц в URL-адресе должны быть «тихими», и вам нужно настроить
конкретный сегмент URL-адреса статьи, чтобы добавить дату. Некоторые
системы позволяют это, а некоторые нет.
Исторические URL-адреса, персональные URL-адреса и пользовательские

перенаправления
URL-адреса являются частью постоянной записи Интернета. Они
индексируются поисковыми системами, отправляются по электронной почте,
публикуются в социальных сетях и добавляются пользователями в закладки.
Таким образом, изменение URL-адреса может привести к появлению
неработающих ссылок. Кроме того, когда URL-адрес формируется деревом,
изменение сегмента URL-адреса объекта, расположенного «высоко» в дереве,
обязательно приведет к изменению всех URL-адресов содержимого под ним,
что может составлять тысячи страниц. Невнимательность в таких ситуациях
может иметь катастрофические последствия.
Некоторые системы учитывают это, сохраняя исторические URL-адреса
объектов, поэтому, если URL-адрес объекта изменится, система запомнит
старый URL-адрес и сможет автоматически перенаправить запрос на него.
Другие системы этого не поддерживают, и эту функциональность приходится
добавлять вручную.
Управление URL-адресами | 225

Редакторы также могут захотеть предоставить совершенно альтернативный
URL-адрес для объекта контента — например, более короткий URL-адрес для
использования с другими носителями (печатными материалами или вывесками)
или URL-адрес, имеющий маркетинговое значение для контента,
расположенного глубоко на сайте, который может иметь меньше преимуществ.
‐ естественный URL-адрес, естественно.
Например:
www.mywebsite.com/free-checking
www.mywebsite.com/signup
В этих случаях иногда может быть предоставлен альтернативный URL-адрес,
который либо создает контент напрямую, либо перенаправляет пользователя к
контенту. В первом случае контент по-прежнему может быть доступен по
естественному URL-адресу, что поднимает вопрос о том, какой URL-адрес сам
сайт использует при ссылке на контент в навигации.17
Помимо соображений тщеславия, редакторы могут захотеть использовать
альтернативные URL-адреса своего контента, чтобы учитывать изменения
словарного запаса. Например, если название вашего продукта изменилось и
старое имя присутствует в 100 разных URL-адресах, это представляет собой
маркетинговую проблему. Другие ситуации могут заключаться в продолжении
предоставления доступа к контенту после миграции сайта. В этих случаях для
обеспечения непрерывности может потребоваться ряд альтернативных URL-
адресов для объекта контента.
Некоторые системы позволяют хранить альтернативные URL-адреса с
контентом, в то время как другие могут предоставлять интерфейс для хранения
данных, который сопоставляет старые URL-адреса с новыми URL-адресами.
Некоторые системы могут выполнять автоматическое перенаправление в
случае ошибки 404, в то время как другим системам придется настраивать эти
перенаправления вручную, обычно путем включения кода поиска и
перенаправления при выполнении самой страницы 404. (Это означает, что код
выполняется и перенаправляется только в случае доступа по старому URL-
адресу, который в противном случае вернул бы ошибку 404.)
Управление несколькими объектами

Если вы хотите развернуть второй веб-сайт с помощью CMS, поддерживающей
несколько сайтов, вы можете выбрать одно из двух решений:
• Встаньте совершенно отдельный экземпляр софта (на том же сервере, а то

и на другом сервере). Новый экземпляр рассматриваемой CMS не будет
знать или иметь отношение к существующему веб-сайту.
• Разместите второй веб-сайт внутри существующего экземпляра CMS. Этот
веб-сайт будет иметь более глубокие знания о первом веб-сайте и,
возможно, сможет делиться с ним контентом и активами.
17 Доступность одного и того же контента по нескольким URL-адресам также может иметь
негативные последствия для SEO.

Размещение более одного веб-сайта в одном экземпляре CMS теоретически
может снизить затраты на управление и разработку за счет обмена данными
между двумя веб-сайтами. К элементам, которыми часто делятся, относятся:
• Объекты контента, например изображения или другие редакционные

элементы. Например, ваши два веб-сайта могут иметь одну и ту же
политику конфиденциальности или отображать одни и те же выпуски
новостей.
• Пользователи, либо редакция, либо посетители. Одни и те же редакторы
могут работать над контентом на обоих сайтах, и пользователи могут
ожидать, что одни и те же учетные данные будут работать на всех сайтах.
• Код, включая код внутренней интеграции и код шаблона. Сайты могут
использовать общие функциональные возможности, и возможность
разработать их для одного сайта и повторно использовать на другом может
быть значительным преимуществом.
Однако трудно сделать общий вывод о том, выгодно это или нет, поскольку два
сайта в одном экземпляре CMS могут иметь широкий диапазон отношений. В
некоторых ситуациях делиться — это преимущество, а в других —
обязанность.
С одной стороны, второй сайт может быть просто переработкой первого. Он
может иметь точно такое же содержание и архитектуру, но иметь немного
другой бренд.18 В этом случае совместное использование редакторов, контента
и кода чрезвычайно выгодно.
На другом конце шкалы второй сайт может принадлежать совершенно другой
организации (возможно, вы являетесь третьей стороной, предоставляющей
SaaS-подобный хостинг CMS). В этом случае совместное использование одного
и того же экземпляра CMS, скорее всего, создаст больше проблем, чем пользы,
поскольку предотвращение совместного использования редакторов, контента и
кода будет гораздо важнее, чем совместное использование чего-либо из этого,
и потребует контроля и повышенной сложности кода. .
Где-то посередине находится наиболее распространенный сценарий: второй
сайт предназначен для той же организации, поэтому совместное использование
редакторов полезно, а второй сайт требует части контента основного сайта, что
также может быть полезно. Но второй сайт также принесет много уникального
контента, функциональности и форматирования до такой степени, что
совместное использование кода и шаблонов станет невозможным. Это
становится все более распространенным, поскольку отделы маркетинга
поддерживают более крупные кампании с помощью отдельных микросайтов,
которые намеренно сильно отличаются от основного сайта с точки зрения
стиля и формата.
Кроме того, второму сайту могут потребоваться изменения в моделировании
контента, поэтому совместное использование типов контента будет затруднено.
Например, если на страницах вашего микросайта есть правая боковая панель (а
на основном сайте ее нет), как с этим справиться? Добавляете ли вы атрибут
правой боковой панели к типу контента «Текстовая страница» для всей
установки и просто убедитесь, что
18 Распространены так называемые «сайты по интересам». Моя компания однажды выполнила

внедрение для организации, которая продавала фирменные финансовые продукты. У них было 86
отдельных веб-сайтов в одной и той же системе CMS, каждый из которых на 90 % использовал
один и тот же контент, с небольшими изменениями в стиле и небольшими изменениями в контенте,
чтобы дифференцировать их.
Управление несколькими объектами | 227

что редакторы основного сайта знают, что к ним это не относится? Или вы
создаете новый тип контента для микросайта и страдаете от дополнительной
сложности поддержки типов контента как «Текстовая страница основного
сайта», так и «Текстовая страница микросайта»? Что произойдет, когда
следующий микросайт должен быть запущен с другой, несколько иной
моделью контента?
Возникающая в результате путаница может затруднить управление
несколькими объектами. Основной вопрос возвращается к тому, какой уровень
совместного использования между двумя сайтами является предпочтительным
и как CMS упрощает или усложняет это. Известно, что организации
навязывают установку CMS на нескольких сайтах, руководствуясь
догматическим принципом («Мы должны быть в состоянии сделать это!»),
тогда как простая настройка другого экземпляра сайта потребовала бы меньше
усилий и привела бы к лучшему опыту как для редакторов, так и для
пользователей.
Инструменты отчетности и информационные панели

Две вещи, которые постоянно ищут редакторы и менеджеры контента, — это
контроль и душевное спокойствие. Многие CMS внедряются потому, что
организация не уверена в том, сколько у нее контента и в каком состоянии он
находится. В большинстве организаций наблюдается явное отсутствие ясности
относительно их контента, и возникает метафора «взять в руки наш контент».
часто встаю.
По этим причинам простая отчетность имеет большое значение. Редакторы и
контент-менеджеры любят видеть отчеты, которые дают им общее
представление об их контенте. Например, многие организации хотели бы
просто видеть список всех файлов изображений в своих CMS, не используемых
каким-либо контентом, который можно безопасно удалить.
Поставщики обычно не обращают внимания на отчетность по двум причинам:
• Как и все редакционные инструменты, он затрагивает меньшую аудиторию

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

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

• Незавершенные задачи рабочего процесса, назначенные вам
• Состояния рабочего процесса, которые ожидаются дольше указанного периода времени
Хотя это, безусловно, ценная информация, ни одна система не может

предугадать уровень отчетности, необходимый отдельному пользователю.
Достаточно одного редактора сказать: «Ну, на самом деле я просто хочу видеть
статьи в разделе политики, которые находятся в стадии разработки, а не все
остальное», чтобы сделать готовый отчет бесполезным.
Многие репортажи носят просто разовый характер. 19 Конечный уровень
функциональности в этом пространстве заключается в том, чтобы редактор
просто задал простой вопрос о репозитории контента в стиле Siri:
«Репозиторий, покажи мне все статьи в разделе политики, которые имеют
статус Черновик». Очевидно, что технологии еще не отвечают этой
потребности, поэтому подобные запросы придется конвертировать в какой-то
поисковый формат, чтобы обеспечить такой уровень отчетности.
Некоторые системы могут иметь интерфейс для разработки отчетов. Однако
тип и диапазон возможных запросов настолько разнообразны, что полностью
обобщенный интерфейс был бы слишком сложным — взгляните еще раз на
скриншот интерфейса Drupal Views с сайтаГлава 7 (Рисунок 7-10), и увеличить
сложность на порядок и более.
Кроме того, некоторые редакторы просто не понимают всех тонкостей своего
контента или логики запросов настолько, чтобы им можно было доверять при
создании отчета, на который они могут положиться. Если они не понимают,
что контент, ожидающий утверждения, технически может считаться
находящимся в черновике, тогда они могут создать отчет, который по своей
сути недействителен и зависеть от него.
В этих случаях лучшим решением будет компетентный API (как обсуждалось в
предыдущем разделе) в сочетании с надежной системой отчетности.
Разработчики, у которых есть хорошие инструменты поиска и платформа для
быстрого создания и развертывания отчетов, могут надеяться быстро
реагировать на потребности редакторов в разработке отчетов, когда это
необходимо.
Поиск контента
Мы обсуждали варианты поиска в предыдущих разделах — вГлава 7 мы
обсуждали поиск контента как метод агрегирования и только что обсуждали
поиск с точки зрения системного API или отчетов. Однако поиск в этих
контекстах был «параметрическим» поиском, или поиском по параметру.
Это точный, или «жесткий», поиск. Если вам нужен список всего контента,
опубликованного в 2015 году, в обратном порядке по дате, то это очень
понятная операция поиска, не подлежащая интерпретации. Год — в данном
случае 2015 — является четким, однозначным параметром и
19 Для этого случаяна латыни означает «для этой цели» и обычно означает «что-то, сделанное по
определенной или конкретной причине без предварительного планирования».
Поиск контента |2 2 9
объект содержимого либо соответствует ему, либо нет. Порядок также
однозначен: даты можно легко изменить в обратном порядке, не прибегая к
какой-либо интерпретации.
Поиск по контенту является противоположным. Это поиск контента, который
пользователи выполняют — вездесущее поле поиска в правом верхнем углу
страницы. Это «мягкий» поиск, который по своей сути является неточным.
Цель состоит в том, чтобы интерпретировать то, что хочет пользователь, а не
делать именно то, что он говорит. Предоставляемые результаты должны
представлять собой совокупность контента, связанного с запросом (даже если
он не совсем соответствует запросу), и упорядочены таким образом, чтобы
наиболее близкое совпадение находилось вверху.
TheНаука информационного поиска

Информационный поиск (IR) – это давняя область исследований. В области
международных отношений предлагаются целые курсы колледжей и даже
ученые степени, и по этому предмету существуют десятки тысяч страниц
теории. Преобразование языкового запроса в математическую формулу и ее
использование для оценки текстовых фрагментов — это область науки, которая
изучается десятилетиями.
Имейте в виду, что Google, одна из самых ценных компаний в мире, в своей
основе основывалась на теории международных отношений, которую Ларри
Пейдж и Сергей Брин разработали, будучи студентами Стэнфорда. 20 В этом
смысле IR несет единоличную ответственность за корпоративную стоимость в
миллиарды долларов.
Я упоминаю об этом только для того, чтобы представить дисциплину в
контексте. IR существует далеко за пределами управления контентом и
изучается и внедряется гораздо дольше, чем управление контентом. Поскольку
поиск является подфункцией CMS, может возникнуть соблазн думать, что IR —
это часть управления контентом, хотя гораздо более верно обратное. Таким
образом, нереалистично предполагать, что каждая платформа CMS будет также
Поиск может быть очень расплывчатым и сложным в реализации. Редакторы и
контент-менеджеры часто имеют определенные вещи, которые они хотят
видеть доступными, и это усугубляется «эффектом Google», который
постулирует, что все, что делает Google, просто увеличивает наши ожидания
наличия этой функции в других контекстах. Google предлагает проверку
орфографии, так что это, должно быть, простая функция поиска, верно? Google
создает похожий контент, так почему же мы не можем?
20 «Рейтинг цитируемости PageRank: наведение порядка в сети».29 января 1998 г. Интересное

примечание: оригинальный патент на это изобретение фактически принадлежал самому
Стэнфорду. Видеть«Метод ранжирования узлов в связанном База данных," 4 сентября 2001 г.
Запрошенные функции поиска контента могут включать в себя любое из следующего:
Полнотекстовое индексирование
Возвращает результаты для несмежных терминов (например, контент,
включающий фразу «рыбалка в озере», будет соответствовать запросу
«рыбалка в озере»).
Проверка орфографии и нечеткое сопоставление запросов
Понимайте поисковые запросы, которые почти совпадают, и учитывайте их.
Стемминг
Спрягайте глаголы и нормализуйте суффиксы (например, поиск по слову
«плавание» также возвращает результаты по словам «плавать» и «плавал»).
Гео-идет поиск
Поиск местоположений на основе географических координат — либо по
расстоянию от точки, либо по местоположениям, содержащимся в
«ограничивающей рамке».
Фонетическое или звуковое соответствие
Подсчитайте, как может звучать слово, и найдите термины, которые звучат одинаково.
Изоляция репозитория
Ищите только в определенном разделе географии контента.
Синонимы иавторитетные файлы
Укажите, что два термина похожи и должны оцениваться одинаково.
Булевы операторы
Разрешите пользователям добавлять в свои запросы логику И, ИЛИ и НЕ.
Смещение
Влияйте на результаты поиска, увеличивая оценку контента, связанного с
определенным поисковым запросом, и, возможно, позволяйте редакторам
или администраторам изменять настройки предвзятости через интерфейс.
Разделение результатов
Разрешить визуальное разделение конкретного контента вверху результатов.
Поиск связанного контента
Предлагайте контент, связанный с контентом, который ищет пользователь
(«покажите мне больше подобного»).
Упреждающий ввод или интеллектуальный поиск
Попытайтесь ввести поисковый запрос пользователя в поле поиска, пока пользователь
вводит его.
Огранка илифильтрация
Позвольте пользователям уточнять свой поиск до конкретных значений
параметров (это представляет собой сочетание парадигм параметрического
и контентного поиска).
Поиск контента |2 3 1
Поисковая аналитика и отчеты
Отслеживайте условия поиска, количество результатов и количество кликов на страницах
результатов.
Стоп-слова
Удалите общие слова из индексированного контента.
Некоторые из них могут показаться странными или эзотерическими, но это
просто потому, что большинство пользователей не осознают, что они
реализованы в поисковых системах без предварительного уведомления или
очевидности. Эти технологии достигли такого уровня, что стали неотъемлемой
частью наших представлений о том, как работает поиск.
Теперь рассмотрим незадачливых поставщиков CMS, которым приходится
внедрять и дублировать эти функции в своих системах «из коробки».
Существуют коммерческие поисковые системы, которые конкурируют и
превосходят по сложности многие системы управления контентом. Средний
поставщик CMS никогда не сможет конкурировать, особенно если учесть, что
поиск не является основной функцией их продукта.
По этой причине поиск, вероятно, является функцией, чаще всего реализуемой
вне самой CMS. В крупных реализациях CMS службы поиска обычно
предоставляются какой-либо другой платформой, а не встроены в саму CMS.
Это усугубило положение поставщиков CMS — поскольку многие клиенты
ищут другие места для поиска, у поставщиков еще меньше стимулов тратить
много времени на работу над этим.
Это еще больше усугубляется сложностью оценки эффективности поиска.
Когда мы видим страницу с результатами поиска, как часто мы тратим время
на оценку того, точны ли они или нет ли результаты в наиболее правильном
порядке? По замыслу этот тип поиска является нечетким и неточным, поэтому
мы, скорее всего, просто примем результаты по умолчанию как оптимальные,
поскольку предполагаем, что поставщик знает больше, чем мы. Поставщики
часто просто позволяют (или даже поощряют) пользователей продолжать так
думать.
В результате поиск становится функцией, в которой поставщики CMS просто
стремятся «поставить галочку». Обычно они реализуют поиск поверхностно,
просто чтобы сказать, что он есть в их продуктах. Они надеются, что их
реализации хватит для 90% клиентов (что часто бывает правдой), и
предполагают, что те, у кого более продвинутые потребности, будут
использовать другой продукт для поиска.
Наконец, поймите, что базовая технология поиска — это лишь часть процесса
поиска пользователя. Огромная часть ценности поиска определяется
пользовательским интерфейсом. Как отображаются результаты? Как работает
прогнозирующий поиск? Насколько хорошо пользователи могут уточнить свои
запросы? По сути, это проблемы пользовательского опыта, которые поисковая
система не может решить и которые весьма специфичны для реализации. Для
поставщика CMS всегда немного опасно добавлять функциональность
клиентского интерфейса, поскольку существует вполне реальная вероятность
конфликта с дизайном клиента или стандартами UX (вспомните дискуссию о
«внедрении в браузер» изГлава 9).

Какую поддержку может предложить CMS в таких ситуациях? Наиболее
важным является понятный API, который позволяет разработчикам настраивать
функции поиска по желанию редакторов и контент-менеджеров и в
соответствии с потребностями пользователей. Альтернативно, CMS должна
предоставлять перехватчики и события, к которым разработчик может
подключить внешнюю систему, чтобы обеспечить возможность поиска с
помощью отдельного продукта.
Лусене
Большинство систем, реализующих расширенный
полнотекстовый поиск, используют технологию с открытым
исходным кодом под названием Lucene.21 Lucene — это
система поискового индексирования и поиска, выпущенная в
1999 году. Это де-факто отраслевой стандарт текстового
поиска, который широко используется в Интернете в целом.
Lucene окружен двумя основными поисковыми серверами с
открытым исходным кодом: Solr и Elasticsearch. Эти системы
предоставляют широкий спектр функциональных
возможностей, и поставщики очень часто либо используют их
скрытно, либо предлагают инструменты для прямой
интеграции с ними.
Пользователь и РазработчикЭкосистема
Это может показаться странной «особенностью», которой можно завершить эту
главу, но сообщество поддержки и разработчиков, окружающее платформу
CMS, возможно, является ее самой важной особенностью. Просто мало что
заменит поддержку, обсуждение и вклад процветающего сообщества
пользователей и разработчиков, которые помогают другим.
Продавцы могут помочь или помешать этим усилиям. Большинство
поставщиков предоставляют своим пользователям официальный адрес
сообщества через форумы и платформы совместного использования кода. Если
поставщика нет, он может возникнуть органически, хотя о его существовании
может быть неизвестно за пределами небольшой группы.
Продавцы могут и дальше поддерживать сообщество, участвуя в нем.
Несколько форумов сообщества CMS частично патрулируются разработчиками
продуктов, что обеспечивает механизм поддержки по обратным каналам и, что,
возможно, более важно, дает этим разработчикам место в первом ряду для
наблюдения за борьбой своих пользователей и способами, которыми продукт
должен разрабатываться для удовлетворения их потребностей.
Разработчики, предоставляющие код сообществу, — это огромное
преимущество, которое можно измерить в чистом бюджете. Часто вы не первая
организация, пытающаяся решить конкретную проблему, и проверенный,
проверенный код для вашей конкретной ситуации может уже существовать.
21 Да, имя уникальное. Дуг Каттинг, первоначальный разработчик, черпал вдохновение из второго
имени своей жены, которое было именем ее бабушки по материнской линии. Похоже, что в
последний раз «Lucene» было хотя бы отдаленно популярно как женское имя в Соединенных
Штатах в 1930-х годах.
Экосистема пользователей и разработчиков |2 3 3

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

становится домом для многих импровизированных сообществ
поддержки программного обеспечения, основанных на
использовании тегов.
Например, на момент написания этой статьи различные
варианты тега «drupal» были присвоены более чем 30 000
вопросам на Stack Overflow. Мой собственный опыт показал,
что разработчики, имеющие опыт работы с конкретной
системой или библиотекой, будут отслеживать
соответствующие теги и выбирать вопросы, на которые нужно
предоставить поддержку и ответы.
В будущем поставщики CMS могут обнаружить, что их
официальные сообщества и форумы поддержки все чаще
обходят вниманием специальные, спонтанные группы
разработчиков, которые собираются вместе на таких сайтах,
как Stack Overflow.
ГЛАВА11
API иРасширяемость
Настройка CMS осуществляется на двух уровнях. Существует шаблонизация,

которая вполне ожидаема почти в каждой реализации и обрабатывается с
помощью комбинации HTML и кода шаблонов. Кроме того, есть более
глубокие настройки, которые можно изменить или добавить в работу самой
CMS. Эти настройки обычно выполняются на родном языке CMS (PHP, C#,
Java и т. д.).
Редакторы могут предположить, что расширяемость CMS касается только
разработчиков, но на самом деле она оказывает существенное влияние на всю
команду. Когда разработчики отвечают на запрос редактора словами: «Мы не
можем этого сделать», это часто происходит потому, что расширяемость CMS в
чем-то их подвела, и у них просто нет возможности выполнить то, что хочет
сделать редактор.
Некоторые системы имеют элегантно разработанные методы доступа к
контенту и безграничные способы манипулирования им, в то время как другие
неуклюжи и разочаровывают и, похоже, работают скорее против
разработчиков, чем вместе с ними. Некоторые системы изначально
разрабатывались как платформы программирования, которые включают в себя
код, разработанный интегратором, и взаимодействуют с ним. Другие системы в
некоторой степени закрыты от этого либо намеренно из-за ограничений
архитектуры (например, многоарендный SaaS), либо из-за конструкции
продукта.
В конечном счете, расширяемость CMS можно связать с основным вопросом:
ожидал ли поставщик, что кто-нибудь ее расширит? Я работал с поставщиками
CMS, которые были удивлены, узнав, что мы пытаемся сделать с их системами.
Некоторые из них просто никогда не ожидали, что разработчик может
попытаться работать с системой определенным образом, либо из-за наивности,
либо из-за ориентации на другой вариант использования. Другие системы
представляют собой не более чем сырые API, на основе которых, как
ожидается, интеграторы будут реализовывать свои собственные интерфейсы и
функциональные возможности.
235
В этом обсуждении я широко использую термин «API».
Технически API — это точки подключения, доступные из кода.
В более широком смысле все точки расширения — код,
события, веб-сервисы и т. д. — часто вместе называются API
системы. Функциональность этой главы можно было бы точнее
описать как «модель расширяемости» CMS.
The КодAPI
Интерфейс прикладного программирования (API), лежащий в основе любого
программного продукта, представляет собой набор инструментов
программирования, которые разработчику предоставляются для работы с
контентом из кода.
Например, вот код от Episerver для получения заголовка страницы контента на
C#:
var repo = ServiceLocator.Current.GetInstance<IContentRepositoryService>();
var myPage = repo.Get<TextPage>(new ContentReference(123));
var title = myPage.Property["PageTitle"].Value;
Концепции, представленные в этом коде — существование репозитория как
внедренного сервиса, объект контента, доступный как строго типизированный
объект TextPage, идентификация контента по числовому идентификатору,
свойства контента, представленные словарем с ключами, — представляют
собой API, доступный для этой конкретной CMS. Базовым языком является C#,
но API — это словарь и инструменты, предоставляемые C# для работы с
Episerver.
Для сравнения, вот тот же общий код в Concrete5 (PHP):
$my_page = Страница::getByID(123);
$title = $page->getAttribute('PageTitle');
В Магнолии (Java, с использованием JCR):
Сеанс сеанса = MgnlContext.getJCRSession("myWorkspace"); Узел
myPage = session.getNodeByIdentifier(123);
String title = myPage.getProperty("pageTitle").getString();
И в Plone (Python):
из API импорта Plon
my_page = api.content.get(UID=123)
title = my_page.page_title
Специфика явно разная, но общая цель и результат одни и те же. API — это
набор инструментов, доступных разработчикам из кода. (Стоит отметить, что
приведенные выше примеры кода взяты из API, которые обычно считаются
достаточно компетентными. Менее функциональные API будут иметь менее
элегантные примеры.)
236 | Глава 11: API и расширяемость
Недавно я учил свою 14-летнюю дочь водить машину. 1 В ходе этого процесса я
выявил аспект вождения, который раньше никогда не замечал: нужно быть
предсказуемым. Цель водителя — делать то, чего от вас ожидают другие. Во
многом из того, что происходит в дороге, другие люди делают предположения
о том, что вы планируете делать. Быть непредсказуемым — значит быть
небезопасным.
То же самое относится и к API. Ключевыми факторами являются
последовательность и предсказуемость. API должен иметь согласованный
интерфейс, который может предсказать разработчик. На самом деле это было
названо принципом наименьшего удивления.2 Способность разработчика
предсказать, как API может работать и какую функциональность он может
предложить, имеет огромное преимущество при расширении системы.
Динамика общей разработки программного обеспечения — это тема,
выходящая далеко за рамки этой книги, но качество API любого программного
обеспечения зависит от того, как программное обеспечение создавалось с
течением времени. Программное обеспечение часто создается бессистемно, а
API развивается по мере необходимости — менеджер по продукту или
торговый представитель в панике говорит: «Нам нужна функция X, чтобы
продавать продукт!» и команда разработчиков торопливо пишет функцию X,
попутно меняя API любым возможным способом.
Более разумная команда разработчиков сначала планирует и пишет API, чтобы
иметь возможность предвидеть потребности групп по продукту и продажам, а
новые функции вписываются в более широкую логическую модель и
философию того, как CMS моделирует и управляет своим контентом. Это
программное обеспечение имеет тенденцию писаться заранее, начиная с API, а
не реактивно, начиная с «новости дня» внутрь. API управляет функциями, а не
наоборот.
Проверка в реальных условиях

Понятно, что это идеализированное описание процесса. Дело в
том, что ни один программный продукт сколько-нибудь
значительного размера не разрабатывается единообразно и не
соответствует одним и тем же стандартам качества.
Над разными частями системы работают разные команды,
приобретаются другие компании и интегрируется их код, а
технологии развиваются и делают некоторые части
программного обеспечения устаревшими или
неоптимальными. В результате даже в самом элегантно
спроектированном программном обеспечении есть темные,
мутные углы, которые команда разработчиков намеревается в
какой-то момент очистить.
1 Да, в Южной Дакоте вы можете водить машину в 14. Это откровение часто встречают с ужасом люди
в более строгих частях страны.
2 Кроме того, эксперт по юзабилити Дон Норман упомянул «концептуальную модель» чего-либо,
которая представляет собой мысленное понимание того, как пользователь ожидает, что это будет
работать. Норман говорил о потребительских продуктах, но то же самое справедливо и в отношении
API: система должна стремиться работать так, как ожидает от нее большинство разработчиков.
API кода | 237

Оценка API может быть сложной. Иногда API, который кажется
компетентным, имеет скрытую глубоко внутри особенность, с которой команда
разработчиков сталкивается в 3 часа ночи, пытаясь внести изменения, и это
останавливает их как вкопанные.
Чтобы смягчить это, полезно, когда CMS принимает известную среду
разработки и использует ее инструменты, соглашения и философию, поскольку
это дает разработчикам некоторую степень знакомства с ней с самого начала.
Например:
• Многие системы .NET полностью основаны на платформе ASP.NET MVC.

Эти системы в первую очередь представляют собой приложения MVC, и за
ними просто стоит CMS. Любой .NET-разработчик, имеющий некоторое
представление о стилях и соглашениях MVC, сразу же будет чувствовать
себя как дома.
• Многие системы PHP используют фреймворк Symfony MVC для решения
основных задач маршрутизации и управления данными, что делает
расширение этих систем довольно простым для существующих
разработчиков Symfony.
При попытке определить компетентность базового API единственным

разумным методом является проверка уровня кода для ваших разработчиков
технической командой поставщика. Вам потребуются ответы как минимум на
следующие вопросы:
• Как вы извлекаете контент из кода? Если у вас есть контент в коде, как вы
можете манипулировать им и сохранить новую версию?
• Насколько детальным может быть извлечение на уровне кода? Сколькими
способами вы можете искать контент? Можете ли вы получить список
контента на основе X различных критериев и упорядочить его по одному
или нескольким из этих критериев?
• Как вы можете создавать новый контент из кода?
• Как реализовать новую функциональность, которая может быть даже не
связана с контентом? Как пользовательский код вашей организации может
сосуществовать с кодом CMS?
• Какие события, перехватчики или триггеры уровня кода доступны?
Например, когда контент публикуется, может ли ваш код обнаружить это
событие и внедрить новую логику в процесс?
• Какая существует возможность запускать задания командной строки или
запланированные задания из интерфейса CMS?
• Как можно настроить административный интерфейс для управления
пользовательскими функциями?
• Доступен ли API только из кода, локального для установки CMS, или
доступны веб-службы или другие удаленные API?
API, как известно, своеобразны. Опять же, не существует Великой
унифицированной теории управления контентом, поэтому нет и Великого
унифицированного API.3
Кроме того, качество API часто не имеет никакого отношения к качеству
продукта с точки зрения пользователя или редактора. Некоторые очень
привлекательные на вид системы имеют ужасно сложные API, которые
постоянно расстраивают разработчиков, в то время как другие системы,
которые кажутся упрощенными, обладают невероятной мощью и
элегантностью кода. (По иронии судьбы, возможно, именно поэтому они
выглядят упрощенно из коробки — их настолько легко настроить, что
большинство клиентов делают это значительно.)
Опять же, единственный способ убедиться и подтвердить компетентность API
CMS — это позволить вашим разработчикам фактически работать с ним.
Модели событий
Одной из проблем любого пакетного программного обеспечения является
вставка в него логики, при которой собственный код будет выполняться среди
основного кода системы. Одним из решений было бы покопаться в исходном
коде и просто вставить новый код в те места, где вы хотите, чтобы он
выполнялся. Однако очевидно, что это открывает многочисленные проблемы с
удобством сопровождения и стабильностью, не говоря уже о том, что исходный
код просто не поставляется со многими коммерческими системами.
Более управляемый способ добиться этого результата — использовать так
называемую модель событий. Программирование на основе событий не
является специфичным для CMS; это обычная архитектура программирования.
Когда код выполняется, он может вызывать события. Событие — это
объявление о том, что что-то произошло внутри исполняющего программного
обеспечения. Внешний код может «подписаться» на эти события, по сути
говоря: «Когда произойдет событие X, выполните этот блок кода». Этот код
обычно известен как обработчик событий.
Обработчикам событий не обязательно знать, где именно в коде CMS
происходят события. Разработчикам просто нужно знать, какие события
доступны и какую информацию предоставляют эти события при их
возникновении. Любой код внутри CMS может вызвать событие, и пока
обработчик событий подписан, он будет выполняться. На событие может быть
подписано более одного обработчика событий, и обычно они выполняются в
том порядке, в котором на них были подписаны.
События обычно предоставляют обработчику информацию о том, что
произошло. Эта информация может быть просто уведомлением, чтобы можно
было написать код для выполнения действия.
3 Хотя попытки были. Службы взаимодействия управления контентом (CMIS) и API репозитория
контента для Java (JCR) представляют собой попытки унифицировать обработку контента на уровне
API. Они имели разную степень успеха и имели ограниченное применение на рынке, в основном в
более крупных корпоративных системах.
API кода | 239

когда что-то происходит. Другие события могут предоставлять информацию,
которую обработчик событий может изменить. В этих случаях событие дает
подписавшемуся коду возможность изменить способ функционирования
системы путем подключения к коду и изменения значений по мере
необходимости. По сути, код говорит: «Я собираюсь выполнить задачу X.
Прежде чем я это сделаю, не хотели бы вы дать мне какой-нибудь совет?»
Большинство систем предоставляют некоторую модель событий, на которую
может подписаться ваш собственный код. Не существует стандартного списка
событий, которые должна генерировать CMS, но большинство событий будут
основаны на изменении состояния контента в течение его жизненного цикла.
От создания до окончательного удаления объект контента может вызвать
десятки событий.
Некоторые примеры (упомянутые события вымышлены, но распространены):
• Веб-сайт активно кэшируется сетью доставки контента (CDN), чтобы

обеспечить более быструю доставку контента по всему миру. Всякий раз,
когда публикуется новый контент, CDN необходимо уведомить об URL-
адресе затронутого контента, чтобы можно было очистить его кеш и
получить обновленный контент. Например, обработчик событий может
подписаться на событие «После публикации контента» и выполнить вызов
API CDN с URL-адресом опубликованного контента.
• Главный редактор недоволен тем, что редакторы используют аббревиатуры
вместо полных имен. Обработчик событий может подписаться на событие
«Перед сохранением контента» и получить контент, который должен быть
сохранен в репозитории. Обработчик событий может сканировать текст на
наличие сокращений и заменять их (например, изменяя текстовую строку
«ФБР» на «Федеральное бюро расследований»). Вместо этого
исправленный текст будет сохранен в репозитории.
• Цены на мероприятия объявляются не ранее, чем за 30 дней до
мероприятия. Вместо того, чтобы создавать и применять эту логику в
десятках мест шаблонов (и доверять разработчикам шаблонов, чтобы они
всегда ее использовали), разработчик подписывается на событие
«Отображение атрибута». Если запрошенным атрибутом является «Цена»,
а до даты начала осталось более 30 дней, возвращается значение атрибута
«Недоступно».
Обычно два события «закрывают» код. Событие «до» будет вызвано перед
кодом, часто предоставляя обработчикам информацию, которую можно
изменить, чтобы повлиять на то, как будет выполняться последующий код. Код
выполнится, затем возникнет событие «после». Та же самая информация
обычно будет предоставлена после события, но ее изменение не будет иметь
никакого эффекта.4
4 В некоторых системах используется соглашение «ing/ed». События «до» и «редактирование» после
событий (например, «Публикация контента» и «Контент опубликован»).

Если события кажутся подозрительно похожими на рабочий процесс, это не
совсем так. Различия незначительны:
• Редакторы не вызывают события напрямую, как это происходит в рабочем

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

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

же процессе, что и сама CMS, и блокируют выполнение
вызывающего кода до тех пор, пока он не завершится, плохо
реализованный обработчик событий может вывести из строя
всю систему. Либо обработчик событий выдает ошибку,
которая полностью завершает выполнение, либо выполнение
занимает так много времени, что система начинает работать
медленно. Реализуйте с осторожностью, особенно при
подписке на частые события, такие как получение значения
атрибута.
В некоторых системах события называются «перехватчиками» (чтобы

представить идею «подключения» к событиям, происходящим в коде CMS); в
других системах их называют «триггерами» или «действиями».
В качестве иллюстрации приведем пример подписки на событие в Episerver (на
C#) для выполнения метода NotifyCDN после публикации контента (первый из
наших предыдущих примеров):
DataFactory.Instance.ContentPublished += NotifyCDN;
(Обратите внимание, что это стандартный синтаксис программирования на
основе событий C#, а не что-то специфическое для Episerver.) В этом случае
обработчику событий (метод NotifyCDN) будет предоставлена ссылка на
только что опубликованный контент, чтобы он мог найдите его URL-адрес и
отправьте запрос на аннулирование в CDN.
Sitecore использует файлы конфигурации XML для указания обработчиков событий:
<имя события="элемент:опубликовано">
<handler type="EventHandlers, MySiteAssembly" метод="NotifyCDN"/>
</событие>
API кода | 241
WordPress позволяет разработчикам указывать события, добавляя «действия» (в PHP):
add_action('publish_post', 'notify_CDN');
Программирование на основе событий вовсе не является специфичным для
CMS, а, скорее, является для разработчиков важным способом расширения
функциональности любой системы. Модель событий обеспечивает понятный и
удобный способ внедрения пользовательского кода в закрытую систему.
Перспектива: CMS как цифровой хаб

Аллан Траен
Когда я впервые присоединился к миру управления
контентом, я ожидал, что он будет довольно скучным. Я
имею в виду, что CMS — это, по сути, база данных, куда
вы помещаете контент, редактируете его, извлекаете и
представляете. Большое дело, правда?!
Но я быстро понял, что по мере того, как наш мир
становится все более онлайн, роль WCMS вырастает из
«просто управления контентом» в естественно
развивающуюся платформу, вокруг которой иногда
вращается весь бизнес.
Если раньше веб-сайты представляли собой статичные брошюры, то теперь они
становятся платформой для маркетинга, продаж и обслуживания клиентов. Для
этого WCMS должна быть подключена ко всем соответствующим системам:
CRM, автоматизации маркетинга, планированию ресурсов предприятия,
внутренним базам данных и системам, социальным сетям, аналитике, бизнес-
аналитике, поисковым системам, электронной коммерции и т. д. скоро.
Модель расширяемости CMS необходима для обеспечения хороших
соединений со всеми другими системами. Конечно, большинство CMS
поставляются с рядом доступных разъемов — либо готовых к использованию,
либо в виде надстроек, — но часто вы обнаружите, что вам не хватает нужных
разъемов именно для той системы, которую вы хотите подключить.
Хорошая платформа API и кода позволит разработчикам расширять CMS и ее
административный интерфейс для подключения во всех необходимых местах к
другим критически важным для бизнеса системам на этапе внедрения.
Представьте, что вы работаете в авиакомпании, которая собирается полностью
заменить свое присутствие в Интернете новой CMS. Помимо регулярной
работы по внедрению, существует множество систем, с которыми вы захотите
интегрироваться:
• Вероятно, у вас уже есть система поиска и бронирования рейсов,

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

функции интеграции с вашими существующими системами могут улучшить
ПлагинАрхитектуры
С API, который предлагает система, тесно связана возможность упаковки и
распространения настроек либо на коммерческой основе, либо через решения с
открытым исходным кодом. Некоторые системы имеют обширные расширения
своих основных функций, доступные через пакеты кода, которые по-разному
называются плагинами, надстройками, расширениями, компонентами или
модулями (мы будем использовать «плагин»).
Таким образом, «архитектура плагинов» представляет собой набор
устоявшихся концепций API, событий и точек подключения, которые
позволяют разработчику создавать некоторые функциональные возможности
для CMS, а затем объединять их в той или иной форме, которая затем может
быть установлена в другой установке системы. эта CMS.
CMS с открытым исходным кодом обычно имеют хорошо развитую
архитектуру подключаемых модулей из-за характера их разработки.
Программное обеспечение с открытым исходным кодом разрабатывается
сообществом разработчиков, а архитектуры подключаемых модулей часто
создаются для обеспечения единообразной интеграции новых функций, когда в
них участвует большая распределенная группа людей. Кроме того, рост
сообществ пользователей систем с открытым исходным кодом приводит к
тому, что множество разных людей пробуют много разных вещей. Огромный
объем реализаций имеет тенденцию приводить к тому, что больше кода
превращается в доступные плагины.
За коммерческим программным обеспечением, напротив, стоит официальная
организация, и предполагается, что эта организация будет обеспечивать
функциональность. Кроме того, лицензионные сборы, естественно, сократят
базу пользователей по сравнению с альтернативами с открытым исходным
кодом, поэтому будет меньше реализаций. Эти реализации будут выполняться
Подключаемые архитектуры |2 4 3
организации, которые в среднем меньше придерживаются философии
открытого исходного кода и больше защищают свой код.
Количество и качество доступных плагинов обычно напрямую связаны с
принятием конкретной платформы. Такие системы, как WordPress и Drupal,
имеют тысячи доступных плагинов, способных удовлетворить практически
любые требования. Действительно, для многих систем наиболее ценным
навыком, которым может обладать разработчик, является глубокое знание того,
какие функциональные возможности доступны через соответствующие
библиотеки плагинов. Большая часть любого внедрения этих систем — это
выбор, настройка и адаптация наиболее подходящих плагинов для выполнения
заявленных требований.
Недостатком плагинов являются проблемы с безопасностью, удобством
сопровождения и согласованностью. Когда плагин внедряется в установку,
третья сторона по существу получает доступ к среде. Интегратор предполагает,
что этот плагин надежен, хорошо протестирован и не создает дыр в
безопасности (непреднамеренно или злонамеренно).
Многие эксплойты безопасности не нацелены на саму CMS, а

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

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

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

Некоторые системы считают свою модель подключаемого модуля основной
частью своей архитектуры и фактически реализуют большую часть своей
базовой функциональности в виде подключаемых модулей, чтобы облегчить
возможность их изменения при необходимости.
Drupal, например, объединяет функции управления пользователями в плагин
(модуль Drupal) под названием «Пользователь». Аналогично, основные
функции контента обрабатываются плагином под названием «Node» (в
описании которого невинно говорится: «Позволяет отправлять контент на сайт
и отображать его на страницах»). Поскольку они разрабатываются как плагины,
взаимодействие между большими разделами кодовой базы происходит
ожидаемым и контролируемым образом, и разработчики, предположительно,
могут выбросить большие разделы предоставленной функциональности и
заменить их своими собственными.
Episerver построил весь свой пользовательский интерфейс администрирования
в виде плагина, чтобы облегчить возможность обновления при необходимости.
Обновление пользовательского интерфейса администратора теперь
представляет собой просто процесс обновления плагина, а не всей базовой
платформы.
Настройка редакционного интерфейса

Часто бывает полезно настроить редакционный интерфейс, чтобы добавить
функциональные возможности, зависящие от реализации. Редакторам могут
потребоваться дополнительные ссылки, кнопки и отчетная информация
непосредственно в интерфейсе, из которого они редактируют контент.
Эти настройки могут быть глобальными для всех редакторов. Например,
зачастую полезно просматривать данные Google Analytics рядом с контентом. В
других случаях редакторы могут иметь возможность настроить интерфейс
только для себя, добавляя гаджеты или виджеты, чтобы предоставлять
информацию, которую они считают полезной, а другие — нет.
Настройка редакционного интерфейса |2 4 5

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

Редакторы форматированного текста также могут нуждаться в настройке и
настройке. Большинство систем реализуют один из двух распространенных
редакторов форматированного текста с открытым исходным кодом на основе
JavaScript: TinyMCE или CKEditor. Меньшее количество других использует
коммерческие редакторы, такие как EditLive! от Ephox или RadEditor от Telerik,
и еще меньшее число реализует свои собственные редакторы
форматированного текста.
Вот некоторые распространенные настройки:
• Включение или отключение кнопок интерфейса

• Настройка информации о стиле, например списка классов или блочных
элементов, которые можно применить.
• Конфигурация процессов проверки или «очистки» HTML, которые
обеспечивают использование допустимых тегов HTML и удаляют
недопустимую разметку.
• Включение или отключение доступа к исходному HTML-коду
• Настройка различных всплывающих интерфейсов, таких как интерфейс
вставки изображений или таблиц.
• Добавление пользовательских плагинов, включая кнопки, выполняющие
произвольный клиентский код (например, функцию JavaScript)
• Стилизация содержимого редактора форматированного текста в соответствии с конечным
результатом сайта.
И TinyMCE, и CKEditor имеют хорошо документированные архитектуры

плагинов и расширяемости. CMS, использующая один из этих редакторов,
должна обеспечивать возможность загрузки необходимых файлов и внедрения
кода JavaScript, необходимого для загрузки плагина при запуске.
Абстракция репозитория
Предполагается, что большая часть содержимого установки CMS будет
храниться в самом репозитории CMS. Однако это не обязательно так.
Некоторые системы позволяют абстрагировать части репозитория. Код для
фактического сбора данных для объектов контента можно заменять и
делегировать другому коду и другим источникам. Пользовательский код может
позволить некоторым данным поступать из других источников хранения, а
также представлять их и манипулировать ими точно так же, как контент,
который фактически находится в

хранилище. Это может произойти только для определенных объектов контента
или мест в географическом регионе.
Например:
• Организация хранит свои выпуски новостей в Microsoft SharePoint.

Команда поддержки также хочет, чтобы эти выпуски отображались на веб-
сайте. Репозиторий CMS может быть абстрактным, так что географический
раздел (например, дочерние элементы страницы новостей) будет
фактически получать контент из SharePoint в реальном времени,
представляя эту информацию так, как если бы выпуски новостей
действительно находились в самой CMS. Посетители (и, возможно, даже
редакторы) могут никогда не узнать, что этот контент на самом деле не
хранится в репозитории.
• Технические писатели хранят образцы кода продуктов в виде файлов
Markdown в Git. Репозиторий CMS может быть абстрактным для
подключения к Git в режиме реального времени и перечисления
содержащихся в нем файлов в качестве дочерних объектов содержимого
страницы примеров кода.
Пользователи операционной системы Unix могут распознать в этом концепцию

«монтирования файловой системы». В Unix совершенно отдельная файловая
система (скажем, Система B) может быть сопоставлена с тем, что выглядит как
простой каталог в Системе A. Пользователи, перемещающиеся по Системе A,
могут войти в определенный каталог и — без их ведома — фактически
оказаться там. просмотр файловой системы на совершенно другой машине.
Абстракция репозитория — это, по сути, одно и то же: раздел репозитория
может «монтировать» какую-то другую систему для предоставления данных.
Обмен данными между CMS и исходной системой происходит в фоновом
режиме. Некоторые системы могут даже записывать данные обратно во
внешний источник, поэтому редактор может изменить объект в CMS и не
осознавать, что на самом деле он меняет данные в совершенно отдельной
системе, совершенно где-то еще.
Очевидно, что это расширенная функция, и необходимо принять решение о
том, когда это более уместно, чем простой импорт контента в репозиторий и
его обновление при его изменении. В зависимости от внешнего источника
данных при доступе в режиме реального времени возникают проблемы с
производительностью, задержкой в сети, безопасностью и стабильностью.
Однако в тех случаях, когда доступ к внешним данным можно получить за
пределами CMS (например, путем выполнения прямого запроса к базе данных
с использованием SQL), абстрагирование репозитория для представления этих
данных в виде контента может повысить согласованность и упростить создание
шаблонов.
ПодключаемыйАутентификация
Одним из недостатков внедрения нового программного обеспечения в
организацию является наличие нового набора учетных данных, которым нужно
управлять и который пользователи должны помнить. Один из самых простых
способов для пользователей почувствовать, что система является
неотъемлемой частью их организации, — это разрешить им использовать те же
учетные данные, которые они используют для других систем. Добавляем еще
один набор креативов
Подключаемая аутентификация |2 4 7
Dentials вызывает утомление паролей, что обычно приводит к появлению
стикеров с паролями, прикрепленных к боковым сторонам мониторов.
Многие CMS позволяют либо интегрировать свои системы с
распространенными методами аутентификации, либо полностью заменить их
на пользовательскую систему. Интеграция с Active Directory от Microsoft
является обычным явлением, как и более общая интеграция с LDAP.
Некоторые системы имеют интеграцию OAuth, OpenID или Facebook Connect,
что позволяет пользователям входить в систему путем аутентификации с
помощью своих учетных записей Google или Facebook.
Если организация использует менее известную или даже специальную систему
аутентификации, иногда можно разработать код и предоставить его CMS для
выполнения задач аутентификации. В этих случаях очевидно, что
разработчики-реализаторы обязаны предоставить хорошо протестированный
код, поскольку безопасность CMS будет настолько безопасна, насколько это
позволяет этот код. CMS будет взаимодействовать только с этим
пользовательским кодом и будет предполагать, что аутентификация
пользователей выполняется безопасным и строгим способом.
Обратите внимание, что подключаемая аутентификация и общие учетные
данные не обязательно означают единый вход. Чтобы обеспечить единый вход,
ваши редакторы входят в одну систему и проходят беспрепятственную
аутентификацию во многих других системах, включая, надеюсь, вашу CMS.
Даже если вы подключите свою CMS к поставщику Active Directory,
редакторам все равно придется вводить свои учетные данные, но это будут те
же учетные данные, которые они используют везде, что само по себе полезно.
Веб-сервисы
Многие системы предоставляют интерфейс веб-службы, позволяющий
удаленно взаимодействовать с CMS через HTTP. Системы различаются по (1)
конкретному используемому протоколу веб-сервиса и
(2) допустимая глубина взаимодействия.
SOAP (простой протокол доступа к объектам) на протяжении многих лет был
стандартным протоколом веб-сервисов, но эту позицию узурпировал REST
(REpresentational State Transfer).5 Аналогично, XML уже давно является
доминирующим форматом сериализации, но его вытесняет JSON. Большинство
систем предлагают некоторую комбинацию этих двух переменных (XML через
SOAP или JSON через REST или иногда наоборот).
Некоторые веб-сервисы доступны только для чтения, но другие системы
стремятся обеспечить полный доступ к своим API через веб-сервисы.
Некоторые системы идут еще дальше и запускают собственные
пользовательские интерфейсы из своего веб-сервиса. Уровни абстракции во
многих языках программирования и средах продвинулись до такой степени,
что доступ к веб-сервису можно получить через общий API и даже заменить
его.
5 Многие разработчики не называют REST «протоколом», а скорее считают его соглашением или философией.

Если API веб-службы системы не соответствует требованиям,
пользовательские веб-службы можно реализовать довольно легко. Во многих
случаях разница между обычно шаблонным объектом контента и запросом
службы REST невелика. Языки шаблонов, генерирующие HTML, обычно могут
с такой же легкостью генерировать XML или JSON, а создание
пользовательских конечных точек веб-служб для конкретных ситуаций
является довольно распространенным явлением. Некоторые реализации могут
даже доставлять версии любого контента в формате XML или JSON, просто
добавляя назначенный аргумент к строке запроса (например, ?format=json).
RSS также хорошо подходит в качестве простого API для доставки контента и
имеет определенный уровень стандартизации. RSS-каналы можно расширять с
помощью пользовательских тегов с пространством имен, чтобы предоставлять
больше контента, чем традиционные каналы блогов, и RSS так же хорошо
подходит для доставки агрегатов или отдельных элементов контента.
Запланированные задания или задания по требованию

Во многих ситуациях редакторам и администраторам CMS просто необходимо
выполнить произвольный код либо по требованию, либо по расписанию и без
присмотра. Этот код обычно не требует пользовательского ввода и не имеет
компонента визуального интерфейса. Обычно он предназначен для пакетного
манипулирования контентом. Многие системы предлагают некоторую
структуру для реализации этого кода, обычно называемую «заданием».
Например:
• Во многих системах есть задание по проверке гиперссылок по расписанию.

Задание получит весь контент, проверит его на наличие внешних URL-
адресов, а затем отправит запрос на каждый из этих URL-адресов, чтобы
убедиться, что они по-прежнему действительны. URL-адреса, которые
больше не доступны, могут быть помечены для проверки, добавлены в
отчет или отправлены по электронной почте администратору.
• Главный редактор может захотеть ввести строгие редакционные правила,
чтобы обеспечить соблюдение политики управления. Запланированное
задание может запускаться каждую ночь, находить весь контент,
измененный с момента последнего выполнения, и обрабатывать его, чтобы
гарантировать соблюдение политик управления: изображения АЛТтеги,
использование компаниипосле названия следует символ товарного знака, за
точкой следует только один пробел и т. д.
• Отдел информационной безопасности может потребовать, чтобы
определенный контент сайта записывался в плоский файл один раз в месяц
и вводился в систему управления корпоративным контентом для проверки
регулирующим органом.
• Название продукта может измениться, и все ссылки на веб-сайты также
должны измениться. Можно разработать задание на просмотр десятков
тысяч объектов контента и изменение ссылок со старого названия. Это
задание можно установить, выполнить, а затем удалить после
подтверждения результатов.
Запланированные задания или задания по требованию |

249
• Во время миграции контента (см.Глава 13), весь сценарий миграции можно
реализовать как задание по требованию. Разработчик может выполнить
задание, просмотреть результаты, изменить сценарий, а затем выполнить
его снова.
API как связь со сдвигом во времени

API системы — это «отпечаток пальца» команды разработчиков поставщика.
API — это путь, который поставщик оставляет разработчикам, использующим
его продукт, для решения сложных проблем и уникальных настроек во время
реализации.
Странным образом разработчики выстраивают своего рода сдвинутые во
времени отношения с первоначальной командой поставщиков через API.
Чистый, последовательный и хорошо документированный API производит
хорошее впечатление о команде поставщика. Разработчики-реализаторы учатся
доверять им и обретают уверенность в том, что запрошенные настройки
действительно могут быть достигнуты. Когда пользователь спрашивает, можно
ли что-то сделать, ответ звучит так: «Я почти уверен, что способ есть».
Плохой API — полная противоположность. Непоследовательные и неуклюжие
API порождают недоверие среди разработчиков. В некоторых случаях
создается впечатление, что API – и, по доверенности, сам поставщик –
действительно работают против них. Это похоже на члена команды, который
не берет на себя ответственность и тянет вниз остальную команду. Всякий раз,
когда запрашивают настройку, ответ звучит так: «Я проверю, но сомневаюсь в
этом».
Таким образом, компетентность системного API является важнейшей
характеристикой, которая оказывает огромное влияние на успех или неудачу
реализации (особенно той, которая требует серьезной настройки), мало чем
отличаясь от человека-члена команды.
Оценивая CMS, позвольте вашим разработчикам «интервьюировать» API,
чтобы узнать, хотят ли они сделать его членом своей команды. Потребуйте от
своих разработчиков пошаговое руководство на уровне кода и оцените их
чувства по поводу увиденного. Если эти отношения потерпят неудачу,
остальная часть проекта может пойти вместе с ней.
ЧАСТЬ III
Реализации
ГЛАВА12
Реализация CMS
У меня две дочери-подростка. Они одержимы своими будущими свадьбами.

Они оба планировали идеальный день десятки раз. Когда они спрашивают,
почему меня это не волнует так же, как их, я всегда отвечаю одинаково: «Меня
меньше волнует день вашей свадьбы, чем 50 лет, которые пройдут после него».
В процессе создания веб-сайта с управляемым контентом организации часто
одержимы поиском подходящей CMS для своих нужд. Они поражены
демонстрациями продаж и мечтают о том, что они будут делать, когда это
будет реализовано. Воодушевленные обнаружением того, что они считают
безупречной технологией, они бросаются к реализации, но затем не понимают,
почему реальность того, с чем они просыпаются каждый день, не соответствует
их мечтам.
Определение и приобретение CMS — это только первая часть создания веб-
сайта с управляемым контентом. Это все равно, что часами ходить в магазин
строительных материалов, искать и покупать все необходимое для постройки
дома, а затем доставлять эти вещи на пустую стоянку. Неважно, сколько у вас
материалов и качественные они или нет — кто-то все равно должен из них
построить дом.1
Что больше влияет на успех или провал веб-сайта: качество CMS или качество
реализации? Это горячо обсуждаемый вопрос. Может ли фантастическая CMS
быть испорчена плохой реализацией? И может ли блестящая реализация спасти
объективно плохую CMS?
Ответ на оба вопроса – да. Самая лучшая CMS в мире может стать совершенно
бесполезной из-за плохой реализации, а можно сделать CMS ниже среднего.
1 Технический рецензент заметил: «Не переусердствуя с этой метафорой, вы могли бы

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

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

Старая пословица управления проектами гласит: если вы хотите узнать,
сколько времени займет проект: «Сложите время, которое, по вашему мнению,
потребуется для выполнения всех задач, а затем удвойте его». Хотя это явно
шутка, зачастую она не далека от истины.
Количество времени, необходимое для внедрения системы управления
контентом, всегда превышает сумму ее частей. Планирование всех
особенностей реализации перед началом работы — непростой процесс. В ходе
проекта будут возникать препятствия, которые значительно удлинят
необходимое время: изменения, скрытые требования, недопонимания,
текучесть кадров, ошибки и переделки.
Мы склонны недооценивать время, необходимое для концентрации на
деятельности, которую мы считаем «строительством принципов», которая по
своей природе ориентирована на развитие. Мы просматриваем
функциональность, необходимую для завершения сборки, суммируем время
реализации и думаем, что это все, что нужно сделать.
Попутно мы забываем о вещах, выходящих за рамки основного пути. Вещи как:
• Настройка среды, например среды разработки, тестирования и интеграции,

не говоря уже о репозиториях системы контроля версий и серверах сборки.
• Тестирование и контроль качества, включая неизбежный период «тонкой
настройки» в течение нескольких дней или недель непосредственно перед
запуском, когда исправления ошибок поглощают команду разработчиков.
• Миграция контента (тема, которую так хронически игнорируют, что я
посвятю ей целую главу)
• Обучение редакций и администраторов — начальная редакционная
команда, будущие члены команды, а также специальное обучение
конкретным задачам.
• Планирование инфраструктуры производственной среды
254 | Глава 12: Реализация CMS

• Планирование и выполнение развертывания, включая первоначальный
запуск и изменения после запуска.
• Документация либо самой реализации, либо процесса проекта.
• Управление проектом, включая отчетность о ходе реализации
• Внутренний маркетинг для затронутого персонала и заинтересованных сторон
• Управление сменой пользователей, включая перемещение учетных записей
пользователей, уведомление пользователей об изменениях и сброс пароля.
• Нагрузочное тестирование и тестирование безопасности
• Переход SSL-сертификатов
• Изменения и распространение DNS
• перенаправление URL-адресов
Все эти действия выходят за рамки построения принципов, и в результате они

часто не учитываются в оценках. В некоторых проектах фактическая
разработка становится незначительной по сравнению со всей работой, не
связанной с разработкой.
Поговорка об удвоении первоначальной оценки усилий, возможно, в конце концов не является
необоснованной.
Типы изРеализации
На самом общем уровне реализации CMS можно разделить на три типа в
зависимости от их связи с текущим веб-сайтом:
Только CMS или «погрузчик»2
В этом случае цель состоит в том, чтобы ничего на веб-сайте не менялось
— дизайн, контент и информационная архитектура останутся
идентичными, но CMS, на которой работает веб-сайт, будет заменена на
другую (или, реже, на статически управляемую систему). на сайте будет
внедрена CMS). В этом типе реализации текущий веб-сайт является
моделью нового веб-сайта.
CMS плюс изменение оформления или реорганизация
Это расширение реализации вилочного погрузчика, когда организация
решает провести легкую служебную работу, поскольку ей предстоит
внедрить CMS. Часто применяются новые дизайны, поскольку шаблоны в
любом случае придется переделывать, а миграция контента часто означает,
что контент можно очистить или реорганизовать без значительной
дополнительной работы. Некоторые вещи изменятся, но изменения
ограничиваются стилем и редакцией, а это означает, что текущий веб-сайт
по-прежнему в некоторой степени актуален в качестве модели.
2 Называется вилочным погрузчиком, потому что веб-сайт «поднимается», а новая CMS заменяется «под» ним.
Типы реализаций |2 5 5
Полная реконструкция
В таких случаях пересматривается весь веб-сайт. Новая CMS может быть
лишь частью более крупного цифрового оборота. Веб-сайт получит новый
дизайн, новый контент, новую информационную архитектуру и новую
функциональность — от старого сайта практически ничего не останется.
Внедрение CMS часто происходит после большой стратегии контента и
этапа планирования UX. Очевидно, что существующий веб-сайт не
подходит в качестве модели для нового веб-сайта.
Хотя первый тип, реализация вилочного погрузчика, может показаться самым
простым, он может оказаться обманчиво сложным, поскольку теперь вам
предстоит обернуть существующую базу исторических функций вокруг новой
CMS. Новая система всегда будет работать иначе, чем старая CMS, и веб-сайт,
вероятно, со временем адаптируется, чтобы соответствовать принципам работы
старой CMS. Команды внедрения часто пытались перенести существующую
функциональность в новую систему, чтобы воспроизвести развитие веб-сайта
на основе старой системы.
Пословица о крайних случаях, обсуждавшаяся ранее, справедлива и здесь. При
наличии достаточного количества времени редакторы найдут каждый уголок
CMS. Как упоминалось вГлава 10, любой конкретный редактор может
использовать только 25% общей функциональности, но каждый редактор
может использовать разные 25%, то есть редакционная группа коллективно
ожидает, что все старые функции будут работать в новой системе, иногда
одинаковым образом. , даже если это неэффективный способ достижения
какой-то цели.
С другой стороны, полная перестройка, по крайней мере, дает вам возможность
сопоставить новые функциональные возможности с новой CMS, на которой
они будут работать. Сопоставление требований к новому дизайну и
функциональности с технической осуществимостью — это ожидаемая
динамика проекта реконструкции, которая дает команде внедрения
возможность влиять на планы в отношении функциональности, которую будет
поддерживать новая CMS.
Перспектива:Скрытые проблемы проектов вилочных

погрузчиков
Джефф Итон
В крупных проектах лица, принимающие решения, часто
настаивают на миграции «вилочным погрузчиком», чтобы
снизить затраты как в деньгах, так и во времени. Это
вполне разумная цель, особенно учитывая масштаб и
сложность сайтов многих организаций. Однако, как
отмечает Дин, есть несколько распространенных ошибок,
на которые следует обратить внимание, если вы пойдете по
этому пути.
Во-первых, существует риск постепенного редизайна. Миграция с помощью
погрузчика обещает экономию времени и средств, поскольку повторно
использует навигацию, организацию и внешний вид существующего дизайна
Предполагалось, но вскоре все решения, заложенные в старом проекте,
пересматриваются и подвергаются сомнению. Придерживайтесь чисто
поверхностных обновлений или инвестируйте в хорошо спланированный
процесс проектирования: «подкрасться» к редизайну таким способом — это
смерть из-за тысяч сокращений сроков и бюджета.
Вторая опасность – архитектурное несоответствие. Различные платформы CMS
по-разному подходят к организации и представлению контента. Иногда рабское
дублирование внешнего вида старого сайта может вынудить вас прибегнуть к
странным и неудобным обходным путям, которые отнимают
непропорционально много времени и ресурсов. Логичным выбором будет
настроить дизайн так, чтобы он соответствовал подходу нового инструмента,
но если это не будет сделано тщательно, это может вызвать волновой эффект
усложнения дизайна.
Последний и самый серьезный риск — это искаженная модель контента. В
идеале модель контента сайта удовлетворяет деловые и коммуникационные
потребности организации, а дизайн разрабатывается для эффективного
представления этого контента. Когда визуальный дизайн находится в центре
внимания на раннем этапе планирования (будь то новые каркасы или внешний
вид текущего сайта), процесс моделирования часто сосредотачивается на
дублировании особенностей и крайних случаев этого дизайна, а не на общей
картине. Когда придет время для нового редизайна, предположения,
заложенные в модель контента, могут значительно усложнить процесс.
По моему опыту, настоящие миграции погрузчиков редки: самые успешные из
них к моменту завершения проекта превращаются в полную модернизацию.
Однако учет этих рисков делает реализацию обещанной экономии гораздо
более вероятной.
Джефф Итон — специалист по цифровой стратегии в Lullabot, Inc.
Предварительная реализация
Прежде чем приступить к реализации, вам необходимо подвести итоги того, с
чем вам придется работать, а затем использовать это для разработки плана.
Открытие и Предварительная реализацияАртефакты

Объем предварительной документации во многом зависит от уровня
планируемых изменений существующего веб-сайта.
Для реализации вилочного погрузчика существует возможность использования
текущего веб-сайта в качестве фактического документа с требованиями. При
простой замене CMS на существующем веб-сайте задачей проекта может быть
просто заставить все работать так же, как и раньше. Пока команда
разработчиков в достаточной степени понимает внутреннюю работу текущего
сайта и кто-то из редакционной команды доступен для вопросов, этого может
быть достаточно.
Если веб-сайт подвергается изменению оформления или реорганизации,
необходимо уделить некоторое внимание тому, как изменения повлияют на
CMS. Если изменения ограничиваются только дизайном и контентом, и ни
одно из этих изменений не требует изменения модели контента.
Предварительная реализация |2 5 7
сами по себе — тогда они могут не иметь отношения к усилиям по развитию.
Например, разработчика не волнует, требует ли дизайн шрифта с засечками или
без засечек, или же контент написан от первого или от третьего лица. Усилия
по развитию те же.
Будьте осторожны: изменения в дизайне и контенте необходимо тщательно
исследовать на предмет потенциальных изменений модели контента. Казалось
бы, простые изменения в дизайне и содержании могут потребовать
значительных изменений базовой модели, и эти изменения имеют странный
характер лавинообразного роста. Изменение вещи А внезапно вызывает
изменения в вещи Б и вещи С. Изменения порождают новые изменения, пока
две недели спустя вы не меняете вещь Z и не понимаете, что первоначальные
изменения зашли гораздо глубже, чем вы думали.
Один винт
Один из моих технических рецензентов рассказал этот анекдот,
который удивительно похож на многие проекты CMS:
Все началось с того, что из нашей старой
посудомоечной машины выпал шуруп. Мы могли бы
заменить винт, но решили, что посудомоечная машина
старая и, вероятно, все равно скоро выйдет из строя.
Поэтому мы купили новый. Новая посудомоечная
машина привлекла больше внимания к нашей
уродливой кухне. Поэтому мы отремонтировали его и
пристроенную к нему столовую. Когда этот проект
был завершен, вид из нашей новой столовой на
старую гостиную был жалким. Итак, мы
отремонтировали третий этаж, перевезли туда детей.
Одну из детских комнат превратили в комнату с
телевизором, а нашу гостиную превратили в красивую
гостиную… и все это благодаря одному винту.
Каков единственный винтик вашего проекта?
Для полной перестройки необходима значительная документация объекта для

эффективной реализации. Как минимум, команде разработчиков потребуется
следующее:
• Набор каркасов, отображающий макет каждого основного типа контента,

включая все соответствующие элементы контента (см.Рисунок 12-1).
• Набор функциональных требований (или эквивалентных аннотаций к
каркасам), объясняющих, как должны работать невизуальные функции,
особенно навигация и контекстные функции в окружении.
• Карта сайта, показывающая, как весь контент сочетается и организован.
Рисунок 12-1. Образец каркаса с пронумерованными выносками, которые
обычно сопровождаются невизуальной информацией о том, как
функционируют элементы. Каркасы помогают отделить контент и
функциональность от готового дизайна, что может отвлекать при
разработке технического плана.
В зависимости от объема обязанностей интегратора ему также может потребоваться:
• Полностью визуализированный дизайн со всеми вспомогательными художественными

файлами.
• Фронтенд HTML/CSS реализованного дизайна
За последние полвека разработка внешнего интерфейса стала отдельной

дисциплиной. Раньше реализации можно было достичь с помощью одного
набора навыков разработки, но с появлением адаптивного дизайна и более
широким использованием клиентских технологий за фронтенд-разработку
теперь часто поручают собственную команду. Кроме того, во многих проектах
разработка внешнего интерфейса будет завершена до начала внедрения CMS.
Фаза открытия проекта CMS обычно выполняется командой специалистов по
контент-стратегии или специалистов по UX/IA, которые работают с
организацией для определения потребностей. Ключевым моментом является
то, нужно ли этой команде работать со знаниями о предполагаемой CMS или
нет, если эта информация вообще известна на данный момент.
Некоторые говорят, что сайты следует планировать так, чтобы они не зависели
от CMS, и что основное внимание должно быть уделено предоставлению
организации наилучшего веб-сайта. Однако более практичная школа мысли
утверждает, что если известна предполагаемая CMS, то необходимо проверить
планы и проекты на предмет того, что действительно может быть реализовано,
что означает отфильтровывание идеалистических и грандиозных планов,
которые невозможно воплотить в жизнь. Например, планирование
комплексной стратегии персонализации — это дорогостоящая трата времени,
если ваша CMS не поддерживает персонализацию и вы не можете
интегрировать необходимые функции из внешнего сервиса.
Если предполагаемая CMS известна, обычно разумно поручить команде
внедрения проанализировать планы и проекты на предмет осуществимости по
мере их появления. Раннее обсуждение гипотетической функциональности
может помочь команде дизайнеров получить четкое понимание того, какие
идеи действительно могут работать.
Разработка технического плана

Среди судебных адвокатов есть старая поговорка: «Никогда не задавай вопрос,
на который еще не знаешь ответа». Нечто подобное можно сказать и о
реализациях: «Никогда не начинайте реализовывать каркас, для которого у вас
еще нет плана».
В какой-то момент команде внедрения необходимо проанализировать
артефакты, предваряющие реализацию, и разработать технические планы для
всего, что в них содержится. Хотя заманчиво попытаться спланировать сайт
сверху вниз, лучше всего начинать снизу вверх. Это означает, что нужно
просмотреть набор каркасов и задать множество вопросов о каждом.
На эти вопросы необходимо ответить в той или иной форме до начала
разработки. В некоторых случаях разработчик составляет официальный план
технической реализации (TIP). В других случаях макеты просто
просматриваются на «совещании по сборке», чтобы обеспечить понимание и
убедиться, что нет ничего, что невозможно реализовать.
Для каждого каркаса рассмотрите следующие вопросы:
• Присутствует ли объект оперативного контента? Какой это тип? Какие

атрибуты он должен поддерживать?
• Можно ли провести четкую линию вокруг объекта оперативного контента
и его окружения? Какой контент будет обрабатываться шаблоном объекта
и какой контент находится в его окружении?
• Что из контента в окружении контекстуально зависит от действующего
объекта контента?

• Что из этой контекстной информации будет получено из контекста или
географического положения, а что основано на дискретном содержании,
присутствующем в объекте?
• Какие агрегаты присутствуют? Могут ли они получить поддержку только
за счет географии, или для их поддержки потребуются вторичные
структуры?
• Какой неконтентный функционал присутствует? Как это будет работать
вместе с CMS?
• Насколько повторяемыми должны быть элементы в этом каркасе? Они
касаются только этой страницы или возникают снова и снова?
• Является ли этот каркас буквальным или просто предполагает широкий
спектр возможных проявлений? Какие области этого каркаса могут быть
заменены редакторами?
• Как часто нужно будет изменять этот конкретный контент? Это то, чем
редакторы будут заниматься каждый день, или это будет установлено при
запуске и больше никогда не будет трогаться?
• Насколько это связано с будущей функциональностью? Следует ли
интерпретировать этот каркас в узком смысле как точное, буквальное
представление того, чего хочет планировщик сайта, или же он указывает
или намекает на другие вещи?
Все это визуальные вопросы, основанные на том, что на самом деле

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

• Каковы требования к редакционному процессу работы? Будет ли редактор
создавать этот контент непосредственно в интерфейсе CMS или он берется
откуда-то еще? Какие разрешения необходимо иметь для этого контента?
• Кто должен иметь разрешения на этот контент? Кто может его создавать,
редактировать или удалять?
• Должен ли контент быть локализован? На сколько языков? Какие
нетекстовые элементы (например, изображения) также потребуется
локализовать?
• Нужно ли версионировать этот контент? Нужно ли будет его архивировать
в какой-то момент? Что это значит в контексте этого проекта и этого
контента?
• В каких еще каналах необходимо публиковать этот контент? Будет ли это
происходить по тому же графику? Должно ли это произойти в любое
время? Кто может это инициировать?
• Существует ли этот контент сейчас? Если да, то где он находится и как мы
можем получить к нему доступ для миграции? Какова текущая скорость
этого контента — насколько быстро он меняется или переворачивается?
В связи с этим самым ценным вопросом, который может задать разработчик,
может быть просто: «Откуда это взялось?»
Для любого элемента каркаса планировщики сайта, владельцы или редакторы
должны объяснить, откуда он взялся. Это управляемый контент? Это из
объекта оперативного контента? Это из другого объекта контента? Это из
внешнего источника данных? Это контекстная логика, например связанный
контент или навигация по боковой панели? Если да, то на каких данных
основана эта логика?
Им не обязательно иметь полное техническое понимание (это работа
разработчика), но им необходимо иметь хотя бы какое-то логическое
представление о том, откуда берется контент. Если нет, разработчик может
сделать резервную копию и задать более общие вопросы о характере
информации:
• Это конкретно для этой страницы?

• Это глобально?
• Это зависит от типа контента?
• Все ли это видят?
• Это откуда-то за пределами CMS?
Из ответов разработчик может экстраполировать некоторую модель контента

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

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

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

• Какова форма этого контента? Какая география контента необходима для
его поддержки?3
• Как выглядит совокупная модель контента? Могут ли типы быть
абстрагированы до базовых типов, от которых могут наследовать другие
типы? Можно ли использовать композицию типов для упрощения модели?
• Какой контент является глобальным для установки и где этот контент
будет храниться?
• Какие более крупные, негеографические структуры агрегирования
необходимы? Существует ли глобальная стратегия тегов, категоризации
или меню, которая связывает контент воедино?
• Какова общая потребность в композиции страницы? Какая часть сайта
создана по шаблону, а какая — кустарная?
• Как выглядят совокупные требования к локализации? Сколько языков
потребуется поддерживать и как следует управлять языковыми
предпочтениями и резервными вариантами?
• Как выглядит модель пользователя? Сколько разных групп пользователей
нужно будет создать и какой охват будет у каждой из них?
• С какими внешними системами необходимо интегрироваться? Какие API
доступны и какой доступ разрешен? Можно ли получить эту информацию в
режиме реального времени или необходимо определить стратегию
импорта?
• Как выглядит наша общая стратегия миграции?
• Если целевая CMS известна, насколько хорошо раскрытая
функциональность совпадает с тем, что доступно «из коробки»? Какая
степень настройки потребуется для завершения реализации?
• Если целевая CMS неизвестна, какая CMS подойдет?
Ответы как на большие, так и на маленькие вопросы в совокупности образуют

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

Важно понимать, что ответы на вопросы предыдущего раздела не являются
универсальными. Многие из них связаны с конкретным сочетанием этой
организации, этой конкретной команды и долгосрочного плана этого веб-сайта.
Тот же план участка для комбинации X может быть реализован по-разному для
комбинации Y.
3 Конечно, если CMS уже выбрана, это может быть спорным вопросом, но это могло бы, по
крайней мере, пролить свет на то, как должна формироваться эта география.
В ходе анализа на уровне функций команда должна будет принять во внимание:
• Какой бюджет доступен для реализации?

• Насколько опытны редакторы? Насколько хорошо они могут быть обучены
и понимать технические концепции?
• Какую часть бюджета будет потреблять конкретная функция, и нужно ли ее
сопоставлять с ее ценностью? Можно ли ответственно реализовать его на
более низком уровне функциональности или доработать для экономии
бюджета?
• В какой степени организация хочет внести структурные изменения на сайт
без участия разработчика? В какой степени у него будут пользователи,
которые достаточно разбираются в HTML или CSS, чтобы разделить
некоторую ответственность за вывод?
• Как долго будет использоваться эта реализация? Это постоянно или временно?
• Каков дальнейший план развития? Есть ли фаза 2? Планирует ли
организация инвестировать в этот сайт в долгосрочной перспективе или это
разовая попытка? Какой уровень внутренней поддержки разработчиков у
него есть?
Вот пример.
Допустим, дизайн сайта требует множества текстовых выносок, все в разных
стилях. Должна ли быть визуальная «палитра» различных стилей, которую
редакторы смогут просматривать и выбирать один щелчком мыши? Или, с
другой стороны, можно ли этим редакторам доверить простое текстовое поле, в
котором можно ввести имя известного CSS-класса, который будет применен к
окружающему DIV?
Первый вариант явно более удобен для пользователя и отточен, но его
реализация может стоить значительно дороже и быть менее гибким. При
втором варианте новые классы CSS могут создаваться «на лету», и редакторы
могут просто вводить их, тогда как при первом варианте палитру стилей,
возможно, придется изменить вручную, чтобы представить новый стиль.
Некоторым редакторам нужен максимально удобный и контролируемый
интерфейс. Другие хотят быть «приближенными к металлу» и иметь больше
ручного контроля над этими вещами. Эти редакторы могут возмущаться, когда
им дают варианты с ложки, и раздражаться тем, что они не могут просто ввести
класс CSS, о существовании которого они знают. Только знание предпочтений,
навыков, подготовки, опыта и политики управления редактора может помочь
вам принять это решение.4
Использование Markdown и других форматов разметки — еще один яркий
пример. Некоторым редакторам нравится точность и скорость, которые дает
Markdown. Другие редакторы
4 Сложнее всего, когда интегратор является внешним и получает оплату за свою работу. В то время
как интегратор может использовать второй вариант в искренней попытке повысить гибкость, клиент
может рассматривать первый вариант как явно лучший и интерпретировать план интегратора как
недостаток навыков или, что еще хуже, желание предоставить некачественный продукт увеличить
свою прибыль.

ожидать редактирования WYSIWYG и может рассматривать Markdown как
«низкую арендную плату» и даже задаваться вопросом, почему такая дорогая
CMS или ее реализация недостаточно компетентны, чтобы ощущаться как
Microsoft Word. В таких ситуациях соответствует ли технический план тому,
что ожидают редакторы, или необходимо обосновать альтернативу?
Это открывает гораздо более широкие вопросы, связанные с принятием
пользователями и внутренним маркетингом, которые имеют решающее
значение, но выходят за рамки этой книги. Возможно, 10–15% усилий по
любой реализации могут составлять социальная инженерия и обучение
пользователей, как самой системы, так и решений, принятых во время
реализации. Возвращаясь к нашему примеру, нужно ли редакторам просто
пройти обучение работе с Markdown, рассказать о его преимуществах и о том,
почему это правильное решение в данной ситуации? Как далеко в эту кроличью
нору готова зайти команда? Придется ли им «вернуть это решение» к более
крупным концепциям, таким как разделение контента и представления?
Правильный путь
Однажды в моей компании шла бурная дискуссия о
приемлемости срезать углы и оставлять некоторые острые
углы ради экономии бюджета (конечно, с понимания клиента).
Один из разработчиков сказал: «Я бы не стал этого делать,
потому что хочу сделать все правильно». Невысказанным
осталось то, что означало «право». Означает ли это
архитектурно совершенный путь? Или это означает
практичный, но менее совершенный способ достижения целей
клиента, одна из которых — уложиться в рамки бюджета?
Разработчикам приходится принимать подобные решения
десятки раз в ходе любой реализации. (Обратитесь к«Несущие
стены» на странице 176.)
Конечные цели проекта также будут оказывать влияние на решения по его

реализации. Рассмотрим эти два проекта:
• Временный рекламный микросайт для поддержки одной конференции с

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

реализации. Для временного микросайта углы могут быть оправданно
сокращены ради бюджета, времени и того факта, что более сложная реализация
не даст многого.
прибыль на инвестиции. Однако основной сайт организации имеет гораздо
больший временной охват и более обширную распределенную редакционную
базу. Для этого проекта требуется более размеренная реализация. Более
глубокие инвестиции в удобство использования и гибкость будут иметь
широту и время, необходимые для того, чтобы обеспечить ценность,
оправдывающую их затраты.
ШагМногослойность
Архитектор Фрэнк Даффи известен своей концепцией под названием
«сдвигающиеся слои» или «наслоение темпов». Он рассматривает проект
здания по слоям, которые движутся и меняются с разной «темпностью». Всего
существует шесть слоев, все начинаются с буквы «S»:5
Сайт
Фактическая территория, на которой находится строительная площадка
Состав
Недвижимые части здания
Кожа
Внешняя поверхность здания
Услуги
Базовые электрические, водопроводные и климатические системы здания.
Космос
Внутренний дизайн здания
Вещи
Вся мебель и отделка внутри здания.
Эти слои движутся с разной скоростью. Мебель в комнате будет переставляться
с гораздо большей скоростью, чем земля под зданием будет разрушаться с
течением времени. Точно так же внешняя поверхность здания меняется гораздо
легче, чем фундамент или опорные столбы.
То же самое относится и к веб-сайту и его содержимому. Все меняется с разной
скоростью. Основная цель CMS будет меняться с другой скоростью, чем слова,
хранящиеся в ней. И логотип в верхнем углу будет меняться с другой
скоростью, чем список выпусков новостей.
Каждый элемент имеет темп. Эти темпы необходимо учитывать при
планировании. Для объектов, которые движутся медленнее, может
потребоваться меньше инструментов управления (или, возможно, менее
совершенных инструментов управления). Очевидно, что понимание темпов
является ключом к принятию разумных решений о том, как реализовать.
5 Подробно Стюартом Брэндом в книге «Как учатся здания: что происходит после того, как они сданы в
эксплуатацию»Построен(Пингвин).

Желание обобщать
Разработчики любят обобщать. Специфика вызывает у нас длительное
беспокойство, как будто мы строим что-то слишком жесткое вокруг набора
требований, а что, если можно получить больше функциональности, немного
ослабив?
Кроме того, разработчики любят иметь дело с абстракциями. Да, этот
конкретный объект контента относится к типу «Статья», но его также можно
рассматривать как тип «Веб-страница», и, даже более абстрактно, это
экземпляр некоторого корневого общего типа, такого как «Объект контента».
Это проявляется в желании интерпретировать каркасы и планы объектов и
обобщать их таким образом, чтобы справляться с ситуациями, которые явно не
требуются. Разработчики постоянно ведут мысленные разговоры вроде этого:
Ну, новостная статья — это на самом деле просто страница с датой и автором.
Если мы добавим поле даты к типу «Страница», то сможем объединить эти два
типа в один. А затем, в будущем, они смогут создавать смешанные списки
страниц и новостных статей. Если уж на то пошло, мне интересно, не следует
ли нам просто сделать тему справки еще и страницей. Мы могли бы сделать
присвоением категории только атрибут «Тема», и теперь у нас на один тип
меньше, и их тоже можно добавлять в списки. Кроме того, они могут добавлять
темы и к другим типам контента. Знаете, каркас домашней страницы этого не
требовал, но я видел, что они захотят добавить эти списки на боковые панели в
будущем.
Кое-что из этого можно интерпретировать как лень, но в основном это
настоящая попытка расширить решение, чтобы охватить сценарии, на
которые проецирует разработчик.пользователи. Если пользователь хочет
сделать что-то X, то разработчик, естественно, заранее продумывает, что он
может захотеть сделать что-то Y в будущем, и разработчик может заранее
удовлетворить эту потребность.
На самом деле нет ничего, что разработчику нравится больше, чем слышать,
как редактор говорит: «Мы думаем о том, чтобы, возможно, сделать что-то
Y…», и обрывает их, откинувшись на спинку стула и говоря: «Нет проблем. Я
подумал, что ты захочешь этого, поэтому я уже сделал это за тебя…» [вставьте
здесь преувеличенное движение руки, похожее на волшебство].
Отчасти это нормально, но иногда разработчики могут быть слишком умными.
Ранее мы обсуждали, как разработчики привыкли думать о сложных
информационных проблемах и работать с абстракциями. Иногда их можно
убедить, что редакторы разделят это удовольствие и мастерство. Но обычно
редакторы любят конкретность в той же степени, в какой разработчики любят
абстракцию.
Разработчикам и планировщикам сайта необходимо провести продуктивные
обсуждения о том, является ли план сайта наводящим на размышления или
буквальным, и за этим должны последовать разговоры с редакторами о том, что
они, возможно, захотят сделать в будущем, а затем за этим должны
последовать разговоры с менеджерам проектов о том, как эти вещи могут
повлиять на бюджет и сроки, как для непосредственного проекта, так и,
возможно, для последующих проектов.
В некоторых случаях разработчикам может потребоваться напомнить, что они
не создают структуру или абстракцию. По сути, они создают настоящий веб-
сайт с ограниченным набором задач, которые необходимо решить.
Майк Тайсон о планировании

Боксер Майк Тайсон известен многими вещами, но когда его спросили о
стратегии его противника перед матчем, он сделал одно из своих наиболее
глубоких заявлений: «У каждого есть план, пока его не ударят по лицу».6
Позиция Майка заключалась в следующем: любое планирование в мире имеет
тенденцию ломаться под нагрузкой. Когда вы находитесь в середине проекта,
план — это отличная отправная точка и хорошее руководство, которое поможет
вам не сбиться с пути, но будьте готовы при необходимости адаптироваться.
Не придерживайтесь плана только потому, что это план. План должен быть
живым документом. Если вы запутались во время реализации, будьте готовы
изменить план, если станет очевидно, что что-то не работает.
Процесс реализации
Реализации CMS может быть трудно обобщать, но следующее описание
должно быть как можно более всеобъемлющим и разумно представлять
важные этапы, через которые будет проходить реализация.
СредаНастраивать
В большинстве случаев разработчики будут разрабатывать новый веб-сайт на
своих локальных рабочих станциях. Они отправят свой код в центральный
репозиторий, который представляет собой платформу управления исходным
кодом (SCM), такую как Git, Subversion или Team Foundation Server. Несколько
разработчиков могут отправлять новый код, который затем объединяется и
развертывается на сервере интеграции для проверки и тестирования.
Разработчики продолжают цикл разработки новых функций, отправки
собственного кода в SCM и загрузки кода, предоставленного другими, для
обновления своих локальных рабочих станций. Каждый разработчик
поддерживает полнофункциональную версию CMS и разрабатываемый веб-
сайт на своей локальной рабочей станции.
Процесс развертывания этого кода на серверах обычно называется «сборкой».
Обычно это достигается с помощью инструментов, называемых «серверами
сборки». Сервер сборки — это программное обеспечение, работающее на
сервере интеграции, которое отслеживает репозиторий SCM. Он обнаруживает
новый код
6 Тайсон сказал это, но это не было записано. Сведения о том, сказал ли он «в лицо», «в нос» или «в
рот», расходятся. Учитывая, насколько сильно бил Железный Майк, я сомневаюсь, что это различие
действительно необходимо.
отправляет и запускает процесс, который проверяет код и выполняет задачи,
необходимые для его запуска на сервере — компиляцию кода, удаление
исходных файлов, копирование кода в каталог веб-сервера, внедрение файлов
лицензий и т. д.7 Jenkins и Cruise Control — два популярных сервера сборки с
открытым исходным кодом.
Помимо сервера интеграции часто используется «тестовый» сервер для
обеспечения более стабильной среды. Хотя веб-сайт создается на сервере
интеграции, новый код (часто отправляемый разработчиками, иногда
несколько раз в час) развертывается на тестовом сервере реже, чтобы
поддерживать полустабильную среду для тестирования. Тестовый сервер
обычно имеет собственный сервер сборки, но он либо активируется вручную,
либо подключается к другой ветке репозитория SCM, где код объединяется
реже.8
Монтаж, Конфигурация, и СодержаниеПримирение

После создания всех необходимых сред происходит установка и настройка
CMS. Это менее важно, чем кажется, поскольку многие CMS устанавливаются
просто путем двойного щелчка по значку или путем развертывания файлов в
корне веб-сервера и выполнения мастера установки.9
Некоторые CMS спроектированы как автономные веб-приложения, намеренно
независимые от всего остального на сервере. В этих случаях CMS не
устанавливается на сервер, а устанавливается в процессе веб-сервера. Другие
требуют более целостной установки, при которой фоновые службы и,
возможно, другие файлы хранятся за пределами веб-сервера. В некоторых из
этих случаев эти файлы и службы могут использоваться более чем одной
реализацией этого CMS на одном сервере.
После завершения установки полученный веб-сайт, каким бы простым он ни
был, необходимо будет зарегистрировать в SCM, развернуть для интеграции, а
затем проверить другими разработчиками.
Согласование установки и ее содержимого между всеми разработчиками,
работающими над проектом, может оказаться непростым этапом. Один из
вечных вопросов — как обращаться с базой данных, на которой работает
большинство CMS. Каждый ли разработчик хранит свою копию
7 Эти инструменты также известны как серверы «непрерывной интеграции». Идея состоит в том, что
новый код должен постоянно интегрироваться в единое целое, чтобы проблемы можно было
обнаружить на ранней стадии, вместо того, чтобы выполнять редкие сборки всего решения, которые
не выявляют проблемы до поздней стадии процесса. Отправка кода, который не работает и
препятствует успешному развертыванию решения, называется «нарушением сборки». Обычно это
является источником остракизма и открытых насмешек среди коллег разработчика.
8 Обратите внимание, что веб-сайты тестирования и интеграции могут находиться на одном
сервере, поэтому их правильнее называть экземплярами тестирования и интеграции.
9 Известно, что менеджеры проектов с гордостью сообщают руководству, что они «завершили
установку CMS!» при этом не упоминая, что эта впечатляющая веха могла занять три минуты.
Процесс реализации |2 6 9
базу данных, или все разработчики общаются с центральной базой данных? А с
какими базами данных работают серверы интеграции и тестирования — со
своей или с центральной версией?
Если у каждого разработчика есть копия базы данных, он может работать, зная,
что его изменения не повлияют на других разработчиков. Однако наличие
нескольких копий базы данных означает, что все работают с разными копиями
контента, а изменения кода, требующие сопутствующих изменений данных,
могут потребовать репликации этих изменений в нескольких версиях базы
данных. Может быть развернут код, который нарушит работу установок других
разработчиков, поскольку соответствующие изменения данных не были
внесены в их копии базы данных.
Эту задачу можно значительно облегчить с помощью CMS, которая хранит
конфигурацию и управляет ею в виде кода. В некоторых системах создание
нового типа контента осуществляется путем написания кода: в Plone новый тип
контента определяется как новый файл Python; в Episerver новый тип контента
— это новый файл класса C#. В этих системах развертывание кода и настройка
представляют собой один и тот же процесс. Действия разработчика,
развертывающего код, также развертывают изменения конфигурации,
необходимые для работы этого кода.
В других системах новые типы контента могут быть созданы путем перехода
через административный интерфейс CMS. Эти изменения типа сохраняются в
базе данных, к которой подключена эта копия CMS. Если разработчик создает
новый тип контента на своей локальной рабочей станции, теперь у него есть
определение этого типа контента, локальное для его базы данных. Ему нужно
либо заново создать тип на сервере интеграции (а затем на тестовом сервере, а
затем на рабочем сервере…), либо использовать какой-то внешний инструмент
для перемещения этих данных из своей базы данных в другую.
Наконец, как разработчики учитывают контент, постоянно создаваемый
редакцией? Если редакторы обнаруживают ошибку в новом контенте или
разработчику необходимо внести изменения, требующие новейшего контента,
как разработчик обновит свою локальную базу данных до уровня рабочей
версии?
Процесс «согласования» изменений контента — проклятие разработчиков
CMS. В то время как некоторые системы разработали значительные технологии
для переноса изменений контента между средами, в других системах просто
есть сообщество разработчиков, которое привыкло перемещать контент
вручную. У других CMS есть внешние поставщики, которые специализируются
на инструментах, специально предназначенных для решения проблем
согласования.
Разработчики обычно работают с локальной базой данных, которая постепенно
становится все более и более устаревшей, пока они не почувствуют, что она
достаточно «устарела», и им необходимо обновить ее из производственных или
тестовых данных, часто с помощью резервного копирования и восстановления
вручную.10
10 И это не говоря уже обо всех файлах контента, созданных и управляемых в рабочей среде, хотя, к
счастью, их реже приходится «возвращать назад» в разработку.

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

Точно так же, как вы не можете протестировать машину, не заправив ее, вы не
можете разработать CMS, не имея в ней контента. Необходимо создать типы
контента для требуемой модели. Необходимо определить типы и добавить
свойства вместе с соответствующими правилами проверки. Возможно,
потребуется разработать специальные свойства в тех случаях, когда
встроенных свойств не хватает.
В дополнение к дискретной модели каждого типа необходимо определить
отношения между типами и объектами, включая свойства, которые ссылаются
на другие объекты, и отношения между типами контента. Это означает, что по
крайней мере часть дерева контента необходимо будет «обработать», чтобы
отобразить эти отношения, прежде чем можно будет продолжить дальнейшую
разработку.
Например, если вы издаете журнал, у вас могут быть тип «Выпуск», тип
«Раздел» и тип «Статья». У выпуска будет несколько дочерних разделов, в
которых будет несколько дочерних статей. Вы не можете работать над
шаблонами или другими функциями, пока у вас не будет репрезентативного
набора контента, что означает создание «фиктивного» контента в качестве
заполнителя для продолжения разработки.
Неявная навигация также зависит от грубого дерева контента. Если навигация
по сайту осуществляется путем итерации по дереву для формирования
основного и вторичного меню контента, перед продолжением разработки
необходимо будет создать объекты.
Обратите внимание, что во время черновой обработки нередко
обнаруживаются проблемы. Планы, которые, казалось бы, имели смысл
абстрактно, могут оказаться явно неработоспособными при фактическом
создании контента. Будьте готовы к тому, что на этом этапе некоторые планы
придется переработать. Это естественная часть процесса реализации.
Другие задачи моделирования включают в себя:
Определение допустимых агрегатов контента
Чтобы продолжить предыдущий пример, возможно, мы оговорим, что
объект Issue может содержать только дочерние элементы типа Раздел,
который, кроме того, может содержать только дочерние элементы типа
Статья.
Доработка редакционного интерфейса
Просто создать типы и свойства недостаточно. Редакционный интерфейс
необходимо рассматривать с точки зрения UX: четко ли обозначены
элементы? Имеется ли адекватный текст справки? Были ли удалены
ненужные элементы интерфейса? Иметь
расширенные параметры скрыты от пользователей, которые не поймут их
или не должны иметь к ним доступа?
Определение разрешений
Это требует, по крайней мере, минимальной доработки пользовательской
модели, чтобы группам можно было предоставлять различный доступ к
контенту. В частности, вам нужно быть осторожным с разрешением на
удаление, поскольку многие объекты контента будут «несущими стенами»
структуры контента, и если они будут удалены, то весь сайт может
перестать работать.
Помимо фактического контента, на этом этапе, возможно, придется создать
другие структуры для поддержки различных агрегатов, в том числе:
• Деревья категорий и таксономии

• Контролируемые наборы тегов
• Меню
• Поисковые индексы
• Списки и коллекции
• Настроенные поиски
Не развивайтесь в пузыре администраторов

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

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

Хотя вся следующая глава посвящена миграции контента, важно отметить, что
она должна начаться в той или иной форме, как только станет доступна
действующая модель контента. Многие реализации сошли с рельсов в конце,
когда «настоящий» контент был перенесен, что выявило множество проблем.
Контент, перенесенный на этом этапе, не обязательно должен быть полным или
идеальным, но его все равно необходимо перенести в систему. Нет никакой
замены реальному контенту в CMS, пока он разрабатывается.
Раннюю миграцию контента можно рассматривать как «расширенную
черновую обработку контента». Подобно тому, как философия непрерывной
интеграции в разработке стремится к полной интеграции кода как можно
раньше и чаще, философия «непрерывной миграции» стремится интегрировать
контент как можно раньше и чаще.
Риск невыполнения этого требования заключается в том, что команда
разработчиков работает только с теоретическим объемом контента. Конечно,
они кое-что доработали до такой степени, что им необходимо продолжить
разработку, но это не настоящий контент — он был придуман просто для того,
чтобы они могли продолжать разработку, и он был создан кем-то, кто хорошо
знает, как работает система. Сознательно или подсознательно, черновой
контент был создан для того, чтобы избежать задержек, а не для точного
отображения реального мира.
У настоящего контента есть недостатки. На нем часто появляются шишки и
синяки, и он не совсем соответствует тому, что вы себе представляете. Вам
необходимо учитывать недостающие данные, различные форматы, проблемы с
длиной, недостающие связи и т. д.
Предыдущее предупреждение о развитии в «пузыре администраторов»
справедливо и в отношении контента. Не развивайтесь в «надуманном пузыре
контента». Если только команде разработчиков не придется время от времени
останавливаться и заниматься контентом, который в конечном итоге будет
управлять сайтом, они будут брать на себя смелость и игнорировать крайние
случаи, которые могут вызвать проблемы в будущем.
Синдром пустого дома

Когда я получил свою первую квартиру, я был так рад переехать туда. У меня в
голове была вся планировка. Все должно было быть идеально.
В день переезда я с грустью осознал, что часть купленной мной мебели не
подошла. В частности, диван был слишком длинным для стены (а может,
квартира была слишком маленькой) и торчал в коридор. В результате
меблированная квартира в реальности оказалась менее величественной и
несколько более неуклюжей, чем тот идеальный вариант, который был у меня в
Я страдал синдромом пустого дома. Дом идеален без мебели.
тура. Когда вы передвигаете вещи, вы обнаруживаете, что некоторые вещи
просто не работают. Из окна в телевизоре противный свет, картинка слишком
мала для огромного пространства стены, и да, диван может торчать в коридор.
Хотя мы не можем решить реальную проблему с мебелью, мы можем что-то
сделать с контентом. Проверяйте свой контент на своем веб-сайте как можно
раньше и чаще. Узнайте, что будет работать нормально, а что нужно
переставить или поменять местами, чтобы избежать сюрприза в день переезда.
К этому моменту среда настроена, установлена CMS, создана модель контента
и доступен готовый контент.
Наконец, пришло время шаблонов. Это момент, которого вы ждали, когда вы
действительно сможете создать несколько презентаций контента, для
управления которым вы внедряете эту систему.
Шаблонизация существует в двух формах:
• Обрамление, которое представляет собой внешнюю оболочку каждой страницы.

• Объект, который представляет собой конкретный объект, который вы представляете.
Помните, что выходные данные шаблона объекта «вводятся» в окружение. Ваш

объект создается по шаблону, затем этот вывод вкладывается в оболочку
окружения.
Шаблоны объемного звучания

В большинстве случаев объемное звучание должно работать для всего
контента. Хотя наличие нескольких шаблонов объемного звучания может
случиться, это редкость. В большинстве случаев архитектура шаблонов имеет
единую среду, достаточно гибкую для адаптации ко всем типам контента. В
некоторых случаях окружения могут даже вкладываться друг в друга, но это
тоже редкость.
Создание шаблонов объемного звучания уникально тем, что оно не
выполняется в вакууме. Окружение зависит от объекта, отображаемого для
информации. Информация может быть двух типов:
Дискретный
Информация, полученная из значения одного или нескольких атрибутов.
Информация, полученная из положения объекта контента по
отношению к другому контенту.
Кроме того, окружение часто извлекает другие объекты контента и структуры
данных в дополнение к отображаемому объекту, чтобы предоставить данные
для других разделов страницы.
Например, основная навигация часто бывает явной, то есть существует
определенная совокупность контента, которая управляет ею. Системы с
деревом контента могут зависеть от страниц верхнего уровня, в то время как
другие системы могут иметь определенную структуру меню, в которой
перечислены эти страницы.
Опять же, здесь может возникнуть проблема «тирании дерева» — если
страницы верхнего уровня находятся в таком положении по причинам,
отличным от того, являются ли они основными вариантами навигации, то как
от этого отказаться? Нередко можно увидеть явное меню для основной
навигации, даже в системах, которые в противном случае зависят от своего
дерева для навигации.
Например, окружение часто зависит от определения правильной логики
навигации. Очевидно, что следы крошек имеют смысл только в отношении
отображаемого объекта контента. Местоположение этого объекта в
географическом пространстве будет определять то, что появится на следах.
Кроме того, на многих сайтах есть меню на левой боковой панели. Откуда ты
знаешь, что там появляется? Зависит ли это каким-либо образом от текущего
объекта контента? Например, отображает ли он все элементы в том же разделе
или группе контента, что и основной элемент? Является ли меню
иерархическим — оно «открывается»? Как определить, где и как он
открывается? На основании каких критериев?
Несмотря на такой акцент на глобальной и реляционной информации,
некоторые элементы окружения более непосредственно связаны с
отображаемым контентом. Например, общий элемент на боковой панели
(например, вездесущий «Связанный контент») зависит от фактического
отображаемого элемента контента. Он будет извлекать информацию из этого
объекта для визуализации. Все ли объекты имеют эту информацию, или
элемент в окружении должен учитывать различную информацию и даже
скрываться, если основной визуализируемый объект не относится к
совместимому типу?
Часто возникает вопрос: шаблонизируются ли подобные элементы в
окружении, или мы шаблонируем их как часть самого объекта контента, а
затем внедряем результаты в окружение? Шаблоны объектов контента часто
можно разделить на «разделы», некоторые из которых можно сопоставить с
местами в окружении. Таким образом, если связанный элемент контента
появляется только для одного типа, то, возможно, более подходящее место для
него — это шаблон объекта, а не объемный шаблон. Однако если этот элемент
объемного звучания требуется более чем в одном шаблоне, это неэффективное
дублирование
код, то есть его следует абстрагировать до включения или переместить в
шаблон окружения.11
Шаблонизация объектов
Внутри окружения находится вывод, созданный для конкретного объекта
контента. Обычно это гораздо проще, чем окружение, поскольку шаблон знает,
какой объект он отображает, и может принимать конкретные решения,
основываясь на безопасных предположениях о том, какие данные доступны.
Шаблон объекта не обязательно должен работать для всего контента, а только
для одного типа контента.
Кроме того, шаблон оперативного объекта на самом деле не имеет никакой
зависимости от шаблона объемного звучания. Хотя окружение во многом
зависит от объекта, обратное обычно неверно. Объект часто не может
выполняться, не зная и не заботясь о том, в какое окружение он в конечном
итоге будет обернут.
Некоторые шаблоны объектов контента представляют собой не более чем одну
или две строки, возможно, для простого вывода заголовка и тела простой
текстовой страницы контента.
Один объект контента может иметь несколько шаблонов для одного и того же
канала, в зависимости от критериев. В большинстве реализаций между типом и
шаблоном существует связь «один к одному», но в некоторых случаях шаблон
может различаться в зависимости от местоположения или содержимого или от
некоторой конкретной комбинации значений свойств внутри самого
содержимого. (Однако, если несколько типов контента имеют несколько
шаблонов, которые значительно различаются, можно подумать о создании
разных типов вообще.)
Создание шаблонов (как окружения, так и объектов) иногда может занимать
большую часть времени разработки реализации. В некоторых командах один
разработчик может нести ответственность за написание кода внешнего
интерфейса (HTML/CSS), тогда как в других ситуациях целая команда может
нести ответственность конкретно за этот код и либо предоставлять его
разработчикам внутреннего интерфейса, либо создавать шаблоны. сами себя. В
последнем случае бэкэнд-разработчик может «набросать» шаблоны, а затем
предоставить доступ внешним разработчикам для завершения кода.
Когда создание шаблонов будет завершено, сайт станет доступен для
навигации, все объекты будут опубликованы правильно, и он будет выглядеть
практически завершенным.
11 Примечательно, что одними из самых оживленных споров в проекте разработки могут быть
философские разногласия по поводу места кода. Возможно, не существует никаких споров о
экзистенциальной достоверности конкретного блока кода или о том, как он работает, но у двух
разработчиков могут возникнуть почти жестокие разногласия по поводу того, какое место в кодовой
базе является «правильным» местом для размещения этого кода.

Несодержание Интеграция иРазработка
Часто встречаются реализации CMS, которые не полностью начинаются и
заканчиваются только с помощью CMS. Многие реализации включают
внешние системы и данные или специально запрограммированные элементы,
не связанные с контентом.
Например, банк может разместить на своем веб-сайте специально
запрограммированную заявку на получение кредита. Это сложное автономное
приложение, которое не имеет абсолютно ничего общего с CMS — оно не
использует контент CMS для рендеринга, а также не создает и не изменяет
какой-либо контент посредством своего использования. Ему просто нужно
«жить» в CMS, чтобы его можно было просматривать вместе со всем
остальным контентом в CMS.
Возможность существования функций, не связанных с CMS, на веб-сайте с
управляемым контентом варьируется. Некоторые системы «хорошо играют» с
кодом, не принадлежащим CMS, который должен выполняться внутри него, но
некоторые системы «ревнивы» и очень затрудняют выполнение
индивидуального программирования в рамках CMS.
Разработчик всегда может написать собственный код вне системы и просто
получить доступ к исполняемому приложению или файлам, не вызывая CMS,
но тогда большая часть функций, связанных с CMS, будет потеряна. В идеале
пользовательский код может выполняться в рамках CMS и использовать
преимущества объемных шаблонов, управления URL-адресами, разрешений и
т. д.
Используя этот метод, выходные данные нашей заявки на получение кредита
могут быть «обернуты» окружением, а с помощью прокси-объекта контента
страница, содержащая приложение, может быть «помещена» внутри географии
CMS, чтобы окружение имело контекст для работы. с момента рендеринга.
(Видеть«Прокси-объекты содержимого» на странице 192.)
Проблемы возникнут при переходе с другой системы, работающей на
совершенно другом технологическом стеке. В таких случаях приложение
просто необходимо переписать, чтобы оно соответствовало стеку технологий
новой системы, что может потребовать значительных инвестиций — возможно,
даже больших, чем сама реализация CMS.
В некоторых ситуациях может потребоваться размещение функциональности
на внешнем сервере и перенос на веб-сайт через обратный прокси-сервер или,
что менее идеально, через IFRAME. Еще менее желательно было бы полностью
перевести пользователя на другой веб-сайт (например, «loanapp.bigbank.com»
для предыдущего примера приложения). Переходы между сайтами часто
приводят к неприятным визуальным и UX-переходам, а также к другим
техническим проблемам, таким как несоответствие доменов файлов cookie и
проблемы с аутентификацией.
The упражняться из содержаниеинтеграция

Эти проблемы рассматриваются под названием «интеграция контента», то есть
процесс объединения внешних данных с контентом в установке CMS. Для
этого существуют десятки моделей, каждая из которых имеет свои
преимущества и недостатки, и, как и во всем, наилучшее соответствие зависит
от требований:
• Где хранятся внешние данные?
• Насколько он изменчив? Как часто оно меняется?
• Нужно ли его переносить в CMS или можно получить доступ к нему там, где он есть?
• Если его необходимо переместить в CMS для доступа, каким должно быть
расписание? Насколько «устаревшим» можно позволить ему стать перед
обновлением?
• Соответствует ли каждая запись во внешнем источнике полному объекту
контента или мы просто добавляем контент к существующему объекту?
• Какова задержка доступа? Как быстро его можно получить?
• Насколько стабильно соединение между CMS и источником данных?
• Нужно ли будет когда-нибудь его модифицировать в среде CMS и отправлять обратно?
• Каковы проблемы безопасности? Может ли кто-нибудь иметь к нему доступ?
• Должны ли отдельные записи иметь URL-адрес или данные предназначены
только для просмотра в совокупности?
Например, университеты часто хотят, чтобы описания курсов были доступны

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

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

разделеГлава 11. Репозиторий курса может быть «монтирован» в режиме реального времени как
раздел репозитория.

Хостингмодели
Распространенные модели хостинга:
• Локальный хостинг, в собственном дата-центре организации

• Сторонний хостинг под контролем организации, когда организация
создает учетную запись хостинга на такой платформе, как Microsoft Azure
или Amazon Web Services, и напрямую управляет этой средой.
• Сторонний «управляемый» хостинг под внешним контролем, когда
организация передает контроль над хостингом другому поставщику (часто
интегратору в рамках пакетной сделки или поставщику CMS).
Как и почти любой другой тип приложений, CMS больше склоняются к облаку,
чем к локальному хостингу. Финансовые учреждения и сектор
здравоохранения продержались дольше остальных из-за проблем
конфиденциальности (или восприятия таковой), но даже эти организации
постепенно отказываются от локальных установок.
Хостинг, предоставляемый поставщиками, становится все более
распространенным, поскольку поставщики CMS стремятся перейти от
продуктовых компаний к сервисным компаниям. Многие объединяют плату за
хостинг и лицензию в рамках модели, подобной SaaS. Некоторые поставщики
продают локальные лицензии только по запросу — новые продажи считаются
продажами в облаке.
Хостинг средадизайн
Простота настройки виртуальных серверов и резервных облачных архитектур
полностью изменила способы запуска и управления хостингом. Раньше
настройка серверов была трудоемким и капиталоемким процессом.13 Запуск
серверов и установка CMS стали важной вехой. Теперь это может происходить
между встречами.
Полное обсуждение хостинга приложений выходит за рамки этой книги, и, к
счастью, оно не сильно отличается от хостинга других типов приложений. При
обсуждении хостинга основные моменты, которые следует учитывать и
обсуждать с вашей инфраструктурной командой, включают:
Отказоустойчивость и резервирование
Насколько избыточна среда и насколько она защищена от сбоев
архитектуры? Идеальное, бесшовное резервирование, безусловно, является
идеальной ситуацией, но оно редко реализуется в полной мере и часто
обходится дорого.
13 Я до сих пор помню, как часами устанавливал и настраивал Ektron CMS400.NET с наспех
записанного установочного компакт-диска (сервер изначально не имел доступа к сети), стоя перед
физическим сервером в стойке в каком-то замерзшем дата-центре еще в начале 2000-х. Мы прошли
долгий путь.
Аварийное переключение и аварийное восстановление
Если что-то пойдет не так, каков процесс восстановления? Будете ли вы
выполнять восстановление из резервной копии в новой среде или будете
поддерживать вторую среду с версией вашего контента, которую можно
будет удалить?
Производительность
Какой трафик может выдержать сайт? Как проходит нагрузочное
тестирование? Насколько быстро он может масштабироваться при
увеличении нагрузки? Можно ли запланировать масштабирование в
ожидании увеличения нагрузки? (Например, можете ли вы запланировать
временное или «пакетное» масштабирование среды на 72 часа в ожидании
увеличения трафика после выпуска основного продукта?)
Безопасность и доступ
Кто имеет доступ к серверу? Как новый код развертывается на веб-сайте?
Кто может одобрить такое развертывание?
Независимо от модели и технических характеристик среды, среда должна быть
доступна задолго до запуска, чтобы ее можно было протестировать под
нагрузкой, иметь установленные и протестированные процедуры резервного
копирования и переключения при сбое, а также иметь достаточное количество
тестовых развертываний, чтобы гарантировать, что процесс свободен от
ошибка. Чего вы явно не хотите, так это того, чтобы среда была доступна в
ночь перед запуском.
Как только рабочая среда станет доступной, убедитесь, что развертывание кода
было выполнено полностью, а команда разработчиков проверила
работоспособность сайта в этой среде. Многие планы запуска были отменены в
последнюю минуту из-за непредвиденных проблем, вызванных первым
развертыванием производства.
Обучение и ПоддерживатьПланирование
Редакторам и администраторам необходимо будет пройти обучение работе с
новой CMS. Существуют два различных типа обучения:
Обучение CMS
Это общее обучение работе с CMS по умолчанию, что означает обучение
работе с Concrete5, Sitecore, BrightSpot или любой другой системой, в
которой был реализован ваш веб-сайт. Обычно это предоставляется
поставщиком.
Обучение внедрению
Это обучение на вашем конкретном веб-сайте, что означает понимание
того, как общая CMS соответствует вашим требованиям, а также
понимание концепций и структур, которые могут существовать на вашем
веб-сайте и ни на каком другом. Это может обеспечить только инструктор,
знакомый с реализацией, поскольку поставщик не имеет ни знаний, ни
понимания того, как был реализован его продукт.
И то, и другое ценно, хотя последнее более важно для большинства редакторов.
Понимание того, как работает базовая CMS, не лишено достоинств, но
редакторам в первую очередь необходимо понимать, как были реализованы
функции их конкретного сайта. Соответствующие аспекты базовой
архитектуры могут быть включены в это обучение по мере необходимости, но
обычно в организации есть несколько избранных «чемпионов по продукту»,
которые знают базовую систему вдоль и поперек, а также для остальной части
редактирования. команде просто иметь конкретные знания о работе в пределах
своей профессиональной юрисдикции.
Помимо первоначального обучения, следует составить план обучения будущих
редакторов. В более крупных и распределенных организациях (например, в
университетах) каждый месяц можно нанимать новых сотрудников, которым
потребуется обучение тому, как добавлять и редактировать контент в CMS.
В дополнение к официальным часам обучения необходимо рассмотреть
возможность специального процесса обучения и поддержки. Что происходит,
когда у редактора возникает проблема или ему нужна более глубокая помощь
по созданию контента? Кто может провести редакторов по системе в
кратчайшие сроки? И как CMS впишется в существующую инфраструктуру
ИТ-поддержки организации? Знает ли служба ИТ-поддержки о новой CMS?
Знают ли они, как этим пользоваться? Как проблемы обостряются?
К сожалению, обучению редко уделяется много внимания, и многие
организации делают как можно меньше в надежде, что все «просто получится».
Помните, что обучение — это прямая основа для внедрения пользователями.
Когда пользователи понимают систему и чувствуют себя комфортно с ней, они
с большей вероятностью примут ее и будут использовать в полной мере. Не
один проект провалился из-за прохладной реакции пользователей, возникшей
из-за отсутствия понимания и обучения.14
Финал Содержание Миграция, ОК, иЗапуск

Мы подробно обсудим миграцию контента в следующей главе. Однако где-то
на позднем этапе цикла разработки начнется окончательная миграция контента,
когда контент начнет поступать в систему в той форме, в которой он останется.
Этот контент необходимо будет проверить и отредактировать, иногда
значительно. Это всегда занимает больше времени, чем планировалось, и
продление даты запуска является обычным явлением, в то время как
редакционная группа работает над контентом, пытаясь «привести его в форму»
достаточно для запуска.
Завершающая часть интеграции CMS никогда не ослабевает. Обычно
редакторы, разработчики и менеджеры проектов манипулируют постоянно
меняющимся списком заявок на контроль качества и исправлений контента.
Вам необходимо заложить в бюджет подход «все наготове» в течение
последних нескольких дней или недель после запуска CMS. Редакционная
группа должна быть готова к экстренному исправлению контента.
14 Майкл Сэмпсон написал целую книгу о стратегиях повышения эффективности внедрения новых
технологий пользователями. ЕгоСтратегии адаптации пользователей («Компания Майкла
Сэмпсона») — одна из немногих книг на рынке, специализирующихся на этой теме.
Окончательные функции могут все еще находиться в стадии разработки вплоть
до запуска, хотя многие функции часто выбрасываются за борт в безумной
схватке за запуск. Многие из них откладываются до повсеместного проекта
«Фаза 1.1», который неизменно планируется сразу после первоначального
запуска (о том, произойдет ли это на самом деле или нет, можно горячо
спорить).
Запуск может оказаться сложным делом в зависимости от того, заменяет ли
новый сайт существующий сайт в существующей среде хостинга или
развертывается в новой среде. Последнее всегда предпочтительнее, поскольку
тогда запуск — это просто вопрос изменения места разрешения доменного
имени (DNS), а не необходимость отключать сайт, выполнять установку и
регрессионное тестирование, а затем освобождать его. Учитывая простоту
настройки новых виртуализированных сред, обычно более эффективно
развернуть сайт в новой параллельной среде, запустить его через изменение
DNS, а затем просто заархивировать старую среду.
Если вы зависите от изменения DNS, возможно, придется временно отключить
пользовательский контент. Во время распространения DNS — процесса,
который варьируется от мгновенного до длительного (до 24 часов), в
зависимости от пользователя — некоторые пользователи будут
взаимодействовать с новым сайтом, а некоторые — со старым. Хотя редакторы
должны создавать контент исключительно на новом сайте, невозможно
гарантировать то же самое для пользователей. В некоторых случаях у
пользователя может возникнуть задержка DNS, он оставит комментарий на
старом сайте, а затем произойдет изменение DNS, в результате чего
пользователь просматривает новый сайт и задается вопросом, почему этот
комментарий отсутствует.
Заранее планируйте и репетируйте запуск сайта. Нет ничего более неприятного,
чем когда все готово к запуску, и обнаружить, что единственный человек,
способный изменить запись DNS, ушел в отпуск. Пройдитесь по запуску
заранее, при необходимости составив поминутный график.
Избегание РазработкаЦентризм
Если есть что-то, что должна была продемонстрировать эта глава, так это то,
что фактическая разработка веб-сайта часто составляет меньшую часть всей
работы. Тем не менее, в проектах CMS по-прежнему очень распространен
подход, ориентированный на разработку, как будто все, что вам нужно сделать,
это создать сайт, а все остальное получится.
Подумайте о строительстве нового дома. На ум приходит образ плотника,
сковывающего пиломатериалы. Однако давайте посмотрим на более широкую
картину. Давайте сделаем шаг назад и учтем все, что происходит в этом
процессе, от начала до конца.
Нашим гипотетическим домовладельцам необходимо:
• Решили построить новый дом

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

завершения. Пока дом строится, нашим домовладельцам необходимо:
• Объясните своим детям, почему они переезжают

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

• Купите новые вещи, чтобы учесть изменения в декоре, размере и типе комнаты.
• Избавьтесь от вещей, которые не подходят для нового дома.
• Научитесь работать со всеми новыми приборами
• Найдите место для хранения всей документации и руководств по дому.
• Начните обслуживание и уборку нового дома, учитывая изменения в
размере, объеме и типе мебели.
• Устройте новоселье для своих друзей и семьи
Список можно продолжать и продолжать. Обратите внимание, что мы

полностью опустили любые задачи, связанные со строительством нового дома.
Все это были просто «мета-задачи» по строительству дома.
Говоря это, я не преуменьшаю важность и масштабы развития. Но будь
готовы к тому, что предстоит сделать гораздо больше, чем просто внедрить
новую CMS. От начала и до конца новый проект CMS представляет собой как
совокупность социальных, организационных, политических, бюджетных и
логистических проблем, так и технических проблем.
Урок ясен: игнорируйте огромный объем работы, не связанной с развитием, на
свой страх и риск.

ГЛАВА13
Миграция контента
Представьте себе, что вы готовите самое вкусное мороженое в мире. Сначала

вы начинаете с лучших ингредиентов — сладких сливок, тростникового сахара,
настоящей ванили — а затем часами смешиваете их вместе. 1 Вы добавляете
настоящие взбитые сливки, домашнюю горячую помадку и самые сладкие,
самые спелые бананы и вишни, которые когда-либо видел мир.
Затем, чтобы завершить шедевр, вы добавляете в него большую порцию…
кетчупа.
Вы прекрасно справлялись до самого конца.
Это история многих миграций контента — задачи перемещения
существующего контента из вашей старой CMS в новую CMS. Точно так же,
как проблемы обычно возникают, когда слишком много внимания уделяется
программному обеспечению, а не реализации, то же самое происходит, когда
этим двум компонентам уделяется слишком много внимания, а миграция
контента игнорируется. Организации найдут идеальную CMS, организуют
фантастическую реализацию, а затем в самом конце полностью провалят
проект из-за катастрофической миграции контента.
Помните, что CMS управляет контентом. Это настолько хорошо, насколько
хорош контент, который вы в него вкладываете. А контент, которым в
настоящее время управляет ваша организация, может быть результатом многих
лет создания, агрегирования и управления. В этот контент можно легко
инвестировать миллионы долларов как в бизнес-актив. Игнорирование этой
заключительной фазы вашего проекта означает неуважение к этому контенту и
обесценивание всех усилий, вложенных в него.
Миграцию часто рассматривают как «дополнительную» работу. Однако в
некоторых случаях миграция может составлять большую часть проекта. Проект
внедрения CMS на самом деле может представлять собой проект миграции с
прикрепленным к нему небольшим компонентом разработки.
1 Очевидно, я ничего не знаю о приготовлении мороженого.

285
Более одного проекта было отменено, когда организация столкнулась с
необходимостью перемещения всего существующего контента. В других
случаях эти затраты привели к решению просто обновить существующую
CMS, оставив контент там, где он был, а не перемещая его на новую CMS.
И, как и в случае с самим управлением контентом, не существует Великой
единой теории миграции контента. Каждый из них уникален. Ваш текущий веб-
сайт использует CMS, которая была модифицирована в результате сотен
решений по внедрению. Ваш новый веб-сайт использует другую CMS, которая
также была изменена сотнями различных решений по внедрению.
В этом смысле оба веб-сайта представляют собой уникальные маленькие
снежинки, и от миграции к миграции мало что можно сделать. Возможность
выполнить миграцию — это не столько определенная методология, сколько
набор лучших практик и болезненных уроков, которые определяют
уникальный план для этой конкретной миграции.
Миграция контента — это просто искусство и наука, и ее хронически
недооценивают. Выполнение их эффективно, вовремя и в рамках бюджета
может оказаться самой сложной частью проекта.
Предупреждение: НеясностьПредстоящий
Разговор о миграции контента может быть крайне
расплывчатым, поскольку мы обсуждаем гипотетически
существующую CMS, наполненную гипотетическим
контентом, которая переходит к новой гипотетической модели
контента в новой гипотетической CMS. Обсуждать эти вещи в
определенных терминах практически невозможно, поэтому
будьте готовы рассмотреть эту тему теоретически, понимая,
что специфика вашей ситуации всегда будет отличаться.
The РедакционныйИспытание
Хотя, казалось бы, главной задачей миграции является перемещение байтов на
диске из одной системы в другую, первая задача миграции на самом деле носит
редакционный характер: какой контент мигрирует и как он изменится?
Для некоторых проектов (например, внедрения вилочных погрузчиков,
обсуждаемых вГлава 12), ответы: (1) весь контент и (2) он вообще не
изменится. Однако для многих других миграция предоставляет ценную
возможность навести порядок, удалить нежелательный контент и изменить
существующий контент, чтобы более эффективно служить целям организации.
286 | Глава 13: Миграция контента

Ключевой момент: легче всего перенести контент, который вы не переносите.
Сейчас самое времяубрать дом.2 Просмотр вашей аналитики на наличие
контента, к которому больше нет доступа, может устранить огромные усилия
по миграции. Я видел интранет-проекты, в которых 90% существующего
контента просто удалялось. Для любого веб-сайта, существующего уже
несколько лет, нет никаких сомнений в том, что часть контента просто больше
не актуальна.
Могут ли эти решения приниматься автоматически? Например, можно ли
сказать: «Все выпуски новостей старше трех лет будут удалены»? Или все эти
решения потребуют редакционного вмешательства?
Многим миграциям контента предшествует инвентаризация контента, в ходе
которой весь существующий контент идентифицируется и анализируется, а
также принимаются решения относительно его будущей жизнеспособности.
Инвентаризация контента сама по себе является искусством и выходит далеко
за рамки этой книги.3 но результат инвентаризации нужно где-то записывать, в
идеале в форме, которую можно будет использовать для принятия
программных решений по контенту.
Многие инвентаризации сопровождаются громоздкими электронными
таблицами, которые бесполезны для разработчика, пытающегося переместить
контент. Лучшая идея — записать предполагаемое расположение контента
непосредственно вместе с самим контентом, добавив в CMS флажки
«Миграция на новый веб-сайт» или «Требуется проверка», что фактически
сделает существующую CMS местом хранения учета инвентаря контента.
Разработчики, выполняющие экспорт контента из существующей CMS, могут
затем безопасно игнорировать этот контент в своем коде.
Первой вехой в миграции контента всегда будет принятие окончательного
решения и запись всего контента, который необходимо переместить в новую
систему. Трудно планировать дальнейшие шаги по миграции, не зная хотя бы
этого.
Автоматизированный или ручной?

Самый низкотехнологичный метод переноса контента всегда будет
заключаться в том, что человек копирует контент из одного окна браузера и
вставляет его в другое. Хотя, по общему признанию, это утомительно, у этого
есть преимущества:
• Никаких технологических несовместимостей нет.

• Человек доступен для принятия редакционных решений в режиме
реального времени о том, как адаптировать контент.
2 Технический обозреватель отметил: «Прежде чем переехать, проведите распродажу во дворе».

3 Паула Лэнд написала справочник под названиемИнвентаризация и аудит контента по этому поводу
(XML Press). Подобным образом Дэвид Хоббс (см. врезку в конце главы) написал отчет на тему под
названием«Переосмыслить- инвентаризации контента».
Автоматизированный или ручной? | 287

• Изменение формата файла происходит проще. Копирование содержимого
из двоичных файлов, таких как Word или PDF, не намного сложнее, чем
копирование со страницы HTML. А динамически составленные страницы
можно легче разобрать и собрать заново.
Недостатком, конечно, является то, что ручная миграция является трудоемкой

и утомительной. Однако это не всегда неправильный ответ. Для миграции
небольшого объема контента, который будет существенно меняться по пути,
ручная миграция может быть правильным решением.
Аргументы против ручной миграции часто сводятся к объему или стоимости.
Решения о миграции контента вручную должны учитывать стоимость и
доступность персонала. Многие миграции вручную выполнялись стажерами
или студентами колледжей. Возможно, это не гламурная работа, но зачастую
она эффективна.
Однако преодоление определенного порога содержания сделает автоматизацию
наиболее экономически эффективным выбором. Миграция контента, которая
не требует серьезных редакционных решений во время миграции, обычно
может быть автоматизирована гораздо эффективнее.
Тем не менее, знайте, что автоматизация имеет пределы, и часто проще просто
восстановить выбранный контент в новой CMS вручную. Домашние страницы,
например, имеют тенденцию быть очень кустарными, со сложными
элементами контента, упорядоченными и размещенными очень тщательно.
Автоматизация извлечения, импорта и размещения элементов может оказаться
более сложной задачей, чем пользы, особенно если лишь несколько страниц
требуют специальной обработки. В таких случаях будьте готовы к гибридному
подходу, при котором определенный контент просто перестраивается на месте,
а не переносится автоматически.
The МиграцияПроцесс
В идеальном мире вы могли бы просто открыть административную консоль в
своей новой CMS и нажать кнопку с надписью «Импортировать контент из
[вставьте сюда существующую CMS]». Такая ситуация действительно
существует в той или иной форме для широко известных и
конкурентоспособных платформ с открытым исходным кодом, таких как
Drupal и WordPress, но недоступна для других.
Перенос контента между двумя системами обычно является индивидуальной
задачей. Просто нет стандартизации между системами и еще меньше
стандартизации между методологиями построения моделей контента. Даже
контент, поступающий из разных установок одной и той же CMS и
попадающий в него, может потребовать значительных изменений, в
зависимости от того, как контент в каждой установке был смоделирован и
агрегирован. Модель контента в одной установке редко просто сопоставляется
с моделью контента в другой установке.
Успешный перенос контента — это слабо структурированный процесс,
состоящий из следующих этапов:
1. Добыча. Содержимое извлекается из текущей среды.

2. Трансформация. Содержимое изменяется, чтобы просто очистить его или
изменить для правильной работы в новой среде.
3. Сборка. Контент агрегируется, чтобы правильно соответствовать новой среде.
4. Импортировать. Содержимое импортируется в новую среду.
5. Разрешение. Связи между объектами контента идентифицируются и разрешаются.
6. контроль качества. Импортированный контент проверяется на точность.
В следующих разделах мы обсудим каждый шаг этого процесса более подробно.
Добыча
К контенту вашей текущей CMS необходимо будет получить доступ и
перенести его в нейтральный формат, из которого его можно будет
преобразовать и импортировать. Контент необходимо извлекать на двух
уровнях: (1) отдельные объекты контента, которые разбиты на (2) отдельные
атрибуты контента.
Итак, вам нужно извлечь все ваши статьи, а также разбить их по атрибутам.
Пока эти два критерия соблюдаются, фактический целевой формат не имеет
значения. XML распространен, как и JSON. Даже вставка содержимого в
простую базу данных может работать нормально. Он просто должен быть в
формате, свободном от презентационных данных (например, дополнительного
HTML-кода, вставленного из шаблона рендеринга), легко манипулируемом и
доступном. Я даже видел, как извлеченный контент просто сохранялся в новой
CMS, чтобы его можно было переместить и уточнить позже.
В идеальном мире ваша существующая CMS имеет функцию экспорта, которая
может предоставить вам весь ваш контент в формате без представления. К
сожалению, встроенный экспорт часто не поддерживается или в результате
получается формат, непригодный для будущих этапов процесса миграции.
Попытка работать с предопределенным форматом экспорта со временем может
обнаружить, что было бы проще написать собственный процесс экспорта.
Без удобной функции экспорта есть два других способа извлечения контента:
• Из репозитория, что означает использование системного API или даже

переход непосредственно к базе данных через SQL (или какой-либо другой
метод для репозиториев, отличных от SQL).
• С самого веб-сайта, что означает написание кода для запроса страниц и
последующее извлечение фрагментов полученного HTML (также известное
как «очистка экрана»).
Процесс миграции |2 8 9
Хотя переход непосредственно к репозиторию может показаться более
простым из двух методов, он во многом зависит от возможностей системного
API. Система может иметь плохой API или находиться в ситуации, когда API
недоступен (например, размещенная система, особенно если поставщик не
знает, что его клиент планирует покинуть их).
Даже если это возможно, существует риск, поскольку в репозитории хранится
содержимое, оптимизированное для этой конкретной системы. CMS редко
хранит контент способом, специально предназначенным для экспорта. 4 От
хранилища к экрану контент может трансформироваться. То, как контент
находится внутри репозитория, может отличаться от того, как он выводится
конечному пользователю. Это может быть дополнительно изменено с помощью
кода шаблона, в результате чего фактический HTML-код, который выводится,
существенно отличается от HTML-кода в репозитории.
При очистке экрана вы гарантированно получите контент в правильной
выходной форме (при условии, что он фактически выводится именно в этот
момент), но вы ограничены тем контентом, который фактически выводится.
Может существовать множество необработанных административных свойств
контента, таких как даты истечения срока действия, имена авторов, разрешения
и метаданные, которые не выводятся конечному пользователю.5
Очистка экрана также ограничена качеством текущего HTML. Если текущий
сайт использует CMS, то он, вероятно, является шаблонным, поэтому вы
можете ожидать хотя бы минимальной согласованности. Еще лучше, когда
шаблоны можно изменить, чтобы упростить этот процесс — может быть очень
полезно, например, временно поместить некоторый контент в четко
определенные структуры HTML, а затем просто скрыть его от общественности
с помощью CSS во время процесса извлечения. . Этот контент по-прежнему
будет доступен для процесса очистки экрана, но страница не изменится для
общего доступа.
Сайты, которые в настоящее время являются статическими и не имеют
шаблонов, могут быть чрезвычайно проблематичными. Когда HTML-код
написан вручную, согласованность обычно гораздо меньше, и попытка извлечь
данные может оказаться невозможной. (К счастью, сайты, написанные
вручную, обычно настолько малы, что их проще перенести вручную.)
Нет двух одинаковых сценариев добычи. При любой миграции необходимо
проанализировать множество факторов, чтобы определить лучший метод
извлечения контента в нейтральном формате.
4 Кто-то может сказать, что несвязанная система устроена именно таким образом и что сам процесс
публикации на самом деле является формой экспорта.
5 Не говоря уже о предыдущих версиях контента, хотя я еще не видел миграции контента, которая бы
переносила какую-либо версию, кроме текущей, опубликованной версии. Перенос всей истории
версий каждого объекта контента был бы чрезвычайно амбициозной задачей. Многие системы даже
не имеют возможности явно воссоздавать старые версии из API (по замыслу), поэтому контент
придется сначала импортировать как самую старую известную версию, а затем последовательно
перезаписывать более новыми версиями, надеясь при этом, что все ссылки на реляционный контент,
используемые для конкретной версии, также будут доступны во время импорта объекта. Достаточно
сказать, что большинство организаций довольствуются простым сохранением где-нибудь старой
CMS на случай, если им придется обратиться к более старым версиям контента.

Усложнение встроенного контента при миграции
Хотя ранее я превозносил функциональность динамической
композиции страниц и встраивания контента (см.«Внедрение
контента» на стр. 97), это значительно усложняет миграцию
между системами. Если в объект контента встроен другой
элемент, необходимо принять трудное решение о том, как с
этим справиться во время миграции:
• Пытаемся ли мы идентифицировать и извлечь весь

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

автоматически реплицировала бы даже умеренный объем
встраивания контента. Различия в архитектурных парадигмах
для этой функциональности просто слишком велики.
Трансформация
Извлеченный контент редко бывает в форме, подходящей для вашей новой
CMS. Велика вероятность, что он содержит дополнительные HTML-теги или
структуру, не подходящую для вашей новой системы и стандартов реализации.
Например, контент, созданный много лет назад, может содержать устаревшие
HTML-теги, такие как FONT и даже BLINK.6 Чаще всего информация о стиле,
которая была действительна в вашей старой реализации, просто меняется.
Новая реализация может иметь новые классы CSS, новые методы указания
заголовков контента, новые методы выравнивания изображений и т. д.
Содержимое HTML необходимо будет изменить, чтобы отразить эти новые
стандарты. Обычно вы извлекаете контент, содержащий большие блоки HTML,
и вы не можете рассматривать этот HTML как непроницаемую единицу. Вам
часто придется «добраться» до этого HTML-кода и каким-либо образом
изменить его.
6 ПроведениеМИГАЮТпереход на новую реализацию может нарушить международные договоры.

Проконсультируйтесь со своим адвокатом.
Общие преобразования включают в себя:
• Удаление старых HTML-тегов

• Удаление встроенногоСЦЕНАРИЙиСТИЛЬтеги
• Смена уровней заголовков (изменение всехH1теги дляН2теги, например)
• Перестановка структур HTML (например, удаление изображений из
табличных структур подписей)
• Исправление неверного HTML (например, неправильной вложенности)
Конечным результатом должен быть HTML-код, который можно

импортировать в новую CMS и который будет совместим с новыми стилями,
стандартами кодирования и редакторами форматированного текста.
Хотя форматированный текст требует львиной доли преобразований,
возможно, потребуется изменить и другие данные:
• Формально слабые ссылки на атрибуты, возможно, придется преобразовать

в свои цели и вместо этого сохранить как идентификаторы.
• Атрибуты, возможно, придется объединить или разделить. Например,
старая система могла хранить имя и фамилию как единое целое, а новая
система требует, чтобы они были разделены.
• Возможно, потребуется удалить лишние данные из атрибутов, чтобы
обеспечить преобразование типов. Старая система могла хранить цену в
виде текстовой строки «1000 долларов США», тогда как новая система
требует целое число «1000» и будет форматировать это число во время
создания шаблона.
• В редких случаях может потребоваться создание новых объектов контента.
Если старая система хранила комментарии непосредственно в объектах
«Статьи», а новая система планирует управлять ими как отдельными
объектами контента, каждый комментарий необходимо будет
проанализировать из родительского объекта и создать как новый,
отдельный объект.
Число потенциальных преобразований безгранично. После того как

максимально чистые данные были извлечены из старой CMS, разработчик
новой реализации должен оценить их на предмет потенциальных проблем и
определить все способы, которыми они должны быть изменены перед
импортом.
Сборка
При обсуждении моделирования контента вГлава 6мы различаем дискретное
моделирование и реляционное моделирование. Первый описывал информацию
о контенте, которая ограничивается самим объектом контента. Последнее
касается того, как этот контент вписывается («относится») к другому контенту.
После того как вы извлекли сотни или тысячи объектов контента из
существующей CMS, эти объекты необходимо будет собрать и организовать,
чтобы правильно отразить их отношения в новой системе. Необходимо
перенести не только контент, но и отношения между контентом.
В частности, необходимо переносить деревья контента, а это означает, что
контент необходимо извлекать таким образом, чтобы отношения
родитель/потомок оставались неповрежденными или могли быть
реконструированы. В некоторых случаях это может означать экспорт
родительского идентификатора с каждым объектом контента. Если вы
выполняете очистку экрана, это может означать вывод родительского
идентификатора в МЕТА-теге или даже попытку реконструировать иерархию
на основе путей URL (при условии, что они правильно отражают древовидную
структуру).7
Изменение географии
Переход от древовидной системы к древовидной системе
интуитивно понятен, но при попытке переключить географию
возникает больше проблем. Если ваша старая система основана
на дереве контента, а новая CMS — на структуре папок, как вы
с этим справитесь? В старой системе контент имеет
родительский элемент, но в новой системе родительским
элементом является папка.
Здесь нет универсального ответа. Необходимо принимать
трудные решенияо том, как адаптировать контент к
фундаментальным географическим изменениям.
В некоторых случаях просто невозможно восстановить структуру контента.

Это может быть связано с присущим структурным параметром (например,
тысячи сообщений в блоге, упорядоченными только по дате) или из-за плохой
организации и архитектуры устаревшего сайта.
Сайты, которые с течением времени развивались органично, часто отражают
плохую и своеобразную навигацию, где пункты меню добавлялись на разовой
основе, чтобы создать желаемый шаблон навигации без какого-либо учета
общей географии контента. Эти сайты могут быть чрезвычайно трудными для
миграции, поскольку трудно навязать структуру чему-то, что в лучшем случае
было плохо структурировано, а в худшем - совершенно неструктурировано.
В этих случаях контент, возможно, придется импортировать без реляционной
структуры, а затем структурировать в новой системе. Группы контента можно
импортировать в «зону хранения» на новом сайте, а затем систематизировать с
помощью инструментов новой системы.
7 Я помню особенно сложный проект с существующей CMS, не имевшей встроенной иерархии, и

новой CMS с очень сильным деревом контента. К сожалению, URL-адреса были «оптимизированы
для SEO», чтобы весь контент находился на верхнем уровне и содержал только один сегмент URL-
адреса. Не имея абсолютно никакого другого способа выяснить географию контента, нам пришлось
анализировать HTML-код, который формировал следы, и восстанавливать иерархию на основе этой
Заглушка контента
В некоторых ситуациях сборка контента становится критической проблемой.
Новая система может потребовать точной географии, но контент старой
системы не содержит извлекаемой структуры, которую можно было бы
использовать повторно.
В этих случаях может быть правильным вариант «заглушить» контент в новой
системе. Используя этот метод, вы вручную создаете пустые объекты контента
в новой системе, организованные в правильную реляционную структуру, но
каждый из которых не содержит ничего, кроме ссылки на соответствующий
объект в существующей системе (и, возможно, заголовка, чтобы их можно
было легко идентифицировать).
Используя этот метод, редакторы создают «оболочку» новой географии
контента, не вводя при этом ничего, кроме существующих идентификаторов
контента. Когда эта структура завершена, ссылки на существующие элементы
контента используются для автоматического извлечения контента из
существующей CMS и заполнения соответствующих объектов в новой CMS.
Здесь работает более широкий принцип: ссылки на контент могут быть
структурированы в новой системе для представления новой реляционной
географии контента без какого-либо фактического дискретного контента. Вы
выделяете географические связи контента в виде заполнителей, которые можно
Импортировать
До этого момента мы получали контент только из старой системы. После того
как контент извлечен, преобразован и снова собран в работоспособную
структуру, его фактически необходимо перенести в новую CMS. Обычно эта
задача требует специального программирования.
Единственным исключением может быть случай, когда ваша новая система
имеет функцию импорта и имеет известный документированный формат, в
котором вы можете упорядочить экспортированный контент. Это редкость.
В большинстве систем разработчик пишет собственное задание для загрузки
нового контента в систему. Это может быть либо отдельная программа, которая
использует веб-службу или аналогичный API для «проталкивания» контента,
либо код, который работает внутри новой системы и «извлекает» контент.
Во многих случаях разработчику придется не просто импортировать контент,
но и создавать другие структуры данных для поддержки дополнительных
географических регионов, например теги, категории или меню.
Например, если ваши объекты контента назначены категориям в старой
системе, то эти категории необходимо будет создать в новой системе перед
миграцией.

(возможно, с помощью отдельного сценария «предварительного импорта») или
создается в реальном времени по мере импорта контента. В любом случае
входящий контент необходимо будет проверить на предмет присвоения
категорий, которые необходимо будет создать в это время.
Кроме того, учитывая итеративный характер миграции контента (подробнее
обсуждается далее в этой главе), задание импорта не может предполагать, что
контент еще не был импортирован ранее. Любое конкретное выполнение
задания импорта может представлять собой повторный запуск для обновления
или уточнения импортированного содержимого. В этом случае любое задание
импорта должно определять, существует ли уже импортируемый объект
контента. В этом случае существующий объект следует обновить на месте.
Может возникнуть соблазн просто удалить импортированный объект и создать
его заново, но это усложняется при работе с реляционным контентом. Как
только импортированный объект X имеет «разрешенную» связь (см.
следующий раздел) с импортированным объектом Y, удаление и воссоздание
разорвут эту связь. Таким образом, после создания импортированные объекты
должны быть обновлены.
Разрешение
Объекты контента имеют связи между собой. Они могут существовать в
географическом пространстве, которое было воссоздано на этапе повторной
сборки, обсуждавшемся ранее, но они также могут иметь явные ссылки —
например, свойство Author объекта Article может ссылаться на другой объект
контента. Кроме того, внутри форматированного текста может быть множество
HTML-ссылок.
Эти ссылки, скорее всего, оборвутся во время извлечения и импорта. Если
HTML-ссылка глубоко внутри форматированного текста объекта контента X
ссылается на объект контента Y, вам необходимо убедиться, что ссылка по-
прежнему действительна после того, как X и Y переместятся в свою новую
систему. При переносе контента структура URL-адресов контента часто
меняется. Эти внутренние ссылки необходимо найти и исправить, чтобы они
представляли новую структуру URL.
Для этого вы всегда должны хранить старый идентификатор вместе с новым
объектом контента. Импортированный объект контента должен знать, откуда
он взялся, то есть ему необходимо знать идентификатор или URL-адрес.8
соответствующего объекта контента в старой CMS. Довольно распространено
создание временных свойств для типов контента в новой CMS для хранения
этих значений во время разработки и миграции, а затем удаление этих полей и
их значений после успешного запуска, когда они больше не нужны.
Возможность обнаружения связей между объектами контента во многом
зависит от API существующей системы. Можно ли при обработке статьи
просто экспортировать идентификатор автора? Или ваша существующая CMS
хранит это как общедоступный URL-адрес автора? Или
8 Это, давайте посмотрим правде в глаза, просто еще одна форма удостоверения личности.
API системы предоставляет вам весь объект контента «Автор» при ссылке на
это свойство?
Для ссылочных атрибутов попытайтесь экспортировать идентификатор, если
это вообще возможно. Если ваша статья ссылается на автора, укажите
идентификатор этого объекта «Автор» в качестве значения атрибута. Вы бы
предпочли знать, что «Автором» является объект контента № 634, чем «Боб
Джонс». В последнем случае вам придется искать авторов по имени «Боб
Джонс» и надеяться, что найдется только один из них.
Процесс повторного подключения или «разрешения» всех этих ссылок
происходит в конце задания импорта. Контент импортируется с
неработающими ссылками, а затем, как только весь контент оказывается в
новой системе, эти ссылки разрешаются и указывают на правильные объекты.
Это невозможно сделать, поскольку контент импортируется, поскольку нет
никакой гарантии, что целевой объект уже находится в системе — например,
статья может быть импортирована до того, как будет импортирован ее автор.
В некоторых случаях вам, возможно, придется скорректировать модель
контента, чтобы разрешить более слабые ссылки во время импорта. Например,
если свойство Author вашего типа контента «Статья» должно быть
обязательным, вам, возможно, придется ослабить это значение во время
импорта, чтобы разрешить импорт статей без имени автора, а затем определить
автора позже в процессе. Как только весь контент будет добавлен, ссылки
можно будет разрешить и снова включить необходимые ограничения.
Чтобы разрешить HTML-ссылки, вам обычно придется анализировать HTML,
что означает поиск компетентной библиотеки синтаксического анализа, такой
как AngleSharp для .NET или Beautiful Soup для Python. Необходимо
обработать весь HTML-код с поиском всех тегов привязки или мультимедиа,
которые затем необходимо проверить, чтобы определить, ссылаются ли они на
внешние веб-сайты или внутренние объекты контента. Для привязок,
ссылающихся на другие импортированные объекты, эти объекты необходимо
найти на основе ссылки и изменить цель ссылки, чтобы отразить новый URL-
адрес (или альтернативный метод связывания). URL-адрес должен быть
вставлен в правильный формат репозитория для новой CMS, который может
быть не общедоступным URL-адресом, а скорее URL-адресом-заполнителем,
предназначенным для разрешения во время запроса.
Обычно разрешение ссылок на контент не происходит сразу. Обычно перед
тем, как весь контент будет успешно импортирован и можно будет начать
разрешение ссылок, выполняется несколько заданий импорта.
"Давайте Только Держать тот URL-адреса тотТакой же!"
Это отлично подходит для SEO, но может не помочь вашему
процессу импорта. Во многих системах встроенные URL-
адреса фактически хранятся как идентификаторы целевого
контента. Итак, URL-адрес внутри репозитория может
выглядеть так:
<a href="CMSLINK:634">
Во время рендерингаCMSLINK:634обнаруживается и заменяется
фактическим URL-адресом объекта контента № 634 в этот
момент. Маловероятно, что обе CMS поддерживают один и тот
же формат и последовательность идентификаторов, и обычно
вы не можете указать новый идентификатор при создании
нового контента. Это означает, что сохранение неизменных
URL-адресов, скорее всего, вам не поможет, поскольку
идентификатор целевого объекта контента («634» в примере)
почти наверняка изменится при импорте.9
контроль качества
Как только контент окажется в новой CMS и ссылки будут разрешены, можно
приступить к контролю качества миграции. Контроль качества миграции
предназначен для проверки того, что контент был успешно перенесен в новую
систему.
Он имеет два уровня:
Функциональныйконтроль качества
Это может выполнить человек, не обладающий знаниями в предметной
области, что означает отсутствие знаний о том, что на самом деле означает
контент. Все, что проверяет этот тестер, — это то, является ли контент в
целом неповрежденным — все ли свойства контента заполнены, все ссылки
работают, все изображения не работают и т. д. Этому человеку не нужно
понимать сам контент.
Контроль качества домена
Это должен выполнять человек, обладающий знаниями в предметной
области, что означает понимание предмета контента. Этот тестер
проверяет, находится ли контент в правильном месте в навигации,
правильно ли он классифицирован, правильно ли он отвечает на поисковые
запросы и т. д. Этот человек должен иметь квалификацию, чтобы
принимать редакционные решения относительно контента.
В идеале должен быть конкретный контрольный список контента для проверки
и четко структурированный метод записи проблем. Если тестировщик
обнаруживает проблему с контентом, где сохраняется эта информация? Во
многих случаях полезно добавить свойства временного контента.
9 В некоторых случаях CMS будет использовать в качестве идентификатора 32-битный GUID. В этих
системах иногда возможно явное указание идентификатора при создании контента. Если обе CMS
имеют этот формат, теоретически возможно сохранить одни и те же идентификаторы во время
миграции. Однако очевидно, что это случается редко, и даже в этом случае фактический текст
ссылки (который обнаруживается и заменяется) будет другим.
например флажок для Migration QA Complete или текстовое поле для записи
дефектов миграции непосредственно в самом объекте контента.
Альтернативно, система управления заявками или проблемами, используемая
для функционального контроля качества, может использоваться для устранения
дефектов миграции.
При обнаружении дефекта его необходимо оценить на предмет объема.
Дефекты могут быть одного из двух типов:
Импортные дефекты
Это дефекты, которые необходимо исправлять на уровне импорта, а это
значит, что они, скорее всего, широко распространены. Зачастую
небольшие дефекты являются предвестниками более серьезной проблемы.
Обнаружение одной или двух статей, у которых не заполнено свойство
Author, может обнаружить, что большая часть объектов Author была
случайно пропущена во время миграции, и единственным решением
является повторный запуск импорта и начало заново. Дефекты импорта
могут быть очень разрушительными, и всей команде миграции, возможно,
придется остановиться в середине работы, пока импорт будет исправлен и
повторен.
Дефекты объекта
Это дефекты, характерные для конкретного объекта контента. Это не
результат импорта, а проблемы, которые либо присутствовали на старом
сайте и были перенесены, либо возникли в результате чего-то, возникшего
в результате взаимодействия с новой CMS — например, отсутствующего
стиля или библиотеки JavaScript. Для них не обязательно заново выполнять
весь импорт, но их необходимо пометить для ручной коррекции после того,
как импорт будет выполнен в последний раз.
Эффективность является ключевым фактором в таких ситуациях. Наличие
нового веб-сайта на одном экране и старого веб-сайта на другом экране может
облегчить процесс сравнения версий контента. Если старый URL-адрес
сохраняется вместе с новым объектом контента, старая страница может даже
отображаться под новой страницей во временном IFRAME, поэтому
тестировщики могут просматривать оба объекта одновременно.
Автоматизированный контроль качества может быть полезен во время
тестирования миграции. Наличие средства проверки ссылок, запускаемого раз
в день и предоставляющего отчет о неработающих ссылках, может повысить
способность тестировщиков находить проблемы.
Миграция СкриптРазработка
Процесс автоматической миграции имеет тенденцию быть итеративным, этапы
которого выполняются циклично. По сути, это процесс выполнения какого-
либо действия, анализа результата, изменения процесса, а затем его
повторения.
Цель состоит в том, чтобы разработать сценарий миграции, который
экспортирует контент, правильно его преобразует, импортирует и разрешает
все ссылки за одно непрерывное выполнение, которое может занять минуты
или часы. Тогда этот скрипт можно будет выполнить непосредственно перед
запуском. Всю предыдущую работу в ходе цикла миграции можно
рассматривать как «пробный прогон», чтобы фактическую миграцию можно
было провести ближе к запуску.

Слово «сценарий» здесь имеет двойное значение: обычно оно принимает
форму реального программного сценария, который выполняется, и в более
общем смысле оно относится к хореографической серии действий — как
машинных, так и человеческих. -powered — которые предназначены для
последовательного выполнения позднее.
Разработка скрипта миграции часто выглядит так:
1. Одновременно с началом внедрения новой CMS разработчик начинает

изучать варианты экспорта контента из существующей CMS. Можно
протестировать несколько методов, пока не будет определен тот, который
обеспечивает наименьшее количество препятствий.
2. Как только работоспособный метод экспорта найден, разработчик
выполняет тестовый экспорт. Результаты просматриваются, часто
обнаруживаются некоторые недостатки (отсутствует свойство, неверные
ссылки и т. д.), и экспорт повторяется. Разработчик может повторять этот
цикл в течение нескольких дней или недель, пока не достигнет экспорта,
который будет считаться приемлемым.
3. Экспортированный контент сравнивается с требованиями новой CMS
(которые во многих случаях все еще находятся в стадии разработки) и
определяются необходимые преобразования. Методы выполнения этих
преобразований разрабатываются и включаются в задание экспорта,
которое затем можно повторно запустить с преобразованиями,
выполняемыми в реальном времени.
4. Когда новая CMS достигает состояния, в котором контент может быть
импортирован (по крайней мере, должна быть реализована модель
контента), разрабатывается задание на импорт для переноса
экспортированного контента в новую CMS. Как и экспорт, импорт
выполняется один раз, проверяется, часто обнаруживается отсутствие,
модифицируется и запускается снова. Этот процесс повторяется несколько
раз, пока импортированный контент не окажется удовлетворительным.
Часто в процессе импорта выявляются дефекты экспорта или
преобразования, что отодвигает разработчика назад в этом процессе.
В определенный момент сценарий миграции был доработан до такой степени,

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

Существует школа мысли, которая утверждает, что миграция должна быть
настолько прямой, насколько это возможно. Типы контента в старой системе
должны быть сопоставлены с идентичными типами в новой системе. Шаблоны
должны быть сопоставлены с идентичными шаблонами. Дерево контента
должно быть идентичным, навигация должна отображаться с использованием
той же логики и т. д.
Даже если вы можете это сделать, часто это не лучшая идея. Разные системы
Разработка сценария миграции |2 9 9
в другой системе. Попытка принудительно подогнать парадигмы одной CMS к
другой — это
идеальный рецепт для неоптимальной реализации.
Например, возможно, в вашей старой системе были «глобальные атрибуты»,
которые применялись к каждому типу контента, но в вашей новой системе их
нет. У него есть наследование типов контента, которое может выполнить то же
самое, но это предполагает создание более общего типа абстракции, а затем
наследование всех типов от него. При миграции «один к одному» этот метод
будет полностью упущен, и из-за этого пострадает реализация.
Содержание Скорость и МиграцияТайминг
Скорость изменения контента на конкретном веб-сайте можно назвать его
«скоростью». Новостной веб-сайт имеет высокую скорость контента, то есть
новый контент добавляется несколько раз в день. Небольшой веб-сайт, скажем,
стоматологического кабинета, может иметь более медленную скорость, а
страницы меняются максимум раз в несколько месяцев.
Даже разные области на одном сайте могут иметь разную скорость. На медиа-
сайте с высокой посещаемостью контент, подобный политике
конфиденциальности, скорее всего, будет иметь чрезвычайно низкую скорость.
Он может пересматриваться максимум раз в год и меняться раз в несколько
лет.
Идеальный контент для миграции имеет нулевую скорость, то есть контент не
изменится с момента начала миграции до запуска нового веб-сайта. Ссылаясь
на цикл миграции, который мы только что обсуждали, разработчик может
начать экспорт контента и знать, что ничто из этого контента не изменится в
ходе неизбежного процесса проб и ошибок, который может занять недели или
месяцы.
В реальном мире контент изменится. Содержимое, которое изначально
экспортируется в начале цикла, может измениться уже на следующий день.
Таким образом, идеальная ситуация — доработать сценарий миграции до такой
степени, что для переноса контента больше ничего не потребуется, а затем
запустить готовый сценарий непосредственно перед запуском.
Этот тип «миграции по нажатию кнопки» — это своего рода мираж. Это
возможно, но обычно требует огромного объема работы. Миграции могут быть
своеобразными, поскольку отдельные элементы контента могут нуждаться в
сложной тонкой настройке, которую нелегко реализовать в сценарии. Они
проявятся как дефекты объектов в процессе контроля качества. Эти разовые
исправления контента довольно распространены и предназначены для
устранения проблем с отдельными элементами контента, которые невозможно
включить в сценарий миграции.
Обычно случается так, что разработчик совершенствует сценарий миграции до
тех пор, пока дальнейшее уточнение становится невозможным или
неэффективным. Разработчик может довести сценарий миграции до состояния,
когда содержимое будет очень близко к состоянию запуска. Несмотря на это,
почти всегда после завершения выполнения сценария необходимо внести
некоторые исправления вручную.

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

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

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

Не стоит недооценивать миграцию контента.Это может оказаться самой
трудоемкой и самой рискованной частью внедрения CMS.
Последнее слово предупреждения | 301

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

Дэвид Хоббс
Миграции, особенно крупные, — это сложная штука. Их
необходимо приручить. Хорошей новостью является то,
что организации имеют больше контроля над ними, чем
может показаться очевидным.
Аналогия Дина с кетчупом уместна, поскольку многие
мигрировать, и в это время нам приходится делать то, что просто (брызгать
бутылку кетчупа, которая просто стоит там), а не то, что важно (возможно,
приготовление соуса, который полностью изменил бы блюдо, но занял бы
гораздо больше времени). Хотя миграционные сюрпризы случаются всегда, мы
хотим уменьшить их количество. Ключевым моментом является раннее
планирование, которое должно произойти еще до тех ранних тестов миграции,
которые Дин справедливо отметил как важные в предыдущей главе.
Даже легкое и раннее планирование миграции имеет большое значение.
Например, здоровая доза вопроса «Как будет происходить этот контент?»
Когда просмотр красивых каркасов имеет большое значение, быстрое указание
на области, где выгрузка контента в последнюю минуту из одной системы в
другую не позволит достичь видения, к которому все сплотились с помощью
каркасов. Помимо общего упоминания о миграции, способ провести очень
конкретные дискуссии по миграции (и более широкие дискуссии о целях
проекта) состоит в том, чтобы оценить усилия по миграции — возможно, даже
до отправки запросов предложений исполнителям — чтобы убедиться, что вы
действительно готовы выполняйте то, что задумали (и измените планы или
бюджет, если нет).
По своей сути у нас есть три ручки управления миграцией:
• Вес (сколько движется)

• Качество (какое качество мы достигаем)
• Расстояние (насколько сильно мы пытаемся изменить текущий
контент/сайт)
Нам нужно поиграть с этими ручками управления при планировании, и оценка

дает нам обратную связь, когда мы поворачиваем ручки. Даже дикие оценки
вытеснят полезный диалог обо всех других аспектах управления контентом, о
которых говорит Дин в книге (например, вы можете обнаружить, что помимо
изменений контента вам нужны существенные изменения в моделировании
контента).
Эффективный способ оценки — попытаться рассмотреть сегменты контента
(например, описания продуктов), просмотреть образцы (из вашего контента), а
затем подумать, какие шаги необходимо будет предпринять для обработки
контента во время миграции. (чтобы решить, что можно пропустить, что можно
автоматизировать и сколько усилий потребуют ручные) для достижения
определенного уровня качества. Затем вы можете настроить и переоценить его
по мере необходимости в дальнейшем развитии проекта.
Но прежде всего: планируйте миграцию заранее!
Дэвид Хоббс помогает организациям осуществлять более эффективные
изменения в сети и интранете посредствомраннем планировании и является
авторомРуководство по миграции веб-сайтов, версия 2 и «Переосмысление
инвентаризации контента» (David Hobbs Consulting).
Последнее слово предупреждения | 303
ГЛАВА14
Работающий с ВнешнийИнтеграторы
Когда приходит время приступить к реализации, кто это делает? Организация,

желающая использовать CMS, конечно, может сделать это сама, но существует
также обширная сеть профессиональных интеграционных фирм. Некоторые
поставщики CMS также интегрируют свои собственные CMS для своих
клиентов. Какой вариант правильный?
Многие организации не имеют сотрудников по разработке, что делает решение
очевидным. Даже если в организации есть внутренний персонал по разработке,
они все равно могут искать интегратора по нескольким причинам:
• Их команда разработчиков слишком занята другой работой, и у них просто

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

разумным выбором благодаря использованию различных моделей
взаимодействия, обсуждаемых в следующем разделе.
Прежде чем рассматривать проект, организациям следует проанализировать
свои внутренние ресурсы и определить, какое место они занимают. Результат
этой инвентаризации, скорее всего, послужит основой для любых решений,
принимаемых в отношении стратегии, функциональности и выбора системы.
305
Чтобы избежать путаницы, в этой главе будут использоваться следующие определения:
• Организация — это лицо, приобретающее CMS для

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

встречается в реализациях CMS.
С этого момента данная глава ориентирована на организацию.
Отныне все случаи использования местоимения «вы»
предназначены конкретно для обозначения реализующей
ОбручениеМодели
Существует несколько форм работы с интегратором, основанных на
распределении работ:
Интегратор разрабатывает
В этом случае вы просто выписываете чек и получаете взамен сайт. В
некоторых случаях вы можете даже заключить контракт с интегратором на
хостинг и поддержку, что означает, что вы никогда не сможете фактически
получить реализацию.
Интегратор и организация совместно разрабатывают
В этой ситуации вы и интегратор разрабатываете веб-сайт вместе, разделив
работу по какому-то согласованному методу.
Организация развивается, интегратор консультирует
В ситуациях, когда вы хотите выполнить большую часть работы
самостоятельно, вы все равно можете обратиться к интегратору за
экспертной консультацией. Во время плановых или специальных
совещаний интегратор может просмотреть текущую работу, обсудить
предстоящие проблемы и дать рекомендации по решению конкретных
ситуаций или проблем.
Организация развивается
Технически в этой ситуации интегратора нет, хотя иногда программное
обеспечение будет продаваться через другую сторону. Либо вы купите у
поставщика, либо программное обеспечение будет перепродано через
интегратора.
В крайних случаях диапазон является односторонним — только интегратор на
одном конце и исключительно ваша организация на другом — с различными
оттенками серого между ними.
Из двух средних вариантов модель совместного развития является наиболее
сложной с точки зрения логистики. Совместная работа над одной и той же
кодовой базой часто может быть затруднена, особенно между командами,
разбросанными по двум не связанным друг с другом организациям. Как ты
306 | Глава 14: Работа с внешними интеграторами

разделенное развитие? По функциональным линиям? Или ваша организация
хочет участвовать в каждом решении?
Передача знаний сопряжена с накладными расходами. Некоторые
обязательства быстро перерастают в долгосрочные обучающие отношения.
Будем надеяться, что это обучение посвящено исключительно CMS, хотя в
некоторых случаях интеграторы обучаются более фундаментальным вопросам
веб-разработки или операций разработки. К сожалению, необходимость такого
уровня обучения часто не очевидна до начала реализации проекта.
Различия в опыте между командами быстро станут очевидными. Интегратор
может создавать от 10 до 100 веб-сайтов в год, тогда как средняя организация
может обновлять свой собственный веб-сайт только раз в три-пять лет.
Эти трудности могут усугубиться, если принять во внимание более глубокие и
тонкие различия между профессиональным интегратором и типичной
организацией:
Мотивации
Интегратор может получать почасовую оплату, а зарплата в организации —
это невозвратные затраты.
Показатели успеха и временные горизонты
Организация должна смириться с результатом, тогда как интегратор
обычно прекращает работу после реализации проекта.
Соревнованиедля внимания
Клиенты интегратора не имеют никакой привязанности друг к другу —
один клиент не заботится о проектах других клиентов и, по сути,
конкурирует с другими клиентами за внимание. Напротив, сотрудники
организации якобы работают над достижением единственной миссии и
«клиента» — самой организации.
Проектстили
Интеграторы зачастую более гибки и итеративны, чем более крупные
организации. И наоборот, организация имеет преимущество более
открытого проекта: они могут продолжать работу над улучшением
реализации с течением времени, в то время как интегратор должен
определить «жесткую» точку остановки.
Межличностные навыки и опыт
Интегратор работает со многими клиентами и организационными стилями,
в то время как организация может быть более изолированной и более
привычной к тому, чтобы поставщики адаптировались к ней.
система управления контентом Продавец ПрофессиональныйУслуги

Многие поставщики CMS предлагают «профессиональные услуги», то есть
услуги по интеграции производимых ими CMS. Для некоторых поставщиков
это просто побочный бизнес, призванный
Модели взаимодействия | 307
обеспечить реальный доступ к своим собственным продуктам и предоставить
клиентам возможность экспертных услуг, чтобы сделать покупку лицензии
более привлекательной.
Однако для других поставщиков профессиональные услуги составляют
значительную часть доходов. Для небольшого подмножества CMS может даже
продаваться с прибылью или с убытком и существовать исключительно для
того, чтобы дать поставщику возможность продавать услуги интеграции. Для
этих поставщиков продажа лицензии без компонента профессиональных услуг
может рассматриваться командой продаж как провал.
Преимущество такого соглашения якобы заключается в том, что поставщики
знают свои системы лучше, чем кто-либо другой, и имеют беспрецедентный
доступ к продуктам и техническим командам. Хотя это, несомненно, верно,
использование профессиональных услуг поставщиков вызывает поляризацию у
многих в отрасли — это можно рассматривать как положительно по
вышеупомянутым причинам, так и отрицательно из-за проблем
изолированности.
Проблема здесь в том, что если поставщик работает только с собственной CMS,
он может оказаться изолированным от других разработок в отрасли. Я не раз
наблюдал команды профессиональных служб поставщиков, которые не знали о
разработках и методах, используемых более широким сообществом CMS. В
этих случаях поставщик может попасть в ловушку «по-своему или по шоссе»
— он всегда выполнял задачу X таким образом, и их продукт предназначен для
выполнения задачи X таким образом, поэтому очевидно, что это правильный
способ решения. задача Х.
Кроме того, поставщик может неохотно признавать, что его продукт имеет
недостатки, и поэтому будет сопротивляться полезным обходным путям или
внешней интеграции. Хотя сторонний интегратор может сказать: «Эта CMS
плохо справляется с задачей X, поэтому мы воспользуемся хаком Y, чтобы это
исправить», поставщик обычно этого не делает, потому что это может вызвать
неловкий вопрос. почему они не решают основную проблему.
Более сложная серая зона — это когда интегратор рекомендует

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

поставщиков столько же, сколько и в пользу отказа от них. Поставщики часто
продвигают профессиональные услуги так же усердно, как и свои продукты,
иногда до такой степени, что конкурируют с другими интеграторами, которые
работают с их продуктами для сервисного бизнеса.
Продажи и определение объема
Несомненно, самой сложной проблемой для интегратора является определение
масштаба проекта. Вы и поставщик должны прийти к какому-то соглашению
относительно работы, которую необходимо выполнить. Это сложнее, чем вы
думаете.
Вы знаете, чего хотите. Ваш сайт уже построен у вас в голове. У вас есть
видение того, как будет выглядеть конечный продукт. Интегратор не разделяет
эту точку зрения. Они не могут читать ваши мысли.
Более того, если вы раньше не интегрировали эту конкретную CMS, вы, скорее
всего, делаете предположения о том, как она работает. Вы предполагаете, что
функция X работает каким-то особым образом, или, возможно, вы не знаете,
как она работает, но предполагаете, что за ту сумму денег, которую вы
заплатили за систему, вы наверняка сможете достичь результата X каким-то
методом.
ВГлава 6мы определили термин овеществление, что в переводе с латыни
означает «сделать реальным». Проекты — это постоянный процесс
овеществления: смутная идея или цель воплощается в реальность посредством
применения информационных структур.
Рассмотрим эти утверждения:
• «Мы действительно терпим неудачу в цифровых технологиях. Нам нужно добиться

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

вниз по континууму к цели. Знать, что в вашей организации дела в цифровом
формате идут плохо, — это одно. Лучше точно определить, где, по вашему
мнению, вы терпите неудачу. Еще лучше определить потенциальное решение.
Проблема постепенно материализуется с течением времени.
К сожалению, у всех этих утверждений есть кое-что общее: ни одно из них не
может быть предложено фирмой-исполнителем. Последний — единственный, у
которого есть действенный план, но в нем все еще отсутствует ключевая
информация:
• Как выглядит техническая записка?

• Сколько их будет?
• Кто их автор?
• В какой системе они будут созданы?
• Как они должны выглядеть?
• Как их нужно доставить?
• Как необходимо контролировать доступ?
Продажи и определение объема | 309

• Что значит «подписаться» на базу данных?
Я мог бы продолжить: здесь нужно ответить как минимум на 50 вопросов, и

ответы на эти вопросы, вероятно, вызовут еще 100.
Во многих случаях на эти вопросы можно предположительно ответить
благодаря общему пониманию схожих вариантов использования, опыт которых
имеется как у организации, так и у интегратора. Если организации нужен RSS-
канал, это уже делалось много раз раньше, и и организация, и интегратор
имеют достаточно общее понимание этого и общее видение того, с чего начать.
Другие потребности гораздо более разнообразны: доски объявлений,
календари, системы профилей, комментирование и т. д. Эти вещи тоже
делались раньше, но диапазон функциональности от одного примера к другому
настолько обширен, что «общее» понимание между организациями и
интегратор может быть не таким распространенным, как думает один или оба
из них — организация может думать, что функция X очевидна и должна быть
включена, но только потому, что она присутствовала в одном примере,
который они видели.
Веб-сайты — это просто очень изменчивые вещи. Конечно, есть
закономерности, но два описания проблемы могут привести к созданию
совершенно разных веб-сайтов, точно так же, как фраза «жилье на одну семью»
может привести к строительству совершенно разных домов.
Артефакты до реализации
Ключевым фактором в попытке получить объем от исполнителя является то,
что вы привносите в отношения. Интегратору нужно с чего-то начинать. Что
вы им предоставляете для управления процессом анализа?
Рассмотрим эти отправные точки:
• У вас есть смутное представление о недостатке: «Нам нужен новый сайт».

• У вас есть существующий веб-сайт, у которого есть проблема: «Нам не
нравится дизайн» или «Наша CMS слишком сложна в использовании».
• У вас есть некий рассказ, объясняющий, чего вы хотите: «Вот различные
разделы, которые мы хотим видеть на новом веб-сайте».
• Вы получаете подробный анализ от квалифицированного консультанта:
«Вот функциональная спецификация, аннотированные каркасы и карта
сайта».
Из них последний — единственный, который предположительно можно

определить и подать заявку без дальнейшей проработки. Описанные
документы — функциональная спецификация, аннотированные каркасы и
карта сайта — вместе называются «артефактами до реализации». Это план, по
которому можно определить область действия веб-сайта.
Точно так же, как вы не зайдете в офис подрядчика и не спросите: «Сколько
стоит дом?» вы не можете спросить интегратора: «Сколько стоит веб-сайт?»
Интегратору понадобится план.
Проблема, скрывающаяся за проблемой

Хотя обращение к интегратору, хорошо вооруженному планом,
лучше, чем альтернативный вариант, будьте осторожны,
пытаясь решить свою собственную проблему. Зачастую
формулировки проблемы, подобные той, которую мы видели
ранее («Наши клиенты неинформированы…»), являются лишь
симптомом более серьезной проблемы, скрывающейся за
первой.
Почему клиенты не информированы? Возможно, ваша
документация плохо написана. Никакая CMS это не
исправит. Возможно, проблема еще серьезнее. Возможно, у
вашей продукции неудачное название, и это вызывает
путаницу. Еще больше: возможно, ваша продуктовая
линейка раздута и слишком сильно пересекается.
Это не книга по общим практикам ведения бизнеса, просто
знайте, что CMS часто обвиняют в проблемах, которые
происходят из источников, далеких от того, что CMS может
контролировать. Прежде чем кого-либо обвинять, проведите
небольшое исследование и убедитесь, что вы решаете
правильную проблему.
Как мы обсуждали вГлава 12, документы, которые нужны большинству интеграторов:

ФункциональныйСпецификация
Это описательный документ, объясняющий, как должен работать веб-сайт.
Он должен описывать все типы и агрегаты контента, пользователей и
группы, рабочие процессы и разрешения и т. д.
Аннотированные каркасы
Это штриховые рисунки того, как должен выглядеть каждый интерфейс.
Для каждого типа контента и агрегата должен быть хотя бы один каркас, а
также каркасы, показывающие их на разных контрольных точках
реагирования (планшет, телефон и т. д.). Выноски должны объяснять, как
должны работать конкретные функции.
Карта сайта или диаграмма IA
Это классическая диаграмма «коробки и стрелки», показывающая весь
контент на веб-сайте (или группы контента; например, новостные статьи в
совокупности). Он должен показывать логические и географические связи
между содержанием и должен быть максимально полным.
Это общепринятый минимум для комплексного и твердого предложения.
Умный интегратор, если у него меньше этой суммы, постарается добраться до
этой точки, прежде чем предоставить вам число.
Продажи и определение объема | 311
Если вы не принесете эту информацию с собой интегратору, ожидайте, что вас
направят в другую фирму для разработки информации или ожидайте, что
интегратор сделает это за вас и возьмет с вас за это плату.
Возможно, даже рассмотрите возможность рассматривать разработку этого
набора документации как отдельный проект с интегратором. Если у вас
возникли проблемы с четко определенным объемом, интегратор может помочь
вам разработать и задокументировать этот объем как самостоятельный проект
(возможно, даже за фиксированную плату), а затем предложить итоговый план.
Не считайте это «дополнительными» расходами, поскольку в какой-то момент
это придется сделать (помните, архитекторы проектируют дома не просто так).
Выделение его в отдельный проект дает вам преимущества как в виде
определенной стоимости, так и в виде более реалистичной и твердой цены для
более крупного проекта благодаря лучшей документации.
В любом проекте среднего или большего масштаба между вами и
интегратором, скорее всего, всегда будет некоторое недопонимание
относительно масштаба. Опытные интеграторы знают это и запланировали
определенную свободу действий в этом отношении. Общая цель — ограничить
эти недопонимания до такой степени, чтобы ни одно из них не оказывало
существенного влияния на проект.
Проверка реальности: дополнительные расходы как защитная мера

Получают ли веб-сайты масштаб и ставки с меньшим количеством
информации, чем то, что я описал здесь? Да все время. Это оптимальный метод
определения объема проекта, но я абсолютно признаю, что этот стандарт часто
не достигается.
Важно понять следующее: неопределенность приведет к заполнению.
Если интегратор не знает точно, как вы хотите, чтобы функция X работала, у
него есть два варианта:
• Заставьте вас сильнее определить свои требования.

• Увеличьте (или «дополните») их ставку, чтобы охватить то, что, по их
мнению, вы могли бы захотеть сделать.
Очевидно, что первый выбор правильный, но именно второй вариант часто в

конечном итоге и происходит. Интегратор может бояться потерять работу, или
у него может быть дыра в графике и ему нужно начать работу, поэтому он
просто увеличивает свою заявку и надеется на лучшее. Если ваши фактические
потребности растут, они покрываются; если они этого не делают, продавец
забирает прокладку в карман.
Разумный и рациональный процесс определения объема часто становится
Расходы
В прошлые годы существовало эмпирическое правило: внедрение CMS будет
стоить в три-четыре раза дороже, чем сама CMS. Таким образом, CMS, покупка
которой стоит 50 000 долларов, будет стоить от 150 000 до 200 000 долларов за
внедрение, в результате чего общая стоимость проекта примерно в четыре-пять
раз превышает стоимость программного обеспечения (или оценочные
эквивалентные затраты для системы с открытым исходным кодом).
Это грубая мера, не универсальная, но полезно хотя бы понять, насколько
дорогими могут быть реализации. Они почти всегда составляют большую часть
расходов в общем бюджете. Исчерпание большей части вашего бюджета на
лицензию CMS ограничит ваши возможности по ее внедрению, независимо от
того, делаете ли вы это самостоятельно или нанимаете третью сторону.
На практике реализации управления контентом охватывают широкий спектр —
от простых блогов, которые могут работать «из коробки», до невероятно
сложных платформ агрегирования контента, требующих огромных усилий по
разработке. Следовательно, не существует простого способа сделать
обобщение относительно объема бюджета. Некоторые из факторов, влияющих
на бюджет, включают в себя:
• Необходимое количество типов контента

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

для широкого диапазона бюджетов.
Возможно, это удивительно, но, если не считать усилий по обеспечению
качества миграции, общий объем контента не играет такой большой роли в
бюджете или уровне усилий, как вы думаете.
Рассмотрим веб-сайт со 100 000 объектов контента, каждый из которых имеет
одинаковый тип контента, структуру и требования к агрегированию.
Разработчик-исполнитель действительно работает с этим контентом на уровне
типа контента, а не на уровне объекта контента. Несмотря на то, что
существует 100 000 объектов, существует только один тип. Это лишь
небольшое преувеличение.
Затраты | 313
Можно сказать, что разработчика мало волнует, существует ли 100 объектов
или 100 000 — уровень усилий, необходимых для создания типов, агрегатов и
инструментов редактирования, в основном один и тот же.
Это та же самая причина, по которой «разовый» дизайн страницы может
привести к завышению стоимости реализации. Известно, что UX-фирмы сходят
с ума, предлагая детальный индивидуальный дизайн для десятков и десятков
страниц, каждая из которых привносит особенности управления контентом или
шаблонами, за которые интегратору придется учитывать. Помните, что
непоследовательность — это проклятие шаблонов, и каждый уникальный
дизайн страницы имеет свою цену.
Даже динамическая композиция страниц имеет ограничения, поскольку эти
системы работают с палитрой доступных элементов интерфейса. Каждый из
этих элементов должен быть идентифицирован вместе со всеми его
вариантами, а затем разработан, шаблонизирован и управляем таким образом,
чтобы страница сочеталась друг с другом так, как задумал дизайнер.
Наконец, при составлении бюджета на неизвестные вещи уходит слишком
много времени и средств. Внешняя интеграция, вероятно, является лучшим
примером. Когда вашей CMS приходится работать с Other System X, если
только команда внедрения не работала с обеими, из-за этого пострадают
график и бюджет. Заставить две системы работать вместе может быть сложно,
а иногда и невозможно. Усилия, необходимые для даже, казалось бы, простой
интеграции, иногда могут превзойти затраты на остальную часть проекта.
Письменные соглашения
В какой-то момент соглашение между вами и интегратором необходимо будет
кодифицировать и оформить посредством какого-либо письменного документа.
Этот документ якобы является юридическим соглашением для обеих сторон.
Номенклатура здесь является проблемой, поскольку не существует
общепринятого словаря для этой отрасли, особенно когда речь идет о
проектной документации. То, что одна фирма называет «предложением», для
другой может быть «заявлением о работе» или «меморандумом о
взаимопонимании».1
В целом документация делится на следующие типы. При работе с
интегратором вы часто будете видеть все три из них:
Маркетинговое предложение
Это привлекательный пакет продаж, предназначенный для того, чтобы
рассказать вам о возможностях фирмы. Это может вообще не относиться к
вашему проекту или даже к вашей организации, но вместо этого
продвигает возможности интегратора в общих чертах. Вы можете увидеть
этот пакет
1Моя компания обычно называет свои документы с предложениями «Предложение по

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

один раз, когда интегратор впервые обращается к вашей организации. Это
не исполняемый документ (строка для подписи отсутствует).
Соглашение об общих услугах (GSA)
Это в высшей степени юридический документ, в котором описываются
такие вещи, как гарантии, необходимое страховое покрытие, правила
интеллектуальной собственности и т. д. GSA обычно разрабатываются и
проверяются юристами. Скорее всего, не будет упоминания конкретного
проекта, поскольку эти документы обычно предназначены для
регулирования всей жизни отношений между интегратором и
организацией. Это исполняемые документы, которые часто являются
предметом серьезных переговоров и пересмотров. Эти документы также
известны как «Генеральные соглашения об оказании услуг» или
«Генеральные соглашения с поставщиками».
Заявление о работе (SOW)
Это документ, посвященный конкретному проекту, который точно
объясняет, что интегратор делает для этого конкретного проекта. Если вы
выполняете более одного проекта с интегратором, у вас, скорее всего,
будет одно задание для каждого проекта. Как следует из названия,
Техническое задание представляет собой объяснение деталей конкретной
единицы работы. Это исполняемый документ. ТЗ иногда называют
«предложением» или «проектным предложением».
Когда дело доходит до Соглашения об общих услугах, ключевой вопрос
заключается в следующем: какая сторона его составляет? У интегратора,
несомненно, есть свой собственный, но велика вероятность, что он есть и у
вашей организации. Вы выполняете оба? Что, если они конфликтуют? Вам
нужно просмотреть обе версии и перейти к третьей, решенной версии? Для
многих отделов соответствия в более крупных организациях это неприемлемо,
поскольку они хотят, чтобы их GSA выполнялось конкретно.
Во многих случаях побеждает сторона с наибольшим количеством юристов.
Интегратор отправит свой GSA на выполнение, а клиент вернет его с таким
количеством изменений, что интегратор решит, что проще просмотреть GSA
организации и просто убедиться, что в нем нет ничего спорного.
При обсуждении проекта часто возникает негласное мнение о том, какой
организации потребуется более строгая документация. Эта организация обычно
выполняет свой документ, даже если он не сильно отличается от версии другой
стороны. Пока обе стороны согласны с содержанием, то, кому изначально
принадлежал документ, не имеет особого значения.
Заявление о работе настолько важно, что требует отдельного раздела для обсуждения.
Заявление о работе
Техническое задание является руководящим документом для любого
конкретного проекта. Если возникают разногласия по какому-либо аспекту
проекта, ТЗ обычно является арбитражным документом. Если чего-то нет в ТЗ,
значит, этого юридически не существует.
Письменные соглашения |3 1 5
Как минимум, в ТЗ необходимо объяснить:
• Чтов настоящее время делается

• Когдаэто делается
• Сколькобудет ли это стоить
Что, когда и сколько. Это важнейшие вопросы в любой реализации.
Что является существованиесделанный?

В ТЗ необходимо четко указать масштаб проекта. Во многих случаях
артефакты до реализации, обсуждавшиеся ранее, будут прикреплены к этому
документу и упомянуты как экспонаты.
Объем работ в ТЗ часто говорит что-то вроде: «Интегратор разработает веб-
сайт, отвечающий функциональности и требованиям, описанным в
Приложении А». В других случаях функционал будет описан в самом
документе, но это бывает реже, поскольку требования могут быть длинными.
В ТЗ также должно быть указано, какую форму должны иметь результаты.
Предоставляет ли интегратор веб-сайт в виде набора файлов и резервной копии
базы данных для развертывания организации? Или интегратор фактически
развертывает веб-сайт где-нибудь на сервере? Они это принимают?2
На практике постоянно ведутся споры о необходимой глубине этой
документации. На каком уровне детализации необходимо описать сайт?
Это сложно оценить количественно по той простой причине, что веб-сайт
всегда можно описать более подробно. Независимо от того, насколько вы
конкретны, вы всегда можете быть более конкретными, и какой уровень
описания является «достаточно хорошим»?
Желание описать каждый аспект веб-сайта может превратиться в черную дыру
потерянного времени, и оно часто переходит от простого определения объема к
более глубокому консультированию, поскольку технические вопросы
становятся все более подробными и на них дают все более конкретные ответы.
Интегратор проведет некоторый объем анализа без оплаты, и каждая сторона
будет ждать не так уж много времени, прежде чем им нужно будет приступить
к работе.
Где провести эту линию, варьируется для каждой организации и интегратора, и
часто это просто уровень комфорта и доверия. Когда обе стороны соглашаются,
что уровень описания достаточен и они чувствуют себя комфортно, двигаясь
вперед, они так и делают. Здесь нет жестких правил.
2Обратите внимание, что соглашения о хостинге почти всегда отделены от соглашений об интеграции.
Модель участия в размещении веб-сайта в течение длительного времени в отличие от одноразовой
интеграции делает характер соглашений совершенно иным.
Консультации по вопросам невнедрения
Иногда вы можете обратиться к интегратору по причинам,
отличным от реализации. Они могут консультировать вас,
чтобы ответить на некоторые вопросы, или оценивать
неэффективную реализацию, или, возможно, помогать вам
оценить и спланировать некоторые новые функции.
Для этих соглашений лучше всего сосредоточиться на
результатах. Что предоставляет интегратор в обмен на оплату?
Документ? Установленное количество часов анализа? Серия
телефонных звонков? Какой-то прототип кода?
Если проект не предполагает конкретной реализации, он может
быть расплывчатым и неопределенным. Четкое определение
того, что предлагает интегратор, помогает всем сторонам
понять, к какой цели движется проект.
Когда это делается?

В Техническом задании даты должны быть указаны двумя способами:
Дата начала
Когда интегратор сможет начать работу? Будьте готовы к задержке запуска
— редко у интегратора будет достаточно сотрудников, просто сидящих без
дела, чтобы они могли начать сразу. Некоторых интеграторов можно
бронировать за три-четыре месяца вперед.3
Проектпродолжительность
Независимо от того, когда он начнется, сколько времени займет проект?
Это не следует обсуждать в часах, потому что обычно это зависит от
стоимости проекта (цены проектов почти всегда оцениваются по некоторой
номинальной почасовой ставке). Скорее, вы хотите знать фактическую
календарную продолжительность. Сколько недель пройдет с даты начала
до запуска?
Целесообразно уточнить у интегратора, ориентирован ли ваш проект на дату
или на качество и функции. Есть ли у вас желаемая дата запуска, и
зафиксирована ли эта дата в камне? Должен ли интегратор планировать свою
разработку к определенной дате, несмотря ни на что, или он должен
планировать создание наилучшего конечного продукта, даже если это означает
вложение большего времени?
Сколько это будет стоить?

Очевидно, что вам нужно иметь некоторое представление о вашей
окончательной стоимости, но определить ее редко бывает просто. Стоимость
проекта может быть оценена несколькими способами:
3Если интегратор может мгновенно приступить к огромному проекту, было бы неплохо спросить,
почему. Иногда у интегратора просто оказывается удобная дыра в графике. В других случаях они
могут быть перегружены персоналом или не иметь достаточного бизнеса для поддержания себя.
Письменные соглашения |3 1 7
Фиксированная плата
Вы получите сайт X за Y, и точка. Ожидайте этого в проектах, где вы четко
определили свои требования. Если ваши требования расплывчаты и носят
исследовательский характер, единственный способ получить
фиксированную плату — это значительные дополнения (или глупость со
стороны интегратора).
Время и материалы
Интегратор выполнит работу за X долларов в час или в день. Интегратор
должен предоставить вам оценку общего количества часов. Если они этого
не делают, то вы просто соглашаетесь платить определенную почасовую
ставку, неограниченную по времени.
Платеж-ограниченный
Вы потратите X долларов, а за эту сумму интегратор получит как можно
больше функциональности.
Очевидно, что первый вариант является наиболее жестким и, следовательно,
наиболее безопасным для обеих сторон. При этом варианте объем работ и
стоимость определяются в ТЗ. Однако из-за того, что это настолько жестко, это
приводит к двум другим явлениям, которые мы обсуждали ранее: тенденции к
увеличению затрат и необходимости чрезмерно определять объем работ, что
часто приводит к задержкам.
Два других варианта более гибкие. У проекта «время и материалы» определен
объем, но стоимость не ограничена. Интегратор просто будет продолжать
работать по часам, пока работа не будет завершена. Это может быть
рискованно для организации. Проект с ограниченной комиссией имеет жесткий
лимит расходов, но не предполагает ожиданий по предоставленной
функциональности. Теоретически интегратор может достичь предела, завершив
только 50% проекта.
В конечном итоге сделки заключаются в основном вокруг распределения
рисков. Обе стороны — организация и интегратор — стараются
минимизировать свой риск. Жесткие сделки являются рискованными для
интегратора, поэтому их часто компенсируют (что предполагает определенный
тип риска для организации — риск переплаты). С другой стороны, гибкие
соглашения опасны для организации, поскольку нет четкой корреляции между
функциональностью и расходами.
Вполне возможно использовать гибридный подход. Если 90% вашего проекта
просты, рассмотрите фиксированную плату за эту часть работы. 10%, которые
являются исследовательскими и рискованными, могут быть обработаны на
разных условиях — по времени и материалам или по ограничению гонорара.
Этот метод позволяет быстро начать работу над основной частью проекта,
вместо того, чтобы откладывать весь проект, пока прорабатываются детали
более сложных разделов.
Независимо от структуры сделки необходимо определить условия и график оплаты:
• Когда наступает срок оплаты?

• Привязаны ли выплаты к этапам?

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

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

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

Какими будут ваши отношения с командой проекта? Хотя работа с удаленной
командой является обычным явлением, другие фирмы могут использовать
модель увеличения штата, когда разработчики приходят к вам на сайт и
работают внутри компании.
Производство | 319
Это становится все более редким и почти всегда ненужным, но некоторым
организациям это требуется. В некоторых организациях требования к
безопасности настолько строгие, что доступ контролируется вплоть до
географического местоположения (это довольно распространено в банковском
деле и финансах). В других случаях коду, возможно, придется тесно
взаимодействовать с другими частями инфраструктуры организации,
доступными только в ее сети.
Определите свою близость к команде. Если они прибудут на объект, есть ли у
вас для них физические условия? Не один проект начинался неловко, потому
что никто не подумал спросить, где будет сидеть команда проекта, пока они
находятся в здании.
Кроме того, в какой степени производственная группа предана конкретно
вашему проекту? Вы нанимаете их на полный рабочий день или делитесь ими с
другими клиентами? Можете ли вы ожидать, что они всегда будут работать над
вашим проектом?
Если не указано иное, предположите, что производственная группа работает не
только над вашим проектом. Таким образом, вы обычно не можете
контролировать их рабочий график или процесс на микроуровне.
Разработка и ТестированиеИнфраструктура
Где будет находиться незавершенная работа и какой у вас будет к ней доступ?
Разработчики обычно работают на своих локальных рабочих станциях и через
регулярные промежутки времени развертывают код в среде интеграции. Кто
контролирует эту среду? Это будет в вашей инфраструктуре или на сервере,
контролируемом интегратором?
Где будет храниться исходный код? Интеграторы обычно хранят исходный код
в своей среде, но в какой момент он должен передать его вам? Кроме того,
какой уровень прозрачности у вас есть в системе управления исходным кодом?
Вы можете проверить его в любое время?
Как вы записываете проблемы? Во время разработки вы можете сообщить о
проблеме, но вам скажут, что она будет решена позже. Как отслеживается эта
проблема? Существует ли система управления билетами или вики, где можно
отслеживать эти предметы, чтобы они не ускользнули? Если ваши опасения
где-то не записаны, вероятность того, что производственная группа запомнит
каждую из них и проактивно вернется обратно, весьма мала.
Коммуникация и регистрация проекта

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

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

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

выделенный менеджер проекта? Если у вас есть опасения, с кем вы можете
связаться и как эта проблема будет обостряться, если вы не будете
удовлетворены результатом? Каков будет ваш уровень случайных,
внеплановых контактов с командой разработчиков? Можете ли вы внезапно
позвонить разработчику? Будете ли вы иметь доступ к разработчикам
напрямую по электронной почте или посредством мгновенных сообщений?
Интеграторы обычно ограничивают прямой доступ к разработчикам. Это
делается не для того, чтобы усложнить работу, а просто для того, чтобы
ограничить перерывы, которые могут оказаться губительными для
производительности. Вы можете подумать: «Ну, это всего лишь быстрый
вопрос», но когда это происходит с несколькими клиентами, несколько раз в
день, это становится серьезным препятствием для прогресса.4
Приемка работ и контроль качества

В какой-то момент интегратор выставит счет за проект, который зависит (явно
или неявно) от того, примет ли организация рабочий продукт. Что делает это
4Программисты обычно пытаются достичь идеального состояния «потока», когда они находятся в зоне
действия и добиваются необычайных успехов. Это явление хорошо известно и широко
распространено в программировании, а прерывания ему противоречат. Возможно, стоит прочитать
основополагающую статью об этой концепции:«Поток: психология Оптимальный опыт» Михай
Чиксентмихайи.
процесс выглядит? Это может быть тесно переплетено с методологией и
стилем разработки, которые использует интеграционная фирма.
Чтобы описать свою деятельность, многие команды разработчиков используют
термин «гибкая». Этот термин имеет смысл только при рассмотрении того, как
создавалось программное обеспечение.
В прошлые годы при разработке программного обеспечения использовалась
так называемая методология «водопада». Процесс разработки шел по
последовательному ряду задач. Точно так же, как вода не может снова
подняться и упасть водопадом во второй раз, каждая задача строится на первой,
медленно и неуклонно продвигаясь вперед. В результате программный продукт
имел тенденцию не складываться до самого конца процесса. Возможно, пока
проект не был почти завершен, смотреть было не на что.
Проблема здесь должна быть очевидна: если ничего не видеть, как узнать,
хорошо ли собран продукт? Огромная проблема может быть обнаружена
только после тестирования конечного продукта, и тогда уже будет слишком
поздно что-либо менять.
В 2001 году группа инженеров-программистов выпустила то, что они
назвали«Гибкий мани- фесто, это было заявлением о том, что старая
методология не работает должным образом. В манифесте 12 принципов, но
первый из них является ключевым:
Нашим высшим приоритетом является удовлетворение потребностей клиентов
посредством своевременной и непрерывной поставки ценного программного
обеспечения.
Это ключ к гибкой разработке программного обеспечения: выполняйте работу
как можно раньше и чаще. Передайте что-то клиенту как можно скорее,
независимо от того, насколько оно грубое или урезанное, затем соберите
отзывы и повторите процесс. Совершенствуйте продукт с течением времени,
используя отзывы клиентов как неотъемлемую часть процесса.
Термином «гибкий» злоупотребляют (и его часто используют разработчики,
слишком молодые, чтобы даже иметь дело с «негибким» процессом), но его
следует принять как стандартную практику. Ключевым моментом для
интегратора является избежание синдрома «заползания в пещеру», когда вы
создаете веб-сайт так, чтобы вы его не видели, до самого запуска.
Еще в 1999 году мы с моим деловым партнером создали веб-

сайт для футбольной команды НФЛ. Отдел маркетинга
команды одобрил проект дизайна, а затем в течение
нескольких месяцев больше ничего не видел. Я помню
телефонный звонок за неделю до запуска сайта, в котором
клиент сказал: «Сайт уже создается, верно?» Впервые они
обратили на это внимание за несколько дней до того, как мы
изменили DNS, чтобы совпасть с запланированной
маркетинговой кампанией, которую нельзя было откладывать.
Я представляю это как хрестоматийный пример того, чего не
следует делать.
С практической точки зрения вам необходимо знать, как часто вам будет
предоставляться возможность проверять и выносить суждения о рабочем
продукте. В ходе проекта должно быть запланировано время, когда части
конечного продукта будут предоставляться для вашей проверки.

Обычно они совпадают с выставлением счета. На этих этапах вас часто будут
просить проверить, утвердить и официально принять рабочий продукт.
В связи с этим, в какой момент вы официально «вступаете во владение»
рабочим продуктом? Вероятно, это связано с окончательным расположением
кода. Если код предназначен для развертывания в вашей среде, интегратор
может заявить, что это происходит при развертывании, но ситуация становится
еще более мрачной, когда код должен размещаться у самого интегратора или у
третьей стороны. В какой момент вы заявляете, что рабочий продукт приемлем
и соответствует соглашению? Это должно быть четко определено заранее.
Заранее определите необходимый вам уровень контроля качества. Будете ли вы
требовать от интегратора разработки формальных сценариев тестирования и
предоставления вам результатов для каждой итерации, включая регрессии
предыдущих тестов? Или вы просто поверите интегратору на слово, что все
работает нормально? Хотите увидеть код? Хотите ли вы получить информацию
на уровне строки для принятия решений по кодированию? Разным
организациям требуются разные уровни контроля качества и документации, и
пусть это не станет сюрпризом, когда придет время принимать работу. Если вы
возлагаете большие надежды на формальный контроль качества, интегратор
должен знать об этом, чтобы он мог включить это в свою сферу деятельности.
Разработка контента
Весьма вероятно, что проект внедрения изменит ваш сайт таким образом, что
потребуются изменения в контенте. Контент придется реорганизовать или
создать новый контент. И это не учитывает весь контент, который придется
перенести.
Кто будет вносить эти изменения или создавать этот контент? Вы платите
интегратору за эти изменения? Вы платите другой фирме? Или вам нужно
внести эти изменения самостоятельно?
Масштабы разработки контента часто недооцениваются организацией и, как
следствие, задерживаются. Многие веб-сайты уже завершены и простаивают
месяцами в ожидании необходимых изменений контента. «Мы запустим, как
только приведем в порядок контент» — распространенный рефрен.
Определите, что необходимо сделать с вашей стороны перед запуском, и
выделите для этого персонал и ресурсы. Убедитесь, что время четко указано.
Когда ваш контент должен быть завершен и в каком состоянии он должен
быть? Можете ли вы ввести его непосредственно на разрабатываемый веб-сайт,
или вам нужно будет разместить его в каком-то нейтральном месте, например в
Google Docs, или в службе, специально предназначенной для этого,
напримерСбор контента? Не один интегратор прямо перед запуском получил
неожиданный ZIP-файл с сотнями документов Word с пометкой: «Вот весь наш
контент. Дайте нам знать, когда он появится в системе!»
В этой отрасли (и во многих других, я уверен) ходит шутка о том, что «эта
работа была бы отличной, если бы не клиенты». Хотя явно черный юмор,
поймите, что самый большой
угрозой вашему проекту на самом деле можете быть вы. Убедитесь, что в
процессе внедрения у вас есть собственные основы.
Не Быть ЧТОКлиент
У каждого интегратора есть десятки страшных историй о
клиентах, которые медлили с выполнением каждой
поставленной перед ним задачи. Независимо от того,
насколько четко интегратор понимает, что и когда необходимо
сделать, некоторые клиенты никогда не выполняют свою часть
сделки.
Хуже того: когда клиент наконец получает то, что должен был
предоставить, он ожидает, что интегратор бросит все и
немедленно вернется к своему проекту. Эти клиенты не
понимают, что интегратору следует избегать дыр в графике, и
когда становится очевидно, что клиент не сможет выполнить
поставленную задачу, их исключают из производственного
графика.
Всегда помните, что у вашего интегратора есть и другие
клиенты. Если вы приведете к остановке вашего проекта,
ожидайте, что интегратордвигаться дальше. Когда и если вы
наконец справитесь, ожидайте, что вас ждет задержка, пока вы
вернетесь в их производственный график.
Обучение и поддержка
Как мы обсуждали вГлава 12Обучение и поддержка могут быть непростыми,
поскольку веб-сайт часто представляет собой комбинацию программного
обеспечения поставщика и реализации интегратора.
Планируя обучение, определите, кому в вашей организации необходимо
пройти обучение и на каком уровне. Сколько людей должны знать основные,
основополагающие принципы программного обеспечения CMS? С другой
стороны, скольким людям не нужно знать ничего, кроме того, что нужно для
выполнения работы?
Большинство интеграторов не будут проводить базовое, фундаментальное
обучение по той причине, что поставщики используют обучение как источник
дохода. Поставщики зарабатывают деньги на обучении и не одобряют
интеграторов, предлагающих формализованные курсы обучения по их
программному обеспечению в качестве конкурентов.
Большинство поставщиков предлагают обучение по одной или нескольким из нескольких
моделей:
На месте
Тренер от поставщика приезжает в вашу организацию, что подходит для
обучения больших групп.
Хостинг
Ваши сотрудники прилетают к месту расположения поставщика (либо к
своему фактическому местоположению, либо к удаленному месту, из которого
они проводят обучение в определенное время); Это

целесообразно обучать меньшее количество людей, чем было бы оправдано
прибытием тренера.
Удаленный
Поставщик проводит онлайн-курс обучения, обычно в режиме реального
времени, для группы участников.
В отличие от базового обучения, обучение внедрению может обеспечить
только интегратор. Наиболее эффективное обучение, вероятно, представляет
собой смесь того и другого, хотя участники, возможно, должны быть готовы
отказаться от некоторых принципов обучения поставщиков при прохождении
тренинга по внедрению («Я знаю, они говорили вам, что это работает именно
так, но на самом деле мы реализовали именно так). это…").
Как и обучение, поддержка становится вопросом юрисдикции между
поставщиком и интегратором. Если возникают проблемы, связаны ли они с
программным обеспечением (поставщик) или реализацией (интегратор)?
Активно управляемый работающий веб-сайт также учитывает переменные
среды хостинга и самих редакторов. Существуют десятки комбинаций
переменных, которые могут быть источником любой конкретной проблемы.
Существует четыре основных типа поддержки, которую интегратор может
предоставить организации:
Поддержка во время простоя
В таких ситуациях сайт значительно и явно поврежден по какой-то
причине, которую редактор не может исправить. К счастью, критические
ошибки программного обеспечения в основных продуктах CMS
относительно редки. Большинство продуктов тестируются до такой
степени, что явные, бросающиеся в глаза ошибки встречаются нечасто.
Когда такая проблема все же возникает, она часто связана с
инфраструктурой (жесткий диск переполнен, DNS не работает, сервер базы
данных перестал работать и т. д.).
Ошибкаподдерживать
В таких ситуациях пользователь столкнулся с ошибкой, которая может
быть или не быть общедоступной (она может быть видна только
редакторам). Пользователь выполняет задачу правильно, но что-то в ПО
явно дало сбой. Редактор не может решить эту проблему и нуждается в
сторонней помощи.
Пользовательподдерживать
Иногда ошибки нет, но редактор не знает, как выполнить конкретную,
определенную задачу, которую, по его мнению, он должен выполнить.
Зачастую это происходит из-за недостаточной подготовки.
Консультационная поддержка
Опять же, в этих случаях ошибки нет, но редактор хочет достичь более
крупной и системной цели и не знает, как лучше всего это сделать. Это
меньше
Обучение и поддержка | 325
поддержка и дополнительные советы. Редактору необходимо знать
наиболее оптимальный путь для достижения какой-то более крупной цели.
Последние два типа — поддержка пользователей и консультационная
поддержка — могут оказаться непростыми, поскольку границы между
поддержкой, обучением и консультированием могут быть размытыми. В какой
момент это становится не столько вопросом поддержки, сколько вопросом
консультирования, когда интегратора просят объяснить основополагающие
концепции управления контентом и веб-разработки, а также помочь
организации в планировании новых функций? К тому же, в какой момент
становится очевидным, что некоторые просто не обратили внимания во время
обучения, а интегратор в десятый раз объясняет одно и то же? Эти разговоры
могут стать неловкими.
Как и в случае с процессом определения объема работ, интегратор может
сделать лишь ограниченный объем работы без оплаты. Границу между тем, что
считается поддержкой, и тем, что считается консультацией или
дополнительным обучением без рамок, может быть сложно провести.
В сфере профессиональных услуг становится довольно распространенным
заключение соглашений типа гонорара, согласно которым организации платят
ежемесячную плату за доступ к команде разработчиков и консультантов по
мере необходимости. Как правило, это часы по принципу «используй или
потеряй», которые обеспечивают разовый доступ к экспертным услугам, но не
переносятся между периодами. Даже если такая поддержка не требуется в
долгосрочной перспективе, все равно весьма полезно иметь такой доступ в
течение нескольких месяцев сразу после запуска, когда неизбежно возникнет
большинство вопросов и проблем.
А ФиналСлово
Хотя было бы идеально, если бы отношения между организацией и
интегратором были совершенно деловыми и свободными от межличностных
проблем, это никогда не бывает так. Организация и интегратор (и, в меньшей
степени, поставщик) будут тесно сотрудничать, обычно в течение длительного
периода времени. В некоторых случаях эти отношения могут растянуться на
годы после запуска.
В таких отношениях со временем в игру вступит человеческий фактор.
Организационная политика может и будет оказывать влияние на проект.
Команды разработчиков в организации могут быть возмущены приходом
внешнего поставщика, команды маркетинга могли иметь неудачный опыт в
прошлом, или интегратор может быть не в состоянии игнорировать свое
восприятие неискушенного мышления организации.
Один друг однажды заметил, что «некоторые из самых детских

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

Джо Кепли
Я работаю в сфере консалтинга около пятнадцати лет и
обнаружил, что, как и любые отношения, отношения между
интегратором и клиентом процветают на взаимном доверии
и уважении.
В лучших отношениях с клиентами мы работаем с
клиентом достаточно долго, чтобы хорошо понимать его
бизнес. Наша команда доверяет клиенту знать свой бизнес,
и они доверяют нам предоставить
отличный опыт работы с CMS. Когда возникает проблема, мы решаем ее
вместе, заботясь об интересах друг друга, потому что мы все считаем себя
частью одной команды.
Отношения, которые не работают, как и любые другие отношения, — это те, в
которых одна сторона хочет выжать максимум из другой стороны и перейти к
чему-то другому. У нас были клиенты, которые ясно давали понять, что мы
являемся средством достижения цели, чувствовали, что наше время или советы
должны быть бесплатными, или просто хотели использовать нас в качестве
рычага против внутренней команды.
Эксперты по CMS редки, и если Blend как организация постоянно подвергает
нашу команду группам, которые готовы их измельчать или игнорировать их
советы, мы говорим им, что они не важны. Если мы готовы продолжать
ввязываться в отношения с клиентами, которым мы не подходим, мы говорим,
что счет имеет большую ценность, чем успех проекта.
Как фирма, предоставляющая профессиональные услуги, мы потратили годы на
создание команды экспертов по CMS. Эта команда — самый ценный актив
нашей компании. Мы обязаны как нашим клиентам, так и нашим сотрудникам
максимизировать здоровые отношения и свести к минимуму нездоровые.
Когда у нас есть клиент, который ценит нашу работу и наш вклад, участвует в
его решении, уделяя время общению, и относится к нам как к надежному
партнеру, мы делаем все возможное, чтобы убедиться, что у него отличный
сайт и отличный опыт работы с нами. Каждая группа, как со стороны клиента,
так и со стороны интегратора, должна работать вместе для развития этого
процесса.
Джо Кепли — технический директор Blend Interactive, компании, занимающейся интеграцией CMS..
Последнее слово | 327
ГЛАВА15
Где Содержание Управление
ЯвляетсяИдущий
Управление веб-контентом постоянно находится в состоянии изменения. Как

дисциплина, она опирается на сам Интернет, и по мере изменения интернет-
ландшафта вместе с ним меняется и управление контентом.
При написании этой книги мне пришлось провести размытую грань между тем,
какие аспекты управления контентом являются основополагающими и вряд ли
изменятся (например, моделирование контента), и тем, какие аспекты все еще
определяются рынком (автоматизация маркетинга и персонализация). , назовем
лишь два). Через пять лет некоторые части этой книги будут по-прежнему
полностью актуальны, другие части устареют, и потребуется добавить
полдюжины новых глав.
В качестве упреждающего удара я хотел бы заглянуть немного вперед и
подумать, куда может направиться управление контентом в будущем. Это
практическое упражнение: я хочу, чтобы вы были готовы к тому, что может
произойти за углом, но это также упражнение в перспективе, поскольку я хочу,
чтобы вы поняли оси и переломные точки, по которым эта отрасль может
расширяться. , чтобы дать вам некоторое представление об эластичности
управления контентом – отрасли, программного обеспечения и дисциплины.
Такие главы трудно писать, потому что они всегда представляют собой
комбинацию обоснованных предсказаний, документирования очевидного и
неизбежного поворота разговора в том направлении, в котором автор хотел бы,
чтобы что-то развивалось. Хотя я думаю, что доказательства существуют для
всех следующих предсказаний, только время покажет, насколько они точны.
Через пять лет я вполне готов к тому, что кто-то найдет меня на конференции и
высмеет, насколько неправы оказались некоторые из них.
Кроме того, подобные прогнозы неизбежно предполагают обращение к
истории и интерпретацию того, что произошло в отрасли. Здесь будут видны
мои предпочтения и мнения. Если у вас большой опыт работы в этой отрасли,
вы
329
без сомнения, не согласен с моей точкой зрения на некоторые из предыдущих
событий. Всё, что сказано, давайте посмотрим…
Меньше Открыть Источник CMS Воля ПолучатьТяга

Рынок CMS с открытым исходным кодом уже переполнен. Я долгое время
утверждал, что разработчикам нравится создавать новые платформы CMS
больше, чем любой другой тип программного обеспечения. Во многом это
связано с быстрым временем запуска (многое можно сделать за короткий
период времени, прежде чем развитие неизбежно пойдет вверх), но это также
связано с привлекательностью фреймворка.
Разработчики просто любят писать фреймворки. Нам нравится решать
проблемы, которые остаются теоретическими. И это, по сути, то, что делает
CMS: она решает проблему, которой еще не существует. Когда-нибудь
созданная нами CMS обязательно решит реальную проблему. Но изначально
это всего лишь фреймворк для веб-сайта, и разработчик получает всю радость и
прилив эндорфинов от «решения» этой проблемы, в то время как связанные с
ней проблемы остаются благополучно гипотетическими. Это все весело и
никакой ответственности.
Десять лет назад казалось, что каждую неделю запускалось ошеломляющее
количество проектов с открытым исходным кодом, каждый из которых
претендует на какой-то новый взгляд на проблему контента. Время от времени
кто-то мог зацепиться за коллективное внимание разработчиков CMS и
проложить себе путь к какой-то известной пользовательской базе. Все
остальные отпадут.
Но даже получить эту первоначальную точку опоры становится все труднее и
труднее. На рынке доступно так много продуктов, что разработчики, похоже,
прибегают к так называемому защитному механизму. Существующие системы
с открытым исходным кодом оказывают своего рода гравитационное
притяжение, привлекая все больше и больше разработчиков, но постепенно
становятся все больше и больше, что позволяет им привлекать еще больше
разработчиков.
Очень немногие новые платформы с открытым исходным кодом получили
распространение за последние пять лет, особенно по сравнению с пятью
годами ранее. Такие системы, какБетон5 иПроцессПровод еще молоды, но
сумели объединить энергичные и преданные своему делу сообщества.
Напротив, предложение CMS с открытым исходным кодом от
Microsoft,фруктовый сад, не смог завоевать большую популярность или
признание, даже несмотря на гигантское сообщество разработчиков ASP.NET
MVC, из которого можно было бы извлечь пользу, и относительно небольшое
количество вариантов с открытым исходным кодом в этой области. И есть
десятки других новых участников, которые просто никогда не достигнут
критической массы.
То, что поддерживает и развивает проект с открытым исходным кодом, — это
способность привлекать разработчиков, а волнение по поводу новой системы
быстро умеряется отсутствием сообщества и установленной базы, в которой
система могла бы расти и тестироваться.
Что приведет к рождению новых систем, так это принятие новых веб-
фреймворков. Каждый раз, когда новый язык или парадигма программирования
набирает обороты, несколько проектов с открытым исходным кодом возникают
из ранних проектов, написанных для этих платформ.
330 | Глава 15: Куда движется управление контентом

На момент написания статьи новым фаворитом веб-разработчиков является
Node.js. Без сомнения, в ближайшие годы мы увидим несколько вариантов
CMS для этой платформы, и эти платформы будут иметь преимущество перед
немногими конкурентами. Они тонут или плывут в зависимости от принятия
базовой платформы — если она засохнет, то же самое произойдет и с ними.
Я ни в коем случае не предсказываю, что развитие CMS с открытым исходным
кодом полностью иссякнет, но просто остается все меньше и меньше
оснований бросать кости на новую систему. В то время как некоторым
разработчикам, как правило, нравится быть противоречивыми и
иконоборческими, большинство других будут просто соблазнены множеством
плагинов и поддержки, доступных для более крупных платформ.
Развязка вернется
Разделенные CMS создали Интернет. Когда я впервые пришел в эту отрасль, у
нас даже не было термина «CMS». У нас почти не было термина «контент».
Как я отметил в предисловии, у нас просто лежала куча файлов, и мы были
вынуждены управлять ими по чистой необходимости.
Некоторые из первых CMS фактически представляли собой просто наборы
скриптов Perl, которые шаблонизировали данные и упрощали управление
агрегатами. Movable Type — одна из первых платформ для блогов, запущенная
в 2001 году, — представляла собой основанную на Perl систему сценариев,
генерирующую статический HTML.
Но развязанные CMS страдали от необходимости в активной среде доставки.
Потребность в интерактивности в реальном времени (доски объявлений,
комментирование, рейтинги) никогда не подходила для статических файлов.
Поскольку веб-сайты становились все более разнообразными, требовался
немедленный доступ к репозиторию, а концепция четко определенного
«момента публикации» становилась все более и более размытой. Небольшие
изменения в среде доставки (комментарий, оценка и т. д.) требовали полной
повторной публикации, что становилось проблематичным.
Со временем в среду доставки добавлялось все больше и больше функций, пока
новым разработчикам не стало очевидно, что контентом следует управлять и
там. При этом разделенные архитектуры начали приходить в упадок.
В то же время управляемые веб-сайты становились все меньше и меньше. Хотя
CMS использовались на более крупных сайтах, многие небольшие веб-сайты
по-прежнему управлялись с помощью клиентских редакторов, таких как
Microsoft FrontPage и Adobe Dreamweaver. Когда CMS начали фильтровать
вниз, в сети появилось поколение сайтов, которые не могли страдать от
сложностей развязки и требовали новейшей интерактивности на стороне
доставки. Это еще больше стимулировало внедрение связанных платформ
CMS.
Но ситуация постепенно возвращается вспять. Судя по всему, произошло то,
что интерактивность, необходимая в среде доставки, стала отделена от CMS —
теперь ее могут обслуживать системы, которым может вообще не
потребоваться взаимодействие с CMS. Добавить комментарий на веб-сайт
теперь так же просто, как использовать подключаемую систему, например
Развязка вернется |3 3 1
Disqus, IntenseDebate или даже Facebook. Клиентские технологии продвинулись
до такой степени, что интеграция с платформами социальных сетей
осуществляется просто с помощью JavaScript. Поставщики средств
автоматизации маркетинга могут интегрироваться исключительно на стороне
клиента, и даже A/B-тестирование доступно практически без изменений
шаблонов.
Это означает, что богатый и разнообразный пользовательский интерфейс
теперь может размещаться «поверх» статических HTML-файлов. HTML-
файлы, содержащие контент, просто служат основой для ошеломляющего
набора интерактивных возможностей, предоставляемых другими сервисами.
Большинство клиентских технологий не знают и не заботятся о том,
существуют ли их HTML-хосты в файлах, записанных на диск 10 лет назад или
сгенерированных на лету миллисекунду назад.
Еще дальше по этому пути отношения между контентом, генерируемым
сервером, и клиентскими технологиями могут оказаться на грани полного
переворота. Полнофункциональные JavaScript-фреймворки, такие как
AngularJS, React и Dojo, порождают «одностраничные приложения», в которых
клиенту доставляется вовсе не контент, а приложение, которое запускается в
браузере и может получать контент в зависимости от пользователя. поведение.
В таких ситуациях вместо контента, доставляющего функциональность
клиента, мы имеем прямо противоположное — функциональность клиента
доставляет контент. По сути, мы устанавливаем в браузер механизм шаблонов
и вывода каждый раз, когда посетитель заходит на сайт.
Все эти изменения сводят на нет некоторые существенные преимущества
связанных CMS. Удаление функций после публикации, а иногда даже
шаблонов, оставляет редакционное ядро, которое может выжить так же
хорошо, как и отдельная система, и может быть для нее даже лучше.
Как отмечено вГлава 9Отдельная публикация дает уникальные преимущества с
точки зрения масштабируемости, стабильности и безопасности. Среды
доставки становятся все проще создавать и поддерживать. Amazon Web
Services позволяет размещать статический контент из платформы хранения
Amazon S3, и парой щелчков мыши его можно интегрировать в CloudFront,
сеть доставки контента. Объедините это с отдельной CMS, и вы буквально
получите практически бесконечно масштабируемую среду для размещения
контента для оптимизированной доставки по всему миру за пять минут. (Для
разработчиков, работающих в этой области с середины 90-х, это просто
поражает воображение.)
Мы вполне можем увидеть, как CMS возвращается к своему ядру, которое
традиционно заключалось в моделировании, управлении и агрегировании
контента. Когда и если это произойдет, развязка сыграет огромную роль в
сложившейся ситуации.
The Рост из Статический СайтГенераторы
Новая волна генераторов статических сайтов в сочетании с
грид-хостингом является интересной разработкой.1 Сейчас
существует множество инструментов командной строки для
шаблонирования и сборки контента, хранящегося в плоских
файлах, обычно в Markdown. Полученный HTML-код затем
передается в среду хостинга.
Некоторые инструменты даже превращают сайты на базе CMS
в статические. У вас может быть сайт Drupal или WordPress на
вашей локальной рабочей станции или за корпоративным
брандмауэром, и эти инструменты подключаются к нему и
«сглаживают» его в статический HTML для размещения в
другом месте.
Подобные инструменты эффективно превращают связанные
CMS в несвязанные. Все редакционные функции по-прежнему
используются для моделирования, управления, агрегирования
и шаблонирования контента, но функции доставки отменяются
в пользу всех других преимуществ, которые обеспечивает
развязка.
Фокус на маркетинговых инструментах и интеграции будет

возрастать
Два года назад я посетил сетевое мероприятие для профессионалов CMS на
Восточном побережье. Одним из докладчиков был менеджер по веб-
маркетингу сервисной компании, который пришел объяснить, как они
обрабатывают свой контент. В течение часа он подробно описывал
замечательный процесс и методы, которые они использовали для мониторинга,
персонализации, доставки и оптимизации своего контента. Было очевидно, что
его команда находилась в центре огромного внимания и бюджета этой
Мне было интересно узнать, какую CMS они использовали, поддерживающую
такой уровень оптимизации маркетинга. Когда я спросил, он упомянул имя
поставщика автоматизации маркетинга. Я знал, что этот конкретный
поставщик не является поставщиком CMS, поэтому я спросил его, какую
платформу управления контентом они используют.
Он просто не знал. Он объяснил, что редакционная группа уведомила его о том,
как выглядит календарь контента, чтобы его команда могла подготовиться, а
затем предоставила URL-адрес непосредственно перед публикацией этого
контента. Он понятия не имел, как управляется и создается контент. Ему и его
команде не нужно было знать.
Я уже отмечал, что многие организации ищут не столько систему управления
контентом, сколько систему контент-маркетинга. Факт
1Видетьhttps://www.staticgen.com полный список этих инструментов.
Фокус на маркетинговых инструментах и интеграции будет возрастать |3 3 3

То есть большинство корпоративных веб-сайтов не так уж и часто обновляются
— скорость их содержания чрезвычайно низкая, и контент может меняться
максимум раз в месяц.2
Однако, даже несмотря на то, что контент может быть не новым, большинство
взаимодействий пользователя с ним являются новыми. Эта страница,
объясняющая особенности продукта, возможно, не менялась на веб-сайте в
течение двух лет, но Боб смотрит на нее впервые, и этот сценарий повторяется
сто раз на день.
Каждая комбинация посетитель + контент — это совершенно новый опыт,
которым необходимо управлять. Возможно, мы не будем менять контент, но
нам необходимо оптимизировать взаимодействие с ним этого посетителя с
помощью арсенала инструментов маркетинга и оптимизации, таких как
персонализация, A/B-тестирование и прогнозная аналитика.
Как отрасль отреагирует на эту потребность с течением времени, еще
неизвестно. Есть два лагеря:
• Сделайте это внутри самой системы, разработав крупные пакеты

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

варианте. Они готовы оставить автоматизацию маркетинга
специализированным поставщикам и сосредоточить свои системы на
управлении.
Коммерческие поставщики хеджируют свои ставки в обоих случаях. Многие
создают маркетинговые пакеты внутри своих систем. Хотя некоторые
утверждают, что это необходимо для обеспечения высокого уровня интеграции
между менеджментом и маркетингом, следует предположить, что они просто
видят другой рынок и источник дохода, который можно захватить. В то же
время большинство коммерческих поставщиков также предлагают интеграцию
с популярными поставщиками средств автоматизации маркетинга.3
Мы можем наблюдать, как коммерческие поставщики продвигаются все
дальше и дальше на этот рынок, пока не станет очевидно, что их превзойдут
специализированные поставщики средств автоматизации маркетинга, которым
не нужно беспокоиться об основных функциях управления. Когда это
произойдет, некоторые поставщики средств управления, скорее всего,
приобретут маркетинговые платформы, другие будут тратить меньше средств
на собственные системы и больше на интеграцию, а некоторые избранные
2В процессе написания веб-сайт этой книгиhttp://flyingsquirrelbook.com, представляла собой одну

страницу кон‐палатке почти год и менялся только за счет добавления названий глав по мере их
написания. Контента просто не было, и вся цель веб-сайта заключалась в том, чтобы направить
посетителя на страницу заказа на веб-сайте О'Рейли.
3Стоит отметить, что некоторые из этих «интеграций» смехотворно слабы. Один коммерческий
поставщик предложил плагин для инструмента A/B-оптимизации. После установки стало очевидно,
что единственное, что делал этот плагин, — это добавлял одну ссылку JavaScript вверху каждой
страницы, на добавление чего-то вручную разработчику шаблона ушло бы 10 секунд.

могут разделить свои маркетинговые платформы на отдельные продукты и
сосредоточить свои усилия на основном управлении.
SaaS начального уровня съест нижнюю часть рынка

ВГлава 3Я выразил скептицизм по поводу чисто мультиарендных SaaS-
предложений на верхнем уровне рынка, где клиентам требуется серьезная
настройка. Тем не менее, рынок SaaS начального уровня, похоже, процветает и
будет продолжать встряхивать этот конец спектра CMS.
Под «начальным уровнем» я подразумеваю продукты SaaS, которые обычно
можно настроить, используя только кредитную карту и некоторую личную
информацию. Такие сервисы, как Squarespace и Wix, пользуются
популярностью в этой сфере уже много лет, не говоря уже о платформах для
ведения блогов, таких как WordPress, которые можно без особых проблем
перепрофилировать в базовые, ограниченные CMS.
Эти системы поглотят нижнюю часть рынка CMS, поскольку организации
решат, что этот уровень управления достаточно хорош, и сосредоточат свой
бюджет и персонал на оптимизации маркетинга с использованием многих
платформ, инструментов и методологий, обсуждавшихся ранее.
Да, функциональность этих систем, несомненно, ограничена, но они все равно
превысят потребности многих организаций, или же от более требовательных
организаций откажутся или отложат их в условиях непосредственной
доступности и низкой стоимости платформ.
Благодаря этим вариантам начального уровня, имея не более чем кредитную
карту, пару часов и некоторое знание рынка, организация может получить
простую платформу веб-сайта и обширный маркетинговый пакет (который, по
общему признанию, все еще требует быть визуально тематическим и
наполненным контентом, но эту задачу необходимо выполнить независимо от
того, как на самом деле приобретается веб-сайт).
Ключом к успеху этих платформ будет способность сбалансировать
потребности широкого круга пользователей. Будут вышеупомянутые
организации, которым «просто нужен веб-сайт», но неизбежно будет также
группа, которая потребует все большей и большей настройки. По мере
развития этих систем способность сбалансировать эти группы (предоставляя
последним все больше и больше возможностей настройки, не делая платформу
слишком дорогой для первых) будет стимулировать или уничтожать принятие.
Помимо простого принятия пользователями, эти платформы переопределяют
функциональность. Ранее мы говорили об «эффекте Google», который
определяет наши ожидания от работы поисковых платформ. Возможно,
«эффект WordPress» — это то, что определяет наши ожидания относительно
того, как должны работать CMS.
SaaS начального уровня съест нижнюю часть рынка |3 3 5

Я предполагаю, что продавцам-поставщикам придется реорганизовать свои
отделы продаж по мере развития платформ начального уровня. Например,
когда WordPress наконец начал предлагать управление версиями, это больше не
было конкурентным преимуществом для систем стоимостью десятки тысяч
долларов. Это начнет происходить на рынке SaaS начального уровня.
Поставщикам придется переориентировать свои системы и процессы продаж на
то, что они предлагают за пределами этих платформ.
Система, которая сегодня стоит 15 долларов в месяц, очень похожа на систему, которую вы
могли бы заплатить.
30 000 долларов десять лет назад. Это здорово. Клиенты со скромным
бюджетом не только получают больше функциональности, но и толкают
отрасль вперед. Отсутствие динамичного рынка начального уровня приводит к
стагнации поставщиков более высокого уровня.
Многоканальный Распределение ВоляУвеличивать

В течение многих лет продавцы на словах поддерживали многоканальную
публикацию. Они утверждали, что их системы будут публиковать контент по
многим каналам распространения (подмигиваем, подмигиваем), но они знали,
что средний пользователь никогда не создаст с их помощью более одного веб-
сайта.
Однако развитие социальных сетей привело к возникновению проблемы
многоканального использования. Создаются огромные объемы контента,
который никогда не увидит внутреннюю часть веб-сайта организации. Этот
контент будет проводить весь свой жизненный цикл на сторонних
размещенных платформах распространения. Facebook, Twitter и Pinterest — это
огромные маркетинговые и коммуникационные каналы, и некоторые
организации могли бы просто полностью отказаться от официального веб-сайта
и осуществлять маркетинг исключительно через эти каналы. 4 Но этим
контентом все равно нужно управлять.
Мы наблюдаем рост популярности «CMS для социальных сетей» в виде
платформ управления обновлениями в социальных сетях. Такие платформы,
как Hootsuite, Buffer и TweetDeck, абстрагируют создателей контента от
реальных платформ, позволяя создавать контент и управлять им в
централизованных приложениях. Граница между этими и более
традиционными CMS становится все более размытой.
В будущем мы, вероятно, увидим, что все больше поставщиков будут поощрять
управление социальными сетями с помощью своих основных продуктов CMS.
Некоторые сделали это с помощью надстроек и подсистем, но другие будут
придерживаться более «чистого» подхода, при котором обновление
социальных сетей рассматривается как объект контента, как и любой другой, с
учетом рабочего процесса, разрешений, аудита и т. д. .Когда контент
публикуется, он не появляется на веб-сайте; он просто внедряется в различные
платформы социальных сетей через различные API.
4Несколько лет назад среди небольших организаций наблюдалась огромная тенденция использовать
Facebook в качестве официального веб-сайта и иметь доменное имя, просто перенаправляющее на
страницу Facebook. В то время Facebook, по сути, позволял организациям создавать статические веб-
сайты в качестве своих страниц в Facebook. Однако эта архитектура была изменена, чтобы сделать
страницу в стиле временной шкалы с постоянным последовательным контентом. После этого
изменения платформа стала менее привлекательной, и тенденция потеряла актуальность.

Социальные сети — лишь один из многих каналов. Отделы маркетинга быстро
освоили микросайты, где создается множество небольших веб-сайтов для
поддержки рекламных кампаний. Хотя этими сайтами часто можно управлять с
помощью одной и той же CMS, сложности и накладные расходы (не говоря уже
о потенциальных расходах на лицензирование) могут побудить организации
создавать статические веб-сайты или использовать меньшие платформы SaaS и
передавать на них выбранный контент из своих основных CMS.
И хотя массовое использование RSS продолжает (к сожалению) уменьшаться,
RSS по-прежнему остается ценным механизмом распространения контента.
Многие платформы и системы используют RSS-каналы, и можно представить
себе CMS, которая «публикует» контент, просто включая его в RSS-канал, где
он поглощается для повторного использования десятками других систем.
Форматы электронных книг продолжают развиваться, но перепрофилирование
контента в таких форматах, как PDF, EPUB или MOBI, может быть
предпочтительным способом его потребления для посетителей, особенно для
длинного справочного контента.
Наконец, как насчет офлайн-каналов? Видеорекламные щиты становятся все
более популярными (и отвлекающими). Каким бы необычным ни казалось это
приложение, оно все равно остается контентом, которым необходимо
управлять. Я с нетерпением жду того дня, когда в целевом меню моей
публикации появятся варианты «10-я улица на 63-й улице» и «I-90, к западу от
Су-Фолс».
Потребление распределенного контента начнет расти

Начинают появляться сервисы, ориентированные непосредственно на процесс
редактирования и создания контента. Такие платформы, какСбор контента
иДивви сосредоточены вокруг управления редакционными календарями,
создания задач и совместной работы. Они фактически отделили этот набор
функций от CMS и сосредоточились именно на нем.
Некоторые организации обратятся к этим услугам, поскольку в их CMS не
хватает инструментов редакционного процесса. Команды начнут работать над
иногда трудоемким процессом создания контента с вызова API, который
фактически создает или обновляет контент в CMS в последний момент.
Кроме того, организации начнут требовать все более распределенного
потребления контента. Я не думаю, что пройдет много времени, прежде чем мы
увидим CMS, предлагающую, например, редактирование контента и
совместную работу непосредственно из Google Docs. Другие системы, такие
какБеегит и собственный О'РейлиАтлас Платформа обеспечивает
высококачественную совместную работу с документами на основе
традиционного контроля версий и синтаксиса, подобного Markdown.
Организации также могут начать распределять управление контентом, имея
несколько внутренних систем и одну внешнюю CMS, которая доставляет весь
контент. Например, авторы внутренних блогов могут писать свои сообщения в
частной установке WordPress, которая затем передает контент в более
надежную маркетинговую CMS для доставки.
Потребление распределенного контента начнет расти |3 3 7

На сегодняшний день поставщик CMS по умолчанию предполагает, что весь
контент начнет жизнь в самой CMS. Ситуация начнет меняться по мере того,
как поставщики начнут осознавать и адаптироваться к тому факту, что другие
платформы обрабатывают редакционный процесс с большей
целенаправленностью и функциональностью.
СПРАВЛЯТЬСЯ, МЫС, и тот система управления контентом как

СодержаниеПромежуточное ПО
В 2009 году два разработчика Национального общественного радио (NPR)
выступили на конференции с докладом о системе, которую они назвали COPE,
что означает Create Once Publish Everywhere. NPR создала платформу контента,
которая позволяла создавать контент и управлять им в нейтральном формате, а
затем использовала эту платформу для передачи его десяткам конечных точек:
собственный веб-сайт, веб-сайты филиалов, мобильные приложения, сторонние
порталы. , Айтюнс и т. д.
Это была многоканальная публикация, и это была картина, которую
поставщики CMS годами рисовали о том, что мы можем сделать с их
продуктами. Однако презентация COPE стала одним из первых примеров
реализации этой идеи в большом масштабе, которую многие видели.
Индустрия была очарована этим.
Несколько лет назад я брал интервью у Зака Брэнда, одного из архитекторов
COPE, и он рассказал мне, что система в конечном итоге превратилась в то, что
они неофициально называли CAPE: Create Anywhere Publish Everywhere.
Вместо единого интерфейса для ввода контента они разработали API для
приема контента из нескольких разных каналов. После приема контента
(«откуда угодно») система выполняла функции управления, а затем отправляла
контент («везде»).
В этом смысле их платформа стала промежуточным программным
обеспечением для контента. Это был «клей», который соединил множество
различных методов создания контента с множеством различных методов его
доставки. Контент поступал из нескольких точек к редакционному «гаишнику»,
а затем отправлялся для доставки конечным потребителям.
Это будущее CMS? Поставщики предоставили нам все инструменты,
необходимые для распределенной доставки контента, и, как мы обсуждали
ранее, социальные сети стали для многих клиентов стимулом двигаться вперед
на этом фронте. Какова будет разработка сопутствующего контента, чтобы дать
толчок распределенному приему и созданию контента?
Я не сомневаюсь, что большая часть веб-контента будет по-прежнему
разрабатываться внутри самой CMS, но организации будут все чаще искать
возможность переносить контент, не относящийся к CMS, на свои CMS
исключительно для доставки вместе со всем остальным.
Послесловие
Управление контентом – это не статичная дисциплина. Мы постоянно

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

тысячелетий. Писцам в Древнем Египте все еще приходилось структурировать
контент, организовывать его, контролировать рабочий процесс его создания и
находить способ его распространения.
Эта отрасль часто может быть очень важной. Существует тенденция полагать,
что то, что мы делаем, является совершенно новым и оригинальным. Но хотя
поверхностные конструкции момента могут измениться, практика управления
контентом, проявленная в этих четырех дисциплинах, является
трансцендентной.
Все остальное — просто детали.
339
Следующие шаги
Чтобы продолжить изучение управления веб-контентом, я предлагаю вам сделать две вещи:
• Посетите глоссарий этой книги на сайтеhttp://flyingsquirrelbook.com/glossary.

Там я определяюи связать сотни терминов, используемых в этой книге, и
включить ссылки на соответствующие ресурсы.1
• Пожалуйста, не стесняйтесь обращаться ко мне, если вы хотите обсудить
какие-либо темы этой книги или если у вас есть какие-либо комментарии
или возражения по поводу всего, что вы здесь прочитали. Я наслаждаюсь и
приветствую бурные дебаты об управлении контентом. Мой е-
маилdeane@blendinteractive.com и меня можно найти в Твиттере по адресу
@gadgetopia.
• С 2003 года я веду блог о веб-технологиях на сайте Gadgetopia. Мои статьи
по управлению контентом собраны вhttp://gadgetopia.com/cm. Некоторым
из этих сообщений в блоге более десяти лет, и иногда интересно (и слегка
смущающе) видеть, как мое мышление изменилось за это время.
1По иронии судьбы, на веб-сайте этой книги не используется система управления контентом. Глоссарий
поддерживается в Markdown, а веб-сайт создается с помощью замечательного генератора статических
сайтов под названиемВьям.
340 | Послесловие
Индекс
А веб-сервисы,248
абстракция(и),189 одобрения
частей репозитория,246 редакционная,157
шаблон,193-194 краткое описание функций,171
запись контроля доступа утверждающие,55
(ACE),165 список контроля атрибуты
доступа (ACL),165 и типы данных,88-90
приобретение,35-51 как редакционные
от коммерческих метаданные,92
поставщиков,39-44 встроенный,90
собственная разработка,47-49 Проверка,91
варианты с открытым аутентификация
исходным кодом,36-39 авторизация против,165
вопросы/контрольные списки подключаемые архитектуры для,247
для,49 автоматическая миграция контента,288
риски, связанные с ИТ- автоматизация контента,11
требованиями,44 SaaS,45-47
время покупки,42
неизвестные неизвестные в процессе Б
отбора,51 действия, разрешения для,168 особенности подпора,204
интерфейс администратора,140 Базовый лагерь,67
администратор,58 преимущества, фактические и
пользователь уровня администратора, теоретические,19 Бернерс-Ли,
разработчик,272 Adobe Дримвивер,331 Тим184
сайты по интересам,227 предвзятость,117
соглашения об агрегировании (см. двунаправленная публикация,30
агрегирование контента), платформы для блогов,80
письменные,314-319 Поле тела,91
Веб-сервисы Amazon,332 Бойко, Боб,5
интеграция Бултон, Марк143
аналитики,218 объем бюджета,313
AngularJS,332 покупка,CMS (см. приобретение, CMS)
аннотированные каркасы,311
анонимная персонализация,214-217 С
API (интерфейсы прикладного CAPE (создавайте где угодно, публикуйте
программирования),235-250 везде),338
и подключаемые категории
архитектуры,243-245 как
сдвинутые во времени
отношения,250 код API,236-243 341
модели событий,239-242
как вторичная география,118 по конфигурации или по коду,130-131
теги против,119 география контента,114-120
CCMS (компонентные системы управления
контентом),8,150
CDN (сеть доставки контента),240 набор
изменений,156
каналы,81
CKEditor,246
Кларк, Джош,79
облачные вычисления (см. программное
обеспечение как услуга) CloudFront,332
API кода CMS (см. системы управления
контентом),236-243
сотрудничество, рабочий процесс
для,160 коллекции, как вторичная
география,118 коммерческое
программное обеспечение CMS
приобретение,39-44
и регулярный доход,43
модели лицензирования,40
программное обеспечение с
открытым исходным кодом
или20-23 методы
ценообразования,41
риски, связанные с ИТ-
требованиями,44 подписка на
программное обеспечение,42
терминология,37
время покупки,42
синдром коммерческого программного
обеспечения,23 сообщество (экосистема
пользователей и разработчиков),
233
комьюнити-менеджеры,55
сложность, анализ функций и,67
системы управления компонентным
контентом (CCMS),8,150
условные поля,222
конфигурация,269
содержание
созданные людьми посредством
редакционного процесса,3
предназначенные для потребления
человеком через
публикация,4
автоматизация/агрегирование,11
код против,28
определенный,5
презентация против,83,173
издательский,196-202
необработанные
данные по
сравнению с,3
отделение презентации от,81-85
агрегирование контента,109-133
и глобальное дерево,115
плоский или и связанные и разделенные системы,26
иерархический,129 управление контентом против,5,25
функциональность, сеть доставки контента (CDN),240
122-130 разработка контента, интеграторы и,323
неявные/явные модели,120-122 встраивание контента
межстраничный,129 и моделирование контента,97-
создание объекта контента 103 и миграция,291
из,121 заказ вручную или блоки,100
производный порядок, последствия для композиции страницы,101-
125-127 103 регионы,101
моделирование для реализации,271-273 встраивание расширенного
разрешения,128 текста,97-100 виджеты,100
фильтры статуса срок действия
публикации,128 контента,156 файлы
ограничения по содержимого
количеству,128 добавление,162
форма ассоциация,163
содержания,111- Обработка изображения,164
113 статический управление,162-164,172
или форматирование контента,13
динамический,123- заморозка контента,301
125 краткое география контента,114-120
описание и предвзятость,117
функций,133 изменение во время миграции
ограничения контента,293 редакционные
типа,127 ограничения,117
URL-адресация,122 вторичная география,118
переменная или деревья,115,119
фиксированная,125 интеграция контента,277
утверждение контента,171 жизненный цикл
создание контента,136-138
контента,12 управление
доставка содержанием
контента
342 | Индекс
и система управления контентом,5-7 элегантности,32 системы против
основные характеристики,1-14 реализаций,17 целевые типы
доставка контента по сравнению с,5,25 сайтов,16
содержание,3-5 стек технологий,23-25
моделирование данных виды,7-9
и,80 дисциплина однонаправленная или двунаправленная
против программного публикация,30
обеспечения,6 первые
дни,xv развивающаяся
роль,60
четыре столпа,339
будущее,329-338
многоязычный (см. многоязычное
управление контентом)
системы против реализаций,17
системы управления контентом (CMS)
получение (см. приобретение,
CMS) фактических и
теоретических выгод,19
и синдром коммерческого
программного обеспечения,23 и
редакционная эффективность,11
и технический
долг,32 как
цифровой хаб,242
код против
конфигурации,29 код
против контента,28
автоматизация/агрегация контента,11
контроль контента,9
ограничения форматирования
контента,13 повторное
использование контента,10
основные функции,9-12
связанные или
разделенные,26
определенный,5-7
расширяемость (см. расширяемость)
функций анализа функций (см.
анализ функций), не
обрабатываемых,12-14 аналогия
домостроения,14 реализация (см.
реализацию) реализации по
сравнению с системами,17
установлено по сравнению с SaaS,27
управление против доставки,5,25
управление несколькими объектами,226-
228
программное обеспечение с открытым
исходным кодом или коммерческое
программное обеспечение,20-23 на
основе страниц,84
стиль платформы и стиль продукта,18
точки сравнения для выбора системы,15-
33
практичность против
команда управления определение
контентом,53-61 модели,85-104
администраторы,58 контрольный список
и заинтересованные функций,107
стороны проекта,59 для реализации,271-273
Разработчики,57 управляемость,105
редакторы,54-56 страничная CMS,84
планировщики сайтов,56 отношения,103
промежуточное программное обеспечение для разделение содержания и представления,81-
контента,338 85 типы,85-88
миграция
контента,285-303
и скорость
контента,300 и Индекс |3 4 3
встроенный
контент,291
автоматизирован
ный или
ручной,287
меняя географию во
время,293 опасность
недооценки,301 на ранних
стадиях процесса
реализации,273
редакционный вызов,286
добыча,289-291
окончательный,281
Импортировать,294
разработка скрипта
миграции,298 один к
одному,299
планирование,302
процесс, 288-298
Контроль качества для,297
повторная сборка, 292-294
разрешение перенесенного
контента,295-297 заглушка,294
время,300
трансформация,291
моделирование контента,75-108
и встраивание
контента,97-103 как
редакционный
выпуск,106
проверка
атрибутов,91
атрибуты и типы
данных,88-90
атрибуты как
редакционные
метаданные,92
встроенные
атрибуты,90
состав,104
Тип содержимого,85-88
наследование типа
контента,93-96 контент
против презентации,83
моделирование данных и
управление контентом,80 основы
моделирования данных,76-79
навигация по
обработка данных, формы
контенту,170
и,223 моделирование данных
объекты контента
и управление
тип контента по сравнению с,86
контентом,80 основы,76-
преобразование агрегации в,121
79
оперативный,178
администраторы баз данных,58
шаблонизация,276
типы данных,88-90
выбор типа,140-142
отдельная система CMS
разрешения на контент,164-
преимущества,198
170 (см. также
контент и код,28
разрешения)
связанная система
предварительный просмотр контента,170
против,26
согласование контента,269
синхронизация среды доставки,200
планирование контента,155,171
краткое описание функций,202
поиск контента,229-233
поиск контента в,139
и поиск информации,230
будущее,331
Люсене,233
публикация контента с помощью,196-
контент-стратеги,56
199 краткое описание функций
заглушка контента,294
публикации,202 публикации целей
обход контента,138-140,170 в,199-201
деревья контента,114 доставка (см. доставку контента)
проблемы с функциональностью,119 синхронизация среды доставки,200
иерархический,115 управление зависимостями,153
миграционный Разработчики
процесс,293 Тип и качество API,250
содержимого и
и моделирование контента,85-88 функциональность,
объект контента по сравнению 29
с,86 и обобщение,266
в агрегатах,127 как пользователи уровня
наследование,93-96 администратора,272 избегая
выбор нового объекта контента,140- центризма развития,282-284
142 типы переключения,87 экосистема,233
шаблон против,175 в команде управления контентом,57
скорость контента,300 центризм развития,282-284
контекст, окружение и,188 сообщество разработчиков,233
постоянный/периодический доход,43 управление цифровыми
структуры управления,181 активами (DAM),7 цифровой
COPE (Создать после публикации хаб,242
везде),338 расходы моделирование дискретного
внедрения CMS,313 контента,103 дискретная
прокладка,312 информация,274
связанная система CMS, Дискус,331
развязанная система распределенный прием
или26 контента,337 DNS (система
публикация контента с доменных имен),282 синдром
помощью,196-199 Круиз- «делай все»,67 управление
контроль,269 документами,7 документация
пользовательские перенаправления,225 и программное
управление взаимоотношениями с обеспечение с открытым
клиентами (CRM),218 исходным кодом,38 в
контексте,149
Д Документум,8
DAM (управление цифровыми активами),7 Додзё,332
информационные панели,228 система доменных имен
(DNS),282 контроль качества
домена,297 шаблонах,101
дропзоны, в Друпал,8,31,101
Друпал Гарденс,15
344 | Индекс
плагины Друпала,244 публикация набора изменений,156
модуль Drupal Views,131 сотрудничество,160
динамическая агрегация,123-125 утверждение контента,160
заказ,125-127 срок действия контента,156
критерии поиска управление файлами контента,162-164 жизненный
в,123 переменная или цикл контента,136-138
фиксированная,125 планирование контента,155
динамическая композиция страниц,101- управление зависимостями,153
103
Э
ECM (управление корпоративным
контентом),7 крайние случаи,79,203
редактирование
и создание агрегации контента,133
моделирование контента как
редакционная проблема,106
редакционные ограничения по
географии,117
интерфейс редактирования,138-150
обход плохих инструментов,150
возможность поиска/обхода
предварительный просмотр
настройка,245
элементы, 144-150
краткое описание
функций,171 для
построения
формы,221
контекстная
помощь/документация,149
многоязычное управление
контентом,211 персонализация и
предварительный просмотр,144
подбор справочного контента,148
расширенное редактирование
текста,146
настройка редактора
форматированного текста,246
масштабируемость,140
выбор типа,140-142
Проверка,145
РедактироватьLive!, 246
редакционные разногласия,135
редакционные метаданные,
атрибуты как,92 редакционный
процесс
и миграция контента,286
CMS и эффективность,11
создание контента с
помощью,3
редакционные инструменты/рабочий
процесс,135-172
одобрения,157
интерфейс редактирования,138-150 событий,159
обход редакторами внешние интеграторы (см. интеграторы, внешние)
плохих извлечение,289-291
инструментов,150 платформа эЗ,24,99
краткое описание
функций,170-172 Ф
Обработка изображения,164 Фейсбук,331
многоязычное анализ функций, CMS,65-73
управление и детали реализации,69
контентом,211 и уникальные потребности
разрешения,164-170 организации,72 контрольный список
контроль версий,153 агрегирования контента,133
метки версий,151 контрольный список моделирования
управление версиями,151-153 контента,107 трудности,65-71
рабоч синдром «делай все»,67
ий контрольный список
процесс,1 редакционных инструментов,170-
57-160 172
редактор
ы
доступ к функционалу,29
в команде управления Индекс |3 4 5
контентом,54-56
элегантность,
практичность vs.,32
встроенный контент,
миграция,291
встраивание (см.
встраивание контента)
Синдром пустого дома,273
управление
корпоративным
контентом (ECM),7
Эписервер,24,101,179
обработчики событий,239
модели событий,239-242
события),239
срок действия,156,171
модель
явной/внешней
агрегации,120
функция
экспорта,289
расширяемость,235-250
и API кода,236-243
настройка
редакционного
интерфейса,245
модели событий,239-
242
подключаемые архитектуры,243-245
подключаемая аутентификация,247
абстракция репозитория,246
запланированные/по требованию
работы,249
веб-
сервисы,
248
внешние
механизм
ы
соответствие цели,66 помощь, в контексте,149
сопоставление функций с иерархические агрегаты,129
проблемами,70 цели,108
контрольный список управления
выводом,201 обзор возможностей
CMS,71 контрольный список
управления публикацией,201 целое
против частей системы,68
файловые шаблоны,195
фильтры,128
соответствие цели,66
плоские агрегаты,129
управление потоком,181
иностранные языки (см. многоязычное
реализация погрузчика,255-257
форма здания,220-224
обработка данных,223
редактирование
интерфейсов для,221
интеграция механизмов внешних
форм,224 проблемы с
дополнительными
инструментами,68 стилистическая
сложность,222
формировать сервисы
двигателя,224 форматирование
(содержание),13 модель
программного обеспечения
freemium,38 трение,135
документ спецификации функции,311
функциональный контроль качества,297
будущее управления контентом,329-338
развязанные системы,331
распределенный прием
контента,337 SaaS
начального уровня,335
маркетинговые инструменты и
интеграция,333-335 многоканальное
распространение,336
CMS с открытым исходным кодом,330
г
соглашение о генеральном обслуживании
(GSA),315 обобщение,266
география контента (см. географию
контента) глобальное дерево,115
Гудридс,83
управление,13
GPL (Универсальная общественная
лицензия GNU),37 GSA (договор
общего обслуживания),315 GUID
(глобальные уникальные
идентификаторы),90
ЧАС
иерархическое дерево,111,115 настройка среды,268
исторические URL-адреса,225 окончательная миграция
домостроение, как аналог контента,281 монтаж,269
CMS,14 модели хостинга,279 запуск,282
HTML из готовых виджетов,185 неконтентная интеграция/разработка,277
предварительная реализация,257-268
я принцип конструкции,254
IA-диаграмма,311 процесс,268-284
управление планирование/настройка
идентификацией производственной среды,278
(IdM),167 Обработка ОК,281
изображения,164 грубость,271-273
реализация(и),253-284 поддерживать,280
агрегатное системы против,17
моделирование,27 шаблонизация,274-276
1-273 в рамках обучение,280
анализа виды,255-257
функций,69 код неявная навигация,271 модель
против неявной/внутренней агрегации,120
контента,28 импортные дефекты,298
конфигурация,26 функция импорта,294
9 импорт,294
миграция (см. также миграцию
контента,273, контента) контекстное
281 (см. также редактирование,142
миграцию контекстная помощь,149
контента) контекстное управление,138
моделирование контента,271-273 собственная разработка
согласование контента,269 CMS,47-49 индексы,
расходы,313 дополнительные,124
информационные архитекторы,56
346 | Индекс
информационный поиск
разговорный (см. многоязычное
(ИР),230 Инженуикс,15
наследование,93-96
запуск,282
внутренний шаблон,194
системы управления обучением
монтаж,269
(LMS),8 лицензирование
интеграторы, внешние
коммерческое программное
в качестве отправной точки для
обеспечение CMS,40
приобретения CMS,35
программное обеспечение с
Профессиональные услуги поставщиков
открытым исходным
CMS,307 разработка контента,323
кодом,39
расходы,313
жизненный цикл (см.
инфраструктура разработки и
жизненный цикл
тестирования,320 во время
контента)списки,100,118
производства,319-324
LMS (системы управления
модели взаимодействия,306-308
обучением),8 локализация,205
консультации по вопросам
Люсене,233
неисполнения,317
артефакты перед реализацией,310-312
общение по проекту и регистрация, М
320 управляемый хостинг,38
ОК,323 управление (см. управление контентом) (см.
В отношениях с,327 системы управления контентом (CMS))
определение объема ручная миграция контента,287
проекта,309-312 ручной заказ, производный порядок
поддержка, или,125-127 маркетинг
предоставляемая,325 интеграция аналитики,218
близость и преданность коллективу,319 и интеграция CRM,218
обучающие модели,324 анонимная персонализация,214-
доверие и,327 217 как выходящее за рамки
прием работ,321-323 CMS,12
работать с,305-327 как редакционная
письменные соглашения с,314-319 роль,55
ИнтенсивныеДебаты,331 автоматизация,213-
виджеты интерфейса, 220
готовые,185 будущее маркетинговых
интернационализация,205 инструментов/интеграции,333-
(см. также управление многоязычным 335
контентом) IR (поиск информации),230 документ предложения,314
ISO (Международная организация по Медиа Вики,112
стандартизации),206 встречи с интеграторами,320
ИТ-отдел, требования организаций по Мендельсон, Ной,184
сравнению с,44 меню, как второстепенная
география,118 метаданные
Дж атрибуты как,92
Дженкинс,269
Microsoft FrontPage,11,331
задания, запланированные/по
промежуточное программное обеспечение,338
требованию,249
миграция (см. миграцию контента)
сценарий миграции,298
К моделирование (см. моделирование
известная персонализация,214 контента) многоканального
распространения,336 многоязычное
л управление контентом,204-213
языки проблемы управления контентом,212
родные языки программирования и поддержка внешних переводческих
шаблонный код,183-185 услуг,211 определение/выбор языка,206
языкправила,208-209
языковые варианты,209
номенклатура,205
Индекс |3 4 7
нетекстовый контент,210 укладка,103
многочастные формы,223 страничная CMS,84
управление несколькими объектами,226- Парр, Теренс177
228 частичные типы, объединение,95
мультитенантное программное разрешения
обеспечение,45 и редакционный рабочий процесс,164-170
(см. также CMS-системы «программное
обеспечение как услуга» (SaaS))
Н
сетевой контент,112
неконтентная интеграция/разработка,277
программное обеспечение с неоткрытым
исходным кодом, терминология,37
консультации по вопросам
неисполнения,317
Норман, Дон,237
О
дефекты
объекта,298
объекты
разрешения на контент (см.
объекты контента),167
индивидуальная миграция
контента,299 программное
обеспечение CMS с открытым
исходным кодом
приобретение,36-39
и терминология программного
обеспечения с закрытым исходным
кодом,37
бизнес-модели,37-39
коммерческое программное
обеспечение против,20-23
будущее,330
объект оперативного
контента,178 Оракул,25
фруктовый сад,330
порядок, ручной или производный,125-
127 выходной агностицизм,195
управление выводом,173-196
контент против
презентации,173 краткое
описание функций,201
шаблонизация,175-196
п
наслоение темпа,266
дополнение
(затрат),312
композиция
страницы
встраивание контента и,101-103
горизонтальная и вертикальная
авторизация против элегантность vs.,32
аутентификации,165 предварительная
Решение конфликта,169 реализация,257-268
краткое описание функций,172 открытия и артефакты,257-260
для действий,168 разработка технического
для объектов,167 плана,260-268
для пользователей,166 презентация
с агрегатами,128 контент против,83,173
персонализация,214-217 отделение контента от,81-85
анонимн редактирование без
ый,214- презентации,142
217 идея принцип конструкции,254
против формулировки проблем,311
реальнос проблемы, сопоставление
ти,217 функций с,70 CMS-системы в
известен, стиле продукта,18
214 производственная среда
при модели хостинга для,279
предварительном планирование и
просмотре настройка,278
контента,144 планы, профессиональныйуслуги,307
ограничения,268 проприетарное программное
CMS-системы обеспечение, терминология,37
платформенного прокси-объекты контента,192
типа,18 публикация
подключаемые как характеристика
архитектуры,243- содержания,4 краткое
245 описание функций,201
основные однонаправленный или
компоненты двунаправленный,30
CMS, такие издательское дело,196-202
как,245 для связанное и разделенное управление
аутентификации, контентом,196-199
247 синхронизация среды доставки,200
полиморфизм,189 краткое описание функций,201
редактор цели публикации, отделенные друг от
мощности,55 друга,199-201 покупка, CMS (см.
практичность, приобретение, CMS)
348 | Индекс
вопрос поиск
контроль качества
для миграции
контента,297
перенесенного
контента,281 с
интеграторами,323
р
Радредактор,246
Реагирова
ть,332
сборка
и затыкание,294
миграция контента,292-294 сверка
(см. сверка контента) управление
записями (RM),7
регулярный доход,43
регионы, в
шаблонах,101
регулярные выражения (regex),146
реификация,77,309
реляционное содержание,112
реляционное моделирование
контента,103 реляционная
информация,274
исполнения,81
инструменты
отчетности,228 хранилище,
абстракция,246 сбор
требований,44
разрешение перенесенного
контента,295-297 адаптивный
дизайн,195
REST (передача репрезентативного
состояния),248 повторное использование,10
обратное управление
контентом,221 богатый текст
интерфейс редактирования для,146
настройка интерфейса редактора,246
встраивание,97-100
РМ (управление
записями),7 грубость,271-
273
С
Системы SaaS CMS (см. программное
обеспечение как услуга).CMS-системы)
масштабирование/масштабирование,140
планирование,155,171
платформа SCM (управление исходным
кодом),268 обзор,309-312
очистка экрана,289
скрипт, миграция (см. скрипт миграции)
как агрегирование кодом,39 окружить,
динамических и внутренний шаблон,194
переменных,125 и шаблонизация,185-190,274
содержание,229-233 контекст,188
критерии в динамических
агрегациях,123 Люсене,233
дополнительные индексы
Т
табличное содержимое,112
для,124 выбор, CMS (см.
приобретение,
CMS)консультант по
подбору,35 Индекс |3 4 9
процесс отбора (см.
приобретение,
CMS)сериальный контент,111
администраторы серверов,58
Серверная часть
включает в
себя,11,185,193 форма
содержания,111-113
срезание слоев,266
одностраничные приложения, 332
планировщики сайтов,56
карта сайта,311
SOAP (простой протокол доступа к
объектам),248 социальная сеть,336
CMS-системы «программное
обеспечение как услуга»
(SaaS)приобретение,45-47
будущее,335
установленное программное обеспечение по
сравнению с,27
платформа управления исходным
кодом (SCM),268 СОУ (описание
работы),315-319
Спольски, Джоэл21,67
стек (стек
технологий),23-25
Переполнение стека
(веб-сайт),234
стекирование (композиция веб-
страницы),103 заинтересованные
стороны, команда управления
контентом и,
59
техническое задание
(SOW),315-319
статическая
агрегация,123-125
администраторы хранилища,58
Строковый шаблон,177
заглушка,294
подписки, программное обеспечение,42
Краткое содержаниеполе,91
дополнительные
индексы,124
поддерживать
интеграторами,325
реализации,280
программного
обеспечения с
открытым исходным
теги
выбор типа
как вторичная география,118
категории против,119
для нового объекта контента,140-142
таксономии,118
команда
управление контентом (см. команду ты
управления контентом) UGC (пользовательский контент),30-31,55
разработка технического плана,263 однонаправленная публикация,30
технический долг,32 управление URL-адресами,224-
план технической реализации (ТИП),260 226,297 (см. также
разработка технического плана,260-268 резолюцию)
стек технологий,23-25 сопоставление URL-адресов,178
шаблонизация,175-196 URL-адреса, агрегаты и,122
и контролирующие удобство использования,69
структуры,181 и дизайнеры пользовательского опыта (UX),56
реализация,274-276 и пользовательский контент (UGC),30-
прокси-объекты,192 31,55 пользователи
и окружение,185-190 экосистема,233
опасности готовых виджетов разрешения на,166
интерфейса,185 определенный,175 UX (пользовательский опыт) дизайнеры,56
языковая функциональность,179-185 В
родные языки программирования и Проверка
шаблонный код,183-185 и интерфейс
объектов,276 редактирования,145
объемного,274 атрибутов,91
выходной агностицизм,195 тщеславные URL-адреса,225
философии,177-179 Вин, Джеффри 31
адаптивный дизайн,195 скорость,
простая замена токена,180 окружает содержание,300
отношение к внутреннему шаблону, продавцы
194 и экосистема пользователей/разработчиков,233
абстракция/включение шаблона,193-194 для интеграции (см. интеграторы, внешние)
разработка/управление шаблонами,195 контроля версий,153,171
выбор шаблона,190-192 тип метки версий,151
против шаблона,175 управление версиями,151-153,171
крошечныйMCE,246 визуальныйдизайнеры,57
ТИП (технический план реализации),260
Поле заголовка,90
жетоны,180 Вт
обучение интерфейс веб-сервиса,248
и реализация,280 и Вебноды,112
программное обеспечение виджеты, готовые,185
с открытым исходным WordPress,112,179,244
кодом,38 и повторение,133 рабочий процесс,157-160
интеграторами,324 (см. также инструменты
трансформация (миграция контента),291 редактирования/рабочий
службы перевода,211 процесс) утверждение контента
переводчики,55 и,160 краткое описание
деревья (см. деревья функций,171
контента) тип (см. тип неофициальный,160
контента) письменные соглашения,314-319
WYSIWYG (что видишь, то и
получаешь)редактор,90
350 | Индекс
О тотАвтор
Дин Баркерзанимается управлением веб-контентом с середины 90-х годов —
еще до того, как у этой дисциплины появилось название. Он является
ветераном сотен внедрений, от небольших маркетинговых сайтов до крупных
издательских операций. Дин работал практически над всеми архитектурами
программирования и десятками различных платформ CMS. Он пишет об
управлении контентом уже более десяти лет и часто выступает на
конференциях по управлению контентом.
О технических рецензентах
Сет Готлибпреобразует идеи в технологические платформы и в равной
степени является разработчиком, архитектором и строителем команды. В
качестве вице-президента по разработке продуктов в Lionbridge Technologies
Сет разрабатывает и внедряет технологии для поддержки стратегических
бизнес-инициатив. Сет имеет глубокий опыт разработки и интеграции
программного обеспечения. Более 20 лет он руководил консалтинговыми и
собственными проектными группами и создавал инженерную культуру,
ориентированную на производительность.
Линси Стразерсразработала свои навыки CMS по борьбе с контентом для высшего
образования
— помогла создать первую собственную систему управления контентом в
колледже своего работодателя в начале 2000-х годов. С тех пор она
консультировала большие и малые организации по вопросам внедрения и
поддержания эффективного присутствия в Интернете. Линси в настоящее
время является старшим консультантом по пользовательскому опыту в
компании Evantage Consulting в Миннеаполисе, штат Миннесота.
Арильд Хенрихсенболее десяти лет занимается созданием веб-сайтов,
порталов и интрасетей, специализируясь на системах управления контентом.
Он сертифицированный разработчик, архитектор, технический руководитель,
тренер, спикер и блоггер, а также MVP Episerver.
Колофон
Животное на обложке журнала Web Content Management — карликовая белка-
летяга. Этот самый маленький вид летяги можно встретить в джунглях Борнео
и Малайзии.
Белку-летягу правильнее называть белкой-планером. Большой лоскут кожи,
называемый патагием, простирается от боков животного до запястий и
лодыжек. Он взлетает в воздух с вытянутыми руками и ногами, тяня за
обученный патагий. Подобно пушистому коршуну, карликовая белка-летяга
плывет вверх и вниз, пролетая три фута на каждый фут падения. Он использует
свои длинные усы, чтобы обнаруживать ветки и земли с закрытыми глазами.
Карликовые летяги имеют всеядную диету, состоящую из орехов, семян,
фруктов, ягод, насекомых и птичьих яиц. Он добывает пищу под покровом
ночи, чтобы избежать хищников.
Многие животные на обложках О'Рейли находятся под угрозой исчезновения;
все они важны для мира. Чтобы узнать больше о том, как вы можете помочь,
перейдите по ссылкеживотные.oreilly.com.
Изображение на обложке взято из словаря Битона. Шрифты обложки: URW
Typewriter и Guardian Sans. Шрифт текста — Adobe Minion Pro; шрифт
заголовка — Adobe Myriad Condensed; шрифт кода — Ubuntu Mono от Далтона
Маага.

Web Content

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Web Content

Загружено:

Авторское право:

Доступные форматы

Перевод: английский - русский - www.onlinedoctranslator.

Дин Баркер, партнер-учредительи директор по стратегии в Blend

Пекин Бостон Фарнем Севастополь Токио

Март 2016 г.: ПервыйВерсия

Редакция История для тот ПервыйВерсия

Видетьhttp://oreilly.com/catalog/errata.csp?isbn=9781491908129 для получения подробной информации о выпуске.

4. The Содержание УправлениеКоманда....................................53

Часть II. The Компоненты из Содержание УправлениеСистемы

8. Редакционные инструменты и рабочий процесс............................135

9. Управление выводами и публикациями.....................................173

10............................................................Другие особенности. 203

11.......................................................API иРасширяемость. 235

Часть III. Реализации

Типы реализаций 255

13...........................................................Миграция контента. 285

14.............................................Работа с внешними интеграторами. 305

15..............................Где Содержание Управление ЯвляетсяИдущий. 329

Индустрия управления веб-контентом существенно изменилась за последние

Примерно в 1995 году я написал свой первый HTML-документ.

Для кого эта книга?

• Менеджерам проектов поручено управлять внедрением новой CMS.

Чего нет в этой книге?

Как организована эта книга?

Примечание об общих чертах

Примечание о боковых панелях

Конвенции Использовал в ЭтотКнига

Этот элемент означает подсказку или предложение.

Этот элемент означает общее примечание.

Сафари® КнигиВ сети

Технологические специалисты, разработчики программного обеспечения, веб-

Как связаться с нами

О'Рейли Медиа, Инк.

У нас есть веб-страница этой книги, на которой мы перечисляем ошибки,

Мы склонны рассматривать управление контентом как цифровую концепцию,

2 | Глава 1: Что такое управление контентом (и чем оно не является)

• Что такое контент?

• Контент создается по-другому.

Сделано Люди через Редакционный процесс

• Какова должна быть тематика контента?

Несмотря на значительные достижения в области вычислений, компьютер не

Намеревался для Человек Потребление с помощью Публикация к

Что Является а Содержание УправлениеСистема?

Что такое система управления контентом? | 5

Дисциплина против программного обеспечения

6 | Глава 1: Что такое управление контентом (и чем оно не является)

Типы систем управления контентом

Типы систем управления контентом |7

• Рынок, на котором он продвигает себя и на котором он конкурирует.

Что Делает "Предприятие"Иметь в виду?

Что делает CMS | 9

Позволять Содержаниеповторное использование

• Новостная статья появляется на отдельной странице, а также в виде тизера

В таких ситуациях эта информация не создается каждый раз в каждом месте, а

Позволять Содержание Автоматизация иАгрегация

• Мы можем разрешить пользователям использовать контент в других

CMS позволяет это сделать, структурируя, храня, проверяя и предоставляя

Повысьте редакционную эффективность

Чего не делает CMS

12 | Глава 1: Что такое управление контентом (и чем оно не является)

Эффективно форматируйте контент

• Слишком частое использование жирного шрифта и курсива

Редакторы никогда не видели в интерфейсе редактирования кнопки, которую

• Сырье для строительства (дерево, гвозди, стекло)