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

Einav Cohen ecohen at redhat.com
Thu Nov 14 21:10:54 UTC 2013 

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

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

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

----
Thanks,
Einav

----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "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 3:17:48 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> ----- Original Message -----
> > From: "Michal Skrivanek" <mskrivan at redhat.com>
> > To: "Einav Cohen" <ecohen at redhat.com>
> > Cc: "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>,
> > "Eldan Hildesheim" <ehildesh at redhat.com>,
> > "info" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, November 14, 2013 2:21:03 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > 
> > On Nov 14, 2013, at 00:09 , Einav Cohen <ecohen at redhat.com> wrote:
> > 
> > >> ... but we may have to see how this looks when multiple sparklines
> > >> reside in columns next to each other.
> > >> ...
> > >> ...
> > >> Is this going to fit in a row of a table? Or are we talking of a
> > >> more detailed view?
> > >> ...
> > > 
> > > a concern on which I happened to briefly discuss with Eldan / Malini
> > > and actually somewhat raised here earlier in the thread (see above):
> > > Since we are adding another information "dimension" (time), we are
> > > actually going to display a lot more information to the user within the
> > > CPU/MEM/NET columns, and there is a chance that the view will become
> > > too overloaded/confusing, and we will end up with a view that is less
> > > clear than the current one.
> > 
> > Well, for that we IMHO have much bigger issue already with the fact we do
> > not
> > hide/show columns, and many of them do not really provide much value in all
> > use cases. If you look at the mockup and the screenshots from users I've
> > seen  - e.g. the Display column(don't care), the Cluster (not wide enough,
> > repetition of the same info on each line), Host(repetition of domain parts
> > of FQDN) makes it overloaded already.
> 
> Agreed and I think we should address that and some efforts in terms of
> designs are underway for some of these issues. However, I think Einav's
> point was about increasing the amount of info in each of those 3 columns
> exponentially since it is a trend and not a single value. Having said that,
> I think the trend represented as a sparkline/ trendline is not meant to give
> you that many more datapoints - It gives you the current value and an idea
> of the trend based on the 'shape' of the trend line and not the individual
> peaks and troughs. So I think it is not that much of a leap in terms of the
> cognitive overload.
> 
> > Since statistics do provide some value and it keeps changing based on load
> > it
> > IMHO looks ok
> 
> I think the question in my mind here is if the trendline is indeed a better
> visualization for all these three attributes? In other words, is a trend for
> the memory as valuable as a trend for network or CPU? Or is it more useful
> for the user to see the current visualization for memory that fills the bar
> as it gets closer to 100% and turns red? The point I am trying to make is
> that the trendline/ sparkline is not necessarily a widget with cognitive
> overload but it is still worth considering if it is the right data
> visualization for the attribute. So is it possible that only one or more of
> these attributes is a sparkline?
> 
> 
> > ...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.
> 
> 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...
> 
> > 
> > > 
> > > Just so we will have a general idea of how it will look like eventually,
> > > so we will be able to do a slightly more educated decision, I am
> > > attaching
> > > a mock-up of how it looks now compared to how it may look once this
> > > feature is implemented.
> 
> Einav, the mockup looks awesome.. you beat me to it! :) Also, after looking
> at the mockup, I am less worried about the 3 sparkline columns displaying
> next to each other especially because the current value breaks the lines
> from all merging together.
> 
> 
> > > 
> > > * In my mock-up, I followed Malini's guideline from earlier in the
> > > thread:
> > > """
> > > One color with a dot to indicate the most recent or most relevant data
> > > and display its value next to the sparkline
> > > """
> 
> I think Sparklines lend themselves less to status/ threshold indicators that
> rely on color. One example that I found potentially acceptable is
> http://chandoo.org/img/2010/introduction-to-excel-sparklines.png. In our
> case, the current value dot can be red, green or any other color based on
> the ranges defined and the colors associated with it. 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.
> 
> 
> > 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.
> 
> 
> > 
> > > 
> > > * keep in mind that the view is dynamic and keeps updating once it
> > > receives new statistics from the backend.
> > > 
> > > Thoughts?
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Malini Rao" <mrao at redhat.com>
> > >> To: "Tomas Jelinek" <tjelinek at redhat.com>
> > >> Cc: "Einav Cohen" <ecohen at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > >> <ehildesh at redhat.com>, "info" <info at eldanet.com>, "Martin Polednik"
> > >> <mpoledni at redhat.com>
> > >> Sent: Wednesday, November 6, 2013 10:24:56 AM
> > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >> 
> > >> Hey all,
> > >> 
> > >> Comments inline-
> > >> 
> > >> 
> > >> 
> > >> ----- Original Message -----
> > >>> From: "Tomas Jelinek" <tjelinek at redhat.com>
> > >>> To: "Einav Cohen" <ecohen at redhat.com>
> > >>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > >>> <ehildesh at redhat.com>, "info" <info at eldanet.com>,
> > >>> "Malini Rao" <mrao at redhat.com>, "Martin Polednik" <mpoledni at redhat.com>
> > >>> Sent: Wednesday, November 6, 2013 9:58:03 AM
> > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>> 
> > >>> Hi Einav,
> > >>> 
> > >>> ----- Original Message -----
> > >>>> From: "Einav Cohen" <ecohen at redhat.com>
> > >>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > >>>> <ehildesh at redhat.com>, "info" <info at eldanet.com>,
> > >>>> "Malini Rao" <mrao at redhat.com>
> > >>>> Sent: Wednesday, November 6, 2013 3:26:15 PM
> > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>>> 
> > >>>> Hi Tomas,
> > >>>> 
> > >>>> Like Itamar, I think that a line chart is a better idea, and that a
> > >>>> chart per monitored fact (rather than a combined chart) is better.
> > >>> 
> > >>> OK
> > >> 
> > >> Based on the original request in the bug, it seems like Itamar is
> > >> looking
> > >> for
> > >> a trend rather than just one data point. I think we are thinking along
> > >> the
> > >> correct lines here with a line graph but I think more specifically, we
> > >> should consider sparklines -
> > >> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
> > >> that we should have one sparkline per fact but we may have to see how
> > >> this
> > >> looks when multiple sparklines reside in columns next to each other. See
> > >> example of a grid where there are 2 sparklines next to each other -
> > >> http://www.panopticon.com/Tables-Grids
> > >> 
> > >>> 
> > >>>> 
> > >>>>>> the statistics readable enough. Maybe if you hover the chart it
> > >>>>>> could
> > >>>>>> pop
> > >>>>>> up a bigger version of the chart? Or not needed?
> > >>>> 
> > >>>> this is a nice-to-have, I think, definitely not needed.
> > >>> 
> > >>> OK
> > >> 
> > >> Agree. As shown in the glucose example in the Tufte link I posted above,
> > >> maybe all we need is to indicate the acceptable range with a band and if
> > >> the
> > >> last point is in the range or outside, it will be clear to the user if
> > >> they
> > >> should pay attention to it.
> > >> 
> > >> 
> > >>> 
> > >>>> 
> > >>>>>> - Would it be enough to have it in one color? Or should it be
> > >>>>>> something
> > >>>>>> like "the bigger the utilization the more red"?
> > >>>> 
> > >>>> question is what will happen when there are a lot of "jumps": let's
> > >>>> say
> > >>>> that the graph changes from 0% to 100% to 0% to 100% and so on... what
> > >>>> will be painted red? the entire line, but only in the periods that it
> > >>>> jumps to 100%? only the parts of line that are in 100%?
> > >>>> maybe a single color is enough.
> > >>> 
> > >>> OK
> > >>> 
> > >> 
> > >> One color with a dot to indicate the most recent or most relevant data
> > >> and
> > >> display its value next to the sparkline
> > >> 
> > >> 
> > >>>> 
> > >>>> I have another concern about this feature: currently, the GUI's most
> > >>>> frequent
> > >>>> refresh rate available is 5 seconds, which means that the line will
> > >>>> "change"
> > >>>> only every 5 seconds, which would be more noticeably slow when
> > >>>> displayed
> > >>>> in
> > >>>> a form of a line chart (not even talking about lower frequencies).
> > >>>> Moreover, I am not sure at what rate the VM statistics are pulled from
> > >>>> VDSM,
> > >>>> but if it is 10 seconds or 15 seconds, it means that the line in the
> > >>>> GUI
> > >>>> will
> > >>>> be "flat" for every 2 reads / 3 reads, which is not so good, I think.
> > >>>> 
> > >>>> any thoughts around that?
> > >>> 
> > >>> Good point! AFAIK the VDSM is polled each 3 seconds for basic info
> > >>> (e.g.
> > >>> the
> > >>> resource
> > >>> usage not included) and than every 5th poll (e.g. every 15 seconds) for
> > >>> full
> > >>> data
> > >>> (with resource usage not included). This would indeed make the graph
> > >>> pretty
> > >>> useless.
> > >>> 
> > >>> Michal proposed to do some averages on the VDSM site from more frequent
> > >>> sampling and
> > >>> send this average back to engine when polled - so we would display an
> > >>> average
> > >>> after each poll (15s).
> > >>> 
> > >>> I wonder if something like this is not already used on other places:
> > >>> @Martin, do you know about something like this?
> > >> 
> > >> Why does the change in the line need to seem palpable every few seconds?
> > >> I
> > >> think the base requirement of how accurate the data is when a user looks
> > >> at
> > >> a grid has not changed.. just the data visualization. Right? So , if the
> > >> refresh rate is not a problem today, why is it a problem now? Am I
> > >> missing
> > >> something?
> > >> 
> > >> 
> > >>> 
> > >>> 
> > >>>> 
> > >>>> ----- Original Message -----
> > >>>>> From: "Itamar Heim" <iheim at redhat.com>
> > >>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>, "engine-devel"
> > >>>>> <engine-devel at ovirt.org>
> > >>>>> Sent: Tuesday, November 5, 2013 10:10:34 AM
> > >>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>>>> 
> > >>>>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
> > >>>>>> Hi all,
> > >>>>>> 
> > >>>>>> There is a feature request [1] which aims to replace the resource
> > >>>>>> utilization graphs (for example the cpu utilization from vm tab) by
> > >>>>>> some
> > >>>>>> which shows not only
> > >>>>>> the actual percentage which is not so useful by some monitor graph.
> > >>>>>> 
> > >>>>>> I have the following concerns:
> > >>>>>> - I can think of a bar chart or a line chart and not sure what would
> > >>>>>> be
> > >>>>>> better.
> > >>>>>> - Not sure if replacing the current chart with a bar/line chart
> > >>>>>> would
> > >>>>>> make
> > >>>>>> the statistics readable enough. Maybe if you hover the chart it
> > >>>>>> could
> > >>>>>> pop
> > >>>>>> up a bigger version of the chart? Or not needed?
> > >>>>>> - Would it be enough to have it in one color? Or should it be
> > >>>>>> something
> > >>>>>> like "the bigger the utilization the more red"?
> > >>>>>> 
> > >>>>>> Please advise from the UX perspective. As soon as the final design
> > >>>>>> will
> > >>>>>> be
> > >>>>>> a bit more clear I will provide a feature page.
> > >>>>>> 
> > >>>>>> Thank you,
> > >>>>>> Tomas
> > >>>>>> 
> > >>>>>> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
> > >>>>>> _______________________________________________
> > >>>>>> Engine-devel mailing list
> > >>>>>> Engine-devel at ovirt.org
> > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>> 
> > >>>>> 
> > >>>>> a moving trend graph (just like fedora's system monitor for
> > >>>>> cpu/ram/network) is what i have in mind. so a line chart.
> > >>>>> you could have a single chart with different lines for
> > >>>>> cpu/ram/network,
> > >>>>> or what seems to be more common, a chart per monitored fact
> > >>>>> _______________________________________________
> > >>>>> Engine-devel mailing list
> > >>>>> Engine-devel at ovirt.org
> > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>> 
> > >>> 
> > > <trendline-mockup.png>
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trendline-mockup--axes-colors.png
Type: image/png
Size: 700899 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20131114/bbb31c46/attachment-0001.png>

More information about the Devel mailing list