Комментарии
Что стоит учитывать при их разработке и почему вообще надо заморачиваться по этому поводу
Идеальные интерфейсы выбора даты и времени.
Часть 1
Что стоит учитывать при их разработке и почему вообще надо заморачиваться по этому поводу
Мы наткнулись на статью Виталия Фридмана, автора и главного редактора Smashing Magazine, об интерфейсах для выбора даты и времени. Автор рассказывает о нюансах, на которые важно обращать внимание при конструировании интерфейсов, и приводит многочисленные примеры: удачные и не очень. Статья содержит в себе килотонну пользы и без картинок занимает 19 страниц — мы заботливо перевели её на русский и поделили на части, чтобы вам легче было всё это усвоить:)
Чего сложного в том, чтобы окно выбора даты выглядело достойно? В принципе, нам просто нужно поле ввода и иконка, очень похожая на календарь — когда пользователь на неё тыкнет, появится поп-ап с днями, выстроенными в строках. Правильно?

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

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

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

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

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

  • Мы разрабатываем интерфейс для выбора даты, диапазона дат или указания времени?

  • Можно ли вводить в поле ввода произвольную дату или придётся выбирать только предопределенные значения из списка?

  • Когда должно появляться всплывающее окно для выбора даты: когда пользователь нажимает на поле ввода или на на иконку календаря (или оба варианта)?

  • Если внутри полей для выбора дат содержатся предварительно заданные значения, то какими должны быть значения по умолчанию?

  • Должны ли мы включить навигацию между «предыдущими, текущими, следующими» значениями? Если да, то на какой период проектировать — несколько дней, месяцев или лет?

  • Стоит ли улучшить пользовательский опыт, отображая доступность, цену и т. д.

  • Для диапазонов дат на узких экранах — должен ли оверлей с датами автоматически исчезать после выбора двух дат или только когда пользователь нажимает кнопку «Продолжить»?

  • Неделя начинается с понедельника или с воскресенья?

  • Как избежать отображения недоступных дат?

  • Интерфейс для выбора дат — действительно правильный шаблон или нужно выбирать диапазон дат, к примеру?


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

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

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

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

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

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

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

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

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

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

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

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

Таймпикер не всегда необходим. Вместо этого вы можете использовать набор кнопок. Однако скрытие некоторых параметров в выпадающем меню может быть слишком неочевидным. Значение по умолчанию (текущее время) имеет большое значение в телегиде Sr.de.
Бывает, что пользователь выбрал даты или временные интервалы, но обновил страницу (случайно или намеренно) — здесь мы можем сбросить его настройки или сохранить их. Если пользователь случайно обновится, он вряд ли будет в восторге от необходимости заполнять всё заново. Если же он обновился намеренно, то увидит сохранённые даты и грустно начнет вбивать новые. А всего-то нужно разместить где-то на виду заметную ссылку «Сброс» или «Новый поиск» рядом с вводом даты. Кроме того, здесь может быть полезен мини-степпер, поскольку даты могут незначительно меняться.
Проектирование всплывающего календаря
Можно подумать, что вам нужно быть очень креативным, чтобы сделать отличный дизайн для всплывашки календаря, ведь обычно они выглядят так одинаково! И действительно, в классическом варианте это оверлей на маленьких экранах и всплывашки на большом, где дни выстроены в недели с раскрывающимися списками для навигации по годам и месяцам. Но всё-таки варианты для детализации и навигации календаря есть.

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

Skyscanner четко отделяет субботу и воскресенье от остальной части недели. Видимо, именно тогда многие люди путешествуют.

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

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

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

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

Fantastical использует цветовые коды и фоновое цветовое кодирование, чтобы указывать на более и менее занятые дни в календаре.
Легко потеряться среди всех этих прекрасных функций и индикаторов, поэтому важно сначала определить основы. Не забудьте указать текущий день, чтобы клиенты могли легко видеть взаимосвязь между удалённой и текущей датами.
Airbnb выделяет дни с наиболее выгодными предложениями зеленой точкой. В результате клиент может просматривать месяцы и искать даты, которые предоставляют больше возможностей.
Как мы уже выяснили, необязательно отображать год все время. Или, по крайней мере, если год указывается нечасто, он не должен быть столь же заметным, как остальные поля, и, возможно, должен появляться только при необходимости. Здесь тоже потребуется продумать некоторую навигацию между днями, месяцами и годами. Но только не вздумайте обойтись обычным выпадающим списком.
Bahn.de, немецкий сервис покупки билетов на поезд, не включает в себя выборщик года во всплывающем календаре. Тем не менее, он включает в себя мини-шагомер в между днями, месяцами и временем (один шаг = один час). Также можно ввести дату без использования календаря.
Мини-шагомер для быстрых переходов
Если ваши клиенты рассматривают короткий диапазон параметров дат, добавьте быструю навигацию рядом с полем ввода: кнопки «предыдущий» и «следующий». Например, при бронировании поездки на выходные пользователь может уехать либо вечером четверга, либо утром пятницы, но вернуться ему нужно вечером субботы — здесь вместо повторного ввода или выбора даты в наложении календаря двойной клик приведет к ожидаемому результату.

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

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

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

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

Выбор дат ... везде! Всякий раз, когда время имеет особенное значение, появится таймпикер — будь то медицинский приём, санаторное лечение, прокат лодок, авиабилет, аренда коттеджа или телевизионный гид. Пример: шведская телекомпания SVTPlay.se.
Не все «выборщики» дат одинаковы, и их дизайн будет значительно отличаться в зависимости от контекста. Одно можно сказать наверняка: если «выборщик» дат не отображается, он должен появляться по клику на поле ввода или на иконку календаря.

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