Tech Spec Design Schedule

Техническое задание на разработку дизайна модуля "Расписание"

Ниже — структура ТЗ (общий шаблон, см. также Getting Started). Команда заполняет каждый раздел своим содержанием; текст в квадратных скобках — подсказка, что писать, а не готовый ответ.

1. Назначение модуля

Модуль “расписания” должен показывать пользователю, что и когда будет происходить в определенный период времени. Например; занятия, встречи, пары, смены и события. Он необходим, что бы человек всегда знал, какой график у него на день, неделю, месяц и более. Не тратил времени на поиск информации и всегда знал, где и как ему ее найти. Простыми словами; это электронный дневник времени, который собирает все события в одном месте, раскладывает их по часам и дням и показывает пользователю простую и всегда актуальную картину его расписания. Модуль одинаково прост и полезен для разных пользователей. Студент видит свои занятия. Преподаватель – экзамены и консультации. Сотрудник- встречи и смены. Таким образом, каждый человек сможет быстро и просто распределять свое время на нужные задачи, перерывы и дорогу. Планировать встречи и выбирать отпуска и выходные .

При входе в модуль “расписание” пользователь попадает на главный экран, который сразу дает ему полную картинку его графика. В центре экрана расположен календарь- это основное поле, где отображаются все события.
Каждое событие в расписании представлено в виде блока. В нем указанно событие, время начала и окончания, место проведения, а так же участники( например кто проводит событие и какие группы будут присутствовать). Сверху расположена панель управления. Там находятся фильтры, с помощью которых можно отобразить только нужные события. Рядом расположена строка поиска- по названию события или по имени участника. Это удобно когда расписание обьемное и сложно найти определенное событие. Пользователь в данном модуле выполняет набор действие, которые можно разделить на несколько групп. Самое основное действие это просмотр расписания. Далее он может искать и фильтровать увиденную информацию. Взаимодействует с событием и просматривает его подробности. Пользователь может получать уведомления и экспортируемые данные. Таким образом пользователь в модуле “расписание” не просто смотрит на список событий, а активно управляет своим временем.

2. Функциональные требования

2.1. Экраны и элементы интерфейса

[страница1- главный экран]

Назначение- отображение общего расписания пользователя на выбранный период. Элементы интерфейса;

1. переключение вида; день\ неделя\месяц
2. кнопки навигации; назад\вперед
3. сетка календаря с блоками собтий
4. линия текущего времени и подсветка “сейчас идет”
5. панель фильтров и строка поиска. [страница 2- карточка события ] Назначение; просмотр подробной информации о выбранном событии. Элементы интерфейса;
6. название события и его тип
7. дата, время начала и окончания
8. место проведения
9. описание
10. кнопки “редактировать” и ”удалить” ( для личных событий)
11. кнопка “закрыть”

[страница 3- фильтр и поиск]

Назначение; быстрый поиск нужных событий в расписании. Элементы интерфейса;

1. фильтр по типу события
2. фильтр по группе\месту
3. фильтр по периоду
4. срока поиска по названию
5. кнопка применить\сбросить

2.2. Пользовательские сценарии

Сценарий 1: [Просмотр расписания на неделю]

1. Пользователь открывает модуль "Расписание".
2. Видит экран с календарем, по умолчанию открыт вид "неделя".
3. Видит события текущей недели в виде цветных блоков с названием, временем и местом.
4. Нажимает на любой блок - открывается карточка события с подробной информацией.
5. Получает результат: понимает, что запланировано, где и во сколько.

Сценарий 2: [Поиск конкретного события]

1. Пользователь открывает модуль "Расписание".
2. Видит строку поиска в верхней части экрана.
3. Вводит название события или имя преподавателя.
4. Видит отфильтрованный список подходящих событий.
5. Нажимает на нужное и открывается карточка события.
6. Получает результат: быстро нашел нужное занятие .

Сценарий 3: [Фильтрация событий]

1. Пользователь открывает модуль "Расписание".
2. Видит панель фильтров над календарем.
3. Выбирает нужные параметры: тип события, группу, преподавателя или место.
4. Нажимает применить.
5. Видит только события соответствующие фильтру.
6. Получает результат: расписание стало чистым и содержит только нужные события.

Сценарий 4: [Переключение вида календаря]

1. Пользователь открывает модуль "Расписание".
2. Видит переключатель видов: "День"/"Неделя"/"Месяц" в верхней части экрана.
3. Нажимает "Месяц".
4. Видит обзор всего месяца с кратким отображением событий.
5. Нажимает "День" и видит подробное расписание на сегодня.
6. Получает результат: выбрал удобный формат просмотра.

3. Нефункциональные требования

Удобство использования:

• Понятность- пользователь выполняет основные действия с первого раза, без обучения.

• Эффективность- ключевые функции доступны на главном экране, в 1-2 клика.

• Запоминаемость- расположение элементов понятно и предсказуемо.

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

• Свобода действий- есть возможность отменить действие или сбросить фильтры.

  Отображение на разных экранах:

• Поддерживаемые браузеры: [требования, если есть]

4. Интерфейсы

4.1. Ожидаемые API Endpoints

Согласовывается с backend-командой этого же модуля до начала Модуля 2 — что это значит и как оформлять, см. 🔌 API-контракт. Этот раздел должен совпадать с разделом 4.1 в specification-backend.md того же модуля.

Метод	Endpoint	Зачем нужен (какому экрану/действию)
GET	/api/v1/schedule/...	[...]
POST	/api/v1/schedule/...	[...]

4.2. Макеты / вайрфреймы

[Ссылки на макеты (например, Figma) или эскизы экранов]

5. Критерии приёмки

• Все экраны реализованы (frontend/schedule/)
• Страницы реально обращаются к backend через согласованный контракт (не через захардкоженные данные)
• Ошибки API показываются пользователю понятным сообщением, а не «падением» страницы
• Раздел 4.1 согласован с specification-backend.md этого модуля (см. чек-лист в 🔌 API-контракт)
• Pull Request создан и принят

6. Приложения

[Скриншоты готового интерфейса]