From Task Analysis to GUI Application Design

1. From Task Analysis to GUI Application Design Ilka Antcheva, Bertrand Bellenot, René Brun, Fons Rademakers CERN, Geneva, Switzerland

2. User Goals, Tasks and Actions Task-Analysis Approach Hierarchical Task Analysis Use-Case Analysis GUI Priorities GUI Paradox of Complexity Three-Click Rule Summary… or How to Manage GUI Complexity Overview

3. User Goals, Tasks and Actions (1) • GUI objects – pass information between users and the application (widgets & interaction devices). • User actions – initiated by operations on GUI objects. • Tasks – a sequence of discrete actions to achieve a goal. • Goals - expected results when using the application.

4. User Goals, Tasks and Actions (2) An ideal automated application has a single button operation. However, users may want to: • Have a choice from several configurations • Modify some parameters • Monitor the process • Specify different options based on the generated data before generating results  As a result, more GUI objects must be added to enable a wider range of flexibility.

5. Task-Analysis Approach • Purpose of Task-Analysis – to map user requirements and to logically organize and distribute the GUI widgets across the application. • The challenge is to determine how far to go - there is a potential to miss important objects and actions if there is a lack of detail in the analysis. On the other hand the GUI will be unnecessarily complicated, if the analysis is taken too far. • Hierarchical Task Analysis (HTA) – uses a top-down approach to divide application goals into tasks, actions and GUI elements. • Use-case analysis – focuses on the limited number of tasks in the described scenarios. Each scenario consists of a number of steps, and has well defined start and an end points.

6. Hierarchical Task Analysis (1) • Start with a list of tasks. • Group the tasks and label the groups by functionality: • Each task must be included in at least one of the groups. • A task may also be common to several groups. • Group composition may change. • Tasks may be regrouped when it is appropriate. • Organize tasks within each group in a hierarchical relationship. • Define the places where to present a set of options or parameters (opening mechanism). • Continue the decomposition up to the level so that all opening mechanisms within the GUI hierarchy are clearly defined

7. Hierarchical Task Analysis (2) • Goal: fit selected data points. • Task list: 1 - select a function 2 - select a method 3 - select fit options 4 - set the range 5 - perform the fit • Organize tasks within each group in hierarchical relationships. • Define places for triggering the opening mechanisms.    Opening Mechanism  

8. Use-Case Analysis • Divides a goal in a number of scenarios. • Each scenario presents one complete operation performed by the user. Example: logging into the system by providing a user name and password. • All steps in a scenario are arranged as a sequence of actions. • A scenario can contain decision points, which introduce complexity. A decision point has two alternative sequences and can be presented as a question requiring a Yes or No answer. • In a description of the scenario all nouns are potential GUI elements.

9. GUI Priorities • In complex interfaces most frequently accessed items are presented on the main panel (one single click away). • GUI objects are related by functionality; located on single panels. • Organization of the GUI objects depends on the different user classes (novices, advanced beginners, competent performers, experts) : • Universally useful items for all user classes are included on the main panel. • Remaining tasks are mapped to class-specific sub-panels. • A single panel may serve the needs of two or more user classes. • Suitable GUI metaphors in use. • Critical items and tasks should provide back-out mechanisms and error indicators.

10. GUI Paradox of Complexity • Easy-to-Learn & Easy-to-Use applications require a limited number of widgets and parameters… flexibility is sacrificed. • Progressive disclosure – a method for finding an appropriate GUI design solution in-between the complete automation and the total user freedom. • 2D structures present the GUI panel hierarchy: Narrow or Wide (on X), Shallow or Deep (on Y). Single GUI panel

11. Three-Click Rule • Every destination should be at most three levels deep, or three mouse clicks from the starting point. • The reason – limitations of short term memory (the memory of just presented) that only handles between 5-7 items. It can be easily replaced by any new information (Miller’s law of 7). • If your application requires 6 mouse clicks, very likely the starting point will be forgotten before the user reaches the intended options or parameters - better think of reducing the depth of the hierarchy by re-organization. • The three-click rule is a difficult target to reach for large applications, but it is a lofty goal.

12. Summary (1) …or How to manage GUI complexity? • Menus – allow a large number of items to be accessible from a single list; decrease the depth levels of the GUI hierarchy. • Tool bar – contains buttons for the most frequently used commands. Buttons use pictures and icons that eliminate the need of additional labels. • Tab widgets – allow several panels to co-exist in a single frame. • Allow users to customize the GUI by: • Personalizing the application menus • Configuring tools that allow/skip options • Changing default settings (of actions, options, parameters, etc.)

13.  Summary (2) • Reduce number of GUI elements on each panel. • Hide some GUI elements and show them only when necessary (1). • Present large amounts of information more efficiently by: • Grouping elements (2) • Removing unnecessary labels (3) • Having tool tip text where possible (4) • Using pictures and icons to eliminate the need of labels (5)    