Topiary: Re-designing End-to-End Development by Sze Nga Wong B.S., M.I.T. 2018 Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY June 2019 ○c Massachusetts Institute of Technology 2019. All rights reserved.

Author...... Department of Electrical Engineering and Computer Science May 24, 2019

Certified by...... Daniel Jackson Professor Thesis Supervisor

Accepted by ...... Katrina LaCurts Chair, Master of Engineering Thesis Committee 2 Topiary: Re-designing End-to-End Web Application Development by Sze Nga Wong

Submitted to the Department of Electrical Engineering and Computer Science on May 24, 2019, in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science

Abstract In this thesis, I built a tool for end-to-end web development, named Topiary, which experiments with a multi-table design to model the interactions between user interface components and the backend database. The main features of Topiary include a flat relational data model, a multi-table view with support for inter-table dependency, data compartmentalization via separate developer and user views, as well as flexible styling options. The frontend programming language is Javascript and in particular the React library, whereas the backend database is . Multiple sample apps have been built with Topiary to determine how powerful the tool is in building general applications for daily use.

Thesis Supervisor: Daniel Jackson Title: Professor

3 4 Acknowledgments

I would first like to thank my advisor Daniel Jackson for the inspiration andun- failing guidance in this project and beyond. Prof. Jackson deeply cares about the professional and personal development of his students. I would also like to thank my teammates Sophie Mori and Yang Yan for the helpful discussion and collaboration along the way. Last but not least, I express my gratitude towards my family and friends for showering me with support and encouragement.

5 6 Contents

1 Introduction 13 1.1 An Overview of Existing Spreadsheet Products ...... 14 1.2 Misalignment with Common User Cases of Spreadsheets ...... 15 1.3 Connecting Spreadsheets to Web Applications ...... 15 1.4 Main Objectives of Topiary ...... 16

2 A Quick Demo of Topiary 17

3 Data Model 23 3.1 Hierarchical Structuring of an Application ...... 23 3.2 Horizontal Object Layout ...... 24 3.2.1 Table, Row and Column Identifiers ...... 25 3.2.2 Table and Column Names ...... 25 3.3 Column Typing ...... 26 3.3.1 The String and Number Types ...... 26 3.3.2 The List Type ...... 26 3.3.3 The Button Type ...... 27 3.3.4 The Dropdown Type ...... 27 3.3.5 The Formula Type ...... 28 3.3.6 The HTML Type ...... 28

4 Software Tools in Topiary 29 4.1 Frontend Development ...... 29

7 4.2 Backend Database ...... 30 4.3 Connecting React and Firebase ...... 32

5 Multi-application and Multi-table View in Topiary 35 5.1 The Design View Versus the User View ...... 35 5.2 The Permission System ...... 36 5.3 User-parameterized Data Versus Public Data ...... 39 5.4 An Example of Design View Versus User View ...... 41 5.5 Multi-table View ...... 42

6 Formula Language API 45 6.1 Pre-binding of Table and Column Names ...... 45 6.2 Supported Functions in the Formula Language API ...... 46 6.3 Formula ...... 49 6.4 Going Through the Shopping Cart Example ...... 50

7 Application Styling in Topiary 53 7.1 Styling Pages, Columns and Cells ...... 53 7.2 Styling Options ...... 54

8 Sample Web Applications Built with Topiary 57 8.1 Shopping Cart ...... 57 8.2 Time Tracker ...... 58 8.3 Room Reservation System ...... 60

9 Conclusion and Future Work 63

8 List of Figures

2-1 A demo of the design view of the shopping cart application ...... 18 2-2 A demo of the user view of the shopping cart application ...... 18 2-3 User view of the shopping cart application, after inputting quantity . 19 2-4 User view of the shopping cart application, after a merchandise has been added ...... 19 2-5 Design view of the shopping cart application, after a merchandise has been added ...... 20 2-6 Design view of the shopping cart application, after a merchandise has been added ...... 20 2-7 Design view of the shopping cart application, after a merchandise has been added ...... 21

4-1 The software tools used in implementing Topiary ...... 29

5-1 The location of the permission setting in the design view ...... 39 5-2 The location of the public vs user-parameterized data setting in the design view ...... 41 5-3 The design view of the shopping cart example ...... 42 5-4 The user view of the shopping cart example ...... 42

6-1 The Products and All_purchase_records tables in the design view . . 51 6-2 The Cart table in the design view ...... 52 6-3 The Subtotal table in the design view ...... 52

7-1 Cell styling in the design view ...... 54

9 7-2 The user view of the shopping cart example after styling ...... 55

8-1 The user view of the shopping cart application ...... 58 8-2 The user view of the time tracker application ...... 59 8-3 The user view of the room reservation system application ...... 60

10 List of Tables

3.1 The basic layout of the Products table ...... 24 3.2 The basic layout of the Cart table ...... 24 3.3 The basic layout of the Subtotal table ...... 24

11 12 Chapter 1

Introduction

A web application is a client-server computer program which stores data in remote servers and can be run in a web browser by the client. With the rapid expansion of the World Wide Web, web applications are now playing a more important role in the lives of many people, and quick development cycles are desired by application builders. As a result, instead of coding up the entire application using pure Javascript, HTML or CSS, application builders often utilize existing libraries and tools to simplify the coding process. A well-designed end-to-end web application development tool can thus be of great help to them. In particular, the spreadsheet model is chosen since tabular data are commonplace in webpages. For example, a shopping cart can be described as a table with each row representing a merchandise and columns comprising its names, description, prices, quantities and subtotals. Furthermore, spreadsheets gives users the privilege of example-driven programming. Users can use visual tools with sample data to design both the inbuilt logic and the look of spreadsheets. This is in contrast with low-level programming which hides away many of the interactions within the data. Altogether, Topiary is an end-to-end web development tool built with the incorporation of the spreadsheet model. Chapter 2 describes the data model of Topiary, including the hierarchical structure of an application, the notion of horizontal object layout, as well as column typing. Chapter 3 introduces the software tools used in the implementation of Topiary, namely Javascript and its libraries React and Re-base, as well as Firebase. The

13 reasoning to use each tool is also elaborated.

Chapter 4 dives into the multi-application view in Topiary, namely the distinction between the design view and the user view, and various tools that application builders can utilize for a flexible user view.

Chapter 5 describes the formula language API of Topiary and demonstrates its flexibility and comprehensiveness through examples.

Chapter 6 goes through the styling options that application builders enjoy with Topiary.

Chapter 7 presents multiple sample applications built with Topiary.

Chapter 8 concludes the work done on Topiary, as well as suggests potential future work.

1.1 An Overview of Existing Spreadsheet Products

