NSF Proposal Programming Dynamic Web Pages By Example
Motivation
Without writing code, designers specify database schemas, complex spreadsheets, and the layout of user interfaces. They also use macro-recording to specify small programs by demonstration. Generalization techniques from programming by demonstration research have increased the complexity of the programs that can be created in this macro-recording like manner.
Unfortunately, these end-user techniques from various domains have not been adapted to dynamic web page development -- building such pages still requires advanced programming skills. Emerging tools such as WebMacro and XMLC allow designers to specify the layout of dynamic content, but not the content itself. A programmer is required to build dynamic web pages that access and manipulate any type of persistent data (e.g. a database or XML file).
Macromedia’s Ultra-Dev4 (formerly ColdFusion) is an exception: without coding, an UltraDev4 developer can create a complete dynamic web page, including one that display live database data and allows the end-user to manipulate that data. UltraDev4 development is dialog-based with some direct-manipulation. The system does not provide end-user programming techniques found in programming by example (PBE) research, visual database research, and spreadsheet systems. To our knowledge, no other commercial or research systems apply such techniques to web development either.
Objective
The objective of the proposed project is to adapt and combine existing end-user techniques to web development, so that designers can create complete dynamic web pages without programming. The techniques will be applied to an interactive development environment based on a what-you-see-is-what-you-get (WYSIWYG) HTML editor. Designers will use Query by Example (QBE) techniques to specify views of persistent data, spreadsheet formulas to specify computations on data, and PBE to specify interactive behaviors for manipulating persistent data. Extensive user studies will be performed to test the techniques compared to other paradigms such as UltraDev4-like dialog-based development. User studies will also be performed to test the system as a whole, as combining QBE, spreadsheet formulas, and PBE within one environment presents a challenging user interface problem.
The following sections present the project sub-objectives in detail.
1.1 Layout and Formatting by Example
The proposed system will allow a designer to visually specify the layout of the page by placing widgets in the page being edited, and specify the format of dynamic data by working on prototypical data. Some widgets, like the dynamic table, can be mapped to persistent data through dialog-based specification (we will consider eliminating this dialog in 1.4). The first row of “live” database data is displayed in the visual table and the designer can use editor operations to specify its formatting. For instance, the designer might italicize the name “Wolber”, as in Figure 1:
Table: STUDENTS
Name Test1 Test2
Wolber
/ 87 / 90When the page is rendered at run-time (e.g., the servlet is executed in a browser), the names in the first column of all the rows will be italicized.
1.2. QBE and Spreadsheet Formulas
QBE, first introduced in 1971[], has become a common technique in commercial DBMSs. Instead of writing queries, the designer enters expressions directly in the cells of a table. The system then generates a query that, when executed, populates a visual table with a view of a database table. Spreadsheets are the most common form of end-user programming. Spreadsheet formulas are similar to QBE, but instead of specifying a selection of rows from a database table, they specify computations on data. One project sub-objective is to explore QBE and spreadsheet formulas within the web page development environment, as in Figure 2:
Table: STUDENTS
Name Test1 Test2 Average
Wolber
/ 87 / 90 / =Average(C2:C3)>85
Here, the designer added a fourth column to the table, and specified a spreadsheet formula for it. Because the table is mapped to a database, the formula is automatically applied to all rows of the table at run-time.
The designer also entered a Boolean expression in the second row of the table. The proposed tool interprets all entries in the second row as QBE strings and thus generates the following query:
Select * from STUDENTS where Test2>80
At run-time, the table will only display students with a Test2 score of greater than 80.
Providing an effective user interface for such development will be a challenge. The user interface must be designed so that designers understand that, unlike those in an actual spreadsheet, the formulas in a database-mapped table are applied not just to the specified row, but all rows in the table. Furthermore, QBE strings and spreadsheet formulas are quite similar in nature, and at least in the proposed user interface they are entered in nearly identical ways. Developing a viable interface combining these approaches will require numerous development iterations and user studies.
1.3. PBE Macro-Recording
QBE and spreadsheet formulas can be used to specify the rows of a database table that should appear in a visual table and the computations on the data in those rows, respectively. However, these techniques do not provide a method for specifying interactive behavior, such as the activities that should occur when a submit button is clicked, and they do not provide methods for modifying data in a database table.
Another project sub-objective is to explore PBE macro-recording techniques for filling this void. Consider the following scenario. A designer enters some data in an input form, specifies a particular submit button, then turns on a macro recorder. The designer then demonstrates the creation of a new row in a table (perhaps on another page), and copies the data in the input form into the cells of the new row. When the designer ends the recording, the system generalizes from the example. In this case, the system interprets the designer’s example to mean that, when the button is clicked, a new database record should be created using the data input into the form.
Adding PBE capabilities to the environment will be particularly challenging. To our knowledge, applying PBE to interactive database manipulation (or persistent data, in general) has not been attempted. Specifying an AddRow such as in the above example appears straight-forward. But what about delete and modify operations? What about interactive queries in which part of a query comes from an input form? What if the underlying data is a complicated relational database or XML file? What if there is not an exact match of input data and result data in the designer’s example?
Adding any mode complicates a user interface. What will happen when a record mode is added to an interface already complicated by spreadsheet formulas and QBE strings? Will only certain types of designers adapt to it, and if so, which types?
1.3. Specifying the Structure of Persistent Data in the Interface
The objectives above presuppose an existing persistent store (e.g., database) and a dialog-based method of initially mapping a visual table to a database table. Thus, an end-user must be familiar with a DBMS to create a database, then be familiar enough with database drivers, pools, etc. to map the visual table to the database table.
Another sub-objective of the project is to devise end-user techniques that allow a designer to specify persistent (database) data directly in the HMTL editor interface-- the designer enters sample data in the cells of a visual table, and the system creates a database table for him along with the connection and mapping information. In this way, the designer is shielded from database details and only need understand that the visual data represents persistent data. Furthermore, the designer need only specify data once using a single specification technique, as opposed to specifying it in a DBMS (or other form) and then again in the user interface (view).
Most existing DBMSs allow table specification using sample data. The scheme described above is different in that table specification is performed in the user interface itself. Such a scheme flows against the long-held view of model-view separation, i.e., that content and presentation should be specified and stored separately. But is this separation of vital importance in end-user programming, or does the need for concreteness overshadow it?
Another issue is whether or not table relations can be specified by example in the user interface. For instance, if a designer entered a table within the cell of another table, the system could deduce that two or even three database tables should be created—one corresponding to both the inner table and its containing table, and one table that maps ids from the two other tables. Such a simple scheme would allow simple relations to be defined, but could the scheme be extended so that an entire relational database could be specified? A related issue is how the system would need to be modified if the underlying data format is XML instead of a relational database?
1.5. Combining Techniques
Applying each of the various techniques to web page development is challenging, but their integration into a single user interface may prove the most difficult task. As proposed, the designer manipulates visual tables for four different reasons: i) to specify query strings, ii) to specify spreadsheet formulas, iii) to specify a response to a submit button, iv) and to create a persistent store. Is such a radical combination of techniques too much? Only extensive user studies can answer this question.
- Expected Significance
The web revolution has created a huge pool of designers eager to create dynamic web pages. The significance of techniques that even remotely increase the creative capabilities of these designers is enormous.
The proposed techniques open traditionally closed development areas to the web designer-- database specification, access, and manipulation. They do not allow all dynamic web pages to be designed without programming. PBE research has been criticized for not scaling up—creating exploratory systems good at building “toy” applications, but lacking generality. But such an attitude ignores the iterative nature of the software development process. Providing a designer with the tools to create a prototype, or first iteration of a complicated dynamic web page, is quite significant.
The project is significant to PBE research because of its adaptation to a new domain, and it's novel application to the specification of persistentdata. It is significant to visual database research in its extending example-based methods of querying to database manipulation and schema creation.
It is significant to spreadsheet research in its applying formulas to web interfaces and combining formulas with QBE and macro-based PBE.
3. Relation to Longer-Term Goals
The principle investigator has spent his research career building tools that expand the
creative capabilities of end-users. To date, he has focused on development tools for graphical, animated applications such as games and simulations. Applying the techniques he has learned to
dynamic web page development constitutes a new challenge and one that could reach a huge audience.
- Relation to present state of knowledge in field
The proposed project is related to a number of fields, including the PBE sub-area of human-computer interfaces, databases, spreadsheets, and web development. Because of the rapidly changing world of the web, emerging commercial systems will be considered along with published research.
PBE
PBE has been applied in a number of domains, text and graphics editors, but it has only recently been applied to dynamic web pages[]. The web-related efforts have concentrated on PBE techniques for inducing wrapper programs by example. Wrapper programs are programs that access data from existing web pages then display it in a composite page. PBE wrapper builders allow a designer to point out data of interest on a page, then the system formulates a general description of that data based on context. Such a contextual description is necessary so that the wrapper program need not be modified every time one of web pages it accesses is changed.
The proposed project is different in that it focuses on building web pages that access databases directly (not through another web page). Whereas wrapper-inducing systems focus on formulating contextual descriptions of data from examples, this project will focus on formulating interactive database operations from examples, including queries, manipulations, and the data specification.
4.2 Query By Example
There have been numerous extensions of the original QBE, including query by templates [] and trigger by example []. The proposed system will apply QBE techniques in the context of web page design, and in conjunction with spreadsheet formulas and PBE.
4.3. Spreadsheet Systems
The spreadsheet is the best example of end-user, programming-in-the-interface development. Research efforts [Burnett] have focused on extending the spreadsheet paradigm to allow non-tabular data elements and logical instead of spatial generalization of formulas. Some have focused specifically on adding spreadsheet capabilities to a user interface development environment [Hudson,?]. The proposed system will apply spreadsheet capabilities in the context of web page development, and in conjunction with QBE and PBE macro-recording.
4.4. XML and XML Query
XML is an emerging standard for data exchange. XML query languages [] provide access to XML data in an SQL-like fashion. [semi-structured data…compared to structured data in databases]Visual XML query languages like xing[] and XML-GL[] are the XML versions of QBE.
The objective of the proposed system is to allow end-users to visually specify web interfaces to persistent data, whether that data is direct from a relational database, or in XML format. A commercial system might provide options for various types of generated code (XML, JDBC database access, EJB). However, the underlying code is not the focus of this research project, so the proposed system will generate only one type of code (JDBC).
4.5. Commercial Web Development Tools
The Java II Enterprise Edition framework has become extremely popular for web development. Servlets, the basis of the framework, are Java programs that dynamically generate web pages containing dynamic data. Unfortunately, many designers cannot write Java code. Because of this, a number of frameworks [] have emerged which allow designers to specify the presentation of a dynamic page visually or in HTML extensions, while allowing a programmer to focus on writing code that accesses and computes the dynamic content.
The XMLC compiler is one such tool. It takes an XML or HTML page, created by a designer, as input, and outputs a java code representation of the page (in the Document Object Model (DOM) format). A programmer can then write Java code that manipulates this representation to insert dynamic data into the presentation. The designer can edit his “template” even after the dynamic part has been coded, then run the template through the XMLC compiler again. In this manner, the concerns of the designer and programmer are kept separate, and the designer can edit and format the presentation without requiring programmer intervention.
Whereas XMLC-like tools help designers format the presentation of dynamic web pages, Macromedia’s Ultra-Dev4 (Cold Fusion) extends the capabilities of designers by allowing them to also visually specify the actual dynamic content. The system provides dialog-based specification of queries and data manipulation. Though the dialogs eliminate some of the syntax problems inherent to regular programming, they don’t take advantage of example-based specification techniques like those proposed.
- Relation to work in progress elsewhere
- Workplan
5.1. Design of Activities
5.1.1.Literature Survey
5.1.2.Product Survey
servlets.com
5.1.3. Student Training
Students who have not learned the skills in course-work will be taught Java Servlet programming, JDBC, and XMLC related technologies.
5.1.4.Exploratory System Development
5.1.4.1. Iteration 1: HTML Editor
The team will develop the base editor using HTML editor classes provided in the Java Development Kit. The Command pattern [] will be used to ease the upcoming task of recording operations.
5.1.4.2. Iteration 2: Live Database Data and Layout by Example
The team will implement dialogs that allow the designer to map columns of a visual table to columns of a database table. The system will generate an HTML template and a servlet. The HTML template will be compiled with XMLC to create a DOM-tree version of the dynamic page. The generated servlet will contain JDBC code to access the database, and DOM-tree manipulation code to insert the data into the generated web page. Informal user studies will be performed at the completion of this iteration to refine the techniques.
5.1.4.3. Spreadsheet and QBE Formulas
The team will implement spreadsheet and QBE formulas within the development environment. Excel formula evaluators will be accessed through a COM interface, both at development time and in the generated servlet code.