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

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

На КДПВ — скриншот части черновика   Dmitry Kabanov
На КДПВ — скриншот части черновика   Dmitry Kabanov

TL;DR

Взял опубликованный ранее на 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. Для краткости показываю, как выглядит пример фида для первого подраздела этого чеклиста:

{ "protocol": "vigorously structured content exchange", "version": "0.0.1", "host_name": "Glyph media",
 "host_description": "Мы помогаем готовить хабрапосты и колонки о технологиях и бизнесе. У нас есть кейсы сотрудничества с PR-агентствами, дистрибьюторами гаджетов, облачными платформами и провайдерами, рекламными холдингами и стартапами.", "host_email": "y@glph.media", "host_home_page_url": "https://glph.media", "feed_url": "https://list.glph.media/vscex.json", "date_created": "08.05.2021", "date_updated": "08.25.2021", "lists": [ { "id": "1", "title": "Как оценить качество текста", "description": "Для пиарщиков, менеджеров и тех, кто взаимодействует с авторами. Авторам также может пригодиться. С помощью этого списка вы поэтапно и с разных сторон оцените материал (колонку для СМИ, блог-пост о технологиях, исследование).", "chapters": [ { "id": "1", "title": "Грубая проверка", "description": "", "statements": [ { "id": "1", "title": "Тема соответствует площадке", "description": "Учитывайте, на кого ориентирована площадка: на продвинутых технических специалистов, маркетологов, предпринимателей или широкую общественность. Для проверки текста на этом шаге не нужно погружаться в детали — достаточно составить общее представление о нем.", "condition": "Если вы обнаружите несоответствие ожиданиям аудитории, попробуйте изменить тему, внести дополнения или убрать лишнее. В крайнем случае — выбрать другую площадку.", "disclaimer": "", "tools": [] }, { "id": "2", "title": "На площадке нет «дублей»", "description": "Даже если на момент согласования тема не освещалась в выбранном медиа, все могло измениться, пока автор писал материал. Текст, который ничего не добавляет к тому, что уже выходило на площадке, рискует вызвать раздражение у аудитории.", "condition": "Если выбранную тему уже многократно обсудили, постарайтесь подготовить существенные дополнения, поделиться собственным опытом или замените тему на ту, которая будет аудитории в новинку. Если ваша публикация актуальна и уникальна — переходите к следующему пункту.", "disclaimer": "", "tools": [] }, { "id": "3", "title": "Уникальность текста выше 95%", "description": "Проверяйте материалы на уникальность с помощью специализированных инструментов. Примеры пары таких сервисов ищите ниже в этом пункте. Такая проверка не дает гарантии того, что текст не является рерайтом стороннего материала. Выявить это можно в ходе дальнейшей оценки текста (смотрите подраздел «Фактчекинг»).", "condition": "Для текстов, которые не содержат объемных цитат, мы рекомендуем ориентироваться на уникальность не ниже 95%. Разберитесь, какие заимствования подсвечивает тот или иной сервис. Это могут быть повторы терминов (менее критично и легко исправить), а может быть плагиат.", "disclaimer": "Такая проверка не дает гарантии того, что текст не является рерайтом стороннего материала. Выявить это можно в ходе дальнейшей оценки текста (смотрите подраздел «Фактчекинг»).", "tools": [ { "url": "https://text.ru", "description": "Проверка текста на уникальность." }, { "url": "https://content-watch.ru/text/", "description": "Антиплагиат онлайн" } ] } ] } ] } ] }

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

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

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

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

Что предстоит доработать

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

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

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

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

1616
20 комментариев

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

4
Ответить

Тут иная ситуация: 3-4 попсовых протокола синдикации контента, поэтому есть, где разгуляться. Если серьезно, идея не в конкуренции с ними, а в специализации, как завещали, например, разработчики RSS «Subsequent work should happen… in completely new syndication formats, with new names» [ в конце дока тут https://cyber.harvard.edu/rss/rss.html#roadmap ]

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

Ответить

С таким материалом и уровнем проработки вам лучше на Хабрахабр

1
Ответить

Хорошо, напишу. Но и тут буду продолжать рассказывать, как только будет прогресс

Ответить

Комментарий недоступен

Ответить

Да, есть такое. Какую альтернативу вы могли бы предложить?

Ответить