When you use an interface it’s the little things that help make it either a pain or just outstanding.
Sadly, too often we have to put up with the bad interfaces.
In light of this I will from time to time be producing a few articles focusing on specifics of bad interface design and implementation practices.
First one off the ranks is date fields and calendar pickers.
This interface element never really seems to work the way you want it to. Making the overall experience very frustrating.
To often you will see the required format for a date field indicated (dd/mm/yyyy).
Now this is good in that you now know which way to put the day and the month, but that’s about it.
What if you want to put in a date as – 1/5/11 or maybe 1.05.11 or 1-12-2011.
All of these are valid notations for a date. But for a poorly designed website they produce an error message.
How easy would it be for a developer to just allow for these other formats.
Or better yet allow for a freeform written date as well like – 1st May 2011, Nov 2 2011, or 21 December 2011.
Again a little more work on the programming side of things, but the ease of use would be outstanding.
Restricting the Input
If you really must restrict the input then take a look at the airline industry. They will often use select lists of the possible dates, this makes it easy to pick the date from the list without any confusion, still not as fast as typing in the date however.
Forced use of a Calendar Picker
Now I can understand that calendar pickers are great idea when you aren’t sure of the date in a relational sense.
However there is nothing worse than being forced to use a calendar picker to fill in a field, especially when you know how to type in the date, you even know the date in question.
Yet it’s assumed you need assistance to find the date. This is like escorting an able bodied person across the road.
It’s a very bad idea to treat your customer as idiots.
Activation Buttons for Calendar Pickers
The way we active a calendar picker needs to be obvious. However too often the way they are designed is with no consideration for the general community.
The activation buttons can be way too small, obscure or just make us unsure what they do. As is the case in the calendar picker from the Public Sector Commission.
Launch Window for Calendar Pickers
It’s very important a calendar picker is launched nearby to the date field it will populate.
From an accessibility view point it is extremely critical a new window is NOT launched for a calendar picker. As this will disorientate the screen reader or maybe invisible (off screen) for a screen enlargers.
However it seems time and time again we are seeing calendar pickers launch in new windows, often over on the other side of our screens. Often to get lost below the windows we have open.
In this modern age of web development why can’t a modal box just appear within a page in the right place.
Clear Large Buttons on Calendar Picker
When you use a calendar picker you want it to be very clear what those arrows on the picker are for. Do they move the month back and forwards a month, year or a quarter. If there are multiple buttons what do they all do. The intent of the buttons needs to be very clear.
Never assume for example that you know the two arrows together means back/forwards a year .
Still even if you a have the buttons labeled well, you need to ensure they aren’t too small to use. Sure the 20somethings building the site might be able to use them, but can the site’s audience.
Use of larger buttons and dates on the calendars would make it easier for the ageing members of the community to use the calendar picker too. The example below is just a little too small.
Any calendar picker should follow the business logic of the application or form it’s supporting.
For example if you are dealing with a reporting function you generally don’t need to be able to navigate future dates. If there is a restriction to 60 days in the past, then this needs to be implemented into the calendar picker as well.
A little smart logic can go an long way. For example of you are using a start and end date, once the start date has been picked, restrict the end date to being after the start date.
Yes all this seems logical, pity it’s not being done.
The Key to it All
To often people are being forced into series of rules or procedures that just go against the way they normally think and operate.
This should not be happening. We aren’t operating in the age of 3270 green screen terminals and mainframes. The interface should not be restricted.
The reason for all these problems are happening comes down to:
- Lack of any interaction design at the beginning of the design process.
- Lack of thinking through the way real people are going to use the system.
- Lack of real users (not developers) testing a system.
- Lazy development, taking the quick easy way to build an interface.
- Designing and building for easy development, not easy use.
So next time you are implementing or designing a calendar picker or date fields, take a moment and think about how people will use it, not the way you want it to be used.