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

Einav Cohen ecohen at redhat.com
Fri Nov 15 19:32:21 UTC 2013 

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

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.
> 
> 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
> > > 
> > > 
> > >
> 
> _______________________________________________
> 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: shaped-markers--colored-numbers.png
Type: image/png
Size: 700913 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20131115/d550b987/attachment-0002.png>
-------------- 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/devel/attachments/20131115/d550b987/attachment-0003.png>

More information about the Devel mailing list