Horizontal cascades and vertical geo-locals

[Michael Allan]

Thomas, here's another layout I've been considering:

  http://zelea.com/project/votorola/a/poll/web/_/pollspace/4-horiz.xht

The cascade trees are horizontal.  Leaves are left and roots are
right.  Scrolling to the right shows the path of the traced vote
(black), together with the contributing flow of votes from
leaves/branches (grey).

Peers (co-voters, competing delegates) are stacked vertically.  The
data are in columns for easy comparison.  (The data shown here are
just placeholders, not real counts, etc.)  For example, imagine the
'p' column is a link to the delegate's/candidate's position draft in
the wiki (or wherever).  You'd run your mouse down the column,
clicking on the positions of interest, and comparing them.

Or imagine the 'g' column is geo-local date.  It has a vector showing
direction (compass needle), and a numeric distance from the user (km).
The distance is maybe colour coded too.  Then you can see at a glance
where the delegates and candidates are located in relation to you, and
where their voters are.  You can even get a sense of their dispersal
pattern.  (We could also add a tiny map of the district in each
vertical cell with a location dot for the voter/candidate, and the
same map in the column header, but with all dots combined.)

And so on.  We can use expandable/collapsible columns to load it up
with useful data, to help the voter make sense of the choices.  Other
layouts I've tried can't do that, or can't clearly show the vote flow.
These don't cut it:

  http://zelea.com/project/votorola/a/poll/web/_/pollspace/1-vert.html
  http://zelea.com/project/votorola/a/poll/web/_/pollspace/2-vert.html
  http://zelea.com/project/votorola/a/poll/web/_/pollspace/3-compactTHI.xht

If I code up the horizontal layout, and add the voting controls, I
think the voting interface will be OK.  Users will like it.  What do
you think?

Then we can focus on the collaborative drafting of positions/proposals
(wiki), and the connection with other sites (distributed voting
controls, sparklines, etc.), and how all three of these interfaces
work together for the use-case of campaigning (vote for me!).  I think
you agree, that's the critical path.

PS, on self-voting: If we allowed it for the root candidates, then I
agree your suggestion is best: we'd have them all vote for themselves
automatically.  Currently we disallow self-voting entirely (it has no
effect).  The advantages of disallowing it are (i) stability in
continuous voting, because a shift in one's own vote can never affect
one's standing; (ii) in the math and code (if I recall) for the
handling of vote cycles, it gives cleaner invariants and simpler edge
cases; (iii) incentive to vote freely and honestly, especially near
the leaves, because voting for someone else (becoming a delegate)
cannot diminish my own (probably low) vote count, and therefore cannot
affect my relative standing; and (iv) you can vote for anybody, but
not just anybody can vote (there are usually residency criteria), and
this will complicate the automation of candidate self-votes.

On the other hand, allowing self-voting would give a more accurate
calculation of % turnout.  Currently, the root candidates are not
included in the turnout.

-- 
Mike Allan

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