Michael Rees, Human-Computer Communications Centre, School of Information Technology, Bond University, Qld 4229, Australia. Phone +61 7 5595 3351, Fax: +61 7 5595 3320 rees@bond.edu.au
World Wide Web, CGI scripts, Java, graphical user interface, client/server, user interface design
This paper describes design constraints and implementation solutions for converting interactive Web applications, originally implemented as CGI scripts, to the Java language. CGI script applications are already in an application class of their own with a particular set of design constraints. Java and the way it is implemented reduces CGI script application constraints considerably. However, at the same time, Java introduces new freedoms to present and control the user interface but also introduces new constraints of its own to enhance Internet security. This paper addresses the issues faced when converting CGI script applications to Java and offers advice on how the security constraints can be made manifest in the user interface designs. Some example designs of early Java applications are presented.
For the purposes of this paper it is necessary to define the term Web application. Basically, a Web application is taken to be the ability of a user to process information within a Web page while running a Web browser. Characteristics which define a Web applications are:
These characteristics can be of great benefit to some types of application. The first characteristic allows new versions of the application to be deployed very easily - the user obtains the latest version automatically at each use. Provided user interface changes are introduced in a slow evolution then no ill effects are felt by the end-users.
Being required to use a central data repository aids in the sharing of information provided access security features are also implemented. The only reported negative consequence is the users' loss of ownership (being able to take copies on their local machines) of information they have personally created. Knowing that the data repository is securely backed up at regular intervals usually overcomes these fears.
The third characteristic is only a problem over low bandwidth network connections where non-availability and high load conditions significantly interrupt the smooth flow of operations within the Web application. This will be the same problem faced when network computers are introduced.
HTML forms and associated CGI scripts were introduced into the Web architecture to allow two-way interaction via Web pages. The user interface elements allowed in forms (buttons, text field and selection lists) supply a basic but effective way of providing text-based data entry and display within a Web page. These interactive elements are traditionally found in direct manipulation interfaces. Therefore, conventional user interface design techniques can be applied which are now liberally described in general texts such as Preece et al in [Preece]. The interactive nature of forms linked to CGI scripts has naturally attracted the attention of application designers who seek to exploit the ubiquitous presence of Web browsers to support user interface requirements.
When designing user interfaces with HTML form components some severe restrictions become apparent. The problems for user interface designers are described in detail by Rees in [HREF1] where six major limitations are identified. In that paper Rees indicates that switching to a Java implementation can overcome these limitations which proved to be the case. However, Java introduces some new limitations of its own which must be manifested in the user interface designs so that the end user can be aware of the constraints of the Web application environment.
Of course, HTML forms and CGI scripts are additions to the basic hypertext facilities of the Web. There is much previous work which addresses the user interface design issues of hypertext systems. The design issues of paramount importance are:
Previous research findings can be applied to the design of Web pages. Tools such as GenTL from the Web structuring group led by Thimbleby [HREF2], [GenTL] and [Theng], impose and verify the hypertext node structure and integrate with other tools to compose and edit the node contents. Other interesting work on active links concentrates on creating efficient navigation aids which minimise the additional content yet provide sufficient hints to the user to prevent unnecessary link click-and-go-back loops [Jones]. Furthermore, much useful feedback can be gained by the analysis of node access logs which record every link followed by every user accessing a page web.
The architecture of a CGI script Web application can be simply described as:
Interaction with the CGI script ends when the Web page at step 2.3 contains no further links to the CGI script. This allows CGI scripts to be used to calculate a link in a dynamic manner to allow procedural navigation to a series of Web pages.
Steps 2.1 and 2.3 involve network transmissions on uncertain duration which may extend to several seconds or more on a heavily loaded network. The response times are therefore usually much in excess of those expected by users running applications directly on their local machines. This is a severe problem for Web applications. Nevertheless, such a primitive response cycle has not discouraged the implementation of a number of production-quality applications. A good example is the Ontology editor from Stanford described in [HREF4]. This excellent paper describes in detail some the workarounds used to overcome layout and response time problems.
Another example of a Web application implemented with CGI scripts is PowerSlide [HREF5] written by the author of this paper. With PowerSlide a user can create a slide show which is a series of linked Web pages in a format suitable for presentation slides. A title slide, topics slide with links to the regular slides are generated by the CGI scripts. Within a Web browser a user simply types the title text, author, topics, slide titles and so on, and specifies the text for the bullet points on each slide. No knowledge of HTML is needed, and once the slide show has been created, opening the title slide gives the presenter access to series of linked slides. PowerSlide implements a centralised repository for slide shows within an organisation. All shows have a similar structure for a consistent, corporate image.
Perhaps the ultimate Web application built with CGI scripts is described in [HREF6]. Crespo and Bier have implemented a complete HTML page editor which also allows dynamic components to be added to pages. The whole implementation uses CGI scripts, but the scripts call complete editor applications written in C++. However, as with all CGI Web applications, the basic user interface is a series of (very complicated) forms containing a very large number of buttons and image maps made to look like buttons. The sheer scale of the implementation is impressive, and their paper forms one of the best illustrative examples of this type of Web application.
Despite these and other examples, the long response times inherent in CGI script Web applications are not tolerable in many commercial and time-critical situations. Some relief from response time delays is possible for form field validation and interlinking but the use of JavaScript [HREF7] which is incorporated within the HTML as it is generated. JavaScript functions are interpreted on the users' own machines by the Web browser and allow many checks to be performed on entered data before finally being passed to the CGI script as usual. Some other benefits of using JavaScript are outlined by Rees in [HREF8]. In almost all cases, however, the response time problems can be substantially eliminated by reimplementing the whole Web application in Java.
Applets written in the Java language are composed of a number of class files containing binary bytecodes intended to be interpreted by a Java virtual machine. Java applets are embedded in Web pages by including an APPLET tag which specifies the initial Java class file as a URL to be loaded separately by the Web browser. On arrival at the client machine, the applets can be interpreted by the Java virtual machine in the Web browser in a secure environment of the browser's choosing. In other words, the browser can prevent access to certain facilities on the client machine considered to be unsafe.
Being a true general purpose language, Java has access to a rich set of class libraries which support production quality data processing, file handling, network protocols and a multiple-window, direct manipulation, graphical user interface. This makes it an ideal language for Web applications since the client applet set has considerable processing capability and can implement any suitable network protocol to provide responsive interaction with a network server. This allows Java applets to completely replace CGI scripts with a graphical user interface frontend which communicates to the server backend processing.
A Web application can be implemented as a set of Web pages each containing one or more Java applets. Thus the Web application can be built and used in an incremental fashion. This exploits the dynamic loading of Java class files so that only those class files actually needed by the current user task need to be loaded. In this way the user interface components are loaded as and when required to achieve the desired remote user interface with its benefit of real-time update capability.
A commercial Web application written as a Java applet will consist of many class files each of which may require a individual request-response cycle between Web browser and Web server (usually the common base classes will be loaded from the local machine). This situation is to be alleviated with the Java Development Kit version 1.1 which allows aggregations of Java classes and their associated data files (mainly images) to be compressed and downloaded in a single request-response cycle. Even so, the user interface designer must take into account that Java applets have a relatively slow startup response time. This leads to the need to introduce the user to the facilities of the applet in an incremental fashion so as to minimise the number of Java classes loaded initially.
Figure 1 shows a breakdown of the various data manipulations that occur in a Web application implemented with CGI scripts. As has been described most of the processing occurs in the CGI script executing on the Web server. Only the user interface presentation and form field capture (any possibly JavaScript validation) is performed on the user's client machine.
Figure 1. CGI script Web application architecture.
Moving to a Java applet implementation leads to a different distribution of the data manipulations between Web browser and server as shown in Figure 2. At first sight the change may appear small, but the bulk of the processing of the entire Web application is present in the 'Data process' oval in both Figures 1 and 2.Bear in mind that data processing encompassed both the raw manipulation of the data and the time consuming operation of regeneration of the user interface in response to user interactions. It is just this user interface regeneration aspect of CGI script Web applications that suffers from poor response time.
Figure 2. Java applet Web application architecture.
In Figure 2 all possible processing is performed at the client end, including the all-important user interface regeneration. Only operations that would contravene the Java security model, namely file input/output and unlimited network access, need to be relegated to the server. Web servers can be used to some extent for retrieving data from files, and some Web servers also support mechanisms to save data files in a controlled manner. All other file access and unlimited network access must be implemented in a server written as a free-standing Java application running alongside the Web server. File access, in particular, tends to be an infrequent operation and, for small to medium amounts of data, the typical network speeds are not substantially different from hard drive speeds.
A good example of this architectural transition is the PowerSlide Web application [HREF5] mentioned above. JSlide is a new version of PowerSlide based on Java applets. JSlide has been designed with an identical architecture to that shown in Figure 2. To provide the simple side show repository, which PowerSlide implements, it has only been necessary to write a JSlide server with less than 300 lines of Java code. The client side classes in the JSlide applet which communicate with the JSlide server amount to less than 150 lines of Java. The remainder of the approximately 1400 lines of PowerSlide CGI script in Perl 5.
The JSlide applet can be used to both create and present slide shows of generated Web pages. The presentation interface is straightforward with a slide Web page being displayed in another frame in the Web browser window under control of the applet. The more challenging user interface designs occur with the slide show creation and editing facilities. The user interface design issues are more import than the architectural ones and are described in detail in later sections.
One disadvantage of the Java applet architecture is the need to make provision for starting the server which runs along side the Web server. Installing a CGI script Web application simply requires the some HTML pages and script or scripts to be placed in suitable directories accessible by the Web server. When a user accesses the appropriate Web page and clicks a button or hyperlink, the Web application runs under the control of the Web server. In contrast, the Java applet Web application installation starts in a similar way by copying HTML pages and Java class files into Web server directories, but requires the extra step of arranging for the Java server to start automatically. This can use the same mechanism that starts the Web server, but is an added complication for installing Java applet Web applications.
The two major challenges for Java applets are whether they can deliver the same:
as applications running locally in the standard operating system environment.
In the first full release of the Java Development Kit (JDK) Sun provided a reasonably extensive package of graphical user interface classes, the Abstract Windowing Toolkit (AWT), that are carefully designed to be portable to the major operating systems platforms. Inevitably, Web application designers seek much richer functionality for their graphical user interfaces and are tempted to create their own framework as extensions to the AWT classes. At the same time they must be aware of the need to maintain multiple-platform portability and multiple Web browser capability. These are novel challenges for user interface programmers.
One of the first companies to address this problem was Netscape when it produced its Internet Foundation Classes [HREF9]. An example IFC applet appears in Figure 3. Note that the emphasis in this design is the use of 3D buttons and text manipulation. Th class implementers have also concentrated on presenting distinctive window manipulation ornaments and control to provide the user with visual clues about this particular user interface framework. Netscape have now produced a prototype of a visual builder tool called Constructor [HREF10], and itself written in Java, to ease the construction of IFC user interfaces.
Figure 3. An example Internet Foundation Class applet.
Another example graphical user interface framework is Bongo from Marimba [HREF11]. This framework is more extensive and aims at emulating conventional user interfaces found in 'office' suite applications. Figure 4 shows a screen taken from a sample available from the Bongo pages.
Figure 4. Bongo Presentation Manager - text widget examples.
Many other graphical user interface frameworks are under construction in other companies, Microsoft and IBM, for example. All of these frameworks strive to maintain compatibility with the underlying Sun AWT classes so that the new frameworks are still portable across different platforms.
Another major user interface design decision is the approach to the overall interaction strategy. Java applets exist in the world of the Web so the designer has a choice of two main approaches:
Web style: plain or image-based buttons trigger actions
Office style: menus trigger actions with occasional shortcut buttons on toolbars
The first approach was the only one available for CGI script Web applications. With Java applets the designer has the choice. Figure 3 shows an example of the first approach. An example of the second appears in Figure 5 which is a screen shot from IBM's AppleAuthor application. This provides an applet generation facility for users who know no Java. Instead, applets are built from a set of standard components, Java source generated and compiled, and the user presented with a finished applet to include in Web pages. Here the traditional style of office suite applications has been emulated in Java, even to the extent of the collection of small 'tool' windows which appear in front of the main window.
Figure 5. IBM AppletAuthor.
The final user interface challenge for Java applet Web applications mentioned above was how to make manifest the Java server environment in which applets execute. A good example of this appears in Figure 6 which is a screen shot of the marimba Castanet tuner [HREF12]. Castanet automatically distributes and maintains software applications and content within a company or across the Internet.
Figure 6. Castanet tuner screen.
The Castanet interface exhibits several important features of Java Web applications. The visual clue to the remote information environment appears in the list of remote sites with IP addresses shown. To give the user some encouragement a conventional Explorer interface similar to Microsoft Windows 95 is adopted. (This hierarchical representation is very commonly required and it is a pity such support was not included in the AWT classes.) A compromise between menus and buttons is evident in the use of a tabbed record style for switching between screens.
Perhaps the most important aspect of a Java Web application interface appears at the bottom of the screen in Figure 6. This is the progress indicator which is the best way to reduce user frustration when the application is having to contend with poor network response.
Web applications implemented as CGI scripts operate in a unique environment, and, although effective for some purposes, suffer from unresponsive user interfaces. Switching to the use of Java will improve responsiveness of the user interface so that it compares favourably with conventional, free-standing applications. However, a series of new constraints are introduced which Java Web application designers must overcome. In summary, these constraints are:
These constraints offer significant challenges to implementers and must be carefully taken into account when designing Java Web applications.
Michael Rees © 1997. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the author.
[Presentation] [All Papers and Posters]