Duarte Leão, our CCC master chief, sent last friday an email to the crew at webdetails to share some very interesting information about some recent goodies in CCC charts.

Unfortunately, he wrote it in Portuguese... (one out of the many things that actually drive me crazy). In between punches, where he promised he wouldn't do it again, he volunteered to translate it. But since it's not like you people pay me for blogging (well, some of you do, indirectly, but meh), google translate is good enough :)

Enjoy, and thanks Duarte!


Hello colleagues!


TL DR

talks about new features in CCC that can help us to get home on time more often
read only the headers
jump directly to the sections ☛
or click a link in another sample
save for later if you need

Overlay plots of arbitrary but consistent [CDF-287]

There is much that the CCC has the concept of a second plot.
Best known for Plot2, this is a graph of points (lines, area, points) that can be superimposed on the main plot.
The graphics that support the second plot is a bar chart, the lines, the scatter (line metric) and box plot.

Data from the second plot is a partition of the data table - the rows that have the series given by plot2Series or plot2SeriesIndexes. The remaining series are presented in the main plot.
Whatever the partition in any of the plots, the data column had to be the same. What was configurable by valueRole property, which would contain the name of the data column ("dimension" in dialect CCC).

Later came the functionality of regression calculation data, and with it the trend plot.
The regression is enabled individually for each plot of the data (not the actual trend plot) using trendType (or plot2TrendType) option.
The data lines generated by the regression algorithm are added to the original table, but a different partition.
It is this partition that feeds the third plot, the trend plot.

For each set of data from a plot that has the regression enabled partition is generated a corresponding series regression, the special partition "trend".
The only series trend plot shows the regression of all the other plots.

The way that CCC uses to represent partitions in the data table is through a special column that by default is called dataPart.
Till date the plots consume data from the following partitions:

partition "0" main plot ➜
partition "1" ➜ second plot
partition "trend" ➜ trend plot

This cooked between plots and data partitions was fixed.
What plot2Series and plot2SeriesIndexes options cause is fill in the fixed values ​​"0" or "1" on dataPart column, depending on the value of the number of each line.

However, it was possible to assign the value "0" or "1" using any other logic, not based on the series of such options (using readers, calculations or visual role dataPart binding to a column pre-charged with special) values​​.

It can here be drawn that the second and third plot are supported on graphs with Cartesian axes (X, Y). There Plot2 for the pie chart, for example.
But the appetite for more and more overlapping plots combinations has "no limits":

Menu lines, points and areas, as a shared
partition 1 ➜ plot lines
➜ partition 2 plot lines / points (with other colors / styles)
partition 3 ➜ plot areas

Menu bars and lines with a measure with another measure (measured in the same row of data, without resorting to tricks like using the series to distinguish)
partition and measure 1 1 ➜ bar plot
partition 1 and measure 2 ➜ plot lines

Menu bars and error lines, with three measures (ditto)
partition and measure 1 1 ➜ bar plot
partition 1 and measures 2:03 ➜ plot boxes, only indicating the minimum and maximum

Menu concentric pies, category and shared measurement (a kind of pie for two series and shared categories)
partition 1 ➜ plot pies
➜ partition 2 plot pies

Menu bars and bars, overlaid with two measures (ditto, a bar may be the present and the other the target value value)
partition and measure 1 1 ➜ bar plot
partition 1 and measure 2 ➜ plot bar (with semi-transparent color)

And most relevant overlaps arise, there were more types of plot; I'm imagining the gantt, to plot grid lines, plots for notes, whatever.

☛ To support these scenarios is therefore a question of power set, in a chart options:

a list of arbitrary types of plots, but compatible, the overlapping
plot uses a particular data partition
the value of a plot must represent a data column, "vendasActuais," for example, and the value of another plot to represent another column of data "vendasObjectivo" for example;
shall begin to sound the words "visual roles for plot"

This is what is already possible today do. A funny example. A Christmas tree. The concentric pies.


Number formatting, internationalization (or i17o) [ANALYZER-2391]

Formatting dates and reading the CCC has been provided by Protovis, relatively easily, via masks formatting, like this "% Y-% m-% d" (pv.Format.date). However, you have to settle for formatted dates containing the names of the days of the week or the months in English. This remains the case, despite what is described here. Something that is on the list.

People often turn to libraries of third formatting, such as moment.js, an authentic Swiss Army knife for dates, whenever something more "serious" is necessary. Mike Bostock had other delegate the implementation of a feature crucial for building views and d3.js would not have their own API for formatting dates, numbers, etc.. The reasons only he knows the for sure. I think there are great advantages in distributing, in one file, and with a uniform API, all that is necessary, essential, to build views (...).

