Uvis: A Formula-Based End-User Tool for Data Visualization

Existing approaches to data visualization are one of these two: accessible to end-user developers but limited in customizability, or inaccessible and expressive. For instance, commercial charting tools are easy to use, but support only predefined visualizations, while programmatic visualization tools support custom visualizations, but require advanced programming skills. We show that it is possible to combine the learnability of charting tools and the expressiveness of visualization tools. Uvis is an interactive visualization and user interface design tool that targets end-user developers with skills comparable to spreadsheet formulas. With Uvis, designers drag and drop visual objects, set visual properties to formulas, and see the result immediately. The formulas are declarative and similar to spreadsheet formulas. The formulas compute the property values and can refer to data from database, visual objects, and end-user input. To substantiate our claim, we compared Uvis with popular visualization tools. Further, we conducted usability studies that test the ability of designers to customize visualizations with our approach. Our results show that end-user developers can learn the basics of Uvis relatively fast.


I. INTRODUCTION
Data visualization aims at supporting human abilities by showing data using visual variables such as position, color, size, and orientation [1]. The insights of data visualization can be applied in many fields such as healthcare, finance, and agriculture.
Charting tools allow designers to build a visualization by selecting predefined visualization templates and mapping them to data. Designers can adjust the visual properties to a limited extent. This approach improves learnability (learning how to build a visualization) as well as task efficiency (building it fast). However, it lacks expressiveness (customizing the visualization to specific needs). Data analysis tools such as Tableau and its predecessor Polaris [2] integrate well with existing data and help users explore the data. They do not require programming skills. However, like charting tools, there is no way to create visualizations beyond what is predefined. Visualization tools such as Lyra [5], iVisDesigner [6], and Data Illustrator [24] allow the creation of custom visualizations without real programming. These tools are more The associate editor coordinating the review of this manuscript and approving it for publication was Gianmaria Silvello . flexible than charting tools. Nevertheless, they are limited in expressiveness. For instance, they use predefined layouts and visual properties that cannot refer to other visual properties or end-user input. Further, it is not possible to create interactive visualizations with these tools.
Designers may resort to programmatic visualization tools and libraries such as D3 [3] and Vega [12] to accomplish their objective. While such tools offer high visualization expressiveness, they require programming skills accessible to technical audience.
Despite the diversity of existing visualization tools, there is still a gap between tools that are accessible to end users, but limited in expressiveness, and tools that are expressive but only accessible to professional programmers.
We contribute Uvis, a visualization tool aimed at enduser developers who have development skills comparable to spreadsheet formulas, but no training in programming. Uvis allows designers to drag and drop visual objects and specify declarative formulas for the visual object properties. A formula computes the value of a property, and can refer to data from databases, visual objects, and end-user input.
To assess expressiveness, we created a collection of visualizations. Furthermore, we compared Uvis with popular visualization tools such as D3 [3] and Vega [12]. To assess learnability and efficiency, we conducted usability studies with designers. Our results show that Uvis has high expressiveness, and its basic principles can be rapidly learned by designers with IT skills akin to spreadsheet formulas. Part of this work is based on Kuhail's thesis from the IT University of Copenhagen [27].
In a previous work [33], we proposed designing visual objects for construction of time-oriented visualizations. The work covered a small part of Uvis principles, and only focused on expressing time-oriented visualizations. Further, the work was not mature enough to be evaluated with users and to be compared with other tools such as D3 and Vega.

II. RELATED WORK
We divide approaches to data visualization and user interface design into two categories: tools aimed at non-programmers (charting tools, data analytical tools, and visualization tools), and tools for designers with programming skills (visualization toolkits and programming languages).

A. NON-PROGRAMMER TOOLS 1) CHARTING TOOLS
Charting tools such as Microsoft Excel, RAWGraphs [40], Flourish [42], and Infogram [43] allow designers to create visualizations with predefined templates. Limited customization is possible. For instance, designers can change appearance properties such as color, text formatting, etc. This approach is accessible to non-programmers, but does not support custom visualizations. Designers do not have sufficient control over the building blocks of the visualization. For instance, not all the visual properties of the visual objects are available for modification.

