As frequently happens, what started out as an email
turned into an article. So this is lengthy. I plan
to convert it to HTML and post it at treelight.com. (01)
Hey... Maybe the purplized version in the Yak archive
will simplify that process?? That would be nice.
(I can convert Yak's purplized text to HTML by plugging
it into a draft at my Artima web log. Then I can change
the < entities to <'s to restore the purple numbers!
Baroque. But it should work!) (02)
P.S.
The ontology guys are going to love this one. (03)
TOC
===
* Introduction
* IBIS as a Discussion Methodology
* IBIS as a Design Methodology
* Goals
* Mechanism
* System Requirements
* Summary (04)
Introduction
============
Ever since I first heard of it, I've been thinking of IBIS
in terms of a design methodology. Today, it occurred
to me that IBIS can be taken a step further, so that it is
directly targeted at generating designs collaboratively,
rather than at "understanding issues" (which is an admittedly
important part of the process). (05)
(For those who don't know what IBIS is, an explanation
is coming up shortly.) (06)
Note, that even if we weren't really improving on IBIS--
if we were only re-casting the IBIS concept as a design
methodology--there would still be several important
benefits from doing so: (07)
* It refocuses attention on solutions, rather than
problems. That makes it more appealing, because
people care about solutions, and would rather not be
reminded of problems. So they'll be more likely
to think of IBIS as a good idea, even if they don't
know much about how it works. (08)
* Artists, architects, software builders, and other
professionals will tend to be more interested in
the project, because it relates to their primary
activity: design. (To that end, it can be used as
a solo design tool--one that happens to dovetail
nicely into collaborative discussions.) (09)
* When applied to issues like global warming, it
will be readily apparent that we are facing a
design problem. That slight shift in focus will
(I believe) will help us think about the issue
in more productive terms. (010)
So if the /only/ thing we did was to portray
IBIS as a design tool, it would tend to be a good
thing. But as you'll see, I think we can do quite a bit
more. I think we can use IBIS as a basis to create
something even stronger--something that overcomes at
least one significant, inherent limitation in the
IBIS process. (011)
Before we get to the "new and improved IBIS", though,
we'll take a short look at IBIS as it stands today. (012)
IBIS as a Discussion Methodology
================================
This is background material. If you're familiar with
IBIS, you can probably skip it. But you may want to
read it anyway to figure out what /I/ mean when I say
"IBIS"--and so the cognoscenti can correct me on the
addled way in which I've presented it. (013)
/IBIS/ stands for Issue Based Information System. It
was developed by Horst Rittel, and has been used
extensively by Jeff Conklin, who popularized it first
in a particularly clear paper, and later in his book
(below). (014)
The basic structure of an IBIS conversation, as I
grokked it quite a while ago, was: (015)
Q: Question
A: Alternative / Answer
P: Pro
C: Con (016)
In this system, the possible statements have types,
and there is a structure among the types. Multiple
instances of each type can exist, and they can
link to each other in bizarre ways, creating
convoluted diagrams that to the kinds of conversations
we actually carry on in real life. (017)
One of the important parts of the process was that it
was not possible to put forth "the answer" without
first putting forth "a question"--thereby allowing
for other possible alternatives. (A practice which,
if followed by religions and politicians, would benefit
all of us.) So the system immediately moves us away
from thinking that is based on "the one right and true
way". (018)
One of the major benefits of an IBIS discussion, as related
to me by a past participant, is that everyone can relax.
Any idea they bring up is recorded. The conversation isn't
finished until all of the recorded ideas are examined
and evaluated, so people don't get antsy about getting
their ideas across. They can relax while other ideas
are examined, knowing that their idea will get its turn. (019)
Another benefit is that it tends to get people more
focused on the problem. When an idea is recorded it
is "out there", and "on the board". The person who
originally presented it can then find themselves
challenging it as vigorously as anyone. (020)
In a purely oral conversation, on the other hand, people
tend to feel the need to defend a proposal since, (a) the
idea is "inside" them (it only exists when they speak),
so it's "their baby", and b) since they are the only
repository for the idea, it is likely to die the moment
they stop defending it, because people will then be able
to "simplify their lives" by having one less proposal to
consider. ("Politics" seem to emerge in such situations,
because people instinctively seek alliances to help
"keep their baby alive".) (021)
The social benefit of the process is that all of the
relevant ideas tend to surface and be examined, so
there is a much stronger chance that the best idea will
be adopted, rather than the one that happens to be
promoted by the loudest or most well-known voice in
the room. (Ever see how quickly discussion stops when
the CEO voices an opinion?) (022)
For more on IBIS see: (023)
* Dialogue Mapping: Building Shared Understanding of
Wicked Problems.
Jeff Conklin. John Wiley and Sons, 2005. (024)
* Wicked Problems and Social Complexity
(Chapter 1 of the book)
http://www.cognexus.org/wpf/wickedproblems.pdf (025)
* The IBIS Manual, Jeff Conklin
http://www.touchstone.com/tr/wp/IBIS.html (026)
IBIS as a Design Methodology
============================
The IBIS mechanism centers around a /discussion/.
It's highly useful for those wide-ranging, infinitely
branching discussions of "wicked problems", where the
nature of the problem isn't clear, and where most
everyone in the room has a different concept of the
problem they're there to solve. (027)
But many of the same techniques can be applied
to carrying out a discussion that is (or is at least
intended to be) slightly more focused: a /design/
/discussion/--one whose objective is the construction
and selection of one or more designs which are aimed
at solving a problem or achieving a desired result. (028)
Since design discussions involving multiple participants
frequently turn out to be "wicked" in nature, a design
methodology based on IBIS techniques makes sense.
But a good methodology can help a solo designer, as well,
helping him or her to clarify and understand the needs of
the target audience. (029)
Note:
In essence, the construction of a design-enabling system
is an Engelbartian "C" level activity. (A "C" level activity
focuses on the design and construction of tools and methods
that can be used by "B" level designers, who are trying
to improve the processes and procedures used to accomplish
"A" level tasks that are being performed currently with
whatever tools and techniques happen to be available.) (030)
Goals
-----
The goals of the system are: (031)
* To carry out an effective design discussion online. (032)
* At the end of the discussion process, to be able to
print or display either the full text or the summary
view of a proposal that has resulted from the discussion,
listing its advantages and drawbacks with respect to the
requirements. (033)
* To print or display alternative proposals as well,
highlighting their advantages and drawbacks. (034)
* To print or display the list of requirements that
emerged from the discussion. (035)
* To print or display a table of proposals and
requirement to show how they compared. (036)
Mechanism
---------
A /discussion/ consists of /statements/ of various types. (037)
Note:
Most of the italicized terms in this section define and
describe the different kinds of statements you can make,
and how they relate to one another. (038)
a) A design has /requirements/, in the form of things
we need to achieve. For example: (039)
REQ: Maintain a stable temperature that supports
life on earth. (040)
b) /Issues/ are things that violate a design requirement: (041)
ISS: Global warming is raising temperatures. (042)
Note:
The value of an issue is that it raises one or more
requirements that need to be satisfied. Human
dissatisfaction and stress are, in general, the
result of social systems, government bureaucracies,
corporate bureaucracies, and software systems that
leave important requirements unaddressed. To the
degree that we can identify those requirements and
consciously address them, we can greatly alleviate
human suffering! (043)
c) /Proposals/ are ways of addressing the collected
requirements. (044)
d) Proposals can have multiple /components/, with
each component (or combination of components)
addressing one or more of the requirements. (045)
e) Components also have multiple /versions/. The
satisfaction of some requirements may be deferred
to later versions. (There may therefore be
multiple viable alternatives, with each alternative
addressing some requirements earlier, and some
later than the others.) (046)
f) Requirements have different /levels/, reflecting their
importance:
Level 1: Immediate Need
Level 2: Important but deferrable
Level 3: Nice, but not vital
Level 4: Low level of desirability
Level 5: Not important at all (047)
Note:
I have conflated desirability and timeliness here.
At the moment, I don't have a problem with that.
I think it will work. But I could be wrong. (048)
Identifying the requirements and the levels that need
to be assigned to them is a major part of the
discussion-and-decision process. (049)
Creating design proposals is a matter of identifying
component/version sequences and relating them to
the requirements. (050)
g) A design proposal can list /drawbacks/.
A drawback *always* refers to a requirement. (051)
This is fairly huge, actually. Jeff Conklin
pointed out that an "argument against" is very often
a new issue in disguise, and that much of the art of
the moderator lies in recognizing them. (052)
At one point, Conklin and his crew created a tool
that allowed people to hold an IBIS discussion online.
In a private conversation, he relayed to me that it
didn't work out all that well, primarily because
it turned out to be a crucial to have a facilitator present--
mostly to identify the issue(s) buried in an objection. (053)
In this system, stating a drawback brings a requirement
into existence if it didn't exist already. So lower level
counter-arguments bring higher level requirements to light.
That function may reduce the need for a moderator to the
point that the process can work online. (There are other
important considerations as well, mentioned later.) (054)
Note:
When making a proposal, you're free (and encouraged)
to put forth the drawbacks as well as the advantages.
Listing the pro's and con's in that manner gives people
an opportunity to let you know that one or more of the
supposed "requirements" may not be as important as
you had thought. (055)
h) Proposals are supported by /advantage/ statements.
Advantages, too, are related to requirements.
So listing reasons in support of a proposal
also brings to light requirements that may have
been previously hidden, and which can then be
applied to other proposals. (056)
i) Any statement in the system can be supported by
/reasons/. (Evidence?) (057)
j) Any statement in the system can also be countered
with an /objection/, or supported with an /agreement/. (058)
At this point, the normal IBIS machinery may well enter
into the picture, in order to facilitate exploration of
the reasons and/or evidence for or against a given point
of view. (059)
k) Objections and agreements may be /put forth/
and /withdrawn/ or /retracted/. (060)
l) A drawback statement is /invalid/ if it is not
yet linked to a requirement--but it can still
be present in the system. (061)
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. (062)
It may or may not be possible to address the first
issue. That's a usability issue that involves entering
random comments or questions and changing them later.
It's an open question that has yet to be decided. (063)
Issue (b) can be addressed at the outset, however, by
declaring that a drawback /can/ be created that does
not yet have a requirement to point to. The requirement
can be created subsequently, and a link to it added. (064)
m) A proposal is /incomplete/ if it has:
* invalid drawbacks
* invalid advantages
* major unaddressed requirements (065)
An invalid drawback or advantage must therefore be either
retracted or validated (by linking it to a requirement)
before the proposal can be considered complete. (066)
A proposal can also be considered "substantially complete"
if it has not yet addressed all of the minor requirements.
It's not incomplete, at least. (067)
n) A proposal /addresses/, /violates/, or /fails to/
/address/ a requirement. A requirement is /addressed/
by an advantage statement. It is /violated/ by a
drawback statement, and is /unaddressed/ if
neither statement is present (in which case the
proposal is incomplete). (068)
o) A proposal is /sound/ if it has no major drawbacks
--even if there are minor drawbacks. But it is only
/viable/ when it is both sound and complete
(all major requirements have been addressed). (069)
A preliminary proposal may be sound as far as it goes,
but if major requirements remain unaddressed, then it
is incomplete and not yet viable. (070)
In many cases, minor requirements may be left
unaddressed. They may only become important when
there are multiple viable alternatives, at which
point minor requirements may become the deciding
factor. (071)
To be decided: How to heuristically determine or
allow the participant to designate primary author,
co-authors, and other such distinguishments. (072)
p) A proposal is /adopted by default/ if there are no other
viable alternatives. When there are multiple choices,
some other basis must be used for deciding among them. (073)
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'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. (074)
q) Other statement types may make sense for editing,
such as /clarification/, /correction/, /restatement/,
or /question/. That kind of capability would
distinguish edits from substantive statements.
(The details still need to be worked out.) (075)
System Requirements
-------------------
To do all this, a mechanism is needed for tagged,
threaded, and attributed discussions: (076)
* *Tagged* so that a proposal is distinguished from
an objection, and so that a schema can enforce
the structure. (077)
* *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.) (078)
* *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.) (079)
However: (080)
--Attributions should be maintained by the system,
but they should generally be /hidden/. (081)
(Interesting wrinkles: The ability to ask "did I
say that?", an option that causes everything you
wrote to be marked as such, and the ability to get
the system to send a message to the author of a
statement--for example, to ask them to retract it
--and to track the request so that the editor can
be involved if an author hasn't responded in
several weeks, or days, depending on what is
considered "timely" for that project.) (082)
--Hiding attributions is important for a discussion
because (a) it prevents knee-jerk, hero-worshiping
agreement, (b) it prevents knee-jerk, devil-despising
disagreement, (c) it gives people freedom to speak
their minds without fear, and (d) it helps to give
the original author some distance, making them even
less likely to become defensive. (083)
--Attributions should probably *never* be shown
for individual statements. (Otherwise, there is
a need tell the system that a discussion is
"finished", so that it can be displayed in a
way that reveals the attributions. But that
implies the possibility of "reopening" a
discussion, which can defeat the purpose of hiding
attributions.) (084)
--Instead, attributions should probably be collected
at the top of (a) the requirements view and (b)
each proposal, using some heuristic that involves
chronology for the original author(s), and statement
types, sizes, and/or numbers to distinguish authors
from contributors. (085)
For example, restatements and corrections would
represent contributions, while a substantive proposal
represents authoring. So it would be possible, for
example, to become one of the authors of the
requirements while contributing to one or more of
the proposals. (086)
And just to be clear: The author of several failed
proposals would probably find themselves listed as
an author of the requirements, but would not be
listed as the author of the "winning" proposal.
(Maybe that's why I'm so good at requirements.
Having built enough things that didn't pan out
certainly ought to qualify me for /something/...) (087)
The interface for such a system needs to solve a
couple of interesting problems: (088)
* *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). (089)
* *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. (090)
* *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. (091)
* *Filtering*. Display a proposal without drawbacks,
with only drawbacks, with or without objections, etc. (092)
* *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. (093)
For more thoughts on the requirements for such a system, see: (094)
Requirements for a Collaborative Design/Discussion/Decision System
http://www.treelight.com/software/collaboration/requirements.html (095)
What's Wrong with Email?
http://www.treelight.com/software/collaboration/whatsWrongWithEmail.html (096)
A Simple Collaboration System (Proposal)
http://www.treelight.com/software/collaboration/SimpleSystem.html (097)
Technical Impediments to Persistent Collaboration Tools
http://www.treelight.com/software/collaboration/Technical_Impediments.html (098)
Summary
=======
Extending IBIS into a design methodology has a number
of potential advantages: (099)
* Every discussion is immediately characterized as
a "design" problem. (I happen to think that's good.
I think it puts people in the right frame of mine
to be productive and find a solution.) (0100)
* It ameliorates one of the problems that has made
it difficult to carry on an IBIS discussion online
--the need for a facilitator--because lower level
drawbacks call into existence higher level requirements
(if they do not already exist) to serve as a foundation. (0101)
* Significantly, the requirements that emerge from that
process are then automatically applied to every other
proposal in the system--so stating one good drawback
can suddenly and immediately invalidate a wide array
of proposals, as it probably should have done at the
outset. (0102)
* The technologies and techniques used to facilitate
IBIS discussions can be used in the design context.
(For existing tools and techniques, see CogNexus.org
and CompendiumInstitute.org) (0103)
* It can help to get software designers and other
designers interested in using (and developing)
the system. (0104)
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?) (0105)
Any other ideas? (0106)
--
Eric Armstrong
TreeLight Health, Citizens' Advisory
http://www.treelight.com/health -- nutrition/fitness/mailing list
http://www.citizensAdvisory.org -- politics, news feed
http://www.artima.com/weblogs -- software technology web log (0107)
--
This message is archived at: (0108)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43BF4649.8000203@sun.com (0109)
|