12:29 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Eldan Hildesheim" <ehildesh(a)redhat.com>, "Users(a)ovirt.org"
<users(a)ovirt.org>
Cc: "Malini Rao" <mrao(a)redhat.com>, "info"
<info(a)eldanet.com>, "Michal Skrivanek" <mskrivan(a)redhat.com>,
"Thomas
Jelinek" <tjelinek(a)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(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>
> Cc: "info" <info(a)eldanet.com>, "engine-devel"
<engine-devel(a)ovirt.org>,
> "Michal Skrivanek" <mskrivan(a)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(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?
>
> 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
