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

Thu Nov 7 07:35:55 UTC 2013

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