# Projectional Editors for JSON-Based DSLs

Andrew McNutt  University of Chicago
<EMAIL_ADDRESS>Ravi Chugh  University of Chicago
<EMAIL_ADDRESS>
###### Abstract

Augmenting text-based programming with rich structured interactions has been
explored in many ways. Among these, _projectional editors_ offer an enticing
combination of structure editing and domain-specific program visualization.
Yet such tools are typically bespoke and expensive to produce, leaving them
inaccessible to many DSL and application designers.

We describe a relatively inexpensive way to build rich projectional editors
for a large class of DSLs—namely, those defined using JSON. Given any such
JSON-based DSL, we derive a projectional editor through (i) a language-
agnostic mapping from JSON Schemas to structure-editor GUIs and (ii) an API
for application designers to implement custom views for the domain-specific
types described in a schema. We implement these ideas in a prototype, Prong,
which we illustrate with several examples including the Vega and Vega-Lite
data visualization DSLs.

###### Index Terms:

Structure Editors, Projections, JSON, DSLs

##  I Introduction

Projectional code editors [1] combine _structure editing_ with _rich,
alternative views_ of code fragments or the runtime value they produce.
Structure-editing a program’s abstract syntax tree (AST) avoids various
classes of errors that arise when editing text, such as typos or misremembered
property names. Custom views, sometimes called _projections_ , further improve
usability via contextual visualizations by providing representations of code
relevant to a given task, such as runtime information or execution traces.
Projectional editors then aim to make programs simpler to read and modify.

When designed for particular languages or applications, projectional editors
can offer extremely rich [2] interactions compared to text. For example,
Sketch-n-Sketch offers both a structure editor [3] and a direct-manipulation
drawing interface for modifying and refactoring programs that generate SVG
images [4]. While powerful, such editors are bespoke, requiring substantial
engineering effort such that building, or even customizing, them may be out of
reach to many developers.

In contrast, language-agnostic editing tools seek to augment languages in
general, such as the autocomplete and refactoring tools available in editors
like VSCode. Compared to “high-cost” designs, such “low-cost” general-purpose
editors are naturally less feature-rich and (by their agnosticism) unable to
support domain-specific nuances.

Figure 1:  Prong can be adapted to any JSON DSL with a schema. Here it is
tuned to Vega-Lite via a custom Tableau-style drag-and-drop view and a view
that replaces inline data with an editable spreadsheet-style display. Here,
and throughout, figures are optimized for online zoomable viewing.

We explore a sweet spot in this spectrum via a generic approach to designing
projectional editors for a large set of diverse languages that support domain-
locality without enormous engineering expense. Namely, we consider domain-
specific languages (DSLs) whose syntax takes the form of JavaScript Object
Notation (JSON). This seemingly exotic form has experienced a sudden
popularity, arising in domains including databases [5], visualization [6],
twitter bots [7], and others [8, 9]. We suggest that a suitably general and
lightweight projectional JSON editor could be reused and adapted to various
JSON-based DSLs for little cost—being both cheap to learn (conceptually
simple) and cheap to use (short programs).

To address this goal, we present a prototype system, called Prong
(Projectional JSON GUI), that embodies two low-cost strategies (cf. Fig. 1).
First, to implement a general structure editor for JSON, we develop a mapping
from a JSON Schema [10] (a common component of a JSON-based DSL definition) to
graphical structure editors. Second, we define a simple API that allows
application designers to concisely define custom views. We provide ecological
validity for this design via a need-finding study consisting of a small survey
and a Technical Dimensions of Programming Systems [11] analysis of a prominent
JSON editor. We demonstrate the practical expressiveness of Prong by
(re)creating examples across several DSLs. Finally, we analyze our design’s
effectiveness via the Cognitive Dimensions of Notations [12]. See prong-
editor.netlify.app for a demo and osf.io/rvyjp for code.

Through this work, we demonstrate that projections can be constructed cheaply
for various DSLs. In doing so, we point toward a future where DSLs of any type
can be thriftily augmented through contextual views and visualizations.

##  II Related Work

We build on prior work that improves programming interfaces via _structure
editors_ , _rich alternative views_ of code, and those aiding _JSON DSL
usability_.

Early _structure editors_ , such as interlisp [13] and the Cornell Program
Synthesizer [14], were motivated in part by performance concerns: maintaining
well-formed program structures throughout the development process enables the
modification of running programs without having to restart execution. Many
subsequent designs (e.g. block-based editors like Scratch [15]) emphasize
learnability: structure editors avoid syntax errors and facilitate syntactic
and functional discoverability. The Cornell Program Synthesizer and MPS [16]
are notably language-agnostic, allowing tool builders to specify language- and
domain-specific definitions. Modern designs[16, 17] aim to emulate familiar
text editing across structural boundaries. Others [3, 18] more closely
resemble mainstream refactoring and autocomplete UIs, which augment
unrestricted text editing with structural interactions. More recently,
Sandblocks [19] enables derivation of structure editors from arbitrary
grammars while allowing some text editing actions.

Some editors render _rich, alternative views_ of programs and their runtime
values or dynamic behavior. Even when used solely for display (but not
editing), these _program visualizations_ are sometimes called “projections”
and generally fall within the goals of projectional editors [1]; examples
include _live programming_ environments, such as Projection Boxes [20], in-
situ visualizations [21], and _i_ -LaTeX [22]. Other editors [23, 24, 25, 26,
27, 28] allow custom GUIs to edit programs. For example, by dragging number
sliders and color pickers, or specifying input and output examples for a
desired code fragment to be synthesized. Among such editors, Hazel [29]
notably gives custom GUIs access to the runtime produced by evaluating a
partial program; this information may help the user decide how to fill in a
missing code fragment.

Some tools have sought to improve the _usability of JSON-based DSLs_ (without
resorting to hiding the underlying program as common in end-user programming
tools [30, 31, 32]). JSON Editor [33] and jet [34] provide structure-editing
and graphical elements for manipulating JSON but do not offer additional
affordances for particular DSLs. Other JSON editors are tuned to specific use
cases. For instance, Vega Editor [35] provides custom support for debugging
Vega and Vega-Lite programs. In-situ sparklines have been explored for program
visualizations [21] and reactive web applications [36]. Similarly, Vaguely
[37] is a block-based editor used for authoring Vega-Lite programs. Workbench-
style tools [38, 39] seek to improve the process of creating JSON DSLs.

In relation to the above characteristics, our design for Prong: is motivated
by enhancing usability and discoverability; supports only JSON syntax but is
agnostic between the many DSLs embedded in JSON and specified with JSON
Schemas; enables the definition of custom GUIs, with access to live value
information, for visualizing and modifying code; and extends ordinary text
editing with projectional features.

##  III Need finding study

To understand the places where projectional-editor style modifications might
usefully aid the process of using, composing, and debugging programs written
in JSON-based DSLs, we conducted an analysis based on the Technical Dimensions
of Programming Systems (TDPS) [11]. TDPS is a closely-related theory to the
Cognitive Dimensions of Notations [12], but instead focused on the system
surrounding the notation rather than the notation itself. We use this theory
to structure a close reading of a particular editor [35] that exemplifies
properties found in a similar system. We then use the identified issues and
drawbacks to guide Prong’s design. TDPS consists of 7 clusters of dimensions
(which shape our discussion), however we forgo consideration of _complexity_
and _conceptual structure_ as they have less bearing on the design of the
editor and more on the design of the notation.

