At UBC our first experiments [1][2] demonstrate that WWW-based courses (with or without accompanying lectures) have the potential to be effective both in terms of student academic performance and student acceptance. We have seen WWW-based courses and supplementary WWW-based course material proliferate. The problem, however, is that the proliferation is much faster, and the level of document sophistication much deeper, in departments where there is a high degree of technical familiarity. Departments such as Computer Science have no trouble taking full advantage of the power of the Web for course delivery. In contrast, other departments that are less technologically focused are either not taking advantage of the WWW or are not exploiting its full power.
It is not the case that these other departments have little interest in making courses and course material available on-line. Many have seen full-featured Web-sites and are enthusiastic about the prospect of placing their material on-line. The problem is that without the technical expertise to use CGIs, they are reduced to either creating only static web pages (no interactivity), or are forced to hire a consultant to do the work for them.
Using Web-CT requires that a course-author connect, using a browser such as Netscape, to a Web-CT site. The site is simply a HTTP server that serves the Web-CT pages and CGI scripts. Normally servers will be maintained centrally at educational institutions or by Internet-service providers. Once the course is built, it can be served from the same server, or can be moved to another.
Web-CT is not an HTML editor. Most people find a basic subset of HTML easy to learn. If the course-author can not learn HTML, he or she has the option of using an HTML editor, or of simply using plain text for course notes. Web-CT allows both.
Web-CT uses the Web as its GUI for building WWW-based courses. One advantage is that WWW-browsers are popular and easy to use. Educators wishing to build WWW-based courses are very likely to have used a browser before and should therefore feel comfortable in the environment. The other advantage of using the WWW as our GUI is platform independence. We need not create special versions of our software for multiple platforms. Likewise, none of our software is installed on user's machines. Instead our software runs on a central server, but is accessible from anywhere a browser can be run.
Another advantage of this setup is that there is no requirement that each course provider set up and maintain their own HTTP server. The expectation is that these servers will be maintained centrally in an organization (such as a university) and will be used by members of that organization. We have created a script that allows simple installation of Web-CT on a HTTP server. The courses that are created using Web-CT are automatically available from the same server that is running Web-CT. The course-author is not required to have any knowledge of HTTP servers at all. Should the author wish to move the completed course to another server, it is a relatively simple matter of moving the created data files and scripts.
Web-CT is also highly adaptable in that new course tools can be added at any time, allowing their incorporation into courses. We are continually getting new ideas and suggestions for useful tools, which we incorporate as we are able.
The remainder of this paper describes Web-CT by first walking through an example session with Web-CT, then by listing the set of tools that can be incorporated into a course built with Web-CT, and finally by providing a summary of the Web-CT implementation. Following these sections conclusions and future work are presented.
Assuming a new course is being started, the author will be asked to choose a set of defaults to be applied as a template to every page in their course. These defaults are chosen using forms and clickable image maps, and include items such as default page background, page header and/or footer text or images, and bullet icons. These defaults will be applied automatically to every page in the course, but can be overridden for individual pages.
Now the course-author can begin creating course pages. To create a course page, the author has two options. If creating course pages from scratch, the author can use the Web-CT course-editing page. Here, the author is presented with a text-entry box where plain text or HTML can be entered. As an alternative, if existing text or HTML is available, these files can be down-loaded to the Web-CT server and incorporated into the course. If modification is required, the course-editing page can be used to update an existing file.
Once a course page has been down-loaded or as it is being entered, the course-author has the option of incorporating course tools into that page. Tools are added to a page by simply clicking the appropriate button on the course-editing page. The complete list of available tools is described below. As examples, however, tools such as a glossary, a student self-evaluation mechanism, a student page page-annotation mechanism, a bulletin-board, a chat-facility, and an image database can be included in any page. The finished page will appear with a button-bar along the top and/or bottom (this is configurable by the author) containing an icon for each tool incorporated into that page.
Finally, the course-author will need to indicate the relative location of this page in the course. Pages are organized both hierarchically (for instant access to any course topic, subtopic, or individual page), and linearly (to define a usual, linear, path through the course). The finished page will have icons for moving forward and backward along the usual path. It will also contain an icon to display the hierarchical view of the course from which the course can be viewed at any level of granularity. This hierarchical view provides direct links to each course subtopic and page.
The finished product (a web-based course) consists of the set of notes-pages created by the course-author. The notes appear in the middle of each page, and button bars appear at the top and/or bottom providing navigation support and links to tools that have been incorporated. The notes portion of each page appears as entered by the course-author (either as HTML or as preformatted text), with the exception that links from various words in the notes will be automatically created by Web-CT to point to glossary entries. These links are generated when the course is viewed by students; the HTML as entered by the course-author is never altered. Two examples of pages created by Web-CT follow (Figures 1 and 2). These are pages that would be viewed by students using the course.
The second view of the course that is presented to the student is a hierarchical view. The course pages can be organized by the course-author into a tree. The topics can then be viewed at any level of granularity, and topics may be jumped to directly from that view. The advantage here is that students wishing an unconventional route through the course (either because they are reviewing completed material, or because they have some existing background) can proceed quickly to any part of the course.
The navigation tool also has the ability to record the route that a student is taking through the material. There are two reasons for this. The first is that when a student begins a session viewing course pages, Web-CT automatically places him or her at the location that they were at when they ended their previous session with that course. This removes the need for a student to have to find the correct context every time they sign on to the course. The second reason is that this record of accesses may be of interest to the course providers. It may provide hints as to which pages are popular or troublesome for students.
Note that these navigation features (and other features of Web-CT) require that students using courses created by Web-CT be given accounts and be asked to authenticate themselves before each session. This allows us to know the identity of the student making use of the course tools. Anonymous student access is also allowed, but tools that depend on knowing the identity of the student will not be available in that case.
The following image (Figure 3) is a view of the Web-CT page that the course-author uses to establish the hierarchical relationships and linear ordering of course pages. Note the triangle buttons that allow the course-author to move pages to other locations (up, down, indent, unindent) in the hierarchy. There are also buttons (the angled arrows), that hide or show subtree contents. There is also a button for each page (the red X) that deletes that page from the hierarchy. The linear view of the course is taken as the order of pages starting at the top, and proceeding to the bottom of the hierarchy.
The course-author is also able to annotate page references in the index in order to explain them further. For example, if the term is World Wide Web, there may be several pages containing that term. Web-CT will create references from the index to all of these pages. The course-author can annotate any or all of the references. For example, the words an introduction to can be used to annotate an entry indicating that this index reference contains an introduction to the World Wide Web.
If the student does not find the term they are looking for in the index, they can enter their own term. A new index entry will be dynamically created showing the course pages where that term occurs, again listed in order of priority.
Finally, an index button can be placed on any or every page's button-bar allowing direct access to the course index.
New articles posted to the bulletin board are presented to every participant. Web-CT keeps track of which articles have been read by which participant in order that once someone reads an article, it is not presented to him or her again (unless they elect to view past articles). Bulletin-board articles can be searched for and listed based on article content, author, forum in which it was posted, and date of posting.
The bulletin-board can be referenced either from the tool page (described below) or from a page of notes. Postings made from the tool page are treated in the usual way, with a user-entered subject.
Postings made from a page of notes are generated with a subject line that contains the name of that page. When articles are viewed from a page of notes, only the articles that pertain to that page (and followups to those articles) will be presented. Also, all articles pertaining to that page will be presented regardless of whether they are new, or have been seen before. This creates a running history of the commentary for that page of notes. The idea is that past discussions about a page form part of the learning experience for students new to that page, and are therefore of value.
The bulletin-board is currently being implemented, but the following image (see Figure 7) will closely reflect the final student view of the bulletin-board page.
The student's view shows the chat rooms, their names, and a list of course participants in each room. A student can enter any room and, if desired, rename that room to advertise the nature of the conversation taking place there. The door to a room can be locked to prevent other students from entering that room. This facilitates private conversations.
Once the student accesses the quiz, a record of the start time is made at the server. The student is responsible for submitting his or her answers before the time allotted for the quiz has expired. There is a button on the quiz page that a student can press to determine how much time remains.
When the quiz answers are submitted, they are saved for the course administrator. A record is made at the top of the answers indicating the time of day that the quiz was written, and the length of time the student took to complete the quiz. The quiz results can be viewed by the course administrator using the Quiz Result Viewing Page.
Every question is followed by a list of potential answers with a button beside each. The student marks the (hopefully) correct answer and presses the submit answers button. At that point a page is presented restating the question and the selected answer with an indication of whether the question was answered correctly, and an explanation as to why the submitted answer was correct or incorrect.
The course-author creates questions (including their potential answers and an explanation for each answer) on the Multiple-Choice Question Creation Page. Aside from the questions, answers and explanations, the author must indicate which is (are) the correct answer(s) for each question, and which page this set of questions is for.
For example, if the course-author defines a set of multiple-choice questions that are to be associated with a page of notes, a file is created by Web-CT containing these questions. The file is named by Web-CT to indicate its relationship with that page of notes. As another example, when a default background for every page of notes is selected, the course configuration file for that course is updated to reflect that preference.
Each course has a directory on the server into which is put all of the HTML, text, image or audio files created by, or downloaded by the course author. These files are never modified by Web-CT. When the student views a page of notes, Web-CT reads the page of notes from that directory, and then reads any associated Web-CT files for that page and for the course. According to the content of all these files, Web-CT dynamically generates the HTML required to produce the finished student-view of that page of notes, complete with default page attributes, button bar and glossary links.
Another possible approach would have been to modify the HTML entered by the course-author to include the button-bar, page attributes and glossary links. This would have made it possible to serve the page to a student without first sending it through a Perl script. The advantage of our scheme is that we can leave the original HTML intact as entered by the course-author. If the author decides to later re-edit the HTML, he or she will be presented with exactly the same page that was previously entered. No extra markup will have been done. It is our feeling that this avoids a lot of potential confusion for the course-author.
We will shortly begin a rewrite of many of our existing tools to take advantage of Java [6]. Java is becoming more widely supported, and we feel it will soon reach the point where most users will have access to browsers that support it. Java will allow us to enhance our current interface by improving the speed and nature of interaction. It will also allow us to implement new tools that would have been difficult with forms and CGIs (our first example of this will be a clickable bitmap editor similar to mapedit [7]).
Additional work will focus on exploring possibilities for new tools with a view toward implementing them for Web-CT. Examples include shared workspaces for student collaboration, real-time audio conferencing, and real-time video conferencing. Where feasible, we will consider the possibility of integrating existing packages into Web-CT rather than implementing all new tools ourselves.
Finally, we will be actively collecting reviews of Web-CT both from course-authors and students using the produced courses. This is the only way we can be sure we are meeting the needs of users in our educational community.
[1] Murray W. Goldberg, "CALOS: An Experiment with Computer-Aided Learning for Operating Systems," To appear in Proceedings of the 1996 SIGCSE Technical Symposium, February, 1996.
[2] Murray W. Goldberg, "CALOS: First Results From an Experiment in Computer-Aided Learning", http://homebrew.cs.ubc.ca/papers/calos-res.
[3] B. Ibrahim, S. Franklin, "Advanced Educational Uses of the World-Wide Web," Computer Networks and ISDN Systems 27 (1995) 871-877.
[4] D. Dimitroyannis, "Virtual Classroom: A Case Study," http://www1.cern.ch/PapersWWW94/ddimitri.ps
[5] Introduction to Object Oriented Programming Using C++, http://info.desy.de/gna/html/cc/index.html
[6] The Java Language Environment: A White Paper, http://java.sun.com/whitePaper/javawhitepaper_1.html
[7] Mapedit: WWW Imagemap Editing Software, http://www.boutell.com/mapedit
[8] WWW Homepage Access Counter and Clock!, http://www.semcor.com/~muquit/Count.html
Sasan Salari,
Department of Computer Science, University of British Columbia, Canada.
E-mail: salari@cs.ubc.ca
Paul Swoboda,
Department of Computer Science, University of British Columbia, Canada.
E-mail: swoboda@cs.ubc.ca