2) DATA ANALYTICAL AND EXPLORATORY TOOLS
Data analytical and exploratory tools such as Tableau [44], Polaris [2], Spotfire [45] and Omni-scope [46] integrate well with existing data and help users explore the data. Despite the expressive power of these tools compared to charting tools, control over graphical output is still limited, making them unsuitable for novel custom visualizations.
Lyra [5] allows designers to specify visual attributes with mathematical expressions that refer to data fields. However, the expressions are limited. For instance, they cannot refer to other visual properties. Further, it is not possible to create a dynamic visualization with Lyra. For instance, dynamic queries [4] are not supported. To cite an example, it is not possible to add filters that allow for data exploration based on user input.
iVisDesigner [6] allows designers to develop visualizations of complex predefined layouts. Designers can drag and drop visual objects, bind visual properties to data or constant numbers. Despite the power of this approach, the visualization specifications are limited. For instance, designers cannot bind a visual property to a mathematical expression that refers to data and other visual properties. Further, it is not possible to implement interaction beyond what is predefined.
VisComposer [7] allows designers to connect modules together to transform the data. Further, designers can use blocks of code to extend their visualizations with custom behavior. This approach may be accessible to end-user developers, but real programming is needed for high expressiveness.
Data Illustrator [24] uses a ''lazy data binding'' approach. Designers use familiar tools to draw their visualizations without underlying specifications. Later, designers apply data encoding when it is necessary. This approach gives flexibility to designers. However, similar to the other tools, expressiveness is still limited as designers cannot specify visual variables with expressions. Moreover, it is not possible to design interactive visualizations.
DataInk [8] supports creation of visualizations with direct manipulation via direct pen and touch input. Designers design their own glyphs, and map their visual attributes to data. This approach combines the power of data visualization and graphic design tools. Nevertheless, the visualizations produced are static, and expressiveness is limited.
Charticulator allows designers to create charts of different layouts such as parallel coordinates [10] and coxcomb charts [47]. However, like the other tools, it is hard for designers to create a custom visualization with a layout beyond what is predefined. Further, Charticulator does not support interactive visualizations.
In conclusion, these tools are innovative, and designed to be accessible to a wider audience than programmatic tools. However, according to a survey study [31], these tools do not allow high customization. As an example, these tools are not able to make visualizations such as LifeLines [25]. This visualization requires dynamic queries [4], user interaction, showing data from various tables, and showing relationships between data entities.

B. PROGRAMMER TOOLS 1) VISUALIZATION TOOLKITS
Visualization toolkits allow designers to construct traditional and new visualizations by means of domain-specific programming languages tailored for visualization. Examples are Protovis [11], D3 [3], Prefuse [15], and Improvise [16]. The approaches of these tools vary from imperative to declarative programming. However, designers may still need to implement program-like specifications. For instance, designers need to declare variables, program functions, etc. Consequently, the gap between the objective (what the designer wants to accomplish) and the solution (how the designer accomplishes the objective) remains high. This is described by Norman as the gulf of execution [17].
Vega [12] is a declarative language for creating, saving, and sharing interactive visualization design. Vega does not require developers to write the visualization specifications in a certain sequence. To support interaction, the tool allows developers to write imperative statements as event handlers. To enable custom calculations, Vega uses its own expression language for writing basic formulas. The expressions can refer to data from a dataset as well as event data. However, the expressions have limitations. For instance, they cannot directly refer to aggregate functions (e.g. sum, max). Data transformations must be made first. Further, the expressions cannot refer to visual properties. This limits the designer's ability to create custom layouts by aligning different visual objects in ways beyond what's predefined. Built on Vega, Vega-lite [13] provides a high-level grammar that enables the concise specification of interactive data visualizations. Vega-lite specifications are shorter than Vega. However, it is less expressive. For instance, Vega-lite does not support custom and specific interaction techniques.
Atom [14] is a high-level grammar for unit visualizations, visualization where every data item is shown by a distinct visual object (a visual unit). Atom maps each visual object to one data item. Some visual properties such as fill color can visualize data. Atom can express a variety of unit visualizations. However, expressiveness is limited. For instance, visual properties cannot be specified with expressions. Further, position properties are determined based on layout definition. Such limits make Atom unsuited for making data visualizations such as LifeLines [25] where visual objects show relationships between data entities by being aligned to other visual objects showing related data. Besides that, Atom does not support interactivity. Therefore, implementing interaction such as dynamic queries [4] is not possible with Atom.