Spreadsheets are interactive computer applications for storing and analyzing data in tabular form. When one thinks of spreadsheets, the immediate examples that come up may be Microsoft Excel, Sheets or Apple Numbers, with Microsoft Excel having a leading market share with over 750 million users worldwide. While each of these spreadsheet products offers the basic functionalities to handle data in various ways, they appeal to different spreadsheet users. Microsoft Excel is the most versatile; for example it offers a multitude of pre-loaded formulas and functions that arenot fully present in nor Apple Numbers. On the other hand, Google Sheets allows its users to collaborate on a document in real-time, and offers the abilities to use many of other Google products, including , within Sheets. Last but not least, Apple Numbers, being the newest of the three, provides a simpler interface that makes it much easier to create spreadsheets with elaborate visual impact.

14 1.2 Misalignment with Common User Cases of Spread- sheets

While spreadsheets offer features like creating charts, they are in fact often usedas tables; each column contains data of the same type, and each row contains a se- quence of data for an individual instance. However, a spreadsheet does not represent the notion of a table very well; rather it treats each cell individually, and as a con- sequence there is no relational operation to manipulate the data in an intuitive and effective manner. Therefore, an objective when designing Topiary is to correct this misalignment between data representation and manipulation.

1.3 Connecting Spreadsheets to Web Applications

Often people complain about why building a web application is so hard, and even a simple event scheduler with basic user interface design is not a trivial project to accomplish. Organizations in need of a web application service usually turn to one of the following options: hire software developers to build the application (which can be costly), use some off-the-shelf product (which may not cater to the exact needs of the organizations), or use a combination of Google Forms, emails and/or other popular existing services (which may require manual processing that can otherwise be eliminated). Therefore, through Topiary it is hoped that the web application building process can become easier for organizations. While there exist application builders, the spreadsheet model is arguably most suitable to handle data-centric tasks, which involve typical not non-trivial data manipulations. In the example of a shopping cart, one data manipulation can be to retrieve the price and quantity of a merchandise to compute the subtotal by multiplication. To this end, we propose an end-to-end web application development tool with a spreadsheet interface, named Topiary. The idea of extending the spreadsheet model has also appeared in Object Spread- sheets [2] and SciSheets [1]. The former presents the end-user development tool called Object Spreadsheets that combines a spreadsheet interface with a rich data model to

15 help build the logic for data-centric web applications, and the tool is intended to be integrated with a UI builder. Topiary differs from Object Spreadsheets in multiple aspects, including the design of the data model and formula language, as well as that Topiary is intended to be an end-to-end development tool without the need for a UI builder. On the other hand, SciSheets proposes that formulas can be arbitrary Python scripts and expressions, which can be seen as a parallel to how the formula language in Topiary is interpreted as Javascript scripts as well. However, SciSheets is considered more as an extension to traditional spreadsheet models, rather than a web application development tool.

1.4 Main Objectives of Topiary

The main objectives of Topiary are stated below:

1. Multi-application views: in the design view, application builders design the pipeline of data manipulation and the layout of the user view; in the user view, users contribute their individual data input and obtain the resulting output subject to the viewing rights.

2. Rich data model: the data model should be versatile and offer support for moderately complex data-centric applications. Moreover, the data model should be easily adaptable to the spreadsheet interface.

3. Multi-table view: the view should support the display of multiple tables with potential data dependencies between them, which should always be followed in the view at any time.

4. Application styling: the styling options available to application builders should support elegant and flexible user views.

16 Chapter 2

A Quick Demo of Topiary

Before diving into the design details of Topiary in subsequent chapters, we provide a quick demo of Topiary through a concrete shopping application of a supermarket. In particular, this application involves three tables in the user view.

1. The first table, call it the Products table, lists all merchandise available in the supermarket and their prices, and allows users to specify the quantity of each product in stock.

2. The second table, call it the Cart table, simulates a shopping cart by listing all items that have been chosen, their respective quantities, as well as their resultant prices.

3. The third table, call it the Subtotal table, computes the total price from all items in the Cart table.

The design view, as seen by application builders, is presented in Figure 2-1. The toolbar on the left is dynamic based on which cell is in focus, and contains general functionality. such as adding or deleting rows and columns, as well as styling options. The space to the right can be thought of as the canvas which contains tables positioned absolutely. Application builders can drag tables to arbitrary position in the canvas. The explanation on how this application is implemented will be left to the later chapters.

17 Figure 2-1: A demo of the design view of the shopping cart application

The user view of the shopping cart application, as seen by users, is presented on Figure 2-2. It looks like the design view, except without the toolbar and the table at the bottom. Indeed Topiary allows application builders to hide any column from the user view, and in this case all columns of the table at the bottom are hidden. Currently, the cart is empty, hence no item shows up under "My Cart".

Figure 2-2: A demo of the user view of the shopping cart application

Another feature is that application builders can declare whether users can edit or view each column. In the Products table, all columns except the quantity column are

18 not editable. Users can input any number in the quantity fields, as demonstrated in Figure 2-3.

Figure 2-3: User view of the shopping cart application, after inputting quantity

After inputting the quantity, users can click the "Add" button to add the mer- chandise to their cart. The updated user view after the "Add" button is clicked is shown in Figure 2-4. The cart now contains one merchandise, and the quantity field is reset to empty.

Figure 2-4: User view of the shopping cart application, after a merchandise has been added

The corresponding design view after a merchandise is added is shown in Figure 2-5. The table at the bottom stores all merchandise added to cart along with the

19 ID of whoever added them. It can be thought of as a "master" table containing (almost) all data. The reasoning of why this "master" table is needed will be covered in Chapter 6.

Figure 2-5: Design view of the shopping cart application, after a merchandise has been added

Suppose that another user uses the same application. His/her data are isolated from those of other users, and this is achieved by the distinction between user- parameterized and public data, to be explained in Section 5.3. The user view may look like that in Figure 2-6.

Figure 2-6: User view of the shopping cart application for another user

The newest version of the design view contains cart data of both users, as shown

20 in Figure 2-7.

Figure 2-7: Design view of the shopping cart application, after both users have added their merchandise

21 22 Chapter 3

Data Model

Topiary uses a flat relational model as the data model. The major design choices include a horizontal object layout, allowed content types of each field, customized visibility as well as the differentiation between user-parameterized and public data in each column. The latter two are explored further in Section 5.2 and Section 5.3. In the following, we re-use the shopping cart example from Chapter 2.

3.1 Hierarchical Structuring of an Application

This section offers a high-level overview of Topiary. Any application built in Topiary follows a general hierarchical structure, in the following order:

1. App

2. Page

3. Table

4. Row

5. Cell

The application can be either single-paged or multi-paged. The current version of Topiary supports only single-paged applications, but the codebase infrastructure has

