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

Malini Rao mrao at redhat.com
Fri Nov 15 18:35:57 UTC 2013 

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

I am not sure how much value the axes provide as it is still pretty hard to tell the difference from 0 to 20. As long as there are no negative values, do we really need the axes? If we do, Einav's mockup is pretty good in terms of representing the axes since it is not looking cluttered.

> 
> ----
> 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: Colored sparklines.fw.png
Type: image/png
Size: 1289740 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131115/002fe183/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shaped markers.fw.png
Type: image/png
Size: 1285707 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131115/002fe183/attachment-0001.png>

More information about the Engine-devel mailing list