Imagine you’re telling a friend a story about a time you took a flying class. You want to give an idea of when the story takes place. What format should you supply the time in? Should you say “The date was 2014/12/31 and the time was 16:05:03 PST”?
Of course not. The point of the story isn’t the exact time you took the class. You want to focus on ...
There is no universally good answer to this question, but there are definitely two pros of YYYY:
by showing the two leading numbers you can easily tell e.g. 1911 from 2011,
you know exactly where the year is in cases when the year is from the range XX01-XX12.
In other words:
Notation Possible interpretations:
I don't have a pointer to published research - but in my experience US folk will always assume the US MM/DD/YYYY format unless they are knowingly using an non-US site, and are already aware of the potential differences.
If you have to use numbers only then the format that causes least confusion across cultures in my experience is YYYY-MM-DD since it ...
| Past year | Past month | Past week |
This is much less likely to be misunderstood than "last year", and is a common way of presenting menus for selecting a time range. For example, the filters for Google search and Reddit's top posts use this exact wording.
I would go with this kind of UI, reasoning:
Users only select the dates that he/she is applying leave for without having to think about first day of leave and first day of work.
Leave balance is not displayed on the same screen as it might get too cluttered and might confuse the users. For "leave balance" checking, I would suggest to make it accessible from ...
As a rule, it's never OK to use a 2-digit year. If you can prove that using a 4-digit year will cause thousands of babies and cute fluffy bunnies to die horribly, that could be an exception to the rule, but probably not.
I have seen hundreds of costly process failures simply because a programmer thought it was perfectly OK to use a 2-digit year or a local ...
The moment a date is ambiguous you should not convert it to what you think it is.
For example, in most of the world date formats are DDMMYYYY or YYYYMMDD, but for some (silly) reason the US uses MMDDYYYY. You know that this is likely to be a confusion, so don't convert a date that is ambiguous.
If the date is critical, consider using a date picker rather ...
Let 3 days ago mean 3 days ago (not 3 business days).
It seems perfectly reasonable for a Monday-Friday company to want to schedule server maintenance to be due on Sunday morning when traffic to their web services is low. If your UI usually reflects number of business days, when they come in on Monday morning, alerting them that their event is "1 day ...
Not enough reputation to comment, but on many sites with this "friendly" time, you can actually hover to get the exact time.
Try it over on this question's "asked" and "active" times on the right hand side.
We use a simple, single text field with an example instruction, just like Bennett suggests.
Date of birth |________| (example: 31/5/1970)
However, we also add another element onto the page, which we call a Field Reflection pattern. The form takes whatever they entered into the field, and then dynamically parses and interprets it, and reflects the ...
Given today's date, 6/20/2016, I offer my users these choices:
Last 7 Days 6/14/2016 - 6/20/2016
Last 30 Days 5/22/2016 - 6/20/2016
This Month 6/1/2016 - 6/20/2016
Last Month 5/1/2016 - 5/31/2016
This Year 1/1/2016 - 6/20/2016
Last Year 1/1/2015 - 12/31/2015
All Time First Record ...
The international standard ISO 8601 specifies a notation that uses the slash “/” between dates expressed in the year-month-day notation, e.g.
This is the only reasonable globalized notation. But it should normally be used only a) internally in data representation when a date range needs to be represented as one string and b) as the ...
Date pickers are helpful when your concerned dates fall within the context of a month or so but not several years apart as jumping between years would require laboriously many clicks.
Date selectors are not just helpful in reducing the typing errors but they also standardize the formats when several correct variations are possible. For Americans, the ...
This is the use of relative timestamps. In relative timestamps, accuracy isn't important, and immediacy of scanning prevails over accuracy, so things like this may happen, where you see "1 year ago" until Aug 15, 2015, where you'll see 2 years ago. There's a lot of controversy about this approach, and IMHO, it's correct that you could add something a bit ...
If "Day" means something other than "Calendar Day", be specific.
A user reading "3 days ago" will assume Friday if they are reading on Monday, and I find it hard to believe that people will know that "3 days ago" on Monday actually refers to the previous Wednesday.
You could use specific term such as "working day" or "business day" if you choose to exclude ...
People operate on dates in variety of ways:
absolute (e.g. December, 21)
relative (e.g. yesterday, last Monday, tommorow, next Friday, next week, soon, etc.)
As you see, relative way is often prevalent. Calendar with next/previous dates extends the context of use and support relative date references and natural dates flow.
Finally, calendar is just a ...
Timestamps aren't meant for most users
Showing friendly names such as 2 hours ago or yesterday can quickly provide context to the user as opposed to showing them 2015-01-27 18:54:03.259 Mixing both formats together will always cause friction (anything that forces a user to ask a question in their mind adds to cognitive friction). In almost all cases ...
The UK site GOV.UK published some initial test findings about how users on mobile devices use a DOB field they were testing against.
Initial reports suggested that having two dropdowns (one for day and one for month) followed by a text field for year was well received by users, although not exclusively. (emphasis mine).
...This tested much better, and ...
I would skip the 'Last' altogether and go with
Lifetime | 1 year | 30 days | 7 days
At most it would take the user one try to remember what it means, especially if you display the date range of the selected period once selected
I've recently had to make a similar choice. And, yea, as a programmer, ISO 8601 is the best, but most humans do find it unintuitive, unfortunately.
I find that the problem isn't so bad for either side as long as you don't use pure numerical date formats.
So this 12/10/2011 is certainly ambiguous, but Oct 12 2011 is not, and neither is 12 Oct 2011. So just ...
Good answers above. Just one more tip, though:
Consider having your application parse and re-write the date the moment the field loses focus. If the user types 091011, transform it into "9 October 2011" (or "10 September 2011" for US users) - your user will instantly see if his entry has been misinterpreted.
Take this example: 01/02/07.
At first look, it could be anything. Now, let's make it YYYY: 01/02/2007.
Quite a bit of difference, right? This is one of the main reasons for the YYYY format. Very few datapoints are in 2-digit / 2-digit / 4-digit format, and this helps avoid a bit of confusion.
Yes, it is reasonable to right align in your case. For other date and time formats, the alignment can be discussed.
Example from Spotify:
The biggest number can vary in number of figures -- in your case the hour, in this example the minute -- but the smallest cannot.
So right alignment is a simple way to a keep a consistent scale along the Y ...
Your question assumes that
a) date pickers (they aren't called spinners) aren't appropriate everywhere,
b) date pickers can't be modified,
and c) the design guidelines must be followed to the tee.
Thus, I think the proper answer would be a review of SDK manuals & UX guidelines not in any kind of research.
First of all, guidelines are called that way ...
When it comes to date formats you should know who is going to read your page. If you are targeting only people from the U.S. than you are OK using Middle Endian, starting with Month(mm/dd/yyyy), but if you are designing for a world-wide crowd than you should spell out the name of the month. That is what I use on my website. Also in USA people do not like ...
What is the context of your application? Context really matters for dates. Consider the two following situations.
A budgeting application where users plan spending for future years
A college reunion signup where users enter their graduation date
Clearly if people are planning, they would be annoyed to get a date in the past and if people are entering ...
I’ve considered the question recently due to travelling and booking hostels. The same problem appears there, since whether you book the night or the day can be confusing indeed.
For usability reasons, the left one is a better choice since the user doesn’t have to do the maths. In this case, the best way to help the user is to be clear in the definition of ...
Is this for a system where "working days" can change (like this is a piece of software for use by various client businesses), or are working days always M-F?
In either case, you could change the assumption to be that it's counting working days. If that's made known to the users, then you can do the math appropriately and not have to worry about it. So if ...