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

Malini Rao mrao at redhat.com
Thu Nov 14 20:17:48 UTC 2013 

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

More information about the Engine-devel mailing list