Direct Manipulation
Internal (conceptual) model
Object 1
Objects
Relations
Attribute
Values
continuous representation of the objects of interest
physical actions (grasping, dragging, pressing buttons etc) are
used instead of commands
the effect of actions on the objects of interest is immediately
visible
examples:
full display editors and word processors (as opposite to
command line editors)
Spreadsheets and visual database management systems
Computer-aided design for electronic circuits, software
engineering projects, presentations (PowerPoint), etc.
Office automation (e.g. MS Windows)
Video games
Virtual reality
COMP106 - lecture 11 – p.1/24
Operations
Object 2
Object 3
Interaction
Representation
Reference
External (observable) model
Textual
outputs
Forms
Input elements
Graphical objects
- menus
- buttons
etc.
each object in the external model has an internal representation
reference is done by means of pointing operation (deictic
reference, rather than symbolic)
COMP106 - lecture 11 – p.2/24
Directness
when is manipulation direct manipulation?
directness can be seen as a measure of the degree to which the
implemented user interface fits the mental conception and
expectation of the user
three levels of directness:
1. Semantic:
how close the user intentions are to the operations
provided by the system.
the user should be able to communicate his intention to
the system in a simple and concise manner
so, a drawing tool which has the option “draw
rectangle” is more direct than one having only a “draw
line” option
COMP106 - lecture 11 – p.3/24
2. Operational
how close the sequence of actions the user thinks should
be done is to the actual sequence of actions in the system
so, an interface allowing to select an icon with the mouse
but not to drag it with the mouse itself is not direct
3. Formal:
how the output is immediately comprehensible to the user
e.g. the WYSIWYG (What You See Is What You Get)
principle
COMP106 - lecture 11 – p.4/24
Constraints
only those objects which are visible on the screen can be
manipulated:
the user should be able to arrange the content of the screen
parallel display of different context is essential (e.g.
window systems)
switching between contexts (e.g. windows) should be easy
and quick
problem of cluttering
high reliance on metaphors and visual language:
usually it’s an advantage, but...
misunderstandings: designer’s and user’s view may differ
may be misleading: user draws incorrect conclusions
about allowed actions
cultural differences
input devices are necessary (e.g. mouse, light pen, joystick,
track ball, touch-screen):
can be inefficient for some tasks
problem of switching between mouse and keyboard
COMP106 - lecture 11 – p.5/24
COMP106 - lecture 11 – p.6/24
Metaphors in Interface Design
A metaphor is "a figure of speech in which a word or phrase
that ordinarily designates one thing is used to designate
another, thus making an implicit comparison" (time flies).
Examples of Metaphor
Application
Metaphor
Exploits knowledge of
Word and text processing
Typewriting
typewriter, typing paper, keyboard
In interface design, a metaphor is a direct comparison between
a system (the target) and some other system already known to
the user (the source)
Advanced word processing
Document
logical structure of documents:
pages, paragraphs
Operating
ment
Desktop
office tools: notepads, calculators, organizers, folders etc.
Aim: To make the interface simpler to use by increasing its
familiarity.
Database
Data table
matrix-structured form: rows and column
Spreadsheets
Ledger sheets
matrix-structured numerical data
OO programming environments
Physical world
physical objects, their attributes, classes,
functionalities
Approach: Exploit prior knowledge that the user has of other
domains.
environ-
chapters,
Do they work? Yes, if well designed. Learning by analogy is
a very effective way for humans to learn.
Problem: That they are ... just metaphors! The target systems
are not completely equivalent to the real thing (functionalities
COMP106 - lecture 11 – p.7/24
may differ).
COMP106 - lecture 11 – p.8/24
Designing with Metaphors
A structured methodology
the use of metaphors in software development should be
carefully thought
developing a metaphor is likely to be done in several passes, in
the context of designing and evaluating a system
metaphors need to be developed and analysed with respect to
the kinds of tasks the user has to carry out, and from the user’s
point of view (task analysis)
1. perform a task analysis
2. identify candidate metaphor(s), from the user’s point of
view
3. detail the metaphor
identify metaphor/software matches with respect to a
representative of tasks
4. evaluate the metaphor(s):
verify there is enough correspondence, and choose the
more appropriate metaphor
identify likely mismatches and their implication
COMP106 - lecture 11 – p.9/24
Identifying Possible Sources of Metaphors
predecessor tools and systems
a vast proportion of tasks in the previous system is likely to have to be included in the
new system
COMP106 - lecture 11 – p.10/24
Identify Software/Metaphor Matches
from the metaphor’s source point of view, (on the basis of the
task analysis), identify:
objects
the previous system/tool becomes the metaphor for the new target system
their attributes/properties
specific design elements and appearance may be reused
the relationships among them
human propensities
the actions the user performs with them
from the metaphor’s target point of view, identify:
the way people organize things (folders, desktops)
the way people manipulate things (ponting, grasping, dragging)
objects
the way people think
e.g. a database systems, Rabbit (1984), was based on the human long-term memory
strategy of “retrieval by reformulation of concrete examples” (the user starts with a
simple query, Rabbit gives an example, and the user can manipulate it)
their attributes/properties
sheer inventions!
the Tinytalk programming environment (1980) was based on the metaphor of the
theatre (objects are actors, they follow scripts...)
COMP106 - lecture 11 – p.11/24
the relationships among them
the actions the system/interface would perform with them
select a comprehensive set of tasks from the task analysis, and
create a table of mappings for all such tasks:
task
how the user performs it
how the interface performs it
COMP106 - lecture 11 – p.12/24
Identify Likely Mismatches
Target and source system are NOT the same thing:
appearance level mismatches
things are similar in appearance (e.g. the icon for a folder and a real life close
folder)
but are also different (the real life folder is a 3D object that unfolds, the icon is a
2D object that expands into a 2D window)
such mismatches do not generally cause problems, after the initial referential
connection
method level mismatches
the methods and tasks of the metaphor are the basis for generating plans for action
in the target domain
there can be some actions that can be done with metaphor object, but cannot be
done with the target correspondent object
· in real life you get out a new folder by picking it up from a stack of new folders
· in the desktop metaphor you have to use menus
Example: the Desktop
Metaphor: The workstation represents a desktop
which can contain a number of documents organized into
folders
and icons representing services (such as printers)
a document is very much like a paper document, and can
be printed as such
direct manipulation commands operate on objects on the
desktop.
Exploit knowledge of:
how people organize their desktop, the objects in a real
life office (folders, documents, stationery pads)
Solution: provide clear indication on how to perform
“atypical” actions, ways to prevent errors, Undo functions, and
ways to recover from “surprising” states.
COMP106 - lecture 11 – p.13/24
Metaphor source characteristics:
Objects and Attributes:
Desktop: size, colour...
Folders: name...
Documents: name, content...
COMP106 - lecture 11 – p.14/24
Metaphor target characteristics
Objects and Attributes:
Screen: size, colour...
Directory: name, path
Files: name, path, content
Icons: name, image, size
Relationships:
Documents, Folders can be put on Desktop
Folders contain Documents
Folders contain other Folders
Actions: pick up documents, put documents in folders, put
documents on desktop...
Relationships:
Icons can be visualized on screen
Files are organized in Directories
Files, Directories etc. can be represented by icons
Actions: move files, open files, remove files, display icons...
COMP106 - lecture 11 – p.15/24
Mappings
COMP106 - lecture 11 – p.16/24
Possible mismatches
task
how the user performs it
how the interface performs it
task1
remove document from a folder to view
select document (file) from folder (directory)
to edit
task2
organize collections of documents in folders
organize collections of documents (files) in
folders (directories)
users don’t know how to set up new folders
solution: provide clear menu items, or create icon/method for "getting new stationery"
users may think they can pick up again what trashed in the bin
solution: provide a warning message when user deletes a file, or provide Undo for
task3
open folder by pulling back cover
select folder (directory) by double-clicking
icon
recovering deleted documents
users may not realize that a folder can contain other folders
solution: make icons for folders containing other folders “fatter” than others, or use
other objects (e.g. boxes, drawers, cabinets etc.)
user may be surprised that, say, printers can be put in folders
task4
file document by moving it into folder
insert document (file) into folder (directory)
by dragging document’s icon into folder window
solution: (disallowing this is not convenient, as “printers” are in fact program files) add
to manual/help a itemize of what a file is, for novice users
user may think that dragging a document to the printer will
print it out
...
COMP106 - lecture 11 – p.17/24
solution: provide clear menu items, or create such a method
COMP106 - lecture 11 – p.18/24
Two Examples of Misuse of Metaphors
Pushing the metaphor too far:
Direct-Manipulation Programming
aka: Programming by Example or Programming by
Demonstration
it is a technique for "teaching" a system new commands by
demonstrating actions on concrete examples
principle: if a user knows how to perform a task, that should
be sufficient to create a program to perform the task
advantage: no need to learn a programming language like C or
ADA
Mac’s trashbin metaphor used to eject the diskette
Going too close to reality:
how it works: the system “watches what the user does” and
generalises a program that can be used in new examples
example: creating macros by simply doing the correspondent
sequence of actions (metaphor of the video-recorder in MS
Office’s applications)
IBM’s Audiostation: an ambiguous “Mode” button
COMP106 - lecture 11 – p.19/24
COMP106 - lecture 11 – p.20/24
An Example: Mondrian
Mondrian is a OO graphical editor that can learn new
graphical procedures through programming by example.
I tell the system how to do it by just doing it: I start by drawing
three rectangles, then I delete the middle part, then I group...
example: I want to create a new command for drawing an arch:
the sequence of actions gets recorded
COMP106 - lecture 11 – p.21/24
what it gets generated (automatically) is some LISP code
COMP106 - lecture 11 – p.22/24
Another example: QBE
In database management systems, Query by Example
(QBE) refers to a method of forming queries in which a
blank table is displayed where the user can select fields
and enter conditions on them.
now the system knows how to draw an arch:
An SQL query gets automatically generated:
SELECT DeptCode, CrsNum, Title FROM Courses
WHERE DeptCode = ‘‘COMM’’;
COMP106 - lecture 11 – p.23/24
COMP106 - lecture 11 – p.24/24