Seeing the differences among position drafts

[Michael Allan]

To David and Thomas,

I think the visualization of textual differences is going to steer the
whole course of the design, as far as the voting/drafting UI goes.
More at bottom.

David Hilvert wrote:
> One approach might be to adapt the existing history view to present a diff
> between arbitrary pages, rather than merely between versions of a single page.
> While this might not effectively cover the case where your draft draws from
> only some small part of someone else's draft, it might be a reasonable start.

Another approach (stepping back) is to implement a diff in the
pollserver.  Or (further back), a general-purpose diff tool for Web
pages.

> http://www.gossamer-threads.com/lists/wiki/foundation/121420
> http://el-tramo.be/software/wigit
>
> In particular, git very naturally handles sharing of changes.  (On the other
> hand, git might be too restrictive for use with Votorola.)

It's interesting, because git (distributed revision control) has
similarities to recombinant text (our pattern of collaboration).  But
I don't think the toolset meshes; like you say, it's too restrictive.
We need wider degrees of textual variation, finer scales of cherry
picking, and persistent differences in the face of bidirectional text
flow.

There are recombinant toolsets (textbender, TextFlow and MixedInk).
They aren't suitable, either.  Basically they don't grapple with the
essential problem, in our case, which is visualization.

Thomas von der Elbe wrote:
> I agree, that the difference between two texts must become more visible.
> That is also why I liked the co-ment tool so much. Highlighting things 
> plus commenting on them is very easy with it.
> So one could highlight the improvements in ones own text as well as the 
> parts in the candidates text, which one wants to improve (and comment 
> all this of course). Friedrich from Adhocracy.org said, its not so 
> difficult to integrate co-ment.

(I couldn't find a MediaWiki extension for doing text annotation.
 Maybe there's a wiki somewhere that is already set up, so we can try
 it out?  After all, we're not restricted to drafting in our own
 pollwiki.  We don't even have to use a wiki, it can be almost any
 drafting medium.)

> But now I used the wiki-way for the vohall-poll.

So this is now a perfect demonstation.  The differences are visible
and the text can begin to flow.

  http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/p/vohall
   |
   v
  http://t.zelea.com/wiki/User:Mike-ZeleaCom/p/vohall

Either I'll transfer it, or Thomas will, or his voters.  Any remaining
yellow marks will reflect an actual difference of opinion between our
voters (Thomas's and mine).  This difference will then become the
topic of discussion.  Generalizing on this, it seems we've discovered
two rules:

  a) Text flows across a differential, like water over a weir.

  b) Where text does not flow, there is something to discuss;
     otherwise not.

The entire debate on social norms (laws, plans and policies) can
therefore be mapped, in perfect detail, by a survey of textual
differences.  This is a strong statement, and very interesting.

Visualization is the key to (a) and (b).  It's like it were controlled
by a light switch: turn on the light, and the text and conversation
begin to flow; turn it off and they freeze.  The upshot is that (up
front) we only need design the visualization tools; we don't have to
think about transfers and mergers.

Some possible requirements that follow from (a) and (b):

  1. In the pollspace browser, the text subtrees within the vote trees
     must be shown.  It must be clear which delegates/candidates have
     substantial texts, worth comparing.

  2. In the pollwiki, links must be provided to upstream and
     downstream texts.

  3. Wherever multiple texts are shown in a list/tree, it must be
     possible to select any two of them, and generate a visual diff.

  4. URLs for the diffs must be stable, short and precise.  They must
     be embeddable in email and other discussion media.  They will
     serve as anchors for the discussion.  According to (b), there is
     nothing else to discuss, so this is crucial.

     By precise, I mean the URL must ref a specific portion of the
     overall diff, like a single word or phrase (a single area of
     yellow highlighting in Thomas's example).  By stable I mean the
     URL must remain valid, even after the two texts are modified.

Anyway, this is what I'm thinking.  As far as the voting/drafting UI
is concerned, these requirements might be sufficient to carry us into
beta.

-- 
Michael Allan

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