Просмотр исходного текста страницы Инфографические конспекты — от унылых страниц к компактным и живым свиткам (Стас Фомин, OSEDUCONF-2026)

{{Speaker|Стас Фомин}}
<blockquote>
Статьи и книги в современном мире неэффективны для передачи знаний — нужно компактно, нескучно и понятно, используя максимальную визуальность и все доступные технологии — цвета, диаграммы, видео, 3D-модели…  
Альтернативные форматы: слайды, презентации, майндмапы, визуальные доски — пытаются решить эту проблему, но тоже концептуально негодны.

Сейчас нужны компактные и визуальные знания, передаваемые и чтением, рассказом-презентацией в зале, на удаленном созвоне и даже на телефоне-планшете, в баре или кулуарах конференции, пересылаемые для просмотра оффлайн, и годные для «автоматического разворачивания в статью». И чтобы с ними можно было эффективно работать — создавать в процессе мышления, индивидуально или коллективно, в «рилтайм» или оффлайн, с ИИ или без; не отвлекаясь на зубодробительные сложности, с нулевой кривой обучения; используя максимально привычные IT-шнику навыки и инструменты.

Такой инструмент мы и предлагаем, превращая стандартный markdown-редактор от <code>code-server</code>/<code>code-oss</code> в «майндмаппер на свитке»; используя все возможности визуализации научно-технических концепций — от десятков типов диаграмм до автоматически получаемых «живых иллюстраций».

Инструмент опробован не только для преподавания и командной работы IT-профессионалов, но и в новой парадигме обучения <ref name="cite-fcromt" />, когда студенты сами или с помощью ИИ изучают неизвестные темы, рассказывая и презентуя темы по свежим научным статьям или редким книгам. А технически это набор open-source проектов: CSS-стилей и расширений к code-server/code-oss/vscode.
</blockquote>


