Exploiting the Full Web User Interface Spectrum

Abstract

Applications which exploit the graphical user interfaces of Web browsers are appearing at a growing rate and will become more prevalent in future. Such client-server applications can exploit the hardware platform independence of the Web user interface. However, there are limitations on the user interface features which can be supported by Web browsers.

Over recent months a variety of mechanisms have become available to push back most restrictions and provide a spectrum of Web user interfaces. This leaves the designer of Web-based client applications with the difficult choice of which user interface mechanism to choose. The capabilities and trade-offs of the Web user interface spectrum are described in this paper and some simple guidelines are developed which lead the application designer to the correct choice of user interface mechanism. Some examples of user interface components are presented to support the guidelines.

Web User Interfaces

The presentation and display of Web page content relies on the features of the HyperText Markup Language (HTML). Primarily defined for static display of text and graphic images, HTML is evolving to cater for much more sophisticated content examples of which are:

• multimedia content such as animation, sound and vision
• specialist content such as high-resolution documents and images
• industrial-strength client-server applications

The delivery and user interface requirements of these new types of page content far exceed the provisions of the original Web architectures for network protocols and information display. It is not surprising that a variety of additional features have been proposed and implemented in different ways and in different Web browser applications in an attempt to keep up with user demand.

Client-server applications deployed across the Web architecture face severe problems. This is primarily due to the one-sided nature of the HyperText Transport Protocol (HTTP) which essentially invests control over Web transactions in the end-user client application (browser). The display of Web pages is triggered by a client request and the fulfilment of that request by the targeted Web server. More traditional client-server architectures allow requests to be generated in both directions. Of course, client-server applications on the Web will most probably need to incorporate multimedia and specialist content as well.

Making use of Web browser technology, though, brings enormous benefits to client/server applications:

• Although the server software may be hardware platform dependent, the users employ off-the-shelf clients available on multiple hardware platforms. Most users will be familiar with the client user interface as new applications are introduced.
• Global delivery of the application is possible over the Web.
• Software upgrades on both the server and in the client can be made instantly without the knowledge or intervention of the user. There is therefore no distribution problem.
• When suitable, secure charging is implemented in the near future, users may be charged by use rather than having to purchase the complete application.

It is not surprising that despite the implementation problems client/server application developers are going to great lengths to shoehorn their software into the Web environment.

The main downsides of this approach are:

• There is limited or no control of response times on the Web because of the asynchronous technology employed.
• Individual transactions via the client user interface are stateless since each transaction is atomic and independent of all others.

The Web architecture evolution mentioned above has attempted to address these problems. Unfortunately, a number of different solutions have been proposed and implemented, and not every browser supports all solutions. In addition, adopting one solution or another considerably affects the training and development costs for Web client/server applications. This paper attempts to describe the range of solutions now on offer and to point out the concomitant costs of each solution.

Web User Interface Spectrum

The Web user interface spectrum refers to the range of user interface elements and capabilities which are now available to client/server application developers. For ease of reading the term Web application will be used for the typical client/server application running in the Web environment. Web applications involve the user submitting choices or new data values to be transmitted to a server which then replies with the display of new page content.

The continuum of the Web user interface spectrum comprises the following components:

1. forms and Common Gateway Interface (CGI) scripts
2. frames
3. Javascript
4. Java applets
5. plug-ins
6. helper applications

Generalising the aspects of difficulty of the coding effort and the portability of the final code, Figure 1 shows this spectrum in a visual manner.

Figure 1. Web User Interface Spectrum.

Only components 1 and 4 offer true hardware platform independence. However, the dominance of the Netscape browser allows components 2 and 3 to be considered independent of hardware also. Components 5 and 6 are essentially free-standing applications which obviously must be developed for specific platforms.

HTML forms have been available for some time and bring the simplicity of traditional forms interfaces to a Web page. Interface elements which allow interaction with the user are:

• editable text lines and field boxes
• checkbox and radio buttons
• command (submit) buttons
• popup menus
• scrolling lists allowing single or multiple selection
• image maps

A good example of a user interface using these standard form features is the PowerSlide Web slide show manager written by the author [Rees]. All interface elements apart from image maps are represented, and the user interface is represented as a series of forms with the clicking on one of the submit buttons causing the interaction to take place.

The above list of user interface elements is a reasonably comprehensive list and allows the design and implementation of a wide range of form-like user interfaces. A menu bar with pulldown menus (list of command buttons) and a combo box element (scrolling selection list but with additional option entry) would ease Web forms interface design somewhat, but are not essential. This is categorised as User Interface problem 1 (UI1)

Layout of interface elements is controlled by the HTML layout rules which are a little restrictive for two dimensional user interface design. However, the use of borderless tables, which are widely supported by browsers, can alleviate most layout problems. Nevertheless, layout difficulties make up UI2.

The user interface interaction cycle is:

1. user clicks a command button
2. browser sends state/contents of form elements to Web server
3. Web server runs (CGI) script to generate new HTML page to transmit to browser
4. browser displays new page

Given reasonable Internet bandwidth, this cycle is adequate for whole form transactions where response time is of the order of a few seconds. However, forms are also used as dialog boxes to alert users of inconsistencies of input or to ask for confirmation of potentially irreversible transactions. Here Internet bandwidth, UI3, can be a problem since users of free-standing applications are used to almost instantaneous response from dialogs.

The browser does give immediate feedback on the state of each individual interface element, such as toggle radio button, select option and edit field. Nevertheless, effective user interface design requires interface elements to be tightly coupled. For example, the state of a radio button may mean that other buttons/selection/fields should be disabled (grayed out or absent) since their selection is not appropriate for that state. With standard form elements the server cannot directly control the state relationships between them on a tightly coupled basis, UI4.

One excellent customisation facility of Web browsers is to allow users to dictate the size of the Web page display window. This aids hardware platform independence (no assumption of screen resolution) and user preference (font size and screen width can be adjusted to aid readability). For the user interface designer, however, there can be no guarantee that a particular layout of interface elements will be duplicated on every user screen. Thus layout control is lost and become user interface problem 5 (UI5).

The very serious architectural problem of non-persistent state mentioned in the first section 'Web User Interfaces' also impinges upon the user interface. The liberal history and page caching mechanism of most browsers which allows users to return to pages previously visited in the current session aggravates the problem. By returning to a locally cached copy of a page containing form interface elements it is likely that their state and/or contents do not reflect the actual values stored on the server. Assuming that the server performs consistency checks then apparently correct user input may generate error reports to confuse the user. This lack control of user interface state is identified as user interface problem 6 (UI6).

Table 1 summarises the main user interface problems that must be solved for commercially acceptable Web applications to be possible. [Rice et al] also report very similar problems to these in their use of CGI scripts. The extent to which other components on the Web user interface spectrum offer solutions is now discussed.

Improved Web User Interfaces

New HTML tags to support frames have been introduced by Netscape in their Navigator browsers. Frames completely solves problem UI5 and helps to address UI2. The display window can be split into any number of rectangular areas not unlike the cells in a table. Each frame corresponds to a separate HTML document. Small frames may be set aside for navigation controls, state information and indexes, while other, larger frames in the same window are used for the main content display.

Whatever size chosen by the user for the actual display window in the browser then frames with relative dimensions adjust automatically. However, frames may be specified to occupy fixed pixel dimensions, and may or may not allow the user the freedom to resize individual frames. So as not to completely freeze out other browsers which do not support frame tags, a NOFRAME tag allows alternative page contents to be specified free of frames.

Figure 2 illustrates the ColorCenter application [Dortch] and shows the type of control a user interface designer can achieve with frames.

Figure 2. Example of a Frameset.

As the user resizes the main viewing window, then the individual frames resize in sympathy except where the developer specified fixed size frames. The cost of using frames is:

• minor training for the developer to learn frame tags
• significant restructuring of Web pages since each FRAME tag in the additional FRAMESET page must link to a separate HTML document
• some loss of control over user interface presentation -- the individual frames load in a non-determinate order which can cause some confusion to the end-user
• familiarisation of the user with the additions to the browser interface for frames (navigation, history and frame window controls are different)

Nevertheless, frames offer a very significant improvement to user interfaces in the Web browser context.

Javascript from Netscape [Javascript] is an interpreted scripting language which is incorporated within HTML Web pages. After downloading as part of an HTML document, statements in Javascript are interpreted on the user's workstation by the Netscape Navigator browser. Thus, 'execution' of Javascript statements is immediate and can respond to user interface events such as dialog handling in real-time. User interface problem UI3 is solved for certain classes of interaction.

Javascript is a subset of the Java language [Java] containing:

• a set of predefined events related to the Web user interface events and the loading of Web pages
• a set of objects related to the contents of a Web page including windows, documents, forms, form interface elements and their values/states, and links

Even short sequences of Javascript statements can have powerful and immediate effects such as changing the contents of the window or individual frames, performing substantial validations and calculations on the contents of interface elements, and dynamically generating HTML for immediate display. In particular, Javascript has immediate control of interface elements in terms of enabling/disabling (ie graying out) in response to user events such as mouse movements, mouse clicks and text entry. Javascript thus offers a complete solution to user interface problem UI4 but does not offer any new types of user interface elements (UI1).

A good example of a responsive Web user interface written completely in Javascript is shown in Figure 3. The calculator [Horn] is built out of standard HTML elements such as tables and submit buttons. This simple calculator controls button clicks and the manipulation of text fields. For forms interfaces it is very important to be able to validate the correctness and completeness of user input before triggering a transaction via a CGI script. Javascript is perfect for this role, and allows all the necessary checks to be performed in real-time on the client machine with all the responsiveness required.

Figure 3. A simple calculator.

As well as being an example of frames, the ColorCenter application in Figure 2 is also a good example of the use of Javascript. Clicking on the Try it! button triggers a script to generate HTML to display the new text and background colours in the frame to the left without the need to contact the Web server. Thus response is equivalent to that of applications running locally on the user's workstation.

The cost of using Javascript is not insignificant:

• developer must learn the language, the objects in the Web environment and HTML context in which to place the Javascript statements
• if using frames, then the distribution of bodies of Javascript between frames is significant and requires careful design

A bonus for Javascript is that it is transparent to the user of the Web application. There is no apparent visual change to the Web interface. Bodies of Javascript are interpreted automatically on certain user interface events with Javascript interfacing seemlessly with existing Web pages.

Sun, the Java language developers, describe it as 'a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language'. For the current discussion the key words here are distributed and architecture-neutral. Java supports programming for Web applications in the form of platform-independent Java applets. Applets in a binary bytecode format are downloaded separately from the Web pages which reference them. On arrival at the client machine, the applets can be interpreted by the browser in a secure environment of the browser's choosing. In other words, the browser can restrict access to certain facilities considered unsafe on the client machine.

Being a general purpose language, Java has access to a rich set of class libraries which support access to production quality data processing, file handling, network protocols and a multiple-window, direct manipulation, graphical user interface. This makes it ideal for Web applications since the client applet set has considerable processing capability and can implement any suitable network protocol to provide responsive interaction with the server. This allows Java applets to completely replace CGI scripts with a graphical user interface frontend which communicates to the server backend processing.

A major test for Java applets is whether they can deliver the response times and user interface functionality as applications running locally in the standard operating system environment. An area that demands very low response times is computer games. Users can judge the success of Java applets by perusing the elementary games, written entirely in Java, at [Applet Arcade].

A growing trend is to provide general-purpose applets which can be parameterised when placed within a Web page. Excellent general-purpose Java applets are available from Macromedia Inc. Called PowerApplets [Power Applets], they add graphical and animation facilities to Web pages. Figure 4 shows one frame from the Banners applet which animates text and images within a small, rectangular banner area.

Figure 4. A frame from the Banners PowerApplet.

Users of the PowerApplets need know nothing of the Java language. They simply insert an APPLET tag in their HTML files with appropriate parameters. A fragment of this HTML is shown in Figure 5.

<APPLET code="Banners.class" width=550 height=100>
<param name=textColor   value=magenta>
<param name=emboss      value=true>
<param name=font        value=Helvetica>
...
<param name=messages    value=
"Banners are here! {textColor=yellow} {bgColor=blue} {enter=zoomIn} {exit=wipeUp}
{bgEnter=squeeze} {size=50} {fps=40} {cpf=1} |
...
</APPLET>

Figure 5. Sample APPLET tag and parameters.

Apart from general-purpose applets, the costs of using Java are high in that all applets must be written in the language. However the benefits are great in that applet distribution occurs on demand (when the user requests the Web page) and there are no distribution and update costs for the client applets.

A number of browser providers have developed add-in or plug-in technology to enable Web application developers to extend the user interface capabilities of the browser windows. As an example, developing Netscape plug-ins allows a Web application to create a whole or part window within the browser environment to display a specified type of file. This window can then be used to:

• display and interact with information extracted from the file
• execute a separate application which must be present on the client machine
• communicate with other applications using the native operating environment of the client machine
• provide links to other Web pages and servers

These facilities are driven via an Applications Programming Interface (API) provided by the browser which the developers of the plug-in must call. The Netscape API is quite powerful and provides facilities to:

• draw into, and receive events from, a window element that is part of the browser window
• obtain data from the network
• generate data for transmission to other plug-ins or the browser
• override and implement protocol handlers

Plug-ins must be installed in known directories and linked with specific file types with the browser prior to execution. Unfortunately, each plug-in, which is a substantial part of a complete application, is dependent on the hardware platform for which it is written. The costs of developing plug-ins are:

• substantial body of code for each plug-in
• a plug-in must be developed for each hardware platform to be supported
• special distribution and update channels must be established

Browsers can also provide access every type of file on the Internet by providing a simple interface to helper applications. When the browser loads a sound, image, video or other special file, it hands off the data to these free-standing, helper applications, to run or display the file. Most of these helper applications are shareware or freeware that can be found at various archive sites around the world. It is obviously in the interests of the supporters and distributors of a particular file format to provide convenient and low (or no) cost display of files in that format. Applications to create the file format are not usually free so that software providers can still generate an income from these information-producing packages

A good example of an application which has spawned a plug-in is the widely-used PowerPoint presentation manager from Microsoft [PowerPoint]. In line with their policy to integrate all products with the Internet, Microsoft have produced an ActiveX PowerPoint object format and a plug-in to display the presentation with animations and sound within a Web browser page. Figure 6 shows an animation with sound of a small slide show which acts as a banner within a Web page.

Figure 6. ActiveX object generated from PowerPoint.

The current release of PowerPoint is not capable of generating the new, compressed ActiveX format. Thus a publisher add-on for PowerPoint is also needed so that PowerPoint users can generate the ActiveX format. Both the publisher and the plug-in for PowerPoint are distributed without charge. It is interesting to see the power of the Internet having such a marked effect on existing, popular, free-standing applications.

Browsers also provide a limited mechanism to configure them for interfacing to helper applications. A dialog box allows the browser user to link certain file name extensions with particular helper applications. The browser will then arrange to save the file in a particular location, launch the helper application, and indicate where the file is to be found.

The costs involved to the developers of a Web application using helper applications are almost the same as providing free-standing, specific client applications for each hardware platform. Using the Web browser between the server and the helper client application means that:

• use can be made of familiar Web page information to navigate to the particular files needed at the client end
• the builtin file transport protocols of the browser can be employed and need not be included in the client (helper) application

Otherwise the application developers face the normal distribution and update problems which all free-standing software suppliers face, somewhat obviating the benefits of Web distribution mentioned earlier in this paper.

Conclusions

Developers of Web applications now have a range of choices on how to implement their client user interfaces at the Web browser-they must choose from within the Web user interface spectrum. This paper has described the trade-offs between development costs and effectiveness of the user interface at different points on the spectrum. A summary is presented in Table 2.

Acknowledgment

The Cooperative Research Centre for Distributed Systems Technology is thanked for providing Web server access to allow some Web user interface features to be examined.

References

Copyright