-All delays in the system longer than .5 seconds will produce a dialog box that says "Please wait.

" -It is possible to reach any given system function from the main window in less than 3 clicks. -It is possible to accomplish any given task with just the keyboard, without the mouse. -All buttons in the system will adhere to established button convention (link to established button convention regarding size, naming, position, etc.) -All screens will have a help button. Each help button on a given screen must provide at least one 'topic' for each control on the screen.

The GUIDE Methodology - Define Style Guide

Objectives
o

To define a standard style for the user interface in an application style guide, so that users perceive a uniform look and feel. (Look refers to appearance, feel refers to interactive behaviour.) To select a style which enhances usability by being appropriate to the users and their tasks.

Inputs The corporate style guide

If one exists.

Environment style guides

Commercially available environment style guides, e.g., for Microsoft Windows, OSF Motif or Apple Macintosh.

Usability requirements Subsidiary inputs

External standards or regulations such as ISO 9241, EEC 90/270. Relevant literature such as user interface guidelines (e.g., Shneidermans Eight Golden Rules) or books. Known constraints of the target and development environment, and tools.

Products Application style guide

Contains

References to any environment style guide or corporate style guide on which it may be based. Design principles. Standards for window interaction Standard window layouts, showing examples. A window hierarchy diagram, showing how standard windows are related to each other, using the object specialization notation Standards for the naming, appearance, sequence and behaviour of menus and push buttons. Standards for the use of keyboard keys. Standards for the use of graphics, tables and diagrams on screen. Standards for the use of window controls, and the mapping of data types to window controls. Standard names, symbols and formats. Standards for the use of colour, type, fonts, etc. Standards for how common user object actions are supported. Standards for integration of applications or objects. (E.g., cut and paste etc.) A conformance checklist for critical areas of the standard.

Quality criteria

Is the application style guide usable by developers in the sense of; being well structured; being unambiguous; being small enough to work with; containing concrete examples?

Is the application style guide appropriate for the users and their tasks? Is the application style guide relevant to and technically feasible in the target environment? Has the application style guide been formally agreed with users and developers as a mandatory standard?

Process
Identify basis for style guide

Corporate style guide Environment style guide, containing; Design principles Standard controls available in the environment Standard menu headings Standard window actions (e.g., Copy, Save, Delete) showing how the dialogue is managed. Standard highlighting and selection rules. National or International regulations or standards. EEC 90/270, ISO 9241 Software ergonomic requirements of EEC 90/270 1. Software must be suitable for the task, allowing users to complete tasks efficiently without presenting unnecessary problems or obstacles. 2. Easy to use. The software should be easy to learn, intuitive, and appropriate to the users ability. 3. The systems speed of response to commands and instructions should be immediately shown on screen, and should be appropriate to the task and the workers abilities. 4. Adaptable to operators skill level. Experienced users should be able to adapt the interface to suit their particular ability level and preferences. 5. The software should prevent users from making errors and allow error recovery. 6. No quantitative or qualitative testing, such as measuring output speed, should be carried out without the operator being informed that such testing is taking place. 7. Systems must give VDU workers feedback on their performance. Such feedback should be in an appropriate style and format, and should not contain unnecessary information. Help facilities should be provided.

Consider style implications of users and usability requirements

Review style of similar applications Define window hierarchy Define other detailed standards

Restrict controls to be used Define new or specialized controls Colour and font Map data types to controls

Validate style guide

Acceptability to users User reviews discussion of examples prototyping of some standard layouts and interactions.

Conformance to regulations, standards and environment style guides. Acceptability to designers and developers. Technical feasible in the target environment. Review by outside expert.

Organize support and enforcement

Integrate into the technical environment Incorporate it into staff roles and procedures

Extend and evolve style guide

Recognition of common controls or patterns of interaction. Documentation of major GUI design decisions. Resolution of inconsistencies.

The GUIDE Methodology - Design GUI

Objectives
o

To design the appearance and user visible behaviour of the graphical user interface.

Inputs
There are two main contexts for GUI design, initial design and redesign (after prototyping and evaluation). Initial Design Tasks and scenarios User object model Application style guide Redesign Prototype feedback Evaluation results

Products GUI design

Consist of a set of windows, which comprise the interface. Each window contains a set of controls, through which the user communicates with the system, and a set of window actions.

Windows
A communication channel through which the user looks to see and interact with objects in the system.

Windows will have a number of common features, as determined by the style guide.

Process
1. Define views of user objects
A view of an object consists of a set of its attribute values, together with actions for modifying them.

