Advanced GUI Paradigms Overview Direct Manipulation

Advanced GUI Paradigms More ideas for successful GUIs

Overview • • • • • •

Direct Manipulation Cut, Copy, Paste Embedded editing Drag & Drop Undo and Redo Help & documentation

Direct Manipulation • • • •

All interactive objects should be visible Rapid feedback in response to user actions Incremental actions are possible Reversibility: encourages exploration – E.g. through use of undo

• Syntactic correctness of all actions – Only legal actions are permitted by the UI

1

Direct Manipulation (2) • Replace language with action – No arcane command syntax to memorize (supports recognition over recall)

• WYSIWYG – what you see is what you get • Need to be: – Fast – actions shouldn’t take long – Tolerant to user errors – Well-designed

• Yet still should enable full spectrum of potential actions

Cut, Copy & Paste Paradigm • Replication/transfer of data via a ‘clipboard’ • Clipboard must support different data types: – Text, e.g. from word processor – words, lines, paragraphs, entire documents – Images, e.g. JPEGs from Photoshop – Multimedia, e.g. PowerPoint animations

• Cut/Copy stores data in one or more formats or makes use of meta-files • Paste queries data format or requests translation into something that receiving application can handle

Programming • Cut, copy & paste – Can cause hard to detect errors: Polygon->vertex[0].x Polygon->vertex[0].y Polygon->vertex[0].z Polygon->vertex[1].x Polygon->vertex[1].x Polygon->vertex[0].z

= = = = = =

1.0; 2.0; 3.0; 3.0; 2.0; 1.0;

2

Publish/Subscribe Paradigm • Cut/copy & paste for permanent transfer of information, which is not always desirable • Publish/Subscribe: link to original object is maintained and copies are update if original changes • Events are used to inform applications of all changes to original object • Publish/Subscribe on Mac – Flexible alias mechanisms, editions, maintain links

• OLE on Windows: pasting retains links to original application – Monikers: relative paths and identifiers into document

• May break if files move around

Embedded Editing • Embedding – Embed object in document
import data and functionality of another program

• Two different strategies for editing: – Edit Aside • Open new window for editing (OLE 1.0) • Relatively straightforward if objects can be serialized

– Edit in Place • Rectangular area (OLE 2.0) • Free form, including page breaks – more complex

Embedded Editing (2) • Embedding requires that pasted objects provide: – Property methods (for determining size, shape, etc.) – Redraw method – Save/load within another document (serialization) – Object’s user interface • E.g. an Excel spreadsheet embedded in a Word document needs Excel UI for editing • Menu bar, toolbar, palette changes, etc.

3

Drag & Drop Paradigm • Data transfer via direct manipulation of interactive objects • Used to move data: – Within and between different applications • Cut, copy & paste-like functionality

– In the file system interface • E.g. Drag a file to another folder to copy/move it there – What about dragging a CD icon to the trash bin to eject?

Undo / Redo • Undo allows user to cancel previous actions • For all undoable actions/commands in the application: – Code is needed which reverses effect of action – For each command executed by the user, save undo record • Either store previous state • Or reference to changed part of data • Or store the whole state of the application

– Usually just store the changes in state – Don’t undo undo!
Redo command

Undo (2) • Irreversible actions can be ignored – E.g. Print, “fire missiles” – what about save? – Transient commands that don’t change the state of the model can also usually be ignored • Rubber-banding in a drawing program • Scrolling in a window

• Selective undo – pick an action to undo in the history – Necessitates conflict resolution

• Hierarchical undo – difficult to understand – Undo entire interaction or parts

4

Help • Help should be problem-oriented and specific to the system features that the user is currently applying • Help can be requested by: – Topic – assumes user knowledge; sometimes user needs guidance to know what to look for – Help button / menu – may be context sensitive – Keyboard or mouse button (e.g. F1)

• Context sensitive help requires that each widget has a help reference to part of documentation relevant to it

Help (2) • Various ways to display help – – – –

In a new window Whole screen (obscuring the work area) Part of screen Help hints and prompts (balloon help or tool tips – or talking paper clips!) – Visual cues when suggestion is available, e.g. on mouseover

• Help ≠ documentation! Simply outputting the user manual isn’t very helpful at all - be specific!

Documentation • Documentation is system-oriented and general, unlike a Help facility • Provides: – Introduction to system functionality – Clear descriptions of “how-to” information: – Task-oriented and should be written from user’s perspective – Requires both table of contents as well as index! • Synonyms increase chance of finding information

• Inconvenient to browse documentation on computer – But companies do it to reduce “your” (i.e. their) costs

5

Wizards • Wizards encapsulate frequently used action sequences, e.g. “add new printer” – Commonly used functionality – Limited learning effect • Users rely on wizard, don’t gain understanding of the behind-the-scenes actions

– Useful for novices and domain experts alike

On-line Tutorials • Demonstrate action sequences that need to be followed – Shows solution to a specific problem (usually system-oriented) – Passive vs. active – E.g. Apple Guide – combines both active and passive tutorials

Presentation of Help & Docs • Use clear and familiar language • Style: “how to use the system” – Not a system description! – User has goals & doesn’t play around with software – Avoid jargon

• Be consistent with screen content/printed manuals • Be unobtrusive – don’t block the application display • DON’T USER COMPUTER SCIENCE HUMOR! – Especially not in error messages!

6