Hello, my name is Marcel Borowski and I am presenting the paper
“Varv: Reprogrammable Interactive Software as a Declarative Data Structure.”
This was a joint effort between me and my co-authors Luke Murray, Rolf Bagge,
Janus Bager Kristensen, Arvind Satyanarayan, and Clemens Klokmose.
Today’s software usually comes in the form of applications.
Applications are constructed as packaged and turn-key products.
This, as a result, gives end-users only little room to modify their own applications
in order to match them to their own needs.
Even for trained programmers it is often difficult to modify their tools.
For example, in Google Tasks, which is part of Gmail, I can create tasks related to my emails.
A task consists of a title, a description and a due date.
However, I cannot assign a task to someone else or add labels to tasks, like I can do to my emails.
Even adding such simple features in today’s software model is either impossible or would require significant effort.
As a response, we present Varv, a declarative language for reprogrammable interactive software
that decouples specification from execution, and is inherently extensible by the end-user.
Changes to code are immediately applied, and enable a live programming experience and collaboration.
The design of the Varv language is motivated by three design goals.
First, we wanted to provide a structured and declarative representation.
Declarative programming allows users to focus on the definition of interaction behavior, the “what”,
while the system takes care of the implementation, the “how.”
Varv achieves this goal by using declarative constructs written in JSON
to define the interactive behavior of an application.
Second, we wanted to make software accretively extensible.
This means that interactive behavior can be modified through incremental addition
without having to change the original code of an application.
In Varv, any application can be extended by adding a new definition file,
which can be used to add new or overwrite existing interactive behavior.
And, third, we wanted to decouple application logic from interaction modalities.
Existing methods of specifying interactive behavior often rely on callbacks
to tightly couple an input event, such as a click or a key press, with an action.
Retargeting an application, therefore, often requires significant manual effort.
Varv, instead, decouples these two pieces.
The Varv language is expressed in JSON.
Concepts are the core building blocks of Varv.
They define individual named units of interactive behavior,
for instance, a “todo list” and a “todo item.”
A concept contains schema and actions.
The schema of a concept defines the shape and type of data associated with a concept.
It does this in the form of properties.
Properties can be either of a primitive data type such as a string or a number,
or they can be a reference to another concept.
For example, the “todos” property in the “todoList” concept
is an array of “todo” concept instances.
Actions, in the next step, provide an abstraction for state transformations.
Actions are named and consist of a when-block and a then-block.
The when-block defines an array of triggers that cause the then-block to be executed
whenever one of the triggers emits an event.
Triggers can be either reactive like in the “updateCompletedCount” action,
or received from the view, like the click on the “toggleCompleted” action.
The then-block of an action can also refer to other actions,
making it possible to nest actions inside each other or to create recursive actions.
Lastly, being extensible is an essential part of the language design.
Varv allows two ways of extensions.
The first method is the merging and overwriting of JSON keys with another definition file.
This makes it possible to add or overwrite behavior without having to modify the existing code.
This works similar to how CSS rules can be overwritten.
For instance, we can create a second concept definition file,
in which we move the when-block of the “toggleCompleted” action.
The Varv event engine then merges the two files and combines
the then-block of the first definition with the when-block of the second definition.
The other way of extending concepts is through the use of one of the four
extension mechanisms “inject”, “join”, “omit” or “pick.”
In this example, we use the “join” extension to merge the two concepts
“todo” and “assignable” to create a new “assignableTodo” concept.
Our main implementation of Varv builds on top of the Webstrates and Codestrates platforms.
It runs purely on the client-side in a web browser and is implemented in JavaScript.
Webstrates is a platform for creating reprogrammable and collaborative software on the web.
Webstrates synchronizes and persists the DOM of a website with a server.
This makes it possible to store concept definitions in the DOM
and, in doing that, making them collaboratively editable.
Besides our main implementation, we also created two proof-of-concept implementations of Varv
using Electron and Observable, which are independent of Webstrates.
This short example demonstrates how an existing collaborative todo list application
created with Varv can be extended in only two steps.
In this example we want to add an “Assigning” feature to todos.
Similar to the one we missed in Google Tasks example earlier.
First, we have to create a new property in the todo concept.
To do this, we first have to open Webstrates’ built-in authoring environment Cauldron.
In Cauldron, we create a new concept definition and add the code
to add the property “assignee” to the todo concept.
In the inspector of Cauldron, we can check whether the property is part of the todo concept now.
Second, we need to display the property in the view.
We do this by creating a new template file and copy the existing todo template over.
We add an input field and set its value to the “assignee” property and we are done.
While we edit the template, changes are immediately updated in the application.
To explore the expressiveness of Varv, we also created other applications like a board game toolkit.
The toolkit consisted of a set of actions like “piecePicked” or “turnSwitched.”
These actions allowed us to create both the Checkers and Othello board games
using the same underlying set of actions and even combine the rules of both games with little effort.
Besides this, we also created an UI designer app similar to Figma.
It lets users create screens of an interface design with elements like buttons on it.
Elements can be moved and resized with the mouse cursor, and can link to other screens.
In the preview mode, interactions can then be tested.
Lastly, we explored new ways of tooling that were enabled by the structured declarative representation
such as a view inspector that makes it possible to inspect concept instances
and their interactive behavior in the user interface.
In our paper, we evaluated the feasibility and expressivity of Varv
through demonstration using case studies and examples.
Future work is needed to evaluate Varv’s usability in a user study.
Through the examples we built with Varv we have also demonstrated
that the ceiling for what can be achieved with Varv is high,
however, we do not clearly know its bounds in terms of expressivity or performance.
Future work on this could involve comparative benchmark studies
or the implementation of more challenging graphical user interfaces.
Lastly, by representing interactive software as a data structure,
Varv makes it possible to programmatically reason about the composition of applications.
This information could be used to analyze interactive behavior
in order to programatically autocomplete or recommend interaction designs.
With Varv we have demonstrated that a declarative approach
to specifying interactive applications as data structure
is not only possible, but also provides a range of powerful capabilities.
We hope that Varv inspires future research
to enable also non-programmers to develop interactive software.