1. CS 422: UI Design and Programming
More on Safety

2. Next up GR5 is due on April 23. AS2 and RS2 are due on April 23.
You are required to describe the feedback you got in your project discussion sessions, and how you incorporated it into your project.
Students/groups who did not attend the project discussion on Apr 9 will be penalized.
AS2 and RS2 are due on April 23.
Final project presentations: April 23 to April 30.
We will discuss details about the final exam during review, on 5/2.

3. Final project presentations: Overview
Apr 23, Apr 25, and Apr groups per day. Schedule is up on the course page.
All group members MUST be present on the date of their presentation.
Designate 2 or 3 members of your group for the presentation.
DO NOT divide the presentation among all 5 members of the group.
Each group gets 10 minutes present. You will be cut off after that. I may ask questions after your presentation.

4. Final project presentations: setup
We lost a lot of time during mid-term presentations due to logistical issues.
This time, every group MUST send their presentation (a link or the slide deck or a zip that can run on a Windows machine) to TA Nina by 12pm of the day their presentation is scheduled.
Do a video talk over of your full-fledged implementation. We won’t have time for a full demo in class.

5. Final project presentations: Content
What to include?
Problem space
2-3 example tasks from user analysis
First iteration of the computer prototype
Lessons learned from heuristic evaluation and next iterations
Comment on aspects of your UI that adds to usability, aka learnability, safety, and efficiency. (include advanced concepts too.)
Video demo of the final iteration and how it addresses the problem space

6. Final project presentations: Rubric
Content (70%)
Did you tell a good story?
Did you tease out the UI design lessons learned from the work done in over the last half of the semester.
Quality of work
Quantity of work
Presentation (30%)
Quality of communication
Quality of presentation
Timeliness
Flow of presentation
Question (if asked)

7. Recap: Learnability

8. In last class, we discussed some advanced aspects of learnability
Affordances
Feedback
Consistency

9. What core aspect of learnability is violated here
What core aspect of learnability is violated here? (choose the best answer)
Internal consistency
External consistency
Both of the above
None of the above

10. Internal consistency
External consistency
Both of the above
None of the above

11. What core aspect of learnability is violated here
What core aspect of learnability is violated here? (choose the best answer)
Internal consistency
External consistency
Both of the above
None of the above

13. Why might the following hinder learnability?
Consistency
Affordances
Feedback

14. Why might the following hinder learnability?
Consistency
Affordances
Feedback

16. What kind of feedback is available here to communicate affordances?
Low-level
High-level

17. What kind of feedback is available here to communicate affordances?
Low-level
High-level

19. Locus of Attention Feedback Visibility Depends on Locus of Attention
Spotlight of attention: attention focuses on one input channel (e.g. area of visual field) at a time
Does the user’s locus of attention include:
Caps Lock light on keyboard?
Status bar?
Menu bar?
Mouse cursor?

20. Locus of Attention
So when you’re thinking about how to make something important visible, you should think about where the user’s attention is likely to be focused – their document? The text cursor? The animated banner ads on the web site?
Users who use keyboard shortcuts heavily may make mode errors – in this case, sending a keyboard command to the wrong application – because they aren’t attending to the state of the menu bar.

21. Visible Navigation State

22. Visible Model State Continuous visual representation of model
What to visualize should be guided by the user’s tasks

23. Visible View State Selection highlight Selection handles
Drag & drop mouse cursor
Keyboard focus

24. Useless Feedback vs. Useful Feedback
Feedback is important, but don’t overdo it.
This dialog box demands a click from the user. Why? Does the interface need a pat on the back for finishing the conversion? It would be better to just skip on and show the resulting documentation.

25. Information Scent
Information foraging theory claims that we ask similar questions when we’re collecting information: Where should I search? Which articles or paragraphs are worth reading? Have I exhausted this source, should I move on to the next search result or a different search?
Users depend on visible cues to figure out how to achieve their goals with the least effort.

26. Information scent
Humans gathering information can be modeled like animals gathering food.
Constantly evaluating and making decisions to maximize information collected against cost of obtaining it
An important part of information foraging is the decision about whether a hyperlink is worth following – i.e., does this smell good enough to eat?
Users make this decision with relatively little information – sometimes only the words in the hyperlink itself, sometimes with some context around it

27. Give Good Information Scent
A link should “smell” like the content it leads to.
Hyperlinks in your interface – or in general, any kind of feature, including menu commands and toolbar buttons – should provide good, appropriate information scent.

28. Good & Bad Information Scent

29. Hierarchy of Exploration Costs
Glance
affordances, icons, short salient words
Read
description, keywords
Hover or press
cursor change, highlight, tooltip, submenu, preview
Click through
target page, dialog box, or mode
Invoke
feedback effect on the model state
For the user, collecting information scent cues is done progressively, with steadily increasing cost.

30. Don’t overdo it.

31. An exception of overdoing information scent

32. Let’s revisit feedback and affordances in your application
Where should you add more feedback?
Where can you improve the affordances?
Where are you giving useless feedback?
How can we reduce the exploration cost by improving the information scent?
Answers I will look for in your final presentations and GR5 submission.

33. More on Safety

34. When we discussed Safety last time:
What are different kinds of Human Error?
How can we prevent user errors when designing a UI?
How to write helpful error messages?

35. Agenda
User Control and Freedom
Undo

36. User Control and Freedom
Good interfaces are explorable.
Recall that a major way users learn is by doing: poking around an interface, trying things out.
An interface should encourage this kind of exploration, not only by making things more visible, but also by making the consequences of errors less severe.
Users should be able to explore the interface without fear of being trapped in a corner.

37. Clearly Marked Exits Long operations should be cancelable
All dialogs should have a cancel button