Initially, this is defined abstractly (perhaps as a list of attributes and actions). Subsequently, particular controls and layout may become associated with a view. Multiple views may be necessary if; There is too much information to display on one screen. Some information or actions are used infrequently. A supplementary view may accommodate this. A user object is used in different contexts or for different tasks. Particular graphical visualizations may assist the user in interpreting or manipulating the object metaphors. But these should be used with utmost caution. See The Myth of Metaphor by Alan Cooper. Different tasks involve different types of use. (E.g., data retrieval vs. inputting data.) Some attributes of a particular object is restricted to particular users.

2. Define windows
2.1. Allocate views to windows. Each object assigned to a pane. Identify which objects must be viewed together. Identify the main windows required. 2.2. Select controls to represent attributes. As defined in the style guide - but also at this point the style guide may be created or amended to record the design decisions taken.

Prevent the user entering erroneous values. (Shnidenrman)

Where a discrete set of values possible for an attribute, present only those values. (Drop down list, option buttons, etc.) If a specific format is required, enforce the format by restricting input, or validate the data (as soon as possible). If a displayed value is unchangeable, the control should indicate this. When a particular attribute is not valid, disable its control but allow the user to find out why it is disabled.

Sketch how the controls will be laid out. 2.3. Define window actions. Windows will already have inherited actions from the window hierarchy.

Ensure that there are sufficient window actions to enable all activities to be performed.

Add redundancy in allowing actions to be performed, both in explicit ways, and intuitive ones. Invalid actions should be disabled but if it is decided that they are still visible, should it should be possible to find out why.
2.4. Define dependencies between windows. This involves defining child that are accessed only through another, parent, window. Used where the child window is used to view an object with is part of the object contained in the parent window.

Consider if changes are made in one window, should it be reflected in other open windows. There is an overhead in doing this.
2.5. Define window instances. Should the user be able to have more than one instance open at a time? If so, how many?

Should the window be modal?

3. Express task scenarios as window actions

Guide recommends that this is performed interactively with the user.

Task scenarios are walked through the initial windows. Windows and window actions are revised as necessary so that each scenario is natural and convenient to express.
3.4. Define window navigation 3.4.1. Navigation of object relationships For each related object (from user object model) consider its usage to assess whether the user:

needs to navigate from the current object to the related object. needs to navigate from the related object to the current object. needs to navigate explicitly in both directions.

does not require direct navigation.

3.4.2. Moving between views of a single object Where there are multiple views of a single object, this is typically effected by a View menu, but other possibilities exist.

Minimize the number of views required for a single task.

3.5. Object action to window action Ensure that each user object action can be achieved by window actions. (Sometimes multiple, and sometimes single.) 3.6. Define modal dialogues Windows in which the user is trapped until the window is closed. Beware of restricting the user's control!

The GUIDE Methodology - Prototype GUI

Objectives
o o

To investigate, and improve, the usability of the proposed GUI design. To provide feedback on the validity of the task model, user object model and style guide.

Inputs
A proposed GUI design A set of task scenarios (to be used as the basis of the investigation) Usability requirements Prototype GUI

Products

Working GUI prototype

Types of prototype

Scope: Global or local Horizontal / vertical Evolutionary /throwaway Fidelity (or realism)

Suggested GUI design changes Feedback within this iteration

Feedback on the task model, user object model and style guide Model user objects: User does not recognize objects or relationships. Model user tasks: Additional task scenarios identified.

Prototype GUI

Process
Define prototype objectives
Examples may be:

To validate the style guide. To reach agreement on the GUI support for a particular task. To explore the appearance and behaviour of a single complex window. To satisfy a specific usability requirement, such as making some part of the interface sufficiently simple that it requires no user training.

Choose the prototype tool

Throwaway prototyping examples;

Paper prototyping - for an argument in favour of this as the main prototyping tool, and suggestions for using it see Prototyping for Tiny Fingers by Marc Rettig (Communications of the ACM April 1994/Vol.37, No.4. downloadable as a PDF file from within the University only). Presentation package (E.g., Microsoft Powerpoint) Application building 4GL (E.g., Microsoft Access) Specialized package (E.g., HyperCard or Microsoft Visual Basic)

Evolutionary prototyping requirements;

The ability to construct production-quality systems. Flexibility to allow tuning the prototype to user requirements. Support for fast turn-around of code changes.

Tool characteristics issues;

Type of interface Integration with other tools Production platform Vendor stability

Build the prototype

Keep the development team small. Include someone with tool expertise.

Investigate the prototype

Walk through task scenarios with the designer. Role-play interactions.