2) GRAPHICAL LIBRARIES
Graphical libraries such as GDI+ [38] and Java 2D [39] are available for many programming languages. They provide basic components such as polygon, textbox and drop-down box. By means of a program, you can create any visualization, bind to any data and perform any interaction. The program can be integrated with development environments that allow programmers to build a user interface. The environments use the visual builder approach [22]. Programmers manually drag and drop graphical components (buttons, text boxes, etc.) and set their properties. However, programming is needed to make the interface functional.

III. DESIGN
In designing Uvis, we started with a simple idea: Let each visual property be like a spreadsheet cell with a formula. It turned out that with this simple approach, the designer does not need to know programming concepts such as variables, loops, and recursion, allowing designers to focus on piecing together visual objects using formulas. The latest version of Uvis can be found in [37].
This work proposes the Uvis approach that consists of four elements: a development environment, general-purpose visual objects, formulas, and documentation. The development environment, shown in Figure 1, consists of six panels: (A) The form being designed, (B) Property grid, (C) Error list, (D) Data map, (E) Toolbox, (F) Visualization specification files, and (G) Data view. All the panels are movable. The visual form (A) contains the visualization the designer is currently building. The property grid (B) allows the designer to change the properties of a visual object. The error list (C) lists the errors in the formulas. The data map (D) shows the structure of the data the designer wants to show. The toolbox (E) is a list of the available visual objects. The visualization specifications (F) are saved as .vis files. The data view (G) shows a sample of the data in the data model. Uvis uses a small collection of visual objects including well-known components such as ellipses, bars, splines, pie slices, and labels.
Visual objects can be bound to a data source. As a result, one visual object is created for each row in the data source. However, if a visual object is not connected to data, only one instance of the object is created. A visual property may be constant or a formula.
Formulas are declarative spreadsheet-like expressions. The formulas can refer to data fields, visual properties, and functions.
The Uvis documentation is a tutorial that walks the designer stepwise through the main Uvis concepts. It contains various examples. Discussing the documentation is outside of the scope of this paper. The details of the documentation can be found at [48].
In the following subsections, we will discuss the fundamental elements of Uvis: Uvis development environment, visual objects, and declarative formulas.

A. DEVELOPMENT ENVIRONMENT
The Uvis development environment ( Figure 1) is a What-You See-Is-What-You-Get (WYSIWYG) visual builder where the designer drags visual objects to the user screen and defines the properties of the components. When the designer changes a property specification, the formulas of all properties are recomputed, and the screen is refreshed. Myers et al. [18] gave an overview of user interface tools and explained why visual builders (called interface builders in the paper) were much more successful with local developers than program-based tools. Besides the traditional visual builder features, we incorporated features that support the design process. As an example, when the designer selects a visual object, the property grid shows the properties, formulas, and computed values of the properties ( Figure 1B). This allows designers to inspect all properties of the visual object [34]. As another example of assisting designers, we show the data map ( Figure 1D) as well as data view ( Figure 1G). Since  (available upon clicking the ptDiagonsis table).
designers may design a visualization of data coming from several data tables, it is essential to show the data tables and the relationships between them. The model is a traditional Entity-Relationship diagram (E-R diagram) [23]. Admittedly, some designers may not be familiar with E-R diagrams. Uvis documentation [48] explains the principles of E-R diagrams. The Table view panel (G) shows a sample of the data when the designer clicks a table in the data model. Exploring the data in that manner helps designers make sense of data particularly if the data have names that are not self-explanatory. Research showed that novice designers relate to data using concrete values rather than field names [19], [20].
The design of the development environment is the result of usability studies and expert feedback. The details of the usability studies to improve the environment are discussed in [27]. Earlier versions of the environment such as [35] were more primitive.

