Design and Domain-Oriented Design Environments

pdf version

Design and Domain-Oriented Design Environments

Gerhard Fischer, Hal Eden, and Holger Dick — Fall Semester 2010

gerhard@colorado.edu; haleden@colorado.edu; holger.dick@gmail.com;  

September 20, 2010

paper: Fischer, G. (1994) "Domain-Oriented Design Environments," Automated Software Engineering, 1(2), pp. 177-203. plus commentaries and reply

Overview

• Design

• Domain-Oriented Design Environments (DODEs)

• Examples

• video-tape of Janus: a DODE for kitchen design

• Critiquing in DODEs

• reflection-in-action
• intrusiveness
• generic, specific, interpretive critics

Design

• a fundamental and important objective:

• Karl Marx: “Die Philosophen haben die Welt nur verschieden interpretiert; es kommt aber darauf an, sie zu verändern!” (Entrance Hall of the Humboldt University in Berlin)
• in English: “Philosophers interpret the world in various ways; what matters is to change it!”

• design as a concept / an activity

• poorly understood
• used differently by different people and different communities

• Herbert Simon’s “Sciences of the Artificial”

• natural sciences: how things are ? understand what is
• design: how things ought to be ? shape what will be
• design = “everyone designs who devises courses of action aimed at changing existing situations into preferred ones”

Different Discourse

• natural science:

• understanding the physical world: natural scientists are given a universe and seek to discover its laws
• in the natural sciences there are right and wrong answers
• studies tame problems

• design:

• computer scientists create worlds in the form of programs and the computer brings these worlds to life
• studies ill-defined, wicked problems

• integration of problem framing and problem solving
• problems have no stopping rule

• trade-offs (e.g.: simplicity ?? complexity) ? problems have no single answer (argumentation support is required)
• there are no best, optimal solutions ? satisfycing

Design Domains

• software design and software engineering

• architecture and urban design

• design in the creative arts

• design of learning environments

• design of collaboration environments

SchemePaint (Michael Eisenberg): a programmable application combining direct manipulation with interactive programming

Example: Crafts Technology — Hypergami
(Michael Eisenberg)

Example: Google SketchUp & 3D Warehouse (2009 Inaugural Stage)
(guest lecture: John Bacus)

Example: Design Kits
(general purpose ?? special purpose)

Example: Architecture

Example: Architecture

Software Design / Engineering: Upstream and Downstream Activities

• upstream: world ? model / specification

• ill-defined problem
• integration of problem framing and problem solving
• collaboration and communication between different stakeholders
• failure leads to design disasters (wrong problem is solved)

• downstream: model / specification ? implementation / system

• well-defined problem
• dealing with difficult technical problems
• creating reliable code
• failure leads to implementation disasters (wrong solution to the right problem)

Design: Beyond Binary Choices

• Turing Tar Pit: “Beware of the Turing Tar Pit, in which everything is possible, but nothing of interest is easy.”  

• level of representation is too far removed from the conceptual world of the domain workers
• claim: they emphasize objective computability ? the challenge: subjective computability

• The Inverse of the Turing Tar Pit: “Beware of the over-specialized systems, where operations are easy, but little of interest is possible.”

• domain-specific tools (such as SimCity) provide extensive support for certain problem contexts
• the ability to extend these environments is limited — even minor incremental changes are often impossible in these systems

Domain-Oriented Design Environments

• rationale:

• recognize the legitimacy of specialization to a domain — do not serve all needs obscurely, serve a few needs well
• support Human Problem-Domain Interaction

Human Problem Domain Interaction — Pinball Construction Kit

Human Problem Domain Interaction — Music Construction Kit

Examples of Domain-Oriented Design Environments

• kitchen design

• voice dialog design

• computer network design

• urban design and transportation planning — Envision and Discovery Collaboratory (EDC)

• multi-media design (color)

• website design

Domain-Oriented Design Environments (Janus-Construction)

Janus-Argumentation

The Multi-Faceted Architecture behind DODEs

Domain-Oriented Design Environments (DODEs)

Reflection-in-Action as a Problem Solving Theory

Movie: The Janus DODE

VDDE: Voice Dialog Design Environment

Computer Network Design

Computational Critics (= “Virtual Human Critics”)

• spelling correctors — example of a “simple” critiquing system

• simple: a “correct” answer exists
• passive ?? active
• suggestions for corrections ?? “auto-correct” in MS-Word

• unlimited opportunities for application: grammar checkers, color critics, graphs critics, webpage critics

• webpage critics and universal access

• http://analyze.websiteoptimization.com/
• http://validator.w3.org/

The Rationale / Need for Critiquing

• color ?Travis, D. (1991) Effective Color Displays—Theory and Practice, Academic Press, London:

• “but when color is used inappropriately it can be very counter productive and few software designers have much experience with the use of color; the aim of this book is to synthesize our current knowledge in the area and specify guidelines so that programmers, engineers, and psychologist can use color.”
• question: what are the benefits of “critiquing systems” compared to “guidelines”

• graphs ?  Kosslyn, S. M. (1994) Elements of Graph Design, W.H. Freeman and Company, New York

• “one reason for the abundance of bad graphs is the proliferation of low-cost microcomputers and ‘business graphics’ packages which often seduce the user into producing flashy but muddled displays; many graphs are designed without consideration of principles of human perception and cognition”
• question: can a critiquing system be developed for “human perception and cognition”

EMMA (Environment for MultiMedia Authoring) and Color Critiquing

Computer-Based Critiquing: Examples and Mechanisms

• examples:

• the length of the work triangle is more than 23 feet
• a critiquing rule in the Envisionment and Discovery Collaboratory: “the maximum distance between two bus stops is 1mile”

• mechanism:

• enable relevant critics
• analyze construction and specification (e.g., the specification states that this is a part of town where many old people live)
• signal breakdowns
• deliver relevant knowledge
• identify the right level of intrusiveness:
  on demand ?? critical points (“windows in Janus”) ?? all the time (MS Word)

Giving Domain Designers Control about the Intrusiveness of Critics

An Implementation of Critics

Embedding Critics in the Contexts of Design

Generic Critics in Construction

A Partial Specification of a Specific Client

questions in answers by client:

specification component

• name: Smith’s kitchen
• size of family: four to six
• primary cook: left-handed
• size of meals: huge (big eaters)
• entertainment: often
• cooking frequency: often
• type of sink: double bowl sink

specification component in EDC: questionnaire for citizens how long they would wait for the bus

Global Objective of Embedding Critics

• increase the “back-talk” of the situation

• support reflection-in-action

• support learning on demand

• reduce information overload: saying the ‘right’ thing at the ‘right’ time in the ‘right’ way to the ‘right’ person

• make information relevant to the task at hand