23 been designed to allow simple extension to multi-paged applications as well. A page can contain any number of tables. There are two choices to further break down a table, either column-wise or row-wise. In Topiary, a table is described as a collection of rows; this decision is further elaborated in Section 3.2. Finally, a row can be broken down into the smallest unit of cells.

3.2 Horizontal Object Layout

Topiary uses a horizontal object layout. In a table, each row represents an object, and each column contains a field of each object, as the basic unit of data. In other words, a table can be thought of as an ordered collection of objects with the same set of fields. This layout is flexible enough to handle many data-centric applications, as demonstrated by the shopping cart example. Each row in the Products table represents a merchandise, and the columns correspond to its name, price, quantity as well as an "Add" button that adds the merchandise to the cart. Table 3.1 summarizes the above description. Similarly, the structures of the Cart and Subtotal tables are shown in Table 3.2 and Table 3.3.

Name Price Quantity Add_Button Product1.name Product1.price Product1.quantity Product1.add_button Product2.name Product2.price Product2.quantity Product2.add_button

Table 3.1: The basic layout of the Products table

Name Price Quantity Total_Price CartProduct1.name CartProduct1.price CartProduct1.quantity CartProduct1.total_price CartProduct2.name CartProduct2.price CartProduct2.quantity CartProduct2.total_price

Table 3.2: The basic layout of the Cart table

Amount Subtotal.amount

Table 3.3: The basic layout of the Subtotal table

24 When implemented in Javascript, the data of all cells in a table share the fol- lowing structure, where any row or column has its unique identifier row_n _id or column_n _id (to be covered in Section 3.2.1):

1 cells_data={ 2 row_1_id:{column_1_id: cell_1_1_data, column_2_id: cell_1_2_data, ...}, 3 row_2_id:{column_1_id: cell_2_1_data, column_2_id: cell_2_2_data, ...}, 4 ... 5 }

Listing 3.1: The Structure of All Cells Data in a Table

3.2.1 Table, Row and Column Identifiers

It should be noted that the row and column identifiers are created with the creation of the respective rows and columns, and persist throughout their lifetime. That is, they are independent of row or column indices. This choice of storing data labeled with persistent identifiers is relatively stable and efficient compared to some other method; for example, an alternative way to store the data in all cells is through a hierarchy from row index to column index, then to cell data. However, in the scenario that the first row is deleted, adopting this alternative implies re-ordering the row indices and thus changing all key-value mappings in the highest level of the hierarchy. By utilizing identifiers, we only need an auxiliary array to store all row identifiers inthe order of the underlying row index, which is clearly computationally more efficient to update. Moreover, tables also have their own identifiers upon creation.

3.2.2 Table and Column Names

Each column has a unique ID. However, sometimes columns represent some particular property and should be named accordingly. For example, the Products table has a column that stores merchandise prices, thus it is best to be able to name that column as price or other names in the same vein. As a result, on top of column IDs,

25 application builders can assign names to columns, with the restriction that these names must be valid Javascript variable names and cannot repeat, to be further elaborated in Section 6.1. The default values of column names are the respective column IDs. By a similar reasoning, in Topiary application builders also enjoy the flexibility of renaming tables.

3.3 Column Typing

Another feature of Topiary is column typing. Section 3.2 already gives the abstraction of each column representing a field of the row objects. Any field can be expected to share the same data type across all row objects; for example, the Products table from the shopping cart example contains a column of merchandise prices, which can all be reasonably expected to be numbers, thus giving the price column the number type. A list of common data types are compiled from common websites and supported in Topiary. They are explained in details below. We take note that some data types, like the String type, represent user-entered data, while the others, like the Formula type, represent derived data, in the sense that the values displayed to application users are derived from those in some other cells.

3.3.1 The String and Number Types

The String and Number types are self-explanatory; they can be interpreted in the same way they are treated in any programming language.

3.3.2 The List Type

The List type is an alias for an ordered collection of Strings. A scenario in which this can be useful is when the origin places of a merchandise are displayed to users, and in particular, there can be multiple origins for a single merchandise. In this case, the Products table can have an additional origins column that is of the List type, showing the full list of origin places each merchandise is from.

26 3.3.3 The Button Type

A column of the Button type contains a button in each of its cells, defined by a common set of specifications. These specifications include:

1. The text to display in each button, which can be either a constant string or a variable string that depends on the data in other cells. The latter option is achieved via a formula, which will be explained in depth in Chapter 6. For example, in the Products table, the last column should contain a button with the text "Add" in each cell, to enable the user to add that merchandise after inputting the quantity.

2. The logic after each button is clicked, which is also specified by a formula. In the shopping cart example, the "Add" button in the Products table should have a logic of adding the information of the relevant merchandise to the Cart table.

3. When each button is disabled, which is also specified by a formula. This can be useful if the user should only press a button after filling in some other cells. For example, in the Products table, the "Add" button should be disabled as long as the user has not entered a number in the Quantity cell.

3.3.4 The Dropdown Type

A column of the Dropdown type contains a dropdown menu in each of its cells, defined by a common list of options that the user can choose from. This list can be declared statically or computed dynamically through a formula, to be introduced in Chapter 6. In the Products table, each merchandise may have a variety of offerings, for example, large versus small apples. In that case, a dropdown menu can be employed to allow users to indicate which one they want. The Dropdown type offers the flexibility that the application builders can choose a fixed collection of options for users to choose from, rather than allowing users to input any variable string.

27 3.3.5 The Formula Type

Often, the values to display in a column may be dependent on those from other columns within the same table, or even from across tables. Therefore, it is necessary for Topiary to offer support to systematically fetch data from other sources, process them via arbitrary transformation, and display the final value. In the shopping cart example, a formula is needed to compute the subtotal in the Cart table by summing up the resultant prices of all merchandise from the Cart table. In this case, assigning a Formula type to the column containing the subtotal may be imperative. Thereby, Topiary offers application builders its own formula language API, through which fetching and transforming data can become simple function calls to the API. The design of the formula language API is detailed in Chapter 6.

3.3.6 The HTML Type

Last but not least, the HTML type is added for the sake of flexibility. If a cell lies in a column of the HTML type, it can hold any HTML script. A useful application is to display an image from the Internet; the only input that the application builder needs to supply is the link address of the image. The script tag is rejected to prevent unnecessary and possibly unintentional change to the database.

28 Chapter 4

Software Tools in Topiary

In this chapter, the software tools used in Topiary are introduced and justified. In particular, Javascript and its library React, coupled with CSS, are utilized in the frontend development, whereas Firebase will serve as the backend database storing all data as necessary. In addition, the Javascript library Re-base is chosen to synchronize data between React states and the data stored in Firebase. The interaction of these tools is presented in Figure 4.

