>> Ressourcen > Download Area für Papers > Maurer, H., Die[..]

How Modern WWW Systems Support Teaching and Learning

H. Maurer, Th. Dietinger

Graz University of Technology, Austria
hmaurer@iicm.edu

Abstract: In this paper we present GENTLE*) , an acronym for GEneral Networked Teaching and Learning Environments. GENTLE is firmly based on the ten theses mentioned in MANKIND (see http://www.iicm.edu/mankind.htm or [38] for details) and on the advanced Web server technology Hyperwave (see http://www.hyperwave.com or [30], [39] ). GENTLE is neither "vapourware" nor is it implemented in all details yet. However, a very substantial core has been available and in use for about a year and modules are continually added to assure that GENTLE remains one of the leading efforts in this field.

1. Introduction

GENTLE is based on the premise that computer networks with reasonable bandwidth (of, say, at least high-speed modem quality) can form the basis of non-isolating powerful teaching, training and learning environments. Lack of sufficient bandwidth can be compensated by combining LANs or CD-ROMs with slow-speed "feeder" networks for communicational purposes. The main idea of GENTLE is to provide a set of tools that allows the delivery of classical multimedia courseware enhanced by digital background libraries, annotation facilities, asynchronous and synchronous discussion and question/answer facilities. GENTLE also provides help for preparing courseware, administrating students, teachers and instructional material and, above all, facilities to customise material for individual needs and to evaluate the success of the teaching efforts at issue. GENTLE also addresses the aspects of testing and examinations, and of general record keeping.

The current paper deals with all of the above issues in the following sections including a description of the necessary infrastructure (Hyperwave as mentioned earlier) and the present status of implementation.

2. The courseware

A course usually consists of a number of lessons, each lesson, in turn, of a number of chapters that consist of individual pages. Each course comes with a block of meta-information including at least the following items:

  1. Brief description of contents of course including pre-requisite knowledge, intended audience, expected benefit and samples/highlights of the course, almost like in a movie trailer.
  2. Description of the individual lessons including an estimate of the time it will take to work through them.
  3. Information on hardware, netware, and software requirements (e.g. drivers) including available options.
  4. A guide on how to use the course, reference material and communicational features available.
  5. A course may contain pre-tests to determine learner's style and learner's level of knowledge, and post-tests or test at the end of chapters or lessons for re-enforcement of knowledge acquired and for allowing students to benchmark themselves. Formal examinations may also be available. Concerning these issues we refer to the appropriate sections below.

The structure of a lesson with its table of contents leading to a number of chapters, each consisting of a sequence of pages is fairly rigid. The flexibility of the material arises from automatic customisation, user determined preferences and options to present more material, skip material, view previously recorded question/answer dialogues and the availability of using a background library and communicational features as described below.

The basic instructional unit is a page. Its presentation style may depend on user preferences e.g. taking into account learning styles, visual or audio handicaps, terseness of presentation desired, etc. A page could be a standard HTML page, enriched by e.g. JAVA Script enabled buttons for more information, examples, or such; the mode of presentation is again possibly dependent on previously set user preferences. However, pages may also be much more sophisticated, using JAVA applets, helper applications, or plug-ins to start complex animations, simulations or such, or offering forms whose evaluation will cause server-side actions. Beyond this, pages may not be HTML based at all, but other types of documents (like Winword, PowerPoint, HM-Card or ShockWave applications) that fire up the necessary program on the basis of the MIME type.

There are further actions available to the user (i.e. learner) as described in the next section. For now it suffices to understand that pages can be quite complex objects and may offer much interactivity; further, with the help of a number of features to be discussed below users do not feel confined to follow a certain sequence of pages, unable to "break out" of an externally imposed course of actions. However, contrary to many other systems although hyperlinks are possible, they are used very sparingly, only for e.g. footnote type explanations. They usually do not and should not allow users to meander all over the place. Other facilities like searching or browsing in the background library provide this kind of "serendipity" phenomenon if desired. In this sense GENTLE courses provide "guidance without dictatorship" yet avoid the "lost in hyperspace" problem. Much has been written about the presentation style of courseware material. We refer to [37] for details. However, we want to emphasise that a style where users have the feeling a person is teaching them, not a computer, by having pictures or videos and voice of this person, is indeed one crucial factor for success.

3. Using the courseware

Users of GENTLE always log into the system to start with. They might have the choice to stay semi-anonymous (i.e. only the system administrators know the identity behind a user name chosen). The identification allows the system to keep track of the progress of students and provides private working space for them (see below).

After choosing a suitable lesson, possibly configured by the system based on past history of the student, environmental parameters, learner's style or level of know-how determined factors, users work through the chapters of the lesson selected.

When starting a new page users have the option to study (work through) it, skip to the next page, return to the previous page, or to go back to the table of contents. In addition, they can start a search in one of (possibly a number of) background libraries, where different libraries can be associated with different parts of a course. Users can also start a chat (including a shared whiteboard) with one or more others online. They can attach notes to the page or to a designated part of the page. Such notes can be private, or public to all or a well-defined user group. Since notes can be added to notes this assures that any point in a course can be the start of an asynchronous discussion. It is up to the administrator to define whether all notes are also sent by email to the teachers, the students, or are also collected in a special place to ease retaining an overview of all discussions going on. Further structuring of discussions can be provided.

It is important to understand that notes attached to a page are visualised as icons when re-visiting the page to the extent the visitor has been defined to have access rights to the notes. Notes are usually text-only or HTML pages but could (in the future) also be much more multimedia directed, much as chat facilities might incorporate video conferencing at some stage. Note in particular that notes may contain links to other (Web) pages. Thus, the annotation facility mentioned and available in Hyperwave allows users to link together pages they do not "own": users may place an icon on a page of interest, and clicking on that item may reveal a link to some related information.

There is a particularly important type of note: a question asked by a student. This is shown by a special "question icon" to whoever is authorised to see it, and an email is sent to the teachers and possibly also to (a subset of) the students. When the question has been answered (immediately or at a later point) the person asking the question is notified and the icon changes: indeed it changes to "verified answer" if a teacher has been involved. Thus, users later visiting a page can profit from question/answer dialogues carried out earlier. Notes also play an important role for quality control as will be pointed out later.

Summarising, users of GENTLE get material customised to meet their needs and are supported by a background library and sophisticated communicational facilities.

4. Administrational issues

The system administrator designates for each course a course administrator. Supported by a component of GENTLE called course wizard the course administrator defines the overall environment of each course. Potential parameters include:

  1. Definition and contact parameters of teacher(s), i.e. of the persons receiving emails e.g. when questions are asked
  2. Selection, pricing and billing details of courses, where applicable. Information if course is also (partially) offered in traditional form.
  3. Definition of students participating in a course, those notified of questions being asked, chats going on, etc. Typically, physics students may not be notified of chats conducted by medical students, but possibly of chats involving calculus students. To put it differently: not all "chats" are open to all users.
  4. Students obtain a private work space. This is where their annotations are (physically) stored, this is where they can edit collect and link material. This is also where their progress is recorded, allowing the teacher or the system to send encouraging or admonishing notes as may be appropriate.
  5. Information on courses available, inter-dependencies of courses, courses taken (subscribed to) by the student, courses completed, further courses that are recommended.
  6. The course administrator also defines which background libraries are relevant to which parts of a course. (Note that this "scope definition" for searches is essential to avoid the dreaded information overkill we are all too familiar with from search engines such as AltaVista.)
  7. The course administrator also provides a bulletin board for general information (like office hours), a discussion forum for items of general interest, a profile of teachers, etc.
  8. Most important, the administrator decides who has read access to which material and notes, monitors overall progress and provides sundry information as applicable.

5. Authoring courseware

GENTLE does not provide authoring tools as such. But it does provide authoring wizards that allow to rapidly prepare simple yet appealing HTML pages that provide additional information in the form of written and/or spoken text, plus potentially the same material in video form. It also provides tools to pull together various multimedia documents into one page and includes a fairly easy to use (HM-Card) editor for animations and certain question/answer dialogues, where the output is automatically converted to JAVA applets or files that are interpreted by JAVA applets.

Authoring beyond the above will also be supported in GENTLE by authoring on the fly ([29],[5]) akin to what was developed by Professor Ottmann's group in Freiburg, Germany, and by allowing to combine small modules easily into larger ones using a module manager and the sequence and cluster concepts inherent in Hyperwave. Most important, GENTLE is open to all other authoring tools.

6. Customising courseware

The old adage that a T-shirt sold as "fits all sizes" is indeed a T-shirt that fits nobody is also true for courseware. No courseware on no subject will ever be satisfactory for a diverse audience. GENTLE, by using Hyperwave's cluster concept allows to easily customise material by learning style, content, and environment. Such customisation can be done by the teacher, the system (based on the outcome of test questions) or the users themselves.

We believe that the cornerstones of GENTLE's success so far are customisation, personalisation and "guidance without dictatorship".

7. Quality control

It is essential that teaching material offered using GENTLE can be evaluated regularly, both as far as subjective satisfaction of users and more objective criteria are concerned.

Numerous attempts to judge subjective user satisfaction by employing questionnaires, be it printed or electronic, have been less than successful: users are irritated by the "unnecessary burden of filling out the forms" and hence respond with sloppy of partial answers. We propose an alternative in GENTLE that will hopefully be more acceptable: the system generates, randomly, a question once in a while. Filling out this single question is little work and will be "rewarded" by showing a cartoon, telling a joke, or such. We are also considering other means of the evaluation of subjective user satisfaction and will report on this, elsewhere.

As far as objective criteria, GENLTE offers two tools: (1) Hyperwave keeps a detailed log file of how users navigate. This can be use on principle to determine difficulties in the material, frustration with certain sections, or the like. However, a cautionary word is in order: many earlier computer assisted instruction systems have kept similar log files, yet usually it was difficult to systematically evaluate them. Therefore the second alternative (2) looks more promising: pages where students have asked many questions by the mechanism described earlier indicate one of two things: either the material is bad and needs improvements or else it is particularly interesting and hence should be further elaborated. In both cases, feedback due to the recording of question/answer dialogues is invaluable.

8. Tests, examinations and record keeping

Pre-tests to determine if courses are suitable or to find out how to best customise them in style and content can be carried out easily in multiple-choice form. Similarly, post-tests to reinforce material, to assure users that they have made progress, and to keep track of the progress made for the course administrator are fairly straight-forward to implement and - while not part of GENTLE at the time of writing - will be added in the near future. The issues of formal examinations and record keeping are important e.g. for motivational reasons in connection with certification issues yet do not only require solid security measures but, if combined with automatic (random) question generation are much more subtle than one would usually think ([12]). Much further work will have to be invested in this area.

9. The role of the Web vs. CD-ROM's

Clearly, the ideal environment for GENTLE is a fairly fast and substantial network with inexpensive access. Unfortunately, such conditions are usually only met in LANs and Intranets. Often, Internet access as such is slow and/or expensive. A possible way out is to use a CD-ROM or a local server that is rapidly accessible (even to the extent that the server is installed on the user's own machine) and to keep most of the instructional material there. Once in a while connection with the main server is established using the (presumably slow and/or expensive net) to download updates, particularly new answers to questions, notes and discussion group contributions, and to upload similar material to the main server.

10. The necessary infrastructure

It is clear that many of the features required to be able to support the above criteria are not available on ordinary WWW servers. Hence, either an exorbitant amount of programming (scripting) is necessary, or else a WWW system supporting features such as customisation, annotation, modularization, etc. is required. The only such system currently available is Hyperwave. Hence this section is dedicated to describing the main functions of Hyperwave.

Information in a hypermedia system is usually stored in "chunks". Chunks consist of individual documents which may themselves consist of various types of "media". Typically, a document may be a piece of text containing a picture or other multimedia objects. Each document may contain links leading to (parts of) other documents in the same or in different chunks. Typical navigation through the information space is based on these links: the user follows a sequence of links until all relevant information has hopefully been encountered.

In ordinary WWW, a chunk consists of a single document. Documents may consist of a combination of arbitrary multimedia elements. To give a simple example, a document may consist of textual information and may include pictures and the (source) anchors of links. Pictures and links are an integral part of this document. Pictures are thus placed in fixed locations within the text ("inline images"). Links may lead to audio- or video-clips or other multimedia elements which can be activated. The textual component of a document is stored in so-called HTML format, a derivative of SGML.

In Hyperwave the setting is considerably more general: chunks, called "clusters" in HyperWave terminology consist of a number of documents. A typical cluster may, for example, consist of five documents: a piece of text (potentially with inline images), a second piece of text (for example in another language, or a different version of the same text, or an entirely different text), a third piece of text (the same text in a third language perhaps), an image and a film clip. Anchors can be attached to textual information, to parts of images, and even to regions in a film clip, a 3D scene, etc. Links are not part of the document but are stored in a separate database. They are both typed and bi-directional: they can be followed forward (as on any WWW server) but also backwards.

The support for multiple pieces of information within a cluster allows Hyperwave to handle multiple languages in a very natural way. It also elegantly handles the case where a document comes in multiple versions: e.g., a more technical (or advanced) one and one more suitable for the novice reader. Or different versions for different bandwidth, for different drivers, like offering the choice of picture, video or 3D scene depending on the user's environment. Most importantly, clusters allow the automatic support of different learning styles like e.g. "verbal", "symbolic" or "visual".

Text can be stored in Hyperwave in a variety of formats including, of course, HTML, PostScript and PDF. In addition to the "usual" types of documents found in any modern hypermedia system, Hyperwave also supports arbitrary other types of information such as 3D objects and scenes [45], electronic courseware and animations [37].

One of the most crucial differences between simple WWW and Hyperwave is the treatment of links. In simple WWW systems links are unidirectional, have no type and are embedded in documents. In Hyperwave they are bi-directional, can have types and are stored in a link database separate from the actual documents. This difference is very significant as we will explain a bit later.

Navigation in ordinary WWW is performed solely using the hypertext paradigm of anchors and links. It has become a well accepted fact that structuring large amounts of data using only hyperlinks in a way that users don't get "lost in hyperspace" is difficult to say the least. Ordinary WWW databases are large, flat networks of chunks of data and resemble more an impenetrable maze than well- structured information. Indeed every simple WWW server acknowledges this fact tacitly, by offering pages that look like menus in a hierarchically structured database: items are listed in an orderly fashion, each with an anchor leading to a subchapter (subdirectory). If links in WWW had types, such links could be distinguished from others. But as it is, all links look the same: whether they are "continue" links, "hierarchical" links, "referential" links, "footnote links", or whatever else cannot be distinguished.

In Hyperwave not only can have links a type, links are by no means the only way to access information. Clusters of documents can be grouped into collections, and collections again into collections in a pseudo-hierarchical fashion. We use the term "pseudo-hierarchical" since, technically speaking, the collection structure is not a tree, but a DAG. I.e., one collection can have more than one parent: an impressionist picture X may belong to the collection "Impressionist Art", as well as to the collection "Pictures by Manet", as well as to the collection "Museum of Modern Art". The collection "hierarchy" is a powerful way of introducing structure into the database. Indeed many links can be avoided this way [33], making the system much more transparent for the user and allowing a more modular approach to systems creation and maintenance. Collections, clusters and documents have titles and attributes. These may be used in Boolean queries to find documents of current interest. Finally, Hyperwave provides sophisticated full-text search facilities. Most importantly, the scope of any of such searches can be defined to be the union of arbitrary collections, even if the collections reside on different servers. The concept of collections has one other very significant advantage: it allows insertion and deletion of documents into a Hyperwave database without any link adjustment, a luxury unknown in ordinary WWW systems. Finally, and for educational applications particularly important, having learning modules packaged as collections eases modularization and re-use of material.

Note that some WWW servers also permit full-text searches. However, no full-text search engine is part of "standard" WWW. Thus, the functionality of full text search is bolted "on top" of most WWW servers: adding functionality on top of WWW leads to the fragmentation of WWW, since different sites will implement missing functionality in different ways. Thus, to stick to the example of the full text search engine, the fuzzy search employed by organisation X may yield entirely different results from the fuzzy search employed by organisation Y, much to the bewilderment of users. Actually, the situation concerning searches on most WWW servers is even more serious: since documents in such WWW servers do not have attributes, no search is possible on attributes; even if such a search or a full text search is artificially implemented, it is not possible to allow users to define the scope for the search, due to the lack of structure in most WWW databases. Hence full-text searches on most WWW servers always work in a fixed, designated part of the database residing on one particular server. Using Hyperwave and the built-in Verity engine searches can both be scoped and can include non-HTML material like Powerpoint, PDF or Word files.

Hyperwave provides various types of access rights and the definition of arbitrarily overlapping user groups. Hyperwave is also a genuine distributed database: servers (independent of geographical location) can be grouped into "tribes" that act as one logical system. Thus, users can define the scope of searches by defining arbitrary sets of collections on arbitrary servers. Note further that proper authorisation schemes allow different groups to work with the same server without fear of interfering with each other's data.

Ordinary WWW systems have traditionally been seen mainly as (simple) information systems. Most applications currently visible support this view: very often WWW servers offer some pleasantly designed general information on the server-institution, but only rarely does the information go much deeper. If it does, usually a "hybrid" system is used, WWW with some add-ons or a database in the background using the scripting interface of WWW.

It is our belief that hypermedia systems acting as simple information systems for educational material in the sense of electronic books, where someone inputs information to be read by other users, do not offer much potential: they will disappear into obscurity sooner rather than later. To ensure the success of a hypermedia system for educational purposes, it must allow users also to act as authors, allow them to change the database, create new entries for themselves or other users, create a personal view of the database as they need it, and, above all, allow the system to be used also for communication and co-operation.

Ordinary WWW systems almost entirely lack support for such features. Emerging more advanced hypermedia systems are bound to incorporate more and more features of the kind mentioned; Hyperwave provides a start.

Hyperwave supports annotations (with user-definable access rights): Hyperwave annotations become part of the database, i.e., are also available when working with other clients, or from another user account or machine. Annotations can themselves be annotated; the network of annotations can be graphically displayed using local map functions. Thus, the annotation mechanism can be used as the basis of (asynchronous) computer-conferencing, and has been successfully employed in this fashion. It can also be seen as allowing users to write private remarks in the "margin" of the material examined for later review purposes.

We believe that many of the features discussed in the area of computer supported co-operative work (for a compact survey see [8]) will eventually be incorporated into advanced hypermedia systems.

As has become clear from the above discussion, ordinary WWW servers do not have enough functionality to be a solid and unified basis for substantial multi-user multimedia repositories with a strong communicational component.

Hyperwave is a first attempt to offer much more basic functionality, yet to continue to work as WWW system: every WWW client can be used to access every Hyperwave server.

We discuss two particularly important points in more detail: the link concept and the notion of collections. As has been mentioned earlier, ordinary WWW uses unidirectional links that are embedded in the documents and cannot be typed. In Hyperwave WWW links are bi-directional, can have a type and attributes and are handled not as part of the document but in a separate database. These extensions of the link concept have far-reaching consequences. We mention a few of the most important ones in what follows.

When viewing a document it is clearly always necessary to know which other documents can be reached from it: this is after all what links are all about, and such "out-links" are of course supported in all WWW systems including Hyperwave. However, it is equally important to also know which documents are pointing to the current one, i.e., to know the "in-links"; this is what bi-directional links are all about. There are many reasons why also the knowledge of "in-links" is important:

First, it gives users (and information providers) the valuable information who is pointing to a particular document for "information only" reason: the context of the document becomes clearer, its "popularity" can be determined, etc. To be specific, suppose you are interested in impressionist art and you have located a picture in the (virtual) gallery of the Museum of Modern Art in Vienna; by examining all "in-links" you are bound to find valuable information about the painting that would have escaped your attention otherwise.

Second, having bi-directional links allows to generate a graphic representation of the "local surroundings" of the current document, the so-called "local map".

This local map will show you an iconized version of your current document, plus all those that (via one or more steps) lead to it or can be reached from it: this is a very powerful support for navigation and helps to avoid the "lost in hyperspace" syndrome mentioned earlier. It also helps to follow discussions based on the annotation concept already mentioned.

Third, and still more important, it is the only way towards better link maintenance to avoid "dangling links", a phenomenon that is a problem on all large WWW servers. Again, to be specific, suppose an important document X is pointed to by documents A(1), A(2), ..., A(n). If X is removed and only unidirectional links are used there is no way to know that A(1), A(2), ...., A (n) point to X, particularly if the A(i)'s reside on different servers. Hence the links in all A(i)'s when activated by users will all yield the very frustrating message "document cannot be found" or such, a phenomenon well-known to every WWW user. However, if bi-directional links are used then the removal of X can at least result in notifying the owners of the documents A(1), A(2), ..., A(n) that X has disappeared so that the links in the A(i)'s can be adjusted. Indeed, if the links in A(1), A(2), ..., A(n) are not embedded within the A(i)'s rather than just notifying the A(i)'s the links in the A(i)'s leading to X can be deactivated automatically.

This, then, is a first step towards automatic link maintenance, a feature imperative for large systems and addressed in Hyperwave for the first time: to be able to carry it out it is necessary to have bi-directional, not-embedded links and to be able to assign rights and attributes to links that differ from those assigned to the document at issue. Typically, you may permit automatic link deletion of a link to X in a document A(i) you have authored although you are unlikely to permit any change of the contents of A(i). This is one reason why keeping links separate from the documents is very important! Automatic link maintenance does not stop at deleting links that are no longer valid, it can also be used to automatically generate links.

Links are usually attached to pieces of text or to pictures. However, one may also want to attach them to parts of a picture, to a moving object in a movie, a 3D object in a 3D scene, a simulation or experiment, etc. In all such cases it is clearly impossible to embed the link information in the document (how would you embed such information in an MPEG film without destroying the MPEG coding?). I.e., links in "unorthodox documents" are only feasible if non-embedded links are used or, if explicitly allowed such as in VRML2. Note that in such cases all drawbacks of embedded links will again re-surface.

Another reason why it is of paramount importance to keep links and documents separate and to be able to differentiate between the rights of links and documents and to add attributes to the links ("typed links") is that only in this way can hypermedia systems be "personalised" and "customised". Suppose teachers want to prepare multimedia presentations based on existing material for a particular class without (e.g., for copyright reasons) being allowed to copy the material. The teachers can connect various bits and pieces of information using links with the name of the class at issue as attribute. Students of the class are identified as such when they log-in and hence only the links generated for that class become visible. Thus, the concept of being allowed to add "private" links to arbitrary documents combined with link filtering based on some link attribute allows to customise a hypermedia system arbitrarily without copying any information. This is basically the original "transclusion" idea of Ted Nelson, see [41]. See [25] and [24] for applications to teaching support, and [6], [28] and [34] for applications to electronic journals and digital libraries. For electronic journals see also in particular the beautiful "classic" papers by Odlyzko, [43] and [44].

To be able to type links offers a tremendous additional potential: it is possible to display different links differently (indicating that one is a footnote, the other one a reference, the next one a link back to a table of contents), to filter out links (e.g., to only show links created by certain authors within a certain time period), or to perform even more complex computations based on the link types.

Hyperwave allows annotations, another feature that requires non-embedded, typed links: an arbitrary document can be attached as annotation to another one by you (even if you have no editing privileges for either of the two documents) and the link to the document attached is shown as annotation. This can be generalised to computer conferencing where link types can be used to show that for a particular thesis a certain number of counter-examples, supporting arguments, generalisations, etc. have been proposed.

Summarising, the original link concept of WWW works well for small amounts of data (say 50 documents) but just does not support larger amounts of data, multi-person co-operation, customisation and other features necessary in educational applications: more powerful additional features as available in Hyperwave are essential.

There is still another twist to links: without additional structure, using links in a large system becomes very confusing, much like "spaghetti-programming" in first generation high level programming languages such as FORTRAN or Basic. It is desirable to organise and structure information in a way going beyond having a "flat database with myriad's of links". In Hyperwave one crucial concept in this direction is the notion of collection mentioned earlier. Documents are gathered into collections, collections may belong to other collections, etc. with a DAG-like structure.

Not only does this allow to structure material better so that it is easier to find; not only does it allow to define the scope for searches, or for the material to be packaged on a CD-ROM, or printed out, or whatever. It is also a powerful tool to replace links to some extent. To be specific, suppose we have defined a collection "pictures of Graz". Once this has been done adding a picture to this collection does not require the creation of any links (nor would the removal of a picture necessitate adjustment of links): when the collection is accessed the titles of all pictures are shown and the relevant ones can be selected. If the collection has the attribute sequence one can automatically step forwards and backwards in the sequence of pictures, again requiring no links at all. Exactly the same applies to sequences of educational modules.

To quote Dieter Fellner from the University of Bonn, Germany: "The collection concept alone is reason enough to choose Hyperwave as WWW server".

In ordinary WWW servers HTML pages or other documents are stored as such, without any "meta-information", i.e. without any information about the documents. In contrast, in Hyperwave every document has some standard attributes and arbitrary further ones as defined by the user. Standard attributes include author, creation date, date when the data is to be made public, expiration data, keywords, etc.

Note that such attributes are invaluable for searching and for administration. Typically, if a document concerns an event on a particular date, clearly the document should be removed (and links pointing to it deactivated) after this date. In ordinary WWW systems this has to be done manually. This requires much effort, tends to lead to many documents whose removal has been forgotten and hence are obsolete, and adds to links whose activation results in a message "object not found" or such, since when the document was removed the deactivation of some link in some document (invisible due the unidirectionality of links in ordinary WWW systems!) was forgotten. In Hyperwave a document as mentioned would be entered with an appropriate expiration date. The removal of the document and the deactivation of links pointing to it (or at least the notification of owners of links pointing to it) can be handled without manual intervention by Hyperwave.

Consider as further example some server that wants to present a new joke every day. In an ordinary WWW server some person has to manually (even on Sundays and holidays!) replace the current joke by the new one ... and if possible at 00:00 hours, so that early risers find a new joke and won't be disappointed. Using Hyperwave an arbitrary set of jokes can be entered into the system, successive jokes with successive opening and expiration dates. The system will do the rest! When using a WWW system pedagogical and psychological reasons will often suggest to make material available a piece at a time: again, the attributes …"opening date" and "expiration date" are exactly what one needs.

Of course creation/modification dates are also valuable in other contexts. It may be a good idea for the Webmaster to have the system show educational material that has not been modified for (say) 2 years: the likelihood that such documents are not of interest any more or are obsolete is very high. In ordinary WWW systems it is impossible to even determine if a document has not been modified for a long time or not. The author attribute of a document is also helpful for administrative purposes. Consider again a specific example: if the presentation of a university, as becomes more and more usual, includes a presentation of the personnel including some WWW pages edited by the persons at issue it might be wise to check once in a while whether the server contains information on persons no longer associated with the university. Again, this is virtually impossible with ordinary WWW servers, but is easy to handle with Hyperwave.

Thus, document (and collection) attributes in Hyperwave are just one other feature supporting system administration. Remember that structuring information was one other such helpful feature, and turned out not only to be convenient for the system administrator, but also for users: it allowed users to e.g. search for information within certain scopes (unions of collections) eliminating many useless "hits" when applying a search engine. The same holds for attributes: they can be used for searching. Hence searching within a certain scope and e.g. only for documents created after a certain date, or by a certain author, allows much more specific queries than would otherwise be feasible.

It is our contention that ordinary WWW and HTML should be seen as "thin interface layers" (and this is how Hyperwave treats them) but that more powerful tools must be used as further underpinning (and this is what Hyperwave does). For detailed information see the "HyperWave" book [30]. An electronic version of this book is available under http://www.iicm.edu/hgbook. Additional information on Hyperwave can also be found in [3], [18], [19], [20] [22] and up-to-date manuals on http://www.hyperwave.com.

11. Current state of implementation

Much of the functionality needed by a WWW server for GENTLE is available in Hyperwave, as explained in section 10. However, a number of tools (particularly on the client-side as Netscape and MS Explorer support) for authoring and administration are necessary and have been developed or are in the process of being developed. A package called GENTLE-Tools Version 1.0 that converts Hyperwave in a GEneral Networked Teaching and Learning Environment (= GENTLE) will be available for CeBit'98 (March 1998).

This package satisfies all basic requirements of sections 1-3, 6, and 10 of this paper and provides basic functionalities of sections 4, 5, and 7. Most aspects of sections 8 and 9 will have to wait for later versions of the GENTLE tools for adequate solutions. However, ad hoc partial solutions can of course be implemented.

12. Summary

GENTLE tools, a package that converts Hyperwave in a GEneral Networked Teaching and Learning Environment, have been in prototype use since spring 97. By spring 98 a first official release, Version 1.0, will be ready. Improvements of GENTLE by a team of about 10 persons will continue till at least December 1999. Thus, the start of 2000 will see a GENTLE of unprecedented generality and usability in educational environments, be it schools, universities, companies, government agencies or other organisations in need of efficient and cost effective educational techniques.

REFERENCES

  1. Adam, N.R., Bhargava, B.K., Halem, M., Yesha,Y. (Eds.) (1995). Digital Libraries. LNCS 1082, Springer Pub. Co., Heidelberg.
  2. Andrews, K.,Kappe, F.; Maurer, H. (1995). "Hyper-G and Harmony: Towards the Next Generation of Networked Information Technology", Proceedings of CHI (1995), Denver, USA, 33-34..
  3. Andrews, K., Kappe, F., Maurer,H., Schmaranz, K.(1995). "On Second Generation Hypermedia Systems", Proc. of ED-MEDIA, (1995),Graz, Austria, 75-80. See also J.UCS 0,0 (1994),127-136 at http:///www.iicm.edu/jucs.
  4. Andrews, K., Kappe, F., Maurer, H.(1995). "Serving Information to the Web with Hyper-G", Computer Networks and ISDN Systems27 , 919-926
  5. Bacher, Ch., Ottmann, Th. (1996). "Tools and Services for Authoring on the Fly", Proc. of ED-MEDIA (1996), Boston, USA, 7-12.
  6. Calude, C., Maurer, H., Salomaa, A. (1994). "J.UCS: The Journal of Universal Computer Science", J.UCS 0,0, 109-117 at http://www.iicm.edu/jucs.
  7. Conklin, E.J.(1987). "Hypertext: an Introduction and Survey", IEEE Computer20, 17-41.
  8. Dewan, P.(1993). "A Survey of Applications of CSCW Including Some in Educational Settings", Proc. of ED-MEDIA (1993), Orlando, USA, 147-152.
  9. Duval, E., Olivie, H., Scherbakov, N. (1995). "Contained Hypermedia", J.UCS 1, 10, 687-705.
  10. Fenn,B., Maurer, H.(1994). "Harmony on an Expanding Net", ACM Interactions 1,3, 26-38.
  11. Flinn, B., Maurer, H. (1995). "Levels of Anonymity", J.UCS 1,1, 35-47.
  12. Gillard, P., Maurer, H. (1990). "Tiny CAI Tools –Giving Students "the Works"", J.MCA 13, 337-345.
  13. Hahn, B.J., Kahn, P., Riley, V.A., Coombs, J.H., Meyrowitz, N.K.(1992). "IRIS Hypermedia Services", Communications of the ACM 35,1, 36-51.
  14. Hall, W., Davis, H., Hurtchings, G.(1996). Rethinking Hypermedia. Kluwer Academic Pub., Boston/London.
  15. Huber, F., Maurer, H.(1987). "On Editors for Presentation Type CAI (Editoren für Präsentations-CUU)", Angewandte Informatik 11, 449-457.
  16. Huber, F., Makedon, F., Maurer, H.(1989). "Hyper-COSTOC: A Comprehensive Computer-Based Teaching Support System", J.MCA 12, 293-317.
  17. Kappe, F. (1995). "A Scalable Architecture for Maintaining Referential Integrity in Distributed Information Systems", J.UCS 1,2, 84-104.
  18. Kappe, F., Maurer, H., Scherbakov, N.(1993). "Hyper-G - a Universal Hypermedia System", Journal of Educational Multimedia and Hypermedia 2,1, 39-66.
  19. F. KAPPE; H. MAURER Hyper-G: A Large Universal Hypermedia System and Some Spin-offs. IIG Report 364, Graz, Austria, 1993; also appeared as electronic version, anonymous FTP siggraph.org, in publications/May-93-online/Kappe.Maurer.
  20. Kappe, F., Maurer, H. (1994). "From Hypertext to Active Communication/Information Systems", J.MCA 17,4, 333-344.
  21. Kappe, F., Maurer, H., Scherbakov, N., Srinivasan, P.(1994). "Conceptual Modeling in Hypermedia: Authoring of Large Hypermedia Databases", Proc. of Hypermedia (1994), Vaasa, Finland, 294-304.
  22. Kappe, F., Andrews, K., Faschingbauer, J., Gaisbauer, M., Maurer, H., Pichler, M., Schipflinger, J. (1994). "Hyper-G: A New Tool for Distributed Multimedia", Proc. of the IASTED/ISMM Conf. on Distributed Multimedia Systems and Applications, Honolulu, USA,209-214.
  23. Kearsley, G.(1992). "Authoring Systems in Computer Based Education", C.ACM 25,, 429-437.
  24. Lennon, J., Maurer, H. (1994). Lecturing Technology: A Future With Hypermedia; Educational Technology 34,4 (1994), 5-14.
  25. Lennon, J., Maurer, H.(1995). "Digital Libraries as Learning and Teaching Support", Proc. of ICCE (1995), Singapore, 28-33.
  26. Lennon, J., Maurer, H. (1995). "Lecturing "On the Fly"",. Proc. of ICCE (1995), Singapore, 150-156.
  27. Makedon, F., Maurer, H.; Ottmann, Th. (1987). "Presentation Type CAI in Computer Science Education at University Level", J.MCA 10, 283-295.
  28. Marchionini, G., Maurer, H.(1995). "The Role of Digital Libraries in Teaching and Learning", Communications of the ACM 38,4, 67-75.
  29. Maurer, H. (1994). "Lecturing in the Future: Bringing it all Together",.Proc. of ED-MEDIA (1994), Vancouver, Canada, 46.
  30. Maurer, H. (1996). HyperWave: The Next Generation Web Solution, Addison Wesley Pub.Co., UK.
  31. Maurer, H. (1996). "LATE: A Unified Concept for a Learning And Teaching Environment", J.UCS 2,8, 580-595.
  32. Maurer, H., Tomek, I. (1990) "Hypermedia in Teleteaching" (Invited Paper), Proc. of the Fifth World Conference on Computers in Education (1990), Sydney, Australia, 1009-1015.
  33. Maurer, H., Philpott, A., Scherbakov, N. (1994). "Hypermedia Systems Without Links", Journal of Microcomputer Applications 17, 4, 321-332.
  34. Maurer, H., Schmaranz, K.(1994). "J.UCS -- The Next Generation in Electronic Journal Publishing". Proc.of the Electronic Publ. Conference (1994), London; also in: Computer Networks for Research in Europe 26 , Supplement 2-3, 63-69.
  35. Maurer, H., Scherbakov, N., Schneider, A.(1995). "HM-Card: A New Hypermedia Authoring System", Multimedia Tools and Applications 1, 305-326.
  36. Maurer, H., Scherbakov, N., Schneider, A.(1995). "Support for teaching in a hypermedia university transaction, information and communication system", Proc. of ED-MEDIA (1995), Graz, Austria, 448-453.
  37. Maurer, H., Scherbakov, N.(1996). Multimedia Authoring for Presentation and Education: The Official Guide to HM-Card, Addison Wesley Pub.Co., Germany.
  38. Maurer, H. (1997). "Necessary Ingredients of Integrated Network Based Learning Environments", ED-MEDIA'97, Calgary, Canada (June 1997), 709-716.
  39. Maurer, H., Mayrhofer, V. (1997). Handling Large Web Sites on Internet and Intranets - The Official Guide to Hyperwave, dpunkt, Heidelberg.
  40. Mühlhäuser, M. (Ed.) (195). Cooperative Computer-Aided Authoring and Learning. Kluwer Publisher, Boston.
  41. Nelson, T.H. (1987). Literary machines. Edition 87.1, 702 South Michigan, South Bend, IN 46618, USA.
  42. Nievergelt, J.(1980). "A Pragmatic Introduction to Courseware Design", Computer 13, 7-21.
  43. Odlyzko, A.M.(1994). "Tragic Loss or Good Riddance? The Impending Demise of Traditional Scholarly Journals", J.UCS 0,0, 3-53 at http://www.iicm.edu/jucs.
  44. Odlyzko, A.M.(1996). "On the Road to Electronic Publishing", Euromath Bulletin (1996); see also J.UCS 2,11 http://www.iicm.edu/jucs.
  45. Pichler, M., Orasche, G., Andrews, K., Grossmann, E., McCahill, M.(1995). "VRweb: A Multi-System VRML Viewer" Proc of. VRML (1995), San Diego, CA,77-85.
  46. Van Dam, A.(1988). "Hypertext'87" (Keynote Address) Communications of the ACM 31,7, 887-895.

*) This acronym was first coined by my good friend Professor Skordalakis from the National Technical University Athens who has given me kind permission to use the term.