Download NSF Project Descript..

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 directmanipulation. 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-whatyou-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
NSF Proposal
Programming Dynamic Web Pages By Example
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
90
When 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
NSF Proposal
Programming Dynamic Web Pages By Example
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?
NSF Proposal
Programming Dynamic Web Pages By Example
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.
NSF Proposal
Programming Dynamic Web Pages By Example
2. 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 persistent data. 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.
3. 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
NSF Proposal
Programming Dynamic Web Pages By Example
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).
NSF Proposal
Programming Dynamic Web Pages By Example
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.
4. Relation to work in progress elsewhere
5. 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.
NSF Proposal
Programming Dynamic Web Pages By Example
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.
5.1.4.4. PBE Database Manipulation
5.2. Description of Experimental Methods
6. Broader Impact
6.1 Integration of Research and Education
The PI recently designed one new course and redesigned another to emphasize web development, and
specifically the Java II Enterprise Environment. The plan is for students to learn the basics of Java
Servlets, JDBC, XMLC, etc. in the first part of these courses, then implement portions of the proposed
research system near the end of the semester. Top students would then continue on the research system
after the semester.
Working with designers who are not programmers will enhance student’s ability to build effective user
interfaces.
6.2. Broadening the participation of underrepresented groups;
Non-programmers are underrepresented within the software development community. The system built
by this project will allow non-programmers to more fully participate in the software creation process.
NSF Proposal
Programming Dynamic Web Pages By Example
6.3. indicate how the results of the project will be disseminated broadly to enhance scientific and
technological understanding; and,
The system will be made publicly available.
6.4. identify potential benefits of the proposed activity to society at large.
The system built by this project will allow non-programmers to more fully participate in the software
creation process. The system will increase the productivity of all designers.