magistr/UX_IMPROVEMENT_PLAN.md

План улучшения пользовательского взаимодействия Magistr

1. Назначение документа

Этот документ описывает целевое пользовательское взаимодействие для всех ролей Magistr и поэтапный план его улучшения. Главная цель — сделать систему удобной не только на демонстрационных данных, но и в реальной работе университета: при сотнях групп и преподавателей, десятках календарных графиков, большом аудиторном фонде, нескольких версиях расписания и постоянном потоке изменений.

План составлен по текущей реализации frontend, ролевой матрице, API и бизнес-логике проекта. Это экспертный UX-аудит кода и документации, а не замена наблюдению за реальными пользователями. Перед крупными изменениями гипотезы следует проверить на сотрудниках учебного отдела, кафедр, преподавателях и студентах.

2. Краткий вывод

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

Основная UX-проблема — функции организованы преимущественно как набор отдельных форм, таблиц и справочников. Живой пользователь мыслит не сущностями базы данных, а задачами:

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

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

3. Принципы целевого интерфейса

1. Сначала текущая задача, затем справочник. Главный экран роли должен отвечать на вопрос «что требует моего внимания сегодня?».
2. Контекст показывается только там, где влияет на результат. Учебный год, семестр и версия выбираются каскадом внутри профильной вкладки и сохраняются при возврате; общая панель не занимает место в остальных разделах.
3. Поиск вместо прокрутки. Любая коллекция более 20–30 элементов должна иметь поиск, фильтры, сортировку и понятный счётчик результатов.
4. Массовые действия — обязательны. Повторяющиеся операции над группами, графиками, дисциплинами и заявками нельзя заставлять выполнять по одной записи.
5. Безопасность изменений. До сохранения пользователь видит последствия, конфликты и область действия; после сохранения — подтверждение, журнал и возможность отмены там, где это допустимо.
6. Прогрессивное раскрытие. Редкие и сложные параметры скрываются до необходимости, а основной сценарий остаётся коротким.
7. Одинаковые паттерны во всех кабинетах. Поиск, фильтры, статусы, пустые состояния, подтверждения, боковые панели и сообщения работают одинаково.
8. Мобильный интерфейс ориентирован на просмотр и оперативные действия. Большие редакторы могут оставаться desktop-first, но расписание, заявки, статусы и замены должны быть удобны с телефона.
9. Доступность является критерием готовности. Полная клавиатурная навигация, видимый фокус, корректные подписи, контраст, понятные ошибки и отсутствие зависимости только от цвета.

4. Текущее состояние и основные риски

Что уже сделано хорошо

• Роли направляются в подходящие кабинеты, а недоступные разделы скрываются.
• Учебный отдел и администратор могут пройти путь от правил до версии, анализа качества и публикации.
• Для точечных изменений есть сравнение «было / станет» и журнал изменений.
• Кафедра имеет собственную рабочую область, а преподаватель — пожелания, отсутствия и заявки.
• Студенческое и преподавательское расписание имеют недельную навигацию и сохраняют часть локальных настроек.
• У календарного графика есть диапазонное заполнение, а не только изменение каждой даты по отдельности.
• Система использует архивирование и сохраняет исторический контекст.

Критические UX-риски при больших объёмах

Риск	Как проявится у пользователя	Последствие
Полная загрузка коллекций	Долгое открытие разделов групп, пользователей, дисциплин и расписания	Ощущение зависания, лишний трафик, тяжёлый DOM
Длинные селекты	Поиск нужной группы, преподавателя или графика среди сотен элементов	Ошибочный выбор и потеря времени
Нет системной пагинации и сортировки	Таблицы становятся длинными, позиция после действия теряется	Невозможность эффективно обрабатывать реестры
Операции по одной записи	Назначение графиков, подготовка групп и привязок повторяется вручную	Большое число кликов и высокий риск пропусков
Контекст хранится фрагментарно	Год, семестр, версия и фильтры приходится выбирать повторно	Ошибки работы «не в том семестре» или «не в той версии»
Разделы отражают модель данных	Пользователь сам собирает бизнес-процесс из нескольких вкладок	Непонятно, что делать дальше и готов ли процесс
Нативные confirm и prompt	Опасные действия имеют мало контекста, комментарии вводятся в системное окно	Слабая предсказуемость и доступность
Нет общего центра уведомлений	Пользователь узнаёт о новых заявках и решениях только после открытия раздела	Задержка согласований и публикаций
Нет общей модели несохранённых изменений	Переход может привести к потере сложной настройки	Повторная работа и недоверие к системе
Ограниченный экспорт и обмен	Расписание и отчёты сложно передать вне системы	Возврат к скриншотам и ручным таблицам