Re-base React - Firebase

Frontend Backend

Figure 4-1: The software tools used in implementing Topiary

The current version of Topiary performs most tasks on the client side, including the retrieval and manipulation of data stored in Firebase.

4.1 Frontend Development

Javascript is chosen for the frontend development because of several reasons, namely its wide availability and popularity, its object-oriented feature, as well as the ease to

29 sync the UI with the state through React. First of all, Javascript is a freely available to anyone, which has made it a popular programming language amongst frontend developers. Its popularity can eventually be useful in attracting contribution effort if Topiary is to be released as an open-source tool in the future. Moreover, the object-oriented nature of Javascript has made it especially suitable for the data model introduced in Chapter 3. In particular, the hierarchical structure of an application built with Topiary, described in Section 3.1, can conveniently make use of the concepts of data encapsulation and abstraction in object-oriented programming. Thus a good way to structure the codebase is to create a class for each level of the hierarchy. Furthermore, the popularity of Javascript has led to the emergence of many ex- ternal libraries and tools that add value to its capability. Developers using pure Javascript often find it challenging to keep the UI in sync with the state; identifying and updating the elements to re-render upon each state change can be tedious and prone to errors. Since Topiary heavily relies on the states of the classes, it is essential to ensure that the synchronization is handled reliability. Fortunately, in the Javascript library React, the DOM is declarative, i.e., the UI is updated automatically when the state changes. Besides, the virtual DOM concept of React allows only the compo- nents which have been changed to re-render, This is an obvious performance boost over reloading the entire page. Therefore, React is used extensively in the frontend development of Topiary. Finally, CSS is used to help with styling efforts and to provide a good user expe- rience for both application builders and users.

4.2 Backend Database

Topiary needs to provide a reliable storage for the data of all applications, and this storage service should work well with Javascript and React. After careful evaluation, Firebase is chosen as the backend service. Firebase offers multiple benefits, including

30 its reliability, availability of authentication and hosting tools, the real-time synchro- nization of Firebase Database, and its representation of data in the JSON format. First of all, Firebase is an established service backed by Google that has been used and tested by many developers. Thus its reliability should be beyond doubt and fits the requirement in Topiary. In addition, Firebase not only is a database service, but also offers a variety of other tools like Firebase Authentication and Firebase Hosting that seamlessly go hand in hand. Topiary can in fact reap great benefits from this: web applications built with Topiary require secure user login, and this can be achieved through Firebase Authentication, which integrates directly with the database service, allowing user- based control access to data. On the other hand, Firebase Hosting can be used to serve both Topiary and the web applications built with Topiary. Firebase being a multi-purpose platform offers multiple products that Topiary has found applicable. An additional note is that the Firebase API is easy to use and helps cut development time. This is in contrast with alternatives like Node which require application builders to manage their own servers and write backend functionality. Moreover, the database service offered by Firebase, called Realtime Database, stores and syncs data between users and devices in realtime using a cloud-hosted database. If some data is updated in the backend database, the changes in the UI are reflected for all users in real time. This feature of real-time synchronization mustbe supported in Topiary because it is essential for many web applications. Imagine that a document editing tool is built with Topiary, and its application builder wants to enable collaborator editing. If we want all parties editing the same document to be on the same page, real-time synchronization is fundamental to support such feature. Finally, Firebase Database stores data in one big JSON tree which fits well with the data model of Topiary, as described in Chapter 3. On one hand, the data stored in the JSON tree can follow the same hierarchical structure in Section 3.1 in a straight- forward manner. On the other hand, the JSON format easily integrates with the object-oriented nature of Javascript. Most data stored in the class states are of type string, number, object or array, all of which can be stored directly in the JSON

31 format. Also, the design choice of horizontal object layout in Section 3.2 again falls in with the JSON format of Firebase Database. Hence, the data model of Topiary matches the JSON data storage format of Firebase Database.

4.3 Connecting React and Firebase

In React, the data of each component are stored in its state and used in the rendering of the UI view. On one hand, if an application user changes some data via interaction with the UI, the change needs to be propagated back to the Firebase database. On the other hand, if either the application builder or some other user makes some data change that impacts the UI view of this application user, the respective change should also be reflected in the UI view. Therefore, this effectively creates the need tosupport a two-way synchronization between React states and Firebase Database. The realtime data synchronization feature of Firebase Database helps keep the latency in the UI update short, but there is yet a missing bridge between React and Firebase: how does one keep the React states and Firebase Database in sync with each other? One solution is to set up listener events for React to detect whenever some data in the database changes, and push changes to the database whenever the React states are modified. However, this can be tedious. Thus, in the implementation of Topiary, the Javascript library Re-base [3] is employed to tackle the two-way bindings in a more stable way. Re-base offers a syncState function that effectively creates a two-way binding between a state property and an endpoint in the Firebase Database. In most situa- tions, syncState performs exactly as intended. However, when a Javascript object or array has become empty, the intended behavior is to remove it from the database, but syncState is not able to reflect this change in the database. Rather, Re-base recommends a feasible hack, which is to replace the empty object or array by null. But this hack can be problematic if some object or array functions are called upon this value in other parts of the code. Thereby, in future iterations of Topiary, it is

32 hoped to explore the existence of any better solution.

33 34 Chapter 5

Multi-application and Multi-table View in Topiary

This chapter covers the design choice of keeping the design view and the user view separate in Topiary, as well as the necessary features to pave the way for the dis- tinction between the two views, including the permission system and the distinction between user-parameterized data and public data. Moreover, the UI design choice of a multi-table view is discussed in Section 5.5.

5.1 The Design View Versus the User View

Each web application created with Topiary comes with a design view and parameter- ized user views. The design view is used by the developer of the application, whereas the user views are used by the users of the web application. It is to be noted that the current version of Topiary supports only one developer per application. The two types of views are explained below, and illustrated through a concrete example in Section 5.4. In the design view, the application developer has full control over the user view, including the layout of the user view and the content that the users can view and edit. The permission system related to the control of what the users can view and edit is discussed in detail in Section 5.2. The application builder can also include the

35 logic to process the data input of the users in the design view. Moreover, he/she can choose whether the hide the column header that displays the column names. While all functionalities of the design view can be found in the context menu, a sidebar is also included for the convenience of application builders. On the other hand, the user view refers to what the application users can see. Different users may have individual data stored with the application, which neces- sitates the concept of parameterized views. The user view is parameterized by the unique ID of each user. The application has access to the IDs of its users because by default any application created with Topiary requires user login. In a parameterized user view, there are two classes of data, namely those that are shared by all users across the application and those that are specific to individual users. This distinction is further discussed in Section 5.3. In addition, in order for application builders to easily visualize how the user view looks like, Topiary offers the option to toggle between the design view and theuser view, in which case the builders can interact with the application as if they are normal users.