With regard to format and read numbers, Protovis has a similar class, pv.Format.number, not, however, support any syntax formatting mask. As with dates, often we resort to third party libraries to format numbers differently than the default, or through ValueFormat percentValueFormat functions.

With the new graphic Sunburst, added to the Analyzer, which has total values ​​at various levels of a hierarchy, the need to be able to format numbers in the same way that the Analyzer does, on the server, via Mondrian emerged. This format uses masks like those we see in Excel, something like "#, 0. # #".
Adding to this need the aforementioned lack of a way to format numbers via masks formatting, the path chosen was to implement an API in JavaScript to format numbers according to these masks.

Rather than initially thought, not these masks to Mondrian data sources in CDA, something that would ensure familiarity with the syntax of the masks who usually develops dashboards with CTools are used. Nothing you can not do, pass the CDA can return data to the original values ​​accompanied the formatted value (require at least generalize the JSON output format).

Something that is important in this field, to be able to satisfy either the Greeks or the Trojans, is able to configure the formatting of values ​​at various levels: dashboard / global, per chart for the data column.
☛ This is possible today:

Globally (using fluent interface)

cdo.format.defaults
. number ("#, 0.00")
. percent ("#, 0:00%")
. date ("% Y /% m /% d")


(cdo = Community Data Objects, a spin-off of the old namespace classes, pvc.data)

graphic level

pvc.BarChart new ({
....
format: {
number "#, 0.00",
percent: ....
}
});


dimension level

pvc.BarChart new ({
dimensions: {
sales: {
format: "#, 0.00"
}
}
});


Having me focused in shades, is possible, however, in any of the levels, and using JSON API or configure the formatting style to meet the needs of i17o:

pvc.BarChart new ({
....
format: {
number: {
mask: "#, 0.00",
style: {
decimal ","
group, "."
NegativeSign: "-",
currency: "€"
/ / (...)
}
}
}
});


Shades format support:

multiple sections: positive values​​, negative, zero, and zero
percentages
rounding without errors, as introduced by Number # toFixed method
mixture of any content on the medium, before or after the numbers
divide by a thousand, million, ...
monetary values
scientific format

In addition to the options of the CCC documentation (a good start is here), there is a third-party page here. The most comprehensive documentation is even reflected in the unit test file.

Turning to the functionality of the overlay plots, it is now possible to format it differently multiple dimensions of measurement.
See the difference in the presentation of the measures in the tooltip between (i) the only possible approach before: paired bar line measures and (ii) can now: really paired bar line measures.
Note also the different experience you have with the legend.

One last note. The ValueFormat option passed to apply to any column of numeric data, whatever its name. So far only applied to columns named value, value2, value3, etc..


Tooltip more informative, more stylable [FDC-282] [FDC-287] [FDC-306]


☛ The new tooltipClassName option allows you to specify an additional CSS class for the tooltip of a graph; example really paired measure line bar.

The default contents of the new tooltip (called summary data):

is a table (goodbye spaghetti lines of names and values​​)
gives more information:
which visual role that a column of data is playing? Special characters like ↕, and ∠ ⊞ indicate the visual scroll beside the name of each column of data to (there are still many basic visual character roles waiting)
what type of interpolation null for each measure separately
shows values ​​resulting aggregation (number # and sum Σ ⋃ or list)
can adapt your style to the plot, axis, legend to which the information pertains
makes it possible to hide / change some of its parts, without the need to write any root

Tipsy.css The file contains information about the structure of the various HTML and CSS classes.

In the example, also note the tooltip that appears when you hover the mouse over the labels of the axis of X.


Pointing [CDF-306]

☛ The new options allow you to configure pointing and pointingMode and choose from the traditional mode, pointing over, and a new mode, the near (the new default value.)
The near mode will activate visual elements that are close to the pointer, whether they are on top of or below other.

The pointing affects both the visual detection of the active element, such as the option hoverable understands both the presentation of the tooltip.
Additionally, clicking somewhere, when a visual element is active, it is always as if you click the active element, whether or not this is the first element under the pointer.

The near mode makes it possible to interact with visual elements that, over the way, are inaccessible to the user, due to the overlapping of various plots, the existence of overlapping series with semi-transparent, etc. funds.
Additionally, over the way makes it very difficult (and is a good exercise control aggression) interaction with visual elements without inner area (or almost no), as are the lines.

The over mode can be used either by choice either to maintain full compatibility with previous uses, mainly for cases where already a point behavior was the Protovis to be used.


Value Labels [ANALYZER-1545]

☛ The purpose of this story, it created a new valuesOverflow option, with possible values ​​hide, trim and show. The existing valuesOptimizeLegibility option was implemented in more types of plots.

Example that uses both options: stacked horizontal bar.

Blurring the Extension Points

The extension points are points of more or less direct input to Protovis world - the world that supports the CCC.
The existence of these points make CCC a library of extremely flexible graphics.

Essentially, some objects used by the CCC Protovis are exposed for further configuration by means of a handle.
Joining this identifier the name of a property of Protovis object (or the name of one of its special methods), you can configure the object, and even add new objects, next to that. The identifier of the object and the property are separated by "_".

For example:

"plot2Label_textStyle" ⬌ "textstyle" property of the object Protovis "plot2Label" (⬌ object "label" the plot "Plot2")


In the definition of a CCC chart, the extension points are placed in a dictionary that is placed in the "extensionPoints" option:

pvc.BarChart new ({
Plot2: true,
/ / ...
extensionPoints: {
plot2Label_textStyle: "blue"
}
});


From the moment in which it is possible to add an arbitrary graphic plots, it is necessary to be able to receive its extension points ... For this reason, there have not guarantee collision with the prefixes many existing options.
Although it was possible to devise a scheme that would allow prefixes, we opted for the solution, which in some perspective, it is simpler: the options and extension points of the new plots can not be placed next to the other, via a single prefix. Once the existence of multiple plots in itself is an advanced feature, and that, even if not so defined, the CDE would have no way of getting these options (do not know the plots that the user will define beforehand ...) we chose to only allow specification of their options for code and with the definition of the plot (not within the top options, the chart):


pvc.BarChart new ({
plots: [
{
type: "point",
valuesVisible: true,
/ / ...
extensionPoints: {
label_textStyle: "blue"
}
}
]
});


Thus, no prefixes to invent and also moves towards a hierarchical definition CCC without prefixes in the names of the properties (something that a future editor also bear willingly).

But it does not end here.

One of the reasons why "not appreciate" the (s) Property (s) extensionPoints is oblige to form two sets of properties of a graph: the options and extension points. Within each of the properties are organized again by sub-components of the graph: properties of the X axis legend properties. This represents an obstacle to the modularity of the definitions. When I copy the properties for the X axis, I copy both options as extension points. I have to go to two sites, copy, and then put in two places ...

The other reason is the division require special treatment when writing code in pre and post execution fetch components. The dictionary extension points must be converted to CDF format (an array of arrays with key and value) for the CCC format (a dictionary), changed the extension points that format, then converted to CDF format.
Later the CDF component itself must convert the set again for the CCC format when building the CCC chart.
To make matters worse, there is often the dashboards of extension points that are in the extension points and CDF code that is in CCC format code form, making it more difficult to copy & paste a few sites for others ...

Then there to explain this over and over in the forums.

Are obstacles that do not add enough value and nmho only increase the learning curve.

☛ The current version of CCC allows extension points are placed next to the options:

pvc.BarChart new ({
plots: [
{
type: "point",
valuesVisible: true,
label_textStyle: "blue"
/ / ...
}
]
});


A important distinction between option and extension point is by the existence of the "_" character in the property name, which is never used in the CCC options.

Examples of the CCC site were all reviewed in order to group the properties by sub-component of the graph, facilitating the understanding and definitions of modularity.
Reasonably representative example: statistics with number 5 bar.

I think I will not have missed the Dashboards.propertiesArrayToObject and Dashboards.objectToPropertiesArray functions.

☛ Another new feature in the area of extension points is the special method call.
Asking to borrow the language d3, the call method to run Protovis allows arbitrary code on any subject Protovis:

pvc.BarChart new ({
plot_call: function () {
this.anchor ('center')
. add (pv.Label)
. text ("Hello");
}
});


Unlike what happens in all other properties / methods (except add), this is the Protovis the object itself.
This language is preferable to use the add method or writing code by option renderCallback chart.


other

Legend stopped allowing hide the last visible number.
The log of abstracts "data source", "date", "complex type" and "visual roles" is much more readable.
New helper function pvc.finished to facilitate making the value of an end point of extension.
The summary of properties and extension points in the CCC site did not include properties of complex value, as readers, dimensions, calculations, plots ...
New methods of the graph, to replace rendering calls (boolean, boolean, boolean??)
renderInteractive () to re-renders only refreshes your style, chasing points extensção
renderResize (width, height) to re-renders resize
Separation of the core code and plugins, one for each type of graph; just to have something internal.
Moved from the pvc.data namespace code for a new CTool, cdo (acronym for Community Data Objects).
[CDF-276] New dataWhere option, allows you to filter data rows using objects cdo.Datum, now independent of the concrete form of transport CDA.


And hopefully, correcting more errors than the input.

best regards,

More...