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

Einav Cohen ecohen at redhat.com
Fri Nov 15 20:26:10 UTC 2013 

> ----- 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.
> > > 
> > > 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--red-text-bold.png
Type: image/png
Size: 701437 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131115/ac9f0e63/attachment.png>

More information about the Engine-devel mailing list