|
Commuters and other central London road users attempting to pay the congestion charge on the Web are likely to be in for a confusing and frustrating time. With less than seven days to go attempting to register on the site www.cclondon.com seems virtually impossible as response times currently stretch into minutes.
Web service providers are usually very aware that response times exceeding several seconds are likely to deter customers, anyone attempting to use the service now to pay in advance is likely to face a long wait.
Whilst evaluating the site it was never possible to actually pay the charge for the first day of operation as the server was continually unavailable. This is not the National Lottery where people will be gladly queuing up to donate money to the government, but a charge which is likely to be resented and so any faults in the system magnified in the user experience.
Users will also have to have a degree of visual acuity far greater than that required to drive a vehicle. Like many other Web sites the designers of the pages have decided that all its users are capable of and comfortable with reading sub-ten point text. Whereas this might be acceptable for a commercial site, where the user can choose not to continue the transaction, it does seem unacceptable for what is effectively to some an essential service. Having to choose between squinting at a screen in order to meet the deadline, or possibly have to pay a penalty charge, does not seem conducive to healthy eyes.
Two essential pieces of information have to be supplied on the congestion charge form, the vehicle registration number and the date which payment is being made for. Although UK registration numbers strictly follow a number of defined patterns, no attempt seems to have been made to determine if the pattern has been followed. However as non-UK registered vehicles will be allowed to pay the charge this does not seem a point of particular note.
It is on the date entry mechanism where good Web design practice has not been followed. The overwhelming majority of websites clearly indicate the month field by using a drop-down list of month names; the congestion charge form has chosen to use the inherently confusing month number technique. So the entry 08/03 might be the eighth day of the third month, or it might just be the third day of the eighth month. The use of a drop-down menu would obviate this potential confusion whilst the provision of guidance in the form dd/mm/yyyy would alleviate it.
In attempting to complete the form further difficulties and inconsistencies were found. An interactive calendar is made available at the press of a button. The majority of Web sites would post the calendar in a floating window, the congestion charge site shows it as a part of the main interface. This makes effective use of a part of the screen that is otherwise not used at all for any other purpose. This does lead to the question of making the calendar permanently available in this otherwise unused area, or even removing the three text fields and relying solely upon it for date selection.
Within the calendar some days are not selectable: any day in the past, weekends and bank holidays. Conventionally these would be shown greyed out to indicate that they cannot be selected. Confusingly on this calendar a range of different colour schemes are used for different categories of unavailable days. The major cue that a particular day can be selected is that cursor changes from an arrow to a pointing finger and the date is underlined, but mostly obscured by the cursor, as it traverses it.
Selecting a data on the calendar causes it to be posted into the text input mechanism. This could be accomplished without any need to communicate with the server, providing an immediate confirmation. The design implemented requires communication with the server, which is currently and can be predicted at peak times to be, unacceptably slow.
Returning to entering the date information from the keyboard, on occasion entering '2' for the month number resulted in a request to enter '02', whilst on later tests entering '8' was accepted. A fairly standard and obvious test, entering the date 29/02/2003, produced the less than helpful error message ' Invalid Date - Enter Date as dd/mm/yyyy'. Whilst correcting this 'error' the message remained continually visible leading to the situation where a valid date was displayed accompanied by a message stating that it was invalid.
Most messages from the system to the user are displayed in small red text against a blue grey background at the lower left of the interface. This is hardly the most noticeable place or format for them and when new users were observed attempting to operate the system many failed to notice them. To confound this problem further, on occasion developer diagnostic messages 'Session variable INTERACTION not found' appeared.
This part of the form was labelled 'Step 1 of 2'. It was not possible to evaluate the communication that ensued in step 2 as, over a period of five days, the server was continually reported as unavailable.
In summary:
1. Soak and capacity testing of a system should be completed in good time before it goes live. Less than 1 week before congestion charging starts, when the system could be considered live, response times are unacceptable.
2. Respect the users customisation of their environment. The browser preferences for text size are ignored by the system.
3. Prevent obvious errors from happening. The use of a pull down menu would reduce date/month confusion.
4. Make effective use of screen space. Having the calendar permanently displayed would make use of space that is not used for anything else and provide an alternative, less confusing and more natural input mechanism.
5. Indicate input formats clearly. The provision of a 'dd/mm/yyyy' indicator on the form would reduce the probability of input errors.
6. Provide clear and consistent feedback. Error messages offset from the center of attention in small font and low contrast colours are likely to be missed. Error messages are for the benefit of users not developers, so diagnostic errors should be removed.
7. Provide clear and consistent feedback. The use of a dialog to communicate with the user in some circumstances and an on-screen message in others makes it even more likely that the on-screen messages will not be attended to.
8. Error messages should indicate the cause and/or the cure for the error. Although 29/02/2003 is an 'Invalid date' explaining why would be a little more helpful.
9. Maintain consistency on the interface. Removing an error message from the interface once the user has attended to it prevents a possible visible contradiction.
10. Respect established conventions. The greying out of a component to indicate its unavailability is a widely accepted convention. The use of an underline to indicate active status is appropriate for a hyperlink but should always be visible, not transiently visible and partly obscured when the cursor passes over it.
11. Less is more. The use of a number of different colour schemes on the calendar to indicate different reasons for unavailability is confusing and unnecessary.
12. Provide timely feedback. The server round trip required by the calendar could and should be removed to provide faster user confirmation.
13. Selection is better than input. As the interface has sufficient space for the calendar component it could be used exclusively to select the required date.
Return to newsletter
|
