Интерактивная доска и общий холст

Кратко

Общий холст – доска, на которой все участники живого занятия рисуют одновременно. Выглядит он как видео, но устроен совсем иначе: система синхронизирует не поток пикселей, а небольшой документ фигур, и браузер каждого учащегося отрисовывает его сам. Сложность в том, чтобы все копии документа оставались одинаковыми, когда его правят много людей сразу. Для этого есть три стратегии синхронизации: центральный сервер, задающий порядок правок (самый простой вариант), Operational Transformation и бесконфликтные типы данных (CRDT). Второе важное решение – развести данные по двум каналам: постоянному для рисунка и эфемерному для курсоров. Если модель данных выбрана правильно, доска быстрая, восстанавливается после сбоя и выгружается в запись занятия. Если нет, штрихи пропадают, курсоры отстают, а доску невозможно сохранить. Статья простым языком объясняет, как работает синхронизация, чем CRDT отличаются от OT, зачем нужны два канала, как сохранять и выгружать доску, что с доступностью и когда своя разработка выгоднее готового решения.

Зачем это читать

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

Что такое общий холст на самом деле

Общий холст, или интерактивная доска, – это рабочее поле, обычно бесконечное и масштабируемое, на котором несколько участников живого занятия одновременно рисуют, пишут и размещают объекты, и все в реальном времени видят одни и те же изменения. Представьте обычную доску, которая волшебным образом одинакова в комнате у каждого учащегося: преподаватель пишет – и надпись за доли секунды появляется на всех досках.

Архитектуру определяет одно различие. Демонстрация экрана преподавателя передаёт видео экрана – поток пикселей, который класс смотрит, но не может изменить. Общий холст устроен наоборот: он передаёт крошечное описание того, что нарисовать («красная линия отсюда сюда», «слово „фотосинтез“ вот здесь»), а рисует уже браузер каждого учащегося. Поток пикселей мы разбираем в статье демонстрация экрана для преподавания; холст – её противоположность.

Поэтому думать об общем холсте нужно как о синхронизируемом документе фигур, а не как о видео. Доска на экране – лишь отрисовка небольшой структуры данных в одном браузере: списка объектов, у каждого из которых есть тип, позиция, цвет и ещё пара свойств. Если этот список надёжно синхронизирован у всех, картинка будет правильной сама собой. За счёт этого доска остаётся чёткой при любом масштабе, весит килобайты, а не мегабиты, и её можно сохранить, искать по ней и выгрузить, тогда как запись демонстрации экрана – просто плоский ролик.

Нажмите, чтобы увеличить

Почему доска окупает свой бюджет

Начнём с педагогики: именно она оправдывает работу. Общее поле для рисования повышает вовлечённость: учащиеся вместе создают идеи, а не пассивно смотрят, и даже молчаливый ученик, который никогда не включит микрофон, может добавить на доску стикер. В исследовании дистанционных занятий по иммунологии студенты-медики высоко оценили цифровую доску: она помогала понять абстрактные понятия и удерживала внимание на занятии (Mendez Reguera, Lopez, Computers & Electrical Engineering, 2021). Доска превращает одностороннюю лекцию в рабочее пространство.

То же исследование честно говорит и об ограничениях: даже с доской удалённые студенты чувствовали себя менее вовлечёнными, чем в аудитории, так что инструмент помогает, но живую аудиторию не заменяет. Добавим очевидное из практики: пустая доска без задания так и остаётся пустой, а тормозящая или ненадёжная доска вредит занятию, потому что учащиеся перестают ей доверять. Вывод для продуктовой команды: доска – не галочка в списке функций, её отзывчивость и надёжность и есть функция. Доска, которая теряет штрихи, отучает ею пользоваться, и это хуже, чем не выпускать её вовсе. Отсюда высокая планка для движка синхронизации.

Суть задачи: держать все копии одинаковыми

Раз доска – общий документ, главная трудность – согласованность: когда правят двадцать пять человек сразу, все копии документа должны быстро прийти к одному состоянию. Двое тянут одну фигуру, третий её удаляет, преподаватель рисует поверх – а в итоге у всех должна остаться одна и та же доска. Надёжно гарантировать это можно тремя способами, и от выбора зависит всё остальное.

