Today, after only four years, the World Wide Web has the potential to become a complex and powerful client-server application environment. The client-server relationship is based on two computers communicating with each other to share information. One computer, called the server, hosts the information which the other computer, called the client, retrieves by sending out a request. The server responds to the client by sending back the information to be displayed or used by the client. The Web has the ability to build on this traditional client-server relationship through multiple Internet protocols. A protocol is a set of conventions specifying how data is transmitted between computers. The Web uses a protocol called HTTP (Hypertext Transfer Protocol) [3] which allows remote hypermedia collaboration through the Internet backbone. Web browsers, such as Netscape Navigator, act as clients to translate the protocols into a format we can understand. The format which the Web browser uses to interpret protocols is called Hypertext Markup Language (HTML) [4]. HTML consists of a series of tags that are used to code text for display by World Wide Web browsers. HTML is a subset of Standard Generalized Markup Language (SGML) [5], which is an international standard for coding text for complex databases to be shared across computer networks.

The Common Gateway Interface (CGI) [6] is a means for a Web server to communicate with programs on another machine or the same machine. CGI is an open system which means communications are possible across platforms and operating systems. CGI programs can function as a gateway between the server and other applications like a database, or as stand alone programs, to transmit information to the client. While most HTML documents are considered "static", CGI allows documents to be generated dynamically based on data sets obtained from a database, for example, or from input obtained from the user through a Web-based form.

Forms are part of the HTML specification to allow active interaction between the client and server. Forms are used for many different purposes on the Web, such as surveys or for constructing customized documents "on-the-fly". The two principal uses of forms are to provide structured information to the server for later processing, and to provide arguments to an application running on the server [7]. Forms can utilize CGI scripts to accept input from the client side and process a transaction on server side and send it back to the client or store the information in another location, like a database. There are several programming languages, such as Perl [8], Python [9] and Java [10] that can be used to write custom gateway programs to process form input. There are also some commercial applications which can be used to build a custom CGI applications [11].

This powerful new Web environment can facilitate the development of new tools to support the use of the technology in education. One such tool, The University of Virginia Faculty Instructional Toolkit (Toolkit) is a Web-based client-server application which uses CGI and Web forms to make it easy for instructors to use the Web for instruction. This paper does not review the emerging areas of research in Web-based applications or long-established instructional design principals and user interface standards, but rather aims to document the overall design process of the Toolkit project to illustrate recommendations for approaching similar projects in the future.

The design of Toolkit has evolved from Release 1 [12] to Release 2 [13] to accommodate changes in technology and instructors needs. The Toolkit is also designed to be shared between educational institutions (it can be downloaded from the Web [14]) and so it must be portable and flexible. Portable in this sense means that when it is installed on another sever it will still work as intended. Flexible means it can be customized by other institutions to meet their needs and it can be easily updated or modified. As a participant in the Toolkit development process, I have gained an appreciation of the complexity of issues surrounding this type of tool and have gained a better understanding of how to design flexible Web applications for the future.

The Toolkit project began in the Spring of 1995 when faculty were just beginning to experiment with the Web for instruction. There were a number of faculty at the University who found that learning the details of Web authoring were time consuming and difficult, but they still wanted to create course home pages. In an attempt to make it easier for faculty to take advantage of the Web for instruction, Information Technology and Communication (ITC) decided to create a set of tools to help faculty through routine tasks so they could bypass having to learn UNIX file management and HTML authoring. At this time, HTML editors were rare and there were really no commercial products available to solve these specific problems. At this point, ITC began the task of creating a new Web-based CGI software application to help teaching faculty or graduate teaching assistants with little background in technology create basic course home pages on the Web. The initial Toolkit was in development from Spring 1995 until early 1996 when the first pilot tests were conducted with faculty.

There were two basic components to the original Toolkit: course home page creation tools and on-line electronic resources to support teaching. To create a course home page, instructors first obtained a Toolkit account to ensure greater security and monitoring of Toolkit usage. Once instructors had an account and access to the Toolkit, they filled out an electronic form with basic information about their course. The Toolkit automatically generated a course home page based on the official course offering directory database, maintained by the University Registrar, and the instructor's information. In addition to the basic course information, instructors had the option to add the following features by filling out additional Web forms: announcements; a syllabus; assignments; materials; and evaluation forms. The class materials section allowed instructors to upload files, such as images, tables, HTML or other documents into a designated directory space. The on-line electronic resources in the Toolkit included access to University Library Web-based services to reserve materials, an electronic form to order books from the University Bookstore and access to ITC multimedia classroom, training and on-line documentation information.

