CS 422: UI Design and Programming More on Safety

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.

Final project presentations: Overview Apr 23, Apr 25, and Apr 30. 6 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.

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.

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

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)

Recap: Learnability

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

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

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

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

Why might the following hinder learnability? Consistency Affordances Feedback

Why might the following hinder learnability? Consistency Affordances Feedback

https://www.w3schools.com/bootstrap4/bootstrap_navs.asp

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

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

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?

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.

Visible Navigation State

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

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

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.

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.

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

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.

Good & Bad Information Scent

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.

Don’t overdo it.

An exception of overdoing information scent

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.

More on Safety

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?

Agenda User Control and Freedom Undo

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.

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

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.

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.

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.

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

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

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.

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

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

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?

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

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?

How much state is recovered?

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?

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

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.

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

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.

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.

Next class Final Presentations