First, we need to define the visualization design space in which a single recommendation system (or algorithm) can be effective. On the one hand, it is impractical to derive a single visualization recommendation system to cover all possible visualizations. On the other hand, it is equally impractical to expect visualization users to learn a completely different system for every conceivable visualization use case. We establish the boundaries of the visualization design space, which effectively covers the search space for most visualization recommendation algorithms (e.g., Voyager [
107,
108], Foresight [
24], DeepEye [
60], Draco [
65] etc.). Then, we explain how we specify individual visualization designs within this space, informed by the literature on visualization specification and visualization languages [
82,
104].
3.1.1 Establishing Design Space Boundaries.
Our boundaries are informed by existing literature on (1) visualization design spaces [
62,
65,
106], which formally define the range of visualization designs that could be recommended; and (2) graphical perception studies [
35,
51,
82,
84,
96], which can be used to identify a subset of designs that can be fairly compared in terms of user performance. We summarize our findings as the following constraints on the visualization design space.
B1. Exclude 3D visualizations. As found in previous work, users often have difficulty in perceiving information from 3D visualizations [
96]. Most recommendation algorithms do not include them [
111]. Moreover, in many cases, multiple linked 2D views prove to be more effective than a single 3D visualization of the same data [
84]. Thus, we exclude 3D visualizations from our design space.
B2. Exclude network graph visualizations. As discussed in previous work [
51], graph analysis tasks are generally considered separate from tabular data in visualization research and should likely be studied separately. Moreover, existing visualization recommendation systems mainly focus on generating visualizations for tabular data and generally do not include network graph visualizations (e.g., [
24,
45,
65,
107,
108].) Thus, we exclude graph visualizations, like trees, treemaps, networks, radar charts, chord diagrams, etc.
B3. Focus on static visualization designs. Although animations and transitions can improve a user’s perception of an underlying dataset [
35], many if not most visualizations are still designed without any animations or transitions. Given a lack of data in the literature evaluating the animation and transition design spaces, we do not include these design elements within our visualization design space. Similarly, the design space of interactions is still an under-explored area in visualization, and enumeration of this space has only recently become viable [
82]. In this case, the lack of data and theoretical principles is already evident and does not require an in-depth literature review. As a result, we exclude animations and interactions from our analysis. We plan to revisit this gap in our future work as more data becomes available.
3.1.2 Specifying Visualization Designs.
After establishing the design space boundaries, we then discuss how to specify individual visualization designs to be compared. The visualization effectiveness could be impacted by many factors, such as the encoding channels, mark types, and scales used in the visualization, but also the data characteristics of the input dataset, like the cardinality and entropy of each attribute. Inspired by one of the most popular visualization grammars, Vega-Lite [
82], we use data types, data transformations, encoding channels, mark types, and scales to specify each observed visualization design. However, Vega-Lite does not support data characteristics specification. To address this limitation, we extend Vega-Lite by integrating a new “data characteristics” component to support describing the target dataset; the specification structure is based on how dataset characteristics are specified in Draco [
65]. Examples of how to use our specification language are provided in 1 and our supplemental materials.
Data Types: quantitative, nominal, or ordinal.
Data Characteristics: cardinality and entropy.
Data Transformations: aggregation or bin.
Encoding Channels: position (X/latitude, Y/longitude), length, angle, area, texture, shape, color saturation, color hue, orientation, column, row.
Mark Types: point, line, area-circle, area-rect, area-arc, area-other, text, geoshape, box-plot.
Scales: linear, log, nominal, or ordinal.
We utilize data types, characteristics, and transformations to describe the data while encoding channels, mark types, and scales to specify the visualization design itself. There exist more measurements for data characteristics like scagnostics [
105]. However, scagnostics are mainly used for one chart type–scatterplot, which is already covered by a recent survey [
81]. In this paper, we focus on comparing different visualization designs instead of emphasizing one or two specific chart types; thus, we select the three most commonly used measurements for data characteristics–cardinality, entropy, and correlation.
When selecting encoding channels for our analysis, we start with the encoding channels discussed in the ranking of perceptual tasks proposed by Cleveland & McGill [
17] and later extended by Mackinlay [
61]. We remove the
connection and
containment channels because they are mainly used for graph visualizations which we exclude from the analysis (section
3.1.1). We also find that
orientation has been discussed frequently in the literature (e.g., [
16,
99]) and is similar to the
direction channel proposed by Cleveland & McGill [
17] and the
slope channel mentioned by Mackinlay [
61]; thus we combine them into
orientation channel. We split the
position channel into
positionX and
positionY since there are 2 directions of position in the 2D Cartesian plane, which could impact a user’s perception of these values. We also add
column and
row encodings for faceting charts, bringing the number of encoding channels to 12 (see Figure
1). To save space, we use an abbreviation to represent each channel. PX is positionX, PY is positionY, L is length, An is angle, O is orientation, Ar is area, C is column, R is row, CS is color saturation, CH is color hue, T is texture and S is shape, shown in Figure
1.