To provide ecological validity to this reading, we augment this analysis with
results of a small online survey with users of JSON-based DSLs ($N=10$).
Participants (denoted PX and “quoted”) were asked questions about any JSON
DSL, but most discussed Vega or Vega-Lite—likely due to selection bias. Most
participants were 30-35 years old (5/10) and male (9/10). All held degrees in
computer science fields and $\geq$6 years programming experience. They were
paid via a raffle with an expected value of $6.50. See supplement for survey
instrument (osf.io/rvyjp).

Figure 2: The Vega editor includes common functionality found in other JSON
editors, so we use it to study it as a representative of this editor style.

Our analysis considers the Vega Editor [35] (Fig. 2). We focus on it because
it includes most features found in similar editors and thus can be seen as
representative of the form. It features various language server protocols
(LSP)-based capabilities [40], such as simple autocompletes, introspection,
and so on. These features are found in similar editors (but adapted to their
domains), including deneb’s BI-centric charting [41], MongoDB Compass’s [42]
NoSQL aggregation query building, and even Tracery Editor’s [43] support for
generative text programs.

Interaction. The first TDPS cluster considers the way in which users manifest
their ideas, such as through different sizes of feedback loops or gulfs of
execution.

The primary interaction loop in the Vega Editor involves textual input,
viewing the created visualization, and then modifying it through further
textual input. Within this loop are conventional text editor interactions,
including linting (providing semantic validation), autocomplete (providing a
simple syntactic search), and hover type hints (providing code explanation).
Outside of this loop are larger cycles that involve debugging (such as by
consulting the data, signal viewer, or developer console), consulting the
documentation, and specifying the data. The last of these might require
tedious round trips to make minor updates to the data. Vega and Vega-Lite
approach this issue via a data transformation notation, however debugging this
can be opaque and difficult for the user. For instance, P7 notes that it is
“easier for me to do data processing outside of Vega.” We address these issues
by supporting _in-situ_ projections of the state within the text, as in the
inline data table in our Vega-Lite case study (Fig. 1).

The presence of a common loop at different granularities suggests that
interventions could be made to tighten the loop bounds. For instance, moving
documentation look up into one of the interior loops, such as by structure
editing, has clear value. Moreover, it seems to be a feature that users
already desire. For instance, P3 wanted a way to know all “the available
values for each thing”, and P5 noted that “I can never remember the syntax of
anything. Where does “mark” go, where does “dataset” go or is it actually
“data”, is it “dot” or “point” mark etc.” Autocomplete can address some of
these issues, but its design limitations can lead it to “not always work” (P6)
and be unable to help place arguments. We explore an alternative approach in
our _in-situ search_ case study. Prior work [3] has shown the value of mixed
textual and graphical structure editing as it allows the user to make
modifications as they wish, without being forced into a single mode. This
notion guides the polite [44] design of our structure editor.

Notation. The next TDPS cluster considers the notations available to the user
of the system. Three top-level notations exist within the editor, Vega, Vega-
Lite, and a CSS-style styling language (for setting colors, fonts, and so on).
These notations are housed within JSON, which has usability issues of its own.
For instance, the lack of comments (P2, P3) and the syntax can be fiddly (such
as due to “trailing commas” P3). Reducing this _error-proneness_ [12], such as
by simplifying symbol input, motivates our use of a structure editor.

Various minor notations are scattered throughout these DSLs. These include the
Vega Expression language (which is used for controlling Vega’s variables),
web-driven properties (such as the hex color language), as well as more
domain-specific elements such as the d3 axis format language. Some of these
are more full-featured than others. For instance, P7 noted that the
“expression language is basically a DSL within a DSL.” P2 desired “syntax
highlighting for the expression language.” Similarly, P4 observed “I think one
limitation is that sometimes properties can hold strings and objects.” We
address these issues by creating means for alternative interfaces for these
languages through views.

Figure 3: An illustration of the mapping between the program, structure editor
menu, and JSON Schema for a toy “produce” DSL. (i) Some cursor positions that
generate some menus (ii). (iii) how each menu element was generated—i.e. via
the schema or various views.

Customizability. This cluster considers how the user can modify the usage of
the system to fit their interests and how system state can be manipulated.
Generally, the editor can not be modified by the language or even much beyond
some limited aesthetic options. Similarly, state is viewable through the
signal and data viewer, but can not be changed. P7 noted that “it is hard to
get info out of the runtime” but that the “data viewer and signal viewer are
very useful because they give visibility to state of runtime.” Surfacing tools
that allow the user to modify the user experience may allow them to specify
things in useful ways. To this end, bidirectional editing of state and code
(such that modifying state updates the code that generates it) seems
especially useful. This is explored in Chart Studio [45] and our Tracery case
study.

Errors. The penultimate cluster of concern considers how errors are surfaced
through the system. The editor can detect syntax errors (such as incorrect
JSON syntax), some semantic errors (such as using properties that are not
allowed by the JSON Schema), and runtime errors (as arising from Vega programs
execution). Dealing with these error types can be difficult [46]: “Debugging
can be hard. When things go wrong, you often just get a blank output” (P2).

The Vega Editor acts most concretely on the first two types. Syntax errors
block execution and are highlighted in the input pane. Runtime errors may stop
execution depending on the severity and are shown in the system information
area. The support might be expanded by, as P5 suggests, “looking at browser
dev tools could be an option,” adding that “Firefox, e.g., tells you which of
your CSS rules don’t have an effect….that would be cool for vega, too.” We
design our view system so that prior bespoke works (such as those on debugging
Vega [21]) are simpler to form and modify.

In contrast, the editor does little to help the user deal with semantic
errors, primarily due to limitations in the Vega and Vega-Lite JSON schemas.
For instance, P1 observed that based on current support “it’s not clear which
properties are valid for different chart types.” Such issues could be
addressed by redesigning the JSON Schema to better capture such issues, or
additional layers of tooling could be introduced (as in visualization linters
[47, 48, 49, 50]). Our system is designed to provide simple support for adding
additional validators. As our malleable views power this support, it is not
bound to highlighting errors via :wavy underlines. See Fig. 5A or Fig. 6.

Adoptability. The final TDPS cluster studies how the system helps or hinders
adoption by various users.

The learning curve of JSON-based DSLS can be high for new users [6]. This is
likely due to the often off-putting JSON-based syntax, and, as noted by P6,
“the toolchain for non-js coders is quite burdensome.” The editor does help
with the latter of these issues by making it easy to quickly drop into a
chart, however, it can still be challenging for novices, which has led to a
variety of tools that seek to make them easier to use [37, 51, 52]. Supporting
novices by providing system-level support for simplifying the idiosyncrasies
of JSON programming informs the design of our structure editor.

