Новый фид для гайдов и списков на JSON — зачем нужен и как может выглядеть на примере чеклиста

Придумал простой и понятный аналог RSS-фида и формата синдикации Atom, но для чеклистов и иного контента с последовательной структурой.

Взял опубликованный ранее на vc.ru гайд и вместе с коллегами переработал его в интерактивный чеклист. На его примере показываю первую версию фида для структурированного контента [инструкций, чеклистов и так далее].

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

Руководства, гайды и туториалы не пишет только ленивый. Ими делятся компании, онлайн-школы, вузы и даже госструктуры.

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

Заголовок «Как настроить ИТ-инфраструктуру в облаке» не обязательно означает, что внутри вас ждет чеклист. Но даже если в нем будет пометка вроде «N шагов для», текст может содержать лишь пространные рассуждения автора на тему и не обладать последовательной структурой.

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

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

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

Реализовать такой проект скорее всего можно на основе существующих форматов синдикации — RSS, Atom, JSON Feed и других. Первые два построены на языке разметки XML. Он универсален; плюс у него есть обширная экосистема вспомогательных решений. Однако RSS и Atom фактически заморожены и не получают обновлений десятилетиями. Работать с ними [читать фид с листа «as is» и редактировать XML-разметку] сложно даже тем, кто годами занимается блогами, контентом и запускает свои подкасты.

Поэтому несколько лет назад и появился JSON Feed. Сформировать ленту по его спецификации на JSON смогут даже те, кто на пушечный выстрел не подходил к программированию. Для JSON Feed есть конвертеры из RSS, валидаторы для проверки ленты и другие полезные инструменты. Формат используют не так массово, как RSS и Atom, но заметные примеры вроде NPR, Daring Fireball и у некоторых русскоязычных авторов все-таки есть.

Однако — на мой взгляд — спецификация JSON Feed обладает скромными возможностями для структурирования содержимого публикаций. Ее авторы просто-напросто не ставили перед собой такую задачу и не занимались вопросом выделения того или иного типа материалов из общей массы публикаций в сети. Поэтому делать надстройку, состоящую на 95% из кастомных тегов, я не стал, и вместо этого предложил новый узкоспециализированный формат структурированного контента.

Для этого я взял готовый гайд, опубликованный ранее на vc.ru. Вместе с коллегами пересобрал его в отдельную страничку с минималистичной анимацией и отредактировал содержание. После этого — описал получившийся чеклист в виде ленты на JSON. Для краткости показываю, как выглядит пример фида для первого подраздела этого чеклиста:

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

Еще здесь исключена html-разметка из текстовых описаний подразделов и пунктов [statements]. Так у компаний будет меньше возможностей для развешивания рекламных ссылок, и читатель не будет отвлекаться на ненужные рефы. Инструменты [tools], на которые обычно и дают ссылки, — вынесены в отдельную категорию. В веб-версии чеклиста этот элемент находится под текстом и сейчас выглядит вот так:

Если говорить о смысловом дроблении, пока остановился на описании [description], условии выполнения [condition] и дисклеймере [disclaimer]. Последние два тега — опциональные, как и некоторые другие — вроде [tools].

Опыта в разработке протоколов и стандартов для обмена данными у меня нет, а на первую версию я потратил буквально несколько вечеров. Поэтому правки могут быть существенные по мере того, как я буду анализировать обратную связь и аналоги [помимо RSS, Atom и JSON Feed есть огромное количество других форматов, поэтому мой — может претерпеть много изменений].

Подумаю о расширении количества опциональных тегов. Например, с данными об организации и авторах материалов. Плюс — о том, каким образом рекомендовать оформление тега "host_description" [думаю, что здесь стоит дать зеленый свет для размещения ссылок на кейсы, как тут].

Еще постараюсь подготовить больше примеров того, как можно структурировать другие типы контента с помощью этого формата.

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