[Engine-devel] [UX] how to design a bar/line chart?
Eldan Hildesheim
ehildesh at redhat.com
Mon Nov 18 13:12:57 UTC 2013
Hi,
Those are very nice mockups :)
I still think it's TOO MUCH information.
I spoke with many workers here regarding this issue.
First: None of the PMs here know about this new feature. Why?
What we have now is a screen with too much noise.
As I see it, most of the users comes to the VM’s screen for creating/modifying VMs, not for Monitoring.
The extra information, completely grabs the attention. Just imagine the screen when all the data refreshes (fast and slow animations enclosed)
I do think we need a Monitor or even a Trend view, we can hook on the lower tab platform and show the info per VM.
Another option is rollover the vm and gaining the bar as a tooltip.
We can then show a monitor or a bigger reasonable x axis scale (even 24 hrs), the data can be grabbed from Jasper as well.
In case this is not enough, we can do something with the monitor tab or even create a new view dedicated for monitoring.
BTW, after talking with Miky Keneth, the following issue was risen:
Should we show the cpu/mem/net according to the Guest perspective or as a percentage of the Host (VMware shows both)
Eldan
----- 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 11:32:15 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Agreed! Also just as it is inaccurate to draw the sparkline in one of the other colors based on the current value, I htink it is also inaccurate to draw the sparklines in green since it has a specific meaning. I think the lines should all be dark gray or black and only the markers and the red numbers should be the color elements.
-Malini
----- 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 3:26:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> ----- 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: bar_graph_ani2.gif
Type: image/gif
Size: 157660 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131118/3a7e5241/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bar_graph_ani3.gif
Type: image/gif
Size: 157699 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131118/3a7e5241/attachment-0001.gif>
More information about the Engine-devel
mailing list