Some comments

[Michael Allan]

davidm wrote:
> I'm curious if you could do a rough simulation in a room with 10
> people making a decision and exchanging paper tokens. Contrasting this
> simpler idea may make it easier to explain.

So here's my idea to explain the scalability part.  This connects up
with my work on the user interface.  (I agree with David Hilvert and
Fred, the UI is not yet good enough for alpha trials.)

Imagine the simulated toolset is just bits of string.  When one person
(X) makes a proposal, and another (A) nods her head in assent, we
formalize it by extending of line of string in a directed arc:

         (X) <-- (A)

This is a vote.  Suppose the discussion ends with a rough consensus in
favour of X's proposal.  Seven people have given their assent, and
seven lines of string are now directed at X:

         (G)
   (F)
          |
       \  v

 (E) --> (X) <-- (A)      (H) --> (Y)

       /  ^  \
          |
   (D)         (B)
         (C)

Now the group is dispersing.  The bits of string are left behind on
the floor.  The pattern of consensus they formalize then becomes a
memory.  Probably it will be forgotten.

Step back for a moment.  Imagine an improvement to the toolset.
Instead of bits of string on the floor, we project lines in glowing
arcs through the air (just suppose).  To see them, we have special
spectacles.  The lines remain attached to people as they disperse.
The lines extend and pivot on the focus (X), but they keep the same
radial pattern.

A week later, A is stopped in the street by a curious neighbour (N).
He's wearing his specs.  He points to the line that extends from her
in a long arc, and lands in a distant quarter of the city, where it is
joined by 6 other lines.  He asks her about it.  She describes her
discussion with the others, and how they came to agree with X's
proposal.  The proposal makes sense to N, as well.  Automatically, a
line is extended from N to A.  The consensus has scaled up by one.
The crucial thing is that it has scaled without losing its
face-to-face, communicative structure.

         (G)
   (F)
          |
       \  v

 (E) --> (X) <- - - - - - - - - - - - - - - - - - - (A) <-- (N)

       /  ^  \
          |
   (D)         (B)
         (C)

I don't know if the above is a good way to explain it, but it does
show the two paramount design requirements of the UI.  The first is
extensibility.  The UI has to reach out to people wherever they are.
We can't expect them to come to us.  I think we have a handle on this
requirement.  We're ahead of MixedInk, for example (at least for now).
Here's what they have for UI extension:

  http://zelea.com/var/tmp-public/mi-widget.xht

By comparison, we're coding smaller embeddable views (sparklines and
other bits of content) for use in blogs, mash ups and other Web sites.
We have open URL's that reach into our Web interface (their's is
opaque); we allow people to compose their texts on external sites, or
to choose their own drafting media; and we allow them to extend their
votes to proposals initiated on other sites, or to vote on other
objects, such as electoral candidates (not just texts).

The other requirement is visibility and general accessibility.  We're
not doing so well here.  In the scenario, for example, no matter what
N's interest is (topic of consensus, or just A) the consensus has to
be made visible to him.  If he wanted to get further involved with it,
he'd also need to see the internal structure.  He may be happy to talk
to A about it, but others may prefer to talk to E instead, or even
directly to X and Y.  That kind of visibility/accessiblity is missing
from the current UI.

So this is where the navigable cascade tree comes in.  (Thomas and I
were discussing it this morning.)  I can code a first cut in maybe a
week.  If it works, we can build a new UI around it, and leave the old
one as a fallback.  (We can have any number of UI's, BTW.)

David Hilvert (in the other thread) wrote:
> (Your suggestion of providing an overview of the cascade flow might subsume the
> above, if the overview provided were to extend to a set of drafts including the
> draft recently viewed by the user at the Wiki.)

Yes, I agree.  We'll need a link to the position draft for each
voter/delegate/candidate in the cascade, so we can compare the text
between various parts of the cascade, or between cascades.  Maybe the
linkage will be modal too, so we can switch it to navigate among other
types of pages (wiki user pages, pollserver registrations, and so
forth) not just position drafts.

-- 
Michael Allan

Toronto, 647-436-4521
http://zelea.com/