During the initial implementation of the Toolkit, one of the originators of the Toolkit was involved in the National Learning Infrastructure Initiative (NLII) group of Educom to explore creating a set of tools which could be shared among universities. It appeared that the Toolkit may have been able to solve the needs of other Universities and a new goal surfaced: to create an application that could be packaged and distributed to other Universities for free. This meant that the back-end of the Toolkit, the code and the structure of the application, had to become flexible and portable for use on other systems by other schools.

Since the Toolkit is a Web-based application, it works on any operating system running a Web browser with an Internet connection. However, the actual code of Toolkit Release 1 was dependent on a UNIX server. The Toolkit application was a written in a combination of Perl and Python. A file upload feature which allowed instructors to transfer files from their desktop computer to the Toolkit through a Web-based form, took advantages of a reverse file transfer protocol (FTP) capability only available in Netscape Navigator 2.0 or greater. The Web interface for the Toolkit was generated by Common Gateway Interface (CGI) scripts, which automatically generated the HTML code and static Web pages. When an instructor created a course home page, all of the course data, Web pages and class materials were stored as static documents in specific course directories on a designated Web server.

There were a number of problems with Toolkit Release 1 that were apparent after the initial implementation. These problems were in the design and functionality as well as the programming code. After these design and programming problems were recognized, the Toolkit development team set out to create a new release of the Toolkit. Two months were spent discussing the actual requirements and investigating possible alternatives to Release 1. The team (3 programmers and 1 designer) knew they needed an updated style based on current user-interface and Web standards, new course home page features as suggested by instructors, easier add-on and customization features, and more flexible and robust code.

Face-to-face interviews with a small group of pilot testers and questions commonly asked by Toolkit users revealed that the major design flaws were due to the fact that the Toolkit could not accommodate multiple instructors and multiple sections for the same course. A major goal of the redesign was to make sure Release 2 provided this functionality. Another goal of the redesign was to make sure the Toolkit supported the way instructors were using the Web for instruction. In order to discover the most the common uses of course home pages, the Toolkit team reviewed 35 of the more than 88 University of Virginia course home pages from the Fall of 1995 and Spring 1996 that were created before Toolkit 1 was released. At this time, the most prevalent uses for course home pages were:

* listings of course reference materials including lists of Internet resources and reserve readings
* extended information about the course including course information, instructor information, student information, syllabus materials, schedules or calendars of course events
* explanations of homework, quizzes, exams, papers and projects with answer keys
* student feedback on the course
* showcase for student Web projects

* the syllabus should not require instructors to use a pre-set format
* the Toolkit should allow more advanced users the ability to extend the Toolkit beyond the basic provided functions
* the Toolkit should provide more sophisticated file management tools
* the Toolkit interface should be easier to use
* the layout of the Toolkit generated Web pages should be more compact to fit on smaller screens and to accommodate printing

Most of the programming problems were due to the fact that the Toolkit was first designed over a period of approximately seven months. There were various people involved in the actual CGI programming and HTML coding so it was difficult to maintain a high level of consistency between each individual's work. The basic problems were:

* there was a mix of Perl and Python which created a "patchwork" of code
* Python was not widely known by all programmers
* the code was platform specific
* the HTML code was not standard in certain cases
* it was time consuming to update and maintain all the static documents
* the software was difficult to install and customize because of many bugs
* there were security problems because access control and session management was not sophisticated enough.

* be easy to customize by other institutions (portable)
* accommodate future additions and updates (flexible)
* had to conform to HTML and CGI programming standards
* had to be highly secure (to accommodate final grade submission)

Because of the possibility of a feature to allow instructors to submit final grades, the most important requirement for Toolkit 2 became security. The chosen protocol for a secure environment was Secure Sockets Layer [17] which is designed to provide privacy and authentication between client and server. This was chosen because it is accepted as an Internet standard and was supported by the Netscape Commerce Server. There are many important issues related to writing secure CGI scripts and safe Internet scripts [18] [19] [20], that were discussed, reviewed and tested before deciding on a final solution described in the next section. An application similar to the Toolkit, called Web Course in Box [21], is a commercial product which uses Java [10] and JavaScript to provide the same basic functionality of the Toolkit, but in a less secure environment. Much time was spent debating the pros and cons of using Java as the main programming language for the Toolkit, but after certain Java security problems were exposed, such as the ability of malicious applets to gain full read/write access to the victim's computer [22], it was determined that this new technology was not yet stable enough to support the security requirements.

