New answers tagged dates
0
The reason we use all sorts of various forms for text fields is typically to validate the data. But these, IMHO, are all workarounds that are best handled programmatically. Assuming the app has a sense of regional differences, there's no reason that the date field can't be text and that some logic be applied to properly parse it.
June 8, 1972
6/8/72
...
0
I feel that either single text field or three separate text field would work the best in your case of having speed over accuracy.
Single text fields have their advantages because as a user I do not want have to stare at three different input fields and worry about tabbing through the inputs, however something that needs to be considered is where is the ...
0
I'll spin your question around a bit: how is a datepicker UI useful for filling in one's birth date?
Date Picker UI's are usually useful when it's important to understand the context of the day within a calendar. Ie, when is next Friday? Or what is exactly one month ago?
But with a birthdate, that's a memorized date and where it falls on the calendar is ...
0
download bmml source – Wireframes created with Balsamiq Mockups
I believe that single field (with guidance) paired with the number keypad is the fastest way to input birth dates. The amount of time a user will have to scroll through or tap through things can be reduced if you just give them full control to enter it manually. They'll spend the ...
0
The negative example 11:32 today in JohnGB's answer has another drawback: it should carry the timezone to be meaningful.
UX-wise, yes we want to know the age of the posts we are reading, because we reaction differently depending on it.
So we look at the date information and mentally calculate the post's age, to find out if it's recent, rather old, legacy, ...
7
If you want to refer to a point in time, you need to either give the time, or give a relative time. So that translates to either something like 11:32 today or 5 hours ago. Simply stating "5 hours" tells you nothing really as it is a measurement of a duration of time and nothing more without a reference point. So don't use this.
When people use forums and ...
0
In Europe we always assume DD/MM/YYYY or DD/MM/YY unless it is explicitly an American website or system. There really isn't much confusion, and it isn't an issue most people encounter in their everyday lives. In other words your premise is flawed.
0
Yes we do; hence the Public Service Announcement from xkcd on "... the correct way to write numeric dates".
1
Perhaps start with the year first? You'll initially throw someone off, but for a good reason. I have never seen a YYYY-DD-MM structure in the wild, only YYYY-MM-DD. It would seem to follow for users that this may not be how they are used to seeing the date, but it does make the expectations clear. You could also locate a key nearby for any date format (if ...
0
You could adopt an internationally recognizable format of dd-MON-yyyy to avoid confusion, For example, see: http://www.oracle.com/webfolder/ux/middleware/richclient/index.html?/webfolder/ux/middleware/richclient/guidelines5/commonFormats.html
However I think if the site, portal or app is US Domestic market or business only, then a US format is reasonable to ...
60
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 ...
Top 50 recent answers are included
