[ba-unrev-talk] Using Pepper
Moving to discussion to unrev, because we have moved
away from licensing, on are alternative implemenation
strategies. (I want to leave ba-ohs-talk clear for
HyperScope, so Doug can get active on it.) (01)
Jack Park wrote: (02)
> At 12:07 PM 5/31/2002 -0700, Eric wrote:
> >I think it will take some social rules (I have no idea what kind) to
> >know when to move to email for a discussion, and when to move
> >back to Pepper to capture pieces of it, but if IBIS will work, this
> >looks like a great way to test it.
>
> Quite right.
> I suspect there needs to be combinations of communications: areas where you
> are focused on some particular issue, and areas where you are hashing
> around vague notions of greatness, which, if done within IBIS, would likely
> clog that system and render it useless (or words to that effect).
>
> Of great interest to me is the notion of using IBIS in an asynchronous
> mode. Jeff Conklin's practice is largely synchronous (f2f, in meetings),
> near as I can tell, but f2f meetings are not always possible, particularly
> with a widely distributed network of participants. Perhaps such an IBIS
> design process will necessarily be moderated, giving some entity (person or
> group) the right to nuke posts that are not germain to the particular
> branch of the discussion tree (or perhaps moving things around to suit),
> and, as has been suggested on this list before, providing summaries of
> branches, making decisions (perhaps, thus, closing branches to further
> discussion), and so forth. (03)
Yes. That's the model I had in mind, where an email list or online discussion
board is used to carry on the conversation, while the moderator(s) pick
up on items and add them to the IBIS structure. (In the ideal case, all of
the participants are moderators. But it would work with only one.) (04)
Conklin expressed that the moderator's most important function is to
recognize when a new issue has been raised. Generally, anytime 2 folks
are carrying on a heated debate, it takes a 3rd with a cooler head to
identify the underlying issues. But those triangles can shift around when
multiple people are involved. (05)
> I'd still argue that email may not satisfy the larger. I suspect that a
> discussion board that offers relational views, along the lines visible at
> http://www.memes.net, but (here I'm not sure) quite possibly also available
> in Pepper, would be appropriate. I've been building prototypes along these
> lines. (06)
I'm so sure about that, either. I think it was Murray who was talking
abut "frameworks" earlier. Let's think of Pepper as our discussion
organizing tool, and X as our discussion device, where X may be
memes.net, slashdot, or email (what was the email-kind of thing
lately where you invite people to join, and hence can't be spammed?
Something like that!) (07)
Let's add a Y, too, where we can draw pictures. A shared whiteboard
or some such. (08)
Now let's wrap all of those into a single "discussion framework", such
that when I select a discussion, all of those windows pop up, in whatever
location and size they were in when I left the discussion. (09)
Naturally, some little flag goes up to alert me when there has been
activity on a discussion -- which means some way to monitor the
activity of each application bound together by the framework. (How
that works, I have no idea. But it's a requirement.) (010)
Given the quasi-email discussions are archived, later on we build some
some SDS-style tool to access them. Or maybe Pepper turns out to
be such a godsend that we use it for everything. Either way, we're
heck of a lot further down the line than currently. (011)
In the absence of a convenient framework that can pop up several
tools simultaneously and reset them to the desired state, we can
implement a manual "fingertip framework" where we pop up the
relevant applications ourselves. (012)
> Perhaps the killer ap lies hidden in an email client that handles
> XML-structured posts such that one could subscribe to a branch of an IBIS
> tree and respond from an email client. I've been thinking along these
> lines as well. (013)
Right now, I'm thinking that "killer app" is the wrong way to think
about this problem, and that "multiple modules", one day gathered
into a framework, is the right approach. (014)
(Personal note: I think I've finally put enough distance between myself
and the approach I was favoring to see the merit in other proposals.) (015)