Developing small teaching programmes is relatively simple, so simple that more or less anybody can do it. A simple programme means using a few nodes and links, like those commonly used for WWW homepages. For teaching purposes, however, this will normally not be adequate, the systems become larger. A designer must therefore place special emphasis on alleviating user problems concerning orientation and navigation, and on guiding the user's accumulation of experience.
The challenge in the future will be that hypersystems must lend themselves both to independent use and to networking.
Previous chapters examined the construction and design of hypersystems and conceptual models. There is, however, another classification which may be reasonable to examine, and that is the type of environment in which the hypersystem is intended to work.
A microsystem is a hypersystem featuring only internal links to other nodes in the data medium. One example of this type is a course which is taught via diskettes or CD-ROMs, using no references external to the medium. One obvious advantage is that this permits a user to work his way through a course using his local computer only, obviating the need to connect directly to a computer network or via a telephone.
Most courses based on multimedia are more than likely of this type. Microsystems have clear advantages for distance teaching because connecting to computer networks via telephone lines comes at a price.
Macrosystems may link to nodes on other storage devices in addition to the local links microsystems use. Such links need not be restricted to a local data system, but may also be links to other nodes in a local or global network.
There is an increasing use of macrosystems in the field of teaching. Seeing a World Wide Web which has come to comprise almost any item of information, irrespective of its usefulness for us, it may be tempting to create links to Web information. We can have everything using a course package exploiting institutional, national and global modules.
However, this flexibility also has a disadvantage - the need to be continually connected to a network during the progression of a course. This may mean high expenses for some people, as everyone may not be located at the one institution or may not have access to the institution's network. A number of students will have to pay for this themselves, perhaps even being charged high business-hour telephone rates. Another drawback is speed. Taking a course module necessitates frequent hypersystem navigation, which may be very time consuming. Inadequate speed may push users to the brink of abandoning the course.
This is no secret to hypersystems designers, so they have attempted to mitigate these problems. Hence some systems feature the option of storing all information, including that found through external links on a storage device, for example a CD-ROM. Thus a microsystem is generated from a macrosystem.
This is a viable option if the information is not too unwieldy,
but copyright problems may thus be infringed. Experience tells
us that there is a lot of work to be done before this will work
smoothly.
Figure 5.1 Microsystem created from a macrosystem The world of information Microsystem, e.g. a CD-ROM
Groupware is a much used term of late. It means that a number of users may collaborate across a network, for various purposes. At NITOL, we have successfully employed this method for close collaboration with institutions all over southern Norway. Almost all our collaborative work is performed this way, we hardly use the telephone or "physical" meetings. Reports and applications are worked out and exchanged across the network. However, we must admit that we have not employed hyperstructures, as our collaboration started at an early stage when hyperstructures were not very common. The hypersystem developed under JITOL (Just In Time Open Learning), NITOL's predecessor, has not been continued.
Hyperstructures are very useful for group work, allowing structures to be built according to need. There are high expectations for this kind of future use of hyperstructures. The background for the World Wide Web was the need for a computer tool for group work. Groupware may also be used for games or simulations permitting several participants, for example when simulating running a business with purchasing and sales departments, accounting offices etc.
As mentioned in the introduction to hypersystems, escaping the rigid teaching programmes of the early period, which suffered from "paging" or "tunnel" syndromes, has long provided an impetus for change. These early forays were generally rigid systems which did not satisfy user requirements for individual programmes, and users' individual ways of approaching various issues. Furthermore, they were developed using very basic computer systems with a pronounced dearth of technical features.
With the arrival of hypersystems we have expanded opportunities for a user to decide on his own pace during courses, while the technology offers speedy navigation and a multitude of presentation modes, for example graphics, audio and video. Nevertheless, whether we are designing a course using hypermedia or not, these basic questions need attention:
In order to study degrees of freedom for course designers from
an overarching point of view, we may start by examining how Hutchings
(92) views this issue. He focuses on three factors of special
significance for educational programmes developed in hypersystems.
The issue has been rendered as a cube placed in a three-dimensional axis system. One axis is called Synthesis, its extremes being presentation and creativity, the second is called Control and its extremes are student and teacher/system, and the third axis we call Participation with its extremes active and passive. The cube is furthermore divided into smaller cubes numbered 1 to 8.
We may say that the corner of cube 1, the intersection of passive, teacher/system and presentation represents traditional film or video. The student is an observer during the presentation which is controlled by the teacher/system, and the student is a spectator.
The corner of cube 7, the intersection creativity/student/active,
represents an active, creative student controlling his own progress,
for many people exemplifying the complete student. We might draw
an arrow from corner 1 to corner 7, and call this the pedagogics
arrow, from the passive, controlled and observing student to the
creative, active and self-controlling student.
Figure 5.3 Hutchings cube extended with the pedagogics arrow
If we connect this to a hypersystem, corner 7 designates a case where the student must orient himself alone, and on his own perform all navigation in the familiar and unfamiliar landscapes. This is very similar to entering a castle or museum and wandering around, for the freedom to open the next door, peering through full of curiosity, may be both exciting and fascinating. However, beginners will especially want to have some guidance, placing everything in a system.
This also applies to using hypersystems. In matter of fact there are two types of hypersystems: those where we look at this and that (browsing or surfing in Internet language), and those where we follow a programme, where progress is well-structured, which is we want in a teaching system. Both types have their uses where they are well suited, what we want to know is where each of them is best suited.
Returning to our cube, this means that we do not follow the pedagogics
arrow directly, rather we detour to cube 6, thus designing a
guided tour or tours (cf. section 4.3.1) through the hypersystem.
Some hypersystems permit this, the most spartan form of guided
tours being the use of bookmarks. If we have created a really
sophisticated system, we may design guided tours for those who
only want an introduction, for those who want to learn how to
use a system (e.g. a Unix user course), and for those who want
more detailed information.
Figure 5.4 Hutchings cube with the addition of a Guided tour
Such an overarching view of a hypersystem does not mean that we should not use film and video clips, animation, simulation etc. to support and reinforce our message. Rather the opposite, these may frequently be essential components.
Even if it should be obvious, it is nevertheless appropriate to mention that the prime intention of a hyperdocument is understanding, as with all other documents. A mental model must be constructed to represent the objects and semantics of the text. Document readability may be defined as the mental effort required to form a correct mental model.
This may require considerable capacity on our part. Studies have shown that difficult navigation and orientation problems compete directly for our total capacity, which means that they may hamper our capacity to form mental models of the document content, the message. This is one of the reasons why well-structured hypersystems/hypermedia/hyperdocuments are so important.
As a general rule one can say that a plethora of text is not well suited for teaching programmes created using hypersystems. Studies have shown that up to 30% more time may be required to read a text off the screen than reading it off paper with the same understanding of the content (Schneiderman and Kearsley 89). If orientation and navigation problems are included, the time needed may easily be doubled. Furthermore, it is well to remember that a number of people find it hard to read off a computer screen - "screen dyslexia" is said to affect up to 20% of the population.
This must of course be taken into consideration. Hence we attempt to reduce the amount of text elements as much as possible, we use more figures, graphics, animations etc. than when we publish on paper. There is, however, no escaping text so we must be stringent when we build document logics (using sections and chapters) and an expedient layout. It is also incumbent on us to know our intended audience - are we writing for beginners (novices) or sophisticated users. If there is no way around using a considerable amount of text, the better solution is to append it as a reference, in a place which one can access whenever necessary, and which does not interfere in a disruptive manner with course progress.
When composing sequential texts, a particular style of writing becomes the norm and it may be hard to leave this when producing texts for a hypersystem course programme. Writing for hypersystems demands a writing style featuring brief texts, often not in sequence. Even a new syntax is required, as sentences must be concise and straight to the point.
Instead of writing an extensive treatise on how to interpret a curve in a diagram, which we normally would do in a textbook, we simply state Observe and offer some key words. The curve should be demonstrated using an animation, making it natural for the student to follow a development hinging on the key words. Nevertheless, it is vital to find a balance as borrowing the overhead transparency style using only key words is not enough meat for the student. The programme will be too "light" and will not be able to stand in its own.
Generally it is necessary to utilise all the advantages a computer has over a book, for example:
Learning by example is an option which might be used on many occasions. You may demonstrate how things develop step by step through a process. You must show clearly what has happened at each stage, using a few words on what has happened, and by using colours, inversion, modification etc. to help the student follow the development. If the student is allowed the option of applying his own parameters or setting values, examples may become even more valuable and telling. In this context we may use many of the examples we employ for software design intended for instructional use, e.g. the NITOL course "Pedagogisk programvaredesign" [Design of Pedagogic Software] with the accompanying project work.
How a document is designed, what we call document coherence, is essential to understanding a document. Empirical studies have shown how user understanding is closely linked to document coherence. A document has good coherence if the reader in a simple way can form a mental model which corresponds to the content (Johnson-Laird, P. N. 89).
The coherence issue is commonly divided into local coherence and global coherence. Local coherence concerns paragraphs and chapters, while global coherence covers larger parts of a document. Local and global coherence are attained through sound document structure, using brief and precise sentences, paragraphs and chapters. Refer to the message in section 5.2.2. Understanding is an obvious and basic component in this case.
In the matter of hyperdocuments local coherence is tied to nodes and global coherence is tied to the entire hyperstructure or net structure.
A common requirement is that the node content should not extend beyond one screen, otherwise message coherence will be impaired. Normally, the amount of information that can be packed onto one screen is rather limited. It depends on screen size, of course, but there is a dilemma for course designers here too, for while tabletop computer screens are growing in size, laptops with small screens are also growing in popularity. Ideally, a course design should cater to all sorts of equipment, witness the requirements for this course.
Thus we easily land in a fragmentation problem, where technical reasons compel us to split document parts more than we want from a logical point of view, with the attendant danger of impairing local coherence. If we do not pay special attention when we are designing, a hyperdocument may become a collection of small bits of information lacking any obvious coherence. In order to enhance local coherence designers may employ a number of methods:
In my experience it has been necessary to include more than one screen in order to avoid too much fragmentation, but without getting negative user feedback. My conclusion is that the requirement that it should be possible to present all information in one node in one screen may be somewhat too strict.
A designer should attempt to avoid referring to other hypersystem locations. A better solution might be to review the material a number of times, at least logically. From a technical point of view, some systems permit storing the material physically only once.
In order to cope with the demand for global coherence, some frequently used methods should be applied:
Figure 5.5 Example of a composite node with table structure. The example is from course IT222: Operating systems at IFI, NTNU. The screen copy quality is poor, unfortunately. All the underlined words/terms are anchor points for further branches to be selected.
Figure 5.6 from the same course as Figure 5.5. First the
FIFO algorithm is presented, then there is an option to go to
a general description, analysis and implementation. Farthest to
the left is the main algorithm (FIFO) improvements are presented.
Sida som kom først inn, skal først ut FIFU/The
first page in is the first to go out FIFO
FIFU/FIFO
Generelt/General
Algoritmen: Gi en ny mulighet/The algorithm: Offer a new chance
Analyse/Analysis
Implementering/Implementation
Forbedringer/Improvements
Klokkealgoritmen/The clock algorithm
Figures 5.7 and 5.8 offer some design rules largely based on the work of Thuring, Hannemann and Haake (Thuring, Hannemann, Haake 95). The rules are designated with the letter I and a number ranging from 1 to 10. More on rule application follows in the subsequent table, Figure 5.8.
[Figure 5.7 How to support the construction of a mental model
of a hyperdocument.]
| Principle | Where design rules are used |
| P1: Use links with labels, names | I1+ and I2 |
| P2: Indicate similarity between information units | I1 and I2+ |
| P3: Focus on information unit contexts | I1 and I2+ |
| P4: Use overarching information unit | I3+ |
| P5: Visualise document structure | I1, I2, I4+, I8 and I9 |
| P6: Use key words in the visualised structure which displays reader's present position, the path leading there and also optional ways to continue | I5+, I6+, I7+ |
| P7: Develop a set of comprehensive navigation aids which cover the need for displaying direction and distance | I8+ and I9+ |
| P8: Utilise a fixed screen layout with windows in fixed positions and standard sizes | I10+ |
"+" indicates special importance
[Figure/Table 5.8 Design rules, to be used with Figure 5.7]
The introductory sections on hypermedia have referred to various familiar hypermedia systems. Most of these are very comprehensive and not easily accessible to interested persons. One alternative might be to use standard software for PCs. For MS-Windows we might use Windows' Help engine (Windows-Help), and for Macintosh users, HyperCard is a natural choice. Even if these do not meet all the criteria for hypermedia we have discussed, they may perform adequately in practice, at any rate if we lavish some extra care on the design.
Designing directly in Windows-Help is cumbersome, therefore a number of helper applications have been developed which permit constructing hyperstructures in Windows-Help in an easy and straightforward manner. Many of these permit creating hyperstructures using standard applications such as MS-Word. This means that we may "write" our course programme directly in Word or other standard applications, and then structure it as a hyperstructure.
Some familiar helper applications for this purpose are:
RoboHelp from Blue Sky Software, Help Breeze from Solutionsoft, MasterHelp from Performance Software Inc., Doc-To-Help from WexTech Systems Inc. and ForeHelp from ForeFront Inc.
All of these, apart from ForeHelp, are capable of transforming Word documents into hyperstructures under Windows-Help. ForeHelp is a so-called independent product with its own editor and a good navigation tool. Navigation tools are sorely lacking in the other products.
For the World Wide Web we use HTML or Hot Java. HTML is a scripting language, Java is a language (operating system) in many ways similar to C++, requiring the same skills to use. More tools are probably in the offing, one is the MS-Word feature which permits simple designs.
Anyone who decides to create a course programme using hypermedia must be willing to spend a significant amount of time on each lesson. It is hard to state how much time will be needed for the different courses, as this will largely depend on how much graphics, animations etc. are used, or whether the hyperstructure is created using only regular text files. The latter solution is by far the simplest, but this clashes with good advice for course design via hyperstructures.
When being so bold as to attempt to estimate time consumption, it would be realistic to suggest 30-60 hours production time per teaching lesson, once some experience has been gained. However, this would depend on the course programme. Nevertheless, a person wishing to try his hand at this must be prepared to supply most of his main motivation from the enthusiasm, joy, and curiosity of testing new teaching options - not from any misguided belief that this will make things easier.
Based on present developments, it appears safe to say that courses developed in hypersystems will flourish in future open learning. Even now course lessons of various types are flooding onto the market, supported by large organisations with the necessary clout for this. Thus even for a person who is not going to develop courses by means of hyperstructures, it is important to keep up-to-date in the field of open learning and to be familiar with hypersystems, their possibilities and limitations.