# План улучшения пользовательского взаимодействия 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/` — кабинет студента.