----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Eldan Hildesheim" <ehildesh@redhat.com>, "Users@ovirt.org" <users@ovirt.org> Cc: "Malini Rao" <mrao@redhat.com>, "info" <info@eldanet.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Thomas Jelinek" <tjelinek@redhat.com> Sent: Monday, November 18, 2013 2:57:13 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
moving this discussion to the users mailing list, to get some more oVirt users' feedback this matter. context is [1]; see attached to see comparison of current state and suggestion; 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=803251]
----- Original Message -----
From: "Eldan Hildesheim" <ehildesh@redhat.com> To: "Malini Rao" <mrao@redhat.com> Cc: "info" <info@eldanet.com>, "engine-devel" <engine-devel@ovirt.org>, "Michal Skrivanek" <mskrivan@redhat.com> Sent: Monday, November 18, 2013 8:12:57 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
Hi, Those are very nice mockups :)
I still think it's TOO MUCH information. I spoke with many workers here regarding this issue.
What we have now is a screen with too much noise. As I see it, most of the users comes to the VM’s screen for creating/modifying VMs, not for Monitoring.
Do we know this for a fact? Can someone with a grasp on requirements/ users of the tool weigh in here and confirm this? In talking to users before, I have heard that they found Monitoring entities hard in Ovirt but I have not had a chance to gather more info around whether it is VM monitoring or monitoring hosts and storage to decide what resources to use as a basis for the VM creation that is hard. In talking to users, I have gathered VM creation and monitoring are both common tasks but I am not sure if one trumps the other. I guess the main question here is - Is there a need for a separate monitoring view or is it tightly integrated with the management of entities?
The extra information, completely grabs the attention. Just imagine the screen when all the data refreshes (fast and slow animations enclosed)
Agreed. The info does grab attention. However, the fast animation is not a scenario that is reasonable. Having said that, even if the rows updated every 15-30 secs all at once, it could be a disturbing experience. I have been raising this as a concern and wonder how important a real time trend is in this context. Can we not have the trend up to the time of the page load and reload every time the user navigates out and comes back and additionally have a refresh button for a manual refresh? As mentioned before, I am trying to understand if (1) all 3 columns need to be visualized the same way and (2) If the frequent updates are necessary. I don't think a trendline/ sparkline in itself is too much info.. it is the constant updating that makes it too much.
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.
I think this 'Monitor' tab exists in the user portal and presents exactly the same info presented in these columns when it can infact present far more as Eldan suggests here. But once again, examining the core need here, why is the user looking for such metrics? If they have to look across hosts to determine consumption and then decide where to create another VM, then a per host view of these metrics is harder to use. So, it will be useful to know the underlying goals and motivations of the user here.
In case this is not enough, we can do something with the monitor tab or even create a new view dedicated for monitoring.
Agreed. But this doesn't mean some high level metric can't be presented elsewhere and drilling for any detail leads to this view.
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)
Again, points to the need for more complete requirements.
Eldan
----- Original Message ----- From: "Malini Rao" <mrao@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Eldan Hildesheim" <ehildesh@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "info" <info@eldanet.com>, "Michal Skrivanek" <mskrivan@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 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@redhat.com> To: "Malini Rao" <mrao@redhat.com> Cc: "Eldan Hildesheim" <ehildesh@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "info" <info@eldanet.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> Sent: Friday, November 15, 2013 2:55:20 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Malini Rao" <mrao@redhat.com> Cc: "Eldan Hildesheim" <ehildesh@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "info" <info@eldanet.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Eldan Hildesheim" <ehildesh@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "info" <info@eldanet.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Malini Rao" <mrao@redhat.com>, "Michal Skrivanek" <mskrivan@redhat.com> Cc: "Eldan Hildesheim" <ehildesh@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "info" <info@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/TufteSparklne_medical.jpg?version=1&modificationDate=1362506139000) > 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