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

[Malini Rao]

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Eldan Hildesheim" <ehildesh at redhat.com>, "Users at ovirt.org" <users at ovirt.org>
> Cc: "Malini Rao" <mrao at redhat.com>, "info" <info at eldanet.com>, "Michal Skrivanek" <mskrivan at redhat.com>, "Thomas
> Jelinek" <tjelinek at redhat.com>
> Sent: Monday, November 18, 2013 2:57:13 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> 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.
> > 
> > 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.

Do we know this for a fact? Can someone with a grasp on requirements/ users of the tool weigh in here and confirm this? In talking to users before, I have heard that they found Monitoring entities hard in Ovirt but I have not had a chance to gather more info around whether it is VM monitoring or monitoring hosts and storage to decide what resources to use as a basis for the VM creation that is hard. In talking to users, I have gathered VM creation and monitoring are both common tasks but I am not sure if one trumps the other. I guess the main question here is - Is there a need for a separate monitoring view or is it tightly integrated with the management of entities? 


> > The extra information, completely grabs the attention. Just imagine the
> > screen when all the data refreshes (fast and slow animations enclosed)

Agreed. The info does grab attention. However, the fast animation is not a scenario that is reasonable. Having said that, even if the rows updated every 15-30 secs all at once, it could be a disturbing experience. I have been raising this as a concern and wonder how important a real time trend is in this context. Can we not have the trend up to the time of the page load and reload every time the user navigates out and comes back and additionally have a refresh button for a manual refresh? As mentioned before, I am trying to understand if (1) all 3 columns need to be visualized the same way and (2) If the frequent updates are necessary. I don't think a trendline/ sparkline in itself is too much info.. it is the constant updating that makes it too much.


> > 
> > 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.

I think this 'Monitor' tab exists in the user portal and presents exactly the same info presented in these columns when it can infact present far more as Eldan suggests here. But once again, examining the core need here, why is the user looking for such metrics? If they have to look across hosts to determine consumption and then decide where to create another VM, then a per host view of these metrics is harder to use. So, it will be useful to know the underlying goals and motivations of the user here.  

> > In case this is not enough, we can do something with the monitor tab or
> > even
> > create a new view dedicated for monitoring.
 
Agreed. But this doesn't mean some high level metric can't be presented elsewhere and drilling for any detail leads to this view. 

> > 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)

Again, points to the need for more complete requirements.

> > 
> > 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