Достаточно пяти минут, чтобы понять две вещи:

• материал – лишь верхушка айсберга, 90 % всей редакционной работы читатель не увидит;

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

Дополнительные пять минут размышлений дают еще два вывода:

• обычная админка ничего подобного не делает, надо писать что-то свое;

• продукт, о котором идет речь, мало похож на экран подготовки черновика в WordPress, Drupal или Joomla.

Похоже, настало время разобраться – какие бывают системы управления контентом?

Строго говоря, функция управления контентом (content management) совершенно не обязательно связана с функцией публикации и тем более функцией представления конечного продукта пользователю.

Все CMS делятся на:

Монолитные, то есть объединяющие в одном продукте управление и доставку контента. Например, админка WordPress – типичная монолитная CMS, нацеленная на вебпубликацию. Она определяет структуру материала, заведует его публикацией и визуализацией на сайте.

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

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

Гибридные или раздельные (decoupled), где управление и доставка контента разделены. Обычно то, как выглядит написанный в них текст, совсем не похоже на то, как он будет представлен на сайте. В то же время у раздельной системы есть функция создания шаблонов, которая использует программный интерфейс (API) для автоматического преобразования вашей статьи. Это удобно, потому что позволяет не замыкаться на сайте как на единственной цели публикации.

Шаблоны могут через API выдавать из заданных в системе управления контентом данных хоть веб-материал, хоть story в Инстаграме, хоть текст поста в Telegram. Это главное преимущество гибридных CMS – они честно признаются, что не знают, во что превратится цифровое потребление.

Характерный пример издания, задействующего гибридную CMS – The Economist[130]. Технологи журнала со 175-летней историей выбрали гибридное решение, потому что редакция не должна думать, куда уходит данный материал: на обычный веб, в Google AMP, Apple News, Facebook Instant Articles или Snapchat. Журналист просто пишет, а шаблоны решают, как это будет выглядеть. То же касается маркетологов – хотя монолитная CMS дает гораздо больший выхлоп в краткосрочной перспективе, гибридная позволяет атаковать по нескольким направлениям.

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

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

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

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

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

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

Журналистам очень не хватает такого инструмента. Есть множество проверочных, но в основном они затрагивают орфографию, пунктуацию, иногда (как в случае «Главреда»[131]) – стилистику.

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

– В заголовке 12 слов, рекомендуется сократить.

– Вы пишете новость, но уже начали седьмой абзац.

– Свыше 30 % текста – сложные предложения. Рекомендуется упростить.

– Редакционная политика издания не рекомендует использовать в новостных заметках восклицательные знаки и точки с запятой.

– Слишком большой абзац. Он займет больше двух экранов мобильника.

– Ни одного нетекстового элемента на пять абзацев. Рекомендуется разбавить текст.

– Заголовок и подзаголовок содержат повторяющиеся слова.

– Ни одной гиперссылки в тексте. Рекомендуется ставить ссылки там, где упоминаются источники.

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

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

Вот некоторые примеры, которые могли бы появляться в ваших текстах реже (приведены в начальных формах в порядке уменьшения частоты, некоторые сгруппированы по смыслу)[26]:

• быть;

• это, этот, тот;

• который, что;

• свой;