Hi,
sorry if I misundestood something ... I did not follow the whole discussion.
If possible we should try to implement a solution supporting both
graphical representations:
1. the standard "easy to understand, fancy looking, but maybe
inaccurate" graphs and
2. the optional "unfamiliar, more complex, but (more) accurate" graphs
Thanks
Andreas :-)
On 10/28/2010 11:10 AM, Joseph Marques wrote:
On 10/28/2010 12:49 AM, Charles Crouch wrote:
> I*think* this was the point Greg was trying to make, the horizontal width of the bar
implies to the user, since time is the y-axis, that there is a period of time related to
the data collection which is important. When there really isn't, its just an artifact
of how we are doing data bucketing.
Actually, the horizontal width of the bar is important because
provides boundaries for each timeslice, which have specific start/end
times relative to the overall time range being viewed. This is a very
accurate type of chart insofar as the mix/max/avg markers are
calculated with respect to the timeslice boundaries.
Contrast with that a line chart which turns those timeslices into
single points (and then connects the dots between two points in
temporal order). The algorithm for querying data uses buckets that
have a non-zero width along the y-axis (time), but then the graph is
displaying that bucket as a single point (no width) connected to the
next single point (no width).
All that said, I'm willing to concede that single points are probably
more intuitive to a lay user than bars. I just wanted to be clear
that intuitiveness was the driving factor here. I didn't and don't
believe that candlestick is any worse at displaying point-in-time
bucketed data than it is at displaying continuous bucketed data - the
bucketing naturally normalizes the input from these sources. And it
was agreed in #rhq that the jitter affect from bucketing would be
present and need to be handled regardless of chart type. My primary
concern was to thoroughly understand the ideas being presented, so
that the wiki could be updated to better elaborate on the pain points
of our current solution and accurately reflect how other solutions
(such as line graphs) could mitigate those issues.
> If you use a point or line graph, then this initial confusion maybe mitigated. The
actual datapoints don't change, so people could still ask over what period do we
calculate the average, but its perhaps not the first thing they think of.
Yes, this is what I thought the conclusion was in #rhq yesterday. It
didn't seem like we were talking about getting rid of bucketing (and
so any chart type would still need to deal with potential jitters, or
somehow make the buckets consistent). I agree that a line chart is
easier on the eyes, but don't believe that we are fundamentally
changing what we are charting (bucketed data); we're just playing
connect-the-dots (instead of bars/ticks) which, again, I'm willing to
concede may be a more intuitive solution (even if it's not as accurate
because it reduces data buckets [which have real width] to single
points [which have no width]).
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel