Greg, Joseph
I just wanted to summarize the discussion from IRC today (
http://pastebin.com/SUt9Wi0N)
and the updated wiki (
http://rhq-project.org/display/RHQ/Design-NewChartingLib) and make
sure I have it correct. Please reply, setting the record straight where I misunderstood.
Cheers
Charles
To be clear from the outset, this discussion seems to have nothing at all to do with
charting libraries, but rather the style of chart we should be rendering. Also this
discussion does not to appear to be about how we bucket data, it appears settled that the
way we are doing it now is a necessary evil.
The idea seems to be that instead of the charts we show right now:
a) The summary metric (1-currentSummaryMetric.png)
Which I think we can all agree is not really a Candlestick
(
http://en.wikipedia.org/wiki/Candlestick_chart), more of a floating column chart (for
high/low) with a tick mark for the average value.
and
b) The "detailed metric" (2-currentDetailedMetric.png)
Which I think could be best described as a slimmed down OHLC chart
(
http://en.wikipedia.org/wiki/Open-high-low-close_chart), overlaid on top of a regular bar
chart showing the average value.
that they should be replaced by something like a standard area chart, as shown in the
attached 3-areaGraphicMetric.png
My 2c...
First off, is there any merit to changing what we've got today? I think so...
1) User expectaions: The difficulty of describing the two chart types in the explanation
above should be an indicator that these are fairly non-standard. Looking at the charts
available in Google Docs and OpenOffice I couldn't readily create a chart that matched
what we currently render, given a simple dataset consisting of min/max/avg datapoints. The
data we are trying to plot is not unusual, I think there is merit in using a chart type
users are familar with, or at least is fairly intuitive.
2) User understanding: When a new user see the metrics tab for the first time, the
reaction is typically something like the following:
NewUser: Ooh, those graphs are cool, what do the bars and squiggles mean?
Me: The bar shows the min/max over the period and the squiggle is the average
NewUser: Cool. What period?
Me: Yeah...Right...you know the *period*.......If you take the start time from the end
time and divide it by 60, then center it around the time indicated by the grey timeline,
then thats the period. See...simple, really....
NewUser: rrrrrrrrrrrrrrrrright
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. 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.
3) Consistency: Why do we use two different chart types for the "summary" and
"detailed" charts? Also the "detailed" chart is no more detailed than
the summary one, correct? Both have 60 datapoints, its just bigger?
So yes I think there is room for improvement.
What should that improvement look like?
Well on first inspection, the use of something like 3-areaGraphicMetric.png is appealing.
Its a normal area graph, which is readily understandable by most people: the min is below
the average which is below the high.
However this is not an apples to apples comparison, the pixel area available to the
summary graphs is vastly different to that shown at the bottom of
http://rhq-project.org/display/RHQ/Design-NewChartingLib. So what looks good at large
scale may not be so good at a much smaller scale.
I think to make an effective comparison of chart types (not saying chart libs) we're
going to need to pick several datasets, and two pixel areas (one for the samll graphs and
one for the large) and try rendering all the datasets acros both pixel areas using each
chart type.