38. Wizard vs. Center Stage: Who’s in Control?
The wizard design pattern is a familiar pattern for improving the learnability of a complex interaction, by structuring it as a step-by-step process, showing each step in a dialog box.
Wizards are the conventional pattern for software installation.
In a wizard, the system controls the dialog - it dictates the steps, the ordering of the steps, and what it asks for at each step.

40. Wizard vs. Center Stage: Who’s in Control?
Contrast that with the center stage pattern, which lays out data objects in the main section of the window, and gives the user a set of tools for operating on the objects.
In this case, the user controls the dialog, deciding which objects to select and which tools to pick up.

42. Wizard vs. Center Stage: Who’s in Control?
Wizards clearly restrict the user’s freedom, but for complex, infrequently-done tasks (like installation), the tradeoff is often worth it.
Note, however, that a good wizard has two key features: a Back button (for backing out of errors) and a Cancel button (for vetoing the operation entirely).
So even though the wizard pattern puts the system in control of the details, the user still has supervisory control.

43. Other ways to provide user control
Manual Overrides for Automatic Systems
Never Ask Me Again
Default app

44. User Control Over Data
Data entered by the user should be editable by the user
UI should give the power to:
Create a data item
Read it
Update it
Delete it
No Arbitrary Limits on User-Defined Names

45. Undo
If Cancel is the most common answer for user control over dialog, then Undo is the most common answer to user control over data.
The first Mac applications supported only single-level undo - that is, you could undo the last command, but no farther. This was largely due to memory constraints, and modern desktop applications allow unlimited undo (or so much that it makes no difference given the current interface for Undo - nobody is going to press Ctrl-Z 1000 times, after all).
But what can we do with smartphone apps? It’s mostly a do-over.

46. Forming a Mental Model of Undo
Undo reverses the effect of an action
But that leaves many questions:
What stream of actions will be undone?
How is the stream divided into undoable units?
Which actions are undoable, and which are skipped?
How much of the previous state is actually recovered by the undo?
How far back in the stream can you undo?
View vs. Model

47. What will be undone?
Actions in this window (MS Word) or entire app (MS Excel)
Actions in this text widget (Web browser)
Just my actions, or everybody’s? (multiuser apps)
Actions made by the computer
MS Office AutoCorrect and AutoFormat are undoable, even though the user didn’t do them

48. How is the stream divided into units?
Lexical Level
Mouse clicks, key presses, mouse moves
Nobody does it at this level
Syntactic level
Commands and button presses
Semantic level
Changes to application data structures (e.g. the result of an entire Format dialog
This is the normal level
Text entry is aggregated into a single action
But other editing commands (like Backspace) and newlines interrupt the aggregation
What about user-defined macros?
Undo macro actions individually, or as a unit?

49. Which actions are undoable?
User’s action stream may include many actions that are ignored by Undo
Selection
Keyboard focus
Changing viewpoint (scrolling, zooming)
Changing layout (opening palettes or sidebars, adjusting window sizes)
UI customization (adding buttons to toolbars)
So which actions does Undo actually undo?
Some applications (web browsers, IDEs) have Undo/Redo for the editing stream, Back/Forward for the viewport stream

50. How much state is recovered?
Even if the Undo stream doesn’t include all the view changes you make, how much of the view state will be restored when it reverses a model change?
When you undo a text edit, for example, will the selection highlight be restored as well?
Will the text cursor be put back where it was before the edit?
If the text scrolls, will it be scrolled back to the same place?

51. How much state is recovered?

52. How far back can you undo?
Often a limit on history size
Used to be one action - now usually hundreds, or infinite!
Does action stream persist across application sessions? Different files of the same application?
If so, stream must be saved to file
Microsoft Excel, despite being part of the same office suite, has a global action stream. Invoking Undo undoes actions from across all open Excel windows.
Does it persist across File/Save?

53. Design Principles for Undo
Visibility
Aggregation
Reversibility of the Undo itself
Reserve it for model changes, not view changes
Undo is not the only way to support reversibility

54. Design Principles for Undo: Visibility
It’s very hard for users to predict what Undo will do.
Faced with this unpredictability, a common strategy is to press Undo until you see the effect you want to reverse actually go away, or until you realize it’s gone too far without solving the problem (i.e., it’s reversed an older, still-desired effect).
So visibility of Undo’s effects is a critical part of making it usable. Whenever Undo undoes a command, it should make sure that the effects of that have a visible change on the screen.
If the user has changed the viewpoint (e.g. scrolling) since doing the command that is now being undone, the viewpoint should be changed back, so that it’s easy to see what was reversed.

55. Design Principles for Undo
Aggregation
The unit actions should correspond to chunks of the user’s interaction: whole typed words (or strings), complete dialogs, user-defined macros.
Reversibility of the Undo itself
Undo itself should be reversible, so that if you overshoot, you can come back.
That’s what the Redo command is for.
Another way to reverse an Undo is to manually issue the undone command again; a good undo mechanism should set up the conditions for this as well

56. Design Principles for Undo
Reserve it for model changes, not view changes
For consistency, reserve the Undo command for model changes.
You can use other commands for view changes.

57. Undo is not the only way to support reversibility
Keep in mind that you don’t necessarily need a command named “Undo” to support reversibility.
There are other commands that move through other action streams (Back), and physical manipulations (like scrollbar dragging) support direct reversibility.
Users may not even think of reaching for Undo if the rest of your interface makes it easy to reverse undesired changes.
Undo is a form of backward error recovery, which fixes errors by going back in time.
A more natural way of thinking is forward error recovery - using other commands to reverse the change.
For example, to undo a Bold command by forward error recovery, you select the text again and toggle Bold off.
If your interface supports forward error recovery as much as possible, then warts in the Undo model won’t hurt as much.

58. Next class
Final Presentations