The actual development of Toolkit Release 2 took place over four months. The redesign began in May 1996 and Release 2 was released at the start of the fall semester in early September 1996. In this four months, approximately two months were spent experimenting with possible solutions to the complex design requirements. The third month was spent developing the final code base and the last month was spent creating the various Toolkit functions.

In Toolkit 2, the major design emphasis was on the course home page creation tools. It was agreed that the other features (Library, Bookstore and ITC resources) that were included in Release 1 were important and should be featured but that they should be maintained apart from the home page tools. The basic premise for the Toolkit remained the same. Instructors obtain a Toolkit account, sign into the Toolkit and then create or manage the class home page. Most of the features were the same from users perspective except for the graphic design and improved interface. Instructors also had the ability to manage features by using the Toolkit form editor, providing a custom URL or uploading a text file. The available functions include:

The major changes in the Toolkit were to the Toolkit source code and the ability accommodate the addition of new features. Toolkit 2 uses mobile code instead of static code to specify dynamic behavior in Web pages.

Mobile code is transforming next generation Web applications by adding interactivity to traditional Web content such as forms, text, graphics, audio, and video. Mobile code, like traditional software, is a sequence of executable instructions. Stand-alone programs such as Web browsers and servers dynamically incorporate mobile code to augment system capabilities or to enhance the presentation of a document." [23]

Because of the security needs, the Toolkit is designed to run on a secure Web server such as the Netscape Commerce Server using Secure Sockets Layer [17] which is designed to provide privacy and authentication between client and server. In addition, ITC Advanced Technology group programmer, Dave Saunders, developed a program called the Page Manager to provide a high-level of security to Web applications. Release 2 of the Toolkit runs in conjunction with the Page Manager to provide a more sophisticated security environment. The Page Manager provides controlled access to collections of web pages, called "page groups". Different "page group types" have different sets of functions. There can be many instances of a particular page group type and these are called "page group instances". In the Toolkit, the page group type is "Class" and the page group instance is a specific course. Access to these page group functions and instances are controlled through session management and user authentication which addresses the problem of needing to be able to authenticate users and designate specific functions to them. This particular structure of the code also makes it easier to "plug-in" new page group types and functions. The Toolkit software is distributed with detailed documentation explaining this structure of the Page Manager and Toolkit in more depth as well as instructions to install and customize the software and templates to build new functions.

Plans are already in the works to begin a Toolkit Release 3. There are a number of issues such as slow response times from Perl and performance expectation of large Web applications like the Toolkit that need to be addressed. Plans are underway to investigate using C code, Perl compilers (to increase response time), and the more object-oriented features of Perl 5 or even Java to enhance the flexibility and performance of the Toolkit. In addition, there have been many requests to use various features of the Toolkit, such as the class roster, in other Web pages that would not be part of the entire Toolkit structure. This would required a stripped-down version of the Page Manager and Toolkit which may not include all of the security features, or creation of modules which are independent of the Page Manager or Toolkit structure. For now, the Toolkit will continue to evolve as the technology improves to accommodate these new programming environments and as educators experiment with new ways of using technology to support learning.

When starting a large Web-based application project, keep in mind the following recommendations based on lessons learned from the Toolkit project:

* Follow the instructional design process from beginning to end
* Follow established multimedia interface guidelines
* Focus on the specification, not the development product [24]
* Avoid duplicating existing products by researching currently available tools that could be used in place of or in conjunction with your planned application
* Evaluate the skills of your users before designing an application to solve their problems
* Develop a set of deadlines and review them on a regular basis
* Always build in extra time to meet your deadlines
* Always overestimate personnel time needed to work on the project
* Develop a "rapid prototype" or a basic working shell of the system before worrying about the graphic design and interface design
* Prototype several possible graphic designs and solicit feedback on them before choosing one
* Pilot test your application with your target users throughout the design process, do not wait until the end
* Seek input from other designers as well as from a variety of target users
* Constantly update your user documentation to address commonly asked questions

