Tag Info

Hot answers tagged

113

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 ...


68

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 ...


67

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 ...


51

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 ...


45

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.


34

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 ...


27

The international standard ISO 8601 specifies a notation that uses the slash “/” between dates expressed in the year-month-day notation, e.g. 2014-07-15/2015-08-01 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 ...


26

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. ...


26

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 ...


24

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 ...


21

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 ...


21

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 ...


20

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 ...


17

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 ---> ...


17

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 ...


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.


16

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 ...


15

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 ...


15

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 ...


14

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 ...


14

Right align 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 ...


14

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 ...


13

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 ...


13

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 ...


12

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 ...


12

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 ...


12

You've caught a common bug (IME) in the implementation of these relative time/date stamps -- at a step-change in the precision you lose a lot of information due to rounding, and the rounding is always down. It's common (I assume due to a built in library) on Android apps to get "59 minutes ago" (more precise than needed) then "1 hour ago" displayed for the ...


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

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 ...



Only top voted, non community-wiki answers of a minimum length are eligible