B. VISUAL OBJECTS
Visual objects are the building blocks of a visualization. Figure 2 shows examples of the visual objects Uvis provides. Unlike many existing visualization tools, Uvis supports standard UI elements (e.g. Button, Textbox, etc.) that allow for interaction. Furthermore, Uvis includes geometric shapes such as Triangle, Ellipse, etc. They are inspired by Cleveland [21] recommendations, and can be used to show data as position, color, orientation, etc. Moreover, we designed specialized objects that are commonly used in visualizations. For example, HTimeScale is a time scale that shows multiple periods of time horizontally. Designers can let a property refer to a time scale and get the pixel position corresponding to a point in time. Further, the time scale is an interactive object that allows users to navigate through time by dragging the scale. As another example, Spiral allows designers to show cyclic time-oriented data on a spiral.
All visual objects have these common properties: Rows, Parent, Canvas, Top, Left, Bottom, Right, Height, Width, BackColor, and BorderColor. The Rows property binds visual objects to data. The Parent property specifies the parent element. This property allows formulas in child elements to refer to data and visual properties in parent elements. The Canvas property specifies the panel on which the object is placed. By default, it is where the designer has dragged the object. Top, Left, Bottom, and Right properties position visual objects. Height and Width are the usual size properties. BackColor and BorderColor are properties that specify the background and border color respectively. Specialized objects such as HTimeScale have special properties such as BorderValues, which determines the periods of time that are covered by the object. Moreover, designers can add their own designer properties. They can compute values that other properties refer to.
To improve task efficiency without compromising expressiveness, some visual objects provide default formulas that cater for common cases. These formulas are still changeable by the designers if they want a different appearance or behavior. For instance, the StartAngle of a PieSlice object has a default formula ( Figure 3).

C. DECLARATIVE FORMULAS
Uvis formulas are inspired by spreadsheet formulas, which have been successful with end-user developers [18]. Uvis formulas are declarative since they specify what the result of the computation should be rather than how it should be done, and where the result should be stored. Further, they are sequence-free, and do not have loops. Uvis formulas may refer to data fields and visual properties. When a visual object is bound to a data row, the formula refers to the data fields of the row as if they were properties of the component. However, Uvis must be able to handle any field or table name found in the database. A field may for instance be called BackColor, which is also a built-in property name. To resolve this ambiguity, Uvis uses dot (.) for data fields and bang (!) for visual properties and other Uvis names. The following subsections will explain Uvis formulas via two examples. Figure 4 illustrates Uvis basic formulas with a bar chart representing sales over the course of six months. This example illustrates a detail-on-demand interaction style [26] as users can see the sales amount as well as the month upon clicking a bar. The bars are made with a Box (SalesBox). The Rows formula binds SalesBox to data in the Sales table. The data is ordered by the sales amount in ascending order. The result of data binding is that Uvis creates an instance of SalesBox for each data row. The Left formula calculates the left position of the bars in such a way that they are spaced 5 pixels apart. The Height formula takes the sales amount and divides it by 1000 to get the height. Upon clicking a box, the visibility of a child label on top (AmountLabel) is toggled. AccountLabel is positioned to be on top of its parent (SalesBox) using the Bottom property. The labels are initially invisible (Visible is set to be false). The init keyword indicates that the value is changeable.