* Leverage existing applications (such as Perl modules) when possible instead of creating your own
* Use programming languages that are commonly understood by other programmers
* Use programming languages that have been proven to be reliable and secure
* Use current Internet Standards and protocols
* Use the version of HTML currently recommended by the World Wide Web Consortium
* Establish standard variable and file naming conventions
* Use variables whenever possible to allow for easier customization
* If portability is a goal, test the application on different Web servers, platforms and browsers throughout the development process in order to uncover any incompatibilities
* Use code validators and debuggers to check your syntax
* Add descriptive explanatory comments to your code
* Establish templates that can be reused--they will save time and provide consistency
* Create a central library of commonly used routines, or pieces of code
* Use consistent formatting in your code

[1] Hobbes' Internet Timeline. Document Available on the World Wide Web. (http://www.cc.utah.edu/history.html).

[2] About the World Wide Web and the Web Community. Document Available on the World Wide Web. (http://www.w3.org/pub/WWW/WWW/).

[3] HTTP - Hypertext Transfer Protocol. Document Available on the World Wide Web. (http://www.w3.org/pub/WWW/Protocols/).

[4] HyperText Markup Language (HTML). Document Available on the World Wide Web. (http://www.w3.org/pub/WWW/MarkUp/)

[5] SGML and the Web. Document Available on the World Wide Web. (http://www.w3.org/pub/WWW/MarkUp/SGML/).

[6] The Common Gateway Interface. Document available on the World Wide Web. (http://hoohoo.ncsa.uiuc.edu/cgi/).

[7] Thistlewaite, P. and S. Ball. (1996). Active FORMs. Paper Presented at the Fifth International World Wide Web Conference, Paris, France. Document Available on the World Wide Web. (http://www5conf.inria.fr/fich_html/papers/P40/Overview.html).

[8] The Perl Language Home Page. Available on the World Wide Web. (http://www.perl.com/perl).

[9] The Python Language Home Page. Document available on the World Wide Web. (http://www.python.org/).

[10] The Java Language: An Overview. Document available on the World Wide Web. (http://java.sun.com/doc/Overviews/java/java-overview-1.html).

[11] Levin, R. (1996). Web Development Tools -- Cooking From Scratch. A new class of products lets users build Web applications with their own ingredients. Client-Server, May 20, 1996 (Page 49). Document Available on the World Wide Web. (http://www.inquiry.com/).

[12] Toolkit Release 1. Available on the World Wide Web. (http://cti.itc.Virginia.EDU/toolkit/).

[13] Toolkit Release 2. Available on the World Wide Web. (http://cti.itc.Virginia.EDU/toolkit2/).

[14] Toolkit Release 2 Software and Documentation. Available on the World Wide Web. (http://cti.itc.Virginia.EDU/toolkit2/software-request.html).

[15] Trevor, J., Bentley, R. and G. Wildgruber. (1996). Exorcising daemons: A modular and lightweight approach to deploying applications on the Web. Paper Presented at the Fifth International World Wide Web Conference, Paris, France. Document available on the World Wide Web. (http://www5conf.inria.fr/fich_html/papers/P14/Overview.html).

[16] CGI.pm - a Perl5 CGI Library. Document available on the World Wide Web. (http://perl.com/cgi-bin/cpan_mod?module=CGI&readme=1).

[17] SSL. Document available on the World Wide Web. (http://home.netscape.com/newsref/std/SSL.html).

[18] The World Wide Web Security FAQ by Lincoln D. Stein. Document available on the World Wide Web. (http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html).

[19] Writing secure CGI scripts. Document available on the World Wide Web. (http://hoohoo.ncsa.uiuc.edu/cgi/security.html).

[20] Safe Internet Programming. Document available on the World Wide Web. (http://www.cs.princeton.edu/sip/).

[21] Web Course in A Box. Document available on the World Wide Web. (http://madduck.mmd.vcu.edu/wcb/info.html).

[22] Java Security: Frequently Asked Questions Document available on the World Wide Web. (http://www.cs.princeton.edu/sip/java-faq.html).

[23] Lucco, S., Sharp, O. and R. Wahbe. (1996). Omniware: A Universal Substrate for Web Programming. Document Available on the World Wide Web: (http://www.w3.org/pub/WWW/Journal/1/wahbe.165/paper/165.html).

[24] Levin, R. (1996). Strategies For Web Success. Client-Server, May 20, 1996 (Page 50). Document Available on the World Wide Web. (http://www.inquiry.com/).

Lara Ashmore plans to complete her Ph.D. in the spring of 1998. Currently, she develops Web applications and explores new Internet technologies for the Advanced Technology Group in the Office of Information Technologies at the University of Virginia. She can be rached via email at: lara@virginia.edu