Emergency system prototype and Heuristic Evaluation of E-mail prototype

The emergency services system prototype can be found here or at http://woolfben.uwcs.co.uk/prototype/interface.html if that doesn't work.

According to my research, older people generally get on well with:

Single screens - no scrollbars.
Simple language - no technical terms.
Big, easily selected icons/links - preferably distinguishable by shape and colour as well as by label.
Static menus - no moving objects or drop down lists.
Concise and obvious labels - preferably including a verb to signify the relevant task being performed.

Points to take into account are:

Failing eyesight/colour blindness
Impaired mobility
Reduced attention span

To this end, the prototype given has simple screens, with no scrolling whatsoever. Buttons are clearly labelled with explicit actions on the menu, and clear choices in the submenu. Simple language is used in large, readable font, in colours chosen to contrast strongly to the background image of the relevant button. Buttons are distinguishable by labels, shape/size, and colour, to prevent colour blindness or failing eyesight from hampering usage of the product. All objects are static and clickable, to prevent confusion and for ease of use. Buttons are also well spaced and large enough to be selected without a need for high accuracy.

Further, an heuristic evaluation of the E-mail prototype (found here or at http://woolfben.uwcs.co.uk/HCI%20Prototype.ppt follows:

Visibility of System Status

The e-mail menu satisfies this heuristic, as each page of the prototype informs the user of the current status and options available to them.


Match between system and the real world.

The e-mail menu matched the real world well, using non-technical termoniology where possible, and no system specific language whatsoever.


User control and freedom

The menus all contained a Back button to cancel the current operation, as well as a backspace on the typewriter keyboard to allow undo functionality.


Consistency and standards

The prototype was generally consistent with itself, however in some cases buttons (notably the Back and OK buttons) changed location on different pages, which should be fixed in the final design.


Error prevention

Use of the delete function came up with a confirmation dialog, as expected. Other functions did not require or provide any confirmation, as the impact of errors would be negligible compared with the decrease in usability.


Recognition rather than recall

The prototype satisfies this heuristic well, as the design clearly shows each stage of sending an e-mail, and allows fields to be completed in any order.


Flexibility and efficiency of use

The e-mail system allows storage of favourite contacts, providing easy access to frequently used addresses. Beyond this, little flexibility is provided except possibly through the Advanced options.


Aesthetic and minimalist design

The design is largely kept minimalistic, with only the basic options provided by the system. Further customisation is available through the Advanced options dialog, which is likely to confuse novice users and probably should not be made accessible in general.


Help users recognise, diagnose and recover from errors

Mistyped information is easily dealt with by use of the Backspace or Delete keys on the keyboard interface. However, incorrectly entered e-mail addresses pose a problem, as the prototype does not show an error message to respresent this. A system to check the validity of the e-mail address on sending, and pop up a simple error dialog if it is invalid, would be a good solution to this issue.


Help and documentation

No help or documentation was provided or required by this prototype, as all functions were easily explained by the onscreen prompts on each function button.