5. Пользовательские сценарии по ролям

5.1. Администратор

Реальные цели

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

Типичный сценарий сейчас

Администратор входит на дашборд, затем отдельно открывает пользователей, структуру вуза, группы, дисциплины, аудитории, календарные графики и заявки. Формы создания постоянно видимы над реестрами, даже если большую часть времени пользователь только ищет или проверяет записи.

Целевой сценарий

1. На главной странице администратор видит очередь внимания: ожидающие заявки, неполные данные, архивные зависимости, ошибки проверки и недавние действия.
2. Выбирает учебный год внутри мастера подготовки периода.
3. Открывает мастер «Подготовить учебный год» с шагами и прогрессом.
4. Исправляет только отмеченные проблемы через глубокие ссылки на конкретную запись.
5. Выполняет массовое создание или импорт, получает предварительный просмотр и отчёт по строкам.
6. После завершения видит статус готовности по каждому блоку.

Улучшения

• заменить постоянные формы создания кнопкой «Добавить», открывающей боковую панель;
• добавить глобальный поиск по пользователям, группам, кафедрам, дисциплинам и аудиториям;
• добавить фильтры по статусу, роли, кафедре и периоду действия;
• показывать историю записи и зависимые объекты до архивирования;
• добавить импорт пользователей, групп, аудиторий и дисциплин с dry-run-проверкой;
• ввести мастер первоначальной настройки тенанта и нового учебного года;
• показывать «здоровье данных»: группы без графика, дисциплины без преподавателей, аудитории без вместимости/оборудования, незакрытые заявки.

5.2. Учебный отдел

Реальные цели

• подготовить календарную и временную основу семестра;
• убедиться, что кафедры предоставили данные;
• составить расписание без конфликтов;
• сравнить, проверить и опубликовать версию;
• быстро обрабатывать отсутствия, переносы и замены;
• находить свободные аудитории и понимать последствия изменений.

Целевой основной путь «Составить и опубликовать расписание»

1. Выбрать учебный год, семестр и версию в локальной панели конструктора расписания.
2. Открыть чек-лист готовности: календарные графики назначены, дисциплины заполнены, преподаватели привязаны, пожелания рассмотрены, временная сетка настроена.
3. Создать черновик из опубликованной версии или с нуля.
4. Работать в конструкторе с поиском, пакетным добавлением и видимой матрицей ресурсов.
5. Получать конфликт сразу в месте редактирования, с предложенными вариантами решения.
6. Запустить анализ качества, перейти из проблемы прямо к правилу, вернуться с сохранёнными фильтрами.
7. Сравнить версию, проверить число изменений и затронутых групп/преподавателей.
8. Опубликовать с причиной и получить подтверждение доставки изменений конечным пользователям.

Целевой оперативный путь «Изменение в течение семестра»

1. Открыть единую очередь инцидентов: отсутствия, заявки преподавателей, конфликты и ручные изменения.
2. Увидеть приоритет, срок, автора и затронутые занятия.
3. Выбрать предложенную замену или найти ресурс через контекстный поиск.
4. До подтверждения увидеть «было / станет», новые конфликты и список уведомляемых людей.
5. Применить решение пакетом и получить запись в журнале.

Улучшения

• объединить версии, качество и конструктор общим пошаговым контуром, не удаляя отдельные экспертные экраны;
• добавить глобальную панель «Учебный год · Семестр · Версия»;
• ввести автосохранение черновика или явный индикатор «Сохранено / Есть изменения / Ошибка»;
• добавить undo для локально обратимых действий и журнал последних операций;
• сделать массовое назначение правил и слотов нескольким группам;
• добавить боковую инспекцию группы, преподавателя и аудитории без ухода со страницы;
• показывать конфликты и пожелания непосредственно в визуальной сетке;
• добавить командную палитру или быстрый поиск для опытных диспетчеров;
• сохранить представления фильтров: «1 курс ИТ», «вечерние аудитории корпуса Б», «кафедра ВТ».

5.3. Кафедра

Реальные цели

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

Проблема текущей компоновки

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

Целевой сценарий

