Usability: What is the ideal date control?

Mace is not the right answer, effective though. As exciting as date controls are they are pretty easy to get wrong. Date controls have the unfortunate problem of trying to represent a large period of time whilst trying to provide a good level of granularity over that time.

Users want to be able to specify a date and if the date control resembles something they are familiar with (i.e. a calendar) then even better. From what I’ve experienced being able to supply a date as quickly as possible doesn’t come into the equation with most non-technical users. That being said, users do not want to waste time trying to operate an unwieldy date control. They want to supply a value in as many steps as few steps they can conceive in their minds.

Developers and experienced computer operators (data entry personnel, power users) tend to want to do things as quickly as possible. This is at odds with user experience. This is also me. I can type over 120 words per minute. Most users can't. Remember that.

Application Platform
Where the application is running has a big impact on how the user is going to interact with the date control. Console applications obviously are going to use a keyboard mechanism. GUI Applications are a mixture of keyboard input and mouse control depending on how many fields need to be supplied. Web applications are mouse driven, and mobile/pda applications are pen driven (essentially mouse), arrow-navigation driven or touch pad.

The type of mouse also impacts usability of a date control. Touch pad mouses and nub mouses are a different user experiences than the standard hand-held mouse.

Date Selection
The types of dates the user selects is also important. How far in the past will the user be selecting a date? If it is a web-site where someone must be 18 years or older or an student records application that requires the date of birth, the date control is going to require the user select a year at least 18 years to something old like 30 (kidding, I mean 40… no 90.)

Are the dates in the past even allowed? Travel booking sites would rather you booked in the future. Does the user need to select a second date based on the first? Can the user supply a partial date? Is the user required to include a range of dates? Simple date range selection is non-trivial whilst keeping it simple, intuitive and aesthetic.


The Options
There are many examples of date controls out there, so I’ll try to provide a real live example of each one.

Drop Down City:

To be honest I had a worst example available but thankfully I can't seem to find it on google (if I can find it again I will post it as it was atrocious. Note to self: bookmark epic failures under "hindenburg"). To be honest it's one of the few times I have been glad to not find an example. A friend told me Immigration Australia had a drop down city control but I couldn't find it either. FYI Some aspects of their site are rubbish and I'll post that under at separate topic in a day or two once I collect my thoughts.


Above, the wordpress one isn't great. Personally I don't like it. Too many controls for something that could be done visually. Furthermore, the month selector doesn't always respond to user input forcing me into mouse input. Some may claim that this is a browser or OS issue. News Just In: The user does not care what you think, only what they experience.

Anyway, back to my original impressions: for starters, lots of drop downs look hideous. Secondly to select a specific date the mouse user has to click on a variety of drop down controls and then the keyboard user must supply some other values. A date control should support either all keyboard or all mouse and preferably both.