5.2 The Permission System

As application builders plan out their applications, there may be some tables that they may want to hide from the user UI view, or some information that application users should not be allowed to modify. There arises the need to specify permissions on whether users can see or even modify some data. In Topiary, there are three types of permission that the application builders can indicate:

1. Not visible to application users

2. Visible to but not editable by application users

3. Editable by application users

Next, there remains the design choice of the level of granularity that these per- missions should apply to. Based on the hierarchical structure of an application in

36 Section 3.1, there can be multiple levels of granularity corresponding to each level in the hierarchy. First, assigning the same permission setting on the entire application or page is too crude and does not fit the use of most applications. The remaining choices are whether to the setting should be applied per table, row, column or cell. While it is possible to define permission settings on multiple levels, Topiary only exploits one level for the sake of simplicity. In order to make this design choice, concrete application examples ought to be considered. To this end, the shopping cart example from Chapter 2 is examined below. The Products table is discussed in particular. In this table, all data like the names, prices and quantities of all merchandise can be made visible to application users. The question that remains is whether they should be made editable by users. It is obvious that merchandise names and prices should not be arbitrarily modified by any application user, otherwise malicious users can simply change any merchandise name and cause confusion to other users. In the worst scenario, all prices may be set to zero, in which case the web store can be severely undermined. Thereby, these fields should be made not editable by users. Furthermore, the "Add" button is simply a UI element that the users can click on, and hence should not be edited by any user. On the other hand, the quantity field of each merchandise object requires input from application users, thus needs to be declared editable by any user. The above discussion of the Products table makes it clear that applying permission setting per column is feasible in the particular example. This aligns well with the horizontal object layout introduced in Section 3.2: each column represents the same field of all objects, and it is reasonable to assume that the permission setting forthe same field should be kept consistent. While it is possible to define permission setting at the lowest level of per cell, such fine granularity is likely not necessary in most applications given a reasonable layout design. Therefore, any application developed with Topiary has a permission setting per column, that specifies whether the data are visible to and editable by general users. Moreover, the permission setting for editing data is further restricted by column

37 typing. The idea is that some data types should never be edited by application users. These data types include List, Button, Dropdown, Formula and Html. The rationale that the above data types should never be edited by users is that the rendering logic for all of them makes use of the formula language API, to be introduced in Chapter 6. There are two reasons that justify why users should never be allowed to manipulate the API directly, namely user experience in the application and data security concern.

Firstly, having users write Javascript code is not a typical scene in web applications and it is unreasonable to assume that all application users are fluent in Javascript.

Secondly, giving users access to the API can be dangerous, since there is no way to control what functions users can call and malicious users can potentially manipulate the API to steal, update or remove data from the database.

As a result, columns with the five data types listed above have only two permission setting options, either visible or not visible. Nonetheless, this does not imply that data of these types remain constant throughout an user session and are never affected by user behavior. For example, application builders can design a button that upon a click adds an item to another cell of the list type. Hence, indirect user interactions with the five data types are definitely possible in Topiary.

In terms of actual implementation in Javascript, each Table class has a state property that maps column IDs to their respective three-value flags, representing the three permission settings:

1 permissions_data={ 2 column_1_id: permission_flag_1, 3 column_2_id: permission_flag_2, 4 ... 5 }

Listing 5.1: How Permission Settings Are Stored in a Table

Figure 5-1 shows the actual location of the permission setting in the design view of Topiary, upon the focus on any column.

38 Figure 5-1: The location of the permission setting in the design view

5.3 User-parameterized Data Versus Public Data

Section 5.1 has introduced the necessity to differentiate between data that are shared by all users and those that are specific to individual users. The data shared byall users are referred to as the public data, whereas those specific to individual users are called the user-parameterized data.

The shopping cart example from Chapter 2 is again employed to explain the difference between public data and user-parameterized data. Inthe Products table, the same prices and names of all merchandise should be displayed in all user views for the sake of consistency. Moreover, the "Add" buttons should also carry the same functionality for all users, which is adding extra rows to the Cart table, signifying the respective merchandise have been added to the cart. Therefore, the prices, names and "Add" buttons in the Products table belong to the category of public data.

On the other hand, different users should have their own separate quantity fields in the Products table. When one user writes in a quantity field, his/her input should be invisible to other users. Therefore, the quantity field is best categorized as user-

39 parameterized data.

From the discussion of the shopping cart example, it is reasonable to assign data in the same column to the same category, be it user-parameterized or public.

In terms of actual implementation in Javascript, each table class has a state prop- erty that maps column IDs to their respective flag of user-parameterized versus public. The data of all cells also need to be stored in the state. Recall that in Section 3.2 the structure of all cells data in a table is laid out, but it only works under the assumption that all data are public as there is only one copy of data for each cell. Therefore, the structure needs to be modified to accommodate user-parameterized data.

Instead of having a single value for the data in each cell, the cell data are now represented by a key-value mapping, where the keys can either be the constant string "public" or all application user IDs. Consider a table containing one row and two columns, and the first column stores public data and the second one stores user- parameterized data. Then the format to store all cells data is as follows:

1 cells_data={ 2 row_1_id:{ 3 column_1_id:{ 4 "public": cell_1_1_data 5 }, 6 column_2_id:{ 7 user_1_id: cell_1_2_data_user_1, 8 user_2_id: cell_1_2_data_user_2, 9 ... 10 } 11 } 12 }

Listing 5.2: The Structure of All Cells Data Including User-parameterized Data

Figure 5-2 shows where in the user view application builders assign columns to contain public or user-parameterized data:

40 Figure 5-2: The location of the public vs user-parameterized data setting in the design view

5.4 An Example of Design View Versus User View

After discussing the permission system and the distinction between user-parameterized and public data, this section shows a concrete example of how the design view is dif- ferent from the user view. Figure 5-3 and Figure 5-4 demonstrate the design view and the user view of the shopping cart example respectively.

A major distinction between the design view and the user view is that the table containing the data of all users is present in the design view but missing from the user view. This is because the permission setting for all columns in that table is set to be not visible to users, which makes sense logically due to user data compartmen- talization. Moreover, the design view comes with a sidebar that shows the options to change settings on different hierarchical levels based on the cell that is infocus.

41 Figure 5-3: The design view of the shopping cart example

Figure 5-4: The user view of the shopping cart example

5.5 Multi-table View

The user interface of Topiary adopts the UI design choice of a multi-table view. Different existing spreadsheet tools are introduced to justify this design choice.