1. Главная кафедры показывает готовность к семестру и очередь действий.
2. Раздел «Подготовка семестра» группирует дисциплины, преподавателей, привязки и пожелания.
3. Раздел «Нагрузка» показывает отклонения, недогруз и перегруз, а не только список метрик.
4. Раздел «Заявки» объединяет создание преподавателя, отсутствия и изменения занятий со статусами и сроками.
5. После отправки данных кафедра видит, что принято, отклонено или требует уточнения.

Улучшения

• разделить рабочую область на «Обзор», «Дисциплины», «Преподаватели и нагрузка», «Заявки»;
• добавить поиск и фильтры по дисциплинам и преподавателям;
• поддержать вставку строк из Excel/буфера и загрузку файла вместо ручного добавления строк импорта;
• добавить массовую привязку преподавателей к дисциплинам;
• показывать полноту данных по каждой дисциплине;
• отображать нагрузку с нормой, отклонением и объяснением расчёта;
• дать кафедре читаемый timeline заявки и явное следующее действие;
• уведомлять о решениях учебного отдела и администратора.

5.4. Пользователь просмотра расписаний

Реальные цели

• быстро найти расписание группы, преподавателя, аудитории или кафедры;
• переключаться между несколькими результатами;
• распечатать, экспортировать или отправить ссылку;
• понимать, актуально ли расписание и есть ли разовые изменения.

Улучшения

• единая поисковая строка с типизированными результатами: «группа», «преподаватель», «аудитория»;
• недавние и избранные расписания;
• URL, содержащий выбранный объект, семестр, дату и режим представления;
• кнопки «Скопировать ссылку», «Печать», «PDF», «ICS»;
• явная отметка «Опубликовано …», легенда замен и отмен;
• режим сравнения двух расписаний для поиска общего свободного времени;
• сохранение фильтров после перезагрузки и возврата на страницу.

5.5. Преподаватель

Реальные цели

• за несколько секунд увидеть ближайшую пару и аудиторию;
• понять, что изменилось с последнего просмотра;
• сообщить об отсутствии;
• задать доступность и пожелания до составления расписания;
• запросить перенос, аудиторию или отмену и отследить решение.

Целевой сценарий

1. После входа преподаватель видит «Сегодня» и карточку следующего занятия.
2. Изменённые, перенесённые и отменённые пары выделены и объяснены текстом.
3. Из карточки занятия доступны контекстные действия: маршрут до аудитории, заявка на изменение, добавление в календарь.
4. Заявка создаётся с уже заполненными данными занятия; система сразу показывает допустимые даты, пары и аудитории.
5. Статус заявки меняется в понятном timeline и сопровождается уведомлением.

Улучшения

• сделать «Сегодня / Неделя / Семестр» тремя явными режимами;
• добавить карточку следующего занятия и блок недавних изменений;
• показывать корпус, этаж и оборудование аудитории;
• сохранить черновик длинной заявки при случайном закрытии;
• объяснять разницу между строгой недоступностью и мягким пожеланием до выбора режима;
• добавить массовое заполнение предпочтений: копирование дня, диапазон пар, типовая неделя;
• показывать дедлайн подачи пожеланий и статус согласования;
• добавить экспорт в личный календарь и подписку ICS.

5.6. Студент

Реальные цели

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

Проблема масштаба

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

Улучшения

• первый запуск: поиск группы по названию с подсказками по специальности, курсу и кафедре;
• после выбора сделать группу постоянным профилем, а смену вынести в отдельное действие;
• стартовый режим «Сегодня», ниже — «Завтра» и ближайшее изменение;
• добавить быстрый переход «Эта неделя / Следующая неделя»;
• показывать статус обновления расписания и понятную легенду изменений;
• добавить shareable URL, печать, PDF и ICS;
• предусмотреть кеш последнего расписания для слабой сети;
• на мобильном устройстве использовать карточки дней и sticky-навигацию, а не уменьшенную широкую таблицу.

6. Сквозные процессы между ролями

6.1. Подготовка семестра

Администратор настраивает структуру и справочники
        ↓
Кафедра заполняет дисциплины, преподавателей и пожелания
        ↓
Учебный отдел проверяет готовность календарей и данных
        ↓
Учебный отдел создаёт и проверяет черновик
        ↓
Публикация → преподаватели, студенты и просмотр расписаний

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

6.2. Отсутствие и замена

Преподаватель сообщает об отсутствии
        ↓
Кафедра подтверждает факт
        ↓
