[Offlist] (01)
I'm sending this offlist because I'm not the sort who is capable of
bragging in public, but I think you ought to look at (i.e. compile, run
and play with, view code) the last iteration of my OTMBuilder for some
basic Java code for this DIBS thing.
http://www.concept67.net/openthemic/openthemicmaps/otmb_v022a_source-2005-03-19.zip
(it requires XMLPullParser 3 or higher on the classpath:
http://www.extreme.indiana.edu/xgws/xsoap/xpp/ ) (02)
Jack and I hacked a Java WebQuestMapper tool that did collaborative IBIS
over Jabber, it didn't have the interface depth mechanism of OTM though
- it was only one diagram deep, though we did discuss a mechanism like
OTM has. But we did manage to get a collaborative session working just
by passing move, create, delete, edit signals for the graph back and
forth in very simple terms.
I have that WQM code on a backup CD somewhere...
Combining the two might give you a lot of what you want, minus the rules
for correct DIBS graphs. (03)
Cheers,
Peter (04)
Eric Armstrong wrote:
> Thanks for the comments, John.
> I understand that you need to force yourself
> to be out of the loop a while. This stuff is
> seductive. There's nothing I'd rather be working
> on, so I spent yesterday putting the article
> together instead of getting my work done! (I
> can only afford so much of that. :_)
>
> A few short responses:
> * Question-Asking Process
> * Typo
> * Refinements
> * Evaluation Strategy
> * Node Types
> * Extensions
>
> Question-Asking Process
> -----------------------
> You are right about needing a process that helps
> you to "ask the right question". That's the kind
> of problem that facilitated IBIS excels at.
>
> The trick is carry on those discussions online,
> reach an agreement, and then *bury* the dialog, with
> a link to it so the reasons can be examined when
> desired.
>
> That's one aspect of the problem that is glossed
> over in the current version of the tutorial.
>
> Typo
> ----
> Thanks for the catch:
> >
> > because the system doesn't __allow_ "illegal"
> > states , even temporarily.
> >
>
> Refinements
> -----------
> Thanks for the other ideas, as well. Would that we
> had the system in operation, so we could capture
> them in context as alternatives the ideas I've proposed!
>
> The most important thing for the design, though, is
> that you've suggested some refinements and alternatives
> that I would have a hard time capturing in the system,
> as currently spec'd.
>
> It's part of the "reaching agreement" issue,
> because your suggestions bring into question features
> of the proposal. More accurately, they bring to
> light questions that should have been asked in the
> original version.
>
> It's the moral of the IBIS story: Any "answer" (statement)
> is in reality an "alternative"--one of potentially many
> possible answers to a question that was never asked.
> IBIS makes sure that the question gets asked, as you
> have done here.
>
> I've got to think about two things:
>
> a) How to integrate your suggestions into the
> proposal, and
>
> b) How to modify the design so they have a
> "natural home".
>
> Evaluation Strategy
> -------------------
> My initial reaction is that the kind of evaluation
> strategy you suggest is something that should
> operate outside the system--which would allow
> other strategies to be plugged in and used.
>
> That's an off-the-cuff reaction, though. We
> definitely need more discussion of the pros and
> cons.
>
> Node Types
> ----------
> A node should definitely be limited to a single
> idea. It was the observation that a paragraph is
> supposed to represent a single idea that led to
> the concept of "NodeIDs", where each "node" is a
> heading or paragraph in a purplized document.
>
> I like your outline of node types and some of the
> additions you've made. They bring up the idea of
> extensions (next). It's something I was thinking
> about when writing the spec, but neglected to
> mention.
>
> Extensions
> ----------
> The DITA spec has done a nice job of defining an
> extensible system. You can add tags, but only by
> extending existing tags. So a tool that's built
> to operate on the basic tags will also do something
> reasonable with the extended versions--until and
> unless you custom the tool to handle special tags
> differently.
>
> That's a hell of an achievement, in my mind. They
> use XML tags, but the tags represent objects, and
> there is an inheritance hierarchy at work when the
> tags are processed. I don't know exactly how they
> achieved that goal, but it's a model for the way
> the system needs to be designed.
>
> Thinking in terms of a the "challenge" type that
> I plan to add tonight:
>
> * One /challenge/ for the system is the ability
> to define a usable /core system/ that can be
> extended for particular applications.
>
> --/Proof/ that it can be done is exhibited
> by DITA--an information-typing architecture.
>
> John Sechrest wrote:
>
>>
>> Eric Armstrong <Eric.Armstrong@Sun.COM> writes:
>>
>> A very nice article. Thank you. It has helped me a lot.
>> Here are some small comments.
>> % REQ: Maintain a stable temperature that supports
>> % life on earth.
>>
>>
>> The process of choosing the question is vitally important.
>> Sometimes questions are generated that have the prefered
>> answer already embedded in them.
>>
>> The difficulty with this "right question" discussion
>> is the same problem with many philosophical discussions.
>> You end up meta discussing the question, and defining terms
>> and never really ever getting to answering the question.
>>
>> But suppose that instead of the REQ above, we ask the question:
>>
>> REQ: How should Humans life on the earth?
>>
>> This becomes a deeply religious discussion quickly. And yet.
>> The first question is directly related to this one. So at
>> some level you have to ask:
>>
>> What is the process for asking the right question?
>>
>> % l) A drawback statement is /invalid/ if it is not
>> % yet linked to a requirement--but it can still
>> % be present in the system.
>>
>> % It seems small but this is another big deal. People
>> % generally dislike structured authoring systems for
>> % two reasons: (a) they're forced to choose a type
>> % when they don't yet know how to categorize what they
>> % want to say and (b) they're forced to do things in an
>> % uncomfortable sequence because the system doesn't
>> % "illegal" states (like a drawback without a requirement
>> % to link to), even temporarily.
>>
>> this last sentence does not have a verb.... What is the verb?
>>
>> -> because the system doesn't _____ "illegal" states , even
>> temporarily.
>>
>>
>>
>> % At this point, the mechanism for choosing among viable
>> % alternatives is undecided. It could (and probably
>> % should) operate completely outside of the design system.
>> % Choices could be made by voting, by personal whim, or
>> % by any other mechanism.
>> I had an idea here. I have an alternative evaluation methodology
>> which involves weighting and evaluating each of the nodes.
>> If you do a weighted sum of all the nodes, then you basically
>> are doing a decision tree evaluation.
>>
>> So allow each of the participants to a) Define the possible states
>> of a node (1-5)
>> - 1 Bad (what does it look like to do bad)
>> - 2 poor
>> - 3 OK
>> - 4 good
>> - 5 Great (what does it look like to do great)
>>
>> b) choose on a per person basis what state they thing this
>> node is at
>>
>> c) Define the wieght about how important this node is to what they
>> consider important.
>> Then you can do (for each node ( node-list) {sum(state($node) *
>> weight($node))})
>> which then gives you an ordered list of proposals.
>>
>> % I'm not sure it matters. As
>> % long as we're choosing from a collection of viable
>> % alternatives, things will be heck of lot better than
>> % they might otherwise have been.
>>
>> It does matter. It matters a lot. Because the minor drawbacks for some
>> will be major drawbacks for others. And the choice need to not be
>> made on whose baby is getting gored.
>>
>>
>> ... % Maybe the only really important task left at this stage
>> % of the process is to come up with a catchy name. We
>> % could simply add a D: DIBS? IBIDS? BIDS? SPID?
>> % Or maybe it could be named after a noted problem solver
>> % or peacemaker. (Buckminster? Bucky? Wright Stuff?)
>>
>> % Any other ideas?
>>
>> Thank you. That was very helpful.
>>
>> I think that there are several places where things are needed.
>> I am still tumbling down the tuple path that jack pushed me down
>> some time ago. This is a representation issue, but I can see how to
>> use it to drive a system like this.
>>
>> The nodes of discussion need to have limited size. As a way to keep
>> the focus on one issue. The problem with many of the "discussion"
>> processes is that they let each node support many different
>> types of objects and to refer to many different issues/ideas/drawbacks
>> all at once.
>>
>> Having "articles" written, which put forth material, should not be
>> the core of the IBIS decision process. But should be base material
>> that is referenced (linked to), but should not be the core of the
>> IBIS nodes.
>> Each node should have just one thing. An idea. which it then
>> references other stuff from. If this is done tightly enough,
>> then the node can have other attributes, like weight and score etc.
>> There are many user interface issues around what you are talking about.
>> And that would be a good thing to deal with as well. But I will put
>> off that set of commentary except to say, that people should
>> be able to indicate how they feel about the discussion. And that you
>> should
>> be able to put timelines into the system.
>>
>> You mentioned that you conflated time line and desirability. This is
>> a problem. Urgency versus importance is a key problem that most people
>> get caught on. You need to be able to represent both independently.
>> I think this is a great outline. I think the next step is to find all
>> the
>> node types and all the things they depend on:
>>
>>
>>
>> Q: Question
>> A: Alternative / Answer
>> P: Pro
>> C: Con
>>
>> REQ: Requirement
>> IMP: Importance Level 1: Immediate Need ->
>> Major Requirement Level 2: Important , but not so ->
>> Minor Requirement
>> Level 3: Nice, but not vital
>> Level 4: Low level of importance
>> Level 5: Not important at all
>> URG: Urgency QUAL: Quality
>> Weight:
>> ISS: Issue
>> PROP: Proposal
>> State (complete, incomplete,sound,viable)
>> (must have link to Requirements)
>> (must have links to advantages)
>> (must have links to drawbacks)
>> A proposal is /incomplete/ if it has:
>> * invalid drawbacks
>> * invalid advantages
>> * major unaddressed requirements
>>
>> (addresses, violates,fails to address ) a requirement.
>>
>>
>> COMP: Component
>> VERS: Component version
>>
>> DRAW: Drawback (must have link to requirement)
>> State: (Valid, invalid)
>> A drawback statement is /invalid/ if it is not
>> yet linked to a requirement--but it can still
>> be present in the system.
>>
>>
>> ADV: Advantage (must have link to requirement)
>>
>> REASON: reasons/evidence State: (asserted, withdrawn,
>> retracted)
>> OBJECTION: Objection
>> State: (asserted, withdrawn, retracted)
>>
>>
>>
>> Clarification
>> Correction
>> Restatement
>> Question
>> (The details still need to be worked out.)
>>
>>
>>
>> Tool features:
>> * *Tagged* so that a proposal is distinguished from
>> an objection, and so that a schema can enforce
>> the structure.
>>
>> * *Threaded* so that people can respond within the
>> context of a proposal, as when quoting an email
>> --but without having to quote and re-re-quote
>> material so that it winds up duplicated in every post
>> in the thread. (Part of the reason for implementing
>> purple numbers in the Yak email archive was to permit
>> operations of that kind in the future, and to at least
>> allow for granular linking in the meantime.)
>>
>> * *Attributed* so that the author of any particular
>> statement can be identified. (Important, since only
>> the author of a statement and the all-powerful
>> /editor/ (sys op) can retract a statement.)
>>
>>
>> * *Indenting*. The original text will have indentation.
>> Responses from others need to be indented, as well.
>> Some way to distinguish the two kinds of indentation
>> is needed so that, when displayed or printed, the
>> discussion reads like a well-structured dialogue,
>> rather than a linear dialogue (as at Slashdot,
>> for example).
>>
>> * *Highlighting*. Like an RSS aggregator, the tool
>> used to watch and participate in the discussion
>> must make it possible to highlight things you haven't
>> yet read.
>>
>> * *Fast Access* It should also be possible to quickly
>> jump to the next unread passage. It should also be
>> possible to flag a passage, see an index of flags,
>> jump to a passage from the index, and jump from flag
>> to flag.
>>
>> * *Filtering*. Display a proposal without drawbacks,
>> with only drawbacks, with or without objections, etc.
>>
>> * *Collecting and Partitioning*. It should be possible
>> to work on multiple projects in the same workspace,
>> putting them in folders and picking up where you left
>> off when you revisit them. So you may collaborate on
>> project A with X, Y, and Z but collaborate on
>> project B with M, N, and O. You'll only work on one
>> project at any one time, but you should be able to
>> see all of your project folders in a single tree,
>> switch between them rapidly, copy files between them,
>> and possibly share authoring templates and other
>> "personal" (non-collaborative) files between them.
>>
>>
>> ----
>>
>> Any other ideas?
>>
>>
>> Ok. I have to work on a proposal due tuesday, so I will have to leave
>> this discussion. But In a week, I would be glad to take the next
>> step.
>>
>>
>>
>>
>>
>> -----
>> John Sechrest . Helping people use
>> . computers and the Internet
>> . more effectively
>> .
>> . Internet: sechrest@peak.org
>> .
>> .
>> http://www.peak.org/~sechrest
>>
> (05)
--
This message is archived at: (06)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43C0F223.7080005@concept67.net (07)
|