[MG] Votespace social map

[Michael Allan]

Thomas von der Elbe wrote:
> Mike, this thing here made me thinking: http://debategraph.org/home
> It does change all the time, but it also very fast opens up a new
> node.  If the time control was sliding backwards 20 events and it
> would directly jump to it and not show the ones in between, it
> should work, or not?

Yes, technically it would.  But I suspect the user will often want the
in-betweens.  He will grab the time controls in hopes of seeing the
history of transformations between the end points - before and after,
past and present.  If we frustrate his hopes, he'll end up fiddling
with the controls in an attempt to create his own animation.  So I
think its indispensible.  (You may have been thinking as much when you
urged that the map's spatial pans ought to be continuous and smooth,
as opposed to discrete jumps.  I think the same rationale applies to
the temporal pans.)

Also, if the view's structure is unstable, such that an isolated vote
shift has wide-ranging visual consequences, then it's especially hard
to understand the relation between two distant end-points.  How did
*this* become *that*?  So especially if we lose structural stability,
then I think animation is more urgent than ever.  Yet we're
constrained in our animation capabilities.  We cannot have too many
moving pieces, at once.  Putting all of this together, I think
structural stability is definitely a requirement. *

> > Myself, I'm starting to think that the inverse video in the
> > theatre app could be a mistake.  It could cause us trouble in
> > future: hard on the eyes; hard to ensure that a faded background
> > graphic is still visible across all hardware.
> 
> By "inverse video" you mean the ability to slide the time contral 
> backwards? I think this is very very useful, isnt it?

No, I meant the bright on dark - bright glyphs/lines on a dark
background.

> What I helplessly tried to describe with words is the lower pic here:
> http://www.visualcomplexity.com/vc/project_details.cfm?id=744&index=744&domain=

Right.  That one would be unstable.

> PS: What I also like about this thing (http://debategraph.org/home),
> it behaves like real people trying to find the best place to talk to
> their candidates (who is in the middle and being pressured from all
> sides).  And as soon as more space becomes available (because
> someone left), others imediatly use the chance and fill it.

I agree, we definitely want it to say "real people" in "real places",
and "things happening".  For me, Debategraph doesn't look real enough,
or connected with reality.

You had a promising idea when we talked yesterday: use voice callouts
to show that we're graphing real people.  You were worried that this
would pose layout problems for the map.  But a solution (as we
discussed) is to bring in the feed.  We make the feed bite (top left)
into the callout bubble, and the callout arrow points to the person on
the map (right):
http://zelea.com/project/votorola/a/crossforum/theatrePlan.png

> And another thought, concerning fixed positions: Since we know
> already, that it doesnt make sense to display more than 20 voters
> per candidate, how if we define 20 fixed positions, which get filled
> up with voters as they grow in number. And not sort them by votes,
> each keeps his position until he shifts his vote. Then someone else
> takes his place. Would this work, Mike?

Yes, it might!  We'd have to track the slot assignments in the
database to give them stability.  But it might be worth the effort.
I'll think about this, and repost my mockups.


 * We're animating SVG.  My favourite SVG animation is this one:
   http://srufaculty.sru.edu/david.dailey/svg/balloon.svg

   It takes a surprising amount of steam to float that balloon across
   the screen.  Current SVG layout engines are inefficient.  Running a
   single CPU core at 100%, it takes my Firefox *minutes* to reach the
   right-hand side of the screen, and start back again.  It takes my
   Chrome about 10 seconds.  That's still too slow.  And that's on a
   fast desktop computer.  We need to support slower, mobile devices,
   too.

-- 
Michael Allan

Toronto, +1 416-699-9528
http://zelea.com/



Originally posted to the mailing list of the Metagovernment Project:
http://metagovernment.org/mailman/listinfo/start_metagovernment.org