Hot answers tagged dates
48
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 in the US 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 ...
47
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 ...
23
In general users are pretty accurate and fast at entering dates as strings in a text box as long as your validation isn’t unnecessarily fussy and provides decent auto-correction and defaults for the sub-fields (e.g., accepting 2-9-04 as well as 02/09/2004). Calendar controls are great to provide as an option when the user isn’t certain of the date (e.g., for ...
22
I do believe a regular textbox with an indication of the expected format is often enough. Like Kevin mentioned, if you use a date picker you should absolutely provide a method for direct entry. Many people prefer to simply type the date.
But this is what I do on Techinsurance.com...
Of course I have client and server side validation in place as well. ...
22
I definitely agree with Rahul, that it depends on the context. A calendar widget is super useful for going back or forward a few months, but not so great for picking your birthdate -- that'd be a clicking nightmare!
I personally hate those date pull-downs to pick your birthdate, also, as they tend to be a pain to hit your target selection, but I saw a nifty ...
17
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.
15
Birth year: They keep starting at the current year, when most people will be 18+ and have to scroll more than 18 years to get to their age. They feel old and have to scroll a lot.
Date Picker vs just typing it in: unless the date requires context of other dates or you need to select a range, just let people type in the date. Its proven that people don't ...
14
In my opinion, relative dates are incredibly helpful (when used correctly). A relative date, such as yesterday, two days ago, last week provides you with more information than 8/9/2011, 8/8/2011, or 8/2/2011. It not only gives you when something happened, but it tells you when something happened in my current context of now.
I have done some design work ...
13
Remember that user-friendliness is a product of your audience and the domain of your app. For instance, if you're building a service like Kayak, you're going to be focusing on reasonably tech-savvy users who will be using date controls a lot during their experience with your app. On the other hand, Google and Amazon have broader audiences and fewer ...
12
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 ...
12
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 ...
11
A free text field with an example is clear, and quick and easy for people to use.
________
Date of birth |________| (example: 31/5/1970)
Dropdowns could be all right for day and month, but not year. It's probably easier to type a four-digit year rather than scroll all the way down to 1950-whatever. The only real benefit of dropdowns is ...
11
Displaying an error message
Ideally you want a combination of your #1 and #2 suggestions:
Please select a date that doesn't fall on a weekend or a holiday and is at least 3 business days from now.
The reason this is the best option is because this is what you would say to a person if they were standing next to you. A good rule of thumb for error copy, or ...
11
Date validation has always been a problem due to American MM/DD/YYYY vs small Endian DD/MM/YYYY vs ISO YYYY-MM-DD, I can't imagine asking or allowing users to enter raw numbers with no separators and hoping it works well. In my subjective experience I must also say I have no idea who on earth would enter a date in this format unless it was a date field such ...
11
The usual caveat of "it depends" applies -- if the users are typing in dates which they are reading off from somewhere else, and that reference material is formatted as MMDDYY or MMDDYYYY then, yes, let them simply transcribe it.
Also, if the users are data entry process workers (eg. in a call centre) and not casual website visitors, then let them perform ...
11
The problem is that the date is never ambiguous to the user - they always know what they mean.
User enters 091011
System displays 09/10/11
User assumes the computer understood correctly.
Simply accepting 091011 and leaving it that way doesn't resolve this because the user doesn't get to see if you have a difference of interpretation.
Key Principle
...
11
As long as it truly is within a single year, a range slider seems appropriate here.
via Kevin Anderson on Dribbble
EDIT:
The date range picker on the google finance site solves the problem with my previous answer. This example doesn't "snap" to month increments, but a different implementation certainly could.
11
If a range of months could span across the year end, perhaps a circular dial makes more sense.
Since you have limited vertical space it would have to be a dropdown though.
Something like this perhaps:
10
Why not consider a timeline slider, with the most recent reports snap-to points for selecting?
If you have reports back to 1860, how often do they need to go back?
| Report XYZ, Jan 12, 1983 |
<--- Earlier \/ Later --->
...
10
Try doing a google search on calendar icon and then you capture the results (if worth it). Just by skimming the results I saw that 9 was a popular number, but not far from others.
From the Semiotics perspective 31 might work, as people easily identify it as the maximum number of days a month can get, and design-wise is filling.
I think that only having the ...
10
If you are asking for data that usually follows a particular format, then ask for it in that format. Visually people are used to months shown in a calendar, so show it in a calendar, and let them select the months that they want.
Visually it is very easy for someone to see whether they have the months that they want like that. Here is a quick example of ...
9
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 ...
8
if your really have to, don't show time zone info but the city associated with the event (or the time zone if no location is provided).
Better, don't show time zones at all. What does it matter if I'm in time zone X, as a user I want it all normalized to my time zone. You loose track of concurrency if you show multiple time zones on one screen.
Ideally you ...
8
I would show a calendar picker with non-selectable days grayed out. When the user hovers over the non-selectable day, I would display a tool tip explaining why that date isn't selectable.
For instance, here's an example of blackout dates from MSDN:
(Sidenote: Are you sure there's a reason for having the user select their shipping date? In most ...
8
Some words for this date-control:
Absence of false associations at interaction with a date control. In other model you can choose any date which will be automatically set as the first date of month. In practice the similar situation will be regarded as an error of a date-control & quite predicted action of the user will be attempt to establish the ...
7
Keep data entry free form when possible
Programmers are lazy! Let the computer work a little and consider not even having a specific date field for initial date entry. Google Calendar, when creating a new event, simply allows you to say:
4 July: Dinner at Joe's place
GC then figures it all out for you (including where), and, based on your user profile ...
7
As long as the date isn't ambiguous, it should be allowed. If you indicate that your expected format is MM/DD/YYYY and they enter 091011, consider auto-correcting it when they lose focus to the textbox. So it'd become 9/10/2011.
Of course the important thing here is that you should indicate your expected format. I was responsible for a site which saw ...
7
This is a rather old and well-tested interaction pattern and it's simple. First, the user has to define the recurrence interval (weekly, monthly, annually) and then the specific pattern to be repeated (date or day of the week).
As you can see in the screenshots below, the "bare minimum" of controls is still a great number if you want to provide flexible ...
7
I do not recommend the highlighting of 'contained' choices. It is an interesting idea, but the edge cases (where previous day, week or whatever are partially or ambiguously contained in the selected choice) would make it confusing, not clarifying. If the effect does not tell anyone something they can't easily know then it doesn't really serve a purpose.
As ...
7
Your proposed solution also introduces a jump. If it's 20 June 2013, and I see a post dated “22 June”, I'm going to think “June this year”, and then do a double take because that's still into the future. When it's June 2013, all posts from June 2012 should be marked “June '12”. As the end of the month approaches, it may be good to mark posts from July as ...
Only top voted, non community-wiki answers of a minimum length are eligible