1) UVIS BASIC FORMULAS
2) DATA NAVIGATION AND CONDITIONALS Figure 5 shows a visualization of patient information inspired by LifeLines [25]. The visualization shows physician notes of patient health and diagnoses mapped to a time scale. The time scale shows three different periods of time of different zoom levels. The data model of the data behind the table is on the top right of the figure. Even for a professional developer, it would be time consuming and challenging to implement such a visualization. With Uvis, it is possible to build it with declarative formulas and two imperative formulas to make it interactive. For space reasons, Figure 5 shows only the interesting formulas.
The Rows formula of label ptLabel (Component A, Figure 5) connects the label to the record of the patient whose ID is the value of ptIDText (Component D, Figure 5). The Rows formula of ptNoteTitle (Component B, Figure 5) joins the parent table (Patient with a selected ID) with the ptNote table.
Uvis uses the operators >-and -< to specify a join between two database tables. A >-B is a left join where we start in A and extend it with a matching B (nulls if there isn't any). A -< B is a right join where we start with B. Uvis also supports inner joins, such as A =< B, where rows are included only where there is a match.
We have chosen -< and >-because they resemble the crow's foot notation in E-R diagrams.
In order to vertically align ptTriangle objects (Component C, Figure 5) with the related ptNoteTitle objects (Component B, Figure 5), the designer needs to let ptTriangle objects find the related ptNoteTitle objects. To that end, the designer added a designer property, noteTitle, in the ptTriangle formula specifications. This property finds the related ptNoteTitle objects using the Find operator. Aligning the ptTriangle objects now is just a matter of setting the Top property to be equal to the Top of noteTitle.
This example shows that Uvis formulas alone allowed for a custom layout due to cross-referencing, the ability of formulas to refer to properties of other visual objects.
To make the background color of the ptTriangle objects represent note warning, the designer used the Choose function known from Visual Basic.

3) USER INTERACTION
To interact with the visualization, the end-user types the patient ID into the textbox ptIDText (Component D, Figure 5). When done, Uvis executes the FocusLost event handler, which asks Uvis to refresh the screen. As a result, Uvis recomputes the formulas, retrieves the information of the patient with that ID, and displays her information on the screen. This is an example of a dynamic query [4].
As another example of interaction, the user can drag the time scale to the right or the left to focus or get an overview of a specific period of time. This interaction style is inspited by the Visual Information-Seeking Mantra: overview first, zoom and filter, then details on demand [26].
timeScale (Component E, Figure 5) shows three periods of time defined by BorderValues. The first period covers the duration between the patient birth until the second of January 2015. The second one ends on the twentieth of January 2015, and the third ends today. Each of the periods is shown in a ribbon, specified by BorderPixels.  much space each period is taking up. When the user interacts with the time scale, BordersChanged is triggered, and as a result, the formulas will be recomputed, and the screen will be updated.
The designer has mapped the time of the patient notes (ptTriangle objects) to the time scale using the HPos function of the time scale. This function calculates the pixel location of the patient note time. When the user interacts with the time scale, the event handler BordersChanged will ask to refresh the screen. As a result, the patient note triangles will be repositioned.

