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

Malini Rao mrao at redhat.com
Fri Nov 15 19:55:20 UTC 2013 

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "info" <info at eldanet.com>,
> "Michal Skrivanek" <mskrivan at 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 at redhat.com>
> > To: "Einav Cohen" <ecohen at redhat.com>
> > Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "info" <info at eldanet.com>,
> > "Michal Skrivanek" <mskrivan at 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 at redhat.com>
> > > To: "Malini Rao" <mrao at redhat.com>, "Michal Skrivanek"
> > > <mskrivan at redhat.com>
> > > Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "info" <info at 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.
> > 
> > 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 at redhat.com>
> > > > To: "Michal Skrivanek" <mskrivan at redhat.com>
> > > > Cc: "Eldan Hildesheim" <ehildesh at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, "info" <info at 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 at redhat.com>
> > > > > To: "Einav Cohen" <ecohen at redhat.com>
> > > > > Cc: "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek"
> > > > > <tjelinek at redhat.com>,
> > > > > "Eldan Hildesheim" <ehildesh at redhat.com>,
> > > > > "info" <info at eldanet.com>, "engine-devel" <engine-devel at 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 at 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/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.
> > > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > * 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 at redhat.com>
> > > > > >> To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > >> Cc: "Einav Cohen" <ecohen at redhat.com>, "engine-devel"
> > > > > >> <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > > > > >> <ehildesh at redhat.com>, "info" <info at eldanet.com>, "Martin
> > > > > >> Polednik"
> > > > > >> <mpoledni at 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 at redhat.com>
> > > > > >>> To: "Einav Cohen" <ecohen at redhat.com>
> > > > > >>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > > > > >>> <ehildesh at redhat.com>, "info" <info at eldanet.com>,
> > > > > >>> "Malini Rao" <mrao at redhat.com>, "Martin Polednik"
> > > > > >>> <mpoledni at 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 at redhat.com>
> > > > > >>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > > > > >>>> <ehildesh at redhat.com>, "info" <info at eldanet.com>,
> > > > > >>>> "Malini Rao" <mrao at 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 at redhat.com>
> > > > > >>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>, "engine-devel"
> > > > > >>>>> <engine-devel at 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 at 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 at ovirt.org
> > > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >>>>> 
> > > > > >>>>> 
> > > > > >>>>> 
> > > > > >>>> 
> > > > > >>> 
> > > > > > <trendline-mockup.png>
> > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > 
> > > >
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

More information about the Engine-devel mailing list