Dialog Design - Representation at the Interface

1. Dialog Design -Representation at the Interface Lecture #13 Gabriel Spitz

2. User Interface Design Process Activity Flow or Interaction Design Conceptual Design Dialog Design Visual Design Gabriel Spitz

3. Dialog Design • A Dialog is the means by which the UI enables a user to specify how a given task should be performed • During Dialog Design we translate the task flow into a dialog flow • A set of one or more windows required to perform the task • Thus Dialog Design focuses on implementing each UI task identified in the Activity Flow Gabriel Spitz

4. Dialog Design Objective • The objective of Dialog Design are: • To guide and manage the task flow • To adapt the task flow to the realities of the interface • E.g., Activity Flow for a Security Clearance application might ask the user to specify all the places a person ever worked at. This can be along list Work History ------------ A VS. B ------------ ------------ ------------ Work History 45-60 Work History 2-22 Work History 23-45 ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------ ------------ OK OK OK OK Gabriel Spitz

5. Representation • Representation is an important element of Dialog Design • It is concerned with the content of the dialog • If we imagine a dialog to be a sentence, than Representation are the individual words making up the sentence Gabriel Spitz

6. Behavior to Represent Commands VS. Options Gabriel Spitz

7. What is Representation (1) • Representation is the choices that a designer make in: • selecting control types • conceptualizing icons • specifying labels • composing instructions to support a function or an object at the interface Gabriel Spitz

8. Representation - Example Gabriel Spitz

9. What is Representation (2) • Representation is concerned primarily with the nature of the choice rather then its implementation • For example should a command to get out from a process be labeled ; Exit, Close, Finish, OK, OR MAYBE kill • Implementation of the selected choice will be discussed later when we talk about Presentation Gabriel Spitz

10. Representation - Example Gabriel Spitz

11. Representation - Example Gabriel Spitz

12. Representation - Examples • The controls in the previous examples were all: • Supporting a single task/function – date picking • They differed in terms of how the user had to specify a date • They also differed in terms of • The type and intensity of (cognitive) demands placed on the users • Speed of task performance • The likelihood of making an error Gabriel Spitz

13. Representation - Example What are the cognitive demands associated with each control? Gabriel Spitz

14. Impact of Representation • The choices a designer makes in selecting a control, specifying a label, or instruction at the interface can: • Impact task performance – e.g., speed, errors • Users’ workload – e.g. memory, calculation • Users’ satisfaction Gabriel Spitz

15. Effective Representation • A representation of an item that is: • Compatible with users characteristics • Suitable for a specific task and usability goals within a given context and culture • Compliant with published standards and guidelines • There is significant overlap among the above elements Gabriel Spitz

16. Effective Representations • Effective representations from a user perspectives are those that are: • Easy to remember • Easy to interpret • Easy to use Gabriel Spitz

17. Effective Commands • Easy to interpret For Example: VS. • For Slideshow in Power Point for the Mac Gabriel Spitz

18. Examples of Poor Representation Decisions Gabriel Spitz

19. Dynamic Menus • Objective is to reduce menu size and complexity • Often confuses users because menu items appear at different locations • OK in some circumstances, e.g. • lists, e.g., recently opened files • Adding menus when users move from one context to another Gabriel Spitz

20. Dynamic Menus Gabriel Spitz

21. Commands are only on Toolbar • Menu bars • Are organized hierarchically • Teach/communicate structure of application • Toolbars • Are for most common actions • Are not used by some users • Should be optional Gabriel Spitz

22. Duplicated Menu Items • Commands that are functionally the same and appear in more than one menu can impact usability • Even more problematic is when the same command has different names • E.G., Exit and Close • Such duplication can hinder performance and slow learning down • But OK while developing prototypes, to see where a command would best fit Gabriel Spitz

23. Confusing Primary and Secondary windows • Primary window: likely to remain open long time; never modal • Main application window must be a primary window. • Secondary window: usually temporary & often modal (blocking input to other windows) • Dialog boxes must not be minimizable nor have a menu bar. Gabriel Spitz

24. Primary/Secondary Window Same functionality using different types of window Gabriel Spitz

25. Confusing Checkboxes and Radio buttons • Radio buttons • 1 choice from N, • where N > 1 • usually, N  8; e.g., COM1, COM2, • Binary • {yes, no}, {true, false}, or {on, off} • Independent choices • e.g., (for text)Underline, Shadow, Emboss, etc., Gabriel Spitz

26. Checkboxes and Radio buttons (2) Some checkboxes should be radio buttons- e.g., Strikethrough & Double strikethrough Gabriel Spitz

27. Confusing Checkboxes and Radio buttons (3) Problem: sometimes independent choices aren’t quite independent Gabriel Spitz

28. Using a Checkbox for a Non-ON/OFF Setting For example: Don’t ask me again • Sometimes we use a single checkbox when there are only two choices, e.g., red vs. green, ascending vs. descending • Problem is that user has to infer the meaning of not checking the box • Contextual: what’s the difference between • yes/no • ascending/descending Gabriel Spitz

29. Using Command Buttons as Toggles • “command button” = “pushbutton” and should invoke some action • If label doesn’t change, then user confused as to what action to expect • However, if label does change, then does it describe • current state or • what will happen if pressed • e.g., does “Stop” describe current situation or what will happen if button pressed? Gabriel Spitz

30. Using Command Buttons as Toggles Gabriel Spitz

31. Abuse of Text Fields • Do not use text fields for read-only data • Confuses user • is it text to be altered? • temporarily grayed out? • or always read-only? • Use a label field instead • Using plain text field for formatted input Gabriel Spitz

32. Abuse of Text Fields We suggest no specific format, but expect one Gabriel Spitz

33. Abuse of Text Fields • Use multiple fields • Instead of (415) 555-1221 as one field, enter it as three. • For time, use hours, minutes, seconds, and AM/PM if 12-hour format (but only as many as appropriate). • Better: • Free-format fields • Intelligent programming to figure out the data, no matter how it was entered. • E.g., Microsoft Outlook’s handling of phone fields. Gabriel Spitz

34. Abuse of Dropped Down List Boxes Over compensation that borders on user abuse Gabriel Spitz

35. Mixing Control and Content Buttons • Dialog box control buttons are, e.g., OK, Apply, Close, Cancel, Help Relate to the activity associated with the dialog box • Content control buttons are, e.g., Add, Delete, Set, … Relate to the content of the dialog box Gabriel Spitz

36. Mixing Control and Content Buttons Gabriel Spitz

37. Mixing Control and Content Buttons • Clear mapping of buttons’ effects • Separate area for window control buttons Gabriel Spitz

38. Misusing Group Boxes • Variations • Group box around one setting • Group box within group box • Only one group box within window Gabriel Spitz

39. Misusing Group Boxes Gabriel Spitz