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

Fri Nov 8 15:40:36 UTC 2013

----- 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: Friday, November 8, 2013 3:42:11 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> 
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek 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>
> > Sent: Friday, November 8, 2013 2:55:51 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Malini Rao" <mrao at redhat.com>
> > > To: "Lior Vernia" <lvernia at redhat.com>
> > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, "Eldan Hildesheim"
> > > <ehildesh at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "info" <info at eldanet.com>
> > > Sent: Thursday, November 7, 2013 4:40:35 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > While the technical discussion carries on, I want to go back to the user
> > > requirement here one more time - What is of most value to the user - the
> > > current value accurate to the second level in time ( in which case why do
> > > we
> > > want line chart/ sparklines etc) or a trend of how this entity is doing
> > > in
> > > the last x hours including a 'sense' of where it is at this time? If a
> > > second to second difference is important to be obvious, then sparklines
> > > or
> > > any other small charting method is possibly not the best way to go. We
> > > may
> > > need to design an entire monitoring view with more detailed graphs for
> > > various measures etc. My impression with this requirement was that it is
> > > valuable for the user to get a sense of the trend for the measure on the
> > > entity just by looking at the shape of the line and the end point gives
> > > you
> > > an 'idea' of where the entity is at so that you can decide if any
> > > investigation is needed or base your decisions on it. I have a hard time
> > > wrapping my head around the possibility that decisions will be influenced
> > > by
> > > data delays of a few secs. In my mind, this is not like a stock ticker...
> > > is
> > > it?
> > 
> > The requirement here (AFAIU) is to have an idea on how the entity is doing
> > -
> > the trend and the actual value
> > so you can take appropriate actions if something is suspicious.
> > 
> > The problem with the 15 sec sampling is not the delay but the completely
> > lost information. It would not be a problem if the resource usage would be
> > rather stable (e.g. the whole 15
> > sec interval the CPU usage is 40%) than we can take the sample once in 15
> > sec, present it to the user and
> > he/she will know if this is OK or not. But this is unfortunately not true
> > (or
> > does not have to be) and the
> > resource usage pretty much jumps up and down. If you take a sample each 15
> > sec you present one random value
> > to the user and he/she can not know what the actual usage is.
> > Imagine this example:
> > sec 1: 100%
> > sec 2: 100%
> > ...
> > sec 10: 100%
> > sec 11: 0%
> > sec 12: 0%
> > sec 13: 0%
> > sec 14: 0%
> > sec 15: 0% <- sample
> > 
> > sec 16: 100%
> > ...
> > And this pattern repeats.
> 
> I thought the system would not just report the sec 15 value but update the
> sparkline with sec 1- 15 at sec 16 and sec 16- 30 at sec 31. So no info is
> lost. No? 

No :) It will just update this one value. Now the question is how often and what value will you get.
I will look into this deeper and get back to this list.

> Is it possible that a change in pattern is not detected until 15
> secs later.. yes. But the question is if that delay is critical and if the
> action/ decision to address it happens in the 15 secs before the next
> refresh.
> 
> > 
> > You will present a user that the CPU usage is stable 0% completely useless
> > (and also incorrect, but mostly useless ;) ).
> > What you want to present instead is stable 66% (which is also incorrect but
> > much more useful).
> > 
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "Lior Vernia" <lvernia 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: Thursday, November 7, 2013 2:35:55 AM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > 
> > > 
> > > 
> > > On 07/11/13 09:26, Tomas Jelinek wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > >> From: "Lior Vernia" <lvernia 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>
> > > >> Sent: Thursday, November 7, 2013 8:03:25 AM
> > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > >>
> > > >> Sorry, obviously I meant RAM usage...
> > > >>
> > > >> On 07/11/13 08:51, Lior Vernia wrote:
> > > >>>
> > > >>>
> > > >>> On 06/11/13 16:26, Einav Cohen wrote:
> > > >>>> 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.
> > > >>>>
> > > >>>>>> 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.
> > > >>>>
> > > >>>>>> - 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.
> > > >>>>
> > > >>>> 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?
> > > >>>>
> > > >>>
> > > >>> If this is indeed an issue, it could be easily solved by delaying the
> > > >>> presentation of the value obtained from VDSM, and at each moment
> > > >>> present
> > > >>> a linear interpolation of the value between the previous input and
> > > >>> the
> > > >>> current input.
> > > >>>
> > > >>> Formally put, let's say T is the measurement period time. If the
> > > >>> value
> > > >>> at time t is f(t), then at time t-T <= t' <= T we would display the
> > > >>> value f(t-2T) + [f(t-T) - f(t-2T]*t'/T, where we control the
> > > >>> increment
> > > >>> rate of t'.
> > > >>>
> > > >>> For example, let's say we get a new value from VDSM every 15 seconds.
> > > >>> 30
> > > >>> seconds ago the CPU usage was 50MB, 15 seconds ago 100MB and now
> > > >>> 200MB.
> > > >>> We decided to update the graph every 3 seconds.
> > > >>>
> > > >>> 15 seconds ago we displayed 50MB (the value from 30 seconds ago). 12
> > > >>> seconds ago we displayed 60MB, 9 seconds ago 70MB, 6 seconds ago
> > > >>> 80MB,
> > > >>> 3
> > > >>> seconds ago 90MB, and now we display 100MB (which is again late by 15
> > > >>> seconds). We will only display 200MB in 15 seconds, after increasing
> > > >>> our
> > > >>> displayed value by 20MB every 3 seconds.
> > > > 
> > > > Hey Lior,
> > > > 
> > > > good idea and certainly better than just draw the current value at each
> > > > refresh.
> > > > We should certainly do this.
> > > 
> > > Just pointing out that it's not necessarily better, as we never actually
> > > draw the current value, we're always late by T (otherwise we'd have
> > > continuity issues as we don't know what future value is coming in the
> > > next measurement). The added benefit is only the feel of constant
> > > updates, at a time period that is independent of the VDSM update period.
> > > 
> > > It might be better to just add a dot whenever we get a new measurement,
> > > and have the dots close enough together for it to look like a nice
> > > graph, and not have it updated constantly.
> > > 
> > > > 
> > > > But this is only one side of the problem - how to visualize it. The
> > > > question is
> > > > how useful the data are if we sample them once in 15 secs. Imagine that
> > > > you
> > > > have
> > > > peeks every ~10 secs which uses 100% of your cpu for ~2 secs. With the
> > > > sampling
> > > > each 15 secs you will see any peek only by luck and certainly not all
> > > > of
> > > > them.
> > > 
> > > Yep, agreed.
> > > 
> > > > 
> > > > But I'm sure we are not the first facing this problem - adding [now the
> > > > correct ;) ]
> > > > Martin as CC:
> > > > 
> > > > @Martin: does the VdsUpdateRunTimeInfo receive the CPU/memory samples
> > > > at
> > > > each 15 secs
> > > > or it receives some sort of average since the last update?
> > > > 
> > > >>>
> > > >>>> ----- 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
> > > >>>>
> > > >>> _______________________________________________
> > > >>> 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
> > > >>
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 