Чего сложного в том, чтобы окно выбора даты выглядело достойно? В принципе, нам просто нужно поле ввода и иконка, очень похожая на календарь — когда пользователь на неё тыкнет, появится поп-ап с днями, выстроенными в строках. Правильно?

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

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

Лучшее поле ввода — то, что соответствует намерению пользователя. Но что, если мы установим для поля ввода лимит кликов? Максимум два, например. Три клика, чтобы выбрать диапазон дат. Будет достаточно пяти кликов, если мы внедрим дополнительные кнопки для выбора даты? Возможно, вы скажете, что это мелочи, ведь это же всего лишь какой-то выбор даты! Но если в вашем интерфейсе выбор даты занимает центральное место на странице, стоит ожидать, что его будут нещадно юзать, и уже только поэтому стоит оптимизировать пользовательский опыт.

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

Если мы внимательно рассмотрим природу интерфейсов для выбора дат, то обнаружим много непростых вопросов:

• Мы разрабатываем интерфейс для выбора даты, диапазона дат или указания времени?
  
  
• Можно ли вводить в поле ввода произвольную дату или придётся выбирать только предопределенные значения из списка?
  
  
• Когда должно появляться всплывающее окно для выбора даты: когда пользователь нажимает на поле ввода или на на иконку календаря (или оба варианта)?
  
  
• Если внутри полей для выбора дат содержатся предварительно заданные значения, то какими должны быть значения по умолчанию?
  
  
• Должны ли мы включить навигацию между «предыдущими, текущими, следующими» значениями? Если да, то на какой период проектировать — несколько дней, месяцев или лет?
  
  
• Стоит ли улучшить пользовательский опыт, отображая доступность, цену и т. д.
  
  
• Для диапазонов дат на узких экранах — должен ли оверлей с датами автоматически исчезать после выбора двух дат или только когда пользователь нажимает кнопку «Продолжить»?
  
  
• Неделя начинается с понедельника или с воскресенья?
  
  
• Как избежать отображения недоступных дат?
  
  
• Интерфейс для выбора дат — действительно правильный шаблон или нужно выбирать диапазон дат, к примеру?
  
  

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

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

Вы также можете расширить параметры, добавив ввод времени, но это не означает, что придётся делить процесс на этапы: сначала дата, потом время. Есть способы интеграции выбора дня и времени в одном компоненте.

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

Если вы задумались о необходимости выбора даты, вероятно, вы знаете, что нужны поля ввода (да ладно?!). Конечно, вы могли бы использовать три отдельных поля для числового ввода через разделитель — например, выпадающие списки <select> для дня, месяца и года, но с таким дизайном пользователи отправятся в мытарства по полосе прокрутки, и вряд ли справятся с этим быстро и просто. А мы ведь хотим, чтобы дата была установлена как можно быстрее, а да ещё в два клика (клик — открыл календарь, клик — выбрал день).

Ну ладно. Что, если вместо трех отдельных полей мы замутим одно — с помощью хелпера в формате DD/MM/YYYY? По мере того, как пользователь печатает, переход между днем, месяцем и годом должен происходить автоматически, чтобы не делать этого вручную. В идеале, пользователь закончит с вводом после максимум восьми нажатий клавиш. Неясно, знает ли пользователь точную дату, но было бы полезным сделать точный ввод возможным в дополнение к обычному выбору даты — особенно в интерфейсах, где тип ввода данных может иметь большое значение (например, с датами истечения срока действия паспорта).

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

Надежность также означает снисхождение. Если пользователь хочет выбрать 1 марта 2019 года с помощью цифрового ввода MM/DD/YYYY, он введёт 01/03/19. Мы, как дизайнеры, ожидаем именно этого.

Но если вы понаблюдаете в юзабилити-тестах, как пользователи вводят дату, то удивитесь: некоторые ждут секунду, вводят 1, затем вручную переключаются на ввод месяца, вводят 3, затем опять вручную переключаются на ввод года и пишут 19 или 2019. Другие пользователи от греха подальше введут 03 и 01. Третьи попытаются включить знак разделителя в любое из полей: в некоторых случаях при вводе исчезает образец заполнения, и пользователи будут писать какой-нибудь дефис ( -) или слэш ( /) вместо того, что вы там запланировали. Другие попытаются увеличить значение цифр с помощью стрелок вверх и вниз в полях ввода. А некоторые будут переходить между полями ввода при помощи клавиши tab. Какой кошмар для встроенной проверки!

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

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

Ввод чисел имеет значение, когда диапазон ввода варьируется в широких пределах: охватывает годы, даты действия визы или когда требуется предсказуемый ввод — например, даты рождения. Вот здесь стоит предусмотреть возможность прямого численного ввода. Вы даже можете выйти на следующий уровень, поддержав контекстно-зависимый ввод — например, запросы вроде «вчера», «сейчас», «сегодня», «в следующую пятницу», «год назад», «две недели назад» или даже «5 дней в июле».

В зависимости от характера приложения вам могут пригодиться гибкие даты и ввод запроса в поле. Если это невозможно, добавьте параллельно с выборщиком дат настраиваемые предопределенные параметры для «сегодня», «завтра», «через 7 дней» и т. д. Это, например, полезно при поиске оптимального тарифа для авиабилета. И да, не забудьте рассказать пользователям, что можно использовать такие вот нечеткие запросы.

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

Если немного ближе рассмотреть взаимодействие с полем ввода даты, мы наткнемся на ряд микро-решений с точки зрения UX. Должно ли поле ввода быть пустым или содержать значения по умолчанию или пример правильного ввода? Какие значения выбирать для значений по умолчанию? И должны ли сбрасываться введенные значения при обновлении страницы?

Мы не тестировали и не заметили каких-либо предпочтений насчет вышеперечисленных вариантов, но кажется, что случайные значения в полях ввода — не самый лучший подход, поскольку это путает людей и укрепляет в сознании случайные даты, хотя изначально пользователи искали совершенно другие. Однако, если ваши клиенты склонны покупать товары и услуги в последний момент (будь то шоу, билеты на общественный транспорт или гостиницы), то текущая дата («сегодня») или даже текущее время («сейчас») может быть хорошим вариантом, учитывая зависимость предложений от времени.

Бывает, что пользователь выбрал даты или временные интервалы, но обновил страницу (случайно или намеренно) — здесь мы можем сбросить его настройки или сохранить их. Если пользователь случайно обновится, он вряд ли будет в восторге от необходимости заполнять всё заново. Если же он обновился намеренно, то увидит сохранённые даты и грустно начнет вбивать новые. А всего-то нужно разместить где-то на виду заметную ссылку «Сброс» или «Новый поиск» рядом с вводом даты. Кроме того, здесь может быть полезен мини-степпер, поскольку даты могут незначительно меняться.

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

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

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

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

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

Выясните критические детали, которые важны для ваших клиентов и выставите их на видном месте — например, с серыми индикаторами (если недоступно) и зелеными (если доступно). И да, они ведь ещё и разных размеров могут быть, чтобы отразить разные классы доступности.

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

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

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

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

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

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

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

Не все «выборщики» дат одинаковы, и их дизайн будет значительно отличаться в зависимости от контекста. Одно можно сказать наверняка: если «выборщик» дат не отображается, он должен появляться по клику на поле ввода или на иконку календаря.