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)    