[MG] Difference bridge layout proposal

Michael Allan mike at zelea.com
Thu Feb 23 09:44:17 EST 2012


C and Thomas,

conseo said:
> ... (At least Mike seems to get some more low-level offlist feedback
> than us super-alpha-users 8-) ). Would be cool, if this could be
> shared somehow, Mike? ...

It comes from an attempt to recruit new alpha users.  I would not
characterize the feedback as low-level though.  Essentially it is:

  * The cost of recruiting a new alpha user is approximately 1 man
    year of effort.

So fuhgeddaboudit.  We've had all the alpha prototyping we can afford.
Ready or not, it's time for beta.

> Mike has also pointed out that the smilies replicate a lot of
> information (eyes, shape), which can be stressing on the eyes. So
> while I would put them in for new users, I would make it themeable
> or even different tracks, because once you know what it is for the
> brace view of Mike is less stressing and I would prefer it as
> well. It is just no good default imo.

The problem is how to say "these are people talking".  If we can't
solve it, then we might just leave it standing (don't paper it over)
and wait for a solution.  I think tactiles are promising, viz. when
the mouse runs across the track... but we'll see.  (We have lots of
time to solve problems of this kind.  Our UI is no longer at the mercy
of one or two make-or-break visuals.  We can try different things and
see what works.  We can invite new developers and new ideas.)

> Thomas said:
> > I like the clickable difference symbols a lot too, but I see
> > problems.  Some of the most important diffs will be to your
> > co-voters, I guess, which are missing here. And the ones to your
> > candidates co-voters, which are missing in Mike's version too.
>
> Right. Btw., I understand Mike's xf mockups in a way that you can
> always view differences by the top right buttons, so you would
> navigate to the person (in the scene/tracks) and then trigger the
> difference view. I have therefore removed it. It is less obvious,
> but if we get the xf HUD right, browsing votespace implicitly might
> work out. This is an issue though for me. Do you have a solution for
> browsing covoters, Mike?

http://zelea.com/project/votorola/s/gwt/stage/_/mock/diff-1.xht

You'll be able to see the user's (Ge.'s) *immediate* co-voters
(Ol. Ev. etc), but not her candidate's (Fr.'s).  Ordinarily Ge. won't
be talking to those folks so we can save the cost of showing them.

Exceptions are handled by pin-ups, as now.  So if Ge. *is* talking to
one of Fr.'s co-voters, or whomever, then she'll probably have a
pin-up for that person and we *will* see that.  Isn't this OK?

We could better place the pin-ups.  Currently they are all lumped
together with the voters (left).  But we could put them left, center
or right depending on whether they are uptree crosstree or downtree.
(I've now tasked this, along with removing the redundant pin-ups.)

Mike

conseo said:
> Hi Thomas et al.,
> 
> Thomas, are you still on IRC from time to time btw.? Others are invited, too. 
> #metagov and #votorola on freenode are the channels. New mockups below...
> 
> > 
> > In my view Conseo's ideas are also very much for 1 usability and 2
> > attracting users, especially the horizontal bridge-layout. I think, for
> > now the best would be, if we could come out with a combined version of
> > your two proposals, instead of two competing ones.
> 
> I think so, too, obviously, but Mike is right that I can't code them myself 
> quickly and that it is better to get the current infrastructure in a usable 
> state (with the old bridge), so users tell us what they need. (At least Mike 
> seems to get some more low-level offlist feedback than us super-alpha-users 
> 8-) ). Would be cool, if this could be shared somehow, Mike?
> If they want a modified bridge layout, we can tackle it then. Since Mike is 
> atm. heavily working on the xf toolbar/HUD, we should get that working with a 
> feed like functionality first. It is easier to write a new module (scene) once 
> the infrastructure is settled and we know how xf works with the tracks and 
> scenes technically. Mike has pointed out that communication is the main 
> attractor and I agree. So I port the difference feed to a track (the 
> smilies/braces) and have to modify the harvester. As this is part of the 
> mockups anyway, I don't see an immediate conflict.
> 
> So this doesn't mean the mockups are in vain. We can collect ideas on the 
> way... Colouring is still an issue imo, for example.
> 
> For reference, I have removed the footings from the scene and put them in a 
> track. This allowed me to radically simplify the horizontal view. (1) The 
> votespace track is a brain storm on how to show it without too much 
> distraction and space loss. With Ed pinned it looks like (2). I have also 
> added a small mugshot to the right caption, giving us a current social network 
> like HUD (like Twitter, Facebook or Diaspora). What do you think?
> 
> Mike has also pointed out that the smilies replicate a lot of information 
> (eyes, shape), which can be stressing on the eyes. So while I would put them 
> in for new users, I would make it themeable or even different tracks, because 
> once you know what it is for the brace view of Mike is less stressing and I 
> would prefer it as well. It is just no good default imo.
> 
> > 
> > That is an interesting use-case. When would that happen? When would you
> > come to the bridge and see an old already matched diff? If I think of
> > something like a diff-history or just an old diff-link, wouldn't it then
> > be better to still show the different texts and just make somehow clear
> > that by now this has changed?
> > 
> 
> I think we need a history track for this. I have put this info in the layout 
> and it looked confusing with a date (time as another hidden dimension). Making 
> it a track makes the dimension configurable and explicit. My old resource 
> track mockups already had some history ideas. (3)
> 
> 
> > I like the clickable difference symbols a lot too, but I see problems.
> > Some of the most important diffs will be to your co-voters, I guess,
> > which are missing here. And the ones to your candidates co-voters, which
> > are missing in Mike's version too.
> 
> Right. Btw., I understand Mike's xf mockups in a way that you can always view 
> differences by the top right buttons, so you would navigate to the person (in 
> the scene/tracks) and then trigger the difference view. I have therefore 
> removed it. It is less obvious, but if we get the xf HUD right, browsing 
> votespace implicitly might work out. This is an issue though for me. Do you 
> have a solution for browsing covoters, Mike?
> 
> > 
> > How, if we had one of Mikes footings atop each draft in the bridge, i.e.
> > two of them? This way we could navigate from within the bridge to truly
> > every diff of the tree. Maybe to much?
> 
> I think so. We have to make the context browsable without showing all 
> information first. This ain't easy... and is the reason why it took so long to 
> get the infrastructure of xf in an implementable state.
> 
> > I like the preview-idea. Maybe it could get a bit more clear, that at
> > this point it is still just a preview and must still be accepted. Maybe
> > "Save preview" on top instead of "Accept selected"?
> > The sliders look a bit confusing to my eyes. hm ...
> 
> Yes the layout and wording is bad. Maybe the "patch" button of Mike is ok. I 
> don't know if people understand patch in this context, it is the software 
> engineering term.
> 
> c
> 
> (1) http://whiletaker.homeip.net/mockups/diffbridge/9/9a.xht
> (2) http://whiletaker.homeip.net/mockups/diffbridge/9/9b.xht
> (3) http://whiletaker.homeip.net/mockups/2g.xht
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.zelea.com/list/votorola/attachments/20120221/f67d79fe/attachment.html>



More information about the Votorola mailing list