Поясню задачу: например, необходимо в мобильном приложении вывести сводку по расходам за определенный период и сформулировать понятный пользователю заголовок с выбранным диапазоном дат. Так, чтобы не набор цифр, а чтобы по-человечески понятно было.
Ширина экрана мобильного устройства чаще всего небольшая, поэтому есть необходимость сокращать. При этом, кроме технической ширины, хочется учитывать еще и эстетическое восприятие и не грузить интерфейс лишними сущностями. Аналогичная ситуация с инпутами в вебе. Усугубляется ситуация на мелких устройствах типа часов и разного рода небольших дисплеях.
Например, получаются вот такие странные штуки:
Цифрами или текстом?
Казалось бы, всем просто прочитать диапазон 10.07 — 12.07, и никаких проблем. Но мы часто начинаем считать в уме, какой это месяц — июнь или июль? А если написать словами, то будет удобнее прочитать, и понятнее: «10 июля — 12 июля». Но здесь у нас включается диапазон внутри одного месяца, и если экранчик маленький, то хочется этот диапазон сократить. Цифрами короче, но не так удобно, поэтому приходит в голову общую часть (месяц) указать один раз: «10-12 июля». И понятно, и компактно. Ещё из аргументов против: если каждый раз выводить разные заголовки, а не одного формата, это может смутить пользователя. Отвечу так: решение зависит от того, насколько человечным хочется получить интерфейс. Чем более человечным (до формата общения между живыми людьми), тем более нормальными будут выглядеть разные оповещения. Это каждый продуктолог должен решить для себя самостоятельно.
Ещё есть чисто ментальные состояния восприятия типа «в этом году» против «в прошлом году», «сейчас» против «тогда», «сегодня» против «вчера»/«в прошлом» и т.п. Их можно учитывать для того, чтобы опускать понятные из контекста ситуации: например, текущий год.
Допустим две пользовательских ситуации:
- Пользователь только что указал диапазон и понимает, что увидит в заголовке. В этом случае наша задача (или задача заголовка) — однозначно подтвердить пользователю корректность указанного им же диапазона. Однозначно в буквальном смысле — то есть чтобы не было других значений (написанное истолковывалось корректно).
- Пользователь перешел в раздел и увидел в заголовке выставленный по умолчанию диапазон дат. Этот диапазон должен быть однозначно прочитан.
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: попытка систематизации этих самых сокращений
Я рассмотрел варианты для дней (недели пока пропустил, но в плане есть), месяцев, кварталов, полугодий и лет, они в табличке.
Пояснения к таблице:
- Курсивом выделены смущающие меня моменты.
- Красным — то, что мне кажется недопустимым или непонятным (вызывает больше всего вопросов).
- Редактировать таблицу нельзя, а комментарии к ячейкам указывать можно. Я их с удовольствием изучу.
О том, что и как грамотно:
- Ставить г. и гг. для года и диапазона лет. 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.
Наверняка кто-то это дело уже причесал и привёл в порядок. Может быть даже кто-то из разработчиков придумал схему и всё это реализовал. Если так — то это замечательно и буду признателен коллегам, которые обозначат эти решения. Если нет — буду признателен за ваши мысли по теме и предложения по её развитию. Также буду признателен педантам и знатокам за любую информацию по форматам записи подобных штук.
Комментарии (28)
Nesvet
27.01.2016 15:24+4Диапазоны с названиями, НАВЕРНОЕ, корректно разделять ТИРЕ (—), а числа — ДЕФИСОМ (-). Например: 12 апреля — 12 октября, но 12-17 апреля и 1998-2000. Интересно, что думаете на эту тему.
Тире — соединяет, дефис — разделяет. В обоих случаях следует использовать тире. Для числовых диапазонов приемлемо использовать среднее тире (en dash; – вместо —)
RealFLYNN
27.01.2016 16:08Сам написал про короткое тире, потом увидел ваш комментарий. Насколько мне известно, в нашей типографике нет четкого правила, касательного этого знака, а вот в англоязычной числовые диапазоны принято обозначать именно им. И, характерно, гораздо аккуратнее смотрится:
2003–2007
2003—2007
kahi4
27.01.2016 16:46+2В нашей типографике есть такое правило. Только культура типографики нашу страну обошла мимо, поэтому на полках сотни ужасно сверстанных книг, что кажется, что у нас ничего из этого не принято.
О том, что и как грамотно:
Ожидал увидеть ссылку на ГОСТ ИСО 8601-2001, ГОСТ 7.64–90 и прочие. Эх, а там ведь все расписано.
Stalker_RED
27.01.2016 19:08+1Ну, в советское время в крупных издательствах верстали очень даже прилично. Ужасно сверстанные книги, по большей части наследие лихих девяностых, когда каждый второй пользователь ворда возомнил, что его творение можно напрямую относить на печать.
RockBee
27.01.2016 22:10+1Не нашел там упоминаний про формат «число — название месяца буквами — год». Плохо искал? Буду признателен, если подскажете, где там этот формат описан, и реально ли выносить год у диапазона и указывать его один раз, а не два?
dom1n1k
27.01.2016 22:40Причем я бы использовал среднее тире в обоих случаях.
Длинное имеет смысл в тексте, но в мобильном интерфейсе избыточно.
achekalin
27.01.2016 22:57Как вариант, неплохо визуально работает многоточие (для веба и небольших экранов — смотрятся и 2, и 3 точки подряд), особенно когда диапазон образован только числами одного типа, скажем, «отчет за 2010..12» (сравните с «отчет за 2010-12» — такое написание заставляет думать не про два года, а про декабрь одного года).
vlivyur
27.01.2016 15:30+1Месяц опускать как-то рука не поднимается
После того, как вы применили «вчера», «сегодня», выкинули текущий год, отчего же на месяц рука не поднялась? Делаем скриншот этого «сегодня», а завтра в 00:01 ответьте на вопрос: сегодня — это когда? а через неделю дату сможете назвать?RockBee
27.01.2016 15:39В тексте я написал о том, что решение про очеловечивание следует принимать продуктологу, который отвечает за результат и понимает специфику приложения. Не всегда это уместно, конечно. Но иногда — очень даже.
Просто число смотрится куцо и непонятно. — 15. — Что «15»? — А что приборы"? :-) Поэтому и не поднимается.
Далее:
1. Я специально обозначил условия, в которых оказался пользователь.
2. Про 00:01 сегодня — это текущая календарная дата. По идее, если экран был открыт а, условно, 23:59, то в 00:01 этот же экран должен назваться «вчера» либо обновить данные (сильно зависит от того, что выводится и какова специфика приложения). В общем же случае «сегодня» — это с 00:00:00 до 23:59:59.
3. Числовые данные логично помещать внутрь записей, если это лента. Скорее всего на скриншоте они окажутся.
dom1n1k
27.01.2016 18:32+1Кмк, заменять даты на «сегодня»/«вчера» допустимо только там, где точная дата события вообще не важна, примерной достаточно. Например, пост на флудофоруме, публикация фото в соцсети, комментарий на юморном сайте. Ну действительно, какая там разница, запосчено это 22 или 23 дня назад? Достаточно просто видеть свежак это или старое. А вот в любых рабочих приложениях и сервисах за такое «очеловечивание» надо отбивать руки.
vlivyur
30.01.2016 23:39Я, кстати, нашёл ситуацию когда мне ближе и роднее не точная дата, а относительная: до конца срока осталось 2 года, 1 месяц, 1 неделя, 6 дней, [0 часов], 21 минута. Но и всё равно точная дата нужна.
Methos
27.01.2016 20:56Особенно добивает на инстраграме ихние 23h или 12w, или 123w.
Посчитать точную дату ВООБЩЕ невозможно, если конечно сначала догадаться. что это означает; это уму непостижимо. Видимо, юзеры так далеко не прокручивают =))
Намного же легче сразу увидеть 8 oct 15
mkuzmin
27.01.2016 17:59+1буду признателен коллегам, которые обозначат эти решения.
github.com/darkleaf/date_range_formatter
Это решение для ruby или ruby on rails.
Все работает через локали github.com/darkleaf/date_range_formatter/blob/master/lib/locale/en.yml
ivanbolhovitinov
27.01.2016 18:11Если то, куда это приворачивать не позволяет писать передним числом, то имеет смысл формулировать иначе, то есть не «с начала недели», а проще, например: «Эта неделя». Так же и «Этот месяц» и «Этот год».
Кроме того не хватает:
— Прошлая неделя
— Прошлый месяц
— Прошлый год
Methos
27.01.2016 19:50-2Все эти «вчера» — это неправильно.
Ибо допустим, открыли вы страницу в браузере и вдруг забыли о ней на пару дней, открываете вкладку и видите «вчера». А на самом деле это было 3...4 дня назад.
Вариантов море — например, распечатка страницы. А там везде «вчера». И читая такую бумажку через 10 лет, дату ВООБЩЕ НЕВОЗМОЖНО узнать.
Точно также это будет при сохранении страницы на диск. Там будет «вчера», а не дата. И читая через 3 года статью, дату вспомнить нереально.
Вчера — это ужас, поймите вы. Дата вообще почти не играет никакой роли и вообще всё равно, вчера это было или неделю назад, но точная дата нужна для истории.
Поэтому, ребята, прошу вас, указывайте дату полностью, вот так "26.01.2016" или вот так "26 янв 2016" или как-то похоже, но чтобы число, месяц и год БЫЛИ ВСЕГДА.
Ну хорошо. Хотя бы указывайте полную дату в атрибуте title или ещё как.
Спасибо.
Rastishka
27.01.2016 20:10-1Ибо допустим, открыли вы страницу в браузере и вдруг забыли о ней на пару дней, открываете вкладку и видите «вчера». А на самом деле это было 3...4 дня назад.
Эта проблема решается на JS. Вчера/позавчера/сегодня сразу понятно, в случае дат надо помнить какое сегодня число.
Methos
28.01.2016 23:22Желательно использовать такое форматирование даты:
<time itemprop=“startDate” datetime=“2012–05-08T19:30?>8 Мая, 19:30</time>
То есть, внутри пишите что хотите, хоть «позавчера», а вот полную дату и время не забывайте сохранять в атрибутах, причём лучше ещё использовать атрибут title
<time itemprop=“startDate” datetime=“2012–05-08T19:30? title="8 Мая, 19:30">позавчера</time>
Pilat
28.01.2016 03:27+1Правильно — сделать несколько вариантов типовых форматов и конструктор формата (это несложно) и предоставить пользователю на выбор. Даты — самый сложный вопрос в информатике ещё со времён Джоэла Спольски.
По приводимым примерам… 09.03.2014 — это девятое марта или третье сентября? А в каком часовом поясе? Или это вообще местное время для какого-то города? И такие вопросы возникают в зависимости от предметной деятельности.
EndUser
28.01.2016 06:19>Что такое «за последние сутки»?
Чёртезнает.
Если бы писал я, то я бы писал либо «текущие сутки», либо «за 24 часа».
И ин100грамм бесит, да, с его «53w ago».
petertretyakov
28.01.2016 09:53Один кейс про «человечные» даты, который я так и не смог для себя решить: когда «сегодня» становится «вчера»?
Вот сижу я, например, уставший, после работы в 23:59 и просматриваю все свои расходы за день в приложении для учета финансов, периодически заходя в некоторые транзакции, чтобы вписать комментарий или изменить категорию, и возвращаюсь к общему списку, нажимая кнопку «Сегодня». И вдруг я вижу не список за день и общую сумму, а пустой список и 0. Потому что уже не 23:59, а 00:00.
Или, например, заводишь транзакцию в 00:05, для тебя-то до сих пор сегодня, а для программы уже завтра началось.
«По-человечески» следующий день должен начинаться, когда я проснулся на следующий день. Поэтому одно из простых решений сделать переход с сегодня на вчера, например, в 4:00. Это решает часть проблем, но создаёт новые ))
Какие тут есть варианты?
Alexus1024
28.01.2016 10:02Не, если UI формируется где то около полуночи (например, менее чем за час до), отключать все плюшки про «вчера» и «сегодня» во избежание.
Мне кажется, около полуночи никто не захочет возиться с этими понятиями.
serafims
Вот только иногда важно не просто видеть «вчера» «два дня назад», но и полную дату со временем. Такая фигня часто мешает найти номер в списке вызовов, который был совершен на рубеже дней, знаешь дату и время примерное, но вот как перевести это в мифические «N дней назад» по тому же алгоритму, что и телефон, — занимает время и совсем контрпродуктивно.
Лучше так: 6 дней назад, 20 января 2015 г., 14:55:30.
RockBee
Салют!
Спасибо за комментарий. Я полностью согласен. Я тоже в эту сторону думал, и вот к каким выводам пришел:
1. Нюанс: я ставил себе задачу сократить вывод (длину) именно заголовка, а не записи для позиции в ленте.
2. Не уверен, что словесные конструкции глубже, чем «вчера» есть смысл использовать в принципе (только понятные типа «с начала недели/месяца и т.п.»).
3. Точную дату для конкретной записи, вплоть до времени, надо писать в конкретной записи.
4. Принципиально, если размер заголовка (или физическое место) позволяют, то можно указывать и очеловеченный заголовок, и цифровой (последний можно выводить мельче, например).
fundorin
Почему бы не использовать трёхбуквенные сокращения месяцев? янв, фев, мар, апр, май, июн, июл, авг, сен, окт, ноя, дек. Мне кажется, многие так делают.
RockBee
В таблице есть, в колонке «сокращенный вариант».