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

Justin Hammond justin at dynam.ac
Wed Nov 6 17:19:40 UTC 2013


Not directly related, but it would be good if the UI could also display disk activity per VM and overall for a host. 

I've got a few disk intensive VM's or the occasional memory starved VM that kills disk throughput for other VM's. it's always a struggle to identify them , so something in the UI would help me as a admin

Sent from my iPhone

On 6 Nov, 2013, at 11:45 PM, "Alexander Wels" <awels at redhat.com> wrote:

> I suppose we need to answer a few questions before we can go into which 
> library is better:
> 
> 1. Do we mind sending data over to Google so Google can render images for us.
> 2. Are we fine with just an image being displayed in the grid? If we aren't 
> okay with #1, we will have to create some sort of servlet to generate the 
> images.
> 3. Do we want the client to render the spark lines using javascript?
> 4. Do we want interactivity with these visualizations? For instance if I move 
> my mouse over the spark line, does the value displayed change?
> 5. Can we display whatever we choice in our current grid implementation? I 
> know the amount of javascript we can apply to it is somewhat limited right 
> now.
> 6. Any other consideration I am not thinking of? 
> 
> Alexander
> 
> On Wednesday, November 06, 2013 11:03:06 AM Malini Rao wrote:
>> Is this a possibility?  Looks nicer. http://style.org/chartapi/sparklines/
>> 
>> ----- Original Message -----
>> From: "Alexander Wels" <awels at redhat.com>
>> To: engine-devel at ovirt.org
>> Cc: "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>,
>> "Eldan Hildesheim" <ehildesh at redhat.com>, "info" <info at eldanet.com> Sent:
>> Wednesday, November 6, 2013 10:46:01 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>> 
>> Maybe gchart is an option? Examples available here [1] one of the available
>> charts is a spark line. I just don't know how well that will play with our
>> grid implementation.
>> 
>> [1]
>> http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gcha
>> rt/client/package-summary.html#ChartGallery
>> On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
>>> 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
> 
> _______________________________________________
> 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