Материал статьи

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

Иллюстрация: выбор дня в календаре и ввод известной даты — разные задачи

Иллюстрация: выбор дня в календаре и ввод известной даты — разные задачи.

Оглавление

Известную дату вводят, доступную — выбирают

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

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

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

Сначала запишите вопрос, который задаёт интерфейс, обычными словами. «Когда вы родились?», «На какой день записаться?» и «За какой период показать операции?» ведут к разным решениям. Если в техническом задании есть только «добавить datepicker», значимая часть проектирования ещё не выполнена.

Не собирайте точность, которой у пользователя нет

Иногда человек знает только месяц, год или приблизительный период. Требование точного дня заставит его придумать значение. Если такая точность не нужна бизнес-процессу, дайте подходящий формат. Если нужна, объясните, где найти сведения или как поступить при неизвестности. Ошибка данных может начинаться не с небрежности пользователя, а с неверного вопроса формы.

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

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

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

Подпись, формат и пример работают вместе

Название поля должно объяснять смысл даты, а не только тип данных. «Дата» недостаточно, если рядом обсуждаются оформление, начало действия и получение. Укажите, какое событие имеется в виду. Формат помогает ввести значение, но не заменяет смысловую подпись. Человек может корректно заполнить не ту дату.

Если используются отдельные поля, подпишите день, месяц и год. Если единое поле — дайте понятный пример и последовательно обрабатывайте выбранную локаль. Числовая запись вроде 03/04/2026 неоднозначна между распространёнными порядками дня и месяца. Для важных подтверждений можно показать дату словами, чтобы человек заметил возможную ошибку.

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

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

Ручной ввод не должен быть наказанием

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

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

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

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

Для диапазона важны обе границы и правила включения дней

Для диапазона важны обе границы и правила включения дней.

Календарь должен показывать разные состояния

Сегодняшний день, выбранная дата, фокус клавиатуры и недоступный день — разные состояния. Если они выглядят одинаково, пользователь теряет ориентир. Выделение выбранного числа не заменяет видимый фокус, а серый цвет не объясняет причину недоступности. Состояния должны различаться не только цветом.

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

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

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

Ограничение должно иметь понятный смысл

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

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

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

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

Диапазон: начало, конец и включённость границ

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

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

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

Проверьте обратный диапазон и изменение начала после конца. Можно автоматически предложить корректировку, но нельзя незаметно менять смысл запроса. Иногда удобнее показать ошибку, иногда — сдвинуть вторую границу с ясным подтверждением. Выбор зависит от сценария; главное, чтобы человек понимал итоговый период до выполнения действия.

Дата без времени не должна случайно стать другим днём

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

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

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

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

Календарь проверяют не только мышью, но и с клавиатуры

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

Доступность проверяют на всём взаимодействии

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

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

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

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

Что проверить на телефоне

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

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

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

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

Значение по умолчанию может стать незаметным решением

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

Быстрые периоды вроде «Сегодня», «Последние семь дней» и «Этот месяц» требуют точного определения. Входит ли текущий неполный день? Начинается ли неделя с понедельника? Какой временной контекст используется? Покажите итоговые границы после выбора, чтобы человек мог проверить смысл. Название пресета помогает действовать быстрее, но не заменяет прозрачного результата.

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

Набор тестов для приёмки

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

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

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

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