Учебный отдел выбирает решения по затронутым занятиям
        ↓
Расписание изменяется, решение попадает в аудит
        ↓
Преподаватель и затронутые группы получают уведомление

Все роли должны видеть один и тот же номер инцидента, единые статусы и хронологию, но разные доступные действия.

6.3. Заявка на изменение занятия

Нужна единая модель статусов: Черновик → Отправлена → Проверяется → Требует уточнения / Одобрена / Отклонена → Применена. Технические статусы API можно сохранить, но UI должен переводить их в понятный язык и показывать следующее действие.

7. Масштабирование интерфейса

7.1. Реестры

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

• серверная пагинация или cursor pagination;
• серверные поиск, фильтрация и сортировка;
• размер страницы 25/50/100;
• строка поиска с задержкой 250–400 мс и отменой предыдущего запроса;
• sticky-заголовок таблицы;
• сохранение фильтров в URL;
• выбор строк и массовая панель действий;
• счётчик «Показано N из M»;
• настраиваемые столбцы для сложных реестров;
• виртуализация только там, где пагинация мешает задаче, например в большой визуальной матрице.

7.2. Поиск сущностей

Селекты с большими наборами следует заменить асинхронным комбобоксом:

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

7.3. Календарные графики

При десятках похожих графиков требуются:

• пользовательское название или короткий alias графика;
• поиск и фасетные фильтры по году, специальности, профилю и форме;
• клонирование графика из прошлого года с предварительным просмотром сдвига дат;
• массовое создание на основе шаблона;
• массовое назначение выбранным совместимым группам;
• индикатор использования: сколько групп назначено;
• сравнение двух графиков и подсветка различий;
• защита от потери несохранённой сетки;
• автосохранение черновика сетки локально или на сервере;
• undo/redo для заполнения диапазона и изменения ячеек;
• проверка до сохранения с переходом к ошибочной дате;
• закреплённые заголовки курса, месяца и легенды при прокрутке.

7.4. Конструктор расписания

• master-detail-компоновка: слева фильтруемый список правил, справа редактор выбранного правила;
• создание из шаблона и дублирование правила;
• массовое назначение групп, преподавателя, слотов и диапазонов недель;
• фильтры по заполненности, конфликтам, кафедре, курсу и дисциплине;
• визуальная сетка загружает только выбранный набор групп;
• конфликт объясняется человеческим языком и содержит ссылку на конфликтующее правило;
• перед удалением показывается количество затронутых занятий;
• публикация заблокирована до прохождения обязательных проверок.

8. Целевая информационная архитектура

Администратор

• Обзор и задачи
• Подготовка учебного года
• Пользователи и доступ
• Структура и справочники
• Расписание
• Оперативные изменения
• Отчёты и аудит
• Настройки

Учебный отдел

• Обзор и очередь
• Подготовка семестра
• Конструктор расписания
• Проверка и публикация
• Просмотр расписаний
• Изменения и замены
• Ресурсы и загруженность

Кафедра

• Обзор
• Подготовка семестра
• Дисциплины
• Преподаватели и нагрузка
• Расписание кафедры
• Заявки и согласования

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

9. Общие компоненты и паттерны

Необходимо сформировать единый набор компонентов для Vanilla JS:

• асинхронный combobox;
• панель фильтров с чипами активных условий и кнопкой «Сбросить»;
• таблица с серверной пагинацией, сортировкой, выбором строк и массовыми действиями;
• боковая панель просмотра/редактирования;
• диалог подтверждения с описанием последствий;
• toast для краткого результата и inline-сообщение для ошибки поля/раздела;
• skeleton-состояние вместо скачка пустой таблицы;
• стандартизированные empty/error/permission states;
• status badge с текстом и иконкой;
• breadcrumb или ссылка «Назад к результатам» с восстановлением позиции;
• индикатор сохранения и защита несохранённых изменений;
• timeline для заявок и аудита;
• центр уведомлений и счётчики очередей.

Системные confirm() и prompt() следует постепенно заменить доступными проектными диалогами. Сообщение об успешном действии должно называть объект и результат: «График назначен 18 группам», а не просто «Успешно».

10. Состояния интерфейса

Каждый рабочий экран должен проектироваться минимум для следующих состояний:

1. первоначальная загрузка;
2. данные загружены;
3. пустой справочник;
4. фильтр не дал результатов;
5. частичная ошибка;
6. полная ошибка с повтором;
7. нет прав;
8. объект изменён другим пользователем;
9. есть несохранённые изменения;
10. действие выполняется;
11. действие успешно завершено;
12. действие завершено частично, например при массовом импорте.

Для конкурентного редактирования версий, календарей и правил желательно использовать optimistic locking и понятный диалог: кто и когда изменил объект, можно ли обновить данные или сохранить копию.

11. Уведомления

Минимально необходимы уведомления внутри приложения:

• новая заявка для ответственной роли;
• решение по заявке;
• приближение дедлайна пожеланий;
• публикация новой версии;
• перенос, отмена или смена аудитории;
• конфликт или ошибка массовой операции.

Уведомление должно вести к конкретному объекту, иметь статус прочтения и не раскрывать данные другой кафедры. Email/web-push можно добавить позднее, используя те же события.

12. Доступность и адаптивность

• обеспечить WCAG 2.2 AA как целевой уровень;
• проверить контраст обеих тем;
• добавить aria-sort таблицам и объявление количества результатов;
• реализовать корректные combobox/listbox-роли для поиска;
• возвращать фокус после закрытия модального окна;
• закрывать диалоги по Escape, удерживать фокус внутри открытого диалога;
• не использовать цвет как единственный признак конфликта, статуса или чётности;
• увеличить интерактивные зоны минимум до 44×44 px на мобильных экранах;
• для расписаний на телефоне показывать один день/список занятий, а не горизонтально сжатую таблицу;
• уважать prefers-reduced-motion;
• сделать печатные стили для расписаний и отчётов.

13. Приоритетный roadmap

Этап 0. Проверка гипотез и базовые метрики — 1–2 недели

• провести 5–7 интервью с учебным отделом, 3–5 с кафедрами, 5 с преподавателями и 5 со студентами;
• наблюдать выполнение реальных задач без подсказок;
• замерить время, число кликов, ошибки и точки возврата;
• зафиксировать объёмы: группы, графики, правила, преподаватели, аудитории, заявки;
• построить карту основных процессов и согласовать владельцев статусов.

Результат: подтверждённый список top-10 проблем и исходные значения метрик.

Этап 1. Быстрые улучшения frontend — 2–4 недели

• сохранять в URL и восстанавливать фильтры, вкладки, семестр и выбранный объект;
• добавить поиск, сортировку и sticky-заголовки в текущие таблицы;
• заменить опасные confirm/prompt проектными диалогами;
• унифицировать загрузку, пустые состояния и ошибки;
• добавить защиту несохранённых изменений в календарь и конструктор;
• улучшить первый выбор группы студента;
• добавить режим «Сегодня» преподавателю и студенту;
• добавить ссылки «Скопировать» и печатные стили просмотра расписания.

Результат: заметное сокращение ежедневного трения без крупной переделки backend.

Этап 2. Масштабные реестры и поиск — 4–8 недель

• добавить API пагинации, поиска, сортировки и фасетных фильтров;
• внедрить общий компонент серверной таблицы;
• внедрить асинхронный combobox;
• добавить массовые операции для групп, графиков и привязок;
• добавить предварительный просмотр и отчёт массовых операций;
• обеспечить стабильные deep links на сущности.

Результат: интерфейс остаётся работоспособным на полном объёме данных университета.

Этап 3. Интерфейс сквозных задач — 6–10 недель

• локальные каскады учебного года, семестра и версии в профильных вкладках;
• чек-лист готовности семестра;
• ролевые дашборды с очередями действий;
• единая очередь инцидентов и согласований;
• timeline заявок;
• связанный путь «конструктор → качество → сравнение → публикация»;
• центр уведомлений.

Результат: пользователь проходит бизнес-процесс, не собирая его вручную из вкладок.

Этап 4. Продвинутые инструменты — после стабилизации

• шаблоны и клонирование календарных графиков;
• импорт из Excel с сопоставлением колонок;
• сравнение расписаний и поиск общего свободного времени;
• экспорт PDF/Excel/ICS и календарная подписка;
• оптимистические блокировки и совместное редактирование;
• командная палитра и горячие клавиши для опытных пользователей;
• персональные сохранённые представления.

14. Приоритеты по модели RICE без числовой фиксации