Способ первый – порядок задаёт центральный сервер. Самая простая и для класса обычно лучшая модель: каждая правка идёт на один сервер, он выбирает порядок, применяет правки и рассылает результат. Конфликты решает простое правило, обычно «побеждает последняя запись» (last-writer-wins, LWW) для конкретного свойства конкретного объекта. Так работает холст Figma: серверы хранят последнее значение, которое любой клиент прислал для каждого свойства каждого объекта. Если двое правят разные свойства, конфликта нет; если одно и то же свойство одного объекта, документ хранит значение, которое пришло на сервер последним (Figma, How Figma's multiplayer technology works, 2019). Инженеры Figma отмечают, что это похоже на регистр LWW из литературы о CRDT, но раз порядок событий задаёт единственный сервер, весь механизм CRDT им не нужен. Для живого занятия, где сервер всегда доступен, а учащиеся онлайн, это самая компактная надёжная схема.

Способ второй – Operational Transformation (OT). На OT исторически построены совместные текстовые редакторы (классический пример – Google Docs). Каждая правка сохраняется, но входящие правки преобразуются с учётом уже случившихся, чтобы сохранить смысл. Если вы вставляете фигуру в позицию 3, пока я удаляю позицию 1, OT переписывает ваше «позиция 3» в «позиция 2», и копии сходятся. OT эффективна и проверена для централизованного редактирования текста, но для сложной графики очень трудоёмка: для каждой пары типов операций нужно правильное преобразование.

Способ третий – бесконфликтные реплицируемые типы данных (CRDT). CRDT – структура данных, устроенная так, что правки могут приходить в любом порядке, даже без центрального сервера, а все копии всё равно автоматически сходятся к одному результату – без преобразований и без арбитра. Платить за это приходится служебными данными: каждая фигура несёт скрытые метаданные (идентификаторы, метки версий), чтобы слияние было однозначным, а это память и трафик. Современные библиотеки CRDT почти сняли прежние проблемы с производительностью: Yjs, самая распространённая CRDT-библиотека для досок, обрабатывает десятки тысяч операций в секунду, а Automerge 2.0 – сотни тысяч нажатий клавиш менее чем за секунду (бенчмарки проектов Yjs и Automerge, 2026).

Если коротко: OT компактнее, но требует центрального сервера и аккуратной логики для каждой операции; CRDT занимают чуть больше памяти, зато сходятся сами и работают офлайн и peer-to-peer. Для одного живого занятия с постоянно доступным сервером центральная схема LWW – самое простое из того, что работает. CRDT берите, когда нужны офлайн-редактирование, peer-to-peer-соединения или доска, которая корректно сливает правки даже при плохой сети. Поэтому Excalidraw и tldraw, две открытые доски, с которых начинает большинство команд, построены на хранилищах в стиле CRDT.

Нажмите, чтобы увеличить

Как передаются правки: WebSocket, WebRTC или оба

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

WebSocket – долгоживущее двустороннее соединение между браузером каждого учащегося и вашим сервером. Это стандартный выбор для синхронизации доски: соединение надёжное, сохраняет порядок сообщений, поддерживается везде и хорошо подходит к схеме «всё идёт через один сервер». Движок синхронизации tldraw, например, держит каждую доску на небольшом серверном экземпляре: тот хранит документ в памяти, применяет каждое входящее изменение и рассылает его всем подключённым клиентам по WebSocket. Так поддерживается порядка десятков одновременных редакторов на доску (tldraw, Announcing tldraw sync, 2024).

WebRTC data channel – прямой канал между браузерами, который передаёт произвольные данные с очень низкой задержкой; он описан в стандартах реального времени (RFC 8831, WebRTC Data Channels, IETF). Он хорош для peer-to-peer-рисования, где важна каждая миллисекунда, но для установления соединения ему нужен сервер, и сам по себе он не масштабируется на большой класс. На практике часто используют гибрид: WebSocket (или сигнальный канал, который уже есть у занятия) для настройки и авторитетного документа, а WebRTC data channel – как дополнительный быстрый путь между участниками. Ваш виртуальный класс и так использует WebRTC для звука и видео (см. WebRTC для живого обучения), поэтому data channel часто уже есть и его можно использовать повторно.

Разумный базовый вариант для учебного продукта – WebSocket к центральному серверу, который владеет документом. WebRTC data channel добавляйте, только когда вы измерили задержку и убедились, что она действительно мешает занятию: в гибридной схеме больше компонентов, которые потом нужно сопровождать.

Два канала: рисунок и курсоры

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

Первый вид – документ, то есть сами фигуры. Ему нужны надёжность и долговечность: штрих преподавателя должен дойти до всех и пережить обновление страницы. Правки документа сравнительно редки (максимум несколько фигур в секунду), и он сохраняется в хранилище, чтобы доску можно было загрузить заново.

Второй – присутствие (awareness): живые курсоры, «кто что выделил», цветные плашки с именами поверх доски. Это частый поток (движущийся курсор шлёт много обновлений в секунду), к тому же эфемерный: вчерашняя позиция курсора никому не нужна, и писать её в сохраняемый документ нельзя. В Yjs это разделение оформлено отдельным протоколом присутствия: словарь, в котором каждому id клиента соответствует маленький JSON-объект (позиция курсора, выделение, имя пользователя). Им обмениваются вживую, но намеренно не хранят, потому что он не должен переживать сессию (документация Yjs, Awareness & Presence). Excalidraw устроен так же: фигуры живут в синхронизируемом документе, а движения курсоров передаются по эфемерному каналу присутствия.

Смешать эти каналы – классическая ошибка, и её цену легко посчитать. Возьмём класс из 25 человек с живыми курсорами: каждый движущийся курсор шлёт 20 обновлений в секунду, и каждое расходится остальным 24 учащимся. Это 25 × 20 × 24 = 12 000 сообщений в секунду. Если пустить их по долговечному каналу документа, а тем более сохранять, база захлебнётся, а рисование начнёт тормозить. По эфемерному каналу, где сообщение забывается сразу после доставки, те же 12 000 сообщений в секунду почти ничего не стоят: они крошечные, не хранятся, и потерять часть из них не страшно.

Нажмите, чтобы увеличить

Сохранение доски и её место в записи занятия

Если доска исчезает в конце занятия, учащийся, который хотел к ней вернуться, остаётся ни с чем. Поэтому сохранение – часть функции, а не доработка на потом, и модель «документ фигур» делает его дешёвым. Доска – небольшая структура данных, поэтому можно сохранить снимок (полный список фигур на определённый момент) в хранилище и позже загрузить доску ровно в том виде, в каком она была. tldraw, например, отдаёт снимок своего хранилища как раз для такого сохранения на сервере, а в Yjs живой документ используется для синхронизации в реальном времени (tldraw, документация Persistence). Сохраняйте снимки периодически во время занятия и при каждом значимом изменении, и учащийся, который обновил страницу или вернулся после обрыва связи, увидит актуальную доску, а не пустую.

Где лежат эти снимки – не только инженерный вопрос. На доске остаются имена авторов фигур, подписи учащихся, иногда их работы целиком, а по каналу присутствия передаются имена участников; всё это персональные данные. С 01.07.2025 ч. 5 ст. 18 152-ФЗ запрещает операции с ПДн граждан РФ в базах данных за пределами России, поэтому сервер синхронизации и хранилище снимков разворачивайте в российском контуре: в своём ЦОДе или российском облаке. По той же причине обычно отпадают зарубежные облачные сервисы синхронизации, которые хранят документ доски у себя.

Добавить доску в запись занятия (о самой записи – в статье запись живых занятий) можно двумя способами. Самый простой – записывать доску вместе со всем остальным, как часть сведённого видео занятия; тогда в записи она будет в виде пикселей. Более полезный способ опирается на модель данных: итоговую доску выгружают в векторный файл (SVG), картинку (PNG) или PDF и прикладывают к занятию для скачивания, и учащиеся получают чёткую масштабируемую копию, а не стоп-кадр из видео. Векторная выгрузка напрашивается сама: доска и так список фигур, и превратить его в SVG несложно. Самые продвинутые системы хранят упорядоченный список правок и умеют воспроизводить построение доски, как короткий ролик. Это наглядно показывает, как строилась схема, но большинству продуктов на старте такая работа не нужна.

Нажмите, чтобы увеличить

Если вы хотите ещё и отслеживать активность на доске для аналитики обучения (кто, когда и сколько внёс), описывайте её как учебные события и не привязывайте аналитику к циклу отрисовки. Стандартный способ записать «Мария добавила на доску 4 фигуры» – xAPI-утверждение; подробнее в статье о трекинге видео через xAPI Video Profile.

Строить или покупать: с чего начать

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

Разумный старт – открытый холст (tldraw или Excalidraw) и слой синхронизации на своём сервере. Своё стоит строить, только когда потребности класса перерастут готовые инструменты: отдельные доски для каждого сессионного зала с привязкой к состоянию, детальный трекинг xAPI, особая выгрузка в вашу LMS. Своя разработка даёт контроль над моделью данных и интеграцией, но обходится в месяцы работы, пока многопользовательское рисование не станет по-настоящему мгновенным; зрелые открытые инструменты этот путь уже прошли. Если ваш заказчик – школа, колледж или вуз, учтите и п. 21 Правил применения ЭО и ДОТ (ПП № 1678 в ред. ПП № 517): программное обеспечение в составе дистанционных технологий должно создаваться и использоваться по законодательству РФ и (или) входить в единый реестр российского ПО. Из-за «и (или)» строгость нормы зависит от толкования, но к государственным заказчикам её на практике применяют жёстко, и собственную доску на открытых библиотеках, развёрнутую в России, здесь обосновать проще, чем зарубежный облачный сервис.

Частая ошибка, которая в демо выглядит нормально

Самый соблазнительный путь – обращаться с доской как с картинкой, а не с документом: синхронизировать отрисованное изображение доски или, хуже того, показывать через демонстрацию экрана приложение для рисования на компьютере преподавателя. В демо с одним ведущим всё прекрасно. Потом учащийся пробует рисовать и обнаруживает, что может только смотреть; доску не выгрузить ни во что, кроме плоской картинки; после обновления страницы всё пропадает, потому что загружать заново нечего; а при увеличении надписи превращаются в кашу. Решение – принцип из начала статьи: синхронизируйте фигуры, а не картинку. Если доска – документ, совместная работа, сохранение, выгрузка и чёткость получаются сами собой.

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

Доступность: осознанно выбирайте технологию отрисовки

Доска – визуальный инструмент, поэтому доступность здесь – полноценное проектное решение, а не финальная полировка. Самый важный выбор – как отрисовывать доску. HTML-элемент <canvas> рисует пиксели без структуры, которую могла бы прочитать программа экранного доступа: его содержимого нет в дереве документа, и для вспомогательных технологий оно ничего не значит, пока вы вручную не добавите текстовую альтернативу. SVG, напротив, рисует фигуры как настоящие элементы в дереве документа со встроенной семантикой, поэтому для интерактивного содержимого, которое должно быть доступным, это лучший выбор (рекомендации W3C по доступности HTML и SVG). Что бы вы ни выбрали, действуют требования WCAG 2.1 уровня AA (рекомендация W3C, 5 июня 2018): у каждого значимого визуального элемента должна быть текстовая альтернатива (критерий 1.1.1 Non-text Content), каждый инструмент рисования должен работать не только с мышью, но и с клавиатуры (критерий 2.1.1 Keyboard), а текст и линии на доске должны соответствовать минимальному контрасту (критерий 1.4.3 Contrast). В России на WCAG 2.1 построен ГОСТ Р 52872-2019; стандарт добровольный, но заказчик может включить его в техническое задание, а для учащихся с ОВЗ ст. 79 273-ФЗ требует специальных условий обучения. Поэтому технологию отрисовки выбирайте с учётом доступности до того, как вокруг неё вырастет вся доска.

Где здесь Фора Софт

Общий холст – задача распределённых систем, которая только выглядит приложением для рисования, и как раз такие задачи мы решаем: состояние в реальном времени, которое должно оставаться одинаковым у множества клиентов. Фора Софт с 2005 года делает ПО для видео реального времени, видеоконференций и виртуальных классов, поэтому одна команда разбирается и в медиаслое, и в сигнальном канале, и в синхронизируемом документе доски и умеет заставить их работать через одно соединение. Мы подключаемся, когда учебному продукту нужна доска, которая работает мгновенно, восстанавливается после сбоев, выгружается в запись занятия и подключена к трекингу. И честно говорим, если открытого холста со слоем синхронизации на вашем сервере уже достаточно и своя разработка не окупится. Во всех наших направлениях – онлайн-обучении, видеоконференциях, телемедицине и стриминге – в основе лежит одно и то же: согласованное состояние в реальном времени.

Главное

• Общий холст синхронизирует документ фигур, а не видео из пикселей: отсюда все его преимущества.
• Выберите модель синхронизации: центральная LWW проще всего для живого класса; CRDT за небольшую цену добавляют офлайн и P2P.
• Передавайте фигуры по надёжному сохраняемому каналу, а курсоры – по эфемерному каналу присутствия; не смешивайте их.
• Сохраняйте снимки с первого дня на своём сервере в России, чтобы после обновления или переподключения возвращалась доска, а не пустая страница.
• Выгружайте доску в SVG, PNG или PDF и прикладывайте к записи занятия: она и так список фигур.
• Ради доступности отрисовывайте доску через SVG, а не canvas, и соблюдайте WCAG 2.1 AA: текстовые альтернативы, клавиатура, контраст.

Что читать дальше

• Виртуальный класс: что это и чем он отличается от встречи
• Сессионные залы: дизайн, состояние и возврат в общий зал
• Запись живых занятий и постобработка для каталога