How to specify date ranges in interfaces?
An unequivocal and exhaustive answer to the question did not provide a superficial search, academic reference books often produce results for publications (including with the use of Roman numerals, which is not very suitable for interfaces), so I want to understand how to specify the ranges dates and in the interfaces and try to formulate a rule or identify patterns. To do this, I remembered everything I could, cases, and arranged them in a table - case, numerical example, full and abbreviated format, for days, weeks, months, quarters, half-years and years (inside the post).
I will clarify the task: for example, it is necessary in a mobile application to display a summary of expenses for a certain period and formulate a user-friendly header with a selected date range. So that not a set of numbers, but so humanly understandable.
The width of the screen of the mobile device is often small, so there is a need to reduce. At the same time, besides the technical width, I also want to take into account the aesthetic perception and not load the interface with unnecessary entities. The situation is similar with input on the web. The situation is aggravated on small devices such as clocks and various small displays.
')
For example, such strange things happen:
It would seem that everyone just read the range 10.07 - 12.07, and no problems. But we often start counting in our mind, what month is it - June or July? And if you write in words, it will be more convenient to read, and more clearly: “July 10 - July 12”. But here we have the range included within one month, and if the screen is small, then I want to reduce this range. The numbers are shorter, but not so convenient, so it comes to mind the general part (month) to specify once: "July 10-12." Both clear and compact. Another of the arguments against: if each time displaying different headers, and not of the same format, this can confuse the user. My answer is this: the decision depends on how human I want to get the interface. The more human (up to the format of communication between living people), the more normal the different alerts will look. This is every productologist must decide for themselves.
There are also purely mental states of perception like “this year” against “last year”, “now” against “then”, “today” against “yesterday” / “in the past”, etc. They can be taken into account in order to omit the situations that are clear from the context: for example, the current year.
Technically, the date range could be written as follows: DD.MM.YYYY - DD.MM.YYYY. All clear.
When we arrive at real dates, the following may happen:
03/09/2014 - 09/03/2014, that is, a range is indicated (for example, expenses, or exercises in a gym) on the same day. Technically, this is all right again, but for a person it is
! That is, the range of one whole (or current) day or the whole week / month / quarter / half-year / year / decade / century is logical to reduce to one entity (the doubts cause decades and weeks - they rarely think with numbers of calendar weeks).
Another story is the intersection. There, too, everything is clear: the overall greatest value is to the right (March 1-3, March 3 - April 15, 2015, etc.). But 2010-15. (the millennium is still left).
One feels that you can omit the values ​​of the type of the current (current) year. For example, if today is January 15, 2016, then with a choice, for example, on January 10, to write simply “January 10”. The month to lower somehow the hand does not rise :-)
I considered the options for days (I missed the week so far, but there are plans in the plan), months, quarters, semesters and years, they are on the plate .
Explanations to the table:
In a similar way, specific instructions are given in Apple's mail (and there are probably many more where, because it is normally perceived): when did the letter arrive? - today, yesterday, and if “today” = “Friday”, then “the day before yesterday” and before the beginning of the week will be shown as “Wednesday”, “Tuesday”, “Monday”, and then on digital dates. A sort of conditional attenuation principle (it is logical to assume “last month”, “last year”, “in a decade”, “century”, “millennium” - but let's leave this research behind the brackets). First - humanly, then, the farther into the past - more numbers. It should be separately painted for tapes and similar records.
What is the "last day"? - there is such a wording in the annexes. They also say "the last 24 hours." Depending on, for example, the billing, this may be 24 hours ago from the current moment, or it may be a calendar day that starts at 00:00. It seems to me that if the system counts exactly 24 hours ago from the current moment, then this must be indicated specifically and unequivocally.
If you expand the topic, then in this context you can take into account time zones. Actual for active travelers. For example, I am in the USA, the difference with Moscow is from 8 hours. If I arrived for two weeks, the detailing of the statement inside the application will be interesting for me in local time, regardless of what time zone the Moscow banking application considers. After all, on the phone's clock, I most likely will automatically have a local time (for example, New York).
Intervals "from - to" and "from - to". It is about when to include the phrase "inclusive", and whether it is necessary to use different approaches within the same interface (when the last day is included in the range or not). It seems to me that different approaches cannot be applied - there must be one. It seems that by default it is logical to use “inclusive” (without the need to write the word “inclusive” everywhere).
Surely someone has already combed this business and put it in order. Maybe even one of the developers came up with a scheme and implemented it all. If so, then this is great and I will be grateful to colleagues who will designate these solutions. If not, I would appreciate your thoughts on the topic and suggestions for its development. I will also be grateful to pedants and connoisseurs for any information on the recording formats of such pieces.
I will clarify the task: for example, it is necessary in a mobile application to display a summary of expenses for a certain period and formulate a user-friendly header with a selected date range. So that not a set of numbers, but so humanly understandable.
The width of the screen of the mobile device is often small, so there is a need to reduce. At the same time, besides the technical width, I also want to take into account the aesthetic perception and not load the interface with unnecessary entities. The situation is similar with input on the web. The situation is aggravated on small devices such as clocks and various small displays.
')
For example, such strange things happen:
Numbers or text?
It would seem that everyone just read the range 10.07 - 12.07, and no problems. But we often start counting in our mind, what month is it - June or July? And if you write in words, it will be more convenient to read, and more clearly: “July 10 - July 12”. But here we have the range included within one month, and if the screen is small, then I want to reduce this range. The numbers are shorter, but not so convenient, so it comes to mind the general part (month) to specify once: "July 10-12." Both clear and compact. Another of the arguments against: if each time displaying different headers, and not of the same format, this can confuse the user. My answer is this: the decision depends on how human I want to get the interface. The more human (up to the format of communication between living people), the more normal the different alerts will look. This is every productologist must decide for themselves.
There are also purely mental states of perception like “this year” against “last year”, “now” against “then”, “today” against “yesterday” / “in the past”, etc. They can be taken into account in order to omit the situations that are clear from the context: for example, the current year.
Assume two user situations:
- The user has just specified a range and understands what he sees in the title. In this case, our task (or the task of the header) is to unequivocally confirm to the user the correctness of the range indicated by him. Unambiguously in the literal sense - that is, that there were no other meanings (the writing was interpreted correctly).
- The user moved to the section and saw the default date range in the header. This range must be clearly read.
DD.MM.YYYY - DD.MM.YYYY.
Technically, the date range could be written as follows: DD.MM.YYYY - DD.MM.YYYY. All clear.
When we arrive at real dates, the following may happen:
03/09/2014 - 09/03/2014, that is, a range is indicated (for example, expenses, or exercises in a gym) on the same day. Technically, this is all right again, but for a person it is
- one day (day);
- this is one specific day (which is important - it is a specific day / day);
- if this day is the current (today), then the word “today” will be clearer to the user than the date. And if yesterday - then “yesterday” is also good. How much did I spend yesterday? - So much;
- finally (?), if this range = date (day = range) is a specific day of the past / forecast year, then it is more humane to show it in the format “March 9, 2014”, and if it does not fit (large print or clock), then “Mar 9 2014 ", or" 9 Mar. 2014 ", it is doubtful already -" 03/09/2014 "and at worst -" 9.3.2014. "
! That is, the range of one whole (or current) day or the whole week / month / quarter / half-year / year / decade / century is logical to reduce to one entity (the doubts cause decades and weeks - they rarely think with numbers of calendar weeks).
Another story is the intersection. There, too, everything is clear: the overall greatest value is to the right (March 1-3, March 3 - April 15, 2015, etc.). But 2010-15. (the millennium is still left).
One feels that you can omit the values ​​of the type of the current (current) year. For example, if today is January 15, 2016, then with a choice, for example, on January 10, to write simply “January 10”. The month to lower somehow the hand does not rise :-)
Plate v1.0: an attempt to systematize these very cuts
I considered the options for days (I missed the week so far, but there are plans in the plan), months, quarters, semesters and years, they are on the plate .
Explanations to the table:
- The moments that confuse me are highlighted in italics.
- Red is something that seems unacceptable or incomprehensible to me (it causes the most questions).
- You cannot edit the table, and you can specify the comments to the cells. I will study them with pleasure.
About what and how competently:
- Set the year and years. for year and range of years. 2015 and 2000-2005 By topic: new.gramota.ru/spravka/letters/22-spravka/letters/90-data
- Write the name of the month with a capital letter at the beginning of the line / after the period and with a small letter after the year (that is, if not at the beginning). For example: Nov. - Dec
- Abbreviate numerals correctly: ilyabirman.ru/meanwhile/all/o-naraschenii-okonchaniy-chislitelnyh
- Ranges with titles, LIKELY, it is correct to separate TIRE (-), and numbers - DEFICE (-). For example: April 12 - October 12, but April 12-17 and 1998-2000. I wonder what you think on this topic.
By the way about "today" and "yesterday" in the tape
In a similar way, specific instructions are given in Apple's mail (and there are probably many more where, because it is normally perceived): when did the letter arrive? - today, yesterday, and if “today” = “Friday”, then “the day before yesterday” and before the beginning of the week will be shown as “Wednesday”, “Tuesday”, “Monday”, and then on digital dates. A sort of conditional attenuation principle (it is logical to assume “last month”, “last year”, “in a decade”, “century”, “millennium” - but let's leave this research behind the brackets). First - humanly, then, the farther into the past - more numbers. It should be separately painted for tapes and similar records.
More interesting moments that colleagues noticed
What is the "last day"? - there is such a wording in the annexes. They also say "the last 24 hours." Depending on, for example, the billing, this may be 24 hours ago from the current moment, or it may be a calendar day that starts at 00:00. It seems to me that if the system counts exactly 24 hours ago from the current moment, then this must be indicated specifically and unequivocally.
If you expand the topic, then in this context you can take into account time zones. Actual for active travelers. For example, I am in the USA, the difference with Moscow is from 8 hours. If I arrived for two weeks, the detailing of the statement inside the application will be interesting for me in local time, regardless of what time zone the Moscow banking application considers. After all, on the phone's clock, I most likely will automatically have a local time (for example, New York).
Intervals "from - to" and "from - to". It is about when to include the phrase "inclusive", and whether it is necessary to use different approaches within the same interface (when the last day is included in the range or not). It seems to me that different approaches cannot be applied - there must be one. It seems that by default it is logical to use “inclusive” (without the need to write the word “inclusive” everywhere).
PS
Surely someone has already combed this business and put it in order. Maybe even one of the developers came up with a scheme and implemented it all. If so, then this is great and I will be grateful to colleagues who will designate these solutions. If not, I would appreciate your thoughts on the topic and suggestions for its development. I will also be grateful to pedants and connoisseurs for any information on the recording formats of such pieces.
Source: https://habr.com/ru/post/275957/
All Articles