Дизайн календаря выбора даты: диапазоны, часовые пояса и ошибки

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

1. Начните с задачи пользователя

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

До отрисовки компонента зафиксируйте короткий набор договорённостей:

• Выбор: одна дата, диапазон, несколько отдельных дат или дата вместе со временем.
• Ограничения: самая ранняя и поздняя дата, максимальная длительность, недоступные дни.
• Календарь и локаль: первый день недели, названия месяцев и формат года.
• Основа времени: часовой пояс пользователя, аккаунта, места проведения либо UTC.
• Завершение: выбор применяется сразу или после отдельного действия «Применить».

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

Так последующие решения о внешнем виде календаря будут опираться на конкретные правила бронирования.

2. Выберите подходящий способ ввода

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

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

3. Определите поведение диапазона до оформления

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

Например, пользователь выбирает заезд 21 сентября. Перемещение по 22–24 сентября показывает предварительный диапазон. Выбор 24 сентября задаёт три ночи. Если 23 сентября недоступно, дальнейшее действие зависит от правил продукта: нельзя молча считать, что такой день разрешено пересекать. Допустимость периода должна определить команда продукта вместе с разработчиками; интерфейс затем либо ограничивает выбор, либо объясняет, почему диапазон не подходит.

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

4. Объясните недоступные даты и ограничения

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

• Отличайте недоступные дни от выбранных дат и чисел соседнего месяца.
• В готовом продукте передавайте состояние недоступности программно и при необходимости добавляйте доступное пояснение причины.
• Не включайте полностью недоступные даты в путь фокуса, если сценарий специально не предусматривает просмотр причины через такой элемент.
• Поясняйте необычные ограничения рядом с календарём: например, «Бронирование — до 14 ночей».
• Разделяйте загрузку доступности и отсутствие мест: пока ответ не получен, дата не должна выглядеть распроданной.

В качестве ориентира для клавиатурной навигации и календарной сетки используйте пример диалога выбора даты WAI-ARIA на английском. Это пример реализации, который требует проверки с реальными браузерами и вспомогательными технологиями. Макет может описывать порядок фокуса, но сам по себе не подтверждает доступность работающего элемента.

5. Рассматривайте часовой пояс как часть значения

Даже дата без времени может получить другой смысл при переводе во временную метку. Указывайте часовой пояс, если он влияет на наличие мест, границы суток или отчётность. Подпись «Время объекта размещения (UTC−04:00)» объясняет контекст лучше, чем отдельная неоднозначная аббревиатура. Смещение в таком примере относится к выбранным датам; оно не заменяет правило часового пояса на весь год.

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

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

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

6. Помогите исправить ошибку без повторного ввода

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

Проверяйте формат после того, как человек получил возможность закончить ввод. Проверку связи между полями и наличия мест обычно понятнее выполнять при применении диапазона или переходе дальше. Ошибка на каждом нажатии клавиши мешает спокойно дописать дату. Формат в сообщении должен соответствовать реально поддерживаемому формату продукта; в русской версии примера это ДД.ММ.ГГГГ.

7. Соберите и обсудите компонент в Pixso

В Pixso создайте редактируемый набор компонентов. Выделите повторно используемые части: поле, заголовок календаря, строку дней недели, ячейку даты, выделение диапазона, пояснение и ошибку. Задайте свойства или понятно названные варианты для обычного состояния, фокуса, начала, середины и конца диапазона, недоступной даты, сегодняшнего дня и числа соседнего месяца.

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

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

8. Проверьте узкий экран и доступность

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

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

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

9. Проверьте календарь перед передачей в разработку

• Элемент соответствует задаче: одна дата, диапазон, несколько дат или дата со временем.
• Текстовый ввод и выбор в календаре приводят к одинаковому значению и формату.
• Различимы начало, конец, предварительное выделение, сегодняшний день, недоступная дата и соседний месяц.
• Понятны минимальная и максимальная даты, блокировки и предел длительности.
• Часовой пояс указан везде, где он влияет на результат.
• Ошибки сохраняют исправляемый ввод и объясняют следующее действие.
• Проработаны загрузка, отсутствие доступных дат, успешный результат и изменение доступности.
• На узком экране числа удобно выбирать, а введённые значения остаются видимыми.
• Поведение клавиатуры и вспомогательных технологий описано и проверено в реализации.

Свяжите календарь с правилами бронирования

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