Инициатива	Охват	Влияние	Сложность	Приоритет
Серверный поиск и пагинация	Все внутренние роли	Очень высокое	Высокая	P0
Локальные каскады года/семестра/версии	Администратор, учебный отдел, кафедра	Очень высокое	Средняя	P0
Защита несохранённых изменений	Учебный отдел	Очень высокое	Средняя	P0
Асинхронные комбобоксы	Все роли	Высокое	Средняя	P0
URL-состояние и глубокие ссылки	Все роли	Высокое	Низкая/средняя	P0
Массовое назначение графиков группам	Администратор, учебный отдел	Очень высокое	Средняя/высокая	P0
Ролевые очереди задач	Внутренние роли	Высокое	Средняя	P1
Единый контур публикации	Учебный отдел	Высокое	Средняя	P1
Уведомления	Все роли	Высокое	Высокая	P1
Импорт с предварительной проверкой	Администратор, кафедра	Высокое	Высокая	P1
«Сегодня» и ближайшая пара	Преподаватель, студент	Высокое	Низкая	P1
PDF/ICS/ссылки	Просмотр, преподаватель, студент	Среднее	Средняя	P2
Командная палитра	Опытные внутренние пользователи	Среднее	Средняя	P2

15. Изменения backend, необходимые для полноценного UX

Frontend-улучшений недостаточно для больших объёмов. Понадобятся:

• единый контракт пагинации и сортировки для реестров;
• полнотекстовый или индексированный поиск по нормализованным полям;
• batch-endpoints с атомарным и частичным режимами;
• dry-run для импорта, назначения и публикации;
• endpoint готовности семестра с кодами проблем и deep-link metadata;
• endpoint глобального поиска в рамках прав пользователя;
• события и хранилище уведомлений;
• optimistic locking/version field для редактируемых сущностей;
• агрегированные endpoints для дашбордов, чтобы не собирать их множеством клиентских запросов;
• экспортные задания для тяжёлых PDF/Excel;
• аудит массовых операций с автором, причиной и набором затронутых объектов.

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

16. UX-метрики

Операционные

• медианное время создания и назначения календарного графика;
• время поиска конкретной группы, преподавателя и аудитории;
• время от регистрации отсутствия до применения всех решений;
• время от создания черновика до публикации;
• число ручных действий на 10 групп или 10 правил;
• процент массовых операций с частичными ошибками.

Качественные

• success rate ключевого сценария без помощи;
• число возвратов и повторных сохранений;
• доля ошибок «не тот семестр / не та версия / не та кафедра»;
• доля пользователей, понимающих следующий шаг;
• SUS или UMUX-Lite по каждой роли;
• CSAT после обработки заявки или публикации.

Технические UX-метрики

• p75 времени появления полезного содержимого;
• p75 ответа поиска;
• размер DOM больших таблиц и сеток;
• частота ошибок API по экрану и действию;
• доля прерванных загрузок и повторных запросов;
• Core Web Vitals для публичных/конечных кабинетов.

Целевые значения следует зафиксировать после этапа 0. Без исходных измерений произвольные проценты улучшения будут недостоверны.

17. Критерии готовности ключевых улучшений

Реестр больших данных готов, если

• 10 000 записей не загружаются целиком в браузер;
• поиск возвращает результат за приемлемое для проекта целевое время;
• фильтры и страница восстанавливаются после возврата;
• массовая операция показывает область действия до подтверждения;
• частичные ошибки перечислены по объектам и доступны для выгрузки;
• управление возможно с клавиатуры.

Календарный график готов, если

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

Публикация готова, если

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

18. План пользовательского тестирования

Для каждого прототипа проводить короткие сценарные тесты:

Роль	Проверочное задание
Администратор	Создать 20 групп импортом, исправить ошибки и назначить графики
Учебный отдел	Создать черновик, устранить конфликт, проверить качество и опубликовать
Учебный отдел	Обработать отсутствие с несколькими затронутыми занятиями
Кафедра	Добавить дисциплины и преподавателей, проверить готовность семестра
Просмотр	Найти расписание аудитории и отправить ссылку коллеге
Преподаватель	Указать недоступность и подать заявку на перенос
Студент	Выбрать группу и найти аудиторию следующей пары

Фиксировать время, ошибки, вопросы пользователя, неверные ожидания и субъективную уверенность. Тестировать минимум на реальных объёмах, а не на 3–5 элементах.

19. Что не следует делать первым