Single Box Date Control
Examples: (seriously, I had several examples planned. Perhaps people learn. I know I do so it's entirely plausible. When I find a relevant example again I will so post.). Anyway you have all seen it. The 12 character input control with '/' for dividers!

This option is the equal fastest date control for keyboard users and not usable at all for mouse users. However if you have a number of text fields before this date control then having a keyboard only field, I feel, is OK. The user will already have two hands on the keyboard at this point and it is only a jump away from the date control.

If the user has to take their hands off the mouse just to use the date control then this option is not a good choice.

This option is not aesthetically pleasing unless there are similar looking input controls near by.

Triple Box Date Control
The other fastest date control. Depending on the look and feel of the user interface this option can be aesthetically pleasing. It can also be ugly [here]. This date control is functionally similar to the single box control, or a completed entry should skip the user to the next field. If your users can specify partial dates then this option beats a single box hands down. It provides the easiest way of allowing the user to select which aspect of the date they may wish to supply (month for instance) whilst still displaying that the other two fields are empty.

One caveat with the three box date control is that you will need to make it clear which box is for the month and which is for the day. US date controls tend to be month first while day first is common in countries like the UK and Australia.


Calendar
The most visually appealing date control, the calendar gives the user a date selection control akin to the calendar on their desk or on the wall in their garage. This is a good thing. Your average non-computer literate user can work a calendar with ease. Unless implemented correctly a calendar is also a nightmare for date selection within a few months or a few years.

This website (Dynarch) has a calendar control on the right hand side. It works fairly well, its an odd concept to work in even years on the right, odd years on the left. Personally I don't like it. To find 2012 I have to go to 2013 and then back a year. Too much work, I would rather scroll than have to click on one side of dialogue and then click on the other side to fine-tune my search.

Still kudos go to them, because the calendar control is trying. My only other criticism of Dynarch is the word "Today" is in the middle of the control, it implies that the current date selected is today, like it is on my physical desktop calendar. It doesn't mean that. It means go back to today. This threw me off. With anything there is a usability vs education issue, personally that text should give a short hand notation of today. Quicklinks should be included below the control with other concepts like "next week", "next month". Depending on your content (always, of course).


To make a calendar usable for larger date ranges the following features need to be supported:

• Click on the month to activate a dropdown control to select a month. The month should open on June/July so that there is minimal distance to move to the desired month.
  
• Click on the year should allow the user to control the year more easily. I see couple of different options implemented here.
• Up Arrow / Down Arrow – this is a bad idea. Your date control should already contain double arrows for going forward or back one year
• Enter a year, this is useful if the year is a long way away from the current year
• A year slide. Looks like a drop down menu with about 5-10 years visible above and below the current year. At the top and bottom are two buttons for scrolling. These should be on-mouse-over activate or click-and-hold activated.

Other usability requirements that are a must:

• Let the user know that if you click on the month your can select a different month. The same applies to the year. Users rely on your visual feedback to let them know what is wrong and what is right within the confines of their education. Step outside those bounds and you lose. I've done it, you've done it. Don't be ashamed, realise a mistake and move towards the user.
  

What isn’t good for calendars? Scroll bars are a bad idea. It is far too difficult to find a specific year using a scroll bar. On one application I tested each scroll click moved 50 years.

Here is an example of someone that is pretty darn close: http://www.basicdatepicker.com/
They're date control only misses the need for auto-scroll one year, and supply forward one year, back one year options.

Some Other Thoughts
Do you need a date control? Seriously. For the beta registration page for No Horizons we used an age attribute. We don't really care about the specifics of someones age as long we could gather their age. This is very valid for websites where someone must be 18 years or over? Seriously, making someone work a serious of dropdowns and input controls to state they're 18 is ridiculous. A simple "I am N years age" where N is a supplied value is just as effective. To memorise: understand your demographics.

Much like piracy "cautionary messages" the only people you hurt are the people who do the right thing. Pirates leave off such messages when duplicated films and people who enter your site underage, etc, are lying.

Conclusion
So what is the best date control? It really depends on the application environment, whether dates are optional, but generally you should try to provide both, the input box input as well as the calendar. A set of input boxes for the keyboard users, this is especially relevant if you have a number of input fields that the user can supply. For visual applications and especially web or mobile applications you should provide calendar functionality.

Bonus Content: Date Ranges
Asking the user to specify date ranges is a non-trivial task. Often I am expected to supply a start and an end date. This is fine if I know the specific range I am searching. If I don’t then it’s trial and error until I do. A better solution is to provide that functionality for users that do know the date range as well as functionality for those that think in terms that users are familiar with. "It was last week" or "I am pretty sure it was in January" are concepts the user understands. Hell, as a developer/tester it's a concept that I think in.

Being able to search one to four weeks ago, and then in terms of months or years is more ideal. Show me all emails sent between June and August last year. That’s closer to how users think and it’s a lot easier to do than, show me all emails from the 01/06/2007 till the 31/08/2008. It’s a subtle difference but one the users prefer.

How would you implement this? You can allow partial dates in your input boxes for keyboard users. Secondly, you can let people double click on the month header to default to the first of that month and then close the window. Furthermore, quick options, like “last week”, “this week”, “this month” are handy shortcuts that make life just a little bit easier.

Bloggerscript

Ok, I think the javascript in Blogger is a little inefficient. As I type into this dialog box my CPU usage cranks up to about 80-90%. According to procexp it's Firefox, which means Blogger. I'm not entirely sure what is going on in each keystroke but this is ridiculous. I'm waiting for each letter to appear on the screen. I'm not waiting long but it's making writing a post difficult.

Having a look at the source and there isn't much occurring. The "Save Now" being enabled on keydown but not much else. It could be a Firefox's Javascript processor. Firefox did update before I started the session but I wouldn't have thought it was that.

I am not working on my primary machine though, which maybe why I've never noticed this before. I am working on a machine that is just used for Continuous Integration and serving up SVN. So it's not powerful at all. I'll explain in my next post while I'm not using my primary machine.

This machine: 1.7Ghz Intel i386 with 1GB of RAM (DDR type1 probably)
Primary machine: Dual Core AMD 4200 64bit (32bit OS) with 2GB of 800mhz DDR2 RAM

Personally I think web-applications should be transparent and I realise I'm not the only one who thinks so. I'm hardly covering new ground. Web-applications are hard to develop properly (super-easy to do poorly... I know, I've written a few), you have a bunch of major platforms you need to support and you don't have the luxury of building a binary/distribution package to suite each one. I built www.icnh-games.com myself (well not entirely, I had a separate company do the style-sheet and layout, non-programmer-art, ftw) and I wrote Perl scripts to dynamically build the content from in-game xml-documents. However, it took us about two months after it was completed to iron out all the cross platform bugs (and I'm sure there are still some in there hiding... a testers job is rarely allowed to be done).

However, right from the start we stipulated with the company we contracted [Voodoo] that we needed to support the primary browsers (IE6, IE7, Firefox, Safari, Opera and there was another... don't feel offended if I left you out) as well as handling users that had Flash (inline vids) didn't have Flash (static images) and may or may not have Javascript (to support fancy menus as well as automatically starting the Flash movies rather than waiting for the user). Not to mention that multiple Flash versions that are out there. Still we got it all working in harmony. The more "features" you have enabled the better your experience is. The important thing is not to deny an experience simply because one is too lazy to support a user's application or operating system choice. We are here to provide applications for users and denying a user simply because of their operating system or browser choice seems a little bit too close to [racial|sexual|religious|*]-discrimination for my liking. Virtual discrimination is what it should be called. It makes it sounds like a social taboo and certainly no where near as cool as supporting Linux only cause everyone else is a n00b, or Apple or Microsoft. Also, it's not as funny as Apartheight.

I will post a blog (in a month or so once I've got all the bugs ironed out and can take comparative screenshots) that illustrates the multiple paths through the ICNH Games Framework. We support Windows (XP, Vista), Apple (10.4, 10.5 and I'm doing some checks as we speak to find out if we can support 10.3 as well... I knows it's old but I have a 10.3 box right here) and Linux (Ubuntu, FreeBSD, Fedora, OpenSUSE, MEPIS and PC Linux OS, potentially more but not tested). On top of that we provide distributions for i386, x86_64 (Intel or AMD), PowerPC 32 and 64 bit as well as there hardware features combinations of MMX, SSE, SSE2, SSE3.1 and SSE4 and 3DNOW. At the GPU level we have paths through our rendering engine that range from no-shaders, no-multitexture and no-VBOs to full-shader support, high dynamic range rendering with countless texture slots (my GPU supports 128 texture units apparently... I've never tested it) and batching algorithms to squeeze as much performance out of the machine as I know how to. I won't say as much as possible, as I know I'm not great at assembly, I'm only good at designing for performance and not getting down into the assembly level code and tweaking it further. One day a clever dev will come in and make it faster than it was before and I'll be happier.

All this being said the visual experience provided to low-end users (like my laptop with the awesome integrated graphics card) is not going to be mind-blowingly awesome, but for No Horizons and potentially other games, users will still be able to play the game. I'm will always play a game I like that looks bad over a game that looks awesome and is just a bit rubbish. That is pretty much our number point at ICNH Games: How many people can we get to play this game? Equal with it is: Is the game fun?

This was only possible because at the start we wrote down that we wanted to support all users, not just those running triple SLI. If you plan to support multiple environment configurations then you are going to get a lot closer to supporting them all then you are by tacking the support on at the end. Refactoring architectural solutions to support user XYZ is only going to make you resent them.

I'm not sure if Google's Blogger is designed to run on all browser configurations. I'm sure they have tested it, but have they tested it running a crappy old PC box? Moore's law has the speed of computers doubling every 18 months. This just means that the percentage of crappy computers is steadily increasing.



Before I go, I don't want to turn this into a gripe-blog but a few things have been bothering me of late and I never sleep much so that can't help. Is it that they've always bothered me and that starting my blog is just a way to vent existing frustrations or are all these recent occurrences of discontent purely anomalies in a generally happy and thoroughly enjoyable life?


This could be an interesting research topic; "Does starting a blog cause one to complain more frequently (or just more openly) than what they did before?". I'm sure than anonymity of the interwub certainly helps here. Perhaps it's the fact that blogging can be very cynical (not all of it is, but I've sure read a few cynical blogs in my time) and therefore bitching on a blog is more acceptable than bitching in person. It certainly allows one the escape of the social stigma associated with their gender. For instance the act of complaining in a male-oriented "traditional" Australian society is frequently met with responses like "dry your eyes Princess" and "harden the fuck up". This isn't all bad of course (fyi, nothing is ever all-bad or all-good) as Australian's tend to be good at putting up with the crap and getting on with the hard work.

I won't get into a discussion on Australian culture (which for the most part I love). For those who have already done the research or are doing it. Drop me a line, I find research topics fascinating.

Project Development Iterations

One of the things I like about where I work is the freedom different development teams have in trying new things with respect to work practices. We are currently starting version 1.5 of a project and one of the developers wanted to try a different way of structuring our iterations to minimise the issues we had in version 1.0 and to improve the overall quality of the project being developed.

The main issue we wanted to fix is developers getting too far ahead of testers - we had a two week iterative process where the developers would code for two weeks straight and then on day 10 they would provide a build to test. Then they would continue on as fast as they could.

This was a problem, they kept on getting further and further away from the testers because new code ranked higher in their eyes than old code did. Therefore some bug fixes took a long time to come, this hampered testing.

So one of the developers suggested a different iteration configuration. An iteration still lasts two weeks but there are five days for development of new code and five days for testing. The final day of development involves preparing the deployment for test. The final day of testing involves preparing the deployment for User Acceptance Testing.


Today was the first day of the first testing phase and so far so good. Defects were raised (not that many which impressed me for day one code) and fixes are already being prepared. Beyond that developers have realised they've made a mistake in one place and as they have the time, they are checking for similar problems in other areas. Proactive bug fixing, another plus.


Now, you may be wondering how complex code can be with five days of development including unit testing. Well for starters the number of developers double the testers but this is a small iteration task wise. Not all will be though so we are breaking our iteration tasks up into two groups. Single iteration tasks and double iteration tasks.

Every second iteration will see the deployment of more complex functionality that cannot be implemented in 5 days (effectively 15 days). As testers I am happy with this, we know these larger tasks are coming in advance and can plan for their arrival. We also still get five days of dedicated developer bug fixing after its delivery.

Both the development and testing teams are aware that the potential for the number of defects to still be greater than what the developers can fix in five days (especially if there are some doozies). To combat this (as what should have always be done), defects have priority one in the iteration following their discovery and as testers we're obliged to ensure that all new code gets at least a once-over to gauge the quality of the build.

Time will tell if policy this works, but at least we are working together to solve our past mistakes.