1Fall 2004 6.831 UI Design and Implementation 1 2Fall 2004 6.831 UI Design and Implementation 2 Source: Interface Hall of ShameThis message used to appear when you tried to delete the contents of your Internet Explorer cache from within the Windows Explorer.Put aside the fact that the message is almost tautological (“Cookie… is a Cookie”) and overexcited (“!!”). Does it give the user enough information to make a decision? What’s a Cookie? What will happen if I delete it? Don’t ask questions the user can’t answer.3Fall 2004 6.831 UI Design and Implementation 3 Source: Interface Hall of ShameAnd definitely don’t ask more than once. There may be hundreds of cookies cached in the browser; this dialog box appears for each one the user selected.There’s something missing from the dialog, whose absence becomes acute once the dialog appears a few times: a Cancel button. Always give users a way to escape.4Fall 2004 6.831 UI Design and Implementation 4 Source: Interface Hall of ShameOne way to fix the too-many-questions problem is Yes To All and No To All buttons, which short-circuit the rest of the questions by giving a blanket answer. That’s a helpful shortcut, but this example shows that it’s not a panacea.This dialog is from Microsoft’s Web Publishing Wizard, which uploads local files to a remote web site. Since the usual mode of operation in web publishing is to develop a complete copy of the web site locally, and then upload it to the web server all at once, the wizard suggests deleting files on the host that don’t appear in the local files, since they may be orphans in the new version of the web site.But what if you know there’s a file on the host that you don’t want to delete? You’d have to say No to every dialog until you found that file.5Fall 2004 6.831 UI Design and Implementation 5 If your interface has a potentially large number of related questions to ask the user, it’s much better to aggregate them into a single dialog. Provide a list of the files, and ask the user to select which ones should be deleted. Select All and Unselect All buttons would serve the role of Yes to All and No to All.Here’s an example of how to do it right, provided by IBM Eclipse. If there’s anything to criticize in Eclipse’s dialog box, it might be the fact that it initially doesn’t show the filenames, just their count --- you have to press Details to see the whole dialog box. Simply knowing the number of files not under CVS control is rarely enough information to decide whether you want to say yes or no, so most users are likely to press Details anyway.Nevertheless, this deserves to be in the hall of fame.6Fall 2004 6.831 UI Design and Implementation 6 Model-view-controller View hierarchy ObserverStarting with today’s lecture, we’ll be talking about how graphical user interfaces are implemented. Today we’ll take a high-level look at the software architecture of GUI software, focusing on the design patterns that have proven most useful. Three of the most important patterns are the model-view-controller abstraction, which has evolved somewhat since its original formulation in the early 80’s; the view hierarchy, which is a central feature in the architecture of every popular GUI toolkit; and the observer pattern, which is essential to decoupling the model from the view and controller.7Fall 2004 6.831 UI Design and Implementation 7 ! "#$# Separation of responsibilities Model: application state Maintains application state (data fields) Implements state-changing behavior Notifies dependent views/controllers when changes occur (observer pattern) View: output Occupies screen extent Queries the model to draw it on the screen Listens for changes to the model to update the drawing Controller: input Listens for keyboard & mouse events Tells the model or the view to change accordingly Decoupling Can have multiple views/controllers for same model Can reuse views/controllers for other modelsThe model-view-controller pattern, originally articulated in the Smalltalk-80 user interface, has strongly influenced the design of UI software ever since. In fact, MVC may have single-handedly inspired the software design pattern movement; it figures strongly in the introductory chapter of the seminal “Gang of Four” book (Gamma, Helm, Johnson, Vlissides, Design Patterns: Elements of Reusable Software).MVC’s primary goal is separation of concerns. It separates the user interface frontend from the application backend, by putting backend code into the model and frontend code into the view and controller. MVC also separates input from output; the controller is supposed to handle input, and the view is supposed to handle output.The model is responsible for maintaining application-specific data and providing access to that data. Models are often mutable, and they provide methods for changing the state safely, preserving its representation invariants. OK, all mutable objects do that. But a model must also notify its clients when there are changes to its data, so that dependent views can update their displays, and dependent controllers can respond appropriately. Models do this notification using the observer pattern, in which interested views and controllers register themselves as listeners for events generated by the model.View objects are responsible for output. A view usually occupies some chunk of the screen, usually a rectangular area. Basically, the view queries the model for data and draws the data on the screen. It listens for changes from the model so that it can update the screen to reflect those changes.Finally, the controller handles the input. It receives keyboard and mouse events, and instructs the model to change accordingly.In principle, this separation has several benefits. First, it allows the interface to have multiple views showing the same application data. For example, a database field might be shown in a table and in an editable form at the same time.
View Full Document
Unlocking...