The user interfaces of Apple Numbers and Microsoft Excel are compared and contrasted. In Microsoft Excel, users work on one sheet at a time, and as many sheets as users desire can be added. There are some limitations to this user interface model. First, at any given time, the computer screen only displays a single sheet.

42 There is no convenient way to view multiple sheets at the same time. Second, the sheet contains empty rows and columns that extend with no limit rightward and downward. Often, users only need to use the sheet to store tables of limited sizes, making the remaining empty space irrelevant. Nonetheless, there is no way to hide away the empty space. In comparison, Apple Numbers appears more appealing in dealing with these lim- itations in Excel. In Numbers, it shows tables, each being a spreadsheet occurrence. Users can add as many tables as desired, and each table functions as a separate spreadsheet. This design is superior compared to the single-sheet view of Excel as users do not have to jump between sheets to inspect all the data. In addition, Numbers users can specify the width and height of each table, and change them in any arbitrary way should the need arise later. This is especially desirable to keep away the otherwise irrelevant empty space in Excel, which can be unnecessarily distracting to users. With these comparisons in mind, Apple Numbers makes it easier for users to see what they are working on, as well as for others to see all that they need to. In a way, Apple Numbers is more presentable. Since a goal of Topiary is to make the UI easy to work with from the perspective of application builders and users, Topiary adopts a user interface similar to Apple Numbers. In this way, the users of Topiary will enjoy a multi-table view that makes data inspection and manipulation easier.

43 44 Chapter 6

Formula Language API

Different elements in a web application often need to interact with one another. Such interactions can come in multiple forms, including the dependency of some displayed values on others, or element update, addition or deletion based on user actions. In order to provide flexibility in designing such interactions, Topiary introduces the notion of a formula. A formula is a block of Javascript code, executed through the eval function. While any well-defined Javascript function can be called in a formula, for the sake of the predictability of code behavior it is recommended to utilize the formula language API as much as possible. This practice is recommended to prevent unintentional side effects, since by design formulas are capable of updating table data. The formula language API is discussed in details in this chapter.

6.1 Pre-binding of Table and Column Names

It is commonplace that the value in a cell may depend on other values in the same row, or even in other tables. For example, the shopping cart example in Chapter 2 contains a Cart table, in which the resultant price of each merchandise is computed by multiplying its unit price and quantity together. The simplest formula for this computation is price * quantity. In order to make this formula functional, appli- cation builders need to be able to reference the price of each merchandise simply by the expression price, and similar saying holds for quantity. Therefore, there is a

45 hidden binding between the column name and the value in that column within the same row, that is, a variable named the same as a column evaluates to the value from the cell located in that column and in the same row. Similarly, there is a binding between table names and the table class objects in React. Referencing table_name exposes the class functions corresponding to the table of that name. In addition, Topiary also pre-binds the ID of the currently logged in user as uid, with applications like the example in Section 6.4. A subtlety is that in order to support such bindings of table and column names, these names need to be valid Javascript variable names. The user interface of Topiary raises warnings if application builders break this rule.

6.2 Supported Functions in the Formula Language API

In Section 6.1, we introduced the logic to access values in other columns within the same row as well as to reference other tables. This section covers a wider variety of functions supported by the formula language API of Topiary. It should be noted that none of these functions takes in row and column indices as parameters, because indices are unstable in the sense that the addition or deletion of rows and columns shifts the indices and may result in unexpected behavior of the formula.

1. rowCount and colCount: The functions rowCount and colCount take in a Ta- ble object as input and return the corresponding numbers of rows and columns. This can be useful if the application builders keep a table listing all users and want to find out how many users there are.

2. sum: There is a sum function that returns the summation of values in the same column of a table, with an optional filter on the row objects of the table. Here, a row object is a mapping from columns to their respective values in a row. This sum function can lend a hand to the shopping cart example from Chapter 2: the

46 subtotal amount can be computed by taking the sum of all resultant prices of merchandise in the Cart table. Moreover, with the help of the filter parameter, it is also possible to compute the subtotal amount of all merchandise with prices above a certain threshold, by supplying the function

r => r.price > threshold.

Here r represents a row object, and r.price accesses the value mapped by the price key.

3. update: The update function updates the values in a column by supplying the new values. The column can be the table that the formula resides in, or any other table. Moreover, the update function also takes in a filter that determines whether the values in individual rows should be updated. The Cart table in the shopping cart example may find this update function helpful: for example, the table may have columns of increment buttons, allowing users to increment the quantity they have picked earlier. The formula describing the click behavior may use update to update the quantity in the quantity field, and may be of the form

update("quantity", quantity + 1)

, where the first parameter is the name of the column to be modified andthe second parameter is the new value to be placed in that column.

4. addRow and delRow: Adding and deleting rows are sometimes necessary, hence the formula language API also defines the addRow and delRow functions. We emphasize that this functionality is not supported by the formulas in other spreadsheet applications like Microsoft Excel. We first discuss the addRow func- tion. It adds a new row to a specified table with optional data parameter, which can be used to pre-fill some data in the new row. We go back to the shopping cart example: in the Products table, each merchandise comes with an "Add" button, which when clicked adds the merchandise relevant information to the

47 Cart table. The formula that defines the click behavior of the "Add" button should use the addRow function, by fetching the name, price and quantity of the merchandise and adding a row to the Cart table with these information.

Next, we discuss the delRow function. This function takes in a table parameter as well as an optional filter. The behavior is to delete the first row in thegiven table that satisfies the filter. In the shopping cart example, application builders may build in a column of "Delete" buttons in the Cart table, which when clicked removes the respective merchandise from the cart.

The remaining functions introduced below are class functions of the Table class.

1. pick: The pick function has a column name parameter and an optional fil- ter parameter. The behavior is to filter the rows in the table by the filter, and returns the value in the column with the supplied column name for one of the fil- tered rows. The pick function is especially useful with one-row tables. Towards the beginning of this section, we discussed why having indices as parameters is bad in the formula language API. However, consider a table in which each user is asked in put in his/her name, and another table that wants to extract the user’s name. All the functions covered so far fail to achieve this, and indeed indexing could be a viable solution. Nonetheless, we have already dismissed indexing and need a way to extract data from the one-row table, which leads to the design of the pick function. The pick function makes it trivial to extract the user’s name, by supplying the corresponding table and column containing the user’s inputted name string.

2. map and filter: The map and filter functions can also be called on Table class instances. Both of them take a callback function parameter, and return an array. The map function maps each row in the table to a value as defined by the callback function, whereas the filter function filters all row objects by the callback function and returns an array containing only those that pass the filter.

48 6.3 Formula Tables

