Interactions of talk track

[Michael Allan]

Hi Thomas,

> Unstaging it doesn't work in polls with no messages at all right!?
> ...

Currently no.  But if sticky staging is fully implemented in the talk
track, then yes.  So I stage a message:

         Hello there, blah blah blah
             ----------X----------------

Then I stage a poll without messages.  The track is filtered to empty.
But the old message is still staged and therefore still shown in the
track, despite filtering:

         Hello there, blah blah blah
                                     X

So the user can click on the lone tracked message (X) to unstage it:

         Sys/p/sandbox
                                     -

> ... What I don't like about it, is simply, that the message takes
> the space of the poll-name and you don't know, where you are
> anymore. But I think I understand your point too: the user is more
> in control.

When the message is unstaged, the hidden poll name reappears (as
above).  The user may then restage the message (clicking on -), or
leave it unstaged.

Maybe this is not ideal, but it should at least work.

It looks like the vote track needs this, too.  Currently when an actor
is staged in the vote track and the poll is unstaged, the track
empties and there's no way to unstage the actor.  He hangs around like
Banquo's ghost.  I've tasked a fix for this.  (Generally a prop should
not allow us to do stuff (like staging or unstaging) unless it also
allows us to undo it.)

> Wow, how difficult is this to code? How long would it take? I think
> I like it, but I'm a bit afraid, it might be too much happening for
> the eyes.

The thing I find difficult (or puzzling) is the geotrack.  Initially
it must cover the globe down to the level of cities (deeper later).  I
don't know yet where all that geodata will come from.  (Do we enter it
ourselves?  Do we reuse an existing database?)  Altogether, the
geotrack is likely to be fairly expensive (like the vote track), but
(like the vote track) it'll be useful for other things too, not just
talk lighting.

Talk lighting might fail, e.g. because it's too flashy (as you say).
But we can probably afford to experiment with it because (itself) it
isn't expensive.

So I had this tasked for my next job.  But lately I've been thinking
the Metagov intro banner is a higer priority.  We have an opportunity
there and should probably move on it ASAP.  Right?  (I wanted to talk
about this, but I need to find a new headset first.  My old one died.)

> > (2) Another problem is to reveal the talk track's internal
> > information in useful ways.  Maybe the acid test for this is to
> > quickly find a given message in the track, like we can find a poll
> > in the poll track.  Then we'd know the information is shining
> > through.
> 
> Can you anchor a certain voter and let all messages related to him
> light up? That would make searching for messages quite easy.

I think it already does that for actor, poll and combinations of the
two (position).

I hit a bug when testing the actor filtering.  Crossing user pages,
the first user is carried over to the second user's page.  (That's my
own bug, so I'll fix that.)

> > (3) We're poorly connected to discussion media, the best of which
> > aren't web based.  Our diff URLs are good rope bridges for some
> > media, but they only work at the exit.  We put a welcome mat at
> > the entrance, but it's actually hard to get in. ...
> 
> Well, private mails and voice are somehow not in the interest of
> your voters and their voters etc., because of their
> intransparency. So there is a draw to public lists and forums, isn't
> it?

Yes, but even public lists are mail based.  Most have web archives,
but that's not where subscribers read the messages.  They read them in
mail readers (like Thunderbird).  But mail readers don't normally run
live software (e.g. JavaScript) like web browsers do, so we can't push
a Votorola UI into a mail message as easily as into a web page.  All
we can push is a diff URL.  (Thankfully we can do at least that much!)
Doing more would require coding an extension for each brand of mail
reader (Thunderbird, Eudora, Mutt, G-mail, etc) to run our UI.  We can
eventually do that (also for phones, desktops, and such), but it's too
expensive for starters.  So we have:

   * Voice and mail networks (good for discussion)
   * Web networks (good for drafting and starter UI)

Our aim is to support discussion but our support UI runs on the web.
But that's good enough for starters.

Mike