{'fraction_non_alphanumeric': 0.03377683654834799, 'fraction_numerical': 0.010143793256909596, 'mean_word_length': 5.030353507310753, 'pattern_counts': {'":': 1, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 3, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 3, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Integrated Visualization Editing via Parameterized Declarative Templates

Interfaces for creating visualizations typically embrace one of several common forms. Textual specification enables fine-grained control, shelf building facilitates rapid exploration, while chart choosing promotes immediacy and simplicity. Ideally these approaches could be unified to integrate the user- and usage-dependent benefits found in each modality, yet these forms remain distinct. We propose parameterized declarative templates, a simple abstraction mechanism over JSON-based visualization grammars, as a foundation for multimodal visualization editors. We demonstrate how templates can facilitate organization and reuse by factoring the more than 160 charts that constitute Vega-Lite's example gallery into approximately 40 templates. We exemplify the pliability of abstracting over charting grammars by implementing -- as a template -- the functionality of the shelf builder Polestar (a simulacra of Tableau) and a set of templates that emulate the Google Sheets chart chooser. We show how templates support multimodal visualization editing by implementing a prototype and evaluating it through an approachability study.

(as in Excel) allow users to rapidly construct familiar visualizations at the expense of flexibility. Shelf builders (as in Tableau) facilitate dynamic exploration but can obstruct the construction of specific chart forms or the addition of visual nuances. Textual programming is highly expressive but can impede rapid exploration.
A modality which may be well suited to the initial stages of a task, may become cumbersome in subsequent phases. For example, while a low-configuration approach for rapid data exploration might suffice at the beginning of their work, the user might subsequently require a more flexible-even if higher friction-interface that allows them to tune specific details of their chart. Graphical user interface (GUI) systems, such as chart choosers and shelf builders, can leave experts wanting more precise control over the chart creation process, while textual systems can leave novices in need of assistance. Without the ability to move between modalities, users are stuck with each interface's shortcomings. None of the existing single-mode interfaces simultaneously achieve each of several goals (as in Fig. 2): ease of use (G1), explorability (G2), flexibility (G3), and ease of reuse (G4). These deficits can force users to switch tools across their analysis [32], or compel proficient users to seek ad hoc solutions that are difficult to repeat in different contexts.
Ideally, interfaces of varying complexity could be integrated such that both novice users (for whom chart choosers are often best suited [21]) and experts (whose most profitable interface will vary) obtain the benefits of each modality as their tasks require. Unfortunately this territory remains under-explored, as visualization systems tend to prefer one-size-fits-all designs. Declarative visualization grammars are an enticing starting point as they provide significant flexibility for specifying visualizations as text (G3). However, they lack the abstraction mechanisms found in full-featured programming languages. This paper considers the question: Can we extend declarative grammars with abstraction mechanisms for reuse (G4), in a way that facilitates explorability (G2) as in shelf builders and ease of use (G1) as in chart choosers?
To answer to this question, we propose an abstraction mechanism called parameterized declarative templates, or simply templates, which extend textual, declarative grammars-specifically, those in which specifications are defined using JavaScript Object Notation (JSON) [15]-with mechanisms for reusing chart definitions. As depicted in Fig. 1h, templates abstract "raw" declarative specifications with parameters that specify data fields for a visual encoding (e.g. Color) and design parameters (e.g. height and width), making them more easily reused (G4). Templates can be rapidly instantiated for different data sets, shared among communities, and modified to taste-alleviating barriers to opportunistically [8] leveraging the rich body of grammar-based charts found online. Templates, which are essentially functions in a simple programming language with variables and conditionals, are described formally in Sec. 4  Here, an "Isotype Waffle" template is used visualize the people executed in the USA under the death penalty by race since 1977 [9]. Templates are functions with typed parameters that abstract JSON specifications in declarative visualization grammars.
We systematically apply this idea in a prototype visualization editor, called Ivy, in which templates are created and instantiated through text-and GUI-based manipulation (G1). Templates abstract over arbitrary JSON-based visualization grammars-our implementation currently supports Vega, Vega-Lite, Atom [62], and a toy data table language-allowing users to easily move between them (G3). We implemented an Ivy template that recreates the functionality of the shelf builder system Polestar [97,98], that serves as the default view of the system, facilitating explorability (G2). Our user interface design is described in Sec. 4.3.
The systematic application of templates furthermore enables two notable interaction features beneficial to exploration (G2). Catalog search utilizes standard type-based compatibility checks to implement an extensible-if simple-recommendation system. Fan out facilitates rapid exploration within a template by juxtaposing multiple chart configurations on demand. These features are described in Sec. 4.4. To evaluate how templates may serve as a foundation for multimodal visualization editing, we performed two investigations. We considered how they might usefully reproduce and compress extant families of charts, first by factoring the 166 unique examples that constitute the Vega-Lite gallery into 43 templates, and then by reconstructing the 32 charts of the Google Sheets chart chooser as 16 templates. We then conducted a small approachability study of our prototype Ivy system which demonstrated that, with some training and guidance, users are able to create and instantiate templates by mixing the available modalities. We present these results in Sec. 5.
Although the main ideas regarding templates-abstraction over value definitions-and their instantiations are familiar concepts, the contribution of this paper is to explore and evaluate how these ideas may help integrate what are currently disparate approaches for creating visualizations. The result of this exploration is our Ivy prototype, which exhibits the promise of this approach. This composition of modalities provides several potential opportunities, including borrowing and adapting external examples (which many shelf builders lack), rapid exploration of parameter combinations (which programmatic interfaces often lack) and self-service chart creation (which chart choosers typically lack). Compared to textual programming in existing declarative grammars, the abstraction layer provided by templates simplifies the process of chart reuse and therein reduces code clones (as in our chart gallery reproductions).
Our prototype is available at https://ivy-vis.netlify.app/. The appendix further details our evaluation and implementation, while other supplementary materials can be found at https://osf.io/cture/.

RELATED WORK
Software systems for creating visualizations can be classified into a variety of interaction modalities [20,59]. Among these, we aim to bridge three of the most common: chart choosing, shelf building, and textual programming. We now discuss declarative grammars and visualization editors, as they relate to the key ideas in this paper: (1) to endow declarative visualization grammars with basic abstraction mechanisms, and (2) to design a multimodal UI based on templates for creating and editing visualizations.  Figure 2: Chart making modalities have distinct strengths and weaknesses. Using parameterized declarative templates, Ivy strives to combine the strengths of several common modalities in this design space.

Declarative Visualization Grammars
Declarative grammars of graphics have proven extremely popular [23, 24, 42, 45, 49, 53, 62, 64, 66, 76-78, 80, 81, 83, 91, 92, 94, 95], with different approaches providing more expressiveness than others for particular tasks. Compared to full-featured, procedural visualization programming languages [6,7,35], declarative visualization languages trade fine-grained control over how to render a view for concise, expressive means to specify what to render. The idea behind parameterized declarative templates is to tilt these specification languages slightly back towards the full-featured languages, by adding some basic programming abstraction mechanisms.
Many declarative grammars [42,45,49,62,[76][77][78]81] adopt JSON as their specification format, which allows chart definitions to be easily consumed by various environments and tools. Vega and its surrounding ecosystem exemplify these benefits, which we seek to amplify by making JSON-based grammar specifications easier to reuse and explore. A related effort is Harper et al. 's [25] system for converting D3 charts [7] into reusable Vega-Lite specifications, which they also dub templates. Their templates provide abstractions related to ours, but are restricted to a limited subset of D3 charts. Ivy templates abstract arbitrary JSON and thus support any JSON-based visualization grammar.

User Interfaces for Visualization
2.2.1 Chart Choosers. This prevalent technique starts with selecting a desired chart form from a (potentially large) set of chart types, and then customizing it through a (usually limited) set of options. They are ubiquitous among analytics tools, such as spreadsheets, and are often found in visual analysis (VA) environments [2,13,60,82]. This workflow facilitates an approach to charting held by many novices [21], but can also lead to premature commitment [22].
Ivy provides a gallery of templates, some of which constitute single distinct chart forms, as in conventional chart choosers. Some systems, like Ivy, provide APIs for extending the selection of charts [17,56], but, unlike Ivy, they tend not to allow these changes from within the tool. Some systems [13,56,90] provide social features, wherein users can create, share, and modify charts. Ivy users can publish, fork, and remix templates through a shared template server.

Shelf Builders.
In shelf builders, users map data columns to visual attributes, typically in a manner that is motivated by a principled visualization framework, such as VizQL [24] or the Grammar of Graphics [95]. Tableau [80] and Charticulator [67] are prominent examples of this paradigm. Data fields of the current dataset are often represented as draggable "pills" that can be placed onto "shelves, " each of which denotes different aspects of the visualization (such as horizontal position or color).
We designed the GUI controls in Ivy for choosing arguments for template parameters to resemble the visual conventions of Polestar [97,98], itself a facsimile of Tableau [80]. Shelf builders support a range of tasks, including presentation [30,34,73,74] and exploration [80,97,98]. We facilitate the latter by constructing an Ivy template-IvyPolestar-that emulates and expands upon the Polestar application. This "default" template provides a familiar shelf builder interface upon application startup.
Many VA tools are backed by JSON-based declarative grammars (such as Lyra [74,102] or Voyager [97,98]), yet do not allow users to modify the underlying specifications. Restricting modifications to what can be created within such tools misses a significant opportunity, as there is a wealth of online knowledge and examples that ought to be utilized [8]. In commercial VA environments (such as Tableau), the disconnect from the underlying specification can cause fine-grained editing capabilities to be relegated to deeplynested drop-down menus, which can preclude feature utilization. We address these issues by making our templates malleable, so that users can adapt the interface to their needs.

View Exploration in Shelf Builders.
Shelf builders often prominently feature affordances for rapid data exploration, often in the form of recommendation systems [97,98]. Lee describes the current state of the art of these subsystems [46]. Our template-based architecture gives rise to simplified analogs to these "smart" features, but which still facilitate view exploration goals.
Our catalog search is an extensible variation of Tableau's Show Me feature [54], enabling users to create examples that are available for subsequent recommendation. Like Show Me, catalog search uses data-role based matching to identify potential alternatives. Unlike Show Me, however, catalog search does not internalize domainspecific knowledge of the underlying grammars-the recommendations do not consider, for example, known relationships between human perception and chart configuration.
Our fan out enables users to rapidly search across both data and design space by simultaneously juxtaposing parameter selections of interest. Similarly to catalog search, this feature is simple but achieves many of the same goals as additional prior systems [1,11,52] that often include sophisticated domain-specific knowledge, by enabling users to rapidly explore alternatives in a low cost manner (i.e. in a simple design gallery [55]) and to manipulate collections of examples simultaneously (à la Juxtapose [26]). This technique most closely resembles René's [18] combinatorial design exploration, although extended to encompass data-based variations.

Text-Based Editors.
There is a long history of UIs that combine textual chart programming with a system for rendering those charts. Computational notebooks, such as Jupyter Notebook [44], facilitate chart construction through tight feedback loops between code and rendered charts. In a similar manner to Ivy templates, papermill [61] allows analysts to parameterize computational notebooks which can then be run in a non-notebook environment. Observable [5] provides a reactive-programming platform for creating rich web-based visualizations, which users are encouraged to fork and remix. Wood et al. [99] take a literate programming approach to the visualization design process by enabling authors to build Vega and Vega-Lite charts in a Markdown document.
Most closely related to our work is the Vega-IDE [86], which augments textual specification of Vega and Vega-Lite charts with debugging tools [31], and Chart Builder [12], which allows users to edit Vega-Lite charts through a GUI or text, but not both. We borrow much of Vega-IDE interface design in the text-editing portion of our system; for instance, we make use of Microsoft Monaco's JSON-Schema [63] based support for JSON grammars as a way to provide linting and validation. Beyond standard text-editing features, we also implement extensible heuristic rewrite rules that (automatically) suggest abstractions of JSON values into parameters. This eases the flow of converting a declarative specification into a reusable template.

Multimodal Editors
. Several prior works have explored combinations of user interface modalities for creating visualizations. Liger [72] mixes together shelf-based chart specification and visualization by demonstration. Hanpuku [4], Data-Driven Guides [41], and Data Illustrator [50] combine visual editor-style manipulation with visual chart specification or textual programming. Victor [89] explored a prototype that combined a spreadsheet with direct manipulation and manual view specification. His system enabled highly expressive visualization construction, whereas we focus on supporting analytic tasks.
Tools such as Jupyter Widgets [38] and Shiny [70] provide mechanisms for parameterizing analysis code in an ad hoc manner, however these lack many of the graphical affordances for exploration found in many visual analytics systems.
Systems including mage [40], Wrex [14], and B2 [100] expand on these ideas by intermingling text and graphical specification in computational notebooks. Sketch-n-Sketch [28] takes a bidirectional approach to combining (non data-driven) visual editing with textual programming (in a full-featured, procedural language). Re-Vize [32] seeks to support multiple modalities by chaining together analysis tools though a Vega-Lite-based API.
Our investigation in this paper-to integrate chart choosing, shelf building, and textual specification-is complementary to these efforts. This combination of modalities offers a rich feature-space (such as our catalog search and fan out features), enables educational opportunities (by presenting a synchronized view between GUI and perhaps unfamiliar textual grammars), and supports a variety of data exploration tasks.

MOTIVATING USE CASES
Here we describe how two hypothetical users-Axel, a novice user of visual analytics systems, and Tabitha, a visual analytics power user-carry out two example workflows in Ivy. A motivation for our work is to allow users like Axel and Tabitha to collaborate and benefit from each other's efforts by working within a common system-aiming to supplant single-modality tooling that contributes to designer-developer breakdowns [48].

Axel: A Novice User
Axel wants to make a chart showing death penalty executions in the USA for a report he is writing. After loading a relevant dataset, Axel browses templates that have been created by others. Axel benefits from how other members of his team can easily grow the collection of templates to adapt to the team's changing visualization needs.
Unsure of what values are in the dataset, he selects a univariate bar chart template and uses fan out (Sec. 4.4.2) to view all of the dimension fields simultaneously. As he views these summaries, he gradually removes fan out options that are not interesting or do not serve his task. He eventually selects the option to display "race". He notices that there are 16 related templates (Sec. 4.4.1) that he could use. The "Isotype Waffle" catches his eye. He selects it to view a fully formed Isotype colored by "race". The chart does not have quite the right dimensions so he adds width and height variables to the template, which allows him to make small incremental adjustments from the GUI to produce the final version ( Fig. 1f). He takes a screenshot and adds it to his report.

Tabitha: An Expert User
Tabitha is interested in exploring the Gapminder dataset [69], so she loads the data and selects the IvyPolestar template. She explores the data using the familiar row and column abstractions (as in Fig. 5) to investigate iterative hypotheses. After viewing several scatter plots and bar charts, Tabitha wants to see a hierarchical representation of the part-to-whole relationships between region, country, and GDP; a Sunburst chart comes to mind.
Unable to find a satisfactory chart in the Ivy gallery, she browses the Vega gallery and finds one, but the way that it works with data does not quite match her intended usage. She creates a blank template in Ivy and pastes in the example from the Vega gallery. She is then presented with a series of automatically generated suggestions (Sec. 4.3.3) on how she might templatize her chart-clicking through these creates new shelves as appropriate. She text-edits the data transformation logic to accommodate her desired functionality. She uses the built-in debugging tools to view the results of the current data state, iteratively developing her transformations. She adds parameters for controlling width, height, color scheme, and other aesthetic values, at which point she is happy with the template and decides to share it. She clicks the publish button to make the template available on the community server, ensuring that she and others can reuse her work in the future. Finally, she instantiates the Sunburst for her dataset and takes a screenshot.

SYSTEM DESIGN
We now describe the design and implementation of Ivy. First, in Sec. 4.1, we introduce to the components of our system with a narrative walkthrough. Next, in Sec. 4.2, we present a rigorous formulation of parameterized declarative templates-a grammar-agnostic mechanism for abstracting JSON-based specifications-in a small programming language. Then, in Sec. 4.3, we describe our UI design for selecting and instantiating templates, designed to obtain the benefits and familiar aesthetics of chart choosing and shelf building. Finally, in Sec. 4.4, we describe how the systematic application of templates enables beneficial forms of view exploration.
A conditional which consists of a JavaScript predicate ($if), as well as (optional) true and false branches.
A reference to the xDim parameter.
Parameter declaration for variable "xDim", including type and configuration options. C Ivy template for an optionally sortable aggregate bar chart.
A fan out across a subset of the allowed years. E age people Fan out control, the darked icon indicates that there is a fan out across that variable.
This color shows the data roles specified by the template designer for this data target. This specification enables typed-based matching, but can be overridden or ignored by the user, as here in xDim.
Color indicates the automatically inferred, or manually set, data role for this data column.

Narrative Walkthrough
We now introduce the technical components of our system with a narrative description of our hypothetical user Tabitha constructing a reusable template from an example.
She begins by loading a population dataset in Ivy. She then copies in the "Aggregate Bar Chart" [84] from the Vega-Lite documentation ( Figure 3b). Figure 3a shows the output visualization.
After pasting in the code into the template body (via the Body tab of Fig. 1c), several automated suggestions are provided on how the data fields could be abstracted as template parameters. Clicking through the suggestions replaces the "age" and "people" data fields ( Figure [23][24]. She uses the settings popover ( Fig. 6) to specify their allowed data roles-she could have also done so using the Params text box (Fig. 1c). These configurations result in a shelf builder style user interface which she uses to explore her data set. She then uses these shelves to specify values for the xDim and yDim parameters ( Figure 3d). These value settings are then applied to the template body to produce a JSON specification, which is then transformed into a visualization by a language-specific rendering function, in this case, by Vega-Lite.
Next, she wants to chart populations for different years, so she replaces the constant value 2000 (Figure 3b Then, Tabitha considers whether and how to sort the bars. Knowing the appropriate Vega-Lite option, she adds a "sort" field with a conditional to the template body ( Figure 3c, line 23). She then creates a new template parameter, sort (line 8), and configures it such that if sort is set to true, then the "sort" value in the resulting Vega-Lite specification is set to "-x", which, in rendered Vega-Lite, sorts the bars in order of increasing value. If sort is set to false, then the resulting spec contains no "sort" field-as in the original specification ( Figure 3b).
Lastly, Tabitha wants to enable control of the color of the bars in her chart. To do so, she first defines a color parameter (Figure 3c, line 14), and then adds a reference to this parameter on line (Figure 3c, line 21). This allows her, or other users of this template, to pick between colors preferred by her organization.
Her template now satisfactorily prepared, she is ready to explore her dataset by specifying parameter values through the GUI (as in Figure 3d). In addition to specifying individual value settings, she can explore multiple options simultaneously using fan out (Figure 3e), which juxtaposes multiple views to consider (Sec. 4.4.2).

Template Language Design
Templates provide a simple set of abstractions over JSON-based grammars. Put simply, a template is a function specified in a superset of JSON, which includes variables and simple control flow operators, that when applied to arguments produces a chart in a particular visualization grammar. Templates are grammar-agnostic as they abstract arbitrary JSON specifications. We provide a full description of templates to highlight exactly how they make declarative grammar specifications reusable (G4)-by combining multiple specifications into a single template-and easier to use (G1)-by demarcating the arguments for manipulation. Formally, we define a template as a function that applies a set of template parameters, with type , to a template body to generate a view . In addition to the function itself, a template is a record that defines: the output JSON specification language L of the template body, metadata, and a list of zero or more templatespecific constant symbols that the body may refer to (Sec. 4.2.2). Our simplified model of JSON [15] values comprises atomic valuesliteral strings of type String, numbers of Number, and booleans of type Boolean-records of string-value pairs, and lists of values. The abstract syntax of templates is defined in Fig. 4.

Template Bodies.
Beyond JSON literals, a template body, or expression , may employ two basic programming constructs. A variable refers to a template function parameter or a template symbol , wherever a JSON literal value might normally appear. A conditional expression, written if then 1 (else 2 ), is dependent on the result of predicate expression , which is a "raw" JavaScript code string that evaluates to a boolean value. The else-branch is optional, which supports optionally-defined fields, per Sec. 4.2.3. Fig. 3c shows the concrete syntax for variables and conditionals in Ivy, which implements the abstract syntax of Fig. 4. Variables are "escaped" with square brackets (e.g. "[year]"). Following similar support in other tools [36], conditionals are written as shown in Fig. 3c line 23. Full-featured languages typically provide more extensive abstraction mechanisms, but-as we show in Sec. 5-even just variables and conditionals suffice for a wide variety of use cases.

Template
Parameters. The parameter declarations with types serve two purposes: to abstract over data fields and stylistic choices in the definition of a visualization and to define GUI elements that allow users to specify argument values for these parameters. For example, a "switch" widget is drawn for each parameter of type Boolean, a dropdown menu for each Enum, and a Tableau-style "shelf" for each DataTarget (Fig. 3d). Fig. 4 defines several parameter types . The data target types DataTarget and MultiDataTarget range over data columns (identified with strings) in the current dataset as well as template-specific symbols (also encoded with strings in our implementation). Symbols are template-specific values that can be used to instantiate parameters. For example, IvyPolestar defines a count symbol that induces a targeted channel to take on a count aggregation.
Each type contains type-specific arguments args , for example, the minimum and maximum allowed values for a Number or the values comprising an Enum. The data parameter types-DataTarget and MultiDataTarget-carry a configuration field to define a data role , discussed further in Sec. 4.3. Each type also contains an optional boolean expression that determines whether the GUI should display controls for that parameter -for example, displaying a sort direction widget only when a boolean sort parameter is set to true. Fig. 4 elides details of these type-specific arguments.
As parameters are arguments to a function, they must also have values. We refer to a user's choice of argument values as settings . Settings are typically set using the GUI, but can also be specified as text (Fig. 1c, "Settings" tab).
Second (Fig. 4B), the resulting expression is evaluated to produce a JSON value, transforming any conditionals into JSON values. This is done by a straightforward recursive traversal, following Eqns (1)-(3). Whenever a conditional is encountered, it is executed by evaluating the JS-based predicate (⟦·⟧ JS referring to JS evaluation), and then replacing the conditional with either the corresponding then-or else-branch as appropriate. Eqns (4) and (5) handle the two usual cases for conditionals. Eqn (6) handles the case when the predicate evaluates to false but no else-branch is provided; returning a ⊥ value, indicating that the conditional is to be deleted. Eqns (7) and (8) explicitly provide a mechanism to delete conditionals that return ⊥ in record values. This is how, for example, Fig. 3c line 23 optionally defines a "sort" field. Our implementation generalizes this rule to arrays by viewing them as numerically indexed records.
The third (Fig. 4C) and final step is to use the generated JSON to render a visualization. This is done by, for a specific visualization language L, using the corresponding rendering function ⟦ ⟧ L to interpret the JSON value and render the resulting view-typically as an HTML Canvas or SVG. Our current implementation supports four languages L, namely, Vega, Vega-Lite, Park et al. 's Atom [62], and a simple table language. However, as we discuss in Sec. 6.1.1, Ivy's language support is designed to be extensible.

User Interface Design
Equipped with the notion of templates, we next describe the user interface design of Ivy. As shown in Fig. 1, the application consists of two panes, one for chart editing and another for chart viewing. The chart editing pane contains a data column filled with Tableau-style "pills" representing data columns, and an encoding column with "shelves" for those pills to be placed upon. This encoding column can be used to instantiate (i.e. provide arguments for) the parameters of the template, or to edit the GUI of the current template. The editing pane also includes a code editor which can manipulate the current template and UI state textually. Per Saket et al. [72], we facilitate multimodal interaction by tightly synchronizing these views, such that changes in one modality are instantly reflected in the other.
Below, we describe how Ivy supports the creation, selection, and application of templates to produce charts.

Template Selection as Chart
Choosing. The root of Ivy is a template gallery, which aims to achieve Satyanarayan et al. 's [78] vision for a system "allowing users to browse through designs for inspiration, or adapt them for their own visualizations. " This avoids the blank canvas problem [75] and supports ease of use (G1).
The gallery is populated with a library of system-provided templates, as well as templates created by Ivy users (stored on a communal server). Simpler templates allow users to jump quickly to familiar visual forms (such as line charts or bar charts), while more sophisticated templates privilege thinking with their data [68] (as in IvyPolestar). The gallery is present both as a homepage for the application, independent from the visualization editor, as well as an intermediate view while creating new view tabs.
Each template is accompanied by a set of user-defined examples, namely, settings chosen by users to instantiate the template, with data bindings and output renderings with respect to a collection of predefined datasets. These examples serve as "crowd-sourced documentation" for how individual templates operate. Furthermore, this adds an element of opportunistic programming: to create templates, users can borrow small snippets-such as a well-formatted list of color schemes-and use them in their own creations.

Template Application via Shelf
Building. After selecting a template and uploading a dataset of interest, the user is presented with a shelf builder-style GUI for setting the template parameters and specifying basic data filters. We choose this GUI design seeking to exploit the same affordances that drive the explorability (G2) of shelf builders. Specifically, our design closely follows that of the Polestar shelf builder system, which Wongsuphasawat et al. [97,98] constructed as a simulacra of Tableau to serve as a baseline comparison in the development of their recommendation-based exploration systems. While emulating Polestar is a relatively small threshold to overcome in the context of visualization systems in general, it demonstrates the promise of our template-based approach. Systems such as Tableau or PowerBI possess features that-although substantially larger and more complex-are not substantially different than those in Polestar.
To select data parameters (i.e. DataTarget or MultiDataTarget) of interest, users drag-and-drop from a list of data fields, colorcoded according to their data roles, onto encoding shelves, as in Fig. 1a, d. Following prior work [1,80,97] roles include Measure u (quantitative fields), Dimension u (nominal or ordinal fields), and Time u (temporal fields). When a dataset is loaded, we make heuristic guesses about the role for each column, which the user can later modify. We use roles in Ivy to construct a naive automatic Add to Shelf feature (akin to Tableau's Add to Sheet [54]), except ours is simply based on order and data role. If a template has three DataTargets, the first of which allows only a Measure u while the latter two allow anything, clicking Add to Shelf on a Dimension u will add it to the second parameter.
In addition to the visual aesthetics of Polestar (and hence that of Tableau), we also emulate the functionality of its shelf-building interface through a "default" library template called IvyPolestar (shown in Fig. 5). The only features not replicated are the Automatic Mark Type-implementation of which, though possible in Ivy, was beyond the scope of the paper-and the chart bookmarks-which we replaced with a notion of view tabs.
Template defined symbols. This enables both the Polestar-style COUNT field, as well more advanced features, such as row and column shown here, which enable a Tableau-style multi-shelf. The config of each parameter can be modified through a type specific popover (here a slider).
Automatically generated suggestions for templatizing the current specification.
Users can edit the template metadata here, including the name and template language.
Parameters can be reordered by dragging. Their display status in view mode is shown here as SHOWN or HIDDEN based on the current param settings. Figure 6: In edit mode, users can modify templates both through the shelf builder GUI and the textual code pane.
A notable feature in Polestar is a count symbol that is visually similar to normal data fields and induces count aggregations on channels without a selected data column. To model this feature, we define a template-specific symbol (cf. Sec. 4.2.2), count, which IvyPolestar uses to implement the corresponding functionality. IvyPolestar introduces two additional symbols, row and column, that enable faceting by data columns in the manner of Tableau's multi-shelves. Placing row or column symbols on any shelf creates a MultiDataTarget which acts as a wrapper around Vega-Lite's juxtaposition operators [76]. Fig. 5 highlights this feature.

Template Creation and Text
Editing. Templates can be created or modified in two ways, either by modifying the textual representation (Fig. 3c) or through GUI interactions (Fig. 6). The textual representation facilitates both small tweaks (Sec. 3.1), as well as creating new templates. For instance, users may copy code snippets found online-such as in language documentation or Stack Overflow-and templatize them to suit their task (Sec. 3.2). Templates can also be created by "freezing" and refining the GUI state when interacting with an existing template. For example, a user might apply a full-featured template, such as IvyPolestar, to construct something resembling their desired chart, fork the text output as a new template (as in Fig. 1d), and then provide fine textual grained updates. As discussed previously, exposing textual representation to the end user furthers our flexibility (G3) and reusability (G4) goals.
To ease the construction of templates, Ivy uses domain-specific pattern matching and rewrite rules to suggest potential transformations to users. For instance, if a user were to find a chart in the Vega documentation that they wanted to copy, they would simply start a new template and paste the code into Ivy. The code pane then suggests ways to transform the code. For example, if a value in a Vega-Lite spec (such as in Fig. 3b) is used where a data reference is expected (e.g. "field": "age"), then Ivy suggests swapping "age" with a reference to a new parameter. Fig. 6 shows an example of such rules. Rules are defined by Ivy developers, rather than Ivy users. We implemented rewrite rules for Vega-Lite, Vega, and Atom.

Template-Based View Search
The systematic formulation and application of templates allows us to emulate recommendation and exploration (G2) features found in a variety of existing charting systems as a consequence of our design. Here we highlight two such features that follow naturally from the use of templates: one arises by fixing the arguments and varying the template, and the other by fixing the choice of template and varying the arguments.

Extensible Recommendation with Catalog
Search. The heterogeneity of user needs is often addressed in chart choosers by offering large and often diverse sets of charting options [54], which can be intimidating or difficult to utilize due to their volume.
The gallery in Ivy is equipped with catalog search, which allows users to search across the set of available templates based on compatibility with a set of specified columns of interest-specifically, by using a simple type-compatibility algorithm that compares template parameter types with the data roles of selected columns. This feature exists both in the gallery-where it acts as a type-based search mechanism-as well as ambiently throughout the system in the related templates tab (Fig. 1f)-where it acts as a simple alternative recommendation system. The current template is compared with each other template, yielding a partial match, a complete match, or no match. A partial match occurs when the selected data columns can be mapped to a template's parameters. A match is complete if all required parameters are mapped. A complete match can translate the current selection without additional specification. This heuristic is further detailed in the appendix. When a match is selected, the current columns are mapped onto the new template, using a similar mechanism as our Add to Shelf, and the resulting chart is shown immediately.

Exploring Encoding Variation through Fan Outs.
Comparisons in visual analytics are often made temporally, requiring the analyst to hold mental reference to each of the values under consideration. To reduce this cognitive burden, Ivy users can fan out a template by applying multiple settings and rendering their output simultaneously. Fig. 3e and Fig. 7 display examples of this interaction. To begin a fan out a user specifies sets of values that they wish to compare for each parameter of concern. This can be applied to both design and data parameters. For data parameters we provide suggestions of appropriate values based on the inferred data role and specified parameter role (Fig. 7a). We then compute a cartesian product of these sets and render a separate instance of the current template for each combination of values. Users then browse the resulting gallery, and can modify all of the combinations at once through the shelf-building UI, as well as remove values or select a combination to view in isolation (thus collapsing the fan out).
This approach allows users a low-stakes way to consider alternative chart configurations and rapidly explore the space of available design and data parameters.

EVALUATION
In the previous section, we discussed how our system design integrates and augments UI capabilities provided by existing chart choosers, shelf builders, and text-based editors. Here, we assess how well our template-based approach may work in practice by considering two questions: Do templates facilitate organization and reuse of existing visualizations? (Sec. 5.1), and Is Ivy's multimodal UI approachable by real users? (Sec. 5  Some examples had to be excluded (right) as they fell outside our data model, usually because they utilize multiple data sources, which Ivy does not currently support.

Templates for Existing Visualizations
We considered two chart corpora, the example gallery of Vega-Lite [88] and the chart chooser found in Google Sheets [19], looking for opportunities to factor related visualizations into templates, which yielded 3.5x and 1.8x compression ratios, respectively. Compression is the number of examples constructible by a given template. The reported average compression are computed by |Examples| − |Excluded by Data Model| |Templates| (9) In an example gallery, a larger ratio means less duplicated code (text) among examples. In a chart chooser, it means fewer chart forms with possibly more parameters. These results demonstrate that the simple template abstraction mechanisms enhance the flexibility (G3) of existing declarative grammars while improving their reusability (G4) by serving a variety of use cases. While even just the basic abstraction mechanisms in templatesnamely, variables and conditionals-are sufficient for merging all examples of each corpus into single templates, we strove to construct templates that are factored in reasonable ways, for example, by not depending on datasets having particular columns or features, and by considering what might plausibly be found in a chart chooser. This process prompted a number of minor system improvements, such as simplifying the conditional syntax and improving error handling, and suggested directions for future work on Ivy, such as a more sophisticated data model. Additional details of this analysis can be found in the appendix.

Vega-Lite Example
Gallery. This gallery consists of 166 distinct specifications, reflecting years of iterative refinement and development by the Vega-Lite community. These examples highlight a breadth and depth of features exposed by the library, thus forming an ideal testbed for the utility of templates. We recreated this corpus with 43 templates, skipping 14 examples due to incompatibility with our data model (a single, flat input data table) for a 3.5x compression. Fig. 8 reports the frequency of each template.
We aimed to capture both the core content of each example (the major feature being demonstrated) as well as the resulting image. However, this was not always possible. We allowed minor text modifications and the inclusion of properties not present in the original example, as long as they did not affect the core of the example (such as styling). It was sometimes necessary to forgo or modify some examples to accommodate our current implementation. For instance, a scatter-map of zip-code centroids colored by their first digit [87] needed to be modified because Ivy currently lacks a custom calculation feature. As a way to guide this design, we strove to maximize the concatenation ratio, or the ratio between the size of a template body and that of the concatenated examples it captures, which is computed for a particular measure of size , The resulting templates have an average lines of code concatenation ratio of 1.48x (a proxy for simplification) and an average abstract syntax tree concatenation ratio of 1.80x (a proxy for UI complexity minimization). In conjunction with the average example compression ratio of 3.5x, this suggests that our templatizations are better than merely concatenating the examples.

Google Sheets Chart
Chooser. The set of charts found in this chooser consists of 32 distinct chart forms. We focused on Google Sheets as a representative chart chooser because it possesses a similar set of chart options as other choosers, such as Excel and LibreOffice. We reproduced 29 of these charts through 16 templates for a 1.8x compression factor. We skipped 3 examples for the following reasons: "3D Pie" charts require a 3D visualization grammar, "Org. Charts" fall outside of our tabular data model, and "Timelines" require annotations, and therein modifications to the underlying dataset, which is not currently supported in Ivy.

Approachability Study
We conducted a study in order to evaluate whether the multimodal user interface in Ivy is approachable by real users. During prestudy pilot sessions, we found that users who were more familiar with Vega-Lite learned more quickly how to integrate Ivy's full capabilities to address tasks than those unfamiliar with Vega-Lite. Therefore, we aimed to recruit users familiar with these paradigms in order to evaluate the approachability of interacting with multiple charting modalities, rather than that of the underlying grammars. The target expertise for our study can be characterized roughly as between that of the hypothetical users from Sec. 3.

Participants.
We solicited 5 participants from a recent visualization course in a computational public policy masters program, all of whom are now employed as professional data analysts.
Based on their participation in the course, we were confident that these now-graduated students were familiar with Vega-Lite and Tableau. Participants, denoted P1 through P5, self-reported a mean familiarity with Vega/Vega-Lite of = 2.4 on 5-point Likert scale, and = 3.2 with visual analytics tools (5 indicating high familiarity). Participants were students at the same institution as the experimenters-specifically, in the context of a student-instructor relationship-thus constituting a source of potential bias.

Methods.
Following a brief introduction to Ivy through inapplication documentation, participants completed a series of 8 tasks that covered data exploration, chart specification, and template construction problems (additional details in the appendix). For instance, one task asked participants to templatize a particular Vega-Lite-based box plot [85], while another asked them to find the number of countries in a multi-year version of the World Happiness Report [27]. We focused on these tasks because they are similar to tasks supported in related systems and (with the exception of template building) were addressable with any of the modalities individually or in conjunction. Correctness was judged by comparison with a solution set prepared prior to the study. We engaged subjects in an informal think-aloud protocol during the session, which led to a number of the reported observations in the next section. Subjects were then asked to fill out an exit survey on the usability of Ivy and templates. Sessions were held over video conference software and lasted a mean of = 95 minutes, although 2 hours were allotted. Participants received a $50 Amazon gift certificate for their work.

Results.
All participants were able to complete all tasks within the allotted time, although all users required some assistance at various stages, typically due to implementation bugs or learnability hurdles. A variety of strategies were used to accomplish the data exploration tasks, some using only shelf building, some only chart choosing, or a mixture of both. All users were able to complete the template construction tasks and then use the templates to address data exploration tasks. We believe this indicates that real users, once acclimated, are able to produce non-trivial templates to accomplish varying goals.
Ths system was generally seen as usable. Participants mostly agreed with the statement "I think that I would like to use this system frequently" ( = 4.4 on a 5-point Likert scale), and gave a mean system usability score of = 68.0-describable as being between "OK" and "Good" [3]. More critical than users' perception of the usability, which may have been positively biased, is the demonstration they were able to navigate the system and use the interlocking modalities to achieve various tasks. While our study did not cover some concepts in our system-such as conditionals and catalog search-it demonstrated that users can approach and utilize the various UI modalities in Ivy. Participants sometimes had to be directed to use certain unfamiliar features, such as the templatization suggestions and fan outs. However, once familiar, users tended to continue to use those features.
Participants were enthusiastic about mixing code and graphical specification. P5 commented that the combination "feels more useful than just coding". P4 noted that their organization had recently switched a major Tableau-based dashboard to a Shiny-based dashboard because of a lack of precise data controls in Tableau. In contrast to the push for visual analytics tools to completely shed ties to text (embracing a "no-code" approach), we believe this suggests that systems that straddle the boundary between code and GUI specification can offer a valuable mixture of affordances that support real use cases.

Limitations.
We observed that Ivy held some challenges for participants. Participants sometimes struggled to understand what the templatization suggestions would do, indicating a closeness of mapping [22] failure. P1 and P2 suggested that visual design could be improved to aid in feature discovery. While some participants (P2, P4) agreed that templates are good for creating rapidly reusable charts, P2 noted that templates are "not very portable. " This could be addressed by embedding Ivy in tools like Shiny [70] or Jupyter [38].
The learnability of the system and mixed-modality remained a primary difficulty. Users typically struggled to figure out how to bridge the gap between text and GUI at first, however, by the end of the session, all users were competent in both regimes. For instance, most subjects iteratively refined their solutions to the box plot task, modifying both code and GUI values to address developing hypotheses. P3 noted that the system required a non-trivial level of computational and visualization literacy. Fortunately, users could seemingly bootstrap their knowledge to overcome these hurdles. P4 noted that the integration between the "code body and the point-andclickable GUI is really tight and also good for reinforcing learning" and that "If you know how to do something in one form, you can do it and watch how it changes the other side of the tool. " The scope of this study was small. We merely sought to demonstrate that real users of similar systems could approach the mixedmodality UI found in Ivy. While these results suggest that this combination is promising, further investigation is required to understand its utility in the context of more developed interfaces. Once our system reaches maturity, we intend to conduct a study comparing it with standard analytics tools, such as Tableau or Excel.

DISCUSSION
In this paper, we described how parameterized declarative templates-a typed abstraction layer over JSON specifications-can serve as a basis for a multimodal UI to create and explore visualizations. Ivy-style templates may help in the organization and reuse (G4) of existing visualization corpora (per Sec. 5.1). Vega and Vega-Lite have garnered ample popularity, and new declarative visualization grammars are being actively developed [42,49,96]. As the availability and use of these grammars continues to proliferate, there is opportunity for shared platforms and tooling between languages, which we explore in our grammar-agnostic templates.
The integration of features in our prototype appears to be accessible to users with modest experience in both visual analytics systems and Vega/Vega-Lite (per Sec. 5.2). Users were able to make effective use of affordances for exploration found in our shelf building UI and fan out (G2), and were able to utilize the capability of templates to improve the ease of use (G1) and reuse (G4) of declarative chart specifications while maintaining their flexibility (G3).
We believe that this multimodal approach has value for a variety of use cases. Exposing a connection between GUI and programmatic API may enable analysts to self-serve their chart creation needs. If a particular chart form is not available (but is constructible by one of the supported grammars) then they can create it for themselves, rather than requiring reliance on engineering resources. This connection between text and GUI appears to help users learn and comprehend JSON-based charting grammars, which may be unfamiliar or difficult to understand. The repeatable customization found in templates might also, for example, enable practitioners (e.g. data journalists) to explore designs in a structured manner that does not violate their organization's visual identity.

Limitations and Future Work
The version of multimodal visual analytics found in our prototype has its share of limitations. The strength of each modality in Ivy is only as good as its implementation, which can render artificial barriers between what users expect and what is supported (e.g. P3 expected a pivot table). And while Ivy encompasses chart choosing, shelf building, and textual specification, it does so at the cost of an increased learning curve. However, we believe that this difficulty is not endemic to multimodal systems, and that through attentive design the experience of using the system can be made easier.
In making our template-based approach more viable for practical use, it is easy to imagine a variety of system improvements-such as additional template parameter types (e.g. color schemes or inline data fields), drag-and-drop interactions for refactoring and abstracting specifications (e.g. [29,47]), as well as enriching the ways in which changes made in one modality are reflected and explained in the others. Beyond these, we highlight below several avenues for future research.
6.1.1 Language Extensibility. Ivy is designed to be extensible: support for each specification language is defined through a standardized interface, which includes a JSON Schema describing the syntax, a JavaScript rendering function for the language, and rewrite rules to help users abstract specifications. Our implementation currently supports a small set of languages (Vega, Vega-Lite, Atom 1 , and a simple table language), which, in future work, we would like to increase so as to support a greater variety of tasks.
Our grammar-agnostic template framework provides a standard set of abstraction and data manipulation mechanisms-which may reduce the need for grammar designers to define their own-and novel UI features for exploring candidate templates (catalog search) and encodings (fan outs)-which may facilitate more efficient and consistent exploration. Our system, furthermore, hoists the burden of data transformation out of the rendering grammar (albeit with a currently-limited set of transforms), which would otherwise require each grammar to implement its own data manipulation logic. As users move between templates (specified in possibly different grammars), their settings (including filters) are mapped from one template to the next via role and order-based heuristics. Future work could enable translation between supported grammars, which could yield opportunities for education and portability.
Despite the benefits of language-independent functionality, there are also benefits to taking domain-specific knowledge into account. Language-specific rewrite rules-part of the extension interface, described above-are one such example. Language-specific knowledge could further be used for recommendation, as well as data manipulation and presentation concerns. For instance, when a data field is dragged to a drop zone in Lyra [74] the appropriate type of scale is automatically inferred [75]. Lyra is able to offer this functionality because it has a model of the grammar being manipulated, a functionality which our approach currently lacks.
A lack of context and content-aware automated guidance is a key limitation of our design. Yet, it should be possible to identify a richer extensibility API, while still allowing each language to benefit from the abstraction and UI concerns shared by all. Such an API would enable us to combine domain-specific chart recommendation (Sec. 2.2.3) with Ivy's domain-independent type-based exploration (Sec. 4.4), as well as embrace new interaction modalities.

Validation in Visual
Analytics. An important question for system designers is how to help users conduct safe visual analysis [101]. Analysts can deceive themselves with statistical traps [65], visualization hallucinations [43], or false graphical inferences [93].
We believe that our type-based template search will dovetail with a metamorphic testing [58] based validation approach: by varying the parameters of a template and comparing the resulting images, a validation system could automatically identify errors at the intersection of data and encoding. Similarly, we suggest that templates likely offer an opportune medium for applying visualization linting [33,57] to a visual analytics context, as the types expose the specific arguments over which analysis could be conducted. Furthermore, the fan out interaction could be extended to allow not only juxtaposition of variants, but also their layering [51], enabling visual sanity checks to the robustness of parameter selections [10].

Integrated Visualization Editors.
A primary focus in this paper has been supporting data exploration tasks, but there are a constellation of other tasks that users perform in visualization tools. Users must carry out tasks "before" exploration (such as model building and data cleaning) and "after" exploration (such as annotation and presentation). Although the designs of many visual analytics systems assume that data has been cleaned and processed prior to analysis [75], in practice these tasks are often interleaved and iterated.
Integrating these tasks within a unified system may thus reap potential benefits. Data manipulation tasks, for instance, might be better facilitated by the incorporation of ideas from dataflow programming and spreadsheets, as well as programming-by-example techniques to help with data wrangling [16,37,39]. To more fully support presentation tasks, it would be fruitful to extend our combination of modalities to include visual builders [20]-which offer a variety of direct manipulation features [71,79] for creating chartsand visualization by demonstration [72,73,91,102].
For each of these tasks, developing rich graphical interactionswhile maintaining a "bidirectional" connection to the underlying textual representation-is an exciting research challenge: to integrate what is typically a vast divide between text and GUI based analytics systems. The approach pursued in this paper provides a step in this longer-term direction.
Users can search the gallery for templates that are compatible with a list of data fields specified in this multidata parameter.
They can organize the templates by a variety of schemes.
Each card gives a minimal description it's the template.

A APPENDIX
In this appendix we expand upon several elements of the design, implementation, and evaluation of Ivy discussed in the main paper. Fig. 9 shows the gallery of Ivy templates in our current implementation. Here we provide a more precise description of the heuristic used to perform the template matching in our catalog search.

A.1 Catalog Search Matching Heuristic
For a template (among the set of templates ) with a set of data parameters , (where each parameter has a set of allowed types ), and a search consisting of a set of data columns { } which each have a single type , then is a partial match for if there is an injective mapping between them such that (∃ ) (∀ ∈ )(∃ ∈ )( : → : Correspondingly is a full match for if where we define the required set of data param in as ⊆ . This check is bounded by the size of and , so a search across the templates will take O (| || |). We illustrate this in Fig. 10.

A.2 Implementation Details
Ivy is a TypeScript React-Redux application. We were motivated to use React as the basis of our application as it provides an opinionated approach on how to build additional renderers, which is important for our approach to extensibility. Our template server is a cloud-based node.js server backed by PostgreSQL. As described in Sec. 6.1.1 our system is designed to be extensible: support for each specification language is defined through an extension interface comprising metadata (such as a JSON Schema describing the syntax), a React component [105] that exposes the rendering function of the language, and rewrite rule definitions that help users abstract specifications into templates. While Ivy currently supports a relatively limited class of rewrite rules, future work could extend the approach with more expressive languages for transforming structured data (such as in CDuce [103] and XDuce [107]).
Our current implementation supports four languages-Vega, Vega-Lite, Atom, and a toy data table language-which serves as a limited demonstration of the validity of our extensible approach. As JSON-mediated visualization grammars continue to gain popularity, additional languages will inevitably emerge to solve problems unaddressed in prior efforts. Future languages could support more complex rendering schemes, focusing on particular domains such as geospatial analytics [106], 3D visual analytics, pivot tables (perhaps simplifying the language of VizQL [24]), or even on the chart recommendation language CompassQL [111]-which would enable task-specific variations of Voyager [98].

A.3 Templates for Vega-Lite Gallery
As described in Sec. 5.1.1, we aimed to factor the Vega-Lite examples into templates in reasonable ways, a heuristic which was guided by the minimization of complexity and the maximization of simplification. We illustrate these metrics in Fig. 11. The metrics in this figure are computed following Equation 10. Most templates exhibit a compression greater than 1, indicating that the template is better than simply concatenating the examples together. Those that do worse tend to have particular affordances to the template usable and also tend to only cover a single example, limiting their compression. See https://osf.io/cture/ for further details.

A.4 Templates to Reproduce Chart Choosers
We describe here in greater detail our templatization of the Google Sheets chart chooser (described in Sec. 5.1.2), as well as an additional chart corpus provided by Russell [109]. The latter fell outside the narrative in the main body of the paper, but we include it here as an example of the chart making culture in one particular organization. Table 1 summarizes the resulting templates described below. Smaller (34) Partially smaller (4) Larger (6) Out of 43 Figure 11: The concatenation ratios across our reproduction of the Vega-Lite gallery between the compression of the Abstract Syntax Tree (a stand-in for complexity minimization) and Line of Code Compression (a stand-in simplification). Higher is better in both cases.
A.4.1 Google Sheets. The Sheets chart chooser consists of 32 options. We reproduce 29 of these through 16 templates, as summarized in Fig. 12. We skipped "3D Pie" charts because there is not yet a dominant grammar for browser-based non-VR 3D visual analytics, although several recent works have put forward interesting approaches [104,110]. We skipped "Org. Charts" because they fall outside of our tabular data model, requiring a hierarchical one. Finally, we skipped "Timelines" because we do not currently support the data manipulations required to support textual annotations as required by this chart form. Each of these deficiencies could be addressed in future work, such as by extending the range of languages supported.
A.4.2 Russell Survey. This survey [109] of internal presentations at Google included approximately 1,300 charts, which were grouped into 15 distinct visual forms. We reproduce 10 of these through 11 templates. There are more templates than charts because, following Sheets, we split Russell's "Map" into two templates, "Country Choropleth" and "Scatter Map". Of the 5 charts from this survey we skipped, 3 involve a non-tabular data model, 1 requires domainspecific data (Lam et al. 's SessionViewer [108]), and 1 uses annotations. Among the 16 plus 11 templates described, 18 are distinct. While informative, this selection covers one particular analytic culture and one family of tool's designs. For instance, Russell's review found SessionViewer [108], a system for understanding web search usage behaviors, made up 2.1% of the review corpus. A review of a different corpus would likely yield a different selection of charts. Furthermore, this selection of charts is also a symptom of software availability. To wit: unit visualizations tend to be uncommon because few systems tend to support them [62].