Задача: Внедрить блог

Контекст

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

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

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

Для этого нужен блог.

Ключевой технический принцип

Блог не должен быть отдельной технической сущностью.

Он должен строиться поверх уже существующих концептов.

Основной механизм различения — поле type у концепта.

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

blog:default
blog:article

и другие типы, начинающиеся с:

blog:

То есть блог — это не отдельная модель данных, а способ классификации, выборки и отображения концептов.

Что нужно проработать

• определить общую систему type для концептов;
• определить namespace blog:*;
• решить, какие конкретные типы блога нужны;
• зафиксировать назначение каждого типа;
• определить, какой тип является базовым/дефолтным;
• определить, какие поля концепта используются для блогового отображения;
• определить правила URL/маршрутизации;
• определить правила списка публикаций;
• определить правила отображения отдельной статьи;
• определить, как блоговые концепты связаны с обычными концептами знаний;
• определить, могут ли одни и те же материалы одновременно участвовать в knowledge-структуре и блоге;
• определить фильтрацию по type;
• внедрить справочник типов так, чтобы не приходилось размазывать строковые значения по коду;
• предусмотреть дальнейшее расширение типов без изменения модели данных;
• определить SEO-поля и правила для блоговых материалов;
• определить, как формируется индексируемая структура блога;
• определить навигацию по тематике без превращения блога в основной вход в продукт.

Возможные типы

Стартовые примеры:

blog:default
blog:article

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

• обзор;
• исследование;
• методический материал;
• заметка;
• кейс;
• объяснение принципа;
• SEO-статья.

При этом конкретный список нельзя фиксировать только по привычным CMS-категориям — он должен отражать реальные способы использования контента в проекте.

Архитектурный принцип

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

Основная логика:

продукт отвечает на вопрос «что я могу сделать прямо сейчас?»

блог отвечает на вопрос «почему это устроено именно так?»

Пользователь может долго пользоваться сайтом и вообще не заходить в блог.

Блог нужен для:

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

Ограничение

Не строить блог как центральную маркетинговую воронку перед продуктом.

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

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