Dialogue Notations and Design

Transcription

1 Dialogue Notations and Design Learning Objectives State the two main classes of dialogue notations Explain why we need dialogue notations For the different types of diagrammatic dialogue notation within these classes explain how they represent dialogue using simple examples Describe dialogue properties that enable analysis to find potential usability problems 1

2 What is a dialogue? In the context of user interface design, dialogue signifies the structure of the conversation between the user and the computer system Why do we want to analyse the dialogue? Lots of reasons, including identification of: Difficult to reverse actions Missing items (things that simply can t be achieved) HCI dialogue is scripted, ordered and structured. Why not just analyse the program? Print our current interest rate is 10% Print What is your annual salary? Input salary Max_loan = 3 * salary Print How much do you want to borrow?. Because: a program has dialogue mixed up with other elements (e.g. computation); a program often has lots of low-level dialogue-related code (e.g. checking syntax of input); program understanding is an interesting area of research, but there s a lot left to do!! 2

3 Dialogue Notations Notations are formal ways of representing the dialoguestructure of the conversation. Why we need separate dialogue notations? Explore, evaluate design options, Discover if flow of events and structure of conversation is logical or too involved or complex. If user has to traverse through too many system sates. Separation of the interface elements of the program from the actual calculations (semantics). Writing down the dialogue before a program is written -- allow the programmer to analyse the structure and use a prototyping tool. Hence, dialogue notation forms part of the overall prototyping methodology. Classes of Dialogue Notation Diagrammatic State Transition Networks (STNs) Hierarchical STNs Flow Charts Jackson Structured Design (JSD) Petri Nets State Charts Textual Grammars Production Rules Event/Process Algebras 3