IV. EVALUATION
Uvis was designed to be an expressive, task efficient, and learnable visualization tool. To assess expressiveness, we built a variety of applications. Furthermore, we compared Uvis with popular visualization tools such as D3 [3] and Vega [12]. To assess learnability and efficiency, we conducted usability studies with designers. Our results show that Uvis has high expressiveness, and its basic principles can be rapidly learned by designers with IT skills akin to spreadsheet formulas.
A. EXPRESSIVENESS AND LIMITATIONS Figure 6 shows example visualizations built with Uvis. The visualizations are fully explained in [27]. Other visualizations can be found in [33]. Table 1 shows an overview of these visualizations. Different data transformations (e.g. filtering, joining, sorting) have been performed to create the visualizations. Further, different types of formulas have been used to create the visualizations. The visualizations show different characteristics and interaction styles. For instance, some have a radial layout whereas others have a linear one. Interaction-wise, some visualizations are based on the details-on-demand metaphor [26], and others allow end-user dynamic queries [4]. The examples are not novel visualizations, but illustrate the expressiveness of Uvis formulas. We have also created other visualizations such as Circle-View [29] and Horizon Graph [41]. Some of the visualizations were created using only primitive visual objects. For instance, the visualization inspired by CircleView [29] was created using PieSlice objects. Other visualizations such as Horizon Graph required a specialized object (Area).
Despite resembling visualizations created with templatebased tools such as Tableau, the visualizations in Figure 6 cannot be easily made with template-based tools. Most of the visualizations are based on combining multiple relational tables whereas template-based visualizations are typically based on single datasets. Further, with Uvis, designers have the freedom to customize the interactivity and appearance of the visualizations in a way that is not possible in template-based tools.
Uvis expressiveness depends on four main principles: Rows formula, visual property formula, utility functions, and visual objects. Table 2 shows examples of what formulas can refer to. Uvis compiler only selects the fields that are used by the formulas. In this case, only ptNote.Title was selected because it was used in the Text property formula. Further, the ON specifications were extracted from the data map (a file that describes the primary and foreign keys of tables).
Some advanced visualizations need sorting and grouping data transformations. Such transformations would require designers to use SQL-like operators such as Order By and Group By. Designers would need to learn such skills prior to attempting such advanced visualizations.
The visual property formulas are expressions similar to spreadsheet formulas, but they can refer to utility functions, visual properties, visual object functions, and fields of any visual object connected to data with a different Rows formula. For a complete reference of Uvis formulas, see the Uvis reference card [36].
Utility functions resemble Visual Basic and spreadsheet functions. For instance, the regular math and aggregation functions are available.
Visual objects provide functions the formulas can call. For instance, formulas can call the HPos function of HTimeScale objects.
Despite the expressive power of Uvis formulas, they have the inherent limitations of declarative formulas. For example, Uvis formulas alone do not support visualizations that require recursive algorithms. Such algorithms contain loops and/or functions that call themselves recursively until a condition is met. Uvis formulas support recursion if it is within the context of existing visual objects. Consider the following formula for a designer Property TotalHeight: index=0? Height : Me[index-1] !TotalHeight + Height This is an example of a conditional formula using the ternary operator known from JavaScript and other languages. The formula means if index is equal to zero (first object in the bundle), the value will be the Height value. Otherwise, it will be the previous object's TotalHeight added to the Height values. This results in the sum of Height values in a bundle of visual objects. This is an example of recursion that Uvis formulas allow. However, Uvis formulas and primitive visual objects alone cannot support a visualization such as Tree maps which requires a recursive algorithm. A possible solution is to provide a visual object that performs these complex layout algorithms. Pantazos developed a TreeMap visual object that supports a tree map visualization with Uvis formulas [28].
Another limitation of Uvis formulas is the inability to create visual objects recursively: For instance, Uvis formulas fall short if we want to show a recursive tree-like structure, for instance a folder tree. Since Uvis uses SQL-like formulas, it inherits SQL limitations. For instance, it is not possible to VOLUME 8, 2020 send a query that retrieves the nesting levels of the folders. As a result, it is not possible to create a recursive tree with Uvis formulas because new visual objects must be defined for each level in the tree. A possible solution is to create a specialized visual object that implements the recursive layout.

