Migc — различия между версиями

Материал из 0x1.tv

(Новая страница: «Ссылки к докладу «Инфографические конспекты» * https://академон.эвристика.рф/public/fc/oseduconf/2026/m…»)
 
Ссылки к докладу «Инфографические конспекты»
* https://академон.эвристика.рф/public/fc/oseduconf/2026/mind-infographic/mind-infographic.html

<ref name="citeproc" />

= Инфографические конспекты  от унылых страниц к компактным и живым свиткам =
'''Стас Фомин'''  
Москва  
ИСП РАН, МФТИ  

* [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]

'''Аннотация'''  
Статьи и книги в современном мире неэффективны для передачи знаний  нужно компактно, нескучно и понятно, используя максимальную визуальность и все доступные технологии  цвета, диаграммы, видео, 3D-модели…  
Альтернативные форматы: слайды, презентации, майндмапы, визуальные доски  пытаются решить эту проблему, но тоже концептуально негодны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Что ожидается от инструмента ===
Для научного материала критично важна «легкость формул»: 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://0x1.tv/Migc https://0x1.tv/Migc].

=== Источники ===
<references />
<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>

Версия 13:17, 21 января 2026

Ссылки к докладу «Инфографические конспекты»

[1]

Инфографические конспекты — от унылых страниц к компактным и живым свиткам

Стас Фомин Москва ИСП РАН, МФТИ

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

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

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

Инструмент опробован не только для преподавания и командной работы IT-профессионалов, но и в новой парадигме обучения [2], когда студенты сами или с помощью ИИ изучают неизвестные темы, рассказывая и презентуя темы по свежим научным статьям или редким книгам. А технически это набор open-source проектов: CSS-стилей и расширений к code-server/code-oss/vscode.

Книги и статьи уже неэффективны для передачи знаний

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

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

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

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

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

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

Проблемы презентаций

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

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

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

Проблемы майндмапов и визуальных досок

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

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

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

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

Что ожидается от инструмента

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

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

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

Нужна интеграция с «живыми артефактами» — кодом, jupyter-ноутбуками, самовизуализирующимися алгоритмами [3] — все это должно жить вместе с ними, в одной среде и жизненном цикле, в единой системе управления версиями, иначе все это ждет судьба «самопротухающей документации» к ПО, или самоустаревающих унылых книг по программированию с криво набитыми примерами.

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

В результате многих экспериментов [4], я понял, что проще всего стартовать с готовой платформы, являющейся де-факто стандартом для ITшников — code-server/code-oss/vscode — далее здесь — Code, и использовать Markdown.

Code, Markdown и специальные CSS

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

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

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

Эти конспекты прекрасно понимают не только люди, но и ИИ! С ИИ можно, например, быстро раскрасить их с помощью идеограмм, оживив представление (ведь эмодзи уже можно использовать даже в коде [4]), или наоборот, развернув их в статью в Word/LaTeX, если нужно публиковать идею по принятым стандартам, или просто обсудив корректность идей. Кстати, сами конспекты ИИ пока делает плохо, он хорош в «наливании воды», а сделать «компактно и понятно человеку» — остается задачей автора.

Но главное — это удобно использовать на лекциях-созвонах, или для записи обучающих видеороликов [5], презентуя прямо в предпросмотре Code такие «неограниченные свитки» — в современном мире это удобней слайдов для демонстрации, т.к. в большинстве случаев докладчик сидит у компьютера, ему удобно скроллировать, искать, делать гиперпереходы, использовать рисование [6]… да и при редких теперь выступлениях в зале-аудитории, есть девайсы, позволяющие совместить это с театральщиной.

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

Живые иллюстрации через микровидео

Полноценная «живая инфографика» всегда считалась крутой, но дорогой, и хотя давно были инструменты генерации научных видеороликов типа Manim, см. [7], использовали их только энтузиасты — это было долго, дорого и больно, большие видео трудно было развивать и поддерживать (почти все сценарии роликов 3Blue1Brown сломаны и сейчас не соберутся), рендеринг большого видео долгий и цикл отладки становится все тяжелее с ростом объема. Да и смотреть их было тяжеловато — «ничего непонятно, но очень интересно». Большое видео все-таки неудобно для того, чтобы быстро вспомнить предыдущую концепцию («где там это было?»), параллельно смотреть на визуализацию нескольких идей, быстро листать и искать…

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

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

Лаконичный Markdown

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

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

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

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

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

Остается только поддерживать умные гиперссылки и в самом исходном Markdown-тексте, чтобы получить «базу знаний» с которой можно работать без переключений в режим редактирования, делать их компактными, чтобы они могли ссылаться хитрым образом с поиском на кодовые базы программных проектов, юпитер-ноутбуки или самовизуализирующиеся алгоритмы [3] — и для этого мы разрабатываем расширение «code-links», но это тема отдельного рассказа.

Практическое применение

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

Да, по этому тексту трудно понять о чем речь, и бесполезно добавлять иллюстрации — как через черно-белый телевизор 50-х годов рекламировать цветной экран во всю стену из 2020-х. Но если кто все-таки откроет этот текст, заходите по ссылке, там будет презентация и множество дополнительных ссылок с примерами: https://0x1.tv/Migc.

Источники

  1. Ошибка цитирования Неверный тег <ref>; для сносок citeproc не указан текст
  2. Ошибка цитирования Неверный тег <ref>; для сносок cite-fcromt не указан текст
  3. Ошибка цитирования Неверный тег <ref>; для сносок cite-ref-20240629H не указан текст
  4. Ошибка цитирования Неверный тег <ref>; для сносок cite-ref-20230128F не указан текст
  5. Ошибка цитирования Неверный тег <ref>; для сносок cite-ref-20190126Q не указан текст
  6. Ошибка цитирования Неверный тег <ref>; для сносок cite-ref-20140126-4 не указан текст
  7. Ошибка цитирования Неверный тег <ref>; для сносок cite-ref-3blue1brown не указан текст

[1] [2] [3] [4] [5] [6]

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