4 State Transition Networks (STN) circles states arcs - actions/events/response from system Start ToolBar Select ellipse' highlight ellipse' click on click on centre circumference Ellipse 1 Ellipse 2 Finish rubber band draw ellipse select polygon' highlight polygon ' click on first point double click Poly 1 Poly 2 Finish rubber band draw last line click on point draw a line State Transition Networks Events arc labels a bit cramped because notation is `state heavy the events require most detail Start ToolBar Select ellipse' highlight ellipse' select polygon' highlight polygon ' click on click on centre circumference Ellipse 1 Ellipse 2 Finish rubber band draw ellipse click on first point double click Poly 1 Poly 2 Finish rubber band draw last line click on point draw a line 4

5 State Transition Networks States labels in circles a bit uninformative states are hard to name but easier to visualise Start ToolBar Select ellipse' highlight ellipse' select polygon' highlight polygon ' click on click on centre circumference Ellipse 1 Ellipse 2 Finish rubber band draw ellipse click on first point double click Poly 1 Poly 2 Finish rubber band draw last line click on point draw a line STNs can represent a sequence of user actions and system responses user choice and iterations. Can t represent dialogues with several concurrent parts. STN for a full system would be big- to manage complexity use Hierarchical STNs 5

6 Hierarchical STNs managing complex dialogue named sub-dialogue Main Menu select graphics pop-up graphics submenu select text pop-up text submenu Graphics submenu Text submenu select paint pop-up paint submenu Paint submenu Concurrent dialogue Consider a simple dialogue Box Text Style example underline 6

7 Concurrent dialogue Three toggles- individual STNS NO click on NO click on NO u line click on underline u line underline Same user action in both directions Concurrent dialogues and combined Text Style NO style click on only example underline click on click on only click on 7

8 NO style Concurrent dialogues all together- combinatorial explosion underline u line only only underline u line example Text Style underline only underline underline u line u line Escapes and help Esc: wherever you are in dialogue, cancels and returns to main menu. Requires an arc from every state back to main menu Main Menu select graphics pop-up graphics submenu select text pop-up text submenu Graphics submenu Text submenu ESC Normal Finish select paint pop-up paint submenu Paint submenu 8

9 Help Invoked at any point in the dialogue Ellipse 1 click on centre rubber band Ellipse 2 click on circumference draw ellipse Finish Help submenu Help submenu Strengths and Limitations Strengths Easy to interpret Allows choice and iteration to be modelled. Limitations Concurrent dialogue Unusual actions (esc, help) 9

10 State Charts Harel s state charts are a form of STN, to address problems. Hierarchy is used within a single diagram to show alternative and concurrent states. A television control panel. Problem The controller has five buttons on, off, mute, sel and reset The TV is either ON or in STANDBY mode When On, user can control the sound with the Mute button and the channel with the Sel Button. 10

11 State chart for TV example Two subdialogues: Sound Channel Standby Black blob is start node (default state) H represents history. TV_on ON Sound OFF RESET AND Channel The reset ARC overrides the default. (access specific states) On Off MUTE SEL SEL SEL SEL H State Charts Includes Composite states Default start states (the filled blobs ) History states (the filled blobs labelled H ) Advantages Can capture notion that a state in reality comprises a set of independent states Allows escape right out of all states stored within a composite state Captures memory of individual states when exiting and re-entering a composite state 11

12 Flowcharts Delete Please enter employee no.: D1 Familiar to programmers C1 read record Boxes Delete D2 Delete D3 Process/event Not state Name: Alan Dix Dept: Computing delete? (Y/N): _ Name: Alan Dix Dept: Computing delete? (Y/N): _ Please enter Y or N Use for dialogue (not internal algorithm) Y C2 answer? N C3 delete record other Finish Finish Uses of dialogue Analysis and Design In prototyping stages use with L/F prototypes. A screen for each state Consult STN to check for the next screen Possible ways of analysing a dialogue to identify potential usability problems in, User actions: whether adequately specified and consistent dialogue states 12

13 Action Properties (1) Completeness: Only a subset of the full set of actions are allowed for any state. But what about other (random) actions, not shown on the diagram? Need to know the consequences of all actions under any event and account for them. For each state/action pair, the designer ought to decide what the behaviour will be. Action Properties (2) Non-determinism: Some states may have several arcs labelled with the same action.. Notdeterministic for action. E.g. two levels of Esc., or actions may be dependent on guard conditions Both non-determinism and completeness may be automatically checked. 13

14 Action Properties (3) Consistency: We expect the same action in different circumstances to do the same thing, e.g. (tab key) Difficult to automatically check consistency as it involves semantics (similar actions do similar things?) State Properties Reachability States must be reachable (easily). Check if the dialogue is fully connected. For any two states, there is a sequence of action which takes the user from one to the other. Can be automated Reversability (Not true undo): Any fully reachable dialogue will be able to reverse actions, but it may not be easy to do so. Analyse reversability by calculating the cost (number of arcs that must be traversed to get back) 14

15 Dangerous States word processor: two modes and exit F1 - changes mode F2 - exit (and save) Esc - no mode change Esc edit F1 menu F2 exit but... Esc resets autosave Dangerous States (ii) exit with/without save dangerous states duplicate states - semantic distinction edit F1 menu F2 exit any update Esc edit F1 menu F2 exit F1-F2 - exit with save F1-Esc-F2 - exit with no save Esc 15

16 layout matters word processor - dangerous states edit F1 menu F2 exit any update Esc old keyboard - OK edit F1 menu F2 exit Esc 1 Esc F1 F2 tab F3... F4... new keyboard layout layout matters Esc F1 F2 F3... intend F1-F2 (save) edit F1 menu F2 exit finger catches Esc any update Esc F1-Esc-F2 - disaster! edit F1 menu F2 exit Esc 16

17 Dangerous states Some states must be made difficult to reach (disk format!) Dangerous states can t be determined automatically- depends on system semantics and designer s judgement The move to dangerous states must be different from other sequences (not-consistent!) References Background reading Dix, Chapter 8, (chapter 16 new edition) Further reading Shneiderman, Chapter 14 17