--On Wednesday, January 25, 2006 2:24 AM -1000 "(Cedric) Qin ZHANG"
<[EMAIL PROTECTED]> wrote:
I am designing a telemetry chart to show how the number of open and
closed jira issues change for a particular release. Obviously, in this
case, a stacked bar chart is more visually intuitive than the line chart
we currently have.
Hi Cedric,
Interesting conjecture. While I don't want to suggest that line charts are
the optimal representation for every situation, it is not "obvious" to me
(yet) why line charts aren't perfectly appropriate here.
First, what is the analysis goal of this telemetry stream? If I assume that
the goal is to manage the number of issues for a current release and ensure
that we are making steady progress toward closing all of them, then I would
claim that a line chart is actually much better than a stacked bar chart.
The reason I say that is because with a line chart, one could easily and
visually detect whether there is a more-or-less linear "negative slope"
with respect to (for example) the % of open issues, and if so, one could
then make an empirically-based prediction of when the line will hit zero
issues, indicating the date of the next release. That kind of
interpretation would be significantly less obvious with stacked bar charts.
The other issue in my mind is that if you are charting "open vs. non-open
issues", then you don't need two lines--one will convey all the
information.
Did you have a different goal for this telemetry stream that makes stacked
bar charts more appropriate?
I have a proposal to enhance telemetry language.
Current telemetry language:
streams mystream() = {"description not visually displayed", "unit",
Reducer()}; chart mychart(param) = {"chart name", mystream()};
draw mychart("param");
Proposed enhancement:
draw mychart("param") [as LineChart|BarChart|....|...]
The "[as LineChart|BarChart|....|...]" part is optional. Default is line
chart, so that it's backward compatible with existing language.
In the case of the draw command, maintaining backward compatibility doesn't
seem like a big deal to me, since that is used only in interactive mode and
so there wouldn't be any ripple effect on existing user-level code.
An alternative syntax is:
draw(mychart("param"), "LineChart");
This alternative contrasts in the following way:
- Does not introduce a new special purpose token "as" into the language
for one single command ("draw")
- Is not backward compatible; users will have to write the draw command
differently.
- Users will have to specify the type of chart explicitly. This makes for
more typing, but also makes the
language features more "visible" in each invocation.
- In future, if we want to extend draw command further, it's just a
matter of adding another argument. Your original proposal would require
yet another special purpose token ("with"? "in which"? "with respect to"?).
At any rate, I would put the language extension on the back burner until we
develop an analysis that we're convinced needs a non-line chart
visualization.
Cheers,
Philip