In this section, we introduced the notion of formula tables in Topiary. In a normal table, rows are added in two ways, either by application builders when the application is built, or by user interaction that triggers the addRow function. However, these limits the way a table can be built. What if we want a dynamic table that can grow or shrink in size based on the data in other tables? In particular, what if we want to display a projection of a table? Therefore, Topiary introduces formula tables which are defined by filtering other tables. Conceptually, each row in a formula table corresponds to a row in the table that gets filtered, and any formula defined in the formula tables gets evaluated asif the formula is being computed in the corresponding row of the table that gets filtered. More specifically, the Table class hasa filterT function, which takes in a filter callback and returns an array of the IDs of the row objects that satisfy the filter function. This array of row IDs is used to construct the rows of the formula table dynamically, i.e., the formula table contains exactly one row corresponding to each of the returned row IDs. In the design view, application builders can create a formula table which requires a definition in the form of a formula. This formula should take theform

other_table_name.filterT(filter_function ).

Let us give a concrete example. Suppose that in the shopping cart example, we would like to add an additional Expensive_products table that displays all merchandise priced greater than $100. This Expensive_products table should be defined as a formula table, defined by the formula

Products.filterT(r => r.price > 100).

After supplying this formula, the Expensive_products table will grow to the right amount of rows, corresponding to the number of merchandise priced greater than $100. However, the table at this state is still quite useless since all cells are empty. In order to display information like the name and price of the merchandise, formulae

49 need to be employed again. To display the name, a column needs to be defined with the formula type and the formula definition is as simple as name, with thanks to the column name bindings.

6.4 Going Through the Shopping Cart Example

We re-visit the shopping cart example first introduced in Chapter 2 again. In this section, we are giving a step-by-step walk through of how to design the tables. In the user view, there should be the Products, Cart, Subtotal tables. The setups of these tables are mostly straight-forward with the formula language API. A major challenge is that the size of the Cart table is dependent on how many merchandise the user has picked, and thus grows dynamically. As a result, the Cart table needs to be set up as a formula table, and on top of that a "master" table storing the purchase data of all users is created. In this way, the Cart table can be built dynamically by filtering this master table by the user ID. Another implication is that the Products table no longer directly interacts with the Cart table; rather, whenever users click the "Add" buttons in the Products table, rows are added to the "master" table along with the ID of the currently logged in user. At this point, we have enough information to build the four tables. First, we go through the Products table. It has four columns, namely merchandise name, price, quantity and "Add" buttons. The merchandise names and prices are directly inputted by the application builder. The quantity field is editable by users. The formulae for the "Add" buttons have yet to be specified. Recall from Section 3.3.3 that buttons are specified by their display text, the logic upon clicking, as well as the disabling logic.

1. Display text: The text can be as simple as the Add string.

2. Logic upon clicking: As explained above, a new row is added to the "master" table upon clicking. It would also be nice to clear the quantity field after

50 clicking. Suppose the "master" table is called All_purchase_records, then it follows that the formula for the click logic looks like

addRow(All_purchase_records, "userID": uid, "name": name, "price": price, "quantity": quantity); update("quantity", "").

3. Disabling logic: The "Add" button does not need to be disabled at any time, so leaving it blank is fine.

At this point, we have all that we need for the Products and All_purchase_records tables, whose visualization in the design view is presented in Figure 6-1.

Figure 6-1: The Products and All_purchase_records tables in the design view

Next, we build the Cart table as a formula table by projecting from the All_purchase_records table. The formula that defines the Cart table needs to filter the rows of the All_purchase_records table by user ID, and can be coded as

All_purchase_records.filterT(r => r.userID === uid).

After that, we still need to add columns corresponding to what is to be displayed in the Cart table. First of all, the merchandise name, price and quantity columns should be added by creating three columns in the Cart table with the formulae name, price and quantity, which are made possible by the pre-bindings as described in Section 6.1. In addition, there should also be a column of the total price of each merchandise, which is defined by the formula

price * quantity.

The Cart table is constructed completely at this point, and is visualized in Figure 6-2. The table wrapper in which the projection formula is located is also included.

51 Figure 6-2: The Cart table in the design view

Finally, the last table in the shopping cart example is the Subtotal table. The subtotal can be computed by summing up the last column in the Cart table, and is computed by the formula

sum("total_price", my_cart)

, where "total_price" and my_cart are the names of the last column in the Cart table and the Cart table itself respectively. The Subtotal table in the design view is visualized in Figure 6-3.

Figure 6-3: The Subtotal table in the design view

52 Chapter 7

Application Styling in Topiary

Any web application without styling will look dull and unattractive. Therefore, Top- iary as a platform for web application development must provide flexible styling options to application builders. The available styling options are discussed in this chapter.

7.1 Styling Pages, Columns and Cells

In Topiary, application builders can set arbitrary styles on cells in the table. This is similar to the styling menu offered by other spreadsheet tools like Microsoft Excel. To maximize flexibility, Topiary offers styling options that are bound to individual cells, as identified by the IDs of the rows and columns they lie in. Thus, whena row is deleted, the styling associated with its cells gets removed instead of passed on to other cells. The styling options can be found in either the sidebar or the context menu upon focusing on the cells. The design view is presented in Figure 7-1, and the details of what styling options are available are covered in Section 7.2. However, providing only cell-level styling may leave application builders frustrated since they have to apply styling for individual cells multiple times, even if the styling to be applied is exactly the same. Thereby, on top of cell-level styling, Topiary also provides batch styling on columns and pages, that is, the same styling applied across the entire column or page, subject to the rule that styling on the lower level takes

53 Figure 7-1: Cell styling in the design view precedence. That is, the styling on cells overwrites that on columns, and similarly the styling on columns overwrites that on pages.

7.2 Styling Options

This section describes the styling options available to application builders, which are listed below.

1. Boldface and italics

2. Font face, size and color

3. Background color

4. Padding amount

5. Border width, style and color

6. Alignment within the cell, including upward, downward, leftward, rightward and center

54 Moreover, for the sake of maximizing flexibility, application builders can also input additional custom CSS for other styling effects. Figure 7-2 displays how the user view of the shopping cart example can look like with the styling options provided by Topiary.

Figure 7-2: The user view of the shopping cart example after styling

55 56 Chapter 8

Sample Web Applications Built with Topiary

In this chapter, we present some sample web applications built with Topiary, to exemplify what application builders can achieve with Topiary. The following sections show three different applications, including the shopping cart example from Chapter 2, a time tracker, and a room reservation system.

8.1 Shopping Cart

We recall the shopping cart example from Chapter 2. It simulates the online shopping process, in which users can browse the merchandise in stock, pick which they want to buy, and see how much they have to pay. Different components of this example have been covered in the previous chapters, and here we provide a summary. Figure 8-1 shows the user view of the shopping cart application. In the application, users can specify the quantity of each merchandise they want to purchase, and then add them to the shopping cart. At any point, users enjoy the most updated view of their shopping cart, which displays how much users are paying for each merchandise, after taking into account the quantity as well. Finally, the subtotal of the cart is shown to users, stating how much they have to pay in total. The implementation logic of the shopping cart application is detailed in Section

57 Figure 8-1: The user view of the shopping cart application

6.4. In short, in order to store the shopping cart data of all users, we adopt a "master" table whose rows contain both the user ID and the merchandise data. Whenever a user add a merchandise to their cart, the underlying logic is to store his/her user ID together with the merchandise in the "master" table. Yet, we still need to show users their shopping cart. This can be done by building a projection from the "master" table. To be more specific, the shopping cart table in the user view is a formula table that filters on the "master" table by user ID. Finally, the subtotal is computedby summing up the respective prices of all merchandise in the cart. Moreover, Figure 8-1 shows the possibility to hide column names in the user view: the column names of the Subtotal table are hidden. Sometimes it makes sense for users to see the column names because they describe the column data well, but this is not always the case. Therefore, Topiary offers the flexibility to show or hide column names in the user view.

8.2 Time Tracker

Using Topiary we built a time tracker, which allows users to list their day-to-day activities and track how much time they have spent on each of them. Figure 8-2 shows the user view of the time tracker application.

58 Figure 8-2: The user view of the time tracker application

The application has a rather simple interface, with which the users can perform one of the following actions:

1. Add a new activity

2. Start or end the timer of an activity

3. Clear the recorded data for an activity

4. Delete an activity and its related data

The implementation logic of this time tracker shares some similarity with the shopping cart example discussed in Section 8.1. There is a hidden "master" table storing the activities of all users. Whenever a user adds a new activity, the click logic appends a row to the "master" table. The list of activities seen in the user view in Figure 8-2 is in fact a projection from the "master" table with a filter on user ID, and thus is an example of a formula table (as defined in Section 6.3). Similarly, the start/end, clear and remove buttons all interact with the "master" table, and the relevant changes are propagated back to the table seen in the user view according to the formula logic. Moreover, in this time tracker application, all of the styling is applied on a column basis for all tables, including the formula table containing a list of all user activities.

59 In fact, this example shows another advantage of column styling over cell styling, which is column styling works much better with formula tables. Since formula tables are generated dynamically, it is impossible for application builders to apply cell styling on them. On the flip side, column styling applies to all rows and thus aligns wellwith the dynamic creation of rows in formula tables.

8.3 Room Reservation System

A simple room reservation system was created with Topiary. The system allows users to view the availability of rooms, reserve available rooms, as well as cancel any reservation. Figure 8-3 displays the user view of the room reservation system.

Figure 8-3: The user view of the room reservation system application

In the application, users need to first put in their names, which is essential for the formula to identify the mapping between the users and the rooms they have reserved. After that, they can see three categories of rooms, namely the rooms that they have

60 reserved, the available rooms and the rooms reserved by other users. The interface also allows them to check the status of any room by inputting the room number, and has different behavior depending on the status:

1. If the room has been reserved by the user himself, the application shows a "Cancel" button for him to cancel the reservation as he wishes, which pops the room from the rooms he has reserved and inserts it back into the list of available rooms.

2. If the room has been reserved by someone else, the application shows whose name the reservation is under, and does not offer any functionality to modify that reservation, which is the expected behavior.

3. If the room has not been reserved by anyone, a "Reserve" button appears. Upon clicking it, the room will be popped from the list of available rooms and added to the rooms the user has reserved.

61 62 Chapter 9

Conclusion and Future Work

We have built the tool Topiary which adopts the spreadsheet model and helps appli- cation builders create their own data-centric web applications. We have also demon- strated the capability of Topiary by featuring some sample applications in Chapter 8. We have seen that the multi-table view, together with the flat relational data model and the formula language API, can indeed abstract out a lot of otherwise repetitive and mundane coding, and make it easier for application builders to prototype their applications. However, we acknowledge that Topiary can benefit from a number of improvement tasks, as listed below:

1. Security concern – Currently Topiary performs client-side rendering on most things including the logic to determine whether a user is the application builder and thus should have access to the design view. This behavior builds on the assumption that all users are trusted parties. We recognize that this can pose serious security threat when malicious users may take advantage of the client- side rendering and possibly steal data from or modify data in the Firebase database. A remedy is to make use of the in-built functionality of Firebase that defines read and write rules for all users.

2. Data privacy concern – As mentioned in Section 4.2, Firebase Database stores all data in one big JSON tree, which implies that the developers of Topiary gain automatic access to the user data of all web applications created with Topiary.

63 This can constitute a concern for data privacy for those web applications. A possible solution is to re-design the database storage such that each application owns its own database instance that is not shared with Topiary.

3. Sort-by and filter functions – Application builders can create a formula table that acts as the filtered version of another table. However, it may be desirable to give users the option to sort or filter on the values in any column, especially if a table has grown too big in size and become hard to inspect. This also aligns well with the way many shopping websites function – customers are allowed to sort and filter the merchandise with custom constraints.

4. Sign-up method – Currently anyone logged into Topiary can get access to all applications developed with Topiary. This auto sign-up behavior should be modified to a per-application sign-up, since applications are developed inde- pendently and may be unrelated to one another. A possible way is to allow each application to send its potentials users an email with a sign-up link.

5. UI layout – Sometimes the appearance of web applications may benefit from more specific layout arrangement. Currently, application builders can place tables in any arbitrary location on the page, but there is no dependency between the positions of any two tables. It may be helpful to enable table alignment, or define table positions as relative instead of absolute positions.

6. Performance concern – So far all testing of Topiary has been done with small quantities of data, so it is unclear how it will scale with more data. Should the performance become a problem in large scale, solutions like keeping a cached copy of data in local storage map help with limiting database accesses.

7. Multi-page applications – While the data model of Topiary is designed to al- low multiple pages in an application, all development work of Topiary has been focused on building single-page applications. Therefore, the UI design for cre- ating a multi-page application is yet to be determined. Moreover, in that case

64 Topiary needs to support parameterized links that redirect to different pages of the application.

65 66 Bibliography

[1] Alicia Clark and Joseph Hellerstein. Scisheets: Providing the power of program- ming with the simplicity of spreadsheets. In Proceedings of the 2017 Python in Science Conference, 2017.

[2] Matt McCutchen, Shachar Itzhaky, and Daniel Jackson. Object spreadsheets: a new computational model for end-user development of data-centric web applica- tions. In Proceedings of the 2016 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, 2016.

[3] Tyler McGinnis. re-base. https://github.com/tylermcginnis/re-base, 2015.

67