Case Studies with Code Snippets

We examine the libraries in more detail by investigating code snippets. We select the snippets that represent distinct API types for idiom creation, in terms of abstraction levels and programming styles.

Figure 9.4: DViz, code snippet for the grouped bar chart in Figure 9.3: high abstraction with complete encapsulation

Figure 9.4, 9.5, 9.6 and 9.7 show four snippets for drawing the grouped bar chart22 _{in Figure 9.3 (left). DViz (Figure 9.4) aims to maximally simplify the}

process of creating visualization idioms: only the data needs to be defined in a traditional tabular format (line 2-7). The library will then automatically recognize the structure of the data and implement all parts of the visualization, including visual encodings and user interactions, in this case: layout of bars, axes and legend, color coding, mouse-hover highlight with a balloon box, and legend filtering. This is the most convenient API type for developers to create visualization idioms programatically. However, the advantage is also

22_{Libraries have different color palettes and layout algorithms, the final looks of the same}

SPECIALIZED LIBRARIES FOR IDIOMS 153

the drawback in the sense that it lacks customizability. ChartKick (Figure 9.5) adopts a similar approach as DViz, but allows more customization by exposing configuration options. Data needs to be first transformed into JSON object, ChartKick then creates the visualization with the “BarChart” template, default parameters can be modified in JSON, as in line 10-13.

Libraries like Vega (Figure 9.7) and AmCharts (Figure 9.6) do not offer (comprehensive) idiom templates. Instead, the developer needs to explicitly define the idiom components. Vega23 _{provides the interfaces for abstract}

components that could be applied to all visualizations: “data” (line 5-10), scales (line 11-23), axes (line 24-28), legends (line 29-31) and marks (32-64). All the specifications of a visualization are defined in JSON. This promotes visualization standardization and reusability. However, it is more verbose and difficult to read than the other libraries for idiom visualization. And it tends to be more so as the complexity of an idiom grows, because it adopts nested JSON to express visualization specifications. For instance, in Figure 9.7, the bar groups are defined as nested marks in line 32-64. AmCharts offers a “meta-template” (line 12), within which, components such as data provider (line 13-14), marks (i.e. bars in this case, line 16-29) and legend (line 30-32) need to be explicitly

defined in JS.

Figure 9.5: ChartKick, code snippet for the grouped bar chart in Figure 9.3: high abstraction with idiom template and configuration options in JSON Furthermore, we find that, the data structure taken as input is dependent on specific libraries. For example, to build the grouped bar chart in Figure 9.3

23_{Vega was conceived based on d3, as a declarative language that hides the imperative details}

of d3, while focusing on reusable visualization design. This approach sacrifices expressiveness to some extent, and so far has been able to create static visualizations. However, vega is being actively developed, and extensions for declarative interaction design have been proposed[144]. Vega has a self-implemented scene graph, partially to accommodate canvas- rendering situations.

Figure 9.6: AmCharts, code snippet for the grouped bar chart in Figure 9.3: high-mid abstraction with idiom components in JS objects

(left), DViz takes CSV (Figure 9.4, line 3-6), ChartKick takes nested JSON array (Figure 9.5, line 4-9), AmCharts (Figure 9.6, line 5-10) takes yet another form of JSON array. This type of diversity creates barriers between data and visualization, and makes a library harder to learn. It is advisable for a library to be “standard-sensitive”, taking conventional data formats, such as TSV, CSV, and transforming the data under the hood.

Figure 9.8 and 9.9 show two snippets for drawing the choropleth map in Figure 9.3 (right). In Google Charts (Figure 9.8), the choropleth or symbol map idiom is given the package name “geochart” (line 3). The developer just needs to define the data (line 5-9) to achieve the visualization, with automatic map rendering/positioning/scaling, color coding, legend drawing, and mouse-hover interactions. Appearance customization can be modified within “options” (line 10). However, the developer needs to explicitly define zoom and pan interactions. The data used in Figure 9.8, line 5-9 is the province-wise population density in Belgium.24

To give developers more freedom for plotting geographic regions that are not readily available, many libraries like Leaflet offer custom vector layers, on which developers can use their own shape files, e.g. SVG, geoJSON, topoJSON, etc. As shown in Figure 9.9, line 8-12, geoJSON objects, in this case, Belgian province shapes, are automatically recognized and event handlers can be attached to each

24_{Province names are ISO-3166 encoded. Also note that we use this data only for illustration}

purpose. However, Google Charts currently do not support Belgium map at the province resolution.

SPECIALIZED LIBRARIES FOR IDIOMS 155

Figure 9.7: Vega, code snippet for the grouped bar chart in Figure 9.3: mid-low abstraction with idiom components in JSON

of these objects. However, Leaflet, like many of its peers, falls back to lower-level programming choices: manually mapping data items to colors, trivially handling events (line 13-16), and drawing legends, balloons (line 17-22). In comparison, Google Charts provides a “cleaner” event handling interface (Figure 9.9, line 16-18).

We also learn that, for map visualizations, having a server-side map provider is beneficial. Because on the one hand, custom shape files are difficult to craft and/or collect, map tiles take large amount of space to store, and when using such files, developers need to make an extra effort in preprocessing them, as the keys/ids in these files tend be diverse in format; on the other hand, a server-side map provider can store and aggregate map resources to provide intelligent/intuitive APIs. For example, a developer can use a list of free-form province names, the map provider then identifies the correct geographic shapes and returns them. Furthermore, features such as location names, administrative divisions can be standardized and updated.

Figure 9.8: Google Charts, code snippet for the choropleth map in Figure 9.3: high-mid abstraction with configuration options in JS objects