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 |
