chart types discussion

Joseph Marques jmarques at redhat.com
Thu Oct 28 09:10:56 UTC 2010


  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]).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20101028/eea0c5e5/attachment.html 


More information about the rhq-devel mailing list