Как редактировать повторяющиеся события: одну встречу, будущие или всю серию

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

Представьте обсуждение дизайна, которое проходит каждый четверг в 09:00 по Лондону. Одну ноябрьскую встречу уже перенесли на 11:00. Теперь организатор хочет сдвинуть остальные обычные встречи на час позже. Если применить новое время ко всем датам без разбора, прежняя договорённость исчезнет.

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

Сделайте структуру серии понятной

Для первой версии макета возьмите конечную серию: четыре обсуждения по 45 минут — 22 октября, 29 октября, 5 ноября и 12 ноября 2026 года. Обычно они начинаются в 09:00, но встреча 12 ноября отдельно перенесена на 11:00. В нашем сценарии организатор открывает встречу 29 октября до её начала и меняет обычное время на 10:00 начиная с этой даты.

Показывайте рядом название, выбранную дату, продолжительность, часовой пояс расписания и правило повторения. Подпись «Каждый четверг · 4 встречи · время Лондона» помогает узнать серию. В подробностях встречи 12 ноября укажите: «Время изменено на 11:00». Пользователь должен понимать отличие, не разбирая техническую строку правила повторения.

После переноса встреча должна сохранять связь с исходной серией. В документации Google Calendar о повторяющихся событиях на английском различаются текущее и первоначальное время начала: первоначальное позволяет определить экземпляр события внутри серии. Для интерфейса это означает, что перенесённая на пятницу встреча по-прежнему узнаваема как обсуждение, первоначально назначенное на четверг. Она не должна выглядеть отдельной дополнительной встречей.

Объясните каждый вариант применения изменений

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

Это явно заданные правила учебного продукта. Реальный сервис может иначе обращаться с прошедшими встречами и исключениями. Согласуйте поведение с продуктовой командой и разработчиками, а затем подбирайте подписи. Если команда влияет только на оставшиеся встречи, название «Вся серия» неточно. Если выбранная встреча сама является исключением, объясните, что редактируется: её индивидуальное время или обычное время серии.

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

Финальное действие можно назвать «Сохранить изменения для 2 встреч». Поместите точные даты непосредственно над ним. У бесконечной серии вместо выдуманного конечного количества покажите границу начала и ограниченный предварительный список: например, «Каждый четверг начиная с 29 октября».

Показывайте обычные встречи вместе с исключениями

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

Подпишите таблицу: «Всё время указано по Лондону». Понятная фраза подтверждения: «Перенести 2 встречи на 10:00 начиная с 29 октября. Оставить 12 ноября в 11:00». Цвет может выделять изменённые строки, но значения «Было» и «Станет» вместе с причиной должны объяснять результат и без цвета.

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

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

Уточните, что сохраняется при переводе часов

Правилу «Каждый четверг в 09:00» всё ещё нужна основа времени. Встреча команды может оставаться в 09:00 в определённом часовом поясе, а её время UTC — меняться. У расписания, закреплённого за 08:00 UTC, показания лондонских часов будут другими.

В Великобритании часы переводят назад 25 октября 2026 года — официальный календарь на английском. Возьмём исходное время встречи, до нашего редактирования: даты по обе стороны перехода показывают разницу.

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

RFC 5545 на английском различает UTC, местное время со ссылкой на часовой пояс и «плавающее» местное время без такой ссылки. Для международной встречи последнее нельзя считать удобным сокращением: его значение на часах не привязано к определённому поясу. Спецификация также предписывает пропускать недопустимые даты и несуществующее местное время, полученные по правилу повторения. Поэтому ежемесячная встреча «31-го числа» или время в момент весеннего перевода часов требуют реального списка встреч, а не дат, придуманных в макете.

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

Проработайте отмену и результат сохранения

Отмене нужна такая же ясность охвата. «Отменить встречу 5 ноября» и «Завершить серию до 5 ноября» имеют разные последствия. В первом случае более поздняя встреча остаётся. Во втором оставшиеся встречи удаляются согласно правилам сервиса. Неопределённое подтверждение «Удалить событие» скрывает это различие.

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

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

Пока предварительный просмотр открыт, другой человек может перенести встречу 12 ноября. Покажите новые данные и попросите организатора проверить обновлённые последствия до подтверждения. Сохраните предложенное им начало в 10:00, чтобы согласовать изменения можно было без повторного ввода.

Разделяйте сохранение расписания и отправку уведомлений, если сервис различает эти результаты. «Обновлены 2 встречи» сообщает о расписании. «Приглашения отправлены» описывает другой исход и допустимо только после его подтверждения. Интерфейс не должен обещать, что все участники уже увидели или приняли новое время.

Проверьте решение в прототипе Pixso

Соберите в Pixso пять связанных фреймов: выбранная встреча 29 октября, новое время с вариантами охвата, предварительный результат для четырёх дат, раскрытое исключение 12 ноября и сохранённый календарь. Во всех фреймах должны совпадать даты, продолжительность и подписи часового пояса. Используйте экземпляры одного компонента строки встречи, чтобы изменение выбранного состояния или ожидания не меняло её данные случайно.

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

Попросите участника перенести обычные встречи начиная с 29 октября на 10:00, оставив отдельно согласованную ноябрьскую встречу на 11:00. До сохранения уточните, какие даты изменятся. Затем предложите найти исключение и отменить только встречу 5 ноября. Отметьте места, где ожидание участника расходится с показанным результатом.

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