A key way in which novices are supported in the Vega ecosystem is through a
close binding between the documentation and the editor in a way that supports
opportunistic programming [53]. For instance, the editor’s examples modal
exposes the hundreds of chart types (mirrored from the documentation), acting
as something akin to a chart chooser [54]. This allows users to jump to
particular charts and then adjust them to task—although, as explored in Ivy
[51], tooling can further simplify this process. To this end, P4 noted, “so I
take an example that is closest to what I want to do and then proceed from
there.” Within the notations, a wide array of functionality is provided,
capturing numerous common data transformation operations (among others). Yet,
P4 noted that the data transformation language is “hard to grasp too and the
data viewer could do a better job in communicating these.” P10 observed
“there’s a lot of hidden state then requires guessing.” The editor has some
support for this type of inquiry, but it is inadequate for some users—P8
wished that the data view “was more insightful, intuitive, and easier to
explore.” We seek to close the gap between context and text by designing our
views so that JSON DSL novice-friendly UIs are simple to build.

##  IV System: Prong

To explore how we might address the limitations of prior JSON editors, we
developed Prong (Projectional JSON GUI). This modular framework supports JSON
DSL use by enabling browser-based projectional editing in the context of a
full featured text editor (CodeMirror [55]), consisting of two components: an
automatically inferred structure editor (based on a JSON Schema [10]) and
custom views that commingle with text (provided by the application designer).
These tools enable cheap domain-specific editors in a practical setting that
previously might have required protracted engineering effort.

Structure Editing. Prong enhances text manipulation through a dynamic menu
that provides type information, structural manipulation, and DSL-aware
suggestions. The basic interface is that a of text editor, so the underlying
source of truth is text, but additional means of editing (namely via our
menu). It follows the text caret as in an IDE-style tooltip (Fig. 5A), appears
docked at the bottom of the editor, or floats in a user-specified location
(Fig. 5E)—allowing the user to decide how much visual response fits their
usage.

The simplest controls in the menu come from JSON parse-tree data types. This
enables basic text manipulations (e.g. inserts, deletes, and reorders) to be
conducted graphically. This limits some of JSON’s well-known _error
proneness_.

More critically, however, is the information derived from JSON Schemas [10].
Schema are JSON objects that describe allowed forms for a given JSON
DSL—analogous to providing TypeScript types for an untyped JavaScript (JS)
library. While JSON DSL usage is often supported by schemas [35], we
demonstrate how those schemas can be used to form structured editing
elements—e.g. buttons that insert synthesized objects (by identifying required
props) or option picklists—instead of merely for validation [56] or
autocomplete [57]. We compute applicable types for every AST node (via the
schema) and then apply them to a suite of heuristics to generate all relevant
information and potential changes from the current state (cf. Fig. 3). For
instance, the user in Fig. 1C can click buttons for each allowed field type
(_nominal_ , _ordinal_ , etc.) rather than needing to remember or type them.

To simplify searching the structure editing options, Prong includes a simple
autocomplete that uses incomplete strings as a signal to filter the menu. This
coarse autocomplete captures many of the same properties as more complex
recommenders without requiring the weighty configuration of tools like a
language server. Autocomplete [57] is typically available for JSON DSLs via
Schema support [57], however, Prong is unusual in its support of browsing all
possible values for a given position, which supports our respondents’ desires
to that effect. Prior work [58, 59] has explored some related designs.

