Spring 2008 6.831 User Interface Design and Implementation 1Lecture 8: Input UI Hall of Fame or Shame?Spring 2008 6.831 User Interface Design and Implementation 2Source: Interface Hall of Shame This message used to appear when you tried to delete the contents of your Internet Explorer cache from inside Windows Explorer (i.e., you browse to the cache directory, select a file containing one of IE’s browser cookies, and delete it). 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? Hall of ShameSpring 2008 6.831 User Interface Design and Implementation 3Source: Interface Hall of Shame Suppose you selected all your cookie files and tried to delete them all in one go. You get one dialog for every cookie you tried to delete! What button is missing from this dialog?Hall of Fame or Shame?Spring 2008 6.831 User Interface Design and Implementation 4Source: Interface Hall of Shame One 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? What would you have to do? Hall of FameSpring 2008 6.831 User Interface 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, found in 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.Today’s Topics• Input events• Event dispatch• Event propagationSpring 2008 6.831 User Interface Design and Implementation 6 Today’s lecture continues our look into the mechanics of implementing user interfaces, by looking at input in more detail. Our goal for these implementation lectures is not to teach any one particular GUI system or toolkit, but to give a survey of the issues involved in GUI programming and the range of solutions adopted by various systems. Presumably you’ve already encountered at least one GUI toolkit, probably Java Swing. These lectures should give you a sense for what’s common and what’s unusual in the toolkit you already know, and what you might expect to find when you pick up another GUI toolkit. Why Use Events for GUI Input?• Console I/O uses blocking procedure callsprint (“Enter name:”)name = readLine();print (“Enter phone number:”)name = readLine();– System controls the dialogue• GUI input uses event handling instead– User has much more control over the dialogue – User can click on almost anythingSpring 2008 6.831 User Interface Design and Implementation 7 Virtually all GUI toolkits use event handling for input. Why? Recall, when you first learned to program, you probably wrote user interfaces that printed a prompt and then waited for the user to enter a response. After the user gave their answer, you produced another prompt and waited for another response. Command-line interfaces (e.g. the Unix shell) and menu-driven interfaces (e.g., Pine) have interfaces that behave this way. In this user interface style, the system has complete control over the dialogue – the order in which inputs and outputs will occur. Interactive graphical user interfaces can’t be written this way – at least, not if they care about giving the user control and freedom. One of the biggest advantages of GUIs is that a user can click anywhere on the window, invoking any command that’s available at the moment, interacting with any view that’s visible. In a GUI, the balance of power in the interaction swings strongly over to the user’s side. As a result, GUI programs can’t be written in a synchronous, prompt-response style. A component can’t simply take over the entire input channel to wait for the user to interact with it, because the user’s next input may be directed to some other component on the screen instead. So GUI programs are designed to handle input asynchronously, receiving it as events.Kinds of Input Events• Raw input events– Mouse moved– Mouse button pressed or released– Key pressed or released• Translated input events– Mouse click or double-click– Mouse entered or exited component– Keyboard focus gained or lost (loss of focus is sometimes called “blur”)– Character typedSpring 2008 6.831 User Interface Design and Implementation 8 There are two major categories of input events: raw and translated. A raw event comes right from the device driver. Mouse movements, mouse button down and up, and keyboard key down and up are the raw events seen in almost every capable GUI system. A toolkit that does not provide separate events for down and up is poorly designed, and makes it difficult or impossible to implement input effects like drag-and-drop or video game controls. For many GUI components, the raw events are too low-level, and must be translated into higher-level events. For example, a mouse button press and release is translated into a mouse click event (assuming the mouse didn’t move much between press and release – if it did, these events would be translated into a drag rather than a click). Key down and up events are translated into character typed events, which take modifiers into account to produce an ASCII character rather than a keyboard key. If you hold a key down, multiple character typed events may
View Full Document
Unlocking...