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
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(a)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
> - 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?
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
<engine-devel(a)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
> - 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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
"Malini Rao" <mrao(a)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.
> > 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?
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?
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
> <engine-devel(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
"Malini Rao" <mrao(a)redhat.com>, "Martin Polednik"
<mpoledni(a)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(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> "Malini Rao" <mrao(a)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(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)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(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
>
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/g...
On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
Hey all,
Comments inline-
----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Malini
Rao"
> <mrao(a)redhat.com>, "Martin Polednik" <mpoledni(a)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(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> > "Malini Rao" <mrao(a)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(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > > <engine-devel(a)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(a)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(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Is this a possibility? Looks nicer. http://style.org/chartapi/sparklines/
----- Original Message -----
From: "Alexander Wels" <awels(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>, "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"info" <info(a)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/g...
On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
Hey all,
Comments inline-
----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Malini
Rao"
> <mrao(a)redhat.com>, "Martin Polednik" <mpoledni(a)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(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> > "Malini Rao" <mrao(a)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(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > > <engine-devel(a)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(a)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(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
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(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>,
"Eldan Hildesheim" <ehildesh(a)redhat.com>, "info"
<info(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
"Malini Rao"
> > <mrao(a)redhat.com>, "Martin Polednik"
<mpoledni(a)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(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> > > "Malini Rao" <mrao(a)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(a)redhat.com>
> > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > > > <engine-devel(a)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(a)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(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
I'd say no. Even from a reliability point of view since users may have
systems that aren't connected to the internet. (Though I don't know how
well oVirt handles this currently.)
On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
I'd say no. Even from a reliability point of view since users may have
systems that aren't connected to the internet. (Though I don't know how
well oVirt handles this currently.)
That would eliminate the entire Google charting api as that requires an active
connection to at least retrieve some stuff from www.google.com/jsapi.
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Sent: Thursday, November 7, 2013 11:44:07 AM
On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
I'd say no. Even from a reliability point of view since users may have
systems that aren't connected to the internet.
Hello all,
We use to have a good solution in the period pre-WPF.
A line chart (used to be in flash) that works like a plotter:
The Line Bar (not bar) had a small animation that shifted all the bar to the left.
When a new data arrived it just added a new line (to the right) and as I said before, in
parallel it always shifted slowly to the left.
The animation gives the impression that data is streaming and when a real new data arrives
the user gets it very fast.
We have to sync between the animation and the rate of the arrival of the data but this is
easy.
If we can't find a good framework it can be created from scratch with JS, svg or
canvas.
Now regarding its position:
Rollover is good but not enough, we should somehow put it in the lower panel under general
or even another tab - (live data).
We could later on have a (live data Tab) in other places as well like host, cluster...
Eldan
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
Sent: Friday, November 8, 2013 10:50:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Sent: Thursday, November 7, 2013 11:44:07 AM
On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
I'd say no. Even from a reliability point of view since users may have
systems that aren't connected to the internet.
From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Sunday, November 10, 2013 3:56:57 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Hello all,
We use to have a good solution in the period pre-WPF.
A line chart (used to be in flash) that works like a plotter:
The Line Bar (not bar) had a small animation that shifted all the bar to the
left.
When a new data arrived it just added a new line (to the right) and as I said
before, in parallel it always shifted slowly to the left.
Any chance you still have some screenshot or mockup so I can imagine it better?
The animation gives the impression that data is streaming and when a
real new
data arrives the user gets it very fast.
We have to sync between the animation and the rate of the arrival of the data
but this is easy.
If we can't find a good framework it can be created from scratch with JS, svg
or canvas.
We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1]
but the HTML5 canvas works only since FF23 [2].
@Einav:
Is there a chance that we could start support only FF23+ and IE9+ (this one is already
OK)
because of this feature?
Now regarding its position:
Rollover is good but not enough, we should somehow put it in the lower panel
under general or even another tab - (live data).
This is a bit different requirement. The point of this specific is to give a better
overview in the main tab. If it will be done we can decide if we want to give more
details in sub tabs.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
Sent: Friday, November 8, 2013 10:50:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> ----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> Sent: Thursday, November 7, 2013 11:44:07 AM
>
> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
>
> I'd say no. Even from a reliability point of view since users may have
> systems that aren't connected to the internet.
+1
> (Though I don't know how well oVirt handles this currently.)
AFAIK - oVirt is handling it ('it' == having no internet connection) well.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
------=_Part_27692436_1766844651.1384173203562
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
I will try to make an animation.
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 12:03:15 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Sunday, November 10, 2013 3:56:57 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Hello all,
We use to have a good solution in the period pre-WPF.
A line chart (used to be in flash) that works like a plotter:
The Line Bar (not bar) had a small animation that shifted all the bar to the
left.
When a new data arrived it just added a new line (to the right) and as I said
before, in parallel it always shifted slowly to the left.
Any chance you still have some screenshot or mockup so I can imagine it better?
The animation gives the impression that data is streaming and when a
real new
data arrives the user gets it very fast.
We have to sync between the animation and the rate of the arrival of the data
but this is easy.
If we can't find a good framework it can be created from scratch with JS, svg
or canvas.
We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1]
but the HTML5 canvas works only since FF23 [2].
@Einav:
Is there a chance that we could start support only FF23+ and IE9+ (this one is already
OK)
because of this feature?
Now regarding its position:
Rollover is good but not enough, we should somehow put it in the lower panel
under general or even another tab - (live data).
This is a bit different requirement. The point of this specific is to give a better
overview in the main tab. If it will be done we can decide if we want to give more
details in sub tabs.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
Sent: Friday, November 8, 2013 10:50:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> ----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> Sent: Thursday, November 7, 2013 11:44:07 AM
>
> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
>
> I'd say no. Even from a reliability point of view since users may have
> systems that aren't connected to the internet.
+1
> (Though I don't know how well oVirt handles this currently.)
AFAIK - oVirt is handling it ('it' == having no internet connection) well.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
------=_Part_27720887_2027154847.1384174867925
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Throw this gif into a browser. This is more or less what I thought.
Eldan
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 12:03:15 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Sunday, November 10, 2013 3:56:57 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Hello all,
We use to have a good solution in the period pre-WPF.
A line chart (used to be in flash) that works like a plotter:
The Line Bar (not bar) had a small animation that shifted all the bar to the
left.
When a new data arrived it just added a new line (to the right) and as I said
before, in parallel it always shifted slowly to the left.
Any chance you still have some screenshot or mockup so I can imagine it better?
The animation gives the impression that data is streaming and when a
real new
data arrives the user gets it very fast.
We have to sync between the animation and the rate of the arrival of the data
but this is easy.
If we can't find a good framework it can be created from scratch with JS, svg
or canvas.
We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1]
but the HTML5 canvas works only since FF23 [2].
@Einav:
Is there a chance that we could start support only FF23+ and IE9+ (this one is already
OK)
because of this feature?
Now regarding its position:
Rollover is good but not enough, we should somehow put it in the lower panel
under general or even another tab - (live data).
This is a bit different requirement. The point of this specific is to give a better
overview in the main tab. If it will be done we can decide if we want to give more
details in sub tabs.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
Sent: Friday, November 8, 2013 10:50:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> ----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> Sent: Thursday, November 7, 2013 11:44:07 AM
>
> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
>
> I'd say no. Even from a reliability point of view since users may have
> systems that aren't connected to the internet.
+1
> (Though I don't know how well oVirt handles this currently.)
AFAIK - oVirt is handling it ('it' == having no internet connection) well.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Is this going to fit in a row of a table? Or are we talking of a more detailed view?
----- Original Message -----
From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 8:01:07 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Throw this gif into a browser. This is more or less what I thought.
Eldan
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 12:03:15 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Sunday, November 10, 2013 3:56:57 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Hello all,
We use to have a good solution in the period pre-WPF.
A line chart (used to be in flash) that works like a plotter:
The Line Bar (not bar) had a small animation that shifted all the bar to the
left.
When a new data arrived it just added a new line (to the right) and as I said
before, in parallel it always shifted slowly to the left.
Any chance you still have some screenshot or mockup so I can imagine it better?
The animation gives the impression that data is streaming and when a
real new
data arrives the user gets it very fast.
We have to sync between the animation and the rate of the arrival of the data
but this is easy.
If we can't find a good framework it can be created from scratch with JS, svg
or canvas.
We need to be careful about what we will use. oVirt is supposed to work on FF 17 [1]
but the HTML5 canvas works only since FF23 [2].
@Einav:
Is there a chance that we could start support only FF23+ and IE9+ (this one is already
OK)
because of this feature?
Now regarding its position:
Rollover is good but not enough, we should somehow put it in the lower panel
under general or even another tab - (live data).
This is a bit different requirement. The point of this specific is to give a better
overview in the main tab. If it will be done we can decide if we want to give more
details in sub tabs.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt(a)kohlvanwijngaarden.nl>
Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
Sent: Friday, November 8, 2013 10:50:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> ----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> Sent: Thursday, November 7, 2013 11:44:07 AM
>
> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
>
> I'd say no. Even from a reliability point of view since users may have
> systems that aren't connected to the internet.
+1
> (Though I don't know how well oVirt handles this currently.)
AFAIK - oVirt is handling it ('it' == having no internet connection) well.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
From: "Malini Rao" <mrao(a)redhat.com>
To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "info"
<info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 4:15:50 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Is this going to fit in a row of a table? Or are we talking of a more
detailed view?
----- Original Message -----
From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 8:01:07 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Throw this gif into a browser. This is more or less what I thought.
Eldan
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>,
engine-devel(a)ovirt.org
Sent: Monday, November 11, 2013 12:03:15 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
> Sent: Sunday, November 10, 2013 3:56:57 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> Hello all,
> We use to have a good solution in the period pre-WPF.
> A line chart (used to be in flash) that works like a plotter:
> The Line Bar (not bar) had a small animation that shifted all the bar to
> the
> left.
> When a new data arrived it just added a new line (to the right) and as I
> said
> before, in parallel it always shifted slowly to the left.
Any chance you still have some screenshot or mockup so I can imagine it
better?
> The animation gives the impression that data is streaming and when a real
> new
> data arrives the user gets it very fast.
> We have to sync between the animation and the rate of the arrival of the
> data
> but this is easy.
> If we can't find a good framework it can be created from scratch with JS,
> svg
> or canvas.
We need to be careful about what we will use. oVirt is supposed to work on FF
17 [1]
but the HTML5 canvas works only since FF23 [2].
@Einav:
Is there a chance that we could start support only FF23+ and IE9+ (this one
is already OK)
because of this feature?
> Now regarding its position:
> Rollover is good but not enough, we should somehow put it in the lower
> panel
> under general or even another tab - (live data).
This is a bit different requirement. The point of this specific is to give a
better
overview in the main tab. If it will be done we can decide if we want to give
more
details in sub tabs.
> We could later on have a (live data Tab) in other places as well like host,
> cluster...
> Eldan
[1]: http://www.ovirt.org/Download
[2]: http://caniuse.com/#feat=canvas
>
> ----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
> Sent: Friday, November 8, 2013 10:50:10 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> > ----- Original Message -----
> > From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > Sent: Thursday, November 7, 2013 11:44:07 AM
> >
> > On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
> >
> > I'd say no. Even from a reliability point of view since users may have
> > systems that aren't connected to the internet.
>
> +1
>
> > (Though I don't know how well oVirt handles this currently.)
>
> AFAIK - oVirt is handling it ('it' == having no internet connection) well.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
So we have looked into the resource usage sampling with mbetak and also with Michal and it
seems that
for the CPU usage:
- VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling
interval is configured in
vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
- libvirt returns something we than use to calculate the average CPU usage since the last
poll
- engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds
is just a coincidence and we can not count on this)
- than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and
gets the current value from the engine
- the user can press the refresh button anytime to poll the engine again
For network usage:
- it should be pretty much the same as the CPU just the VDSM poll interval is configured
as vm_sample_net_interval and by default it is 5 seconds
For memory usage:
- guest agent sends a message to VDSM with the memory usage regularly. The interval is set
in ovirt-guest-agent.conf as heart_beat_rate
and by default it is 5 seconds
- the actual value sent by ovirt-guest-agent is the actual value at the time when the
value is sent (e.g. for Linux taken from "cat /proc/meminfo")
- vdsm is doing no statistics on top of it, just remembers the last value taken from
ovirt-guest-agent
- the rest of the poling is the same
So, visualizing this in some usable form will be quite challenging ;)
I see the following problems:
- if the VDSM gets the data faster than the engine polls it (and most often it does) than
the info in between will be lost.
The question is how big this problem is and if it is worth solving (I would say not for
CPU which are averages but maybe yes for memory).
Other question if there is a way how to solve it since the VDSM can be polled by anyone
and it does not really care if someone polls it... (Michal?)
- we can lost some data between frontend<->engine if the polling interval of the FE
is slower than the polling interval of the engine. This is something
not really worth solving because the user can set this according to the level of detail
he/she wants
- since we will get new info once in ~15 seconds, and the polling of the FE is by default
5 seconds, do we want to do some interpolation? Or just show the
same value 3 times? Or be smart and show only changed values? (this is tricky since
there is a chance that it did not change - e.g. constant 0 mem usage if you have no guest
agent)
- What if the user starts clicking to the refresh button? Do we want to keep appending the
same value if the engine still has only the old ones?
Tomas
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info" <info(a)eldanet.com>
Sent: Monday, November 11, 2013 4:23:09 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
> From: "Malini Rao" <mrao(a)redhat.com>
> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "info"
<info(a)eldanet.com>,
> engine-devel(a)ovirt.org
> Sent: Monday, November 11, 2013 4:15:50 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> Is this going to fit in a row of a table? Or are we talking of a more
> detailed view?
it should fit into one cell of the table
>
> ----- Original Message -----
> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
> Sent: Monday, November 11, 2013 8:01:07 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> Throw this gif into a browser. This is more or less what I thought.
> Eldan
>
> ----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>,
> engine-devel(a)ovirt.org
> Sent: Monday, November 11, 2013 12:03:15 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
>
>
> ----- Original Message -----
> > From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
> > Sent: Sunday, November 10, 2013 3:56:57 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > Hello all,
> > We use to have a good solution in the period pre-WPF.
> > A line chart (used to be in flash) that works like a plotter:
> > The Line Bar (not bar) had a small animation that shifted all the bar to
> > the
> > left.
> > When a new data arrived it just added a new line (to the right) and as I
> > said
> > before, in parallel it always shifted slowly to the left.
>
> Any chance you still have some screenshot or mockup so I can imagine it
> better?
>
> > The animation gives the impression that data is streaming and when a real
> > new
> > data arrives the user gets it very fast.
> > We have to sync between the animation and the rate of the arrival of the
> > data
> > but this is easy.
> > If we can't find a good framework it can be created from scratch with JS,
> > svg
> > or canvas.
>
> We need to be careful about what we will use. oVirt is supposed to work on
> FF
> 17 [1]
> but the HTML5 canvas works only since FF23 [2].
>
> @Einav:
> Is there a chance that we could start support only FF23+ and IE9+ (this one
> is already OK)
> because of this feature?
>
> > Now regarding its position:
> > Rollover is good but not enough, we should somehow put it in the lower
> > panel
> > under general or even another tab - (live data).
>
> This is a bit different requirement. The point of this specific is to give
> a
> better
> overview in the main tab. If it will be done we can decide if we want to
> give
> more
> details in sub tabs.
>
> > We could later on have a (live data Tab) in other places as well like
> > host,
> > cluster...
> > Eldan
>
> [1]: http://www.ovirt.org/Download
> [2]: http://caniuse.com/#feat=canvas
>
> >
> > ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
> > Sent: Friday, November 8, 2013 10:50:10 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > > ----- Original Message -----
> > > From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > Sent: Thursday, November 7, 2013 11:44:07 AM
> > >
> > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
> > >
> > > I'd say no. Even from a reliability point of view since users may
have
> > > systems that aren't connected to the internet.
> >
> > +1
> >
> > > (Though I don't know how well oVirt handles this currently.)
> >
> > AFAIK - oVirt is handling it ('it' == having no internet connection)
> > well.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
So we have looked into the resource usage sampling with mbetak and
also with Michal and it seems that
for the CPU usage:
- VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling
interval is configured in
vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
- libvirt returns something we than use to calculate the average CPU usage since the last
poll
- engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds
is just a coincidence and we can not count on this)
- than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and
gets the current value from the engine
- the user can press the refresh button anytime to poll the engine again
For network usage:
- it should be pretty much the same as the CPU just the VDSM poll interval is configured
as vm_sample_net_interval and by default it is 5 seconds
Dan, since we poll only every 15s and cpu info is 15s wouldn't it make sense to change
the default for network monitoring to 15s as well? it's 2 libvirt rounds trip for
nothing really. Or does it serve some other purpose?
For memory usage:
- guest agent sends a message to VDSM with the memory usage regularly. The interval is
set in ovirt-guest-agent.conf as heart_beat_rate
and by default it is 5 seconds
- the actual value sent by ovirt-guest-agent is the actual value at the time when the
value is sent (e.g. for Linux taken from "cat /proc/meminfo")
- vdsm is doing no statistics on top of it, just remembers the last value taken from
ovirt-guest-agent
which is fine, it doesn't change so often and there are typically no spikes
- the rest of the poling is the same
So, visualizing this in some usable form will be quite challenging ;)
I see the following problems:
- if the VDSM gets the data faster than the engine polls it (and most often it does) than
the info in between will be lost.
The question is how big this problem is and if it is worth solving (I would say not for
CPU which are averages but maybe yes for memory).
Other question if there is a way how to solve it since the VDSM can be polled by anyone
and it does not really care if someone polls it... (Michal?)
I'd say not solve it and try to keep it in sync on vdsm side with engine poll, to save
unnecessary libvirt calls
- we can lost some data between frontend<->engine if the
polling interval of the FE is slower than the polling interval of the engine. This is
something
not really worth solving because the user can set this according to the level of detail
he/she wants
well, you should average the values in engine in case the FE refresh is >15s. Or add
(refresh/15) of them
- since we will get new info once in ~15 seconds, and the polling of
the FE is by default 5 seconds, do we want to do some interpolation? Or just show the
same value 3 times? Or be smart and show only changed values? (this is tricky since
there is a chance that it did not change - e.g. constant 0 mem usage if you have no guest
agent)
- What if the user starts clicking to the refresh button? Do we want to keep appending
the same value if the engine still has only the old ones?
just add a new line/point every 15s should be ok
Thanks,
michal
Tomas
----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info" <info(a)eldanet.com>
> Sent: Monday, November 11, 2013 4:23:09 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
>
>
> ----- Original Message -----
>> From: "Malini Rao" <mrao(a)redhat.com>
>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "info"
<info(a)eldanet.com>,
>> engine-devel(a)ovirt.org
>> Sent: Monday, November 11, 2013 4:15:50 PM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> Is this going to fit in a row of a table? Or are we talking of a more
>> detailed view?
>
> it should fit into one cell of the table
>
>>
>> ----- Original Message -----
>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
>> Sent: Monday, November 11, 2013 8:01:07 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> Throw this gif into a browser. This is more or less what I thought.
>> Eldan
>>
>> ----- Original Message -----
>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>,
>> engine-devel(a)ovirt.org
>> Sent: Monday, November 11, 2013 12:03:15 PM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>>> To: "Einav Cohen" <ecohen(a)redhat.com>
>>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
>>> Sent: Sunday, November 10, 2013 3:56:57 PM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>> Hello all,
>>> We use to have a good solution in the period pre-WPF.
>>> A line chart (used to be in flash) that works like a plotter:
>>> The Line Bar (not bar) had a small animation that shifted all the bar to
>>> the
>>> left.
>>> When a new data arrived it just added a new line (to the right) and as I
>>> said
>>> before, in parallel it always shifted slowly to the left.
>>
>> Any chance you still have some screenshot or mockup so I can imagine it
>> better?
>>
>>> The animation gives the impression that data is streaming and when a real
>>> new
>>> data arrives the user gets it very fast.
>>> We have to sync between the animation and the rate of the arrival of the
>>> data
>>> but this is easy.
>>> If we can't find a good framework it can be created from scratch with
JS,
>>> svg
>>> or canvas.
>>
>> We need to be careful about what we will use. oVirt is supposed to work on
>> FF
>> 17 [1]
>> but the HTML5 canvas works only since FF23 [2].
>>
>> @Einav:
>> Is there a chance that we could start support only FF23+ and IE9+ (this one
>> is already OK)
>> because of this feature?
>>
>>> Now regarding its position:
>>> Rollover is good but not enough, we should somehow put it in the lower
>>> panel
>>> under general or even another tab - (live data).
>>
>> This is a bit different requirement. The point of this specific is to give
>> a
>> better
>> overview in the main tab. If it will be done we can decide if we want to
>> give
>> more
>> details in sub tabs.
>>
>>> We could later on have a (live data Tab) in other places as well like
>>> host,
>>> cluster...
>>> Eldan
>>
>> [1]: http://www.ovirt.org/Download
>> [2]: http://caniuse.com/#feat=canvas
>>
>>>
>>> ----- Original Message -----
>>> From: "Einav Cohen" <ecohen(a)redhat.com>
>>> To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
>>> Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan
Hildesheim"
>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
>>> Sent: Friday, November 8, 2013 10:50:10 PM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>>> ----- Original Message -----
>>>> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
>>>>
>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
>>>>
>>>> I'd say no. Even from a reliability point of view since users may
have
>>>> systems that aren't connected to the internet.
>>>
>>> +1
>>>
>>>> (Though I don't know how well oVirt handles this currently.)
>>>
>>> AFAIK - oVirt is handling it ('it' == having no internet
connection)
>>> well.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
Hey all,
let me conclude what has been written in this thread to one proposal:
== From the UX perspective the behavior ==
- each time the FE will receive new data and this data are different from the old ones,
visualize it in the chart
It means if you will keep pressing the refresh button but the data will not change, no
new data will be visualized (an exception will be the 0 usage)
- the amount of data visualized will depend on the size of the widget (since the tables
are resizable).
It means that if you make the widget bigger you will not see the same chart bigger but
more data.
- If you make the widget bigger, only then the amount of data will start to increase:
e.g.
before resize:
| /-------\ |
|/ \|
after resize:
| /-------\ |
|/ \ |
and only now the new data will start to appear
== From FE technical point of view ==
- since I have not found any GWT library which would be acceptable (e.g. actively
developed and without the need to connect to google servers)
and given that the required chart is quite simple I guess it would be ok to write it by
myself.
- according to Einav's mail it is ok to use HTML5 canvas so I would go with writing a
new widget using HTML5 canvas
== From L&F point of view ==
- would look pretty much like the one proposed by Malini:
http://style.org/chartapi/sparklines/
== From data point of view ==
- do not do any averages on VDSM side (since it already does them for CPU and network and
the memory is stable enough)
- do not do any averages on engine side (since would have to be done for each FE
separately and stored in session which is a bit overcomplicated. If the user wants to see
more accurate data, he/she can change the refresh rate)
- do not do any interpolation since the data are already averaged and we will show only
new ones
@Malini,Einav,Eldan,Michal what do you think?
Tomas
----- Original Message -----
From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>
Cc: "Malini Rao" <mrao(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
Sent: Tuesday, November 12, 2013 11:49:12 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
On Nov 12, 2013, at 11:18 , Tomas Jelinek <tjelinek(a)redhat.com> wrote:
> So we have looked into the resource usage sampling with mbetak and also
> with Michal and it seems that
>
> for the CPU usage:
> - VDSM polls libvirt to get the runtime statistics of the VM regularly. The
> pooling interval is configured in
> vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
> - libvirt returns something we than use to calculate the average CPU usage
> since the last poll
> - engine polls VDSM once in 15 seconds to get the current statistics (the
> same 15 seconds is just a coincidence and we can not count on this)
> - than the frontend polls the engine each 5-60 seconds (depends on the
> refresh rate) and gets the current value from the engine
> - the user can press the refresh button anytime to poll the engine again
>
> For network usage:
> - it should be pretty much the same as the CPU just the VDSM poll interval
> is configured as vm_sample_net_interval and by default it is 5 seconds
Dan, since we poll only every 15s and cpu info is 15s wouldn't it make sense
to change the default for network monitoring to 15s as well? it's 2 libvirt
rounds trip for nothing really. Or does it serve some other purpose?
> For memory usage:
> - guest agent sends a message to VDSM with the memory usage regularly. The
> interval is set in ovirt-guest-agent.conf as heart_beat_rate
> and by default it is 5 seconds
> - the actual value sent by ovirt-guest-agent is the actual value at the
> time when the value is sent (e.g. for Linux taken from "cat
> /proc/meminfo")
> - vdsm is doing no statistics on top of it, just remembers the last value
> taken from ovirt-guest-agent
which is fine, it doesn't change so often and there are typically no spikes
> - the rest of the poling is the same
>
> So, visualizing this in some usable form will be quite challenging ;)
> I see the following problems:
> - if the VDSM gets the data faster than the engine polls it (and most often
> it does) than the info in between will be lost.
> The question is how big this problem is and if it is worth solving (I
> would say not for CPU which are averages but maybe yes for memory).
> Other question if there is a way how to solve it since the VDSM can be
> polled by anyone and it does not really care if someone polls it...
> (Michal?)
I'd say not solve it and try to keep it in sync on vdsm side with engine
poll, to save unnecessary libvirt calls
> - we can lost some data between frontend<->engine if the polling interval
> of the FE is slower than the polling interval of the engine. This is
> something
> not really worth solving because the user can set this according to the
> level of detail he/she wants
well, you should average the values in engine in case the FE refresh is >15s.
Or add (refresh/15) of them
It is not that simple since you can have more frontends and not sure if it would be
a good idea to put this into the session...
> - since we will get new info once in ~15 seconds, and the polling of the FE
> is by default 5 seconds, do we want to do some interpolation? Or just show
> the
> same value 3 times? Or be smart and show only changed values? (this is
> tricky since there is a chance that it did not change - e.g. constant 0
> mem usage if you have no guest agent)
> - What if the user starts clicking to the refresh button? Do we want to
> keep appending the same value if the engine still has only the old ones?
just add a new line/point every 15s should be ok
Thanks,
michal
>
> Tomas
>
> ----- Original Message -----
>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
>> To: "Malini Rao" <mrao(a)redhat.com>
>> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org,
>> "info" <info(a)eldanet.com>
>> Sent: Monday, November 11, 2013 4:23:09 PM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Malini Rao" <mrao(a)redhat.com>
>>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "info"
<info(a)eldanet.com>,
>>> engine-devel(a)ovirt.org
>>> Sent: Monday, November 11, 2013 4:15:50 PM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>> Is this going to fit in a row of a table? Or are we talking of a more
>>> detailed view?
>>
>> it should fit into one cell of the table
>>
>>>
>>> ----- Original Message -----
>>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
>>> Sent: Monday, November 11, 2013 8:01:07 AM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>> Throw this gif into a browser. This is more or less what I thought.
>>> Eldan
>>>
>>> ----- Original Message -----
>>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
>>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>>> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>,
>>> engine-devel(a)ovirt.org
>>> Sent: Monday, November 11, 2013 12:03:15 PM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>>>> To: "Einav Cohen" <ecohen(a)redhat.com>
>>>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
>>>> Sent: Sunday, November 10, 2013 3:56:57 PM
>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>>
>>>> Hello all,
>>>> We use to have a good solution in the period pre-WPF.
>>>> A line chart (used to be in flash) that works like a plotter:
>>>> The Line Bar (not bar) had a small animation that shifted all the bar
to
>>>> the
>>>> left.
>>>> When a new data arrived it just added a new line (to the right) and as
I
>>>> said
>>>> before, in parallel it always shifted slowly to the left.
>>>
>>> Any chance you still have some screenshot or mockup so I can imagine it
>>> better?
>>>
>>>> The animation gives the impression that data is streaming and when a
>>>> real
>>>> new
>>>> data arrives the user gets it very fast.
>>>> We have to sync between the animation and the rate of the arrival of
the
>>>> data
>>>> but this is easy.
>>>> If we can't find a good framework it can be created from scratch
with
>>>> JS,
>>>> svg
>>>> or canvas.
>>>
>>> We need to be careful about what we will use. oVirt is supposed to work
>>> on
>>> FF
>>> 17 [1]
>>> but the HTML5 canvas works only since FF23 [2].
>>>
>>> @Einav:
>>> Is there a chance that we could start support only FF23+ and IE9+ (this
>>> one
>>> is already OK)
>>> because of this feature?
>>>
>>>> Now regarding its position:
>>>> Rollover is good but not enough, we should somehow put it in the lower
>>>> panel
>>>> under general or even another tab - (live data).
>>>
>>> This is a bit different requirement. The point of this specific is to
>>> give
>>> a
>>> better
>>> overview in the main tab. If it will be done we can decide if we want to
>>> give
>>> more
>>> details in sub tabs.
>>>
>>>> We could later on have a (live data Tab) in other places as well like
>>>> host,
>>>> cluster...
>>>> Eldan
>>>
>>> [1]: http://www.ovirt.org/Download
>>> [2]: http://caniuse.com/#feat=canvas
>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Einav Cohen" <ecohen(a)redhat.com>
>>>> To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
>>>> Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan
Hildesheim"
>>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
>>>> Sent: Friday, November 8, 2013 10:50:10 PM
>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>>
>>>>> ----- Original Message -----
>>>>> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
>>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
>>>>>
>>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
>>>>>
>>>>> I'd say no. Even from a reliability point of view since users
may have
>>>>> systems that aren't connected to the internet.
>>>>
>>>> +1
>>>>
>>>>> (Though I don't know how well oVirt handles this currently.)
>>>>
>>>> AFAIK - oVirt is handling it ('it' == having no internet
connection)
>>>> well.
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
Hey all,
let me conclude what has been written in this thread to one proposal:
== From the UX perspective the behavior ==
- each time the FE will receive new data and this data are different from
the old ones, visualize it in the chart It means if you will keep pressing
the refresh button but the data will not change, no new data will be
visualized (an exception will be the 0 usage) - the amount of data
visualized will depend on the size of the widget (since the tables are
resizable). It means that if you make the widget bigger you will not see
the same chart bigger but more data. - If you make the widget bigger, only
then the amount of data will start to increase: e.g.
before resize:
| /-------\ |
|
|/ \|
after resize:
| /-------\ |
|
|/ \ |
and only now the new data will start to appear
== From FE technical point of view ==
- since I have not found any GWT library which would be acceptable (e.g.
actively developed and without the need to connect to google servers) and
given that the required chart is quite simple I guess it would be ok to
write it by myself. - according to Einav's mail it is ok to use HTML5
canvas so I would go with writing a new widget using HTML5 canvas
Just to throw out something to think about, we could also in theory generate
an image on the server side and simply display that image inside the grid (so
no need for HTML5 canvas or other things like that). The idea being basically
that when the grid refreshes it makes a request for a new image on the back-
end with the appropriate timeframe and the back-end generates the image which
is easy to embed inside the grid.
pros:
* Easy to embed inside grid (just an image tag).
* Works on all browsers, even ones without HTML5 canvas support.
cons:
* More load on the back-end.
* Extra round trips to back-end on refresh.
* Not 'hot' like HTML5 canvas.
* No interactivity if that is something we are interested in.
== From L&F point of view ==
- would look pretty much like the one proposed by Malini:
http://style.org/chartapi/sparklines/
== From data point of view ==
- do not do any averages on VDSM side (since it already does them for CPU
and network and the memory is stable enough) - do not do any averages on
engine side (since would have to be done for each FE separately and stored
in session which is a bit overcomplicated. If the user wants to see more
accurate data, he/she can change the refresh rate) - do not do any
interpolation since the data are already averaged and we will show only new
ones
@Malini,Einav,Eldan,Michal what do you think?
Tomas
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Dan
Kenigsberg"
> <danken(a)redhat.com> Cc: "Malini Rao" <mrao(a)redhat.com>,
"Eldan
> Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> <info(a)eldanet.com>
> Sent: Tuesday, November 12, 2013 11:49:12 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> On Nov 12, 2013, at 11:18 , Tomas Jelinek <tjelinek(a)redhat.com> wrote:
> > So we have looked into the resource usage sampling with mbetak and also
> > with Michal and it seems that
> >
> > for the CPU usage:
> > - VDSM polls libvirt to get the runtime statistics of the VM regularly.
> > The
> > pooling interval is configured in
> >
> > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
> >
> > - libvirt returns something we than use to calculate the average CPU
> > usage
> > since the last poll
> > - engine polls VDSM once in 15 seconds to get the current statistics
> > (the
> > same 15 seconds is just a coincidence and we can not count on this)
> > - than the frontend polls the engine each 5-60 seconds (depends on the
> > refresh rate) and gets the current value from the engine
> > - the user can press the refresh button anytime to poll the engine again
> >
> > For network usage:
> > - it should be pretty much the same as the CPU just the VDSM poll
> > interval
> > is configured as vm_sample_net_interval and by default it is 5 seconds
>
> Dan, since we poll only every 15s and cpu info is 15s wouldn't it make
> sense to change the default for network monitoring to 15s as well? it's 2
> libvirt rounds trip for nothing really. Or does it serve some other
> purpose?>
> > For memory usage:
> > - guest agent sends a message to VDSM with the memory usage regularly.
> > The
> > interval is set in ovirt-guest-agent.conf as heart_beat_rate
> >
> > and by default it is 5 seconds
> >
> > - the actual value sent by ovirt-guest-agent is the actual value at the
> > time when the value is sent (e.g. for Linux taken from "cat
> > /proc/meminfo")
> > - vdsm is doing no statistics on top of it, just remembers the last
> > value
> > taken from ovirt-guest-agent
>
> which is fine, it doesn't change so often and there are typically no
> spikes
>
> > - the rest of the poling is the same
> >
> > So, visualizing this in some usable form will be quite challenging ;)
> > I see the following problems:
> > - if the VDSM gets the data faster than the engine polls it (and most
> > often
> > it does) than the info in between will be lost.
> >
> > The question is how big this problem is and if it is worth solving (I
> > would say not for CPU which are averages but maybe yes for memory).
> > Other question if there is a way how to solve it since the VDSM can be
> > polled by anyone and it does not really care if someone polls it...
> > (Michal?)
>
> I'd say not solve it and try to keep it in sync on vdsm side with engine
> poll, to save unnecessary libvirt calls
>
> > - we can lost some data between frontend<->engine if the polling
> > interval
> > of the FE is slower than the polling interval of the engine. This is
> > something
> >
> > not really worth solving because the user can set this according to the
> > level of detail he/she wants
>
> well, you should average the values in engine in case the FE refresh is
> >15s. Or add (refresh/15) of them
It is not that simple since you can have more frontends and not sure if it
would be a good idea to put this into the session...
> > - since we will get new info once in ~15 seconds, and the polling of the
> > FE
> > is by default 5 seconds, do we want to do some interpolation? Or just
> > show
> > the
> >
> > same value 3 times? Or be smart and show only changed values? (this is
> > tricky since there is a chance that it did not change - e.g. constant 0
> > mem usage if you have no guest agent)
> >
> > - What if the user starts clicking to the refresh button? Do we want to
> > keep appending the same value if the engine still has only the old ones?
>
> just add a new line/point every 15s should be ok
>
> Thanks,
> michal
>
> > Tomas
> >
> > ----- Original Message -----
> >
> >> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> >> To: "Malini Rao" <mrao(a)redhat.com>
> >> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org,
> >> "info" <info(a)eldanet.com>
> >> Sent: Monday, November 11, 2013 4:23:09 PM
> >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>
> >>
> >>
> >> ----- Original Message -----
> >>
> >>> From: "Malini Rao" <mrao(a)redhat.com>
> >>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> >>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"info" <info(a)eldanet.com>,
> >>> engine-devel(a)ovirt.org
> >>> Sent: Monday, November 11, 2013 4:15:50 PM
> >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>>
> >>> Is this going to fit in a row of a table? Or are we talking of a more
> >>> detailed view?
> >>
> >> it should fit into one cell of the table
> >>
> >>> ----- Original Message -----
> >>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> >>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> >>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
> >>> Sent: Monday, November 11, 2013 8:01:07 AM
> >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>>
> >>> Throw this gif into a browser. This is more or less what I thought.
> >>> Eldan
> >>>
> >>> ----- Original Message -----
> >>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> >>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> >>> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>,
> >>> engine-devel(a)ovirt.org
> >>> Sent: Monday, November 11, 2013 12:03:15 PM
> >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>
> >>>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> >>>> To: "Einav Cohen" <ecohen(a)redhat.com>
> >>>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> >>>> Sent: Sunday, November 10, 2013 3:56:57 PM
> >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>>>
> >>>> Hello all,
> >>>> We use to have a good solution in the period pre-WPF.
> >>>> A line chart (used to be in flash) that works like a plotter:
> >>>> The Line Bar (not bar) had a small animation that shifted all the
bar
> >>>> to
> >>>> the
> >>>> left.
> >>>> When a new data arrived it just added a new line (to the right)
and
> >>>> as I
> >>>> said
> >>>> before, in parallel it always shifted slowly to the left.
> >>>
> >>> Any chance you still have some screenshot or mockup so I can imagine
> >>> it
> >>> better?
> >>>
> >>>> The animation gives the impression that data is streaming and when
a
> >>>> real
> >>>> new
> >>>> data arrives the user gets it very fast.
> >>>> We have to sync between the animation and the rate of the arrival
of
> >>>> the
> >>>> data
> >>>> but this is easy.
> >>>> If we can't find a good framework it can be created from
scratch with
> >>>> JS,
> >>>> svg
> >>>> or canvas.
> >>>
> >>> We need to be careful about what we will use. oVirt is supposed to
> >>> work
> >>> on
> >>> FF
> >>> 17 [1]
> >>> but the HTML5 canvas works only since FF23 [2].
> >>>
> >>> @Einav:
> >>> Is there a chance that we could start support only FF23+ and IE9+
> >>> (this
> >>> one
> >>> is already OK)
> >>> because of this feature?
> >>>
> >>>> Now regarding its position:
> >>>> Rollover is good but not enough, we should somehow put it in the
> >>>> lower
> >>>> panel
> >>>> under general or even another tab - (live data).
> >>>
> >>> This is a bit different requirement. The point of this specific is to
> >>> give
> >>> a
> >>> better
> >>> overview in the main tab. If it will be done we can decide if we want
> >>> to
> >>> give
> >>> more
> >>> details in sub tabs.
> >>>
> >>>> We could later on have a (live data Tab) in other places as well
like
> >>>> host,
> >>>> cluster...
> >>>> Eldan
> >>>
> >>> [1]: http://www.ovirt.org/Download
> >>> [2]: http://caniuse.com/#feat=canvas
> >>>
> >>>> ----- Original Message -----
> >>>> From: "Einav Cohen" <ecohen(a)redhat.com>
> >>>> To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> >>>> Cc: "Alexander Wels" <awels(a)redhat.com>,
"Eldan Hildesheim"
> >>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> >>>> <info(a)eldanet.com>
> >>>> Sent: Friday, November 8, 2013 10:50:10 PM
> >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >>>>
> >>>>> ----- Original Message -----
> >>>>> From: "Ewoud Kohl van Wijngaarden"
> >>>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
> >>>>>
> >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels
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.
> >>>>>
> >>>>> I'd say no. Even from a reliability point of view since
users may
> >>>>> have
> >>>>> systems that aren't connected to the internet.
> >>>>
> >>>> +1
> >>>>
> >>>>> (Though I don't know how well oVirt handles this
currently.)
> >>>>
> >>>> AFAIK - oVirt is handling it ('it' == having no internet
connection)
> >>>> well.
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel(a)ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel(a)ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
From: "Alexander Wels" <awels(a)redhat.com>
To: engine-devel(a)ovirt.org
Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>
Sent: Tuesday, November 12, 2013 3:33:56 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote:
> Hey all,
>
> let me conclude what has been written in this thread to one proposal:
>
> == From the UX perspective the behavior ==
> - each time the FE will receive new data and this data are different from
> the old ones, visualize it in the chart It means if you will keep pressing
> the refresh button but the data will not change, no new data will be
> visualized (an exception will be the 0 usage) - the amount of data
> visualized will depend on the size of the widget (since the tables are
> resizable). It means that if you make the widget bigger you will not see
> the same chart bigger but more data. - If you make the widget bigger, only
> then the amount of data will start to increase: e.g.
>
> before resize:
> | /-------\ |
> |
> |/ \|
>
> after resize:
> | /-------\ |
> |
> |/ \ |
>
> and only now the new data will start to appear
>
> == From FE technical point of view ==
> - since I have not found any GWT library which would be acceptable (e.g.
> actively developed and without the need to connect to google servers) and
> given that the required chart is quite simple I guess it would be ok to
> write it by myself. - according to Einav's mail it is ok to use HTML5
> canvas so I would go with writing a new widget using HTML5 canvas
>
Just to throw out something to think about, we could also in theory generate
an image on the server side and simply display that image inside the grid (so
no need for HTML5 canvas or other things like that). The idea being basically
that when the grid refreshes it makes a request for a new image on the back-
end with the appropriate timeframe and the back-end generates the image which
is easy to embed inside the grid.
pros:
* Easy to embed inside grid (just an image tag).
* Works on all browsers, even ones without HTML5 canvas support.
cons:
* More load on the back-end.
* Extra round trips to back-end on refresh.
* Not 'hot' like HTML5 canvas.
* No interactivity if that is something we are interested in.
some more cons:
* need to remember the statistics on server in the memory. For thousands of VMs it is not
something we would like to do
* lots of overhead to retrieve all the images on each refresh. If you have 100 VMs on a
page and refresh each 5 seconds, it is 100 images transmitted
from engine to frontend each 5 seconds per one client (and we can have more of them of
course)
* FE logic on Server is in general not awesome
> == From L&F point of view ==
> - would look pretty much like the one proposed by Malini:
> http://style.org/chartapi/sparklines/
>
> == From data point of view ==
> - do not do any averages on VDSM side (since it already does them for CPU
> and network and the memory is stable enough) - do not do any averages on
> engine side (since would have to be done for each FE separately and stored
> in session which is a bit overcomplicated. If the user wants to see more
> accurate data, he/she can change the refresh rate) - do not do any
> interpolation since the data are already averaged and we will show only new
> ones
>
> @Malini,Einav,Eldan,Michal what do you think?
>
> Tomas
>
> ----- Original Message -----
>
> > From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Dan
Kenigsberg"
> > <danken(a)redhat.com> Cc: "Malini Rao" <mrao(a)redhat.com>,
"Eldan
> > Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> > <info(a)eldanet.com>
> > Sent: Tuesday, November 12, 2013 11:49:12 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > On Nov 12, 2013, at 11:18 , Tomas Jelinek <tjelinek(a)redhat.com> wrote:
> > > So we have looked into the resource usage sampling with mbetak and also
> > > with Michal and it seems that
> > >
> > > for the CPU usage:
> > > - VDSM polls libvirt to get the runtime statistics of the VM regularly.
> > > The
> > > pooling interval is configured in
> > >
> > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
> > >
> > > - libvirt returns something we than use to calculate the average CPU
> > > usage
> > > since the last poll
> > > - engine polls VDSM once in 15 seconds to get the current statistics
> > > (the
> > > same 15 seconds is just a coincidence and we can not count on this)
> > > - than the frontend polls the engine each 5-60 seconds (depends on the
> > > refresh rate) and gets the current value from the engine
> > > - the user can press the refresh button anytime to poll the engine
> > > again
> > >
> > > For network usage:
> > > - it should be pretty much the same as the CPU just the VDSM poll
> > > interval
> > > is configured as vm_sample_net_interval and by default it is 5 seconds
> >
> > Dan, since we poll only every 15s and cpu info is 15s wouldn't it make
> > sense to change the default for network monitoring to 15s as well? it's 2
> > libvirt rounds trip for nothing really. Or does it serve some other
> > purpose?>
> > > For memory usage:
> > > - guest agent sends a message to VDSM with the memory usage regularly.
> > > The
> > > interval is set in ovirt-guest-agent.conf as heart_beat_rate
> > >
> > > and by default it is 5 seconds
> > >
> > > - the actual value sent by ovirt-guest-agent is the actual value at the
> > > time when the value is sent (e.g. for Linux taken from "cat
> > > /proc/meminfo")
> > > - vdsm is doing no statistics on top of it, just remembers the last
> > > value
> > > taken from ovirt-guest-agent
> >
> > which is fine, it doesn't change so often and there are typically no
> > spikes
> >
> > > - the rest of the poling is the same
> > >
> > > So, visualizing this in some usable form will be quite challenging ;)
> > > I see the following problems:
> > > - if the VDSM gets the data faster than the engine polls it (and most
> > > often
> > > it does) than the info in between will be lost.
> > >
> > > The question is how big this problem is and if it is worth solving (I
> > > would say not for CPU which are averages but maybe yes for memory).
> > > Other question if there is a way how to solve it since the VDSM can be
> > > polled by anyone and it does not really care if someone polls it...
> > > (Michal?)
> >
> > I'd say not solve it and try to keep it in sync on vdsm side with engine
> > poll, to save unnecessary libvirt calls
> >
> > > - we can lost some data between frontend<->engine if the polling
> > > interval
> > > of the FE is slower than the polling interval of the engine. This is
> > > something
> > >
> > > not really worth solving because the user can set this according to
> > > the
> > > level of detail he/she wants
> >
> > well, you should average the values in engine in case the FE refresh is
> > >15s. Or add (refresh/15) of them
>
> It is not that simple since you can have more frontends and not sure if it
> would be a good idea to put this into the session...
>
> > > - since we will get new info once in ~15 seconds, and the polling of
> > > the
> > > FE
> > > is by default 5 seconds, do we want to do some interpolation? Or just
> > > show
> > > the
> > >
> > > same value 3 times? Or be smart and show only changed values? (this is
> > > tricky since there is a chance that it did not change - e.g. constant
> > > 0
> > > mem usage if you have no guest agent)
> > >
> > > - What if the user starts clicking to the refresh button? Do we want to
> > > keep appending the same value if the engine still has only the old
> > > ones?
> >
> > just add a new line/point every 15s should be ok
> >
> > Thanks,
> > michal
> >
> > > Tomas
> > >
> > > ----- Original Message -----
> > >
> > >> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > >> To: "Malini Rao" <mrao(a)redhat.com>
> > >> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org,
> > >> "info" <info(a)eldanet.com>
> > >> Sent: Monday, November 11, 2013 4:23:09 PM
> > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>
> > >>> From: "Malini Rao" <mrao(a)redhat.com>
> > >>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > >>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"info" <info(a)eldanet.com>,
> > >>> engine-devel(a)ovirt.org
> > >>> Sent: Monday, November 11, 2013 4:15:50 PM
> > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>>
> > >>> Is this going to fit in a row of a table? Or are we talking of a
more
> > >>> detailed view?
> > >>
> > >> it should fit into one cell of the table
> > >>
> > >>> ----- Original Message -----
> > >>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > >>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > >>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > >>> Sent: Monday, November 11, 2013 8:01:07 AM
> > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>>
> > >>> Throw this gif into a browser. This is more or less what I
thought.
> > >>> Eldan
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > >>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > >>> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"info" <info(a)eldanet.com>,
> > >>> engine-devel(a)ovirt.org
> > >>> Sent: Monday, November 11, 2013 12:03:15 PM
> > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>
> > >>>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > >>>> To: "Einav Cohen" <ecohen(a)redhat.com>
> > >>>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM
> > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > >>>>
> > >>>> Hello all,
> > >>>> We use to have a good solution in the period pre-WPF.
> > >>>> A line chart (used to be in flash) that works like a plotter:
> > >>>> The Line Bar (not bar) had a small animation that shifted all
the
> > >>>> bar
> > >>>> to
> > >>>> the
> > >>>> left.
> > >>>> When a new data arrived it just added a new line (to the
right) and
> > >>>> as I
> > >>>> said
> > >>>> before, in parallel it always shifted slowly to the left.
> > >>>
> > >>> Any chance you still have some screenshot or mockup so I can
imagine
> > >>> it
> > >>> better?
> > >>>
> > >>>> The animation gives the impression that data is streaming and
when a
> > >>>> real
> > >>>> new
> > >>>> data arrives the user gets it very fast.
> > >>>> We have to sync between the animation and the rate of the
arrival of
> > >>>> the
> > >>>> data
> > >>>> but this is easy.
> > >>>> If we can't find a good framework it can be created from
scratch
> > >>>> with
> > >>>> JS,
> > >>>> svg
> > >>>> or canvas.
> > >>>
> > >>> We need to be careful about what we will use. oVirt is supposed
to
> > >>> work
> > >>> on
> > >>> FF
> > >>> 17 [1]
> > >>> but the HTML5 canvas works only since FF23 [2].
> > >>>
> > >>> @Einav:
> > >>> Is there a chance that we could start support only FF23+ and IE9+
> > >>> (this
> > >>> one
> > >>> is already OK)
> > >>> because of this feature?
> > >>>
> > >>>> Now regarding its position:
> > >>>> Rollover is good but not enough, we should somehow put it in
the
> > >>>> lower
> > >>>> panel
> > >>>> under general or even another tab - (live data).
> > >>>
> > >>> This is a bit different requirement. The point of this specific is
to
> > >>> give
> > >>> a
> > >>> better
> > >>> overview in the main tab. If it will be done we can decide if we
want
> > >>> to
> > >>> give
> > >>> more
> > >>> details in sub tabs.
> > >>>
> > >>>> We could later on have a (live data Tab) in other places as
well
> > >>>> like
> > >>>> host,
> > >>>> cluster...
> > >>>> Eldan
> > >>>
> > >>> [1]: http://www.ovirt.org/Download
> > >>> [2]: http://caniuse.com/#feat=canvas
> > >>>
> > >>>> ----- Original Message -----
> > >>>> From: "Einav Cohen" <ecohen(a)redhat.com>
> > >>>> To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > >>>> Cc: "Alexander Wels" <awels(a)redhat.com>,
"Eldan Hildesheim"
> > >>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> > >>>> <info(a)eldanet.com>
> > >>>> Sent: Friday, November 8, 2013 10:50:10 PM
> > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > >>>>
> > >>>>> ----- Original Message -----
> > >>>>> From: "Ewoud Kohl van Wijngaarden"
> > >>>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
> > >>>>>
> > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels
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.
> > >>>>>
> > >>>>> I'd say no. Even from a reliability point of view
since users may
> > >>>>> have
> > >>>>> systems that aren't connected to the internet.
> > >>>>
> > >>>> +1
> > >>>>
> > >>>>> (Though I don't know how well oVirt handles this
currently.)
> > >>>>
> > >>>> AFAIK - oVirt is handling it ('it' == having no
internet
> > >>>> connection)
> > >>>> well.
> > >>>> _______________________________________________
> > >>>> Engine-devel mailing list
> > >>>> Engine-devel(a)ovirt.org
> > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel(a)ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel(a)ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
> From: "Alexander Wels" <awels(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Michal
Skrivanek"
> <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>,
> "info" <info(a)eldanet.com>
> Sent: Tuesday, November 12, 2013 3:33:56 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote:
> > Hey all,
> >
> > let me conclude what has been written in this thread to one proposal:
> >
> > == From the UX perspective the behavior ==
> > - each time the FE will receive new data and this data are different
> > from
> > the old ones, visualize it in the chart It means if you will keep
> > pressing
> > the refresh button but the data will not change, no new data will be
> > visualized (an exception will be the 0 usage) - the amount of data
> > visualized will depend on the size of the widget (since the tables are
> > resizable). It means that if you make the widget bigger you will not see
> > the same chart bigger but more data. - If you make the widget bigger,
> > only
> > then the amount of data will start to increase: e.g.
> >
> > before resize:
> > | /-------\ |
> > |
> > |/ \|
> >
> > after resize:
> > | /-------\ |
> > |
> > |/ \ |
> >
> > and only now the new data will start to appear
> >
> > == From FE technical point of view ==
> > - since I have not found any GWT library which would be acceptable (e.g.
> > actively developed and without the need to connect to google servers)
> > and
> > given that the required chart is quite simple I guess it would be ok to
> > write it by myself. - according to Einav's mail it is ok to use HTML5
> > canvas so I would go with writing a new widget using HTML5 canvas
>
> Just to throw out something to think about, we could also in theory
> generate an image on the server side and simply display that image inside
> the grid (so no need for HTML5 canvas or other things like that). The
> idea being basically that when the grid refreshes it makes a request for
> a new image on the back- end with the appropriate timeframe and the
> back-end generates the image which is easy to embed inside the grid.
>
> pros:
> * Easy to embed inside grid (just an image tag).
> * Works on all browsers, even ones without HTML5 canvas support.
> cons:
> * More load on the back-end.
> * Extra round trips to back-end on refresh.
> * Not 'hot' like HTML5 canvas.
> * No interactivity if that is something we are interested in.
some more cons:
* need to remember the statistics on server in the memory. For thousands of
VMs it is not something we would like to do * lots of overhead to retrieve
all the images on each refresh. If you have 100 VMs on a page and refresh
each 5 seconds, it is 100 images transmitted from engine to frontend each 5
seconds per one client (and we can have more of them of course) * FE logic
on Server is in general not awesome
I would expect the statistics to be stored in the database somewhere, that way
we can pull them for reports and things of that nature (like charts).
Obviously we wouldn't do 100 round trips for the image, we would generate a
single image sprite that would contain all the images in a single request and
display the appropriate part of the image in the grid.
You are right in general front-end logic is not done on the back-end. However
we must consider if we are really doing front end logic here, or if we are
just displaying some reporting information as part of the grid.
If we are not storing the statistics anywhere, then this is a terrible plan,
and we should do the logic on the client, but if we are, it is something to
consider.
> > == From L&F point of view ==
> > - would look pretty much like the one proposed by Malini:
> > http://style.org/chartapi/sparklines/
> >
> > == From data point of view ==
> > - do not do any averages on VDSM side (since it already does them for
> > CPU
> > and network and the memory is stable enough) - do not do any averages on
> > engine side (since would have to be done for each FE separately and
> > stored
> > in session which is a bit overcomplicated. If the user wants to see more
> > accurate data, he/she can change the refresh rate) - do not do any
> > interpolation since the data are already averaged and we will show only
> > new
> > ones
> >
> > @Malini,Einav,Eldan,Michal what do you think?
> >
> > Tomas
> >
> > ----- Original Message -----
> >
> > > From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Dan
Kenigsberg"
> > > <danken(a)redhat.com> Cc: "Malini Rao"
<mrao(a)redhat.com>, "Eldan
> > > Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> > > <info(a)eldanet.com>
> > > Sent: Tuesday, November 12, 2013 11:49:12 AM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >
> > > On Nov 12, 2013, at 11:18 , Tomas Jelinek <tjelinek(a)redhat.com>
wrote:
> > > > So we have looked into the resource usage sampling with mbetak and
> > > > also
> > > > with Michal and it seems that
> > > >
> > > > for the CPU usage:
> > > > - VDSM polls libvirt to get the runtime statistics of the VM
> > > > regularly.
> > > > The
> > > > pooling interval is configured in
> > > >
> > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
> > > >
> > > > - libvirt returns something we than use to calculate the average CPU
> > > > usage
> > > > since the last poll
> > > > - engine polls VDSM once in 15 seconds to get the current statistics
> > > > (the
> > > > same 15 seconds is just a coincidence and we can not count on this)
> > > > - than the frontend polls the engine each 5-60 seconds (depends on
> > > > the
> > > > refresh rate) and gets the current value from the engine
> > > > - the user can press the refresh button anytime to poll the engine
> > > > again
> > > >
> > > > For network usage:
> > > > - it should be pretty much the same as the CPU just the VDSM poll
> > > > interval
> > > > is configured as vm_sample_net_interval and by default it is 5
> > > > seconds
> > >
> > > Dan, since we poll only every 15s and cpu info is 15s wouldn't it
make
> > > sense to change the default for network monitoring to 15s as well?
> > > it's 2
> > > libvirt rounds trip for nothing really. Or does it serve some other
> > > purpose?>
> > >
> > > > For memory usage:
> > > > - guest agent sends a message to VDSM with the memory usage
> > > > regularly.
> > > > The
> > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate
> > > >
> > > > and by default it is 5 seconds
> > > >
> > > > - the actual value sent by ovirt-guest-agent is the actual value at
> > > > the
> > > > time when the value is sent (e.g. for Linux taken from "cat
> > > > /proc/meminfo")
> > > > - vdsm is doing no statistics on top of it, just remembers the last
> > > > value
> > > > taken from ovirt-guest-agent
> > >
> > > which is fine, it doesn't change so often and there are typically no
> > > spikes
> > >
> > > > - the rest of the poling is the same
> > > >
> > > > So, visualizing this in some usable form will be quite challenging
> > > > ;)
> > > > I see the following problems:
> > > > - if the VDSM gets the data faster than the engine polls it (and
> > > > most
> > > > often
> > > > it does) than the info in between will be lost.
> > > >
> > > > The question is how big this problem is and if it is worth solving
> > > > (I
> > > > would say not for CPU which are averages but maybe yes for memory).
> > > > Other question if there is a way how to solve it since the VDSM can
> > > > be
> > > > polled by anyone and it does not really care if someone polls it...
> > > > (Michal?)
> > >
> > > I'd say not solve it and try to keep it in sync on vdsm side with
> > > engine
> > > poll, to save unnecessary libvirt calls
> > >
> > > > - we can lost some data between frontend<->engine if the
polling
> > > > interval
> > > > of the FE is slower than the polling interval of the engine. This is
> > > > something
> > > >
> > > > not really worth solving because the user can set this according to
> > > > the
> > > > level of detail he/she wants
> > >
> > > well, you should average the values in engine in case the FE refresh
> > > is
> > >
> > > >15s. Or add (refresh/15) of them
> >
> > It is not that simple since you can have more frontends and not sure if
> > it
> > would be a good idea to put this into the session...
> >
> > > > - since we will get new info once in ~15 seconds, and the polling of
> > > > the
> > > > FE
> > > > is by default 5 seconds, do we want to do some interpolation? Or
> > > > just
> > > > show
> > > > the
> > > >
> > > > same value 3 times? Or be smart and show only changed values? (this
> > > > is
> > > > tricky since there is a chance that it did not change - e.g.
> > > > constant
> > > > 0
> > > > mem usage if you have no guest agent)
> > > >
> > > > - What if the user starts clicking to the refresh button? Do we want
> > > > to
> > > > keep appending the same value if the engine still has only the old
> > > > ones?
> > >
> > > just add a new line/point every 15s should be ok
> > >
> > > Thanks,
> > > michal
> > >
> > > > Tomas
> > > >
> > > > ----- Original Message -----
> > > >
> > > >> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > >> To: "Malini Rao" <mrao(a)redhat.com>
> > > >> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > > >> engine-devel(a)ovirt.org,
> > > >> "info" <info(a)eldanet.com>
> > > >> Sent: Monday, November 11, 2013 4:23:09 PM
> > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > >>
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>
> > > >>> From: "Malini Rao" <mrao(a)redhat.com>
> > > >>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > > >>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"info"
> > > >>> <info(a)eldanet.com>,
> > > >>> engine-devel(a)ovirt.org
> > > >>> Sent: Monday, November 11, 2013 4:15:50 PM
> > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > >>>
> > > >>> Is this going to fit in a row of a table? Or are we talking
of a
> > > >>> more
> > > >>> detailed view?
> > > >>
> > > >> it should fit into one cell of the table
> > > >>
> > > >>> ----- Original Message -----
> > > >>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > >>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > >>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > > >>> Sent: Monday, November 11, 2013 8:01:07 AM
> > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > >>>
> > > >>> Throw this gif into a browser. This is more or less what I
> > > >>> thought.
> > > >>> Eldan
> > > >>>
> > > >>> ----- Original Message -----
> > > >>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > >>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > > >>> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"info" <info(a)eldanet.com>,
> > > >>> engine-devel(a)ovirt.org
> > > >>> Sent: Monday, November 11, 2013 12:03:15 PM
> > > >>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > >>>
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>
> > > >>>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > >>>> To: "Einav Cohen" <ecohen(a)redhat.com>
> > > >>>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM
> > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > >>>>
> > > >>>> Hello all,
> > > >>>> We use to have a good solution in the period pre-WPF.
> > > >>>> A line chart (used to be in flash) that works like a
plotter:
> > > >>>> The Line Bar (not bar) had a small animation that shifted
all the
> > > >>>> bar
> > > >>>> to
> > > >>>> the
> > > >>>> left.
> > > >>>> When a new data arrived it just added a new line (to the
right)
> > > >>>> and
> > > >>>> as I
> > > >>>> said
> > > >>>> before, in parallel it always shifted slowly to the
left.
> > > >>>
> > > >>> Any chance you still have some screenshot or mockup so I can
> > > >>> imagine
> > > >>> it
> > > >>> better?
> > > >>>
> > > >>>> The animation gives the impression that data is streaming
and
> > > >>>> when a
> > > >>>> real
> > > >>>> new
> > > >>>> data arrives the user gets it very fast.
> > > >>>> We have to sync between the animation and the rate of the
arrival
> > > >>>> of
> > > >>>> the
> > > >>>> data
> > > >>>> but this is easy.
> > > >>>> If we can't find a good framework it can be created
from scratch
> > > >>>> with
> > > >>>> JS,
> > > >>>> svg
> > > >>>> or canvas.
> > > >>>
> > > >>> We need to be careful about what we will use. oVirt is
supposed to
> > > >>> work
> > > >>> on
> > > >>> FF
> > > >>> 17 [1]
> > > >>> but the HTML5 canvas works only since FF23 [2].
> > > >>>
> > > >>> @Einav:
> > > >>> Is there a chance that we could start support only FF23+ and
IE9+
> > > >>> (this
> > > >>> one
> > > >>> is already OK)
> > > >>> because of this feature?
> > > >>>
> > > >>>> Now regarding its position:
> > > >>>> Rollover is good but not enough, we should somehow put it
in the
> > > >>>> lower
> > > >>>> panel
> > > >>>> under general or even another tab - (live data).
> > > >>>
> > > >>> This is a bit different requirement. The point of this
specific is
> > > >>> to
> > > >>> give
> > > >>> a
> > > >>> better
> > > >>> overview in the main tab. If it will be done we can decide if
we
> > > >>> want
> > > >>> to
> > > >>> give
> > > >>> more
> > > >>> details in sub tabs.
> > > >>>
> > > >>>> We could later on have a (live data Tab) in other places
as well
> > > >>>> like
> > > >>>> host,
> > > >>>> cluster...
> > > >>>> Eldan
> > > >>>
> > > >>> [1]: http://www.ovirt.org/Download
> > > >>> [2]: http://caniuse.com/#feat=canvas
> > > >>>
> > > >>>> ----- Original Message -----
> > > >>>> From: "Einav Cohen" <ecohen(a)redhat.com>
> > > >>>> To: "Ewoud Kohl van Wijngaarden"
> > > >>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > >>>> Cc: "Alexander Wels" <awels(a)redhat.com>,
"Eldan Hildesheim"
> > > >>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> > > >>>> <info(a)eldanet.com>
> > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM
> > > >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > >>>>
> > > >>>>> ----- Original Message -----
> > > >>>>> From: "Ewoud Kohl van Wijngaarden"
> > > >>>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
> > > >>>>>
> > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander
Wels 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.
> > > >>>>>
> > > >>>>> I'd say no. Even from a reliability point of view
since users
> > > >>>>> may
> > > >>>>> have
> > > >>>>> systems that aren't connected to the internet.
> > > >>>>
> > > >>>> +1
> > > >>>>
> > > >>>>> (Though I don't know how well oVirt handles this
currently.)
> > > >>>>
> > > >>>> AFAIK - oVirt is handling it ('it' == having no
internet
> > > >>>> connection)
> > > >>>> well.
> > > >>>> _______________________________________________
> > > >>>> Engine-devel mailing list
> > > >>>> Engine-devel(a)ovirt.org
> > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>
> > > >>> _______________________________________________
> > > >>> Engine-devel mailing list
> > > >>> Engine-devel(a)ovirt.org
> > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>
> > > >> _______________________________________________
> > > >> Engine-devel mailing list
> > > >> Engine-devel(a)ovirt.org
> > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
From: "Alexander Wels" <awels(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>
Sent: Tuesday, November 12, 2013 4:03:14 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote:
> ----- Original Message -----
>
> > From: "Alexander Wels" <awels(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Michal
Skrivanek"
> > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>,
> > "info" <info(a)eldanet.com>
> > Sent: Tuesday, November 12, 2013 3:33:56 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote:
> > > Hey all,
> > >
> > > let me conclude what has been written in this thread to one proposal:
> > >
> > > == From the UX perspective the behavior ==
> > > - each time the FE will receive new data and this data are different
> > > from
> > > the old ones, visualize it in the chart It means if you will keep
> > > pressing
> > > the refresh button but the data will not change, no new data will be
> > > visualized (an exception will be the 0 usage) - the amount of data
> > > visualized will depend on the size of the widget (since the tables are
> > > resizable). It means that if you make the widget bigger you will not
> > > see
> > > the same chart bigger but more data. - If you make the widget bigger,
> > > only
> > > then the amount of data will start to increase: e.g.
> > >
> > > before resize:
> > > | /-------\ |
> > > |
> > > |/ \|
> > >
> > > after resize:
> > > | /-------\ |
> > > |
> > > |/ \ |
> > >
> > > and only now the new data will start to appear
> > >
> > > == From FE technical point of view ==
> > > - since I have not found any GWT library which would be acceptable
> > > (e.g.
> > > actively developed and without the need to connect to google servers)
> > > and
> > > given that the required chart is quite simple I guess it would be ok to
> > > write it by myself. - according to Einav's mail it is ok to use HTML5
> > > canvas so I would go with writing a new widget using HTML5 canvas
> >
> > Just to throw out something to think about, we could also in theory
> > generate an image on the server side and simply display that image inside
> > the grid (so no need for HTML5 canvas or other things like that). The
> > idea being basically that when the grid refreshes it makes a request for
> > a new image on the back- end with the appropriate timeframe and the
> > back-end generates the image which is easy to embed inside the grid.
> >
> > pros:
> > * Easy to embed inside grid (just an image tag).
> > * Works on all browsers, even ones without HTML5 canvas support.
> > cons:
> > * More load on the back-end.
> > * Extra round trips to back-end on refresh.
> > * Not 'hot' like HTML5 canvas.
> > * No interactivity if that is something we are interested in.
>
> some more cons:
> * need to remember the statistics on server in the memory. For thousands of
> VMs it is not something we would like to do * lots of overhead to retrieve
> all the images on each refresh. If you have 100 VMs on a page and refresh
> each 5 seconds, it is 100 images transmitted from engine to frontend each 5
> seconds per one client (and we can have more of them of course) * FE logic
> on Server is in general not awesome
>
I would expect the statistics to be stored in the database somewhere, that
way
we can pull them for reports and things of that nature (like charts).
Obviously we wouldn't do 100 round trips for the image, we would generate a
single image sprite that would contain all the images in a single request and
display the appropriate part of the image in the grid.
You are right in general front-end logic is not done on the back-end. However
we must consider if we are really doing front end logic here, or if we are
just displaying some reporting information as part of the grid.
If we are not storing the statistics anywhere, then this is a terrible plan,
and we should do the logic on the client, but if we are, it is something to
consider.
We store only the actual value. The statistics are stored only by DWH
but that is a different application. Engine itself does not have it so we would have
to implement it.
> > > == From L&F point of view ==
> > > - would look pretty much like the one proposed by Malini:
> > > http://style.org/chartapi/sparklines/
> > >
> > > == From data point of view ==
> > > - do not do any averages on VDSM side (since it already does them for
> > > CPU
> > > and network and the memory is stable enough) - do not do any averages
> > > on
> > > engine side (since would have to be done for each FE separately and
> > > stored
> > > in session which is a bit overcomplicated. If the user wants to see
> > > more
> > > accurate data, he/she can change the refresh rate) - do not do any
> > > interpolation since the data are already averaged and we will show only
> > > new
> > > ones
> > >
> > > @Malini,Einav,Eldan,Michal what do you think?
> > >
> > > Tomas
> > >
> > > ----- Original Message -----
> > >
> > > > From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
> > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Dan
Kenigsberg"
> > > > <danken(a)redhat.com> Cc: "Malini Rao"
<mrao(a)redhat.com>, "Eldan
> > > > Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> > > > <info(a)eldanet.com>
> > > > Sent: Tuesday, November 12, 2013 11:49:12 AM
> > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > >
> > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek
<tjelinek(a)redhat.com>
> > > > wrote:
> > > > > So we have looked into the resource usage sampling with mbetak
and
> > > > > also
> > > > > with Michal and it seems that
> > > > >
> > > > > for the CPU usage:
> > > > > - VDSM polls libvirt to get the runtime statistics of the VM
> > > > > regularly.
> > > > > The
> > > > > pooling interval is configured in
> > > > >
> > > > > vdsm.conf as vm_sample_cpu_interval and by default it is 15
> > > > > seconds
> > > > >
> > > > > - libvirt returns something we than use to calculate the
average
> > > > > CPU
> > > > > usage
> > > > > since the last poll
> > > > > - engine polls VDSM once in 15 seconds to get the current
> > > > > statistics
> > > > > (the
> > > > > same 15 seconds is just a coincidence and we can not count on
this)
> > > > > - than the frontend polls the engine each 5-60 seconds (depends
on
> > > > > the
> > > > > refresh rate) and gets the current value from the engine
> > > > > - the user can press the refresh button anytime to poll the
engine
> > > > > again
> > > > >
> > > > > For network usage:
> > > > > - it should be pretty much the same as the CPU just the VDSM
poll
> > > > > interval
> > > > > is configured as vm_sample_net_interval and by default it is 5
> > > > > seconds
> > > >
> > > > Dan, since we poll only every 15s and cpu info is 15s wouldn't
it
> > > > make
> > > > sense to change the default for network monitoring to 15s as well?
> > > > it's 2
> > > > libvirt rounds trip for nothing really. Or does it serve some other
> > > > purpose?>
> > > >
> > > > > For memory usage:
> > > > > - guest agent sends a message to VDSM with the memory usage
> > > > > regularly.
> > > > > The
> > > > > interval is set in ovirt-guest-agent.conf as heart_beat_rate
> > > > >
> > > > > and by default it is 5 seconds
> > > > >
> > > > > - the actual value sent by ovirt-guest-agent is the actual value
at
> > > > > the
> > > > > time when the value is sent (e.g. for Linux taken from
"cat
> > > > > /proc/meminfo")
> > > > > - vdsm is doing no statistics on top of it, just remembers the
last
> > > > > value
> > > > > taken from ovirt-guest-agent
> > > >
> > > > which is fine, it doesn't change so often and there are typically
no
> > > > spikes
> > > >
> > > > > - the rest of the poling is the same
> > > > >
> > > > > So, visualizing this in some usable form will be quite
challenging
> > > > > ;)
> > > > > I see the following problems:
> > > > > - if the VDSM gets the data faster than the engine polls it
(and
> > > > > most
> > > > > often
> > > > > it does) than the info in between will be lost.
> > > > >
> > > > > The question is how big this problem is and if it is worth
solving
> > > > > (I
> > > > > would say not for CPU which are averages but maybe yes for
> > > > > memory).
> > > > > Other question if there is a way how to solve it since the
VDSM
> > > > > can
> > > > > be
> > > > > polled by anyone and it does not really care if someone polls
> > > > > it...
> > > > > (Michal?)
> > > >
> > > > I'd say not solve it and try to keep it in sync on vdsm side
with
> > > > engine
> > > > poll, to save unnecessary libvirt calls
> > > >
> > > > > - we can lost some data between frontend<->engine if the
polling
> > > > > interval
> > > > > of the FE is slower than the polling interval of the engine.
This
> > > > > is
> > > > > something
> > > > >
> > > > > not really worth solving because the user can set this
according
> > > > > to
> > > > > the
> > > > > level of detail he/she wants
> > > >
> > > > well, you should average the values in engine in case the FE refresh
> > > > is
> > > >
> > > > >15s. Or add (refresh/15) of them
> > >
> > > It is not that simple since you can have more frontends and not sure if
> > > it
> > > would be a good idea to put this into the session...
> > >
> > > > > - since we will get new info once in ~15 seconds, and the
polling
> > > > > of
> > > > > the
> > > > > FE
> > > > > is by default 5 seconds, do we want to do some interpolation?
Or
> > > > > just
> > > > > show
> > > > > the
> > > > >
> > > > > same value 3 times? Or be smart and show only changed values?
> > > > > (this
> > > > > is
> > > > > tricky since there is a chance that it did not change - e.g.
> > > > > constant
> > > > > 0
> > > > > mem usage if you have no guest agent)
> > > > >
> > > > > - What if the user starts clicking to the refresh button? Do we
> > > > > want
> > > > > to
> > > > > keep appending the same value if the engine still has only the
old
> > > > > ones?
> > > >
> > > > just add a new line/point every 15s should be ok
> > > >
> > > > Thanks,
> > > > michal
> > > >
> > > > > Tomas
> > > > >
> > > > > ----- Original Message -----
> > > > >
> > > > >> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > > >> To: "Malini Rao" <mrao(a)redhat.com>
> > > > >> Cc: "Eldan Hildesheim"
<ehildesh(a)redhat.com>,
> > > > >> engine-devel(a)ovirt.org,
> > > > >> "info" <info(a)eldanet.com>
> > > > >> Sent: Monday, November 11, 2013 4:23:09 PM
> > > > >> Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > > >>
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>
> > > > >>> From: "Malini Rao" <mrao(a)redhat.com>
> > > > >>> To: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > >>> Cc: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "info"
> > > > >>> <info(a)eldanet.com>,
> > > > >>> engine-devel(a)ovirt.org
> > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM
> > > > >>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line chart?
> > > > >>>
> > > > >>> Is this going to fit in a row of a table? Or are we
talking of a
> > > > >>> more
> > > > >>> detailed view?
> > > > >>
> > > > >> it should fit into one cell of the table
> > > > >>
> > > > >>> ----- Original Message -----
> > > > >>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > >>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > >>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM
> > > > >>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line chart?
> > > > >>>
> > > > >>> Throw this gif into a browser. This is more or less what
I
> > > > >>> thought.
> > > > >>> Eldan
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>> From: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > >>> To: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > >>> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"info" <info(a)eldanet.com>,
> > > > >>> engine-devel(a)ovirt.org
> > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM
> > > > >>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line chart?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>
> > > > >>>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > >>>> To: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > >>>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM
> > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line chart?
> > > > >>>>
> > > > >>>> Hello all,
> > > > >>>> We use to have a good solution in the period
pre-WPF.
> > > > >>>> A line chart (used to be in flash) that works like a
plotter:
> > > > >>>> The Line Bar (not bar) had a small animation that
shifted all
> > > > >>>> the
> > > > >>>> bar
> > > > >>>> to
> > > > >>>> the
> > > > >>>> left.
> > > > >>>> When a new data arrived it just added a new line (to
the right)
> > > > >>>> and
> > > > >>>> as I
> > > > >>>> said
> > > > >>>> before, in parallel it always shifted slowly to the
left.
> > > > >>>
> > > > >>> Any chance you still have some screenshot or mockup so I
can
> > > > >>> imagine
> > > > >>> it
> > > > >>> better?
> > > > >>>
> > > > >>>> The animation gives the impression that data is
streaming and
> > > > >>>> when a
> > > > >>>> real
> > > > >>>> new
> > > > >>>> data arrives the user gets it very fast.
> > > > >>>> We have to sync between the animation and the rate
of the
> > > > >>>> arrival
> > > > >>>> of
> > > > >>>> the
> > > > >>>> data
> > > > >>>> but this is easy.
> > > > >>>> If we can't find a good framework it can be
created from scratch
> > > > >>>> with
> > > > >>>> JS,
> > > > >>>> svg
> > > > >>>> or canvas.
> > > > >>>
> > > > >>> We need to be careful about what we will use. oVirt is
supposed
> > > > >>> to
> > > > >>> work
> > > > >>> on
> > > > >>> FF
> > > > >>> 17 [1]
> > > > >>> but the HTML5 canvas works only since FF23 [2].
> > > > >>>
> > > > >>> @Einav:
> > > > >>> Is there a chance that we could start support only FF23+
and IE9+
> > > > >>> (this
> > > > >>> one
> > > > >>> is already OK)
> > > > >>> because of this feature?
> > > > >>>
> > > > >>>> Now regarding its position:
> > > > >>>> Rollover is good but not enough, we should somehow
put it in the
> > > > >>>> lower
> > > > >>>> panel
> > > > >>>> under general or even another tab - (live data).
> > > > >>>
> > > > >>> This is a bit different requirement. The point of this
specific
> > > > >>> is
> > > > >>> to
> > > > >>> give
> > > > >>> a
> > > > >>> better
> > > > >>> overview in the main tab. If it will be done we can
decide if we
> > > > >>> want
> > > > >>> to
> > > > >>> give
> > > > >>> more
> > > > >>> details in sub tabs.
> > > > >>>
> > > > >>>> We could later on have a (live data Tab) in other
places as well
> > > > >>>> like
> > > > >>>> host,
> > > > >>>> cluster...
> > > > >>>> Eldan
> > > > >>>
> > > > >>> [1]: http://www.ovirt.org/Download
> > > > >>> [2]: http://caniuse.com/#feat=canvas
> > > > >>>
> > > > >>>> ----- Original Message -----
> > > > >>>> From: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > >>>> To: "Ewoud Kohl van Wijngaarden"
> > > > >>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > > >>>> Cc: "Alexander Wels"
<awels(a)redhat.com>, "Eldan Hildesheim"
> > > > >>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info"
> > > > >>>> <info(a)eldanet.com>
> > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM
> > > > >>>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line chart?
> > > > >>>>
> > > > >>>>> ----- Original Message -----
> > > > >>>>> From: "Ewoud Kohl van Wijngaarden"
> > > > >>>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
> > > > >>>>>
> > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500,
Alexander Wels 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.
> > > > >>>>>
> > > > >>>>> I'd say no. Even from a reliability point of
view since users
> > > > >>>>> may
> > > > >>>>> have
> > > > >>>>> systems that aren't connected to the
internet.
> > > > >>>>
> > > > >>>> +1
> > > > >>>>
> > > > >>>>> (Though I don't know how well oVirt handles
this currently.)
> > > > >>>>
> > > > >>>> AFAIK - oVirt is handling it ('it' ==
having no internet
> > > > >>>> connection)
> > > > >>>> well.
> > > > >>>> _______________________________________________
> > > > >>>> Engine-devel mailing list
> > > > >>>> Engine-devel(a)ovirt.org
> > > > >>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> Engine-devel mailing list
> > > > >>> Engine-devel(a)ovirt.org
> > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>
> > > > >> _______________________________________________
> > > > >> Engine-devel mailing list
> > > > >> Engine-devel(a)ovirt.org
> > > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
> From: "Alexander Wels" <awels(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>,
> "info" <info(a)eldanet.com>
> Sent: Tuesday, November 12, 2013 4:03:14 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote:
> > ----- Original Message -----
> >
> > > From: "Alexander Wels" <awels(a)redhat.com>
> > > To: engine-devel(a)ovirt.org
> > > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Michal
Skrivanek"
> > > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> > > <ehildesh(a)redhat.com>,
> > > "info" <info(a)eldanet.com>
> > > Sent: Tuesday, November 12, 2013 3:33:56 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >
> > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote:
> > > > Hey all,
> > > >
> > > > let me conclude what has been written in this thread to one
> > > > proposal:
> > > >
> > > > == From the UX perspective the behavior ==
> > > > - each time the FE will receive new data and this data are different
> > > > from
> > > > the old ones, visualize it in the chart It means if you will keep
> > > > pressing
> > > > the refresh button but the data will not change, no new data will be
> > > > visualized (an exception will be the 0 usage) - the amount of data
> > > > visualized will depend on the size of the widget (since the tables
> > > > are
> > > > resizable). It means that if you make the widget bigger you will not
> > > > see
> > > > the same chart bigger but more data. - If you make the widget
> > > > bigger,
> > > > only
> > > > then the amount of data will start to increase: e.g.
> > > >
> > > > before resize:
> > > > | /-------\ |
> > > > |
> > > > |/ \|
> > > >
> > > > after resize:
> > > > | /-------\ |
> > > > |
> > > > |/ \ |
> > > >
> > > > and only now the new data will start to appear
> > > >
> > > > == From FE technical point of view ==
> > > > - since I have not found any GWT library which would be acceptable
> > > > (e.g.
> > > > actively developed and without the need to connect to google
> > > > servers)
> > > > and
> > > > given that the required chart is quite simple I guess it would be ok
> > > > to
> > > > write it by myself. - according to Einav's mail it is ok to use
> > > > HTML5
> > > > canvas so I would go with writing a new widget using HTML5 canvas
> > >
> > > Just to throw out something to think about, we could also in theory
> > > generate an image on the server side and simply display that image
> > > inside
> > > the grid (so no need for HTML5 canvas or other things like that). The
> > > idea being basically that when the grid refreshes it makes a request
> > > for
> > > a new image on the back- end with the appropriate timeframe and the
> > > back-end generates the image which is easy to embed inside the grid.
> > >
> > > pros:
> > > * Easy to embed inside grid (just an image tag).
> > > * Works on all browsers, even ones without HTML5 canvas support.
> > > cons:
> > > * More load on the back-end.
> > > * Extra round trips to back-end on refresh.
> > > * Not 'hot' like HTML5 canvas.
> > > * No interactivity if that is something we are interested in.
> >
> > some more cons:
> > * need to remember the statistics on server in the memory. For thousands
> > of
> > VMs it is not something we would like to do * lots of overhead to
> > retrieve
> > all the images on each refresh. If you have 100 VMs on a page and
> > refresh
> > each 5 seconds, it is 100 images transmitted from engine to frontend
> > each 5
> > seconds per one client (and we can have more of them of course) * FE
> > logic
> > on Server is in general not awesome
>
> I would expect the statistics to be stored in the database somewhere, that
> way
> we can pull them for reports and things of that nature (like charts).
> Obviously we wouldn't do 100 round trips for the image, we would generate
> a
> single image sprite that would contain all the images in a single request
> and display the appropriate part of the image in the grid.
>
> You are right in general front-end logic is not done on the back-end.
> However we must consider if we are really doing front end logic here, or
> if we are just displaying some reporting information as part of the grid.
>
> If we are not storing the statistics anywhere, then this is a terrible
> plan, and we should do the logic on the client, but if we are, it is
> something to consider.
We store only the actual value. The statistics are stored only by DWH
but that is a different application. Engine itself does not have it so we
would have to implement it.
Which as you mentioned is not a desirable thing to do for thousands of VMs,
but does bring up the question, if we only aggregate the statistics on the
client, do we care if that information is lost when the user logs out/switches
tab/etc. Since essentially we stop requesting that information from the back-
end if the current active tab is not the VM main tab.
> > > > == From L&F point of view ==
> > > > - would look pretty much like the one proposed by Malini:
> > > > http://style.org/chartapi/sparklines/
> > > >
> > > > == From data point of view ==
> > > > - do not do any averages on VDSM side (since it already does them
> > > > for
> > > > CPU
> > > > and network and the memory is stable enough) - do not do any
> > > > averages
> > > > on
> > > > engine side (since would have to be done for each FE separately and
> > > > stored
> > > > in session which is a bit overcomplicated. If the user wants to see
> > > > more
> > > > accurate data, he/she can change the refresh rate) - do not do any
> > > > interpolation since the data are already averaged and we will show
> > > > only
> > > > new
> > > > ones
> > > >
> > > > @Malini,Einav,Eldan,Michal what do you think?
> > > >
> > > > Tomas
> > > >
> > > > ----- Original Message -----
> > > >
> > > > > From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
> > > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"Dan Kenigsberg"
> > > > > <danken(a)redhat.com> Cc: "Malini Rao"
<mrao(a)redhat.com>, "Eldan
> > > > > Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org, "info"
> > > > > <info(a)eldanet.com>
> > > > > Sent: Tuesday, November 12, 2013 11:49:12 AM
> > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > > >
> > > > > On Nov 12, 2013, at 11:18 , Tomas Jelinek
<tjelinek(a)redhat.com>
> > > > >
> > > > > wrote:
> > > > > > So we have looked into the resource usage sampling with
mbetak
> > > > > > and
> > > > > > also
> > > > > > with Michal and it seems that
> > > > > >
> > > > > > for the CPU usage:
> > > > > > - VDSM polls libvirt to get the runtime statistics of the
VM
> > > > > > regularly.
> > > > > > The
> > > > > > pooling interval is configured in
> > > > > >
> > > > > > vdsm.conf as vm_sample_cpu_interval and by default it is
15
> > > > > > seconds
> > > > > >
> > > > > > - libvirt returns something we than use to calculate the
average
> > > > > > CPU
> > > > > > usage
> > > > > > since the last poll
> > > > > > - engine polls VDSM once in 15 seconds to get the current
> > > > > > statistics
> > > > > > (the
> > > > > > same 15 seconds is just a coincidence and we can not count
on
> > > > > > this)
> > > > > > - than the frontend polls the engine each 5-60 seconds
(depends
> > > > > > on
> > > > > > the
> > > > > > refresh rate) and gets the current value from the engine
> > > > > > - the user can press the refresh button anytime to poll
the
> > > > > > engine
> > > > > > again
> > > > > >
> > > > > > For network usage:
> > > > > > - it should be pretty much the same as the CPU just the
VDSM
> > > > > > poll
> > > > > > interval
> > > > > > is configured as vm_sample_net_interval and by default it
is 5
> > > > > > seconds
> > > > >
> > > > > Dan, since we poll only every 15s and cpu info is 15s
wouldn't it
> > > > > make
> > > > > sense to change the default for network monitoring to 15s as
well?
> > > > > it's 2
> > > > > libvirt rounds trip for nothing really. Or does it serve some
> > > > > other
> > > > > purpose?>
> > > > >
> > > > > > For memory usage:
> > > > > > - guest agent sends a message to VDSM with the memory
usage
> > > > > > regularly.
> > > > > > The
> > > > > > interval is set in ovirt-guest-agent.conf as
heart_beat_rate
> > > > > >
> > > > > > and by default it is 5 seconds
> > > > > >
> > > > > > - the actual value sent by ovirt-guest-agent is the actual
value
> > > > > > at
> > > > > > the
> > > > > > time when the value is sent (e.g. for Linux taken from
"cat
> > > > > > /proc/meminfo")
> > > > > > - vdsm is doing no statistics on top of it, just remembers
the
> > > > > > last
> > > > > > value
> > > > > > taken from ovirt-guest-agent
> > > > >
> > > > > which is fine, it doesn't change so often and there are
typically
> > > > > no
> > > > > spikes
> > > > >
> > > > > > - the rest of the poling is the same
> > > > > >
> > > > > > So, visualizing this in some usable form will be quite
> > > > > > challenging
> > > > > > ;)
> > > > > > I see the following problems:
> > > > > > - if the VDSM gets the data faster than the engine polls it
(and
> > > > > > most
> > > > > > often
> > > > > > it does) than the info in between will be lost.
> > > > > >
> > > > > > The question is how big this problem is and if it is
worth
> > > > > > solving
> > > > > > (I
> > > > > > would say not for CPU which are averages but maybe yes
for
> > > > > > memory).
> > > > > > Other question if there is a way how to solve it since the
VDSM
> > > > > > can
> > > > > > be
> > > > > > polled by anyone and it does not really care if someone
polls
> > > > > > it...
> > > > > > (Michal?)
> > > > >
> > > > > I'd say not solve it and try to keep it in sync on vdsm side
with
> > > > > engine
> > > > > poll, to save unnecessary libvirt calls
> > > > >
> > > > > > - we can lost some data between frontend<->engine if
the polling
> > > > > > interval
> > > > > > of the FE is slower than the polling interval of the
engine.
> > > > > > This
> > > > > > is
> > > > > > something
> > > > > >
> > > > > > not really worth solving because the user can set this
> > > > > > according
> > > > > > to
> > > > > > the
> > > > > > level of detail he/she wants
> > > > >
> > > > > well, you should average the values in engine in case the FE
> > > > > refresh
> > > > > is
> > > > >
> > > > > >15s. Or add (refresh/15) of them
> > > >
> > > > It is not that simple since you can have more frontends and not sure
> > > > if
> > > > it
> > > > would be a good idea to put this into the session...
> > > >
> > > > > > - since we will get new info once in ~15 seconds, and the
> > > > > > polling
> > > > > > of
> > > > > > the
> > > > > > FE
> > > > > > is by default 5 seconds, do we want to do some
interpolation? Or
> > > > > > just
> > > > > > show
> > > > > > the
> > > > > >
> > > > > > same value 3 times? Or be smart and show only changed
values?
> > > > > > (this
> > > > > > is
> > > > > > tricky since there is a chance that it did not change -
e.g.
> > > > > > constant
> > > > > > 0
> > > > > > mem usage if you have no guest agent)
> > > > > >
> > > > > > - What if the user starts clicking to the refresh button?
Do we
> > > > > > want
> > > > > > to
> > > > > > keep appending the same value if the engine still has only
the
> > > > > > old
> > > > > > ones?
> > > > >
> > > > > just add a new line/point every 15s should be ok
> > > > >
> > > > > Thanks,
> > > > > michal
> > > > >
> > > > > > Tomas
> > > > > >
> > > > > > ----- Original Message -----
> > > > > >
> > > > > >> From: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >> To: "Malini Rao" <mrao(a)redhat.com>
> > > > > >> Cc: "Eldan Hildesheim"
<ehildesh(a)redhat.com>,
> > > > > >> engine-devel(a)ovirt.org,
> > > > > >> "info" <info(a)eldanet.com>
> > > > > >> Sent: Monday, November 11, 2013 4:23:09 PM
> > > > > >> Subject: Re: [Engine-devel] [UX] how to design a
bar/line
> > > > > >> chart?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>
> > > > > >>> From: "Malini Rao"
<mrao(a)redhat.com>
> > > > > >>> To: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > > >>> Cc: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "info"
> > > > > >>> <info(a)eldanet.com>,
> > > > > >>> engine-devel(a)ovirt.org
> > > > > >>> Sent: Monday, November 11, 2013 4:15:50 PM
> > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line
> > > > > >>> chart?
> > > > > >>>
> > > > > >>> Is this going to fit in a row of a table? Or are we
talking of
> > > > > >>> a
> > > > > >>> more
> > > > > >>> detailed view?
> > > > > >>
> > > > > >> it should fit into one cell of the table
> > > > > >>
> > > > > >>> ----- Original Message -----
> > > > > >>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > > >>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > > > > >>> Sent: Monday, November 11, 2013 8:01:07 AM
> > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line
> > > > > >>> chart?
> > > > > >>>
> > > > > >>> Throw this gif into a browser. This is more or less
what I
> > > > > >>> thought.
> > > > > >>> Eldan
> > > > > >>>
> > > > > >>> ----- Original Message -----
> > > > > >>> From: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >>> To: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > > >>> Cc: "Einav Cohen"
<ecohen(a)redhat.com>, "info"
> > > > > >>> <info(a)eldanet.com>,
> > > > > >>> engine-devel(a)ovirt.org
> > > > > >>> Sent: Monday, November 11, 2013 12:03:15 PM
> > > > > >>> Subject: Re: [Engine-devel] [UX] how to design a
bar/line
> > > > > >>> chart?
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> ----- Original Message -----
> > > > > >>>
> > > > > >>>> From: "Eldan Hildesheim"
<ehildesh(a)redhat.com>
> > > > > >>>> To: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > > >>>> Cc: "info" <info(a)eldanet.com>,
engine-devel(a)ovirt.org
> > > > > >>>> Sent: Sunday, November 10, 2013 3:56:57 PM
> > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design
a bar/line
> > > > > >>>> chart?
> > > > > >>>>
> > > > > >>>> Hello all,
> > > > > >>>> We use to have a good solution in the period
pre-WPF.
> > > > > >>>> A line chart (used to be in flash) that works
like a plotter:
> > > > > >>>> The Line Bar (not bar) had a small animation
that shifted all
> > > > > >>>> the
> > > > > >>>> bar
> > > > > >>>> to
> > > > > >>>> the
> > > > > >>>> left.
> > > > > >>>> When a new data arrived it just added a new
line (to the
> > > > > >>>> right)
> > > > > >>>> and
> > > > > >>>> as I
> > > > > >>>> said
> > > > > >>>> before, in parallel it always shifted slowly to
the left.
> > > > > >>>
> > > > > >>> Any chance you still have some screenshot or mockup
so I can
> > > > > >>> imagine
> > > > > >>> it
> > > > > >>> better?
> > > > > >>>
> > > > > >>>> The animation gives the impression that data is
streaming and
> > > > > >>>> when a
> > > > > >>>> real
> > > > > >>>> new
> > > > > >>>> data arrives the user gets it very fast.
> > > > > >>>> We have to sync between the animation and the
rate of the
> > > > > >>>> arrival
> > > > > >>>> of
> > > > > >>>> the
> > > > > >>>> data
> > > > > >>>> but this is easy.
> > > > > >>>> If we can't find a good framework it can be
created from
> > > > > >>>> scratch
> > > > > >>>> with
> > > > > >>>> JS,
> > > > > >>>> svg
> > > > > >>>> or canvas.
> > > > > >>>
> > > > > >>> We need to be careful about what we will use. oVirt
is
> > > > > >>> supposed
> > > > > >>> to
> > > > > >>> work
> > > > > >>> on
> > > > > >>> FF
> > > > > >>> 17 [1]
> > > > > >>> but the HTML5 canvas works only since FF23 [2].
> > > > > >>>
> > > > > >>> @Einav:
> > > > > >>> Is there a chance that we could start support only
FF23+ and
> > > > > >>> IE9+
> > > > > >>> (this
> > > > > >>> one
> > > > > >>> is already OK)
> > > > > >>> because of this feature?
> > > > > >>>
> > > > > >>>> Now regarding its position:
> > > > > >>>> Rollover is good but not enough, we should
somehow put it in
> > > > > >>>> the
> > > > > >>>> lower
> > > > > >>>> panel
> > > > > >>>> under general or even another tab - (live
data).
> > > > > >>>
> > > > > >>> This is a bit different requirement. The point of
this
> > > > > >>> specific
> > > > > >>> is
> > > > > >>> to
> > > > > >>> give
> > > > > >>> a
> > > > > >>> better
> > > > > >>> overview in the main tab. If it will be done we can
decide if
> > > > > >>> we
> > > > > >>> want
> > > > > >>> to
> > > > > >>> give
> > > > > >>> more
> > > > > >>> details in sub tabs.
> > > > > >>>
> > > > > >>>> We could later on have a (live data Tab) in
other places as
> > > > > >>>> well
> > > > > >>>> like
> > > > > >>>> host,
> > > > > >>>> cluster...
> > > > > >>>> Eldan
> > > > > >>>
> > > > > >>> [1]: http://www.ovirt.org/Download
> > > > > >>> [2]: http://caniuse.com/#feat=canvas
> > > > > >>>
> > > > > >>>> ----- Original Message -----
> > > > > >>>> From: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > > >>>> To: "Ewoud Kohl van Wijngaarden"
> > > > > >>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > > > >>>> Cc: "Alexander Wels"
<awels(a)redhat.com>, "Eldan Hildesheim"
> > > > > >>>> <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org, "info"
> > > > > >>>> <info(a)eldanet.com>
> > > > > >>>> Sent: Friday, November 8, 2013 10:50:10 PM
> > > > > >>>> Subject: Re: [Engine-devel] [UX] how to design
a bar/line
> > > > > >>>> chart?
> > > > > >>>>
> > > > > >>>>> ----- Original Message -----
> > > > > >>>>> From: "Ewoud Kohl van
Wijngaarden"
> > > > > >>>>> <ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > > > >>>>> Sent: Thursday, November 7, 2013 11:44:07
AM
> > > > > >>>>>
> > > > > >>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500,
Alexander Wels
From: "Alexander Wels" <awels(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>
Sent: Tuesday, November 12, 2013 4:52:12 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote:
> ----- Original Message -----
>
> > From: "Alexander Wels" <awels(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>,
> > "info" <info(a)eldanet.com>
> > Sent: Tuesday, November 12, 2013 4:03:14 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote:
> > > ----- Original Message -----
> > >
> > > > From: "Alexander Wels" <awels(a)redhat.com>
> > > > To: engine-devel(a)ovirt.org
> > > > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"Michal Skrivanek"
> > > > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> > > > <ehildesh(a)redhat.com>,
> > > > "info" <info(a)eldanet.com>
> > > > Sent: Tuesday, November 12, 2013 3:33:56 PM
> > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > >
> > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote:
> > > > > Hey all,
> > > > >
> > > > > let me conclude what has been written in this thread to one
> > > > > proposal:
> > > > >
> > > > > == From the UX perspective the behavior ==
> > > > > - each time the FE will receive new data and this data are
> > > > > different
> > > > > from
> > > > > the old ones, visualize it in the chart It means if you will
keep
> > > > > pressing
> > > > > the refresh button but the data will not change, no new data
will
> > > > > be
> > > > > visualized (an exception will be the 0 usage) - the amount of
data
> > > > > visualized will depend on the size of the widget (since the
tables
> > > > > are
> > > > > resizable). It means that if you make the widget bigger you
will
> > > > > not
> > > > > see
> > > > > the same chart bigger but more data. - If you make the widget
> > > > > bigger,
> > > > > only
> > > > > then the amount of data will start to increase: e.g.
> > > > >
> > > > > before resize:
> > > > > | /-------\ |
> > > > > |
> > > > > |/ \|
> > > > >
> > > > > after resize:
> > > > > | /-------\ |
> > > > > |
> > > > > |/ \ |
> > > > >
> > > > > and only now the new data will start to appear
> > > > >
> > > > > == From FE technical point of view ==
> > > > > - since I have not found any GWT library which would be
acceptable
> > > > > (e.g.
> > > > > actively developed and without the need to connect to google
> > > > > servers)
> > > > > and
> > > > > given that the required chart is quite simple I guess it would
be
> > > > > ok
> > > > > to
> > > > > write it by myself. - according to Einav's mail it is ok to
use
> > > > > HTML5
> > > > > canvas so I would go with writing a new widget using HTML5
canvas
> > > >
> > > > Just to throw out something to think about, we could also in theory
> > > > generate an image on the server side and simply display that image
> > > > inside
> > > > the grid (so no need for HTML5 canvas or other things like that).
The
> > > > idea being basically that when the grid refreshes it makes a request
> > > > for
> > > > a new image on the back- end with the appropriate timeframe and the
> > > > back-end generates the image which is easy to embed inside the grid.
> > > >
> > > > pros:
> > > > * Easy to embed inside grid (just an image tag).
> > > > * Works on all browsers, even ones without HTML5 canvas support.
> > > > cons:
> > > > * More load on the back-end.
> > > > * Extra round trips to back-end on refresh.
> > > > * Not 'hot' like HTML5 canvas.
> > > > * No interactivity if that is something we are interested in.
> > >
> > > some more cons:
> > > * need to remember the statistics on server in the memory. For
> > > thousands
> > > of
> > > VMs it is not something we would like to do * lots of overhead to
> > > retrieve
> > > all the images on each refresh. If you have 100 VMs on a page and
> > > refresh
> > > each 5 seconds, it is 100 images transmitted from engine to frontend
> > > each 5
> > > seconds per one client (and we can have more of them of course) * FE
> > > logic
> > > on Server is in general not awesome
> >
> > I would expect the statistics to be stored in the database somewhere,
> > that
> > way
> > we can pull them for reports and things of that nature (like charts).
> > Obviously we wouldn't do 100 round trips for the image, we would generate
> > a
> > single image sprite that would contain all the images in a single request
> > and display the appropriate part of the image in the grid.
> >
> > You are right in general front-end logic is not done on the back-end.
> > However we must consider if we are really doing front end logic here, or
> > if we are just displaying some reporting information as part of the grid.
> >
> > If we are not storing the statistics anywhere, then this is a terrible
> > plan, and we should do the logic on the client, but if we are, it is
> > something to consider.
>
> We store only the actual value. The statistics are stored only by DWH
> but that is a different application. Engine itself does not have it so we
> would have to implement it.
>
Which as you mentioned is not a desirable thing to do for thousands of VMs,
but does bring up the question, if we only aggregate the statistics on the
client, do we care if that information is lost when the user logs
out/switches
tab/etc. Since essentially we stop requesting that information from the back-
end if the current active tab is not the VM main tab.
I would say it is not a problem. The VM tab is not for detailed statistics or history
data.
For this kind of data we have the reports portal.
On the other hand it may be painful to go to the VM tab and see no statistics and get them
updated
each 15 seconds. So after couple of minutes you will maybe see something useful. Just
don't click on any
other tab, otherwise you will loose that all :)
@Michal,Einav: Is this acceptable?
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: awels(a)redhat.com
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info" <info(a)eldanet.com>
Sent: Wednesday, November 13, 2013 8:21:56 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
----- Original Message -----
> From: "Alexander Wels" <awels(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>
> Sent: Tuesday, November 12, 2013 4:52:12 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
> On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote:
> > ----- Original Message -----
> >
> > > From: "Alexander Wels" <awels(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> > > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> > > <ehildesh(a)redhat.com>,
> > > "info" <info(a)eldanet.com>
> > > Sent: Tuesday, November 12, 2013 4:03:14 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >
> > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote:
> > > > ----- Original Message -----
> > > >
> > > > > From: "Alexander Wels" <awels(a)redhat.com>
> > > > > To: engine-devel(a)ovirt.org
> > > > > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"Michal Skrivanek"
> > > > > <michal.skrivanek(a)redhat.com>, "Eldan
Hildesheim"
> > > > > <ehildesh(a)redhat.com>,
> > > > > "info" <info(a)eldanet.com>
> > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM
> > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > > >
> > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek wrote:
> > > > > > Hey all,
> > > > > >
> > > > > > let me conclude what has been written in this thread to
one
> > > > > > proposal:
> > > > > >
> > > > > > == From the UX perspective the behavior ==
> > > > > > - each time the FE will receive new data and this data are
> > > > > > different
> > > > > > from
> > > > > > the old ones, visualize it in the chart It means if you
will keep
> > > > > > pressing
> > > > > > the refresh button but the data will not change, no new
data will
> > > > > > be
> > > > > > visualized (an exception will be the 0 usage) - the amount
of
> > > > > > data
> > > > > > visualized will depend on the size of the widget (since
the
> > > > > > tables
> > > > > > are
> > > > > > resizable). It means that if you make the widget bigger you
will
> > > > > > not
> > > > > > see
> > > > > > the same chart bigger but more data. - If you make the
widget
> > > > > > bigger,
> > > > > > only
> > > > > > then the amount of data will start to increase: e.g.
> > > > > >
> > > > > > before resize:
> > > > > > | /-------\ |
> > > > > > |
> > > > > > |/ \|
> > > > > >
> > > > > > after resize:
> > > > > > | /-------\ |
> > > > > > |
> > > > > > |/ \ |
> > > > > >
> > > > > > and only now the new data will start to appear
> > > > > >
> > > > > > == From FE technical point of view ==
> > > > > > - since I have not found any GWT library which would be
> > > > > > acceptable
> > > > > > (e.g.
> > > > > > actively developed and without the need to connect to
google
> > > > > > servers)
> > > > > > and
> > > > > > given that the required chart is quite simple I guess it
would be
> > > > > > ok
> > > > > > to
> > > > > > write it by myself. - according to Einav's mail it is
ok to use
> > > > > > HTML5
> > > > > > canvas so I would go with writing a new widget using HTML5
canvas
> > > > >
> > > > > Just to throw out something to think about, we could also in
theory
> > > > > generate an image on the server side and simply display that
image
> > > > > inside
> > > > > the grid (so no need for HTML5 canvas or other things like
that).
> > > > > The
> > > > > idea being basically that when the grid refreshes it makes a
> > > > > request
> > > > > for
> > > > > a new image on the back- end with the appropriate timeframe and
the
> > > > > back-end generates the image which is easy to embed inside the
> > > > > grid.
> > > > >
> > > > > pros:
> > > > > * Easy to embed inside grid (just an image tag).
> > > > > * Works on all browsers, even ones without HTML5 canvas
support.
> > > > > cons:
> > > > > * More load on the back-end.
> > > > > * Extra round trips to back-end on refresh.
> > > > > * Not 'hot' like HTML5 canvas.
> > > > > * No interactivity if that is something we are interested in.
> > > >
> > > > some more cons:
> > > > * need to remember the statistics on server in the memory. For
> > > > thousands
> > > > of
> > > > VMs it is not something we would like to do * lots of overhead to
> > > > retrieve
> > > > all the images on each refresh. If you have 100 VMs on a page and
> > > > refresh
> > > > each 5 seconds, it is 100 images transmitted from engine to frontend
> > > > each 5
> > > > seconds per one client (and we can have more of them of course) * FE
> > > > logic
> > > > on Server is in general not awesome
> > >
> > > I would expect the statistics to be stored in the database somewhere,
> > > that
> > > way
> > > we can pull them for reports and things of that nature (like charts).
> > > Obviously we wouldn't do 100 round trips for the image, we would
> > > generate
> > > a
> > > single image sprite that would contain all the images in a single
> > > request
> > > and display the appropriate part of the image in the grid.
> > >
> > > You are right in general front-end logic is not done on the back-end.
> > > However we must consider if we are really doing front end logic here,
> > > or
> > > if we are just displaying some reporting information as part of the
> > > grid.
> > >
> > > If we are not storing the statistics anywhere, then this is a terrible
> > > plan, and we should do the logic on the client, but if we are, it is
> > > something to consider.
> >
> > We store only the actual value. The statistics are stored only by DWH
> > but that is a different application. Engine itself does not have it so we
> > would have to implement it.
> >
>
> Which as you mentioned is not a desirable thing to do for thousands of VMs,
> but does bring up the question, if we only aggregate the statistics on the
> client, do we care if that information is lost when the user logs
> out/switches
> tab/etc. Since essentially we stop requesting that information from the
> back-
> end if the current active tab is not the VM main tab.
I would say it is not a problem. The VM tab is not for detailed statistics or
history data.
For this kind of data we have the reports portal.
On the other hand it may be painful to go to the VM tab and see no statistics
and get them updated
each 15 seconds. So after couple of minutes you will maybe see something
useful. Just don't click on any
other tab, otherwise you will loose that all :)
@Michal,Einav: Is this acceptable?
OK, after some more discussions with Michal about the idea of having some history data in
our DB it starts to look like a really good idea.
What about this solution:
Let's store the last N results of VDSM poll in the vm_dynamic table instead of the
last one only
(where the N would be configured in vdc_options and by default something like 10).
Let's send this to client so the client will be able to draw a nice chart out of all
the values which are available.
It would have this advantages:
Technical:
- no lost data caused by slower polling of engine by FE than is the polling of the VDSM by
engine
- consequently no need to do any interpolations because the data are already averaged by
VDSM and I have no "holes" in between
- also no problems to "ignore" updates caused by faster refresh of engine by FE
than the poll of VDSM by engine
UX:
- after the first load of the VM tab the data shown in this tab would already be useful -
no need to wait couple of refresh cycles until I get enough poll results
- I can freely jump from tab to tab without the fear to loose all precious data I have in
this tab collected
Disadvantage is that we would have to store a bit more data on the server (but not much
more since we would remember only couple of polls) and a bit more data transferred to
client.
What do you guys think?
----- Original Message -----
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
Sent: Wednesday, November 13, 2013 8:42:40 AM
----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: awels(a)redhat.com
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org,
> "info" <info(a)eldanet.com>
> Sent: Wednesday, November 13, 2013 8:21:56 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
>
>
> ----- Original Message -----
> > From: "Alexander Wels" <awels(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>
> > Sent: Tuesday, November 12, 2013 4:52:12 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote:
> > > ----- Original Message -----
> > >
> > > > From: "Alexander Wels" <awels(a)redhat.com>
> > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > > Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> > > > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> > > > <ehildesh(a)redhat.com>,
> > > > "info" <info(a)eldanet.com>
> > > > Sent: Tuesday, November 12, 2013 4:03:14 PM
> > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > > >
> > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote:
> > > > > ----- Original Message -----
> > > > >
> > > > > > From: "Alexander Wels" <awels(a)redhat.com>
> > > > > > To: engine-devel(a)ovirt.org
> > > > > > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"Michal Skrivanek"
> > > > > > <michal.skrivanek(a)redhat.com>, "Eldan
Hildesheim"
> > > > > > <ehildesh(a)redhat.com>,
> > > > > > "info" <info(a)eldanet.com>
> > > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM
> > > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > > > >
> > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas Jelinek
wrote:
> > > > > > > Hey all,
> > > > > > >
> > > > > > > let me conclude what has been written in this thread
to one
> > > > > > > proposal:
> > > > > > >
> > > > > > > == From the UX perspective the behavior ==
> > > > > > > - each time the FE will receive new data and this data
are
> > > > > > > different
> > > > > > > from
> > > > > > > the old ones, visualize it in the chart It means if
you will
> > > > > > > keep
> > > > > > > pressing
> > > > > > > the refresh button but the data will not change, no
new data
> > > > > > > will
> > > > > > > be
> > > > > > > visualized (an exception will be the 0 usage) - the
amount of
> > > > > > > data
> > > > > > > visualized will depend on the size of the widget
(since the
> > > > > > > tables
> > > > > > > are
> > > > > > > resizable). It means that if you make the widget
bigger you
> > > > > > > will
> > > > > > > not
> > > > > > > see
> > > > > > > the same chart bigger but more data. - If you make the
widget
> > > > > > > bigger,
> > > > > > > only
> > > > > > > then the amount of data will start to increase: e.g.
> > > > > > >
> > > > > > > before resize:
> > > > > > > | /-------\ |
> > > > > > > |
> > > > > > > |/ \|
> > > > > > >
> > > > > > > after resize:
> > > > > > > | /-------\ |
> > > > > > > |
> > > > > > > |/ \ |
> > > > > > >
> > > > > > > and only now the new data will start to appear
> > > > > > >
> > > > > > > == From FE technical point of view ==
> > > > > > > - since I have not found any GWT library which would
be
> > > > > > > acceptable
> > > > > > > (e.g.
> > > > > > > actively developed and without the need to connect to
google
> > > > > > > servers)
> > > > > > > and
> > > > > > > given that the required chart is quite simple I guess
it would
> > > > > > > be
> > > > > > > ok
> > > > > > > to
> > > > > > > write it by myself. - according to Einav's mail it
is ok to use
> > > > > > > HTML5
> > > > > > > canvas so I would go with writing a new widget using
HTML5
> > > > > > > canvas
> > > > > >
> > > > > > Just to throw out something to think about, we could also
in
> > > > > > theory
> > > > > > generate an image on the server side and simply display
that
> > > > > > image
> > > > > > inside
> > > > > > the grid (so no need for HTML5 canvas or other things like
that).
> > > > > > The
> > > > > > idea being basically that when the grid refreshes it makes
a
> > > > > > request
> > > > > > for
> > > > > > a new image on the back- end with the appropriate timeframe
and
> > > > > > the
> > > > > > back-end generates the image which is easy to embed inside
the
> > > > > > grid.
> > > > > >
> > > > > > pros:
> > > > > > * Easy to embed inside grid (just an image tag).
> > > > > > * Works on all browsers, even ones without HTML5 canvas
support.
> > > > > > cons:
> > > > > > * More load on the back-end.
> > > > > > * Extra round trips to back-end on refresh.
> > > > > > * Not 'hot' like HTML5 canvas.
> > > > > > * No interactivity if that is something we are interested
in.
> > > > >
> > > > > some more cons:
> > > > > * need to remember the statistics on server in the memory. For
> > > > > thousands
> > > > > of
> > > > > VMs it is not something we would like to do * lots of overhead
to
> > > > > retrieve
> > > > > all the images on each refresh. If you have 100 VMs on a page
and
> > > > > refresh
> > > > > each 5 seconds, it is 100 images transmitted from engine to
> > > > > frontend
> > > > > each 5
> > > > > seconds per one client (and we can have more of them of course)
*
> > > > > FE
> > > > > logic
> > > > > on Server is in general not awesome
> > > >
> > > > I would expect the statistics to be stored in the database
somewhere,
> > > > that
> > > > way
> > > > we can pull them for reports and things of that nature (like
charts).
> > > > Obviously we wouldn't do 100 round trips for the image, we would
> > > > generate
> > > > a
> > > > single image sprite that would contain all the images in a single
> > > > request
> > > > and display the appropriate part of the image in the grid.
> > > >
> > > > You are right in general front-end logic is not done on the
back-end.
> > > > However we must consider if we are really doing front end logic
here,
> > > > or
> > > > if we are just displaying some reporting information as part of the
> > > > grid.
> > > >
> > > > If we are not storing the statistics anywhere, then this is a
> > > > terrible
> > > > plan, and we should do the logic on the client, but if we are, it is
> > > > something to consider.
> > >
> > > We store only the actual value. The statistics are stored only by DWH
> > > but that is a different application. Engine itself does not have it so
> > > we
> > > would have to implement it.
> > >
> >
> > Which as you mentioned is not a desirable thing to do for thousands of
> > VMs,
> > but does bring up the question, if we only aggregate the statistics on
> > the
> > client, do we care if that information is lost when the user logs
> > out/switches
> > tab/etc. Since essentially we stop requesting that information from the
> > back-
> > end if the current active tab is not the VM main tab.
>
> I would say it is not a problem. The VM tab is not for detailed statistics
> or
> history data.
> For this kind of data we have the reports portal.
>
> On the other hand it may be painful to go to the VM tab and see no
> statistics
> and get them updated
> each 15 seconds. So after couple of minutes you will maybe see something
> useful. Just don't click on any
> other tab, otherwise you will loose that all :)
>
> @Michal,Einav: Is this acceptable?
OK, after some more discussions with Michal about the idea of having some
history data in our DB it starts to look like a really good idea.
What about this solution:
Let's store the last N results of VDSM poll in the vm_dynamic table instead
of the last one only
(where the N would be configured in vdc_options and by default something like
10).
Let's send this to client so the client will be able to draw a nice chart out
of all the values which are available.
It would have this advantages:
Technical:
- no lost data caused by slower polling of engine by FE than is the polling
of the VDSM by engine
- consequently no need to do any interpolations because the data are already
averaged by VDSM and I have no "holes" in between
- also no problems to "ignore" updates caused by faster refresh of engine by
FE than the poll of VDSM by engine
UX:
- after the first load of the VM tab the data shown in this tab would already
be useful - no need to wait couple of refresh cycles until I get enough poll
results
- I can freely jump from tab to tab without the fear to loose all precious
data I have in this tab collected
Disadvantage is that we would have to store a bit more data on the server
(but not much more since we would remember only couple of polls) and a bit
more data transferred to client.
What do you guys think?
+1 on this suggestion, I like it a lot.
I am concerned about one thing that you mentioned yesterday (which I don't think
is relevant anymore with this new suggestion, but just in case):
"""
== From the UX perspective the behavior ==
- each time the FE will receive new data and this data are different from the old ones,
visualize it in the chart
It means if you will keep pressing the refresh button but the data will not change, no
new data will be visualized (an exception will be the 0 usage)
"""
IIUC, it means that if the CPU is constantly 5% and it spikes to 100% once an hour,
we will see a graph of 5%-100%-5%-100% (over a *long* period of time though), which
may seem like the VM is spiking half of its time, which is misleading.
But with the new approach of persisting the "historic" info in the DB, this will
not be the case anymore, correct?
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: awels(a)redhat.com, "Eldan Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org, "info" <info(a)eldanet.com>
Sent: Wednesday, November 13, 2013 2:59:48 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> ----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Sent: Wednesday, November 13, 2013 8:42:40 AM
>
>
>
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > To: awels(a)redhat.com
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
engine-devel(a)ovirt.org,
> > "info" <info(a)eldanet.com>
> > Sent: Wednesday, November 13, 2013 8:21:56 AM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> >
> >
> > ----- Original Message -----
> > > From: "Alexander Wels" <awels(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> > > <michal.skrivanek(a)redhat.com>, "Eldan Hildesheim"
> > > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>
> > > Sent: Tuesday, November 12, 2013 4:52:12 PM
> > > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > >
> > > On Tuesday, November 12, 2013 10:21:15 AM Tomas Jelinek wrote:
> > > > ----- Original Message -----
> > > >
> > > > > From: "Alexander Wels" <awels(a)redhat.com>
> > > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > > > Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> > > > > <michal.skrivanek(a)redhat.com>, "Eldan
Hildesheim"
> > > > > <ehildesh(a)redhat.com>,
> > > > > "info" <info(a)eldanet.com>
> > > > > Sent: Tuesday, November 12, 2013 4:03:14 PM
> > > > > Subject: Re: [Engine-devel] [UX] how to design a bar/line
chart?
> > > > >
> > > > > On Tuesday, November 12, 2013 09:50:07 AM Tomas Jelinek wrote:
> > > > > > ----- Original Message -----
> > > > > >
> > > > > > > From: "Alexander Wels"
<awels(a)redhat.com>
> > > > > > > To: engine-devel(a)ovirt.org
> > > > > > > Cc: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "Michal Skrivanek"
> > > > > > > <michal.skrivanek(a)redhat.com>, "Eldan
Hildesheim"
> > > > > > > <ehildesh(a)redhat.com>,
> > > > > > > "info" <info(a)eldanet.com>
> > > > > > > Sent: Tuesday, November 12, 2013 3:33:56 PM
> > > > > > > Subject: Re: [Engine-devel] [UX] how to design a
bar/line
> > > > > > > chart?
> > > > > > >
> > > > > > > On Tuesday, November 12, 2013 09:25:34 AM Tomas
Jelinek wrote:
> > > > > > > > Hey all,
> > > > > > > >
> > > > > > > > let me conclude what has been written in this
thread to one
> > > > > > > > proposal:
> > > > > > > >
> > > > > > > > == From the UX perspective the behavior ==
> > > > > > > > - each time the FE will receive new data and this
data are
> > > > > > > > different
> > > > > > > > from
> > > > > > > > the old ones, visualize it in the chart It means
if you will
> > > > > > > > keep
> > > > > > > > pressing
> > > > > > > > the refresh button but the data will not change,
no new data
> > > > > > > > will
> > > > > > > > be
> > > > > > > > visualized (an exception will be the 0 usage) -
the amount of
> > > > > > > > data
> > > > > > > > visualized will depend on the size of the widget
(since the
> > > > > > > > tables
> > > > > > > > are
> > > > > > > > resizable). It means that if you make the widget
bigger you
> > > > > > > > will
> > > > > > > > not
> > > > > > > > see
> > > > > > > > the same chart bigger but more data. - If you
make the widget
> > > > > > > > bigger,
> > > > > > > > only
> > > > > > > > then the amount of data will start to increase:
e.g.
> > > > > > > >
> > > > > > > > before resize:
> > > > > > > > | /-------\ |
> > > > > > > > |
> > > > > > > > |/ \|
> > > > > > > >
> > > > > > > > after resize:
> > > > > > > > | /-------\ |
> > > > > > > > |
> > > > > > > > |/ \ |
> > > > > > > >
> > > > > > > > and only now the new data will start to appear
> > > > > > > >
> > > > > > > > == From FE technical point of view ==
> > > > > > > > - since I have not found any GWT library which
would be
> > > > > > > > acceptable
> > > > > > > > (e.g.
> > > > > > > > actively developed and without the need to
connect to google
> > > > > > > > servers)
> > > > > > > > and
> > > > > > > > given that the required chart is quite simple I
guess it
> > > > > > > > would
> > > > > > > > be
> > > > > > > > ok
> > > > > > > > to
> > > > > > > > write it by myself. - according to Einav's
mail it is ok to
> > > > > > > > use
> > > > > > > > HTML5
> > > > > > > > canvas so I would go with writing a new widget
using HTML5
> > > > > > > > canvas
> > > > > > >
> > > > > > > Just to throw out something to think about, we could
also in
> > > > > > > theory
> > > > > > > generate an image on the server side and simply
display that
> > > > > > > image
> > > > > > > inside
> > > > > > > the grid (so no need for HTML5 canvas or other things
like
> > > > > > > that).
> > > > > > > The
> > > > > > > idea being basically that when the grid refreshes it
makes a
> > > > > > > request
> > > > > > > for
> > > > > > > a new image on the back- end with the appropriate
timeframe and
> > > > > > > the
> > > > > > > back-end generates the image which is easy to embed
inside the
> > > > > > > grid.
> > > > > > >
> > > > > > > pros:
> > > > > > > * Easy to embed inside grid (just an image tag).
> > > > > > > * Works on all browsers, even ones without HTML5
canvas
> > > > > > > support.
> > > > > > > cons:
> > > > > > > * More load on the back-end.
> > > > > > > * Extra round trips to back-end on refresh.
> > > > > > > * Not 'hot' like HTML5 canvas.
> > > > > > > * No interactivity if that is something we are
interested in.
> > > > > >
> > > > > > some more cons:
> > > > > > * need to remember the statistics on server in the memory.
For
> > > > > > thousands
> > > > > > of
> > > > > > VMs it is not something we would like to do * lots of
overhead to
> > > > > > retrieve
> > > > > > all the images on each refresh. If you have 100 VMs on a
page and
> > > > > > refresh
> > > > > > each 5 seconds, it is 100 images transmitted from engine
to
> > > > > > frontend
> > > > > > each 5
> > > > > > seconds per one client (and we can have more of them of
course) *
> > > > > > FE
> > > > > > logic
> > > > > > on Server is in general not awesome
> > > > >
> > > > > I would expect the statistics to be stored in the database
> > > > > somewhere,
> > > > > that
> > > > > way
> > > > > we can pull them for reports and things of that nature (like
> > > > > charts).
> > > > > Obviously we wouldn't do 100 round trips for the image, we
would
> > > > > generate
> > > > > a
> > > > > single image sprite that would contain all the images in a
single
> > > > > request
> > > > > and display the appropriate part of the image in the grid.
> > > > >
> > > > > You are right in general front-end logic is not done on the
> > > > > back-end.
> > > > > However we must consider if we are really doing front end logic
> > > > > here,
> > > > > or
> > > > > if we are just displaying some reporting information as part of
the
> > > > > grid.
> > > > >
> > > > > If we are not storing the statistics anywhere, then this is a
> > > > > terrible
> > > > > plan, and we should do the logic on the client, but if we are,
it
> > > > > is
> > > > > something to consider.
> > > >
> > > > We store only the actual value. The statistics are stored only by
DWH
> > > > but that is a different application. Engine itself does not have it
> > > > so
> > > > we
> > > > would have to implement it.
> > > >
> > >
> > > Which as you mentioned is not a desirable thing to do for thousands of
> > > VMs,
> > > but does bring up the question, if we only aggregate the statistics on
> > > the
> > > client, do we care if that information is lost when the user logs
> > > out/switches
> > > tab/etc. Since essentially we stop requesting that information from the
> > > back-
> > > end if the current active tab is not the VM main tab.
> >
> > I would say it is not a problem. The VM tab is not for detailed
> > statistics
> > or
> > history data.
> > For this kind of data we have the reports portal.
> >
> > On the other hand it may be painful to go to the VM tab and see no
> > statistics
> > and get them updated
> > each 15 seconds. So after couple of minutes you will maybe see something
> > useful. Just don't click on any
> > other tab, otherwise you will loose that all :)
> >
> > @Michal,Einav: Is this acceptable?
>
> OK, after some more discussions with Michal about the idea of having some
> history data in our DB it starts to look like a really good idea.
>
> What about this solution:
> Let's store the last N results of VDSM poll in the vm_dynamic table instead
> of the last one only
> (where the N would be configured in vdc_options and by default something
> like
> 10).
> Let's send this to client so the client will be able to draw a nice chart
> out
> of all the values which are available.
>
> It would have this advantages:
> Technical:
> - no lost data caused by slower polling of engine by FE than is the polling
> of the VDSM by engine
> - consequently no need to do any interpolations because the data are
> already
> averaged by VDSM and I have no "holes" in between
> - also no problems to "ignore" updates caused by faster refresh of engine
> by
> FE than the poll of VDSM by engine
>
> UX:
> - after the first load of the VM tab the data shown in this tab would
> already
> be useful - no need to wait couple of refresh cycles until I get enough
> poll
> results
> - I can freely jump from tab to tab without the fear to loose all precious
> data I have in this tab collected
>
> Disadvantage is that we would have to store a bit more data on the server
> (but not much more since we would remember only couple of polls) and a bit
> more data transferred to client.
>
> What do you guys think?
+1 on this suggestion, I like it a lot.
I am concerned about one thing that you mentioned yesterday (which I don't
think
is relevant anymore with this new suggestion, but just in case):
"""
== From the UX perspective the behavior ==
- each time the FE will receive new data and this data are different from the
old ones, visualize it in the chart
It means if you will keep pressing the refresh button but the data will not
change, no new data will be visualized (an exception will be the 0 usage)
"""
IIUC, it means that if the CPU is constantly 5% and it spikes to 100% once an
hour,
we will see a graph of 5%-100%-5%-100% (over a *long* period of time though),
which
may seem like the VM is spiking half of its time, which is misleading.
But with the new approach of persisting the "historic" info in the DB, this
will
not be the case anymore, correct?
On Nov 12, 2013, at 11:18 , Tomas Jelinek <tjelinek(a)redhat.com> wrote:
> So we have looked into the resource usage sampling with mbetak and also with Michal
and it seems that
>
> for the CPU usage:
> - VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling
interval is configured in
> vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
> - libvirt returns something we than use to calculate the average CPU usage since the
last poll
> - engine polls VDSM once in 15 seconds to get the current statistics (the same 15
seconds is just a coincidence and we can not count on this)
> - than the frontend polls the engine each 5-60 seconds (depends on the refresh rate)
and gets the current value from the engine
> - the user can press the refresh button anytime to poll the engine again
>
> For network usage:
> - it should be pretty much the same as the CPU just the VDSM poll interval is
configured as vm_sample_net_interval and by default it is 5 seconds
Dan, since we poll only every 15s and cpu info is 15s wouldn't it make
sense to change the default for network monitoring to 15s as well?
it's 2 libvirt rounds trip for nothing really. Or does it serve some
other purpose?
I see no motivation for Vdsm to poll libvirt faster than Engine polls
Vdsm.
Maybe Federico, who's improved scalability back in
https://bugzilla.redhat.com/show_bug.cgi?id=661321 [vdsm] [scale] vdsm CPU consumption
goes between 180-400 when running 100 vms
remembers a reason.
I'm for changing the default to 15.
From this point on, I don't think that there is a reason that we
should "support"
FF17 - we will probably move to "supporting"
FF24, which is the next/current ESR
(other users can correct me if I am wrong - maybe I am missing something).
Need to keep in mind that in the user portal we are still being "friendly" to
IE8
users, so as long as our plans for this feature (at least for the near future) are
for the web-admin only, we are good.
[1] http://en.wikipedia.org/wiki/Firefox_release_history
----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>, engine-devel(a)ovirt.org
> Sent: Monday, November 11, 2013 5:03:15 AM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
>
>
> ----- Original Message -----
> > From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
> > Sent: Sunday, November 10, 2013 3:56:57 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > Hello all,
> > We use to have a good solution in the period pre-WPF.
> > A line chart (used to be in flash) that works like a plotter:
> > The Line Bar (not bar) had a small animation that shifted all the bar to
> > the
> > left.
> > When a new data arrived it just added a new line (to the right) and as I
> > said
> > before, in parallel it always shifted slowly to the left.
>
> Any chance you still have some screenshot or mockup so I can imagine it
> better?
>
> > The animation gives the impression that data is streaming and when a real
> > new
> > data arrives the user gets it very fast.
> > We have to sync between the animation and the rate of the arrival of the
> > data
> > but this is easy.
> > If we can't find a good framework it can be created from scratch with JS,
> > svg
> > or canvas.
>
> We need to be careful about what we will use. oVirt is supposed to work on FF
> 17 [1]
> but the HTML5 canvas works only since FF23 [2].
>
@Einav:
Is there a chance that we could start support only FF23+ and IE9+ (this one
is already OK)
because of this feature?
>
> > Now regarding its position:
> > Rollover is good but not enough, we should somehow put it in the lower
> > panel
> > under general or even another tab - (live data).
>
> This is a bit different requirement. The point of this specific is to give a
> better
> overview in the main tab. If it will be done we can decide if we want to give
> more
> details in sub tabs.
>
> > We could later on have a (live data Tab) in other places as well like host,
> > cluster...
> > Eldan
>
> [1]: http://www.ovirt.org/Download
> [2]: http://caniuse.com/#feat=canvas
>
> >
> > ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
> > Sent: Friday, November 8, 2013 10:50:10 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >
> > > ----- Original Message -----
> > > From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
> > > Sent: Thursday, November 7, 2013 11:44:07 AM
> > >
> > > On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels 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.
> > >
> > > I'd say no. Even from a reliability point of view since users may have
> > > systems that aren't connected to the internet.
> >
> > +1
> >
> > > (Though I don't know how well oVirt handles this currently.)
> >
> > AFAIK - oVirt is handling it ('it' == having no internet connection)
well.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
> @Einav:
> Is there a chance that we could start support only FF23+ and IE9+ (this one
> is already OK)
> because of this feature?
According to [1], FF17 EOL is expected to be at the beginning of December 2013.
From this point on, I don't think that there is a reason that we should
"support"
FF17 - we will probably move to "supporting" FF24, which is the next/current
ESR
(other users can correct me if I am wrong - maybe I am missing something).
Need to keep in mind that in the user portal we are still being "friendly" to
IE8
users, so as long as our plans for this feature (at least for the near future) are
for the web-admin only, we are good.
being friendly to IE8 doesn't mean we can't do this to only work on IE9
and just not have the monitor subtab with this chart for IE8 user portal
users.
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(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>, "info"
<info(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> > "Malini Rao" <mrao(a)redhat.com>, "Martin Polednik"
<mpoledni(a)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(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> > > "Malini Rao" <mrao(a)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(a)redhat.com>
> > > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > > > <engine-devel(a)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(a)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(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> > >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
... 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.
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.
* 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
"""
* 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(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Martin
Polednik" <mpoledni(a)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(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> "Malini Rao" <mrao(a)redhat.com>, "Martin Polednik"
<mpoledni(a)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(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
> > "Malini Rao" <mrao(a)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(a)redhat.com>
> > > To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > > <engine-devel(a)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(a)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(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> >
>
> ... 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.
Since statistics do provide some value and it keeps changing based on load it IMHO looks
ok
...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.
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.
* 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
"""
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
* 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(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Martin
Polednik" <mpoledni(a)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(a)redhat.com>
>> To: "Einav Cohen" <ecohen(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
>> "Malini Rao" <mrao(a)redhat.com>, "Martin Polednik"
<mpoledni(a)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(a)redhat.com>
>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
>>> "Malini Rao" <mrao(a)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(a)redhat.com>
>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
>>>> <engine-devel(a)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(a)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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>>
>>>>
>>>
>>
<trendline-mockup.png>
From: "Michal Skrivanek" <mskrivan(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>, "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"info" <info(a)eldanet.com>, "engine-devel"
<engine-devel(a)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(a)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/TufteSparkl...)
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(a)redhat.com>
>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "engine-devel"
>> <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
"Martin Polednik"
>> <mpoledni(a)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(a)redhat.com>
>>> To: "Einav Cohen" <ecohen(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
>>> "Malini Rao" <mrao(a)redhat.com>, "Martin Polednik"
<mpoledni(a)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(a)redhat.com>
>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
>>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
>>>> "Malini Rao" <mrao(a)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(a)redhat.com>
>>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
>>>>> <engine-devel(a)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(a)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(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>
> <trendline-mockup.png>
> ...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?
... 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?
> 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/TufteSparkl...)
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.
----
Thanks,
Einav
----- Original Message -----
> From: "Malini Rao" <mrao(a)redhat.com>
> To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>, "info"
<info(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>,
> > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > "info" <info(a)eldanet.com>, "engine-devel"
<engine-devel(a)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(a)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?
>
>
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/TufteSparkl...)
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.
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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/TufteSparkl...)
> 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(a)redhat.com>
> To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek"
> > <tjelinek(a)redhat.com>,
> > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > "info" <info(a)eldanet.com>, "engine-devel"
<engine-devel(a)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(a)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/TufteSparkl...)
> 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(a)redhat.com>
> > >> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > >> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"engine-devel"
> > >> <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > >> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>, "Martin Polednik"
> > >> <mpoledni(a)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(a)redhat.com>
> > >>> To: "Einav Cohen" <ecohen(a)redhat.com>
> > >>> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Eldan Hildesheim"
> > >>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > >>> "Malini Rao" <mrao(a)redhat.com>, "Martin
Polednik"
> > >>> <mpoledni(a)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(a)redhat.com>
> > >>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > >>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Eldan Hildesheim"
> > >>>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > >>>> "Malini Rao" <mrao(a)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(a)redhat.com>
> > >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > > <trendline-mockup.png>
> >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
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?
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).
thoughts?
----
Thanks,
Einav
----- Original Message -----
From: "Malini Rao" <mrao(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
"Michal Skrivanek" <mskrivan(a)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(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>, "Michal Skrivanek"
> <mskrivan(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)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/TufteSparkl...)
> > 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(a)redhat.com>
> > To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> > > To: "Einav Cohen" <ecohen(a)redhat.com>
> > > Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas
Jelinek"
> > > <tjelinek(a)redhat.com>,
> > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > > "info" <info(a)eldanet.com>, "engine-devel"
<engine-devel(a)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(a)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/TufteSparkl...)
> > 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(a)redhat.com>
> > > >> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > >> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"engine-devel"
> > > >> <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > > >> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>, "Martin Polednik"
> > > >> <mpoledni(a)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(a)redhat.com>
> > > >>> To: "Einav Cohen" <ecohen(a)redhat.com>
> > > >>> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Eldan Hildesheim"
> > > >>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > >>> "Malini Rao" <mrao(a)redhat.com>, "Martin
Polednik"
> > > >>> <mpoledni(a)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(a)redhat.com>
> > > >>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > >>>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > > >>>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > >>>> "Malini Rao" <mrao(a)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(a)redhat.com>
> > > >>>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "engine-devel"
> > > >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > > <trendline-mockup.png>
> > >
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
"Michal Skrivanek" <mskrivan(a)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?
thoughts?
----
Thanks,
Einav
----- Original Message -----
> From: "Malini Rao" <mrao(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
> "Michal Skrivanek" <mskrivan(a)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(a)redhat.com>
> > To: "Malini Rao" <mrao(a)redhat.com>, "Michal
Skrivanek"
> > <mskrivan(a)redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)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/TufteSparkl...)
> > > 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(a)redhat.com>
> > > To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > > <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> > > > To: "Einav Cohen" <ecohen(a)redhat.com>
> > > > Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas
Jelinek"
> > > > <tjelinek(a)redhat.com>,
> > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > > > "info" <info(a)eldanet.com>, "engine-devel"
<engine-devel(a)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(a)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/TufteSparkl...)
> > > 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(a)redhat.com>
> > > > >> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > > > >> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"engine-devel"
> > > > >> <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > > > >> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>, "Martin
> > > > >> Polednik"
> > > > >> <mpoledni(a)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(a)redhat.com>
> > > > >>> To: "Einav Cohen" <ecohen(a)redhat.com>
> > > > >>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > > > >>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > > >>> "Malini Rao" <mrao(a)redhat.com>,
"Martin Polednik"
> > > > >>> <mpoledni(a)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(a)redhat.com>
> > > > >>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > >>>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > > > >>>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > > >>>> "Malini Rao" <mrao(a)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(a)redhat.com>
> > > > >>>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "engine-devel"
> > > > >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> > > > >>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > > <trendline-mockup.png>
> > > >
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
----- Original Message -----
From: "Malini Rao" <mrao(a)redhat.com>
Sent: Friday, November 15, 2013 2:55:20 PM
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
> "Michal Skrivanek" <mskrivan(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
> > "Michal Skrivanek" <mskrivan(a)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(a)redhat.com>
> > > To: "Malini Rao" <mrao(a)redhat.com>, "Michal
Skrivanek"
> > > <mskrivan(a)redhat.com>
> > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > > <engine-devel(a)ovirt.org>, "info" <info(a)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/TufteSparkl...)
> > > > 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(a)redhat.com>
> > > > To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> > > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > > > <engine-devel(a)ovirt.org>, "info"
<info(a)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(a)redhat.com>
> > > > > To: "Einav Cohen" <ecohen(a)redhat.com>
> > > > > Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas
Jelinek"
> > > > > <tjelinek(a)redhat.com>,
> > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > > > > "info" <info(a)eldanet.com>,
"engine-devel" <engine-devel(a)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(a)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/TufteSparkl...)
> > > > 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(a)redhat.com>
> > > > > >> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"engine-devel"
> > > > > >> <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > > > > >> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>, "Martin
> > > > > >> Polednik"
> > > > > >> <mpoledni(a)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(a)redhat.com>
> > > > > >>> To: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > > >>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > > > > >>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > > > >>> "Malini Rao" <mrao(a)redhat.com>,
"Martin Polednik"
> > > > > >>> <mpoledni(a)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(a)redhat.com>
> > > > > >>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >>>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan
> > > > > >>>> Hildesheim"
> > > > > >>>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > > > >>>> "Malini Rao" <mrao(a)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(a)redhat.com>
> > > > > >>>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "engine-devel"
> > > > > >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> > > > > >>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > > <trendline-mockup.png>
> > > > >
> > > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
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(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>, "Michal
Skrivanek" <mskrivan(a)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(a)redhat.com>
Sent: Friday, November 15, 2013 2:55:20 PM
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
> "Michal Skrivanek" <mskrivan(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
> > "Michal Skrivanek" <mskrivan(a)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(a)redhat.com>
> > > To: "Malini Rao" <mrao(a)redhat.com>, "Michal
Skrivanek"
> > > <mskrivan(a)redhat.com>
> > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > > <engine-devel(a)ovirt.org>, "info" <info(a)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/TufteSparkl...)
> > > > 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(a)redhat.com>
> > > > To: "Michal Skrivanek" <mskrivan(a)redhat.com>
> > > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > > > <engine-devel(a)ovirt.org>, "info"
<info(a)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(a)redhat.com>
> > > > > To: "Einav Cohen" <ecohen(a)redhat.com>
> > > > > Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas
Jelinek"
> > > > > <tjelinek(a)redhat.com>,
> > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
> > > > > "info" <info(a)eldanet.com>,
"engine-devel" <engine-devel(a)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(a)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/TufteSparkl...)
> > > > 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(a)redhat.com>
> > > > > >> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >> Cc: "Einav Cohen" <ecohen(a)redhat.com>,
"engine-devel"
> > > > > >> <engine-devel(a)ovirt.org>, "Eldan
Hildesheim"
> > > > > >> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>, "Martin
> > > > > >> Polednik"
> > > > > >> <mpoledni(a)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(a)redhat.com>
> > > > > >>> To: "Einav Cohen"
<ecohen(a)redhat.com>
> > > > > >>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan Hildesheim"
> > > > > >>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > > > >>> "Malini Rao" <mrao(a)redhat.com>,
"Martin Polednik"
> > > > > >>> <mpoledni(a)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(a)redhat.com>
> > > > > >>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>
> > > > > >>>> Cc: "engine-devel"
<engine-devel(a)ovirt.org>, "Eldan
> > > > > >>>> Hildesheim"
> > > > > >>>> <ehildesh(a)redhat.com>, "info"
<info(a)eldanet.com>,
> > > > > >>>> "Malini Rao" <mrao(a)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(a)redhat.com>
> > > > > >>>>> To: "Tomas Jelinek"
<tjelinek(a)redhat.com>, "engine-devel"
> > > > > >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> > > > > >>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > > <trendline-mockup.png>
> > > > >
> > > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
------=_Part_35193332_276403214.1384780377662
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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=E2=80=99s screen for creatin=
g/modifying VMs, not for Monitoring.
The extra information, completely grabs the attention. Just imagine the scr=
een 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 eve=
n create a new view dedicated for monitoring.=20
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 p=
ercentage of the Host (VMware shows both)
Eldan
----- Original Message -----
From: "Malini Rao" <mrao(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel@=
ovirt.org>, "info" <info(a)eldanet.com>, "Michal Skrivanek"
<mskrivan(a)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 o=
ther colors based on the current value, I htink it is also inaccurate to dr=
aw the sparklines in green since it has a specific meaning. I think the lin=
es should all be dark gray or black and only the markers and the red number=
s should be the color elements.
-Malini
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel@=
ovirt.org>, "info" <info(a)eldanet.com>, "Michal Skrivanek"
<mskrivan(a)redhat.=
com>
Sent: Friday, November 15, 2013 3:26:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> > 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 th=
> > proposed view because there is more color there than in a
small dot.
>=20
> +1
>=20
> > As an experiment, I tried to render the entire sparkline in the color=
> > which
> > is not technically accurate. What do you guys think?
>=20
> 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 tha=
> 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 (i=
> this
> mock-up, I marked bold only the red text).
=20
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 on=
> > > > > It's
> > > > > a
> > > > > small feature and it's trivial to add such a setting.
> > > >=20
> > >=20
> > > @Michal: I am not sure what you mean by "disable"; if you mean
"hid=
> > > (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 use=
> > > will
> > > be
> > > able
> > > to define his view as he wishes.
> > >=20
> > > > I am averse to turning it off completely since it will be less th=
> > > > able
> > > > to
> > > > choose to only see the current value...
> > >=20
> > > @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?
> >=20
> > 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.
> >=20
> >=20
> > >=20
> > > > ... If we have colored dots, we should possibly change the shape =
> > > sufficient
> > > to rely on the dot "height" + the textual value?
> >=20
> > I am not sure it is enough - Height and text are available for all us=
> > 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 fr=
> > triangle and a square. Having more than that may be
tricky.( See
> > attached)
> >=20
> > Also, I am glad you are always presenting current and proposed togeth=
> > 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 th=
> > which
> > is not technically accurate. What do you guys think?
> >=20
> > >=20
> > > > > 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 someh=
> > > > > "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
> > > >=20
> > > > I am not sure I completely understand the request here. Is there =
> > > 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
nee=
> > > well-
> > > define the "range" of the band so it would makes sense (not sure
if
> > > easy
> > > to
> > > do).
> > >=20
> > > I am attaching an updated mock-up with axes (only added for the fir=
> > 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 i=
> > > > >=20
> > > > > >> ... 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 =
> > > > > >> more detailed view?
> > > > > >> ...
> > > > > >=20
> > > > > > 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), w=
> > > > > > 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=
> > > > > 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 u=
> > > > > enough,
> > > > > repetition of the same info on each line), Host(repetition of
> > > > > domain
> > > > > parts
> > > > > of FQDN) makes it overloaded already.
> > > >=20
> > > > Agreed and I think we should address that and some efforts in ter=
> > > > 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 =
> > > > 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 te=
> > > > 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 dat=
> > > > more
> > > > of
> > > > these attributes is a sparkline?
> > > >=20
> > > >=20
> > > > > ...maybe just a global setting to disable this if it gets annoy=
> > > > > It's
> > > > > a
> > > > > small feature and it's trivial to add such a setting.
> > > >=20
> > > > I am averse to turning it off completely since it will be less th=
> > > > able
> > > > to
> > > > choose to only see the current value...
> > > >=20
> > > > >=20
> > > > > >=20
> > > > > > 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=
> > > > looking
> > > > at the mockup, I am less worried about the 3 sparkline columns
> > > > displaying
> > > > next to each other especially because the current value breaks th=
> > > > > > data
> > > > > > and display its value next to the sparkline
> > > > > > """
> > > >=20
> > > > 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.=
> > > > 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 e=
> > > > indicator.
> > > >=20
> > > >=20
> > > > > 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 someh=
> > > > > "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
> > > >=20
> > > > I am not sure I completely understand the request here. Is there =
> > > > > >>>> that
> > > > > >>>> a
> > > > > >>>> chart per monitored fact (rather than a
combined chart) is
> > > > > >>>> better.
> > > > > >>>=20
> > > > > >>> OK
> > > > > >>=20
> > > > > >> Based on the original request in the bug, it seems like
Itam=
> > > > > >>>>>> it
> > > > > >>>>>> could
> > > > > >>>>>> pop
> > > > > >>>>>> up a bigger version of the chart? Or
not needed?
> > > > > >>>>=20
> > > > > >>>> this is a nice-to-have, I think, definitely not
needed.
> > > > > >>>=20
> > > > > >>> OK
> > > > > >>=20
> > > > > >> 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 t=
> > > > > >> user
> > > > > >> if
> > > > > >> they
> > > > > >> should pay attention to it.
> > > > > >>=20
> > > > > >>=20
> > > > > >>>=20
> > > > > >>>>=20
> > > > > >>>>>> - Would it be enough to have it in one
color? Or should =
> > > > > >>>>>> be
> > > > > >>>>>> something
> > > > > >>>>>> like "the bigger the utilization
the more red"?
> > > > > >>>>=20
> > > > > >>>> question is what will happen when there are a
lot of "jump=
> > > > > >>>> that
> > > > > >>>> it
> > > > > >>>> jumps to 100%? only the parts of line that are
in 100%?
> > > > > >>>> maybe a single color is enough.
> > > > > >>>=20
> > > > > >>> OK
> > > > > >>>=20
> > > > > >>=20
> > > > > >> One color with a dot to indicate the most recent or
most
> > > > > >> relevant
> > > > > >> data
> > > > > >> and
> > > > > >> display its value next to the sparkline
> > > > > >>=20
> > > > > >>=20
> > > > > >>>>=20
> > > > > >>>> I have another concern about this feature:
currently, the
> > > > > >>>> GUI's
> > > > > >>>> most
> > > > > >>>> frequent
> > > > > >>>> refresh rate available is 5 seconds, which
means that the =
> > > > > >>>> 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 l=
> > > > > >>> frequent
> > > > > >>> sampling and
> > > > > >>> send this average back to engine when polled - so
we would
> > > > > >>> display
> > > > > >>> an
> > > > > >>> average
> > > > > >>> after each poll (15s).
> > > > > >>>=20
> > > > > >>> I wonder if something like this is not already used
on othe=
> > > > > >>> places:
> > > > > >>> @Martin, do you know about something like this?
> > > > > >>=20
> > > > > >> Why does the change in the line need to seem palpable
every =
> > > > > >>>>>> tab)
> > > > > >>>>>> by
> > > > > >>>>>> some
> > > > > >>>>>> which shows not only
> > > > > >>>>>> the actual percentage which is not so
useful by some mon=
> > > > > >>>>>> graph.
> > > > > >>>>>>=20
> > > > > >>>>>> I have the following concerns:
> > > > > >>>>>> - I can think of a bar chart or a line
chart and not sur=
> > > > > >>>>>> what
> > > > > >>>>>> would
> > > > > >>>>>> be
> > > > > >>>>>> better.
> > > > > >>>>>> - Not sure if replacing the current
chart with a bar/lin=
> > > > > >>>>>> 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 =
> > > > > >>>>>> be
> > > > > >>>>>> something
> > > > > >>>>>> like "the bigger the utilization
the more red"?
> > > > > >>>>>>=20
> > > > > >>>>>> Please advise from the UX perspective.
As soon as the fi=
> > > > > >>>>> 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 fa=
------=_Part_7625024_1946301944.1384804633769
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
moving this discussion to the users mailing list, to get some more oVirt us=
ers'=20
feedback this matter.
context is [1];=20
see attached to see comparison of current state and suggestion;=20
see below for engine-devel correspondence so far.
----
Thanks,
Einav
[1] Bug 803251 - improve the resource usage graph for VM cpu/memory/network
[https://bugzilla.redhat.com/show_bug.cgi?id=3D803251]
----- Original Message -----
Sent: Monday, November 18, 2013 8:12:57 AM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
=20
Hi,
Those are very nice mockups :)
=20
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?
=20
What we have now is a screen with too much noise.
As I see it, most of the users comes to the VM=E2=80=99s 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)
=20
I do think we need a Monitor or even a Trend view, we can hook on the low=
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 h=
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)
=20
Eldan
=20
=20
=20
=20
=20
=20
----- Original Message -----
From: "Malini Rao" <mrao(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>, "Michal
Skrivanek"
<mskrivan(a)redhat.com>
Sent: Friday, November 15, 2013 11:32:15 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
=20
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.
=20
-Malini
=20
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>, "Michal
Skrivanek"
<mskrivan(a)redhat.com>
Sent: Friday, November 15, 2013 3:26:10 PM
Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
=20
> ----- Original Message -----
> From: "Malini Rao" <mrao(a)redhat.com>
> Sent: Friday, November 15, 2013 2:55:20 PM
>=20
>=20
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Malini Rao" <mrao(a)redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)eldanet.com>,
> > "Michal Skrivanek" <mskrivan(a)redhat.com>
> > Sent: Friday, November 15, 2013 2:32:21 PM
> > Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
> >=20
> > > Also, I am glad you are always presenting current and proposed toge=
> > > 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 va=
> > > which
> > > is not technically accurate. What do you guys think?
> >=20
> > Malini, I agree with the above: it is more effective in the scannabli=
> > 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 thin=
> > > > will
> > > > be
> > > > able
> > > > to define his view as he wishes.
> > > >=20
> > > > > I am averse to turning it off completely since it will be less =
> > > > > be
> > > > > able
> > > > > to
> > > > > choose to only see the current value...
> > > >=20
> > > > @Malini, do you mean that they need the option to
"fallback" to t=
> > > 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 t=
> > > fall
> > > back option instead of having a setting to turn these columns off
> > > altogether
> > > permanently.
> > >=20
> > >=20
> > > >=20
> > > > > ... If we have colored dots, we should possibly change the shap=
> > > > > on
> > > > > this
> > > > > as
> > > > > a status indicator.
> > > >=20
> > > > I like the idea of colored dots; not sure about the different sha=
> > > > be
> > > > sufficient
> > > > to rely on the dot "height" + the textual value?
> > >=20
> > > 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=
> > > a
> > > triangle and a square. Having more than that may be tricky.( See
> > > attached)
> > >=20
> > > Also, I am glad you are always presenting current and proposed toge=
> > > current value ( See attached) - It is more effective
in the
> > > scannability
> > > aspect but it is painting all values in the color of the current va=
> > > which
> > > is not technically accurate. What do you guys think?
> > >=20
> > > >=20
> > > > > > 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
som=
> > > > > > "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
o=
> > > > > 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/=
> > > > > in
> > > > > relation to the overall shape.
> > > >=20
> > > > 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 =
> > > > 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 n=
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.
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
> ----- Original Message -----
>> From: "Itamar Heim" <iheim(a)redhat.com>
>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel" <engine-devel(a)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(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
From: "Lior Vernia" <lvernia(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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.
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.
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(a)redhat.com>
>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
>>> <engine-devel(a)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(a)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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
> From: "Lior Vernia" <lvernia(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>, "info"
<info(a)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.
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(a)redhat.com>
>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
>>>> <engine-devel(a)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(a)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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
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?
----- Original Message -----
From: "Lior Vernia" <lvernia(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>, "info"
<info(a)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.
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(a)redhat.com>
>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
>>>> <engine-devel(a)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(a)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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
From: "Malini Rao" <mrao(a)redhat.com>
To: "Lior Vernia" <lvernia(a)redhat.com>
Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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.
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(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
>> To: "Einav Cohen" <ecohen(a)redhat.com>
>> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
>> <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
>>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
>>>>> <engine-devel(a)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(a)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(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
From: "Tomas Jelinek" <tjelinek(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> To: "Lior Vernia" <lvernia(a)redhat.com>
> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Eldan
Hildesheim"
> <ehildesh(a)redhat.com>, "engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)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? 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(a)redhat.com>
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> >> To: "Einav Cohen" <ecohen(a)redhat.com>
> >> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> >> <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel(a)ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel(a)ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
From: "Malini Rao" <mrao(a)redhat.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> > To: "Lior Vernia" <lvernia(a)redhat.com>
> > Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Eldan
Hildesheim"
> > <ehildesh(a)redhat.com>, "engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> > To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "info" <info(a)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(a)redhat.com>
> > >> To: "Einav Cohen" <ecohen(a)redhat.com>
> > >> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"engine-devel"
> > >> <engine-devel(a)ovirt.org>, "info"
<info(a)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(a)redhat.com>
> > >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>,
"engine-devel"
> > >>>>> <engine-devel(a)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(a)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(a)ovirt.org
> > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> _______________________________________________
> > >>>> Engine-devel mailing list
> > >>>> Engine-devel(a)ovirt.org
> > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel(a)ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel(a)ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>