$\begin{array}[]{ll}View&=\Bigg{\\{}\begin{array}[]{l}{placement}=`inline^{\prime}\hskip
5.78172pt|\hskip 5.78172pt`replace^{\prime}\hskip 5.78172pt|\hskip
5.78172pt`menu^{\prime}\\\ {query}=Query,\\\ {content}=ReactComponent\\\
\end{array}\\\ \\\ Query&=(SyntaxNode,ASTNodeName[])\\\ &{\hskip
2.8903pt|\hskip 5.78172pt}{}(KeyPath,keyPath[])\\\ &{\hskip 2.8903pt|\hskip
5.78172pt}{}(SchemaNode,SchemaNodeName[])\\\ &{\hskip 2.8903pt|\hskip
5.78172pt}{}...\end{array}$ Figure 4: Formal description of our views.
SchemaNode refers to the inferred type of a given node from the Schema,
whereas SyntaxNode refers to the type inferred from parsing. See prong-
editor.netlify.app for implementation-specific details, such as component
props.  Figure 5:  Prong’s projectional editing consists of schema-derived
structure editing (B, E) and custom views (A, C, D, F).

Custom Views. Prong supports domain-specific functionality through views.
These modular specifications let the application designer describe how and
where custom components should be placed, enabling construction of numerous
potentially bespoke UIs in a systematic manner. For instance, sparklines[60]
can be used to show runtime data inline [21], or a spreadsheet might replace a
block of tabular data—examples we explore in our Vega case study. While not
prescribed, the intent of views is to present DSL information in a fashion
that might more effectively match that content. This design seeks to address
the limitations found in conventional editors due to their _unrich_ connection
with their output, which often leads to difficulties in both text authoring
and debugging.

As formalized in Fig. 4, views are placed _inline_ with the text (as prefixes,
suffixes, or backgrounds), _replace_ the text, or appear in the _menu_.
Queries executed during a syntax tree traversal determine on which AST nodes
views will appear. Queries are a tuple consisting of the query content and its
type, which might include the location in the syntax tree (_KeyPath_), the
inferred data type from the JSON Schema (_SchemaNode_), the AST Node type
(_SyntaxNode_). For instance, the query _(SchemaNode, exprString[])_ selects
all Vega Expressions in a Vega-Lite program. Views follow a CSS-style cascade,
so that later views take priority over earlier ones. For instance, two
_replace_ views whose queries match the same node, the one specified later
will be used. View content consists of a React component which can contain any
details present in the containing application, or automatically inferred data,
such as types from the schema. For instance, runtime info can be integrated
directly into the text via sparklines. Views’ unprescribed format supports
numerous designs while offering a familiar API for many developers (conceptual
thrift).

Views are supplemented by a preamble of common tools (as in JSON Editor [33]),
including boolean toggles, color indicators ${\color[rgb]{1,0,0}\bullet}$,
color pickers, number sliders, code formatters, and object sorters. These
elements can be removed by the application designer if they are unnecessary.

##  V Case Studies

We next demonstrate the expressiveness of this approach via several case
studies. We focus on these DSLs because they are intended for human use [6],
have differing semantics, and have well-formed schemas. Demos are at prong-
editor.netlify.app. 111These demo implementations make some functional
simplifications to show the properties of concern (e.g. the Vega-Lite example
only supports small data). However, because of Prong’s architecture, each DSL
is fully supported—although further projections are necessary to use them as a
complete end-user application.

Warm-up. To begin, consider a toy example. JSON can be verbose, as it features
numerous double quotes for string literal and object properties. To reduce
this visual noise, we can construct a quiet view that prunes double quotes:

$\left\\{\begin{array}[]{l}target=(SyntaxNode,[PropertyName,String]),\\\
context=`inline^{\prime}\\\ content=\\\ \hskip 14.45377pt\verb+(props) =>
<div>{trim(props.value)</div>+\\\ \end{array}\right.\\\ \\\ $

This small amount of code transforms the editor (Fig. 5A) without requiring
heavyweight extension code used in tools like base CodeMirror [55] or VSCode.
For instance, a minimal React application enabling quiet mode requires 128
lines of code (LOC) in base CodeMirror and only 42 LOC in Prong (see link).
Verbose extension APIs (like CodeMirror) support the construction of any
extension for any language and text, whereas ours augments the JSON AST. This
exchange is one of domain-specificity: by simplifying the API, we make many
editors simpler to produce while making some impossible.

In-situ Visualization with Vega. Vega is famously difficult to debug [21, 46]
as it possesses ample _hidden dependencies_ , the navigation of which can
yield _hard mental operations_. 222 These issues are well enunciated by the
Cognitive Dimensions of Notations [12], which is a set of heuristics used to
structure close readings of interfaces. We reference these _dimensions_
throughout to note usability issues.

An exciting approach [21, 36] to these issues has been to add visual
presentations of these _hidden dependencies_ in the code itself—such as
through sparklines, like . Yet such enhancements are typically bespoke,
requiring expertise with the extension environment, putting them far beyond
many developers. Fig. 5C shows a view that inserts several families of
sparklines showing univariate data summaries. Our sparklines extend prior work
[21, 36] by allowing users to toggle through different visualizations, rather
than fixing a single one. This is enabled by our lightweight component
architecture.

Debugging Vega is made more difficult by the DSLs embedded in its schema. For
instance, it includes an expression language (a JS subset specified in string
literals) that controls its variables (called signals). This supports a range
of expression types that would be difficult to capture via JSON-based
operators, for instance, the snippet "1 + sqrt(datum.size) / 2" concisely
describes a simulation force. Yet, editors typically do not provide syntax
highlighting for string-embedded DSL or other typical editor affordances like
autocomplete, which can yield an _inconsistent_ interaction between the
notations. These issues impede reasoning about whether a given expression is
correct. To address these issues, we created a signal editor view (Fig. 5F),
which includes a syntax highlighting code editor with a Vega Expression-aware
autocomplete. To compose a new signal, the user navigates to an expression and
starts typing in the menu, receiving autocompletes and validations (à la
linting) of their expression. By supporting nested DSL usage, we can reduce
some of the cognitive burdens of using Vega.

With relatively little work, we can (re)create sophisticated bespoke editors
and resolve issues latent to this form of DSL.

Blurring Text and GUI in Vega-Lite. Vega-Lite simplifies Vega by limiting what
is expressible in favor of a syntax tightly bound to the grammar of graphics.
Yet, its sometimes _terse_ and _secondary notation_ -free syntax can be
difficult for novices [51, 61, 62]. Previous solutions often put a facade
between the user and text, letting them interact indirectly with the DSL via a
GUI—as in Lyra [30] or Voyager [63]. Here we explore how Prong can help weave
GUI interactions into text editing.

We explore the potential of this approach through several views. First: a
Tableau-style drag-drop interaction, in which data columns are dragged from an
automatically inferred set of “pills” onto “shelves” that replace text that
describes the binding of data fields to graphical channels. For instance, to
change the encoding of the x dimension in Fig. 1A the user drags one of the
data fields above the editor onto the relevant field target. When the text
caret enters the drop targets, they switch from GUI to text—allowing more
familiar users to use text if they wish (functionality that can be activated
per view). Next, we replace inlined data (arrays of objects) with a more
graphically approachable editable data table (Fig. 1B), which operates akin to
a familiar spreadsheet interface. Views can be introduced to modify the
program to better align with the form the application designer wishes to use.
For instance, we include a view that converts data references into inline data
(which is better suited to our data table component’s expectations) and
another that allows the user to upload data into a specification without
copying and pasting. Finally, we add pick lists directly into the UI so that
users might more easily select values relevant to them, such as allowing the
user to select a mark type. Such views can simplify JSON-based DSLs use, as
they provide a straightforward way to use and modify a potentially unfamiliar
DSL.

Vega-Lite features a well-annotated JSON Schema that enables our structure
editor to provide useful suggestions and options. Yet this schema is imperfect
and can make it difficult to check if a chart is being used in a semantically
incorrect way. For instance, the _circle_ mark type does not support _text_
encoding, as that encoding field is unique to the _text_ mark, yet nothing in
the schema would prevent the user from authoring such a program. Thus, while
schemas cheaply give basic validation, they do so potentially at the cost of
being unable to handle some usability issues. A custom linter [49, 50, 47, 48]
could potentially guard against issues like this, however, such tools require
careful construction. Our view system supports simple construction and
presentation of such validators (such as through the CSS class-based styling
used in Fig. 6), but this places a non-trivial burden on the application
designer to re-engineer the intended semantics of the DSL.

Through these modest views, we are able to create novel domain-specific
interfaces that simplify interactions with a sometimes thorny or complex
visualization DSL.

In-situ Search for Vega Config. Vega Config is a CSS-like DSL for making
reusable chart styles in Vega and Vega-Lite . Creating such a style is a non-
trivial task because Vega Config is closely bound to the rendering context and
does not have Vega/Vega-Lite’s elegant formalisms. These factors cause it to
be a large and _inconsistent_ DSL. Such _inconsistencies_ can lead to frequent
docs searches—cycles that can cause the user to lose context [51] and lead to
the _language cacophony_ [64] DSL failure mode.

Among such external loops, there are several types of search, including what
the specific syntax of a given property is (as in Barke et al.’s [65]
acceleration), browsing available functionality (as in their exploration), and
where a property should be placed (which is more local to JSON-based DSLs).
Prong supports the first two issues via the menu and autocomplete. For
placement, we create an in-situ search view that generates inline suggestions,
as shown in Fig. 5D. Suggestions are generated by a schema traversal that
matches properties like name or description with a query string. These are
then formed into JSON snippets from the traversal path, inserted into the
code, and visually marked as suggestions. This addresses respondents concerns
about knowing where in a specification to place an argument in a JSON program.

A user composing a chart style has then several entry points. They might begin
by typing part of a property name to receive IDE-style autocomplete menu
filtering. They can also start by searching for a particular endpoint they
wish to find, such as by typing a color scheme they want to include (e.g.
_cividis_) into the in-situ search, which then will generate suggestions
including each of the intermediate steps to reach their goal. They can then
click through those they want to accept and dismiss the rest. A _richer_ [2]
UI would allow user to select and style parts of a rendered chart directly,
without needing to pass through text. Yet, such an approach would require
careful instrumentation of the Vega renderer. This search could be replaced
with an AI-based code-generator model [66], which might enrich the results at
a steeper cost.

Our approach gives ample value for little implementation cost ($<$500 LOC) in
a way that can be applied to any schema.

Tracery: Bidirectional Views. A key advantage of using JSON for a hosting
language of DSLs is that it is simple for mechanizations to operate. Here we
explore how this property can simplify the creation of applications that are
tightly synchronized between representations in Tracery [7].

Tracery is a generative textual language intended to support casual creators
by creating text from a predefined grammar, facilitating tools like Twitter
bots or procedural narratives. It consists of an input grammar (a JSON object
describing the grammar) which is used to generate a piece of text. The
language has a type `Record<Symbol, Rule[]>` where `Rule`s are strings that
may contain references to symbols (e.g. `#mood#`). An instantiation is created
by recursively expanding from a start symbol. The DSL’s simplicity matches its
intended users, who lack technical skill (such as children [67]) or whose
expertise lies in other domains (such as artists).

Despite the apparent simplicity of the language, its users may have trouble
tracing the relationship between the program output and the grammar, yielding
_hard mental operations_. To address this, we developed an instance of Prong
tuned to support Tracery (Fig. 6). This system includes several custom views.
Fig. 6A highlights a menu focused on one of the `Symbol`s, which shows several
type-based suggestions (such as remove key) as well as a Tracery Editor-
inspired view [43] (TraceryEditor) that shows the relationship between the
constructed piece of text and the grammar. Fig. 6B shows a menu focused on a
`Rule` that includes suggestions to insert references to the `Symbol`s.
Throughout the text pane `Symbol`s and `Rule`s are colored to highlight their
usage. These colors are synchronized with the output (Fig. 6C) to simplify
tracing the connection between output and grammar.

Figure 6: Prong supporting the generative text language Tracery [7]. This
instance has simple bidirectional editing between the output and input, and
syntax highlighting for the specific values involved in the output.

Finally, the output and the grammar are bidirectionally synchronized, such
that edits to the output are propagated back into the grammar. In particular,
edits to the output are returned to the grammar through a simplistic
enumerative synthesis algorithm, in which the modification to the output is
identified (delete, insert, swap). Then an appropriate modification is made to
every `Rule`, until the expected output is formed. If this fails (such as
because a `Rule` is in use twice), then a provenance-based algorithm (based on
annotating the execution tree) is used to identify the string position. When
unsure how to proceed, the system does not propagate the edit back into the
grammar, instead alerting the user that it is out of sync. While imperfect, it
offers functionality not previously available for this DSL.

These views provide a rich connection between the input language and the
output. This example further highlights the simplicity of using Prong as part
of a UI. While this was the most involved of the studies, requiring the most
bespoke crafting, it was achievable in $<$800 LOC.

##  VI Analysis

Here we analyze Prong using the Cognitive Dimensions of Notations [12] (CDN).
We use CDN (rather than TDPS) because it can be used evaluatively [68],
whereas TDPS is primarily a descriptive theory.

Prong utilizes a text-forward approach compared to other structure editors,
which often preference GUI representations at the cost of losing some textual
expressiveness. In giving primacy to text, we also inherit all of the issues
latent to it. For instance, JSON’s strict textual syntax can be highly _error-
prone_ , as even small typos will cause programs to be unreadable by many
parsers, yielding a disproportionate error response. Prong addresses this
issue by utilizing the forgiving JSONC parser [69] (which supports comments as
a _secondary notation_), and by offering structural edits (such as inserting
new elements in arrays) so that such issues are harder to encounter. Yet it is
not impossible to encounter such issues. Prong has limited error handling
capabilities, whose default is to deactivate views in the presence of an
unresolvable error. This may confuse the end-user, who is not clearly warned.
While primarily an implementation issue, the design for such alerting needs to
be clarified.

Just as in other declarative languages, it can be challenging to debug [70],
requiring the programmer to hold a potentially unfamiliar execution model held
by the DSL in their mind to address possible subtle errors (providing _hidden
dependency_ and _hard mental operations_ difficulties). We follow Hoffswell et
al.’s [21] _in-situ visualization_ in that our custom views offer a space for
the application designer to surface relevant information into the editor to
help end-users debug. However, this support does not come for free, and so it
pushes the burden on the application designer to make the tool useful.
Similarly, the other common shortcomings of JSON editors (such as difficulties
with _juxtaposability_) are not addressed by Prong directly. Instead, the
application designer is simply given more places to help resolve those issues.

Prong seeks to improve the _closeness of mapping_ between using a language and
its output through its projections, but this approach can be somewhat
artificial. Enhancing the textual form of JSON-based DSLs supports their use—a
task distinct from the actual task that the DSL aims to achieve: making it
easier to author Vega programs is different from presenting data. Such _rich_
[2] interactions are ideal but difficult to achieve in a cheap generalizable
manner, as in our Tracery case study.

From an application developer’s perspective, Prong is also not without
cognitive roadblocks. Our query-and-effect model for specifying view placement
utilizes likely familiar CSS-style conventions. However, this exposes CSS-
style issues, such as _progressive evaluation_ difficulties in the potentially
opaque placement of nodes. Further, our AST and JSON Schema-centric mental
model might be challenging to some developers. We try to address these issues
via a debugging view that exposes properties like inferred types and node key
paths, but this will do little to reduce _hard mental operations_ for some
users. Yet, some designs are simply impossible with our approach. For
instance, our views cannot modify each other (à la CSS cascades), making some
context-sensitive queries difficult to produce. Other designs (like
CodeMirror’s functional-update loop) could address some of these issues but
induce other burdens of their own (such as a more _vicious_ and complex usage)
that may be unfamiliar to many.

##  VII Discussion

We have shown a way to make projectional editors for JSON-based DSLs cheaply
(in terms of implementation size and conceptual burden). This enables
straightforward construction of designs that might otherwise require
substantial effort.

We used our prototype instantiation of this idea, Prong, to explore how text-
based interfaces can be the foundation of a UI rather than merely a part of
one—in contrast to tools like Ivy [51] or GALVIS [71], which attempt to
enhance JSON-based DSL usage by surfacing them as a _component_ of the
interface. From these explorations, we suggest that contexts where DSLs (like
SQL) are prominent might surface those DSLs in the UI rather than (digitally)
papering over them. For instance, a dashboard could show data provenance by
weaving its charts into its SQL queries. Numerous new application forms open
by viewing the text plane as an approachable part of UI design. However, like
any work, this one has its share of limitations and areas which could be
usefully expanded.

This paper focused on showing that bespoke editor enhancements can be built
cheaply and systematically, rather than verifying such interventions are
valuable to users. Prior studies—both from works debuting some of these
techniques [20, 21] and those considering projectional editors more generally
[72, 73]—provide empirical evidence of the utility of these interventions. As
a way to check these properties we employed a theory-forward evaluation that
allowed us to identify various short comings. While a useful form of critical
reflection [74], we intend expanded on these considerations by exploring how
useful projectional editors are for realistic lay end-users in practice, once
we have refined Prong for wider release.

Sulír et al. [75] describe a design space of visual augmentation of source
code editors. While Prong can produce most designs, it can only place elements
on the AST, which precludes marginalia and line-based views. This is a
limitation of our query language that we intend to address.

JSON Schemas provide substantial value for us but also have non-trivial
limitations. They can be challenging to author or maintain and have known
design flaws [76, 77] (like being unable to validate within strings). Growing
tool support (e.g. auto-generating schemas [78]) minimizes some of these
issues, but future work should abstract our use of JSON Schema to other JSON
DSL metalanguages, like TypeSchema [79].

Prong supports a use case where expressivity and full DSL access is important,
however, other usages might be well served by something form-like (à la Flex-
ER[80]). Yet, tools like Ivy [51] show that such modalities can fruitfully
coexist. Future work should explore how projections can mingle with simple
forms like chart choosers [54].

Beyond our case studies, there are numerous [57, 77] exciting applications for
Prong. For instance, supporting the web application DSL Varv [8] might allow a
self-hosting view system that is modifiable by the end-user. A Prong-based
JSON Schema builder could guide users to create schemas that would make the
schema more useful for Prong (e.g. including descriptions). Aiding such
domains promises to make a wide variety of novel experiences not only
possible, but cheap.

##  VIII Acknowledgements

We thank our survey participants for sharing their experiences, our reviewers
for their thoughtful critiques, and the IEEE VIS Doctoral Colloquium for their
support of this work. We also thank Will Brackenbury, Nicolas Kruchten, and
Brian Hempel for their helpful comments on this work.

## References

  * [1] M. Fowler, “Projectional editing,” 2008. [Online]. Available: https://martinfowler.com/bliki/ProjectionalEditing.html
  * [2] J. Horowitz and J. Heer, “Live, Rich, and Composable: Qualities for Programming Beyond Static Text,” in _PLATEAU Workshop_ , 2023.
  * [3] B. Hempel, J. Lubin, G. Lu, and R. Chugh, “Deuce: A Lightweight User Interface for Structured Editing,” in _International Conference on Software Engineering (ICSE)_. ACM, 2018, pp. 654–664. [Online]. Available: https://doi.org/10.1145/3180155.3180165
  * [4] B. Hempel, J. Lubin, and R. Chugh, “Sketch-n-Sketch: Output-Directed Programming for SVG,” in _Symposium on User Interface Software and Technology (UIST)_. ACM, 2019, pp. 281–292. [Online]. Available: https://doi.org/10.1145/3332165.3347925
  * [5] MongoDB Inc., “MongoDB,” 2023. [Online]. Available: https://www.mongodb.com
  * [6] A. McNutt, “No Grammar to Rule Them All: A Survey of JSON-style DSLs for Visualization,” _IEEE Transactions on Visualization and Computer Graphics_ , vol. 29, no. 1, pp. 160–170, 2023. [Online]. Available: https://doi.org/10.1109/TVCG.2022.3209460
  * [7] K. Compton, B. A. Kybartas, and M. Mateas, “Tracery: An Author-Focused Generative Text Tool,” in _International Conference on Interactive Digital Storytelling ICIDS_ , vol. 9445. Springer, 2015, pp. 154–161. [Online]. Available: https://doi.org/10.1007/978-3-319-27036-4_14
  * [8] M. Borowski, L. Murray, R. Bagge, J. B. Kristensen, A. Satyanarayan, and C. N. Klokmose, “Varv: Reprogrammable Interactive Software As a Declarative Data Structure,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2022, pp. 492:1–492:20. [Online]. Available: https://doi.org/10.1145/3491102.3502064
  * [9] W. C. Payne, Y. Bergner, M. E. West, C. Charp, R. B. B. Shapiro, D. A. Szafir, E. V. Taylor, and K. DesPortes, “danceon: Culturally responsive creative computing,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2021, pp. 1–16.
  * [10] F. Pezoa, J. L. Reutter, F. Suárez, M. Ugarte, and D. Vrgoc, “Foundations of JSON Schema,” in _International Conference on World Wide Web WWW_. ACM, 2016, pp. 263–273. [Online]. Available: https://doi.org/10.1145/2872427.2883029
  * [11] J. Jakubovic, J. Edwards, and T. Petricek, “Technical Dimensions of Programming Systems,” in _The Art, Science, and Engineering of Programming_ , vol. 7, no. 3, 2023. [Online]. Available: https://doi.org/10.22152/programming-journal.org/2023/7/13
  * [12] T. R. Green, “Cognitive Dimensions of Notations,” _People and computers V_ , pp. 443–460, 1989.
  * [13] W. Teitelman, “History of Interlisp,” in _Celebrating the 50th Anniversary of Lisp_ , ser. LISP50. ACM, 2008. [Online]. Available: https://doi.org/10.1145/1529966.1529971
  * [14] T. Teitelbaum and T. Reps, “The Cornell Program Synthesizer: A Syntax-Directed Programming Environment,” _Communications of the ACM_ , vol. 24, no. 9, p. 563–573, sep 1981. [Online]. Available: https://doi.org/10.1145/358746.358755
  * [15] M. Resnick, J. Maloney, A. Monroy-Hernández, N. Rusk, E. Eastmond, K. Brennan, A. Millner, E. Rosenbaum, J. Silver, B. Silverman _et al._ , “Scratch: Programming for All,” _Communications of the ACM_ , vol. 52, no. 11, pp. 60–67, 2009. [Online]. Available: https://doi.org/10.1145/1592761.1592779
  * [16] V. Pech, A. Shatalin, and M. Voelter, “Jetbrains MPS as a tool for extending java,” in _Proceedings of the International Conference on Principles and Practices of Programming on the Java Platform: Virtual Machines, Languages, and Tools_. ACM, 2013, pp. 165–168. [Online]. Available: https://doi.org/10.1145/2500828.2500846
  * [17] D. Moon, A. Blinn, and C. Omar, “Tylr: A tiny tile-based structure editor,” in _SIGPLAN International Workshop on Type-Driven Development_ , ser. TyDe 2022. ACM, 2022, pp. 28–37. [Online]. Available: https://doi.org/10.1145/3546196.3550164
  * [18] P. Voinov, M. Rigger, and Z. Su, “Forest: Structural code editing with multiple cursors,” in _SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software Onward!_ ACM, 2022, pp. 137–152. [Online]. Available: https://doi.org/10.1145/3563835.3567663
  * [19] T. Beckmann, P. Rein, S. Ramson, J. Bergsiek, and R. Hirschfeld, “Structured Editing for All: Deriving Usable Structured Editors From Grammars,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2023, pp. 595:1–595:16. [Online]. Available: https://doi.org/10.1145/3544548.3580785
  * [20] S. Lerner, “Projection Boxes: On-the-fly Reconfigurable Visualization for Live Programming,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2020, pp. 1–7. [Online]. Available: https://doi.org/10.1145/3313831.3376494
  * [21] J. Hoffswell, A. Satyanarayan, and J. Heer, “Augmenting code with in situ visualizations to aid program understanding,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2018, p. 1–12. [Online]. Available: https://doi.org/10.1145/3173574.3174106
  * [22] C. Gobert and M. Beaudouin-Lafon, “i-LaTeX: Manipulating Transitional Representations between LaTeX Code and Generated Documents,” in _Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems_ , ser. CHI ’22. ACM, 2022. [Online]. Available: https://doi.org/10.1145/3491102.3517494
  * [23] Y. Chuchem, “awesome-structure-editors,” 2022. [Online]. Available: https://github.com/yairchu/awesome-structure-editors
  * [24] A. J. Ko and B. A. Myers, “Citrus: a Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data,” in _Symposium on User Interface Software and Technology (UIST)_. ACM, 2005, pp. 3–12. [Online]. Available: https://doi.org/10.1145/1095034.1095037
  * [25] ——, “Barista: An Implementation Framework for Enabling New Tools, Interaction Techniques and Views in Code Editors,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2006, pp. 387–396. [Online]. Available: https://doi.org/10.1145/1124772.1124831
  * [26] C. Omar, Y. Yoon, T. D. LaToza, and B. A. Myers, “Active Code Completion,” in _International Conference on Software Engineering (ICSE)_. IEEE, 2012, pp. 859–869. [Online]. Available: https://doi.org/10.1109/ICSE.2012.6227133
  * [27] L. Andersen, M. Ballantyne, and M. Felleisen, “Adding Interactive Visual Syntax to Textual Code,” _International Conference on Object Oriented Programming Systems Languages & Applications OOPSLA_, vol. 4, pp. 222:1–222:28, 2020. [Online]. Available: https://doi.org/10.1145/3428290
  * [28] K. Ferdowsifard, A. Ordookhanians, H. Peleg, S. Lerner, and N. Polikarpova, “Small-Step Live Programming by Example,” in _Symposium on User Interface Software and Technology (UIST)_. ACM, 2020, pp. 614–626. [Online]. Available: https://doi.org/10.1145/3379337.3415869
  * [29] C. Omar, D. Moon, A. Blinn, I. Voysey, N. Collins, and R. Chugh, “Filling typed holes with live guis,” in _SIGPLAN International Conference on Programming Language Design and Implementation (PLDI)_. ACM, 2021, pp. 511–525. [Online]. Available: https://doi.org/10.1145/3453483.3454059
  * [30] J. Zong, D. Barnwal, R. Neogy, and A. Satyanarayan, “Lyra 2: Designing Interactive Visualizations by Demonstration,” _IEEE Transactions on Visualization and Computer Graphics_ , vol. 27, no. 2, pp. 304–314, 2021. [Online]. Available: https://doi.org/10.1109/TVCG.2020.3030367
  * [31] data.world, “Chart Builder.” [Online]. Available: https://github.com/datadotworld/chart-builder
  * [32] J. Hoffswell, W. Li, and Z. Liu, “Techniques for Flexible Responsive Visualization Design,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2020, pp. 1–13. [Online]. Available: https://doi.org/10.1145/3313831.3376777
  * [33] J. de Jong, “jsoneditor,” 2021. [Online]. Available: https://github.com/josdejong/jsoneditor
  * [34] C. Penner, “jet,” 2021. [Online]. Available: https://github.com/ChrisPenner/jet/
  * [35] Vega, “Editor/IDE for Vega and Vega-Lite.” [Online]. Available: https://vega.github.io/editor/
  * [36] G. Litt, “Runtime Visualization for Model-View-Update GUIs,” 2020. [Online]. Available: https://www.geoffreylitt.com/resources/todomvc-vis.pdf
  * [37] M. Travers, “Vaguely,” 2021. [Online]. Available: https://github.com/mtravers/vaguely
  * [38] E. Chavarriaga, F. Jurado, and F. D. Rodríguez, “An approach to build json-based domain specific languages solutions for web applications,” _Journal of Computer Languages_ , vol. 75, pp. 1–18, 2023. [Online]. Available: https://doi.org/10.1016/j.cola.2023.101203
  * [39] C. Petitpierre, “Bottom up creation of a DSL using templates and JSON,” in _SPLASH’11 Workshops - Compilation Proceedings of the Co-Located Workshops: DSM’11, TMC’11, AGERE!’11, AOOPES’11, NEAT’11, and VMIL’11_. ACM, 2011, pp. 47–52. [Online]. Available: https://doi.org/10.1145/2095050.2095059
  * [40] Microsoft, “vscode-json-languageservice,” 2021. [Online]. Available: https://github.com/microsoft/vscode-json-languageservice
  * [41] D. Marsh-Patrick, “deneb.” [Online]. Available: https://deneb-viz.github.io/visual-editor
  * [42] MongoDB Inc., “Compass. The GUI for MongoDB.” 2023. [Online]. Available: https://www.mongodb.com/products/compass
  * [43] K. Compton, “Tracery Editor,” 2021. [Online]. Available: http://tracery.io/editor/
  * [44] B. Whitworth, “Polite Computing,” _Behaviour & Information Technology_, vol. 24, no. 5, pp. 353–363, 2005. [Online]. Available: https://doi.org/10.1080/01449290512331333700
  * [45] plotly, “Chart Studio,” 2023. [Online]. Available: https://chart-studio.plotly.com/create/#/
  * [46] J. Hoffswell, A. Satyanarayan, and J. Heer, “Visual Debugging Techniques for Reactive Data Visualization,” in _Computer Graphics Forum_ , vol. 35, no. 3. Wiley Online Library, 2016, pp. 271–280. [Online]. Available: https://doi.org/10.1111/cgf.12903
  * [47] A. McNutt, G. Kindlmann, and M. Correll, “Surfacing visualization mirages,” _Conference on Human Factors in Computing Systems (CHI)_ , pp. 1–16, 2020\. [Online]. Available: https://doi.org/10.1145/3313831.3376420
  * [48] A. K. Hopkins, M. Correll, and A. Satyanarayan, “VisuaLint: Sketchy In Situ Annotations of Chart Construction Errors,” vol. 39, no. 3, 2020, pp. 219–228. [Online]. Available: https://doi.org/10.1111/cgf.13975
  * [49] Q. Chen, F. Sun, X. Xu, Z. Chen, J. Wang, and N. Cao, “VizLinter: A Linter and Fixer Framework for Data Visualization,” _IEEE Transactions on Visualization and Computer Graphics_ , vol. 28, no. 1, pp. 206–216, 2022. [Online]. Available: https://doi.org/10.1109/TVCG.2021.3114804
  * [50] A. McNutt and G. Kindlmann, “Linting for Visualization: Towards a Practical Automated Visualization Guidance System,” in _VisGuides: 2nd Workshop on the Creation, Curation, Critique and Conditioning of Principles and Guidelines in Visualization_ , 2018.
  * [51] A. McNutt and R. Chugh, “Integrated Visualization Editing via Parameterized Declarative Templates,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2021, pp. 1–14.
  * [52] M. Guzdial and T. Shreiner, “Integrating computing through task-specific programming for disciplinary relevance: Considerations and examples,” _Computational Thinking in Compulsory Education_ , 2021. [Online]. Available: http://dx.doi.org/10.4324/9781003102991-10
  * [53] J. Brandt, P. J. Guo, J. Lewenstein, M. Dontcheva, and S. R. Klemmer, “Two Studies of Opportunistic Programming: Interleaving Web Foraging, Learning, and Writing Code,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2009, pp. 1589–1598. [Online]. Available: https://doi.org/10.1145/1518701.1518944
  * [54] L. Grammel, C. Bennett, M. Tory, and M.-A. D. Storey, “A Survey of Visualization Construction User Interfaces,” in _EuroVis (Short Papers)_ , 2013. [Online]. Available: https://doi.org/10.2312/PE.EuroVisShort.EuroVisShort2013.019-023
  * [55] M. Haverbeke, “Code mirror: Extensible code editor,” 2023. [Online]. Available: https://codemirror.net/
  * [56] AJV, “Ajv JSON schema validator,” 2023. [Online]. Available: https://ajv.js.org/
  * [57] SchemaStore, “Json schema store.” [Online]. Available: https://github.com/schemastore/schemastore/
  * [58] S. Oney and J. Brandt, “Codelets: Linking interactive documentation and example code in the editor,” in _Conference on Human Factors in Computing Systems (CHI)_ , ser. CHI ’12. ACM, 2012, pp. 2697–2706. [Online]. Available: https://doi.org/10.1145/2207676.2208664
  * [59] X. Rong, S. Yan, S. Oney, M. Dontcheva, and E. Adar, “Codemend: Assisting Interactive Programming with Bimodal Embedding,” in _Symposium on User Interface Software and Technology (UIST)_. ACM, 2016, pp. 247–258. [Online]. Available: https://doi.org/10.1145/2984511.2984544
  * [60] P. Goffin, J. Boy, W. Willett, and P. Isenberg, “An Exploratory Study of Word-scale Graphics in Data-rich Text Documents,” _IEEE Transactions on Visualization and Computer Graphics_ , vol. 23, no. 10, pp. 2275–2287, 2017\. [Online]. Available: https://doi.org/10.1109/TVCG.2016.2618797
  * [61] B. Naimipour, M. Guzdial, and T. Shreiner, “Engaging Pre-service Teachers in Front-end Design: Developing Technology for a Social Studies Classroom,” in _Frontiers in Education Conference_. IEEE, 2020, pp. 1–9. [Online]. Available: https://doi.org/10.1109/FIE44824.2020.9273908
  * [62] T. Nelson-Fromm, “Creating Better Teaching Tools Through Examining Teachers’ Understanding of Data Representations,” in _Symposium on Visual Languages and Human-Centric Computing (VL/HCC)_. IEEE, 2021, pp. 1–2. [Online]. Available: https://doi.org/10.1109/VL/HCC51201.2021.9576206
  * [63] K. Wongsuphasawat, Z. Qu, D. Moritz, R. Chang, F. Ouk, A. Anand, J. Mackinlay, B. Howe, and J. Heer, “Voyager 2: Augmenting Visual Analysis with Partial View Specifications,” in _Conference on Human Factors in Computing Systems (CHI)_. ACM, 2017, pp. 2648–2659. [Online]. Available: https://doi.org/10.1145/3025453.3025768
  * [64] M. Fowler, _Domain-specific languages_. Pearson Education, 2010.
  * [65] S. Barke, M. B. James, and N. Polikarpova, “Grounded copilot: How programmers interact with code-generating models,” _International Conference on Object Oriented Programming Systems Languages & Applications OOPSLA_, vol. 7, no. OOPSLA1, pp. 85–111, 2023. [Online]. Available: https://doi.org/10.1145/3586030
  * [66] A. Blinn, D. Moon, E. Griffis, and C. Omar, “An Integrative Human-Centered Architecture for Interactive Programming Assistants,” in _Symposium on Visual Languages and Human-Centric Computing (VL/HCC)_. IEEE, 2022, pp. 1–5. [Online]. Available: https://doi.org/10.1109/VL/HCC53370.2022.9833110
  * [67] K. Compton, “tweet,” May 2022, https://twitter.com/GalaxyKate/status/1528109593187975168?s=20 content:
Thanks to my Patreon supporters, today you paid for 30 Chicago middle school
girls to learn Tracery, I guess.

  * [68] M. Beaudouin-Lafon, “Designing Interaction, Not Interfaces,” in _Workshop Conference on Advanced Visual Interfaces (AVI)_. ACM, 2004. [Online]. Available: https://doi.org/10.1145/989863.989865
  * [69] Microsoft, “node-jsonc-parser.” [Online]. Available: https://github.com/microsoft/node-jsonc-parser
  * [70] S. Gathani, P. Lim, and L. Battle, “Debugging database queries: A survey of tools, techniques, and users,” in _Conference on Human Factors in Computing Systems (CHI)_ , ser. CHI ’20. ACM, 2020, pp. 1–16. [Online]. Available: https://doi.org/10.1145/3313831.3376485
  * [71] L. Shen, E. Shen, Z. Tai, Y. Wang, Y. Luo, and J. Wang, “GALVIS: Visualization Construction through Example-Powered Declarative Programming,” in _International Conference on Information & Knowledge Management_. ACM, 2022, pp. 4975–4979. [Online]. Available: https://doi.org/10.1145/3511808.3557159
  * [72] T. Berger, M. Völter, H. P. Jensen, T. Dangprasert, and J. Siegmund, “Efficiency of Projectional Editing: A Controlled Experiment,” in _SIGSOFT International Symposium on Foundations of Software Engineering_. ACM, 2016, pp. 763–774. [Online]. Available: https://doi.org/10.1145/2950290.2950315
  * [73] S. Chodarev, M. Sulír, J. Porubän, and M. Kopčáková, “Experimental comparison of editor types for domain-specific languages,” _Applied Sciences_ , vol. 12, no. 19, 2022. [Online]. Available: https://www.mdpi.com/2076-3417/12/19/9893
  * [74] A. Satyanarayan, B. Lee, D. Ren, J. Heer, J. T. Stasko, J. Thompson, M. Brehmer, and Z. Liu, “Critical Reflections on Visualization Authoring Systems,” _IEEE Transactions on Visualization and Computer Graphics_ , vol. 26, no. 1, pp. 461–471, 2020. [Online]. Available: https://doi.org/10.1109/TVCG.2019.2934281
  * [75] M. Sulír, M. Bačíková, S. Chodarev, and J. Porubän, “Visual augmentation of source code editors: A systematic mapping study,” _Journal of Visual Languages & Computing_, vol. 49, pp. 46–59, 2018.
  * [76] Stackoverflow, “JSON schema : “allof” with “additionalProperties”,” 2015\. [Online]. Available: https://stackoverflow.com/questions/22689900/json-schema-allof-with-additionalproperties
  * [77] M. A. Baazizi, D. Colazzo, G. Ghelli, C. Sartiani, and S. Scherzinger, “An Empirical Study on the ”Usage of Not” in Real-world JSON Schema Documents,” in _International Conference on Conceptual Modeling_ , vol. 13011. Springer, 2021, pp. 102–112. [Online]. Available: https://doi.org/10.1007/978-3-030-89022-3_9
  * [78] YousefED, “typescript-json-schema.” [Online]. Available: https://github.com/YousefED/typescript-json-schema
  * [79] apioo, “TypeSchema.” [Online]. Available: https://typeschema.org/
  * [80] M. J. Lobo, C. Hurter, and P. Irani, “Flex-er: A platform to evaluate interaction techniques for immersive visualizations,” _Human-Computer Interaction_ , vol. 4, no. ISS, nov 2020. [Online]. Available: https://doi.org/10.1145/3427323