Как указывать диапазоны дат в интерфейсах?

в 11:39, , рубрики: usability, диапазоны, инпуты, интерфейсы, Календарь, юзабилити, метки:

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

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

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

Например, получаются вот такие странные штуки:

Как указывать диапазоны дат в интерфейсах? - 1

Цифрами или текстом?

Казалось бы, всем просто прочитать диапазон 10.07 — 12.07, и никаких проблем. Но мы часто начинаем считать в уме, какой это месяц — июнь или июль? А если написать словами, то будет удобнее прочитать, и понятнее: «10 июля — 12 июля». Но здесь у нас включается диапазон внутри одного месяца, и если экранчик маленький, то хочется этот диапазон сократить. Цифрами короче, но не так удобно, поэтому приходит в голову общую часть (месяц) указать один раз: «10-12 июля». И понятно, и компактно. Ещё из аргументов против: если каждый раз выводить разные заголовки, а не одного формата, это может смутить пользователя. Отвечу так: решение зависит от того, насколько человечным хочется получить интерфейс. Чем более человечным (до формата общения между живыми людьми), тем более нормальными будут выглядеть разные оповещения. Это каждый продуктолог должен решить для себя самостоятельно.

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

Допустим две пользовательских ситуации:

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

DD.MM.YYYY — DD.MM.YYYY.

Технически диапазон дат мог бы быть записан так: DD.MM.YYYY — DD.MM.YYYY. Всё понятно.

Когда приходим к реальным датам, может получиться следующее:

09.03.2014 — 09.03.2014, то есть указан диапазон (например, расходов, или упражнений в спортзале) в один день. Технически снова всё верно, но для человека это:

  • один день (сутки);
  • это один конкретный день (что важно — именно конкретный день/сутки);
  • если этот день — текущий (сегодня), то пользователю слово «сегодня» будет понятнее, чем дата. А если вчера — то «вчера» тоже хорошо. Сколько я потратил вчера? — Столько;
  • наконец (?), если этот диапазон = дата (сутки = диапазон) — конкретный день прошедшего/прогнозируемого года, то более человечно показать его в формате «9 марта 2014 г.», а если не влезает (крупный шрифт или часы), то «9 мар. 2014 г.», или «9 мар. 2014», сомнительно уже — «09.03.2014» и на худой конец — «9.3.2014».

!То есть диапазон в один целый (или текущий) день или целые неделю/месяц/квартал/полугодие/год/десятилетие/век логично сокращать до одной сущности (сомнения вызывают десятилетия и недели — номерами календарных недель всё-таки редко думают).

Другая история — пересечения. Там тоже всё понятно: общее самое большое значение — выносим правее (1-3 марта, 3 марта — 15 апреля 2015 г. и т.п.). Но 2010-15 гг. (тысячелетие всё-таки слева).

Чувствуется, что можно опускать значения типа текущего (нынешнего) года. Например, если сегодня — 15 января 2016 г., то при выбранном, например, 10 января, писать просто «10 января». Месяц опускать как-то рука не поднимается :-)

Табличка v1.0: попытка систематизации этих самых сокращений

Как указывать диапазоны дат в интерфейсах? - 2

Я рассмотрел варианты для дней (недели пока пропустил, но в плане есть), месяцев, кварталов, полугодий и лет, они в табличке.

Пояснения к таблице:

  • Курсивом выделены смущающие меня моменты.
  • Красным — то, что мне кажется недопустимым или непонятным (вызывает больше всего вопросов).
  • Редактировать таблицу нельзя, а комментарии к ячейкам указывать можно. Я их с удовольствием изучу.

О том, что и как грамотно:

  • Ставить г. и гг. для года и диапазона лет. 2015 г. и 2000-2005 гг. По теме: new.gramota.ru/spravka/letters/22-spravka/letters/90-data
  • Писать название месяца с большой буквы в начале строки / после точки и с маленькой после цифры года (т. е. если не в начале). Например: Ноя. — дек.
  • Сокращать числительные правильно: ilyabirman.ru/meanwhile/all/o-naraschenii-okonchaniy-chislitelnyh
  • Диапазоны с названиями, НАВЕРНОЕ, корректно разделять ТИРЕ (—), а числа — ДЕФИСОМ (-). Например: 12 апреля — 12 октября, но 12-17 апреля и 1998-2000. Интересно, что думаете на эту тему.

Кстати про «сегодня» и «вчера» в ленте

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

Ещё интересные моменты, на которые обратили внимание коллеги

Что такое «за последние сутки»? — встречается такая формулировка в приложениях. Ещё говорят «последние 24 часа». В зависимости от, например, биллинга, это могут быть 24 часа назад от текущего момента, а могут быть календарные сутки, которые начинаются в 00:00. Мне кажется, что если система считает именно по 24 часа назад от текущего момента, то это необходимо указывать специально и однозначно.

Если расширить тему, то в этом контексте можно учитывать и часовые пояса. Актуально для активных путешественников. Например, я — в США, разница с Москвой от 8 часов. Если я приехал недели на две, детализация выписки внутри приложения мне будет интересна по локальному времени, независимо от того, по какому часовому поясу считает то же московское банковское приложение. Ведь на часах телефона у меня скорее всего автоматически проставится локальное время (например, Нью-Йорк).

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

P.S.

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

Автор: RockBee

Источник

Поделиться новостью

* - обязательные к заполнению поля