Мобильная LMS: как понять, что отдельному приложению есть работа

Родитель открывает расписание двух детей между станциями метро. Ему нужна минута: проверить уроки на завтра, оценки и домашние задания. Если в этот момент показать ему мобильную версию всей LMS с курсами, отчётами и инструментами преподавателя, получится экскурсия по школе вместо ответа на простой вопрос.

Запрос «к веб-версии нужно ещё приложение» звучит просто. Но за ним стоят отдельная разработка и выпуск, проверка на разных устройствах, публикация в App Store и Google Play и дальнейшая поддержка после обновлений.

Поэтому начинать стоит не с решения «делаем приложение», а с учебной ситуации. Что именно телефон должен изменить для ученика, преподавателя или родителя? Если ответ сводится к уменьшенной копии личного кабинета, сначала стоит привести в порядок мобильный веб. В Qtim мы придерживаемся этого подхода при разработке EdTech-платформ: сначала определяем сценарий и его ценность для пользователя, а уже затем выбираем технологический формат.

Телефон должен получить отдельную задачу

Отдельное приложение имеет смысл при двух условиях. Смартфон даёт учебному сценарию полезную возможность за пределами браузера. Человек возвращается к этому сценарию достаточно часто, чтобы установка окупилась удобством.

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

PWA хватает для коротких возвращений с телефона

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

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

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

Формат онлайн-урока определяет устройство

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

Офлайн начинается после кнопки «Скачать»

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

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

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

Шесть курсов в вебе: карточки ещё не делают приложение

Короткие занятия хорошо ложатся на телефон: повторить карточки, пройти один тест, разобрать ошибки.

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

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

460 экзаменов с камерой — и ни одного мобильного клиента

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

В платформе аттестации для Университета Льва Толстого экзаменационный контур вынесен в отдельный клиент: кандидат проверяет камеру и микрофон, включает запись видео, звука и экрана, затем сдаёт письменную или устную часть. Мобильного клиента в проекте нет. Экзамен проходит на площадке, в корпусе и аудитории, с фиксацией личности и записью экрана. Устройство здесь определяет регламент.

Через платформу прошли около 460 кандидатов. До разработки мы описали весь путь записи: создание файла, временное хранение, загрузку, доступ проверяющего и удаление. Камера занимает один элемент интерфейса; большая часть системы начинает работать после нажатия.

Три месяца на дневник, а не на всю LMS

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

Так мы разделили контуры в «Онлайн-школе №1». Учебное ядро осталось в вебе, а для родителей мы собрали мобильный дневник на Flutter поверх NestJS-бэкенда действующей платформы. Первую версию (MVP) сделали за три месяца. В неё вошли расписание, оценки, домашние задания, посещаемость, записи занятий и переключение между детьми в одном аккаунте.

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

У каждой роли остался короткий маршрут, а общие данные живут в одном бэкенде. Получилось ровно то разделение, с которого началась статья: уроки — в вебе, дневник — в телефоне.

Пуши подождали до второй волны

Оплату и чаты тоже перенесли на следующие этапы: ежедневный родительский сценарий уже работал без дополнительных функций.

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

Копия веб-кабинета превращает каждое изменение в два выпуска

У приложения появляется собственная жизнь ещё до публикации. Команда настраивает сертификаты и подписи, готовит страницы в сторах, запрашивает разрешения и проверяет сборки на разных устройствах. После запуска этот цикл повторяется с каждым заметным обновлением.

Flutter позволяет вести один мобильный продукт для iOS и Android, когда экраны и основная логика совпадают. Публикация, тестирование и часть интеграций с возможностями телефона всё равно остаются раздельными. Полная копия веб-кабинета заставит каждую новую роль, оценку или отчёт приезжать сразу в два интерфейса.

Поэтому бэкенд строим по принципу API-first: бизнес-логика, роли, права, прогресс и аналитика остаются на сервере, а веб и приложение используют общий серверный API как разные клиенты. Такой подход позволяет добавить мобильный сценарий после проверки спроса, не перевозя LMS целиком в новый интерфейс.

Пять вопросов отделяют учебный сценарий от списка экранов

• В какой момент обучения человек берёт телефон: по дороге к занятию, во время задания или между уроками?

• Какую короткую задачу он должен завершить за один заход?

• Что мешает пройти этот путь в мобильном браузере: связь, работа с файлами, камера, микрофон или переход из уведомления?

• Кому нужен мобильный маршрут — ученику, родителю, преподавателю или куратору — и какая часть LMS нужна этой роли?К

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

Ответы обычно приводят к одному из четырёх вариантов: адаптивный веб, PWA, отдельное мобильное приложение или специализированный клиент для контролируемого процесса. Название технологии появляется после маршрута пользователя.

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