Расписание на сайте: как показывать исключения и изменения

Отменённое занятие нельзя просто стереть

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

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

В стандарте календарных данных iCalendar предусмотрено свойство STATUS, которое для события допускает значение CANCELLED для передачи отмены. Перевод этого состояния на русский язык и заметность сообщения в расписании остаются задачей интерфейса сайта.

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

Обычная неделя задаёт правило, а не готовые даты

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

Для описания повторения iCalendar использует RRULE. Свойство DTSTART задаёт начало события. Оба названия нужны при разговоре об обмене данными с календарём: они помогают отличить первую дату от правила, по которому появляются следующие занятия. Назначение свойств описано в RFC 5545.

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

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

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

Почему переносу нужна связь с прежней датой?

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

Стандарт iCalendar выделяет RECURRENCE-ID для обращения к одному повторению серии. Это связь с исходной датой. При переносе этот идентификатор относится к первоначальному времени занятия. Именно так RFC 5545 отделяет исходное событие от его изменённого начала.

Для посетителя технический идентификатор не нужен. Ему полезнее сообщение: занятие перенесено с прежней даты, новое время указано рядом. На старом месте остаётся заметка о переносе, а новая строка ведёт к тем же сведениям о занятии.

Я бы сохранял перенос как изменение существующего события, если предмет, группа и содержание занятия остаются прежними: две отдельные записи хуже объясняют произошедшее, а при последующем исправлении их легко развести. При добавлении действительно нового занятия создают самостоятельное событие, а решение определяет сотрудник, который отвечает за расписание, поскольку сайт не способен по одному совпадению названия понять, является новая дата переносом или расширением программы.

Для исключения даты из повторения используется EXDATE. Это отдельное свойство iCalendar, которое описывает исключённые даты. При импорте календаря исполнитель показывает, как исключённая дата отражается для посетителя: на прежнем месте остаётся понятное объяснение изменения, по которому человек сможет найти новое время или связаться с ответственным за расписание.

Время принадлежит месту проведения

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

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

В календарном обмене параметр TZID связывает время с часовым поясом. Его назначение описано в стандарте iCalendar. Отсутствие этой связи стоит обсудить с исполнителем до импорта: один и тот же набор цифр разные системы могут интерпретировать по-разному.

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

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

Неделя и список показывают одни события

Широкая календарная сетка удобна для обзора недели. На телефоне строки со временем и статусом читаются спокойнее, чем множество узких колонок.

Список не стоит делать отдельным расписанием. Он использует те же события и те же фильтры, а меняется только способ показа. Тогда отмена, опубликованная сотрудником, появляется и в календаре, и на мобильном экране.

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

Для поиска по направлениям нужен устойчивый результат. После выбора направления сайт показывает понятное название фильтра и оставляет способ его сбросить. Если занятий на выбранную неделю нет, пустой экран заменяют сообщением о результате поиска и переходом к другой дате. Утверждение о полном отсутствии программы здесь было бы неверным: исчезли только события под выбранными условиями, а не все занятия организации. Это различие особенно заметно после переноса, когда обычный день опустел, а новая дата находится в соседней неделе.

Цвета недостаточно для статуса. Слова об отмене или переносе читаются и без различения оттенков, поэтому их стоит сохранять в строке вместе с датой.

Как сотруднику исправлять расписание без сюрпризов

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

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

В задание можно включить такой образец карточки изменения: «Исходное занятие — дата и направление. Действие — отмена, перенос или замена. Новые сведения — время, место либо преподаватель. Пояснение посетителю — причина и способ уточнить детали». Это пример структуры редактирования, а не обязательные названия готовой системы.

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

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

Попросите показать перенос через границу недели

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

Содержательный вопрос подрядчику звучит так: «Как посетитель узнает, куда делось занятие с привычного места, и что останется после следующего импорта?» Ответ включает экран со старой датой, новое время и источник сведений, а слова о поддержке календаря без этого показа мало помогают принять работу.

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

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