Divide and Conquer is our best friend, we would decompose a chart into different pieces and evaluate the possibilities to reuse components.

A chart can be described as:

• dimension: width and length
• type: how the data is visualized
• title: states the purpose of the chart

and it can be decomposed as the following components:

• Axes: XAxis, YAxis and ZAxis if necessary
• Series: the raw data
• Legend
• Grid: used to improve readability in the background
• Background/Wall/Floor: the background of chart, Wall and Floor are specialized in 3D chart
• Marker: optional to mark the value in the data series

Here is a typical chart example:

Generally, we can categorize charts into different types : Lines, Area, Column, Bar, Pie, XY-Chart, Stack; and 3D variants if applicable. Type determines how the data is visualized.

Axis

Axis is another essential factor, which determines the resolution of the data. A “smart” axis needs to calibrate the length of unit and upper-bound, low-bound to maximize the resolution. On the other hand, users may override the default range. The attributes for Axis objects include: range: {floor, ceil}, lineStyle(color, dotted, slash …), labelStyle(font, position, …), arrowStyle.
Linear axis is commonly used in business world, while some scientists prefer logarithmic axis. A derived class LogarithmicAxis aims to support this feature.

Series

Series holds the raw data, which could be an array(in Column and Bar), single value(used in Pie), or array of (x, y) tuples(in XY-Chart). Series also needs a Label to identify itself and Style to differentiate itself with others.

Most user may not care about the Style, or even the Label, the chart would attach a default Style and Label if they are missing.

Grid

Grid is seldom used in most cases, but if the axis is logarithmic, the grid would improve readability dramatically.

Label

Label is the characterized by the font style and position.

Expected pseudo-code

Here is the code snippet of dojox.chart in action:

The above code snippet demonstrates a typical chart operation. Once the series are added, calibrate would calculate the dimension of plotting area, resolution, floor and ceiling of values, add missing label and styles of series if necessary; then render the chart. These operations are supposed to be portable, aka the type of chart is interchangeable.

It is a big challenge to design a flexible and easy-to-use library.Developers need to balance between the complexity of API and the simplicity of ease of use. A good approach is to give the users options, but hide them with a default implementation that would fit for daily use. Advanced users may explore the API and fine tune the parameters.

From the perspective of developers, chart objects share lots of common attributes, most likely they all have axes, legend; some may have wall, grid. It would make sense to reuse the components. Furthermore, we should reuse some algorithms, for example, how to normalize the range of data.

In this series, we are going to discuss the chart design/development. This prototype is not merged into dojo trunk, so is one of its dependencies, dojox.gfx3d. You need to fetch the snapshot of dojox.gfx3d in my previous posts for testing.

NOTE I really enjoy series writing recently, it does not intimidate my readers to go though some complicated technical details, and helps me to organize the topic using divide-n-conquer approach.

All businessman are crazy about the pie chart. Here is Pie3D powered by dojox.gfx3d. The interface for the end-user is pretty similar with dojox.chart.bar3d: just add the data via addSeries, set the light, then call render, boo, you are all set.

There is a long design struggle between dojox.gfx and dojox.gfx3d. The 3D pie chart is a Cylinder, but crippled intentionally, for example, only rotation around Y axis is supported. Last but not the least, it is much easier for user to specify the rx, ry and height, instead of scratching their heads to find the right rotation angle. dojox.gfx would suffice.

On the other hand, dojox.gfx3d brings schedulers and reusable gradient from Cylinder. The schedulers may be essential if we want to highlight some slices by moving them a little bit away from the center. Plan to throw one away; you will, anyhow. dojox.gfx3d is selected. Please checkout the code.

One picture is worthy two thousand words. The idea is inspired by the Microsoft Excel’s canonical bar3d graphics. Features include:

• Multiple-series are supported
• Lighting
• Rotation, of course you can, but you need to be aware how difficult to find the right angles.
• Animation, check calibration section
• User-interactivity, theoretically if we could figure out how to interpret the mouse movement

And there is still a long long way to go…

Z-Order

To be honest, the data series is optimized for the Z-Order rendering. The cubes are misplaced if the difference of two values are huge. This issue could be addressed by override the Z-Order of the bar.

Calibration

The best scenario for the chart users is to fill the data, let the plotter figure out the range of X, Y, Z, and the user may override the “smart ticks” if necessary. We supports the latter only. Personally I regard there is an industry standard for ticking. Just need more time to dig it.

Other missing features

Other missing features include, but not limited: grid, labels, ticks, titles and legend. Most of them are infrastructure of chart.

As always, the snapshot of code, it is in dojox.chart namespace and depends dojox.gfx3d.