• полностью менять визуальный стиль без исправления поиска, масштаба и процессов;
• объединять все роли в один универсальный экран;
• скрывать сложность только дополнительными модальными окнами;
• переносить всю фильтрацию на клиент;
• добавлять массовые действия без preview, отчёта и аудита;
• полагаться только на цвет для статусов;
• автоматически применять пожелания преподавателей без явного решения ответственной роли;
• внедрять drag-and-drop как единственный способ редактирования расписания.

20. Рекомендуемый первый пакет реализации

Первый практический пакет должен дать максимальный эффект без полной перестройки системы:

1. локальные каскады «Учебный год / Семестр / Версия» только в профильных вкладках;
2. URL-состояние для вкладок и фильтров;
3. асинхронный поиск групп, преподавателей, аудиторий и графиков;
4. серверная пагинация для групп, пользователей, дисциплин и заявок;
5. массовое назначение календарного графика выбранным группам с dry-run;
6. предупреждение о несохранённых изменениях календаря и конструктора;
7. проектные диалоги вместо confirm/prompt;
8. «Сегодня» и «Следующая пара» в кабинетах преподавателя и студента;
9. единые состояния загрузки, отсутствия данных и ошибки;
10. базовые события аналитики для измерения результата.

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

20.1. Статус реализации первого пакета — 19 августа 2026

№	Статус	Что реализовано
1	Выполнено, решение уточнено	Общая панель контекста удалена. В schedule, schedule-versions и schedule-quality используются локальные каскады учебного года, семестра и версии; в schedule-view — года и семестра, поскольку экран показывает только опубликованное расписание.
2	Выполнено	Вкладки, фильтры, сортировка, размер и номер страницы сохраняются в query string. Просмотр расписания сохраняет локальные год и семестр; преподаватель — вкладку и неделю, студент — группу и неделю.
3	Выполнено	Добавлены серверные endpoints и общий AsyncCombobox для групп, преподавателей, аудиторий и совместимых календарных графиков. Первый выбор группы студента и выбор преподавателя при регистрации отсутствия больше не загружают полный справочник.
4	Выполнено	Группы, пользователи, дисциплины и заявки преподавателей используют серверные поиск, фильтры, сортировку и пагинацию 25/50/100 с общим PageResponse. Для страницы дисциплин загружаются только её привязки преподавателей, а подгруппы запрашиваются только для открытой или выбранной в конструкторе группы.
5	Отложено по решению заказчика	Массовое назначение одного календарного графика нескольким совместимым группам и dry-run в этот пакет не входят. Текущее одиночное назначение сохранено.
6	Выполнено	Календарная сетка, привязки дисциплин и конструктор правил отслеживают несохранённые изменения, показывают индикатор на кнопке и предупреждают при уходе, смене графика или версии.
7	Выполнено	Нативные confirm, prompt и alert в административных и settings-модулях заменены единым доступным проектным диалогом.
8	Выполнено	В кабинетах преподавателя и студента появились блок «Сегодня» и карточка «Следующая пара» с поиском занятия в горизонте 14 дней.
9	Выполнено	Для серверных реестров внедрены общие loading/empty/error-состояния с повтором; для ближайших занятий применяется единый компонент состояния.
10	Выполнено	Добавлены прикладные UX-события: смена раздела, загрузка реестра/расписания, выбор группы, сохранение правила, сетки и привязок. В production события преобразуются в OpenTelemetry spans.

Дополнительно закрыты три согласованных требования масштабирования: серверные поиск/фильтрация/сортировка/пагинация реестров, асинхронные селекты больших справочников и восстановление фильтров/страницы из URL. Ролевое ограничение кафедры повторно применяется backend и не зависит от переданного frontend-фильтра.

Проверка реализации: npm run check выполняет синтаксический контроль новых модулей и все 18 frontend-наборов; отдельный тест закрепляет выбор сегодняшних занятий, текущей и следующей пары. Production-сборка frontend и 339 backend-тестов через полный mvn test в Java 17 контейнере проходят успешно. Массовое назначение из пункта 5 остаётся единственным сознательно незавершённым пунктом этого пакета.

21. Источники анализа в проекте

• docs/BUSINESS_LOGIC.md — роли и бизнес-процессы;
• docs/FRONTEND.md — маршруты и текущее поведение экранов;
• docs/API.md — возможности и ограничения API;
• frontend/admin/js/role-capabilities.js — фактическая матрица вкладок;
• frontend/admin/views/ и frontend/admin/js/views/ — административные сценарии;
• frontend/teacher/ — кабинет преподавателя;
• frontend/student/ — кабинет студента.