(Ebook) Conceptual Models: Core To Good Use PB by Johnson, Henderson ISBN 9781608457496, 1608457494 PDF Download
(Ebook) Conceptual Models: Core To Good Use PB by Johnson, Henderson ISBN 9781608457496, 1608457494 PDF Download
https://ebooknice.com/product/conceptual-models-core-to-good-use-
pb-2456254
https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374
https://ebooknice.com/product/matematik-5000-kurs-2c-larobok-23848312
https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018
(Ebook) Master SAT II Math 1c and 2c 4th ed (Arco Master the SAT
Subject Test: Math Levels 1 & 2) by Arco ISBN 9780768923049,
0768923042
https://ebooknice.com/product/master-sat-ii-math-1c-and-2c-4th-ed-
arco-master-the-sat-subject-test-math-levels-1-2-2326094
(Ebook) Cambridge IGCSE and O Level History Workbook 2C - Depth Study:
the United States, 1919-41 2nd Edition by Benjamin Harrison ISBN
9781398375147, 9781398375048, 1398375144, 1398375047
https://ebooknice.com/product/cambridge-igcse-and-o-level-history-
workbook-2c-depth-study-the-united-states-1919-41-2nd-edition-53538044
https://ebooknice.com/product/teaching-to-avoid-plagiarism-how-to-
promote-good-source-use-5047202
https://ebooknice.com/product/the-geology-of-australia-48067776
https://ebooknice.com/product/core-knowledge-and-conceptual-
change-5743212
https://ebooknice.com/product/models-for-mental-disorder-4th-ed-
conceptual-models-in-psychiatry-1400586
Series
SeriesISSN:
Series ISSN:1946-7680
ISSN: 1946-7680
1946-7680
JOHNSON
JOHNSON ••• HENDERSON
JOHNSON
SSYNTHESIS
YNTHESIS LLECTURES
C
ECTURES ON
&
YNTHESIS ECTURES ON
ON Mor
Mor gan&
Morgan
gan &Cl
Claypool
Cl aypool Publishers
aypool Publishers
Publishers
H UMAN-C
HUMAN-
UMAN- ENTERED IINFORMATICS
CENTERED
ENTERED NFORMATICS
NFORMATICS
HENDERSON
HENDERSON
Series
SeriesEditor:
Series Editor:John
Editor: JohnM.
John M.Carroll,
M. Carroll,Penn
Carroll, PennState
Penn StateUniversity
State University
University
Conceptual
Conceptual Models
Models Conceptual Models
Core
Core to
to Good
Good Design
Design
Jeff
JeffJohnson,
Jeff Johnson,UI
Johnson, UIWizards,
UI Wizards,Inc.
Wizards, Inc.
Inc.
Core
Core to
to Good
Good D
Deesign
sign
Austin
AustinHenderson,
Austin Henderson,Rivendel
Henderson, RivendelConsulting
Rivendel Consulting&
Consulting &Design
& Design
Design
People
Peoplemake
People makeuse
make useof
use ofsoftware
of softwareapplications
software applicationsin
applications intheir
in theiractivities,
their activities,applying
activities, applyingthem
applying themas
them astools
as toolsin
tools incarrying
in carryingout
carrying outtasks.
out tasks.That
tasks. That
That
this
thisuse
this useshould
use shouldbe
should begood
be goodfor
good forpeople
for people–––easy,
people easy,effective,
easy, effective,efficient,
effective, efficient,and
efficient, andenjoyable
and enjoyable–––isisisaaaprincipal
enjoyable principalgoal
principal goalof
goal ofdesign.
of design.In
design. In
In
this
thisbook,
this book,we
book, wepresent
we presentthe
present thenotion
the notionof
notion ofConceptual
of ConceptualModels,
Conceptual Models,and
Models, andargue
and arguethat
argue thatConceptual
that ConceptualModels
Conceptual Modelsare
Models arecore
are coreto
core toachieving
to achieving
achieving
CONCEPTUAL
CONCEPTUAL MODELS
CONCEPTUAL
good
gooddesign.
good design.From
design. Fromyears
From yearsof
years ofhelping
of helpingcompanies
helping companiescreate
companies createsoftware
create softwareapplications,
software applications,we
applications, wehave
we havecome
have cometo
come tobelieve
to believethat
believe that
that
building
buildingapplications
building applicationswithout
applications withoutConceptual
without ConceptualModels
Conceptual Modelsisisisjust
Models justasking
just askingfor
asking fordesigns
for designsthat
designs thatwill
that willbe
will beconfusing
be confusingand
confusing anddifficult
and difficult
difficult
totolearn,
to learn,remember,
learn, remember,and
remember, anduse.
and use.
use.
WeWeshow
We showhow
show howConceptual
how ConceptualModels
Conceptual Modelsare
Models arethe
are thecentral
the centrallink
central linkbetween
link betweenthe
between theelements
the elementsinvolved
elements involvedin
involved inapplication
in applicationuse:
application use:
use:
people’s
people’stasks
people’s tasks(task
tasks (taskdomains),
(task domains),the
domains), theuse
the useof
use oftools
of toolsto
tools toperform
to performthe
perform thetasks,
the tasks,the
tasks, theconceptual
the conceptualstructure
conceptual structureof
structure ofthose
of thosetools,
those tools,
tools,
MODELS
MODELS
the
thepresentation
the presentationof
presentation ofthe
of theconceptual
the conceptualmodel
conceptual model(i.e.,
model (i.e.,the
(i.e., theuser
the userinterface),
user interface),the
interface), thelanguage
the languageused
language usedto
used todescribe
to describeit,
describe it,its
it, its
its
implementation,
implementation,and
implementation, andthe
and thelearning
the learningthat
learning thatpeople
that peoplemust
people mustdo
must doto
do touse
to usethe
use theapplication.
the application.We
application. Wefurther
We furthershow
further showthat
show thatputting
that putting
putting
aaaConceptual
are
ConceptualModel
Conceptual
aresimpler
are simplerand
simpler
Modelat
Model
andmesh
and
atthe
at
meshbetter
mesh
thecenter
the centerof
center
betterwith
better
ofthe
of
withusers’
with
thedesign
the designand
design
users’tasks,
users’
anddevelopment
and
tasks,avoidance
tasks,
developmentprocess
development
avoidanceof
avoidance ofunnecessary
of
processcan
process
unnecessaryfeatures,
unnecessary
canpay
can payrich
pay richdividends:
rich
features,easier
features,
dividends:designs
dividends:
easierdocumentation,
easier
designsthat
designs
documentation,faster
documentation,
that
that
faster
faster Jeff
JeffJohnson
Johnson
development,
development,improved
development, improvedcustomer
improved customeruptake,
customer uptake,and
uptake, anddecreased
and decreasedneed
decreased needfor
need fortraining
for trainingand
training andcustomer
and customersupport.
customer support.
support.
Austin
AustinHenderson
Henderson
About
AboutSYNTHESIs
About SYNTHESIs
SYNTHESIs
This
Thisvolume
This volumeisisisaaaprinted
volume printedversion
printed versionof
version ofaaawork
of workthat
work thatappears
that appearsin
appears inthe
in theSynthesis
the Synthesis
Synthesis
Digital
DigitalLibrary
Digital Libraryof
Library ofEngineering
of Engineeringand
Engineering andComputer
and ComputerScience.
Computer Science. Synthesis
Science. SynthesisLectures
Synthesis Lectures
Lectures
Mor
Morgan
Mor
provide
provide concise,
provideconcise, original
concise,original presentations
originalpresentations
presentationsof of important
ofimportant research
importantresearch and
researchand development
anddevelopment
development
topics,
topics,published
topics, publishedquickly,
published quickly,in
quickly, indigital
in digitaland
digital andprint
and printformats.
print formats.For
formats. Formore
For moreinformation
more information
information
gan &Cl
gan
visit
visitwww.morganclaypool.com
visit www.morganclaypool.com
www.morganclaypool.com
SSYNTHESIS
YNTHESIS L
YNTHESIS LECTURES
ECTURES ON
ECTURES ON
ON
&Claypool
&Cl
Mor
Morgan
Mor gan
gan &
&
&Cl
Claypool
Cl aypool Publishers
aypool Publishers
Publishers
ISBN:
ISBN: 978-1-60845-749-6
ISBN: 978-1-60845-749-6
978-1-60845-749-6
90000
90000
90000 H UMAN-C
HUMAN-
UMAN- ENTERED IINFORMATICS
CENTERED
ENTERED NFORMATICS
NFORMATICS
aypool
aypool
w
www
www
ww...m
mooorrrgggaaannnccclllaaayyypppoooooolll...cccooom
m m
m
9
99781608
781608457496
781608 457496
457496
John
JohnM.
John M.Carroll,
M. Carroll,Series
Carroll, SeriesEditor
Series Editor
Editor
Conceptual Models
Core to Good Design
Synthesis Lectures on
Human-Centered Informatics
Editor
John M. Carroll, Penn State University
Human-Centered Informatics (HCI) is the intersection of the cultural, the social, the cognitive,
and the aesthetic with computing and information technology. It encompasses a huge range of
issues, theories, technologies, designs, tools, environments and human experiences in knowledge
work, recreation and leisure activity, teaching and learning, and the potpourri of everyday life. The
series will publish state-of-the-art syntheses, case studies, and tutorials in key areas. It will share
the focus of leading international conferences in HCI.
Designing and Evaluating Usable Technology in Industrial Research: Three Case Studies
Clare-Marie Karat and John Karat
2010
iii
Interacting with Information
Ann Blandford and Simon Attfield
2010
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in
any form or by any means—electronic, mechanical, photocopy, recording, or any other except for brief quotations in
printed reviews, without the prior permission of the publisher.
DOI 10.2200/S00391ED1V01Y201111HCI012
Lecture #12
Series Editor: John M. Carroll, Penn State University
Series ISSN
Synthesis Lectures on Human-Centered Informatics
Print 1946-7680 Electronic 1946-7699
Conceptual Models
Core to Good Design
Jeff Johnson
UI Wizards, Inc.
Austin Henderson
Rivendel Consulting & Design
M
&C Morgan & cLaypool publishers
ABSTRACT
People make use of software applications in their activities, applying them as tools in carrying
out tasks. That this use should be good for people – easy, effective, efficient, and enjoyable – is
a principal goal of design. In this book, we present the notion of Conceptual Models, and argue
that Conceptual Models are core to achieving good design. From years of helping companies create
software applications, we have come to believe that building applications without Conceptual Models
is just asking for designs that will be confusing and difficult to learn, remember, and use.
We show how Conceptual Models are the central link between the elements involved in
application use: people’s tasks (task domains), the use of tools to perform the tasks, the conceptual
structure of those tools, the presentation of the conceptual model (i.e., the user interface), the language
used to describe it, its implementation, and the learning that people must do to use the application.
We further show that putting a Conceptual Model at the center of the design and development
process can pay rich dividends: designs that are simpler and mesh better with users’ tasks, avoidance
of unnecessary features, easier documentation, faster development, improved customer uptake, and
decreased need for training and customer support.
KEYWORDS
conceptual model, conceptual design, concepts, task-domain, tasks, tools, task-to-tool
mapping, object/operations analysis, interaction design, user interface design, applica-
tion design, software design, design, usability, software development method, software
development process
vii
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Using Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Task Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Task-to-tool Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Describing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Task-Based Descriptions of Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.2 Model-Based Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Seeing the Model Through the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 Implementation Architecture and Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.10 Mental Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.11 Conceptual Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 What a Conceptual Model Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 High-Level Description of an Application . . . . . . . . . . . . . . . . . . . . . . . . . . 17
viii
3.1.2 Basis for Users’ Understanding of the Application . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Close Relative: Information Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4 Summary: What a Conceptual Model Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 What a Conceptual Model Is Not . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Not Task-Level Scenarios or Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Not Users’ Mental Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Not a Design Metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.4 Not the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.5 Not the Implementation Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.6 Not Product Designer’s “Concept Design” . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Design Goals for Conceptual Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Task-Focused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Purpose & High-Level Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Major Concepts and Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Objects/Operations Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Declares Concepts that the Application will Expose . . . . . . . . . . . . . . . . . . 31
4.3.2 Introduces New Concepts, if Needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.3 Hides Concepts that Once Were Necessary but No Longer Are . . . . . . . . 32
4.3.4 Shows Relationships Between Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Example of Objects/Operation Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Conceptual Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Mapping from Task-Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 Overall Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 High-Level Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Major Concepts and Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4 Object-Operations Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4.1 Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4.2 Object-Operations Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5 Mapping: Task Hierarchy Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6 Resolved Conceptual Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7 Open Conceptual Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
ix
6 Essential Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1 Basic Object/Operations Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.1 Assign Operations and Attributes to Objects . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.2 Assign Operations to the Appropriate Object(s) . . . . . . . . . . . . . . . . . . . . . 49
6.1.3 Decide How to Model Similar Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.4 Decide Whether to Include the Generic Object Type . . . . . . . . . . . . . . . . . 51
6.1.5 Decide What Type of Values an Attribute Has . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.6 Decide How Detailed to be in Modeling Common Operations . . . . . . . . . 52
6.1.7 Include All Task-Relevant Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.8 Part-of and Containment Relationships Need Not Always be
Distinguished . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Supporting Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1 Metaphors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2 Progressive Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Component Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.4 Surrounding Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.5 Object-Oriented vs. Task-Oriented User Interfaces . . . . . . . . . . . . . . . . . . . 56
6.3 Conceptual Model vs. User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1 View vs. Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.2 Interactive Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4 Object Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.1 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.2 Synchronizing Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.3 Inheriting Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.4 What Work is Saved, When? And Can I Reverse It? . . . . . . . . . . . . . . . . . . 60
7 Optional Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1 Going Meta: Activity as Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.1 Managing Trouble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.2 Anticipating Trouble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.3 Macros: Capturing Work Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Evolving the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.1 Managed Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.2 Anticipated Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.4 Unanticipated Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2.5 Embedding in Social Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
x
8 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1 First Step of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.2 Start with User Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.3 The Conceptual Model Needs a Place at the Project Table . . . . . . . . . . . . . . . . . . . 72
8.3.1 Coordination is Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.3.2 One Team-member Should Drive the Conceptual Design . . . . . . . . . . . . . 73
8.3.3 Include Developers, but Keep the Conceptual Model Focused on Tasks . . 74
8.4 Use the Conceptual Model to Coordinate Development . . . . . . . . . . . . . . . . . . . . . 74
8.5 Representing Conceptual Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.6 Iterate, Iterate, Iterate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.7 Including Conceptual Models in Agile Development . . . . . . . . . . . . . . . . . . . . . . . 77
8.8 Testing Conceptual Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1 Produces a Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.2 Facilitates Creation of High-Level Task Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.3 Facilitates Creation of User Documentation, Training, and Support . . . . . . . . . . . 85
9.4 Focuses the User Interface Design: Gives Designers a Clear Target . . . . . . . . . . . . 86
9.5 Jump-Starts and Focuses the Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.6 Saves Time and Money . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10 Epilogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Authors’ Biographies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
xi
Preface
We have been interested in Conceptual Models for years. We both lived through the rough and
tumble days of inventing the future at Xerox and understand just how hard it has been for the
world to develop applications that work as well as they do. A continuing subject of discussion for all
concerned has been the “model of the system,” the view of the application that the designers hope
people will adopt when using the application.
Yet in all this time, there has been a lack of clarity about exactly what these models are. This is
not entirely surprising, seeing as there are so many different kinds of models, and modeling is such
an endemic effort in the development of systems.
For that reason, in 2002 we wrote an article for interactions magazine – a 2500 word attempt to
encourage designers to “begin by designing what to design”. In the intervening decade, we have re-
ceived sporadic reports that that article has been helpful to some designers and developers. However,
conceptual models do not seem to have become common in accepted practice.
We also noticed that our own interest in conceptual models continued to evolve. We realized
that there was much more to say than we said in the Interactions article. We felt that conceptual
models should be discussed more thoroughly and in a place that was readily available to all engaged
in developing applications or studying how to develop them.
This book is the result.
Acknowledgments
We thank Jack Carroll for offering to publish this in his “Human-Centered Informatics” series at
Morgan & Claypool. His encouragement has been supportive. We thank Diane Cerra for her help in
setting direction and managing the mechanics of this undertaking. We thank our colleagues Robin
Jeffries, Jon Meads, Susan Fowler, and Nigel Bevan for their helpful feedback on our first draft. We
also thank Jon Meads for allowing us to use two of his diagrams (Fig. 8.3 courtesy of Jon Meads,
copyright © 2011 Jon Meads). We thank those who helped edit and design this book.
Finally, we each have people we would like to acknowledge.
Austin Henderson: I want to acknowledge many people for conversations over the years that
have touched on conceptual models, particularly,Tom Moran, Stuart Card, John Rheinfrank, Shelley
Evenson, Don Norman, David Asano, Hugh Dubberly, Jed Harris and, of course, most centrally,
Jeff Johnson. I want to thank my wife Lynne for invaluable support and encouragement while this
work has been underway.
Jeff Johnson: I acknowledge the many insights I have gained as a result of discussions — and
arguments — about interaction design and conceptual models over the years with many colleagues
with whom I have worked: Robin Jeffries, Bonnie Nardi, Steve Whittaker, Terry Roberts, Chuck
Clanton, Stuart Card, and of course, Austin Henderson. I also acknowledge the support and patience
of my wife Karen Ande as this book was being written.
Introduction
This book presents and argues that a good Conceptual Model (CM) should be at the core of
the design of every artifact that people use to help them get their work done. This includes software
products, electronic appliances, and web services, but also products more generally and even human
services1 .
Those unfamiliar with interaction design often consider it to be designing the user interface
or “skin” of an application: the controls, displays, error messages, use of colors, layout, etc. However,
the interaction design for an application is more than just the controls, displays, etc. that comprise
its user interface. The interaction design goes deeper than the skin: it includes all concepts that the
application’s user interface exposes to users, and it includes the sequences of operations that users
execute to accomplish the application’s supported tasks. The interaction design has roots that extend
deep into an application’s architecture and implementation — including into any back-end services
the application uses. Thus, an interaction design consists of concepts, task-flow, and presentation.
A key part of interaction design is creating a conceptual model of an application. The purpose
of conceptual design — of creating a conceptual model — is to get the concepts and their rela-
tionships right, to enable the desired task-flow. Obviously, it makes sense to get the concepts and
their relationships right before designing how those concepts will be implemented or presented. In
other words, start by designing how the user would ideally think about the application and its use in
supporting tasks. Indeed, shape the whole development process around creating and delivering a
good conceptual model.
A FEW EXAMPLES
Let’s consider examples of conceptual models. Here are a number of possible pairs of alternative
conceptual models, any of which could be quite acceptable given different circumstances. However,
the designer must choose one of them (or invent yet another alternative) because these alternative
conceptual models are incompatible.
Assume you are designing the following:
1 For simplicity, this book uses the term “application” to cover all such technologies.
2 INTRODUCTION
• An application for creating newsletters. Is a newsletter:
a) a list of items, or
b) a set of pages, each with layout of items?
a) a list of days, or
b) a list of events?
• helps focus the design of the application by coupling the design to the tasks that the
user is doing;
• supports having a good process for developing that design into a product; and
Since the design, process, and experience of use are all informed by the conceptual model, these all
feed off each other and grow together.
ORGANIZATION
The book is organized as follows. (Please see the figure on page 3.)
Chapters 1 and 2 set the context within which conceptual models are important. Chapter 1
(Using Tools) reviews the role of tools in helping people to get work done. It introduces key concepts
and terms (e.g., task domain, task, application, mental model, conceptual model, user interface,
implementation). With the place of tools established, Chapter 2 (Start with the Conceptual Model)
provides sketches of several alternative ways that people carry out design, starting with the task, the
user interface, or the implementation; instead it is argued that the place to start is by designing the
conceptual model.
These initial two chapters are intended to provide those new to the design of tools with
sufficient background knowledge to understand the rest of the book. Those experienced in the
theory and/or practice of designing tools may want to skip Chapters 1 and 2 and start with Chapter 3.
However, first they may want to check how our terms align with those with which they are familiar.
INTRODUCTION 3
Chapters 1-2. Context of CMs: Designing
tools to help people get tasks done:
1. Using tools to do work; 1. 2.
Using Start with
2. Where to start design. tools the CM
of design: 6. 7. 8. 9.
6. Essential modeling issues; Essential Optional Process Value
Modeling Modeling
7. Optional modeling issues;
8. Recommended processes;
9. Value of CMs.
Chapters 3 – 5 explain what conceptual models are. Chapter 3 (Definition) introduces concep-
tual models and the purpose they serve. Chapter 4 (Structure) describes how they are structured (ob-
jects/attributes/operations) and some common ways of denoting them (e.g., UML, concept maps).
Both Chapters 3 and 4 are filled with parts of examples. Chapter 5 (Example) provides a much
more complete, and so larger, worked example. Most readers will want to focus on Chapter 4, with
Chapters 3 and 5 providing scaffolding.
Chapters 6 – 9 discuss building and using conceptual models. Chapter 6 (Essential Modeling)
describes how common configurations of concepts (e.g., types, specialization) can be expressed using
the objects/attributes/operations structure of conceptual models. Chapter 7 (Optional Modeling)
raises some advanced issues that designers may choose to address in their conceptual models. Chap-
ter 8 (Process) discusses how the conceptual model can and should play a continuing role in enabling
the many perspectives on a design to create and maintain alignment with each other throughout the
course of the development of tools. Chapter 9 (Value) discusses the benefits that conceptual models
can bring to the development of tools, and therefore to users in their work of getting their tasks
done.
Exploring the Variety of Random
Documents with Different Content
EMILY BRONTË.
What sacramental hurt that brings
The terror of the truth of things,
Had changed thee? Secret be it yet.
’Twas thine, upon a headland set,
To view no isles of man’s delight
With lyric foam in rainbow flight,
But all a-swing, a-gleam, mid slow uproar,
Black sea, and curved uncouth sea-bitten shore.
PAX PAGANICA.
By A. E. HOUSMAN.
A SHROPSHIRE LAD. Fcap. 8vo, cloth, 3s. 6d. net.
By ALICE MEYNELL.
THE FLOWER OF THE MIND: A Choice among the best Poems. With
Cover designed by Laurence Housman. Crown 8vo, yapped
parchment, 7s. 6d.
By LAURENCE HOUSMAN.
SPIKENARD: A Book of Devotional Love Poems. With Cover designed by
the Author. Small 4to, boards, 3s. 6d. net.
By LAURENCE BINYON.
PORPHYRION AND OTHER POEMS. Crown 8vo, buckram, 5s. net.
By RICHARD LE GALLIENNE.
RUBAIYAT OF OMAR KHAYYĀM: A Paraphrase from several Literal
Translations. Long fcap. 8vo, parchment cover, 5s.
By LAURENCE ALMA-TADEMA.
REALMS OF UNKNOWN KINGS: Poems. Fcap. 8vo, buckram, 3s. net;
paper covers, 2s. net.
By LOUISA SHORE.
HANNIBAL: A Drama in Two Parts. With Photogravure Portrait of the
Author. Crown 8vo, cloth, 5s. net.
By EUGENE LEE-HAMILTON.
THE INFERNO OF DANTE TRANSLATED INTO ENGLISH VERSE. Fcap.
8vo, half parchment, 5s. net.
By MAURICE MAETERLINCK.
AGLAVAINE AND SELYSETTE: A Drama in Five Acts. Translated by
Alfred Sutro. With an Introduction by W. J. Mackail, and Title-
page designed by W. H. Margetson. Globe 8vo, half buckram,
2s. 6d. net.
————————
GRANT RICHARDS,
9, HENRIETTA STREET, COVENT GARDEN, W.C.
*** END OF THE PROJECT GUTENBERG EBOOK "ENGLAND AND
YESTERDAY": A BOOK OF SHORT POEMS ***
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must,
at no additional cost, fee or expense to the user, provide a copy,
a means of exporting a copy, or a means of obtaining a copy
upon request, of the work in its original “Plain Vanilla ASCII” or
other form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.
• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”
• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.
1.F.
Most people start at our website which has the main PG search
facility: www.gutenberg.org.
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
ebooknice.com