Tag Info

Hot answers tagged

26

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


19

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


11

In my experience if you want them to focus on something, you need to make it as clear as possible. If you are looking to have them focus on the month, then you should focus on the month directly. Comparing your two examples, the second one is far, far easier to understand, but I would definitely use the full month names, instead of dates. I think the month ...


11

I think it's better to put n-dash symbol (U+2013) without spaces on sides. This is typographically right. There is no strict rules about it so you are free to use western tradition. What is the difference between dash and n-dash, you can read here: http://en.wikipedia.org/wiki/Dash


8

Other reasons for using a calendar widget (besides taking care of format): Picking date ranges: from/to, start/end, depart/return dates. Providing custom presets for dates and date ranges such as: "A week from now" or "Month to date". Associating date and time (when time is required). They are inseparable in real-life, why separate them (in different ...


7

You should definitely allow the user to make this choice independent of their locale settings. Many people will want their planner calendar to match up to other calendar software in which they may have made custom settings, or to match features of their work schedule or lifestyle that might not be represented in the standard for their locale.


7

I like both ideas, although I'm leaning more towards the second design because it better illustrates the idea of fullness (of schedule) which is what you're trying to convey. In the first design, the days with more tasks are more prominent than the ones with less tasks, which is the opposite of what the user is going to be looking for (less busy days). If ...


5

Sorry, first it looks too complex. Still, calendar view provides much better user experience in date-related matters. This is an Excel quick sketch. The root of the problems with you current design is in time perception by human and bad human abilities of mental manipulation with data. Some possible issues are: weak relation to current date requires ...


5

You're trying to relay the "fullness" of a day but neither visualization provides that information at a glance. The heatmap needs a key, and the horizontal bar feels more like a progress indicator. A pie, while widely panned, is a common indicator of "fullness". Here's a quick mockup to give some flavor. It works great with your defined rule of 0 to 4 ...


5

The international standard defined in ISO 8601 is that a week begins on Monday. That means that you don't set someones week starting with Sunday based on language configurations. Monday is always the correct default. If you want to give the user the choice to use a nonstandard calendar that starts with Sunday, the user should make that choice himself.


5

WHEN They are extremely useful for planning events in the future or for exploring times in the past as well as planning ranges for examination of some sort. Use it anytime you could see your user going to their calendar on the wall and attempting to plan the future or examine past events. WHY The calendar is probably one of the greatest examples of ...


5

The reason why the two calendar approach has been adopted so widely and is so convenient to use is because it is in sync with the users' thinking process i.e. when people go for booking a ticket, they know the dates for departure and return of their travel but are not often consciously aware of the duration of their stay. Making them state the duration (and ...


4

Consider: Start: Mon 9/1/2014, 8PM Ends: Tue 9/2/2014, 12AM (28 hours long) Although not directly in your question, be prepare for 12AM to confuse users - is it midnight or midday (the former is the convention, but many people don't know this). By the way, if your event is never more than 6 hours long consider: Start: Mon 9/1/2014, 8PM Length: 4 ...


4

Depending on how flexible you are with your interface design, you could have them default to entering 14 for weeks and 14d for 14 days or vice versa. Display it as 13w 6d with some logic behind to catch the zeroes. If it is a non-mouse workflow, typing is fine to optimize for. As for the sorting, again depending on the design environment you might be able to ...


4

whats the best way to handle the mixture of leadtimes? Since you want to have a universal reference point, you would want to use your loweset time unit as the reference point. For example, if your lowest time unit available is hours, then all user inputted time should be converted to hours. Of course, this should happen in the back-end for sorting and ...


4

The date should be shown only once, but aligned with the first date, but not show the dash indicating it's a range. I think showing the same date twice is very confusing, because the user does not only read the same date twice. After seeing what seems to be the same date twice, he would need to reread it to make sure he did not just misread. Then he needs ...


4

I think you've pretty much sold the duration idea, but I'm not sure how it would be quicker on touch devices? Also, I'm not sure why there's a combobox for duration. It's an extra click and I'm not sure what's inside. Perhaps you may wish to borrow some ideas from this design: Notes: I'm sure you can do a better job on the colours. On the calendar, ...


3

I think your two bullet points succinctly sum up when they make sense and when they don't. Our error, perhaps, is that we've long called them 'date pickers'. They really should be called 'day-of-the-week' pickers in that they are useful when, as you point out, the visual cue of a calendar makes sense...when you need to know the day of the week, or which ...


3

What about using dots? It is very similar to the bar graph, but doesn't give the same feeling of waiting (a progress bar is usually something you watch fill up). The dots convey the same information, but not the "progress"ness of the bar. Also, I used background color to represent today's date, and border to represent selected day. Two different things that ...


3

I would suggest a combination of the two. The first is great for instantly knowing which days have something but shades require looking at a key which is user friction The second is great for knowing quantity but is somewhat busy so seeing which days have something at a glance is not as clear (although it is relatively clear) A combo approach would be all ...


3

Please see ISO 8601 (eg http://en.wikipedia.org/wiki/ISO_8601) yyyy-mm-dd hh:mm:ss First, this is simply the largest to the smallest unit. No other argument--no matter how tightly held--can seem to overcome this logic. The 4-digit year removes any confusion as to what the other numbers represent--even when the hyphens are left out. (Use of a 2-digit ...


3

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


3

A combination is normally a good way to go. As an example, the London Underground website allows you to check train schedules at a given date/time. When you go onto the site, it defaults to 'Today' for the date and the current time: When you choose to edit the date, while giving a date picker, it also provides quick links to "today" and "tomorrow", ...


3

I'm currently implementing a date range picker like yours but with a few differences: I have "other..." as an option below the canned date ranges. This way people will know that they have more options and will choose that if their choice isn't in the list. The custom fields are hidden until "other..." is selected. This is just a design choice to make the ...


3

I think one common approach is to put (+1 day) next to the 12 A.M. time. This is used for example in flight searches.


3

The simplest notation I've seen is to simply bold them. Another option is to give them a slightly different background color. It really depends on how you are using other elements to indicate events on days. It often helps to include in the top row the list of days so that it is clear whether you are formatting using S M T W R F S or M T W R F S S for your ...


3

I would feel relatively safe in assuming that any 2 digits that are equal to or less than the last 2 digits of the current year are describing the current year. So today, it would be numbers 00-14. There is a small chance that there are people 100+ years old that will be excluded but in today's world, when I say "back in '07" I mean 2007 and not 1907 so ...


2

have you considered drop downs ? if your goal is to reduce clicks then providing three drop downs would be a good solution. Assuming a wide range of possible input dates, an assumption based on the assertion that you don't want users to click lots on a date picker, perhaps looking at how sites handle dates of birth would be a good idea. Dates of birth ...


2

I worked on a commercial product where this was an important issue. Here are a few considerations in addition to the article referenced above discussing localization formats: How does the user identify the rows they need? If they are trying to identify the orders by first-in-first-out you can consider changing the date to something like "2 hours ago" or ...


2

I think is important to point out that HTML 5 has a new input type=month which seems to be exactly what you want. And altought most browsers doesn't support it yet that doesn't mean we should overlook that. Because they'll probably implement that in the near future, and then most users will be presented with their most familiar and fast UI for each device ...



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