Central Library, Indian Institute of Technology Delhi
केंद्रीय पुस्तकालय, भारतीय प्रौद्योगिकी संस्थान दिल्ली

Conceptual models [electronic resource] : core to good design / Jeff Johnson, Austin Henderson.

By: Johnson, Jeff, Ph. DContributor(s): Henderson, AustinMaterial type: TextTextSeries: Synthesis digital library of engineering and computer science | Synthesis lectures on human-centered informatics ; # 12.Publication details: San Rafael, Calif. (1537 Fourth Street, San Rafael, CA 94901 USA) :: Morgan & Claypool,, c2012Description: 1 electronic text (xiii, 96 p.) : ill., digital fileISBN: 9781608457502 (electronic bk.)Subject(s): Conceptual structures (Information theory) | Computer programs -- Design | User interfaces (Computer systems) -- Design | conceptual model | conceptual design | concepts | task-domain | tasks | tools | task-to-tool mapping | object/operations analysis | interaction design | user interface design | application design | software design | design | usability | software development method | software development processAdditional physical formats: Print version:: No titleDDC classification: 003.54 LOC classification: Q387.2 | .J643 2012Online resources: Abstract with links to resource Also available in print.
Contents:
Preface -- Acknowledgments -- Introduction --
1. Using tools -- 1.1 Activity -- 1.2 Tasks -- 1.3 Task domains -- 1.4 Tools -- 1.5 Function -- 1.6 Task-to-tool mapping -- 1.7 Describing tools -- 1.7.1 Task-based descriptions of tools -- 1.7.2 Model-based descriptions -- 1.8 Seeing the model through the user interface -- 1.9 Implementation architecture and implementations -- 1.10 Mental models -- 1.11 Conceptual models --
2. Start with the conceptual model -- 2.1 Design (and implement) functionality? -- 2.2 Duplicate the existing activity? -- 2.3 Design (sketch) the user interface? -- 2.4 Start with conceptual design -- 2.5 Important decisions -- 2.6 Conceptual design's place in software development --
3. Definition -- 3.1 What a conceptual model is -- 3.1.1 High-level description of an application -- 3.1.2 Basis for users' understanding of the application -- 3.1.3 Close relative: information architecture -- 3.1.4 Summary: what a conceptual model is -- 3.2 What a conceptual model is not -- 3.2.1 Not task-level scenarios or use cases -- 3.2.2 Not users' mental model -- 3.2.3 Not a design metaphor -- 3.2.4 Not the user interface -- 3.2.5 Not the implementation architecture -- 3.2.6 Not product designer's "Concept design" -- 3.3 Design goals for conceptual models -- 3.3.1 Simple -- 3.3.2 Task-focused --
4. Structure -- 4.1 Purpose & high-level functionality -- 4.2 Major concepts and vocabulary -- 4.3 Objects/operations analysis -- 4.3.1 Declares concepts that the application will expose -- 4.3.2 Introduces new concepts, if needed -- 4.3.3 Hides concepts that once were necessary but no longer are -- 4.3.4 Shows relationships between concepts -- 4.4 Example of objects/operation analysis -- 4.5 Conceptual design issues -- 4.6 Mapping from task-domain --
5. Example -- 5.1 Overall purpose -- 5.2 High-level functionality -- 5.3 Major concepts and vocabulary -- 5.4 Object-operations analysis -- 5.4.1 Formatting conventions -- 5.4.2 Object-operations hierarchy -- 5.5 Mapping: task hierarchy enumeration -- 5.6 Resolved conceptual design issues -- 5.7 Open conceptual design issues --
6. Essential modeling -- 6.1 Basic object/operations analysis -- 6.1.1 Assign operations and attributes to objects -- 6.1.2 Assign operations to the appropriate object(s) -- 6.1.3 Decide how to model similar objects -- 6.1.4 Decide whether to include the generic object type -- 6.1.5 Decide what type of values an attribute has -- 6.1.6 Decide how detailed to be in modeling common operations -- 6.1.7 Include all task-relevant operations -- 6.1.8 Part-of and containment relationships need not always be distinguished -- 6.2 Supporting learning -- 6.2.1 Metaphors -- 6.2.2 Progressive disclosure -- 6.2.3 Component models -- 6.2.4 Surrounding models -- 6.2.5 Object-oriented vs.task-oriented user interfaces -- 6.3 Conceptual model vs. user interface -- 6.3.1 View vs. focus -- 6.3.2 Interactive concepts -- 6.4 Object identity -- 6.4.1 Containment -- 6.4.2 Synchronizing objects -- 6.4.3 Inheriting attributes -- 6.4.4 What work is saved,when? And can I reverse it? --
7. Optional modeling -- 7.1 Going meta: activity as objects -- 7.1.1 Managing trouble -- 7.1.2 Anticipating trouble -- 7.1.3 Macros: capturing work activity -- 7.2 Evolving the application -- 7.2.1 Managed growth -- 7.2.2 Anticipated growth -- 7.2.3 Versioning -- 7.2.4 Unanticipated growth -- 7.2.5 Embedding in social domains --
8. Process -- 8.1 First step of design -- 8.2 Start with user research -- 8.3 The conceptual model needs a place at the project table -- 8.3.1 Coordination is required -- 8.3.2 One team-member should drive the conceptual design -- 8.3.3 Include developers, but keep the conceptual model focused on tasks -- 8.4 Use the conceptual model to coordinate development -- 8.5 Representing conceptual models -- 8.6 Iterate, iterate, iterate -- 8.7 Including conceptual models in agile development -- 8.8 Testing conceptual models --
9. Value -- 9.1 Produces a vocabulary -- 9.2 Facilitates creation of high-level task scenarios -- 9.3 Facilitates creation of user documentation, training, and support -- 9.4 Focuses the user interface design: gives designers a clear target -- 9.5 Jump-starts and focuses the implementation -- 9.6 Saves time and money --
10. Epilogue -- Bibliography -- Authors' biographies.
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.
Tags from this library: No tags from this library for this title. Log in to add tags.
Star ratings
    Average rating: 0.0 (0 votes)
Holdings
Item type Current library Call number Status Date due Barcode
Ebooks Ebooks Indian Institute of Technology Delhi - Central Library
Available

Mode of access: World Wide Web.

System requirements: Adobe Acrobat Reader.

Part of: Synthesis digital library of engineering and computer science.

Series from website.

Includes bibliographical references (p. 91-93).

Preface -- Acknowledgments -- Introduction --

1. Using tools -- 1.1 Activity -- 1.2 Tasks -- 1.3 Task domains -- 1.4 Tools -- 1.5 Function -- 1.6 Task-to-tool mapping -- 1.7 Describing tools -- 1.7.1 Task-based descriptions of tools -- 1.7.2 Model-based descriptions -- 1.8 Seeing the model through the user interface -- 1.9 Implementation architecture and implementations -- 1.10 Mental models -- 1.11 Conceptual models --

2. Start with the conceptual model -- 2.1 Design (and implement) functionality? -- 2.2 Duplicate the existing activity? -- 2.3 Design (sketch) the user interface? -- 2.4 Start with conceptual design -- 2.5 Important decisions -- 2.6 Conceptual design's place in software development --

3. Definition -- 3.1 What a conceptual model is -- 3.1.1 High-level description of an application -- 3.1.2 Basis for users' understanding of the application -- 3.1.3 Close relative: information architecture -- 3.1.4 Summary: what a conceptual model is -- 3.2 What a conceptual model is not -- 3.2.1 Not task-level scenarios or use cases -- 3.2.2 Not users' mental model -- 3.2.3 Not a design metaphor -- 3.2.4 Not the user interface -- 3.2.5 Not the implementation architecture -- 3.2.6 Not product designer's "Concept design" -- 3.3 Design goals for conceptual models -- 3.3.1 Simple -- 3.3.2 Task-focused --

