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

From: "Einav Cohen" <ecohen(a)redhat.com&gt; To: "Malini Rao" <mrao(a)redhat.com&gt; Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt;, "info" <info(a)eldanet.com&gt;, "Michal Skrivanek" <mskrivan(a)redhat.com&gt; 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).

thoughts? ---- Thanks, Einav ----- Original Message ----- > From: "Malini Rao" <mrao(a)redhat.com&gt; > To: "Einav Cohen" <ecohen(a)redhat.com&gt; > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, "engine-devel" > <engine-devel(a)ovirt.org&gt;, "info" <info(a)eldanet.com&gt;, > "Michal Skrivanek" <mskrivan(a)redhat.com&gt; > 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&gt; > > To: "Malini Rao" <mrao(a)redhat.com&gt;, "Michal Skrivanek" > > <mskrivan(a)redhat.com&gt; > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, "engine-devel" > > <engine-devel(a)ovirt.org&gt;, "info" <info(a)eldanet.com&gt; > > 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&gt; > > > To: "Michal Skrivanek" <mskrivan(a)redhat.com&gt; > > > Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, "engine-devel" > > > <engine-devel(a)ovirt.org&gt;, "info" <info(a)eldanet.com&gt; > > > 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&gt; > > > > To: "Einav Cohen" <ecohen(a)redhat.com&gt; > > > > Cc: "Malini Rao" <mrao(a)redhat.com&gt;, "Tomas Jelinek" > > > > <tjelinek(a)redhat.com&gt;, > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com&gt;, > > > > "info" <info(a)eldanet.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; > > > > 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&gt; 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&gt; > > > > >> To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; > > > > >> Cc: "Einav Cohen" <ecohen(a)redhat.com&gt;, "engine-devel" > > > > >> <engine-devel(a)ovirt.org&gt;, "Eldan Hildesheim" > > > > >> <ehildesh(a)redhat.com&gt;, "info" <info(a)eldanet.com&gt;, "Martin > > > > >> Polednik" > > > > >> <mpoledni(a)redhat.com&gt; > > > > >> 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&gt; > > > > >>> To: "Einav Cohen" <ecohen(a)redhat.com&gt; > > > > >>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eldan Hildesheim" > > > > >>> <ehildesh(a)redhat.com&gt;, "info" <info(a)eldanet.com&gt;, > > > > >>> "Malini Rao" <mrao(a)redhat.com&gt;, "Martin Polednik" > > > > >>> <mpoledni(a)redhat.com&gt; > > > > >>> 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&gt; > > > > >>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; > > > > >>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eldan Hildesheim" > > > > >>>> <ehildesh(a)redhat.com&gt;, "info" <info(a)eldanet.com&gt;, > > > > >>>> "Malini Rao" <mrao(a)redhat.com&gt; > > > > >>>> 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&gt; > > > > >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, "engine-devel" > > > > >>>>> <engine-devel(a)ovirt.org&gt; > > > > >>>>> 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 >