We could always support both graph styles and allow the user to choose whichever one they prefer.

On 10/28/2010 05: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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer@redhat.com