Re: [unrev-II] Simon's Paper

From: Eric Armstrong (
Date: Mon Oct 22 2001 - 13:14:45 PDT

  • Next message: "Re: [unrev-II] readings list for engelbart issues class?"

    Yup. It's there.

    Gil Regev wrote:

    > Eric,Thanks for the review. What is the title of the paper? Maybe it
    > is on the Web already. Can you find it at this address (KMI tech.
    > reports)?
    > -----Original Message-----
    > From: Eric Armstrong []
    > Sent: vendredi, 19. octobre 2001 21:30
    > To: unrev2
    > Subject: [unrev-II] Simon's Paper
    > Simon wrote a highly thought-provoking paper, which
    > I tried to attach, but Yahoo groups rejected it as
    > too big. Below are the notes I sent him on it.
    > Simon:
    > Perhaps you can make it available on the web
    > somewhere, or send it to folks who request it.
    > Notes
    > -----
    > * "DR" stands for Design Rationale system.
    > * The paper begins on page 603
    > Over all comment
    > ------------------
    > Extremely good and provocative paper.
    > p. 604
    > -------
    > So far, I like the approach and the decision to evaluate
    > claims
    > that are being made. Good idea. But...
    > There is a need to distinguish between capturing DR (why)
    > and
    > capturing the process by which design decisions are made.
    > The
    > process-history is of interest the psychologist and design
    > anthropologists -- who want to understand the mechanisms by
    > which decisions were made, who decided, and what information
    > the decsions was based on.
    > The engineer/design-archaeologist only wants to know why
    > people did what they did -- or, at least, what they thought
    > the
    > reasons were at the time. From a practical standpoint, the
    > question of *how* decisions were reached is of no
    > consequence.
    > I'm feeling a sense on this page that those two aspects of
    > DR are
    > not being distinguished. It may not matter, for the purposes
    > of
    > the paper, Or it may be huge. I'll have a better idea when I
    > see
    > where the paper is headed.
    > (Granted, some times the notions merge. "We tried this, and
    > then
    > we tried that, and none of those approches worked, so we
    > settled
    > on thus-and-so, which combines some of the features of
    > each...",
    > and notes to that effect, constitute a historical rationale.
    > But the
    > argument need not be a "how". It could simply consist of
    > evaluations
    > of the first, second, and third approaches.)
    > pp. 605-611
    > -------------
    > Great survey of who-has-done-what.
    > pp. 612-613
    > -------------
    > Brilliant analysis of the kinds of claims being made, and
    > the types
    > of evidence being adduced. I'm looking forward to reading
    > further.
    > pp. 614-616
    > -------------
    > I'm not sure how useful the evaluation of legal
    > argumentation
    > methodologies is to evaluating the potential for DR
    > structures.
    > The legal domain is totally "unbounded". Every case stands
    > by
    > itself, and it is extremely difficult to extract
    > generalitites which
    > can be usefully applied elsewhere. The problems that noted
    > the
    > results were not easily penetrable by others, and not that
    > helpful in clarifying the designer's thinking are, for that
    > reason,
    > less useful indicators of the possibilities inherent in the
    > methodology.
    > In design, the issues are more restricted, and the cases
    > more
    > bounded. It is therefore reasonable to expect that the
    > symbols,
    > patterns, and understandings gained from one design will be
    > applicable in another area. In other words, over time one
    > could
    > build up a argumentation/design vocabulary that would be
    > usefully
    > applied in new contexts, and which would help you "read" the
    > DR that others had constructed. (In law, by contrast, if you
    > hadn't
    > constructed it yourself, you probably wouldn't be able to
    > read it.)
    > pp. 632-633
    > -------------
    > I have to agree that premature structuring and cognitive
    > overhead
    > are major issues with any tool that is devoted to capturing
    > and
    > clarifying thought. Done badly, the solution can appear to
    > be worse
    > than the problem.
    > However, I don't believe that the inadequacy of the tool is
    > a valid
    > argument against the method. As an example, I would cite
    > outlines.
    > Prior to computers, outlining technique was taught in
    > schools. Some
    > of us loved them. Most students hated them. The reason
    > became
    > apparent many years later, when I constructed one of the
    > first
    > outlining programs ever written. (It was in Basic, and it
    > was extremely
    > minimal, but it predated ThinkTank by a year or more.)
    > In that process, and in the process of working with the
    > production
    > outliner I and my cohorts subsequently developed, I
    > discovered that
    > the outliner's truth strength lay in the ability to
    > RE-organize
    > material.
    > It became clear that the issue with outlines as a
    > thought-organizing
    > tool derived from the "concrete" nature of the pen and paper
    > medium. Those of us with "logical minds", and the ability to
    > try out
    > several organzational schemes in our head, loved outline
    > structures.
    > The vast majority didn't, because it never came out right,
    > and was
    > impossible to change afterwards.
    > With a computerized outlining tool at my service, I found
    > myself
    > tackling larger problems, easily shifting things about as
    > new organizing
    > principles occured to me.
    > To bring the moral home, those pen and paper outlines
    > imposed the
    > induced "premature structuring". In a more maleable medium,
    > any
    > starting organization was as good as any other, due to the
    > ease of
    > rearranging material.
    > >From the standpoint of cognitive overhead, such
    > hierarchical structures
    > are useful precisely because they allow one to "divide and
    > conquer"
    > the problem. They also make it easy to see the big picture,
    > so you
    > know what the major categories are, and then dive deep into
    > any
    > given area to deal with the details.
    > A realistically usable DR must retain those advantages. I
    > have written
    > elsewhere on how graphic hierarchies have to work to provide
    > the
    > same advantages (via nesting). Very few extant systems
    > operate in
    > that way, so it is no surprise to me that no graphical
    > representation
    > remains useful once a problem gets complex.
    > More importantantly, I contend that the major goal of DR
    > system
    > should be to *derive* organization over time, and to record
    > the
    > final state of the organization, with a record of the
    > justifications for
    > each design decision. (Again, I see a difference between the
    > historical
    > approach that shows how you got there, and rationale
    > recording,
    > that simply describes your reasoning, without going into
    > detail on
    > the experiences that led you to those conclusions. Some
    > folks favor
    > the former, and I agree it would be useful, as long as the
    > additional
    > detail
    > can remain hidden until it is needed. But in terms of
    > practicality, I
    > believe that only the latter is needed for the vast majority
    > of
    > projects.)
    > p. 637
    > -------
    > A really important point mentioned here. One that is worth
    > highlighting.
    > The Design Loop.
    > raw problem --> micro problem --> design
    > alternatives
    > This is an aspect that the hierarchical structures I'm used
    > to are
    > miserable for. There really needs to be a loop, where you
    > drill
    > down solving problems, and then leap up to pose new
    > alternatives,
    > each of which are linked to the problem(s) they solve.
    > Given a rich set of interlinking information, it should even
    > be possible
    > for a *computer* to select the most elegant solution,
    > defined as
    > the minimal set of alternatives that cover all of the known
    > problems.
    > (Note: That "minimal" could be defined in terms of nodes, or
    > it
    > be the product of some metric attached to each node, such as
    > a
    > time estimate for completion. A business-elegant solution
    > might
    > therefore minimize the time-to-complete, while a
    > technology-elegant
    > solution would minimize the number of nodes in the solution
    > set.
    > Example: Modules A, B, C already exist and could be applied
    > to
    > solve the problem in one-day each. Or Module D could be
    > created
    > in 4 days, and combined with an unchanged module C to solve
    > the problem. The business elegant solution is A'+B'+C', for
    > a total
    > of 3 days. The technology-elegant solution is D+C, for a
    > total of
    > 4 days.
    > p. 637
    > -------
    > Good detailed feedback on the frustrations of using IBIS and
    > gIBIS
    > at the bottom of this page.
    > p. 639
    > -------
    > A good checklist for constructing a design represenation
    > language.
    > Conclusion
    > -----------
    > All in all, an excellent paper that challenges many
    > unquestioned
    > assumptions. A worthwhile read.
    > Community email addresses:
    > Post message:
    > Subscribe:
    > Unsubscribe:
    > List owner:
    > Shortcut URL to this page:
    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
    > Service.
    > Yahoo! Groups Sponsor

      [Choose from 1000s of job listings!]

                  Choose from 1000s of job listings!

    > Community email addresses:
    > Post message:
    > Subscribe:
    > Unsubscribe:
    > List owner:
    > Shortcut URL to this page:
    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
    Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    This archive was generated by hypermail 2.0.0 : Mon Oct 22 2001 - 13:01:43 PDT