Ссылки к докладу «Инфографические конспекты»
* https://академон.эвристика.рф/public/fc/oseduconf/2026/mind-infographic/mind-infographic.html
* [https://алгоритмы.испран.рф/public/ae/code-notes-infograph/idea.html Вот старые наброски с видео по теме]
* [https://vkvideo.ru/video-667081_456239463?t=3h30m13s увы фигово снятое с глючным звуком выступление на конфе, но в целом понимаемо]

== Thesis ==
* [https://gitverse.ru/belonesox/code-notes-infograph https://gitverse.ru/belonesox/code-notes-infograph]
* [https://gitverse.ru/belonesox/freeze-markdown-vscode-ext https://gitverse.ru/belonesox/freeze-markdown-vscode-ext]
* [https://gitverse.ru/belonesox/markdown-laconicism https://gitverse.ru/belonesox/markdown-laconicism]

=== Книги и статьи уже неэффективны для передачи знаний ===
Текущая практика передачи знаний в научном мире, образовании и бизнесе по-прежнему опирается на формат «научной статьи» и книги. Это было рационально в эпоху типографий и бумажной печати, но сейчас это «кандалы на пути прогресса». Стандартная двухколоночная черно-белая научная статья, заточенная «под печать» шрифтами и версткой, жесткими требованиями к цветам, объему и структуре мучительна и для написания, и для чтения с экрана.

Можно долго перечислять кучу проблем именно «бумажно-страничной печати» — «уплывающие» таблицы и графики, мучительная имитация гиперссылок и поиска через «см. табл. X на стр. Y» и списки таблиц, алгоритмов и рисунков, безумные требования к строчкам и страницам, висячие предлоги, чертовы переносы… Кто занимался версткой книг-сборников и вызубрил «справочник корректора», тот в цирке не смеется, только во сне вскрикивает «авикосуя!». Все это, включая «попадание строчек на просвет» (для печати на тонкой дешевой бумаге) — было оправдано в свое время, когда именно типографии дали буст прогрессу знаний, при уходе от малочисленных переписчиков на дорогущем пергаменте.

Но все уже, ушли «касты переписчиков» и «когорты машинисток», не нужно бумажных книг-пылесборников, когда все читают на электронных устройствах разного размера — и привыкли, что любой контент умеет адаптироваться к размеру экрана, показывает себя максимально красиво, читаемыми экранными шрифтами, с цветами и графикой без ограничений по объему. А стандарты «бумажной верстки» остались, вместе с унылыми правилами «написания научной статьи», превращающей понятный результат в вязкий, скучный формализованный поток оправданий-извинений-упоминаний, где зачастую отсутствующая суть погребена под массивами ватного текста, ненужных ссылок для игр в цитируемость, и не остается места для главного — ясного и яркого доказательства, чего-то живого, проверяемой сути. Ситуация усугубляется валом «ИИ-слопа», и в целом информационной перегрузкой современного читателя — везде идет запрос на «короче, понятней, если куда отсылать — только работающими гиперссылками».

А бумажные книги, кроме перечисленных проблем статей, имеют дополнительные болезни собственных терминологий и концепций, усиленных повторов вводных тем для «герметичности», местами и просто для набирания объема:  
''Самым же плодовитым александрийским ученым был Дидим, сын Дидима, по прозвищу Меднобрюхий: за свою жизнь он написал то ли 3500, то ли 4000 книг, причем сам уже не помнил, о чем он писал, о чем нет, и некоторые книги сочинял по два раза. © Гаспаров, «Занимательная Греция»''.  
С навигацией в книгах еще хуже, а идея ссылаться на другие книги, потому что они «где-то изданы» и их «может быть можно купить или найти в какой-нибудь библиотеке» вовсе порочна — информация должна быть доступна и проверяема, здесь и сейчас.

Собственно, если книги работали, то не было «преподаватель прочтет курс по книге» — выдавались бы учебники, и никто не листал бы слайды, не мазался мелом у доски, не записывал видеоролики. Не знаю, пишут ли сейчас студенты конспекты — но в наше время, хорошие конспекты, с выделениями маркером, компактными «прорубающими» рисунками от осознавшего, ценились сильно больше учебников даже по классическим темам. А уж для обучения современным IT-технологиям, софту и алгоритмам, бумажные книги стали совершенно негодны <ref name="cite-ref-20240629H" />.

Со стороны автора писать-публиковать книгу — это тоже мучение — как долгий процесс возни с издательством, так и страдания от невозможности переписать все или часть, реструктурировать или выкинуть куда-то боковые ветки, особенно если тема — что-то меняющееся и живое, а в Computer Science и IT именно так.

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

Но довольно быстро это привело к двум противоположным перекосам — с одной стороны «слайдоментам», где на каждый лист трамбуется содержание целой статьи, и это становится невозможно показать как презентацию, с другой — перекос в модный «рекламный стиль», с утратой содержательной глубины. Впрочем, большая часть докладчиков до сих пор просто зачитывает чуть сокращенный неструктурированный и нераскрашенный текст со слайдов, добиваясь «информационной интерференции» — слушатель-читатель засыпает. Это мой опыт десятков лет организации IT и научных конференций, тренинга докладчиков, переверстки их слайдов, и боль от тонн монотонных докладов, опубликованных на ресурсе автора <code>0x1.tv</code>, которые не смотрят, несмотря на все старания по оптимальной видеопубликации. Отдельная боль — фреймворк научных презентаций <code>beamer</code>, решивший проблему «принести нормальные TeX-формулы на слайды», но делающий эти слайды скучными, причем мучительно — ведь любая latex-верстка не совместима с мышлением над основной идеей.

Удивительно, что все эти проблемы опять обусловлены «страничным ограничением», унаследованным с времен, когда докладчик вручную переворачивал листы на бумажном флипчарте, а теперь, в силу технологических традиций, привык листать кликером или выкрикивать «следующий слайд, пожалуйста».

=== Проблемы майндмапов и визуальных досок ===
Вырваться за «пределы листа» пытались многие — математики-физики, пытающиеся провести (с лестницами!) лекции на куче досок, изобретатели разного вида «визуального мышления» — майндмапов, бесконечных электронных досок и т.п.

Как практикующий электронные «майндмапы» уже десятки лет, я соглашусь, что это один из эффективных методов визуального размышления над проблемой и порождения «быстрой инфографики» по исследуемой теме, прямо в процессе размышления или коллективного мозгового штурма. Но стоит сразу признать и проблемы — практически никто, кроме меня, использующего «подвесной компьютер» и слепое владение клавиатурой, не мог делать эффективные рассказы по майндмапам — остальные или фейлили презентацию, или нарубали их на слайды — «обманули кондуктора, купили билет и не поехали»©. Та же история с попытками презентаций на электронных виртуальных досках типа Miro.

Тут надо пойти против «аксиомы основателей майндмапинга», что визуальное мышление должно быть «радиантным во все стороны» — при рассказе важно поддерживать последовательный нарратив, а для этого должна быть история и выделенное для нее направление. Еще в нулевые, экспериментируя с майндмап-стилями, я понял, что если делать майндмапы, где история «вытянута по вертикали», а структура и глубина концепций — по горизонтали<ref>Это естественно для любой письменной культуры, может кроме японии и R2L-языков</ref>, их можно эффективно рассказывать любой аудитории, по мере необходимости погружаясь в глубину темы, но при этом держа контроль за последовательностью и основными идеями. Не говоря уж о том, что вместо виртуозного владения клавиатурой достаточно «скроллинга колесом мыши», или чего-то подобного.

И идея написать идеальный коллаборативный майндмаппер для совместной работы команд не покидала меня давно, и я даже сделал несколько попыток, убедившись, что для успеха важнее другое…

=== Что ожидается от инструмента ===
Для научного материала критично важна «легкость формул»: TeX-формулы могут возникнуть в любом месте, они не должны быть специальным «объектом».

Форматирование для рассказа-презентации должно быть умным, и адаптивным — важное автоматически должно быть больше, неважное и более детальное — меньше, и при этом чтобы было можно мгновенно выделить специальным цветом-стилем любое слово, и даже символ. Да, современные слайд-средства это предлагают для верстки списков, но по совокупности факторов — ограничение листа, визуальная несвязность списков… все пытаются втискивать туда абзацы текста, а уж с мгновенной стилевой разметкой за пределами «болд-италик» до сих пор везде и все плохо.

Чтобы использовать в команде или со студентами — это должно быть что-то уже почти понятное и привычное — практически нереально «продать» новый инструмент-сервис, с новым интерфейсом, каким бы прекрасным он ни был, не говоря уж о том, что тут требуется эффективная работа с клавиатурой — а «погружение хоткеев в костный мозг» это долго, больно… и 100500 ITшных конфликтов в духе «Vim vs Emacs», «Tab vs Spaces» они от этого. Оно не должно «бить током» новичков — как делает какой-нибудь не собирающийся latex, плюющийся каббалистическими ошибками.

Нужна интеграция с «живыми артефактами» — кодом, jupyter-ноутбуками, самовизуализирующимися алгоритмами <ref name="cite-ref-20240629H" /> — все это должно жить вместе с ними, в одной среде и жизненном цикле, в единой системе управления версиями, иначе все это ждет судьба «самопротухающей документации» к ПО, или самоустаревающих унылых книг по программированию с криво набитыми примерами.

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

В результате многих экспериментов <ref name="cite-ref-20230128F" />, я понял, что проще всего стартовать с готовой платформы, являющейся де-факто стандартом для ITшников — <code>code-server</code>/<code>code-oss</code>/<code>vscode</code> — далее здесь — <code>Code</code>, и использовать Markdown.

=== Code, Markdown и специальные CSS ===
Markdown стал доминирующей плоской разметкой, с нулевой кривой входа, известной всем околоайтишникам и ИИ, и по сути похоронил массовое использование <code>SGML</code>, <code>[X]HTML</code>, <code>Dita</code>, <code>LaTeX</code>, <code>AsciiDoc</code>, <code>RST</code>, <code>[Media]Wiki</code> и прочих, возможно более умных разметок. Может это и к лучшему, поддержка Markdown в <code>code-server</code>, с LaTeX-формулами-графами и кучей других возможностей позволяет эффективно делать и техдокументацию и обучающие материалы, не заморачиваясь с проблемами страничной «версткой книг», и не используя монструозные решения типа <code>pandoc</code>.

Особенность Markdown среди других плоских разметок в том, что он максимально использует «интуитивное структурирование» понятное человеку при работе с плоским текстом — пустые пространства и отступы, как и в Python — самом интуитивном языке программирования. Такого, например, нет в вики-разметках, т.к. они придумывались чтобы работать внутри textarea браузера, и там нельзя использовать основной механизм отступов — <code>TAB</code>/<code>SHIFT-Tab</code> — это будет уводить из редактируемой области. А в отличие от теговых форматов, разметки-выделения в Markdown компактны и с помощью <code>Code</code> вводятся мгновенно — все эти <code>*</code>, <code>~</code>, <code>`</code> и прочие скобки умеют окружать блоки текста одним нажатием клавиши. Осталось приспособить это для «инфографических конспектов», приучив себя, студентов и прочих писать максимально коротко, и так, чтобы «предпросмотр» можно было показывать как презентацию!

Оказалось, что первый и основной шаг к этому можно сделать даже не реализуя специальных расширений для <code>Code</code>, а просто поиграв с настройками и подключив специальные CSS-стили. Так появился проект [https://gitverse.ru/belonesox/code-notes-infograph gitverse.ru/belonesox/code-notes-infograph], стимулирующий писать кратко и показывать структурированный майндмап с визуально связанной иерархией. С ним можно быстро структурировать мысли даже не глядя на мгновенный предпросмотр, не заморачиваясь разбиением на слайды-страницы, выращивая «скелет-майндмап» слева, и заполняя лакуны справа плавающими иллюстрациями. Конечно, это надо видеть, и черно-белой печати это не передать, надеюсь вы посмотрите доклад или его конспект и другие примеры.

Эти конспекты прекрасно понимают не только люди, но и ИИ! С ИИ можно, например, быстро раскрасить их с помощью идеограмм, оживив представление (ведь эмодзи уже можно использовать даже в коде <ref name="cite-ref-20230128F" />), или наоборот, развернув их в статью в Word/LaTeX, если нужно публиковать идею по принятым стандартам, или просто обсудив корректность идей. Кстати, сами конспекты ИИ пока делает плохо, он хорош в «наливании воды», а сделать «компактно и понятно человеку» — остается задачей автора.

Но главное — это удобно использовать на лекциях-созвонах, или для записи обучающих видеороликов <ref name="cite-ref-20190126Q" />, презентуя прямо в предпросмотре <code>Code</code> такие «неограниченные свитки» — в современном мире это удобней слайдов для демонстрации, т.к. в большинстве случаев докладчик сидит у компьютера, ему удобно скроллировать, искать, делать гиперпереходы, использовать рисование <ref name="cite-ref-20140126-4" />… да и при редких теперь выступлениях в зале-аудитории, есть девайсы, позволяющие совместить это с театральщиной.

А для того, чтобы это стало переносимым отчуждаемым, написано расширение «Freeze Markdown» [https://gitverse.ru/belonesox/freeze-markdown-vscode-ext https://gitverse.ru/belonesox/freeze-markdown-vscode-ext], позволяющее «заморозить» текущий предпросмотр в HTML, с возможностью встроить туда все картинки — и получить самостоятельный артефакт для пересылки-публикации, в отличие от какого-нибудь PDF, самоадаптирующийся к любым экранам и размерам шрифтов, и открывающий все медиавозможности современного веб.

=== Живые иллюстрации через микровидео ===
Полноценная «живая инфографика» всегда считалась крутой, но дорогой, и хотя давно были инструменты генерации научных видеороликов типа Manim, см. <ref name="cite-ref-3blue1brown" />, использовали их только энтузиасты — это было долго, дорого и больно, большие видео трудно было развивать и поддерживать (почти все сценарии роликов 3Blue1Brown сломаны и сейчас не соберутся), рендеринг большого видео долгий и цикл отладки становится все тяжелее с ростом объема. Да и смотреть их было тяжеловато — «ничего непонятно, но очень интересно». Большое видео все-таки неудобно для того, чтобы быстро вспомнить предыдущую концепцию («где там это было?»), параллельно смотреть на визуализацию нескольких идей, быстро листать и искать…

Но в процессе экспериментов, я обнаружил, что если не гнаться за длинными роликами, а визуализировать саму суть утверждений «по месту» с помощью «зацикленных микровидео» по 10–60 секунд, «живых фотографий» понятий и идей, то убивается несколько зайцев. Они легко встраиваются в повествование, не перегружая контекст, и их очень легко делать с ИИ, скармливая ему просто кусок только что составленного конспекта — «визуализируй это с помощью Manim», бросая в ИИ сгенеренный ролик и комментарии «это сделай пониже, а тут стрелки уехали», а всякое простое легко изменить вручную. Или вовсе использовать сервисы ИИ-видеогенерации — короткие ролики это практически бесплатно — если что не так, легко перезаказать.

Единственное, тут начинал жать «стандартный Markdown», в котором видео вставлялось некомпактно, да и напрягали некоторые другие ограничения.

=== Лаконичный Markdown ===
Некоторые вещи в Markdown можно улучшить «не отходя от кассы», не изобретая нестандартных расширений (pandoc-подход), не добавляя новых элементов разметки, а только расширяя идеи, уже заложенные в Markdown, позволяя той же разметкой делать что-то компактней и лучше.

Как говорили выше, в образовательных материалах и технической документации полезно вставлять маленькие иллюстрирующие медиаролики. Но классический подход с тегами <code>&lt;div&gt;&lt;video …&gt;…&lt;/video&gt;</code> очень монструозен, ведь таких «картинок» может быть много. Поэтому мы расширяем функциональность «включения» совместимо с Markdown-расширением <code>image size</code>, включая не только картинки — <code>![ALT](./путь-к-картинке.png =WxH)</code>, но и видео <code>![класс и стили](./путь-к-видео.webm =WxH)</code>, лаконично руля и размерами, и стилями («плавающий справа»).

Также больным местом является трансклюзия других Markdown-документов — то, что есть практически во всех остальных разметках (LaTeX/SGML Docbook/MediaWiki/RST/…), но отсутствует «из коробки» в Markdown. Такую же «трансклюзию» мы получаем, расширяя семантику «включения»: <code>![класс и стили](./путь-к.md)</code>.

Еще одной частой необходимостью является автоматическая гиперлинковка на лежащие рядом Markdown-документы и другие программные артефакты. Для этого «кодовые» литералы, начинающиеся с <code>./</code>, например <code>./путь-к/какому-то/артефакту.py</code>, автоматически превращаются в гиперссылку относительно текущего пути.

Если же ссылка указывает на Markdown-документ, то литерал вида <code>./путь-к/какому-то/артефакту.md</code> в HTML автоматически превращается в ссылку <code>./путь-к/какому-то/артефакту.html</code>. Это позволяет из набора Markdown-документов сформировать связанную техническую документацию или базу знаний.

Остается только поддерживать умные гиперссылки и в самом исходном Markdown-тексте, чтобы получить «базу знаний» с которой можно работать без переключений в режим редактирования, делать их компактными, чтобы они могли ссылаться хитрым образом с поиском на кодовые базы программных проектов, юпитер-ноутбуки или самовизуализирующиеся алгоритмы <ref name="cite-ref-20240629H" /> — и для этого мы разрабатываем расширение «code-links», но это тема отдельного рассказа.

=== Практическое применение ===
Инструмент опробован не только для преподавания студентам и школьникам, не только в командной работе IT-профессионалов — для ведения требований-отчетов-техдокументации, но и в новой парадигме обучения <ref name="cite-fcromt" />, когда студенты сами или с помощью ИИ, изучают неизвестные темы по свежим научным статьям или редким книгам, конспектируя и «презентуя» их.

Да, по этому тексту трудно понять о чем речь, и бесполезно добавлять иллюстрации — как через черно-белый телевизор 50-х годов рекламировать цветной экран во всю стену из 2020-х. Но если кто все-таки откроет этот текст, откройте с примерами
* https://академон.эвристика.рф/public/fc/oseduconf/2026/mind-infographic/mind-infographic.html
* [https://алгоритмы.испран.рф/public/ae/code-notes-infograph/idea.html Вот старые наброски с видео по теме]


=== Источники ===
<ref name="cite-ref-20140126-4">Фомин, С. А. ''Магия пера или эффективная свобода преподавания со стилусом'', // OSEDUCONF-2014 // Девятая конференция «Свободное программное обеспечение в высшей школе» : Тезисы докладов, Переславль, 25–26 января 2014 года. — Переславль: Альт Линукс, 2014. [https://0x1.tv/20140126-4 https://0x1.tv/20140126-4]</ref>
<ref name="cite-ref-20200208Q">Фомин, С. А. ''Udaff — русский пиктографический Python. От элементарных алгоритмов до гомоморфного шифрования'' // Свободное программное обеспечение в высшей школе : Сборник тезисов XV конференции, Переславль, 07–09 февраля 2020 года / Отв. редактор В. Л. Чёрный. — Переславль: ООО «МАКС Пресс», 2020. — С. 121–127. — EDN JZBFRI. [https://0x1.tv/20200208Q https://0x1.tv/20200208Q]</ref>
<ref name="cite-ref-20190126Q">Фомин, С. А. ''OBS — швейцарский нож передачи знаний. Боевые приёмы Open Broadcaster Software'' // Свободное программное обеспечение в высшей школе : Сборник тезисов Четырнадцатой конференции, Переславль, 25–27 января 2019 года / Ответственный редактор В. Л. Чёрный. — Переславль: ООО «МАКС Пресс», 2019. — С. 82–92. [https://0x1.tv/20190126Q https://0x1.tv/20190126Q]</ref>
<ref name="cite-ref-20230128F">Фомин, С. А. ''Современные «интерактивные среды» и «живые лаборатории» — эффективное дистанционное образование по алгоритмам и математическим дисциплинам'' / С. А. Фомин // Восемнадцатая конференция. Свободное программное обеспечение в высшей школе : Тезисы докладов материалов конференции, Переславль-Залесский, 27–29 января 2023 года / Отв. редактор В. Л. Чёрный. — Москва: ООО «МАКС Пресс», 2023. — С. 63–64. — EDN GIZTTL. [https://0x1.tv/20230128F https://0x1.tv/20230128F]</ref>
<ref name="cite-ref-20240629H">Фомин, С. А. ''PyAlgovizualizer — эффективное преподавание алгоритмов'' / С. А. Фомин // Девятнадцатая конференция «Свободное программное обеспечение в высшей школе» : Материалы конференции, Переславль-Залесский, 28–30 июня 2024 года. — Москва: ООО «МАКС Пресс», 2024. — С. 69–75. [https://0x1.tv/20240629H https://0x1.tv/20240629H]</ref>
<ref name="cite-ref-3blue1brown">''Прекрасные примеры визуализации при разборе математических вопросов и IT технологий''. [https://www.3blue1brown.com https://www.3blue1brown.com]</ref>
<ref name="cite-fcromt">Фомин, С. А. ''Flip Classroom One More Time — интерактивность и асинхронность в эффективных курсах на open-source'' / С. А. Фомин // Двадцатая конференция «Свободное программное обеспечение в высшей школе» : Материалы конференции, Переславль-Залесский, 7–9 февраля 2025 года. — Москва: ООО «МАКС Пресс», 2025. [https://0x1.tv/fcromt https://0x1.tv/fcromt]</ref>

<references />

[[Категория:OSEDUCONF-2026]]
[[Категория:Markdown]]
[[Категория:Документирование]]