—
31.08.2025
Наблюдая за развитием на российском рынке новых приложений для работы со знаниями (Yonote, Teamly, встроенные wiki в таск-трекерах), приходишь к выводу, что они, не раздумывая, пошли по пути своих популярных западных коллег, создавая полностью закрытые решения.
Все подобные приложения используют block-based редакторы с набором типовых «блоков». Непосредственно текст с иерархией заголовков и вложения (картинки) — это лишь половина информации, заключенная в документах. Именно «блоки» определяют вторую её половину, а именно:
Проблема в том, что «блоки» в каждом отдельном приложении проприетарные (оригинальные), их нельзя один-в-один переместить в другое приложение. Даже у структурно простых блоков (например, «code block») хватает различий в дизайне и поведении. В результате у созданных пользователем документов минимальная интероперабельность.
И от этого вопроса не откреститься утверждением, что «у нас есть API». С его помощью обычному пользователю свои документы (с сохранением их оригинальной структуры, связей, поведения) и привычные процессы (UX) не перенести.
Говоря проще: текст со структурой заголовков и какие-то элементы оформления ты автоматически как-то ещё скопируешь. А вот всё остальное придётся или вручную копипастить, или создавать заново — это огромный объём трудозатрат. Затем придётся привыкать к иному набору блоков в новом приложении и их поведению.
Массовая миграция пользователей в прошлом году из западных сервисов должна была, по идее, хоть чему-то научить российских разработчиков. Они в лоб столкнулись сразу со всеми гранями данной проблемы (им, наверное, теперь везде мерещится возглас пользователей «Хочу как в Notion»). Но пока какой-либо реакции не заметно.
Чтобы показать, что путь развития нового приложения не обязательно должен быть таким вот «закрытым», решил поделиться заметкой из своего архива с кратким переводом доклада Maggie Appleton «The block-paved path to structured data» на «Structured Content Conference» (май 2022).
Подвигнуть разработчиков к тому, чтобы они начали использовать общие унифицированные типы блоков (front-end компоненты) в своих приложениях. И заодно сэкономили ресурсы, не разрабатывая их с нуля. Как следствие:
Команда Hash.ai, от чьего имени выступала Maggie Appleton, в том числе предложила примеры таких унифицированных блоков (открытый стандарт «Block Protocol», в перспективе RFC).
Практически сразу после него команды двух проектов (AppFlowy и AFFiNE) взяли курс на создание своих собственных open-source «Building blocks for developers to create their own applications».
Видимо, попытались перехватить инициативу 😁 AppFlowy, впрочем, потом одумался и в своём roadmap начал декларировать в будущем поддержку «Block Protocol».
У самого Hash.ai пока не получилось популяризовать свою экосистему открытых блоков. Но, думаю, всё впереди. Они на пару лет приостанавливали активное продвижение и занимались более тщательной проработкой архитектуры платформы. (у проекта нет проблем с финансированием и сроками, поэтому работают в удобном им темпе).
Своё основное приложение Hash, которое должно стать эталонным примером использования блоков, команда планомерно разрабатывает и должна вот-вот выпустить в открытый доступ. После этого можно ожидать и рост популярности экосистемы.
➊ Близкую по смыслу деятельность уже больше года ведут разработчики whiteboards, которые вырабатывают единый стандарт блоков / файлов в рамках «Open Canvas Working Group». И вполне успешно. За небольшой промежуток времени группа вышла на этап Candidate Recommendation, и уже создаются примеры конвертеров для легкого переноса данных / структур из одного приложения в другое.
➋ Ранее уже публиковал пару заметок и про сам проект Hash, и своего рода его историческую ретроспективу:
➌ Если задаться мыслью более плотно изучить вопрос интероперабильности данных и UX между приложениями, то можно найти ещё много схожих по назначению кейсов. Как пример:
Сам подход очевидный и уже устоявшийся. Видимо, ниша «редакторов для веб-приложений» до него ещё не окончательно дозрела.
Хочется надеяться, что российские разработчики со временем предложат своим пользователям решение, подобное тому, что озвучено в докладе. А если уж дальше развивать эту мысль, то у нас в стране явно не хватает:
Чтобы любой новый проект мог свободно им воспользоваться в своем приложении. Блоки в таком случае можно сразу сделать совместимыми с тем же стандартом «Block Protocol» от Hash.ai (или аналогами, если они появятся).
Такого готового редактора с коллекцией блоков, собственно говоря, и в мире пока нет. Те приложения, за которыми много лет наблюдаю, в итоге создавали свои редакторы под себя. И процесс работы над ними так и не закончен (постоянное улучшение стабильности, производительности на большом количестве блоков, скорости отклика…).