Много разных изменений

UX_IMPROVEMENT_PLAN.md

@@ -0,0 +1,676 @@
+# План улучшения пользовательского взаимодействия 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. Подготовка семестра
+
+```text
+Администратор настраивает структуру и справочники
+        ↓
+Кафедра заполняет дисциплины, преподавателей и пожелания
+        ↓
+Учебный отдел проверяет готовность календарей и данных
+        ↓
+Учебный отдел создаёт и проверяет черновик
+        ↓
+Публикация → преподаватели, студенты и просмотр расписаний
+```
+
+Для процесса нужен единый статус готовности с владельцем каждой проблемы. Пользователь должен видеть не просто «ошибка», а «что не готово → кто исправляет → куда перейти».
+
+### 6.2. Отсутствие и замена
+
+```text
+Преподаватель сообщает об отсутствии
+        ↓
+Кафедра подтверждает факт
+        ↓
+Учебный отдел выбирает решения по затронутым занятиям
+        ↓
+Расписание изменяется, решение попадает в аудит
+        ↓
+Преподаватель и затронутые группы получают уведомление
+```
+
+Все роли должны видеть один и тот же номер инцидента, единые статусы и хронологию, но разные доступные действия.
+
+### 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/` — кабинет студента.