TrackStack mockup help request

[Michael Allan]

Dear C and Alex,

alex at twister11.de wrote:
> ... Because the progress bar is about the amount of us dollars
> donated and the large green numbers are about the votes donated. ...

All numbers are dollars in this view.  No votes are shown.  See here
for example: http://zelea.com/y/vw/xf/#a=qUS$&c=DV&s=G!p!sandbox*1
To show the votes, you must select the "Votes" superaccount instead of
"US$" (top left).

> If thats not the case, ...means if green numbers correlate with the
> size of a progress-bar-part, then why is the part of "Dm." so small
> compared to his green number?

http://whiletaker.homeip.net/mockups/4/4.ns.hov.vs.xht
I'm also confused.  There are only 4 users in the outer semi-circle
(voting for Dm.), one of whom is is under the mouse.  But the track
shows 10 segements.  I think the track represents the currently
selected "circle", and so there should be a single segment per user.

conseo wrote:
> Issues:
> 1. Does anybody see any problems with the Track? I haven't changed
> it.

The basic track (arrows and segments) is excellent.  I have been
trying not to think about the other details, because I think they
distract from the main design problem.  See below.

> 2. I have decided to make non-permanent text in the HUD italic,
> which seperates from the static Ui. Using the HUD for the toolbar
> would also allow to display tooltips better imo. The main problem
> with the HUD is that we may not show too much text, because it would
> flicker too much. Mike, I have done it just to see what is needed in
> the HUD for the trackstack, not to recommend a specific layout.

I'm OK with you mocking up the HUD.  It's shared between track and
votespace proper, but it doesn't affect the design of votespace.  The
placement of the HUD (below left of track) is also OK.  I think its
text should always be non-permanent, as you say (instead of "heads up
display", we could almost call it "hover up").  It should show the
minimum of information the user needs to decide whether or not to
click on whatever is under the mouse.  So generally this is OK.

> 3. Any other issues?

I still feel that navigation is the #1 design problem for this
particular track.  The other details and doodads are clouding the
issue (at least for me).  I would like to see what happens after
clicking on a track segment (= user node in votespace).  Maybe draw a
series of 3 mockups showing the structural changes in both track and
votespace.  You can copy the SVG unchanged from the existing votespace
mockups.  There's no need to draw anything new in votespace, I can
take care of that.  Maybe just focus on the structure of the track:
http://zelea.com/project/votorola/a/xf/vote/_/1.xht
http://zelea.com/project/votorola/a/xf/vote/_/2.xht
http://zelea.com/project/votorola/a/xf/vote/_/3.xht
(see parent directory for SVG source)

-- 
Michael Allan

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


conseo wrote:
> Hi,
> 
> I have been busy with university lately, sorry for the delay.
> 
> I have a new round of mockups (1), showing HUD hover information below the 
> (yet single) track and the highlighting of track when you hover a node in 
> votespace (2) and vice versa (3). All non-core information is removed for now 
> and votespace is only visualized to get the combined information. I have also 
> mocked up the information shown in the embedded view (embedded on the 
> difference bridge, for example) without any interaction (4) and on hover of a 
> track (no selection possible, it is fixed on one position) (5).
> Hovering over the empty section will show a missing information in the HUD 
> (6), target information is shown on both ends of the Track (7)
> 
> I have also moved the tooltip information of the Toolbar to the HUD, for both 
> left caption (8) and the pledge/vote button (9).
> 
> Issues:
> 1. Does anybody see any problems with the Track? I haven't changed it. 
> 2. I have decided to make non-permanent text in the HUD italic, which 
> seperates from the static Ui. Using the HUD for the toolbar would also allow 
> to display tooltips better imo. The main problem with the HUD is that we may 
> not show too much text, because it would flicker too much. Mike, I have done 
> it just to see what is needed in the HUD for the trackstack, not to recommend 
> a specific layout.
> 3. Any other issues?
> 
> 
> conseo
> 
> (1) http://whiletaker.homeip.net/mockups/4
> (2) http://whiletaker.homeip.net/mockups/4/4.ns.hov.vs.xht
> (3) http://whiletaker.homeip.net/mockups/4/4.ns.hov.ts.xht
> (4) http://whiletaker.homeip.net/mockups/4/4.ns.em.xht
> (5) http://whiletaker.homeip.net/mockups/4/4.ns.hov.ts.em.xht
> (6) http://whiletaker.homeip.net/mockups/4/4.ns.hov.tempty.xht
> (7) http://whiletaker.homeip.net/mockups/4/4.ns.hov.ttarget.xht
> (8) http://whiletaker.homeip.net/mockups/4/4.ns.hov.leftcapt.xht
> (9) http://whiletaker.homeip.net/mockups/4/4.ns.hov.pledge.xht


alex at twister11.de wrote:
> One idea popped to my mind, when i was looking at the new mockups.
> 
> Each "progress part" of the ressource bar represents one "member".
> e.g. "Dm." represents the dark gray progress part.
> 
> Am I right? If yes... read on, else forget about what i say :P
> 
> ...So it's possible that Voter's with large green numbers correspond
> to small progress bars and people with small big green numbers
> represent large progress bars.
> Because the progress bar is about the amount of us dollars donated and
> the large green numbers are about the votes donated.
> I thought, each ressource might theoretically be of equal importance.
> So why are votes presented in a circle and donated US Dollars are
> presented as a proress bar?
> 
> If thats not the case, ...means if green numbers correlate with the
> size of a progress-bar-part, then why is the part of "Dm." so small
> compared to his green number?
. . .
> -- 
> ______________________
> Alexander Praetorius
> ICQ - 8201955
> Skype - alexander.praetorius
> Facebook - Alexander Praetorius
> Diaspora/Geraspora - Alexander Praetorius
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