B. COMPARATIVE ANALYSIS
We selected two popular visualization tools to compare with Uvis: D3 [3] and Vega [12]. The tools were selected because they support custom visualizations, have high citations, and a different approach to visualization construction. For a comparative analysis with other tools, consult [32].
We excluded Protovis [11] as it is the predecessor of D3 [3], and is no longer active. We excluded Vega-lite [13] as it is based on Vega, and is intended for high-level visualization grammar. Moreover, the selected tools were ranked based on the total number of citations on ACM Portal and IEEE website. In a previous work [32], we compared Uvis with other tools such as Prefuse [15] and Improvise [16].
We implemented a custom scatterplot (Figure 7) with the selected tools as well as with Uvis. The scatterplot shows the daily maximum of temperature in a given city in a certain period of time. The circles represent the readings. If the circle is showing the highest temperature in the given period, it is black. Otherwise, if the circle is showing a temperature greater than 25, it is red. The rest of the circles are orange. Although the example is relatively simple, it is a custom scatterplot, and not a standard scatterplot that can be easily made with charting tools. Further, all the tools support it with their language design and visual objects. We were careful not to select a more advanced example as it may be too lengthy and tedious to follow, and it may favor one tool over the others.
To sum up, D3 visualization specifications are programlike. Variables and anonymous functions are defined. Further, the instructions are written and executed in sequence. D3 provides non-visual scale classes that facilitate the construction of axes. The axes are not defined directly. Instead, primitive axis objects are used for drawing the axes. This separation increases flexibility (e.g designers might define a custom axis in this way), but increases the steps of such a common task. D3 uses declarative expressions to specify the Circle visual objects.
Vega uses a declarative approach to visualization specifications. Unlike D3, Vega does not require the specifications to be written in a certain sequence. Vega requires data transformations to be explicitly specified for extracting aggregate functions such as max, min, sum, and average. Like D3, Vega uses non-visual scale classes that facilitate the construction of axes. The visual axes are defined separately. To define a formula-like expression, designers need to use a signal, a dynamic variable that parameterizes a visualization.
3) UVIS Figure 10 shows the specifications of the custom scatterplot with Uvis. To create the time and numeric axes, the designer dragged HTimeScale and VNumericScale visual objects from the toolbox and dropped them on a form. The designer moved and resized them until they looked satisfactory. Uvis sets position properties (i.e. Top, Height, etc.) accordingly. To define the range of time and numbers the scales show, the designer typed the value of the BorderValues property in the property grid (lines 5 and 11). To create circles representing the Unlike D3 and Vega, Uvis uses only visible visual objects. Further, Uvis does not require data transformations to extract aggregate functions (such as max, sum). Designers specify the aggregate functions in the property where they will be used. Like Vega, Uvis uses declarative expressions that directly define the visual properties. Further, there is no need to define variables, and the sequence of specifying the expressions is unimportant. The environment shows the available visual objects, and allows the designers to drag, drop, and resize them (as long as the position and size properties do not have dynamic expressions) rather than textually setting them. Uvis expressions are more expressive than D3 and Vega as they can refer to visual properties of the same and other visual objects. For instance, the Left formula of the TemperatureEllipse refers to a visual property Width as well as a function of a visual object HPos ( Figure 10). VOLUME 8, 2020

C. EVALUATION STUDIES
We conducted several evaluation studies. Our objectives were to evaluate the learnability of Uvis and identify the concepts that are not easy to learn. Here we show the details of one evaluation study with seven participants. All the participants were non-programmers. They had no prior knowledge of the Uvis formulas, and had never used the Uvis environment. They had basic knowledge of Excel  formulas, algebra, trigonometry, and sequences, and knew what a database table is. Further, they knew how to read simple visualizations such as bar charts. Table 3 shows the participant profiles in more detail.
We judged that the number of participants we tested with was sufficient for the purpose of identifying whether the Uvis concepts were understandable. Nielsen et al. empirically found out that most of the usability problems are found by testing with five users [30].

