Yup. It's there.
Abstract: http://kmi.open.ac.uk/tr/abstracts/kmi-tr-21.html
PostScript: http://kmi.open.ac.uk/tr/papers/kmi-tr-21.ps.gz
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)?http://kmi.open.ac.uk/publications/techreports-text.cfmGil
>
> -----Original Message-----
> From: Eric Armstrong [mailto:eric.armstrong@sun.com]
> 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: unrev-II@onelist.com
> Subscribe: unrev-II-subscribe@onelist.com
> Unsubscribe: unrev-II-unsubscribe@onelist.com
> List owner: unrev-II-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/unrev-II
>
> 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: unrev-II@onelist.com
> Subscribe: unrev-II-subscribe@onelist.com
> Unsubscribe: unrev-II-unsubscribe@onelist.com
> List owner: unrev-II-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/unrev-II
>
> 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!
http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/IHFolB/TM
---------------------------------------------------------------------~->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Mon Oct 22 2001 - 13:01:43 PDT