[Engine-devel] [UX] how to design a bar/line chart?

Einav Cohen ecohen at redhat.com
Mon Nov 18 19:57:13 UTC 2013 

moving this discussion to the users mailing list, to get some more oVirt users' 
feedback this matter.
context is [1]; 
see attached to see comparison of current state and suggestion; 
see below for engine-devel correspondence so far.

----
Thanks,
Einav

[1] Bug 803251 - improve the resource usage graph for VM cpu/memory/network
[https://bugzilla.redhat.com/show_bug.cgi?id=803251]

----- Original Message -----
> From: "Eldan Hildesheim" <ehildesh at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: "info" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>, "Michal Skrivanek" <mskrivan at redhat.com>
> Sent: Monday, November 18, 2013 8:12:57 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Hi,
> Those are very nice mockups :)
> 
> I still think it's TOO MUCH information.
> I spoke with many workers here regarding this issue.
> First: None of the PMs here know about this new feature. Why?
> 
> What we have now is a screen with too much noise.
> As I see it, most of the users comes to the VM’s screen for
> creating/modifying VMs, not for Monitoring.
> The extra information, completely grabs the attention. Just imagine the
> screen when all the data refreshes (fast and slow animations enclosed)
> 
> I do think we need a Monitor or even a Trend view, we can hook on the lower
> tab platform and show the info per VM.
> Another option is rollover the vm and gaining the bar as a tooltip.
> We can then show a monitor or a bigger reasonable x axis scale (even 24 hrs),
> the data can be grabbed from Jasper as well.
> In case this is not enough, we can do something with the monitor tab or even
> create a new view dedicated for monitoring.
> BTW, after talking with Miky Keneth, the following issue was risen:
> Should we show the cpu/mem/net according to the Guest perspective or as a
> percentage of the Host (VMware shows both)
> 
> Eldan
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "info" <info at eldanet.com>, "Michal Skrivanek"
> <mskrivan at redhat.com>
> Sent: Friday, November 15, 2013 11:32:15 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> Agreed! Also just as it is inaccurate to draw the sparkline in one of the
> other colors based on the current value, I htink it is also inaccurate to
> draw the sparklines in green since it has a specific meaning. I think the
> lines should all be dark gray or black and only the markers and the red
> numbers should be the color elements.
> 
> -Malini
> 
> ----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "info" <info at eldanet.com>, "Michal Skrivanek"
> <mskrivan at redhat.com>
> Sent: Friday, November 15, 2013 3:26:10 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> > ----- Original Message -----
> > From: "Malini Rao" <mrao at redhat.com>
> > Sent: Friday, November 15, 2013 2:55:20 PM
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Malini Rao" <mrao at redhat.com>
> > > Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "info" <info at eldanet.com>,
> > > "Michal Skrivanek" <mskrivan at redhat.com>
> > > Sent: Friday, November 15, 2013 2:32:21 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > > Also, I am glad you are always presenting current and proposed together
> > > > as
> > > > it
> > > > allows for effective comparison. I think it is safe to say that it is
> > > > easier
> > > > to discern the VMs that need attention in the current view than in the
> > > > proposed view because there is more color there than in a small dot.
> > > 
> > > +1
> > > 
> > > > As an experiment, I tried to render the entire sparkline in the color
> > > > of
> > > > the
> > > > current value ( See attached) - It is more effective in the
> > > > scannability
> > > > aspect but it is painting all values in the color of the current value
> > > > which
> > > > is not technically accurate. What do you guys think?
> > > 
> > > Malini, I agree with the above: it is more effective in the scannablity
> > > aspect,
> > > but misleading due to the entire trend being represented by a color that
> > > actually represents only the last reading.
> > > For better scannability without the misleading aspect, I was thinking
> > > about
> > > coloring the text next to the dot in the same color. we can also think
> > > about
> > > marking in bold this text when it is orange and/or red, for even better
> > > scannability (that will be helpful also for color-blind users).
> > > see attached "shaped-markers--colored-numbers.png" for demonstration (in
> > > this
> > > mock-up, I marked bold only the red text).
> > 
> > I like it. But to take it even further and to remove any contrast issues
> > affecting readability, I would only change the color and bold the red
> > numbers. Rest should all be regular text. That will truly call out the ones
> > in the red zone which are the ones that need attention. The colored shaped
> > markers will still accurately reveal all other values in and their
> > associated status range.
> > What say?
> 
> good idea, Malini - indeed the red ones are standing out more clearly in
> this case (see attached).
> 
> > 
> > 
> > > 
> > > thoughts?
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > 
> > > ----- Original Message -----
> > > > From: "Malini Rao" <mrao at redhat.com>
> > > > To: "Einav Cohen" <ecohen at redhat.com>
> > > > Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, "info" <info at eldanet.com>,
> > > > "Michal Skrivanek" <mskrivan at redhat.com>
> > > > Sent: Friday, November 15, 2013 1:35:57 PM
> > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > To: "Malini Rao" <mrao at redhat.com>, "Michal Skrivanek"
> > > > > <mskrivan at redhat.com>
> > > > > Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>, "info" <info at eldanet.com>
> > > > > Sent: Thursday, November 14, 2013 4:10:54 PM
> > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > > > 
> > > > > > > ...maybe just a global setting to disable this if it gets
> > > > > > > annoying?
> > > > > > > It's
> > > > > > > a
> > > > > > > small feature and it's trivial to add such a setting.
> > > > > > 
> > > > > 
> > > > > @Michal: I am not sure what you mean by "disable"; if you mean "hide
> > > > > (the
> > > > > columns)",
> > > > > then I think that we should rely on the global "show/hide columns"
> > > > > feature,
> > > > > and
> > > > > not create a dedicated configuration value for these particular
> > > > > columns.
> > > > > Moreover,
> > > > > the global "show/hide columns" feature will allow customization per
> > > > > user/client,
> > > > > rather than a global-configuration-level customization, so each user
> > > > > will
> > > > > be
> > > > > able
> > > > > to define his view as he wishes.
> > > > > 
> > > > > > I am averse to turning it off completely since it will be less than
> > > > > > what
> > > > > > they
> > > > > > have today but may be if they are displaying a trend, they should
> > > > > > be
> > > > > > able
> > > > > > to
> > > > > > choose to only see the current value...
> > > > > 
> > > > > @Malini, do you mean that they need the option to "fallback" to the
> > > > > current
> > > > > "bar"
> > > > > design (which reflects only the current value)? or something else?
> > > > 
> > > > My preference is to choose a suitable visualization and not have any
> > > > other
> > > > view options. I think the ability to add or remove that column is
> > > > sufficient
> > > > should a user not find value in these columns. I merely suggested the
> > > > fall
> > > > back option instead of having a setting to turn these columns off
> > > > altogether
> > > > permanently.
> > > > 
> > > > 
> > > > > 
> > > > > > ... If we have colored dots, we should possibly change the shape of
> > > > > > the
> > > > > > marker
> > > > > > too for each color so that color blind people can still find value
> > > > > > on
> > > > > > this
> > > > > > as
> > > > > > a status indicator.
> > > > > 
> > > > > I like the idea of colored dots; not sure about the different shapes
> > > > > though,
> > > > > as
> > > > > the dots would be pretty tiny; in the color-blind case: wouldn't it
> > > > > be
> > > > > sufficient
> > > > > to rely on the dot "height" + the textual value?
> > > > 
> > > > I am not sure it is enough - Height and text are available for all
> > > > users
> > > > including those that are not colorblind and the color of the dot is an
> > > > additional data point that they will miss out on if we didn't do the
> > > > shape.
> > > > I think even at this size, it will be easy to distinguish a circle from
> > > > a
> > > > triangle and a square. Having more than that may be tricky.( See
> > > > attached)
> > > > 
> > > > Also, I am glad you are always presenting current and proposed together
> > > > as
> > > > it
> > > > allows for effective comparison. I think it is safe to say that it is
> > > > easier
> > > > to discern the VMs that need attention in the current view than in the
> > > > proposed view because there is more color there than in a small dot. As
> > > > an
> > > > experiment, I tried to render the entire sparkline in the color of the
> > > > current value ( See attached) - It is more effective in the
> > > > scannability
> > > > aspect but it is painting all values in the color of the current value
> > > > which
> > > > is not technically accurate. What do you guys think?
> > > > 
> > > > > 
> > > > > > > Thanks for the mock up, I think it looks great. Perhaps I'd
> > > > > > > consider
> > > > > > > lines
> > > > > > > instead of dots (to see the base 0, currently the line is somehow
> > > > > > > "in
> > > > > > > the
> > > > > > > air" and since the height is limited it may be difficult to
> > > > > > > distinguissh
> > > > > > > 20%
> > > > > > > from 0%), provided they are in some light color it may look ok
> > > > > > 
> > > > > > I am not sure I completely understand the request here. Is there a
> > > > > > need
> > > > > > to
> > > > > > clearly mark the zero/baseline here? Or need multiple dots to
> > > > > > highlight
> > > > > > various values on the line? Or are we needing a band like this
> > > > > > (https://www.broadbandmetrics.com/download/attachments/3768372/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000)
> > > > > > to mark the desirable range? One thing I want to make sure we are
> > > > > > on
> > > > > > the
> > > > > > same page is that the sparkline is definitely not a good widget to
> > > > > > distinguish small or accurate changes but more the current position
> > > > > > in
> > > > > > relation to the overall shape.
> > > > > 
> > > > > I think that we are all on the same page here (others - please
> > > > > correct
> > > > > me
> > > > > if
> > > > > I am wrong) that only the general trend is of interest here, and not
> > > > > the
> > > > > exact
> > > > > values (maybe with the exception of the "last" value in each
> > > > > trendline).
> > > > > I believe that Michal was referring to axes [in particular the
> > > > > horizontal
> > > > > ('x')
> > > > > axis, I assume] so indeed we will have a clearer baseline for the
> > > > > trend.
> > > > > theoretically we can also have a "band", as you suggested, just need
> > > > > to
> > > > > well-
> > > > > define the "range" of the band so it would makes sense (not sure if
> > > > > easy
> > > > > to
> > > > > do).
> > > > > 
> > > > > I am attaching an updated mock-up with axes (only added for the first
> > > > > few lines) as well as colored dots, as you (Malini) suggested above
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shaped-markers--red-text-bold.png
Type: image/png
Size: 701437 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131118/30013713/attachment.png>

More information about the Engine-devel mailing list