1) METHODOLOGY
Each evaluation study lasted 2 hours on average. The studies were carried out in a lab. Each participant viewed two screens. One screen showed a Microsoft PowerPoint-based step-bystep tutorial available, and the other showed the Uvis environment. Each participant was asked to follow the instructions in the tutorial. The tutorial is divided into sections, at the end of which, designers were given a task to work on their own, but they could go back to the tutorial and/or example solutions. The tutorial can be found in [48].
The participants were asked to think aloud while they were carrying out the tasks. They received no help from us during the study.
To evaluate ease of learning, we measured task completion time (T) and the quality of the solution (Q). The quality of the solution was measured by comparing the participant's solution against the optimal solution and then rating it on a scale 0-10.
To find out which concepts are easy or hard to understand, and collect other information related to Uvis, we observed the participants while they used the tool, and asked them to provide feedback at the end of the evaluation study. The detailed documentation can be found at [27]. Figure 11 shows the test tasks the participants carried out in the evaluation. The tasks are modification tasks. Customizing a visualization as opposed to building one from the ground up is less time consuming and challenging to designers because they have something to build on. This is adequate for our purpose of identifying Uvis concepts that are hard to understand. The participants were given the desired visual output, a given visualization, as well as a written description of the requirements. The participants could ask for clarifications.

2) TEST TASKS
• Task 1: The bars show a company's monthly sales. Position the bars representing monthly sales like a horizontal list, make the bar heights represent the monthly sales, and order them based on the sales.

3) SURVEY QUESTIONS
At the end of the study, the participants were asked to fill out a survey. The purpose of the survey was to identify weaknesses in Uvis concepts that would be basis of improvement in future releases. VOLUME 8, 2020  We asked the participants about their experience in general, and any difficulties they encountered during the study. Furthermore, we asked about formulas that they thought were hard to understand.
To evaluate understandability of formulas, we asked participants about the functionality of some operators such as ''!'', ''.'', ''-<'', and ''index''. Table 4 shows the quantitative results. The participants were able to complete the tasks at different times. They managed to complete most of the requirements. Despite the variability in quality score and time, the results are encouraging. Task 3 had the lowest average quality score (6.4). This might be described by designers needing to understand unfamiliar formulas such as the formula of SweepAngle in the PieSlice. Nevertheless, half of the participants successfully implemented task 3 as they saw the similarity between the blue pie slice and the pink pie slice. The longest time a participant spent on a task was the time participant 7 spent on the first task (25 minutes). This might be explained by the number of modifications needed for the task (three different modifications). Nevertheless, the time the participant needed was still within the total time we had planned for.

4) RESULTS
The qualitative results can be summarized as follows: The participants were able to learn the Rows formulas that are used to connect the visual objects to data. All participants were able to explain the ''-<'' operator. Additionally, the participants found basic visual property formulas easy to understand. However, half of the participants were confused about the difference between the dot operator (.) and the bang operator (!).
We observed that all participants used most of the Uvis environment components to work on tasks. In particular, participants used the data model, data view, and property grid. Participant 2 appreciated that she viewed everything needed to complete the task at hand. When asked after the end of each task about how confident they are about their solution, two participants inspected their solution to check the visual mappings and answered ''yes''.

V. CONCLUSION AND FUTURE WORK
This paper presented Uvis, a visualization tool that targets end-user developers without programming skills. With Uvis, designers drag and drop visual objects, set visual properties with formulas, and see the result immediately. The formulas are declarative and similar to spreadsheet formulas. The formulas compute the property values and can refer to fields, visual properties, functions, etc. Cognitive aids assist designers while implementing a visualization. Uvis formulas can express custom visualizations that are made of primitive and specialized visual objects. Since they are declarative, Uvis formulas do not support visualizations with recursive layout. As a remedy, a specialized object will have to be made for that purpose. Our evaluation shows that designers can learn the basics of Uvis relatively fast, and can customize visualizations. Based on the evaluation studies we conducted, we have improved autocompletion of formulas as well as error messages to help designers understand Uvis better.
Currently Uvis is desktop based. We are working on making Uvis available on several platforms including web and mobile. Uvis currently supports raw relational data. Many commercial systems hide their data behind web-services and multi-layer architectures, and are unable to give access to data in such a way that end-user developers can join tables and filter them according to end-user needs. We are currently exploring accessing the data with OData [49], which can take an SQL statement as a parameter.