1Fall 2004 6.831 UI Design and Implementation 1 2Fall 2004 6.831 UI Design and Implementation 2 Suggested by Vikki ChouToday’s candidate for the Hall of Fame or Shame is the modal dialog box.A modal dialog box (like the File Open dialog seen here) prevents the user from interacting with the application that popped it up.Modal dialogs do have some usability advantages, such as error prevention (the modal dialog is always on top, so it can’t get lost or be ignored, and the user can’t accidentally change the selection in the main window while working on a modal dialog that affects that selection) and dialog closure (you’re required to proceed through the dialog rather than switching to something else).But there are usability disadvantages too, chief among them loss of user control and reduced visibility (e.g., you can’t see important information or previews in the main window). Worst of all, failures in task analysis might bite you hard -- forcing the user to remember information from one modal dialog to another, rather than viewing and interacting with both dialogs side-by-side.When you try to interact with the main window, Windows gives some nice animated feedback – flashing the border of the modal dialog box. This helps explain why your clicks on the main window had no effect. On most platforms, you can at least move, resize, and minimize the main window, even when a modal dialog is showing. (The modal dialog minimizes along with it). Alas, not on Windows… the main window is completely pinned! You can minimize it only by obscure means, like the Show Desktop command, which minimizes all windows. This is a big problem with user control and freedom.Modeless dialogs, by contrast, don’t prevent using other windows in the application. They’re often used for ongoing interactions with the main window, like Find/Replace. One problem is that a modeless dialog box can get in the way of viewing or interacting with the main window (as when a Find/Replace dialog covers up the match). Another problem is a consistency problem: modal dialogs and modeless dialogs usually look identical. Sometimes the presence of a Minimize button is a clue that it’s modeless, but that’s not a very strong visual distinction. A modeless dialog may be better represented as a sidebar, a temporary pane in the main window that’s anchored to one side of the window. Then it can’t obscure the user’s work, can’t get lost, and is clearly visually different from a modal dialog box.3Fall 2004 6.831 UI Design and Implementation 3 On Windows, modal dialogs are generally application-modal – all windows in the application stop responding until the dialog is dismissed. (The old days of GUIs also had system-modal dialogs, which suspended allapplications.) Mac OS X has a neat improvement, window-modal dialogs, which are displayed as translucent sheets attached to the titlebar of the blocked window. This tightly associates the dialog with its window, gives a little visibility of what’s underneath it in the main window – and allows you to interact with other windows, even if they’re from the same application.Another advantage of Mac sheets is that they make a strong contrast with modeless dialogs – the translucent, anchored modal sheet is easy to distinguish from a modeless window.4Fall 2004 6.831 UI Design and Implementation 4 ! Keystroke-level models GOMS CPM-GOMSToday’s lecture is about predictive evaluation – the holy grail of usability engineering. If we had an accurate model for the way a human used a computer interface, we would be able to predict the usability of a design, without having to actually build it, test it against real people, and measure their behavior. User interface design would then become more like other fields of engineering. Civil engineers can use models (of material stress and strain) to predict the load that can be carried by a bridge; they don’t have to build it and test it to destruction first. As user interface designers, we’d like to do the same thing.5Fall 2004 6.831 UI Design and Implementation 5 Predictive evaluation uses an engineering model of human cognition to predict usability Model is abstract quantitative approximate estimated from user experiments 7 ± 2 At its heart, any predictive evaluation technique requires a model for how a user interacts with an interface. We’ve already seen one such model, the Newell/Card/Moran human information processing model. This model needs to be abstract – it can’t be as detailed as an actual human being (with billions of neurons, muscles, and sensory cells), because it wouldn’t be practical to use for prediction. The model we looked at boiled down the rich aspects of information processing into just three processors and two memories.It also has to be quantitative, i.e., assigning numerical parameters to each component. Without parameters, we won’t be able to compute a prediction. We might still be able to do qualitativecomparisons, such as we’ve already done to compare, say, Mac menu bars with Windows menu bars, or cascading submenus. But our goals for predictive evaluation These numerical parameters are necessarily approximate; first because the abstraction in the model aggregates over a rich variety of different conditions and tasks; and second because human beings exhibit large individual differences, sometimes up to a factor of 10 between the worst and the best. So the parameters we use will be averages, and we may want to take the variance of the parameters into account when we do calculations with the model.Where do the parameters come from? They’re estimated from experiments with real users. The numbers seen here for the general model of human information processing (e.g., cycle times of processors and capacities of memories) were inferred from a long literature of cognitive psychology experiments. But for more specific models, parameters may actually be estimated by
View Full Document
Unlocking...