4. Structure -- 4.1 Purpose & high-level functionality -- 4.2 Major concepts and vocabulary -- 4.3 Objects/operations analysis -- 4.3.1 Declares concepts that the application will expose -- 4.3.2 Introduces new concepts, if needed -- 4.3.3 Hides concepts that once were necessary but no longer are -- 4.3.4 Shows relationships between concepts -- 4.4 Example of objects/operation analysis -- 4.5 Conceptual design issues -- 4.6 Mapping from task-domain --

5. Example -- 5.1 Overall purpose -- 5.2 High-level functionality -- 5.3 Major concepts and vocabulary -- 5.4 Object-operations analysis -- 5.4.1 Formatting conventions -- 5.4.2 Object-operations hierarchy -- 5.5 Mapping: task hierarchy enumeration -- 5.6 Resolved conceptual design issues -- 5.7 Open conceptual design issues --

6. Essential modeling -- 6.1 Basic object/operations analysis -- 6.1.1 Assign operations and attributes to objects -- 6.1.2 Assign operations to the appropriate object(s) -- 6.1.3 Decide how to model similar objects -- 6.1.4 Decide whether to include the generic object type -- 6.1.5 Decide what type of values an attribute has -- 6.1.6 Decide how detailed to be in modeling common operations -- 6.1.7 Include all task-relevant operations -- 6.1.8 Part-of and containment relationships need not always be distinguished -- 6.2 Supporting learning -- 6.2.1 Metaphors -- 6.2.2 Progressive disclosure -- 6.2.3 Component models -- 6.2.4 Surrounding models -- 6.2.5 Object-oriented vs.task-oriented user interfaces -- 6.3 Conceptual model vs. user interface -- 6.3.1 View vs. focus -- 6.3.2 Interactive concepts -- 6.4 Object identity -- 6.4.1 Containment -- 6.4.2 Synchronizing objects -- 6.4.3 Inheriting attributes -- 6.4.4 What work is saved,when? And can I reverse it? --

7. Optional modeling -- 7.1 Going meta: activity as objects -- 7.1.1 Managing trouble -- 7.1.2 Anticipating trouble -- 7.1.3 Macros: capturing work activity -- 7.2 Evolving the application -- 7.2.1 Managed growth -- 7.2.2 Anticipated growth -- 7.2.3 Versioning -- 7.2.4 Unanticipated growth -- 7.2.5 Embedding in social domains --

8. Process -- 8.1 First step of design -- 8.2 Start with user research -- 8.3 The conceptual model needs a place at the project table -- 8.3.1 Coordination is required -- 8.3.2 One team-member should drive the conceptual design -- 8.3.3 Include developers, but keep the conceptual model focused on tasks -- 8.4 Use the conceptual model to coordinate development -- 8.5 Representing conceptual models -- 8.6 Iterate, iterate, iterate -- 8.7 Including conceptual models in agile development -- 8.8 Testing conceptual models --

9. Value -- 9.1 Produces a vocabulary -- 9.2 Facilitates creation of high-level task scenarios -- 9.3 Facilitates creation of user documentation, training, and support -- 9.4 Focuses the user interface design: gives designers a clear target -- 9.5 Jump-starts and focuses the implementation -- 9.6 Saves time and money --

10. Epilogue -- Bibliography -- Authors' biographies.

Abstract freely available; full-text restricted to subscribers or individual document purchasers.

Compendex

INSPEC

Google scholar

Google book search

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.

Also available in print.

Title from PDF t.p. (viewed on December 17, 2011).

There are no comments on this title.

to post a comment.
Copyright © 2022 Central Library, Indian Institute of Technology Delhi. All Rights Reserved.

Powered by Koha