Figure 9.1 shows the client-server architecture of World-Wide Web as it has already been described in this article. A client accesses servers on the Internet using various protocols. It communicates with various helper applications that extend its functionality. When it accesses a World-Wide Web server using the HTTP protocol that server can also access various helper applications through server gateways.
Figure 9.1 Client-server architecture of World-Wide Web
What changed with the advent of the forms capability was that the client in Figure 9.1 became able to trasmit structured information from the user back to an arbitrary application gatewayed through the server. The server could then process that information and generate a HTML document which it sent back as a reply. This document could itself contain forms for further interaction with the user, thus supporting a sequence of client-server transactions.
In essence, the adoption of an SGML tagged encoding schema allows HTML documents to include not only text, typographic and multimedia material but also to carry arbitrary additional data through simple, backwards compatible extensions. The HTML DTD is currently being standardized at four levels (Berners-Lee et al., 1994):
<TITLE>Faculty of Physical Education home page</TITLE> <IMG SRC="pelogo.gif"> <H1>University of Calgary Faculty of Physical Education</H1> <B><A HREF="calendar.html"> <IMG SRC="cal.gif" ALT=" "> Calendar Info</A></B> <B><A HREF="memos/readmem.html"> <IMG SRC="memo.gif"> Faculty Memos</A></B> <B><A HREF = "execute/runmail.jcl"> <IMG SRC="mail.gif"> Email</A></B><BR> <B><A HREF="meet.html"> <IMG SRC="meet.gif" ALT=" "> Meet the staff</A></B> <B><A HREF="mission/mission.html"> <IMG SRC="mission.gif" ALT=" "> Faculty Mission</A></B> <B><A HREF="media.html"> <IMG SRC="media.gif" ALT=" "> Multi-Media</A></B>Figure 9.2 Document generating Figure 7.5
Clicking on an icon in Figure 7.5 requests another document but this can have the side-effect of taking other actions at either server or client. For example, the "runmail.jcl" document in line 8 of Figure 9.2 runs a script in a job control application on the client that starts the user's normal email application and brings its window to the front.
The interface of Figure 7.5 is achieved though level 1 HTML hypermedia functionality. However, such applications suggested the provision of embedded GUIs as a natural extension to HTML. The level 2 forms extension enhances the capability of HTML documents to act as GUIs by allowing other widgets such as buttons, check boxes, radio buttons, popup menus, scrolling lists, and text entry boxes to be embedded. Figure 9.3 shows the memo entry facility selected through the "Faculty Memos" icon in Figure 7.5. The user can type information into what appears to be a normal GUI dialog box, and submit that information to the server.
Figure 9.3 Memo entry in a university information system
Figure 9.4 shows the HTML specification for the form of Figure 9.3. The text boxes are simply specified, and the ACTION field gives the URL to which their contents will be sent using the POST facility of the HTTP protocol. When the "Submit" button is clicked the client sends the contents of the form to the server which passes them to the program "post-memo" which files them. Users may retrieve memos through an index document with hypertext links to available memos.
<FORM METHOD="POST" ACTION="http://pe.cpsc.ucalgary.ca/cgi-bin/post-memo"> <H2>Enter the following information and press the "submit" key</H2> <BR> <STRONG>From: </STRONG> <INPUT SIZE=20 NAME="username"> <STRONG>Urgent:</STRONG> <INPUT TYPE=CHECKBOX NAME="urgent" VALUE="yes"> <BR> <STRONG>To: </STRONG> <INPUT TYPE=RADIO NAME="to" VALUE="All" CHECKED> <STRONG>All</STRONG> <INPUT TYPE=RADIO NAME="to" VALUE="Faculty"> <STRONG>Faculty</STRONG> <INPUT TYPE=RADIO NAME="to" VALUE="Students"> <STRONG>Students</STRONG> <BR> <STRONG>Subject: </STRONG> <INPUT SIZE=40 NAME="subject"> <BR> <STRONG>Memo Text: </STRONG><BR> <TEXTAREA NAME="Content" cols=50 rows=6></textarea> <BR> <STRONG>Attachments:</STRONG> <INPUT SIZE=40 NAME="attachments"><BR> <STRONG>Number of days to keep active: </STRONG> <INPUT SIZE=4 NAME="duration"> <BR> <INPUT TYPE=SUBMIT VALUE="Submit"> <INPUT TYPE=RESET VALUE="Clear Form"> </FORM>Figure 9.4 Form generating user interface in Figure 9.3
From a human-computer interaction perspective, what is significant about Figures 7.5 and 9.3 is that they represent graphic user interfaces operating on Unix, Mac, PC and other platforms, giving access to a functionality on a local or remote server operating on any platform supporting tcp/ip connections. Moreover, the user interface is programmed through a simple script that can be written in any text editor. It is this simplicity of development of interactive applications which has generated widespread interest in programming client-server applications through World-Wide Web in the short period since the inception of the forms capability.
GWN documents are stored in HTML format and can be accessed normally through WWW. A member of a registered group can request that a document belonging to that group be retrieved in annotatable form as shown in Figure 9.5. Each paragraph in the annotatable document is followed by a form allowing annotation to be entered and submitted to the server. Members of the group can then retrieve the document with each paragraph followed by hypertext links to the related annotation.
Figure 9.5 Annotation in collaborative writing
Figure 9.6 shows the HTML specification for the forms in Figure 9.5. Note the HIDDEN field in line 2 which contains an identification code for the annotator. The HTTP protocol is designed to be stateless so that the server does not in itself keep track of a sequence of related transactions with the same client. However, the required state information can be embedded in documents sent to the client so that when the server receives a request the associated service can determine the state of a transaction sequence. Since a client can save an HTML document and reopen it at a later time, this also allows transaction sequences to be suspended with the state information retained by the client. The fact that this is achieved through the normal local document storage mechanism also makes it a simple and natural activity for the user.
<FORM ACTION="ISC4.script" METHOD=POST> <INPUT TYPE=HIDDEN NAME="Annotator" VALUE="BRGpGF9y"> <TEXTAREA NAME="ISC4.1.1-1" ROWS=3 COLS=60> </TEXTAREA> <BR> <INPUT TYPE=RESET VALUE="Clear Annotation"> <INPUT TYPE=SUBMIT VALUE="Send Annotation"> </FORM>Figure 9.6 Annotation forms in Figure 9.5
Figure 9.7 Teaching Pascal over the web
Figure 9.8 Fault diagnosis over the web
When the user clicks on a component in the schematic at the bottom of Figure 9.8 the server returns a document giving information about its role in the device model linked to other information, such as its current state. This uses another HTML level 1 interface feature, the ISMAP attribute that designates an image as a `map' which when clicked returns the position of the cursor in the image to the server. The Device Modeling Environment system is also interesting because it uses a distributed server based on agents communicating through the kqml protocol (Finin, Weber, Wiederhold, Genesereth, Fritzson, McKay, McGuire, Shapiro and Beck, 1992) to make inferences about the model.
Attaching the concept mapping tool as a helper to the client allows local use of its full interactive functionality. Attaching it through a gateway to the server allows significant parts of its functionality to be offered through any client. Both are useful system architectures, and determining where to place such functionality is one of the interesting decisions to be made in designing distributed client-server applications.
Figure 9.11 Concept map server
The multilingual, multimedia, interactive facilities of WAX illustrate what has become possible in the support of special-interest communities through MUD-like systems on World-Wide Web (Rossello, 1994).
Figure 9.12 A MUD operating through World-Wide Web
The capability to support telepresecence where the user interacts with real systems in a remote situation opens up many innovative applications of World-Wide Web. It changes the nature of the web from one of supporting discourse between people to one of supporting action in the real world. Experiments involving specialist equipment can take place at one site and be controlled and monitored at another. New forms of research collaboration can be explored.
Figure 9.13 Tele-operation of a robot arm
The technology involves four main areas of human-computer interaction:
In future developments it would be simple for clients to support script languages of the power of tcl and tk (Ousterhout, 1994), which would allow interactivity to be programmed equivalent to that of local operation. In particular this would allow widgets to be programmed offering the full variety of click and drag interfaces. There are security problems in clients supporting scripts with full access to file and operating system facilities, but these can be overcome through the use of trusted interpreters with well-defined restrictions such as those proposed for General Magic's Telescript (Knaster, 1994).
The stateless transaction protocol adds an interesting design factor to World-Wide Web systems in that state information is normally associated with the computations taking place at the server rather than with the user interaction taking place at the client. However, one soon becomes used to passing state information back to a client, and making provision to store it there through operations that are natural to the user. This would be aided if clients made better provision for local action to be taken as a result of user interaction with a document. Essentially, one needs to be able to post forms to a local mini-server that can interact directly with the client. This is becoming easier as clients come to support scripting through inter-application protocols.
Another addition to client functionality that would greatly improve interactivity is the support of incremental updating of the screen. Much could be achieved by the normal flicker reduction technique of writing new data into an offscreen bitmap and refreshing the complete screen. World-Wide Web was designed to retrieve a succession of different items of information, but it is being used increasingly in applications such as those illustrated in Figures 9.9 and 9.13 where the user envisions a screen of changing information not a succession of different documents.