This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Spring 2008 6.831 User Interface Design and Implementation 1Lecture 6: Output UI Hall of Fame or Shame?Fall 2006 6.831 UI Design and Implementation 2 Our Hall of Fame or Shame candidate for today is the command ribbon, which was introduced in Microsoft Office 2007. The ribbon is a radically different user interface for Office, merging the menubar and toolbars together into a single common widget. Clicking on one of the tabs (“Write”, “Insert”, “Page Layout”, etc) switches to a different ribbon of widgets underneath. The metaphor is a mix of menubar, toolbar, and tabbed pane. (Notice how UIs have evolved to the point where new metaphorical designs are riffing on existing GUI objects, rather than physical objects. Expect to see more of that in the future.) Needless to say, slavish external consistency has been thrown out the window – Office no longer has a menubar or toolbar. But if we were slavishly consistent, we’d never make any progress in user interface design. Despite the radical change, the ribbon is still externally consistent in some interesting ways, with other Windows programs and with previous versions of Office. Can you find some of those ways? The ribbon is also notable for being designed from careful task analysis. How can you tell?Today’s Topics• Output models•Drawing• Rasterization• Color modelsSpring 2008 6.831 User Interface Design and Implementation 3 Today’s lecture continues our look into the mechanics of implementing user interfaces, by considering output in more detail. One 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. Three Output Models• Components– Graphical objects arranged in a tree with automatic redraw– Example: Label object, Line object– Also called: views, interactors, widgets, controls, retained graphics•Strokes– High-level drawing primitives: lines, shapes, curves, text– Example: drawText() method, drawLine() method– Also called: vector graphics, structured graphics•Pixels– 2D array of pixels– Also called: raster, image, bitmapSpring 2008 6.831 User Interface Design and Implementation 4 There are basically three ways to represent the output of a graphical user interface. Components is the same as the view hierarchy we discussed last week. Parts of the display are represented by view objects arranged in a spatial hierarchy, with automatic redraw propagating down the hierarchy. There have been many names for this idea over the years; the GUI community hasn’t managed to settle on a single preferred term. Strokes draws output by making calls to high-level drawing primitives, like drawLine, drawRectangle, drawArc, and drawText. Pixels regards the screen as an array of pixels and deals with the pixels directly. All three output models appear in virtually every modern GUI application. The component model always appears at the very top level, for windows, and often for components within the windows as well. At some point, we reach the leaves of the view hierarchy, and the leaf views draw themselves with stroke calls. A graphics package then converts those strokes into pixels displayed on the screen. For performance reasons, a component may short-circuit the stroke package and draw pixels on the screen directly. On Windows, for example, video players do this using the DirectX interface to have direct control over a particular screen rectangle. What model do each of the following representations use? HTML (component);Postscript laser printer (stroke input, pixel output); plotter (stroke input and output); PDF (stroke); LCD panel (pixel). Example: Designing a Graph View• Component model– Each node and edge is a component– A node might have two subcomponents: circle and label• Stroke model– Graph view draws lines, circles and text•Pixel model– Graph view has pixel images of the nodesSpring 2008 6.831 User Interface Design and Implementation 5ACB Since every application uses all three models, the design question becomes: at which points in your application do you want to step down into a lower-level output model? Here’s an example. Suppose you want to build a view that displays a graph of nodes and edges. One approach would represent each node and each edge in the graph by a component. Each node in turn might have two components, a circle and a text label. Eventually, you’ll get down to the primitive components available in your GUI toolkit. Most GUI toolkits provide a text label component; most don’t provide a primitive circle component. One notable exception is Amulet, which has component equivalents for all the common drawing primitives. This would be a pure component model, at least from your application’s point of view – stroke output and pixel output would still happen, but inside primitive components that you took from the library. Alternatively, the top-level window might have no subcomponents. Instead, it would draw the entire graph by a sequence of stroke calls: drawCircle for the node outlines, drawText for the labels, drawLine for the edges. This would be a pure stroke model. Finally, your graph view might bypass stroke drawing and set pixels in the window directly. The text labels might be assembled by copying character images to the screen. This pure pixel model is rarely used nowadays, because it’s the most work for the programmer, but it used to be theonly way to program graphics. Hybrid models for the graph view are certainly possible, in which some parts of the output use one model, and others use another model. The graph view might use components for nodes, but draw the edges itself as strokes. It might draw all the lines itself, but use label components for the text. Issues in Choosing Output Models• Layout• Input• Redraw• Drawing order• Heavyweight objects• Device dependenceSpring 2008 6.831 User Interface Design and Implementation 6 Layout: Components remember where they were put, and draw themselves there. They also support automatic layout. With stroke or pixel models, you


View Full Document

MIT 6 831 - Output

Documents in this Course
Quiz 2

Quiz 2

10 pages

Quiz 2

Quiz 2

8 pages

Input

Input

9 pages

Load more
Download Output
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Output and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Output 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?