1Fall 2005 6.831 UI Design and Implementation 1 2Fall 2005 6.831 UI Design and Implementation 2 Source: UI Hall of ShameOur Hall of Shame candidate for the day is this dialog box from Adaptec Easy CD Creator, which appears at the end of burning a CD. The top image shows the dialog when the CD was burned successfully; the bottom image shows what it looks like when there was an error.The key problem is the lack of contrast between these two states. Success or failure of CD burning is important enough to the user that it should be obvious at a glance. But these two dialogs look identical at a glance. How can we tell? Use the squint test, which we talked about in the graphic design lecture. When you’re squinting, you see some labels, a big filled progress bar, a roundishicon with a blob of red, and three buttons. All the details, particularly the text of the messages and the exact shapes of the red blob, are fuzzed out. This simulates what a user would see at a quick glance, and it shows that the graphic design doesn’t convey the contrast.One improvement would change the check mark to another color, say green or black. Using red for OK seems inconsistent with the real world, anyway. But designs that differ only in red and green wouldn’t pass the squint test for color-blind users.Another improvement might remove the completed progress bar from the error dialog, perhaps replacing it with a big white text box containing a more detailed description of the problem. That would clearly pass the squint test, and make errors much more noticeable.3Fall 2005 6.831 UI Design and Implementation 3 Source: UI Hall of ShameOur second Hall of Shame candidate for the day is this interface for choosing how a list of database records should be sorted. Like other sorting interfaces, this one allows the user to select more than one field to sort on, so that if two records are equal on the primary sort key, they are next compared by the secondary sort key, and so on.On the plus side, this interface communicates one aspect of its model very well. Each column is a set of radio buttons, clearly grouped together (both by gestalt proximity and by an explicit raised border). Radio buttons have the property that only one can be selected at a time. So the interface has a clear affordance for picking only one field for each sort key.But, on the down side, the radio buttons don’t afford making NO choice. What if I want to sort by only one key? I have to resort to a trick, like setting all three sort keys to the same field. The interface model clearly doesn’t map correctly to the task it’s intended to perform. In fact, unlike typical model mismatch problems, both the user and the system have to adjust to this silly interface model – the user by selecting the same field more than once, and the system by detecting redundant selections in order to avoid doing unnecessary sorts.The interface also fails on minimalist design grounds. It wastes a huge amount of screen real estate on a two-dimensional matrix, which doesn’t convey enough information to merit the cost. The column labels are similarly redundant; “sort option” could be factored out to a higher level heading. The term “Primary” is not really consistent with “Second” and “Third”; “First” would be simpler.4Fall 2005 6.831 UI Design and Implementation 4 Widgets Toolkit layering Look-and-feel5Fall 2005 6.831 UI Design and Implementation 5 Reusable user interface components Also called controls, interactors, gizmos, gadgets Widget is a view + controller Embedded model Application data must be copied into the widget Changes must be copied out Linked model Application provides model satisfying an interface Enables data-bound widgets, e.g. a table showing thousands of database rows, or a combo box with thousands of choicesWidgets are the last part of user interface toolkits we’ll look at. Widgets are a success story for user interface software, and for object-oriented programming in general. Many GUI applications derive substantial reuse from widgets in a toolkit.Widgets generally combine a view and a controller into a single tightly-coupled object. For the widget’s model, however, there are two common approaches. One is to fuse the model into the widget as well, making it a little MVC complex. With this embedded model approach, application data must be copied into the widget to initialize it. When the user interacts with the widget, the user’s changes or selections must be copied back out.The other alternative is to leave the model separate from the widget, with a well-defined interface that the application can implement.Embedded models are usually easier for the developer to understand and use for simple interfaces, but suffer from serious scaling problems. For example, suppose you want to use a table widget to show the contents of a database. If the table widget had an embedded model, you would have to fetch the entire database and load it into the table widget, which may be prohibitively slow and memory-intensive. Furthermore, most of this is wasted work, since the user can only see a few rows of the table at a time. With a well-designed linked model, the table widget will only request as much of the data as it needs to display.The linked model idea is also called data binding.6Fall 2005 6.831 UI Design and Implementation 6 !"#" Advantages Reuse of development effort Coding, testing, debugging, maintenance Iteration and evaluation External consistency Disadvantages Constrain designer s thinking Encourage menu & forms style, rather than richer direct manipulation style May be used inappropriatelyWidget reuse is beneficial in two ways, actually. First are the conventional software engineering benefits of reusing code, like shorter development time and greater reliability. A widget encapsulates a lot of effort that somebody else has already put in.Second are usability benefits. Widget reuse increases consistency among the applications on a platform. It also (potentially) represents usability effort that its designers
View Full Document
Unlocking...