[Engine-devel] [UX] how to design a bar/line chart?
Einav Cohen
ecohen at redhat.com
Thu Nov 7 01:07:08 UTC 2013
Hi Malini,
> 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?
Currently, we display only the "current" value (visualized by a bar), and if
we will go with a line chart, which is displaying also some of the previous
values and is sort-of "progressing" on each refresh, I think that it might
look weird if it will progress slowly.
typically, when looking at this sort of progressing line chart (like a
performance/CPU monitor in your computer task manager or similar), you
expect the frequency to be ~1 second or so. With a slower frequency,
it may seem like the graph is occasionally "stuck". I agree that the
current state is not ideal either, but it is definitely more "acceptable"
than how I think it would be with a line chart.
Moreover, there's the non-sync'd frequencies that I mentioned earlier. I.e.
if the GUI is refreshing every 5 seconds, but the statistics in the backend
are refreshing every 15 seconds (and it doesn't really matter IMO if the new
statistic are an average of some sort or single-point readings) - you are
expected to have "flat" periods in the graph. so it may look something like:
*-----*-----* / ....
\ *-----*-----*
\ /
*-----*-----*
so only every 3rd GUI-refresh-cycle, the graph can potentially "change" the
value, since every "1st" and "2nd" GUI-refresh-cycle, the value in the
backend still hasn't changed (again, since the refresh rate on the backend
side is lower than the one in the GUI).
----
Thanks,
Einav
----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "info" <info at eldanet.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
> > > >
> > > >
> > > >
> > >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
More information about the Engine-devel
mailing list