Hi Malini, > Why does the change in the line need to seem palpable every few seconds? I > think the base requirement of how accurate the data is when a user looks at > a grid has not changed.. just the data visualization. Right? So , if the > refresh rate is not a problem today, why is it a problem now? Am I missing > something?
Currently, we display only the "current" value (visualized by a bar), and if we will go with a line chart, which is displaying also some of the previous values and is sort-of "progressing" on each refresh, I think that it might look weird if it will progress slowly. typically, when looking at this sort of progressing line chart (like a performance/CPU monitor in your computer task manager or similar), you expect the frequency to be ~1 second or so. With a slower frequency, it may seem like the graph is occasionally "stuck". I agree that the current state is not ideal either, but it is definitely more "acceptable" than how I think it would be with a line chart. Moreover, there's the non-sync'd frequencies that I mentioned earlier. I.e. if the GUI is refreshing every 5 seconds, but the statistics in the backend are refreshing every 15 seconds (and it doesn't really matter IMO if the new statistic are an average of some sort or single-point readings) - you are expected to have "flat" periods in the graph. so it may look something like: *-----*-----* / .... \ *-----*-----* \ / *-----*-----* so only every 3rd GUI-refresh-cycle, the graph can potentially "change" the value, since every "1st" and "2nd" GUI-refresh-cycle, the value in the backend still hasn't changed (again, since the refresh rate on the backend side is lower than the one in the GUI). ---- Thanks, Einav ----- Original Message ----- > From: "Malini Rao" <m...@redhat.com> > To: "Tomas Jelinek" <tjeli...@redhat.com> > Cc: "Eldan Hildesheim" <ehild...@redhat.com>, "engine-devel" > <engine-devel@ovirt.org>, "info" <i...@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" <tjeli...@redhat.com> > > To: "Einav Cohen" <eco...@redhat.com> > > Cc: "engine-devel" <engine-devel@ovirt.org>, "Eldan Hildesheim" > > <ehild...@redhat.com>, "info" <i...@eldanet.com>, > > "Malini Rao" <m...@redhat.com>, "Martin Polednik" <mpole...@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" <eco...@redhat.com> > > > To: "Tomas Jelinek" <tjeli...@redhat.com> > > > Cc: "engine-devel" <engine-devel@ovirt.org>, "Eldan Hildesheim" > > > <ehild...@redhat.com>, "info" <i...@eldanet.com>, > > > "Malini Rao" <m...@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" <ih...@redhat.com> > > > > To: "Tomas Jelinek" <tjeli...@redhat.com>, "engine-devel" > > > > <engine-devel@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@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@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel