Synchronous navigation control for distance learning on the Web

12  Download (0)



Computer Networks and I SDN Systems 28 (1996) 1207-1218





Synchronous navigation control for distance learning on the Web

Ping-Jer Yeh *, Bih-Horng Chen 1, Ming-Chih Lai 2, Shyan-Ming Yuan 3

Institute of Computer and Information Science 4, 1001 Ta Hsuch Rd., Hsinchu, Taiwan30050, ROC


Most of the research on "distance learning on the Web" is learner-centric. That is, learners play an active role in their learning process, while instructors are passive or even invisible. Unable to treat the instructor/learner relationship as a whole causes some problems. Therefore, we introduce a new concept of instructor-oriented navigation control on the Web, and then propose and implement a protocol for it. In this model, an instructor (technically, master) can setup a learning group, and those who wish to be guided distantly (technically, slaves) during the study may have their navigation activities controlled synchronously by joining the group. We believe that instructors will become more active and positive with the help of our proposed model in a WSNW-based educational environment.

Keywords: Distance learning; Synchronous navigation control; Master/slave model; Instructor/learner relationship; Albatross

1. I n t r o d u c t i o n

The Albatross [1] is a W W W - b a s e d distance education system that aims to provide an integrated and distributed h y p e r m e d i a information environment for the academic community. In this environment, instructors can construct course material and prepare some learning assistance for learners; learners can access course material and participate in on-line and off-line discussion. Learners can use ordinary W W W browsers or Albatross clients, though with the latter they can use several unique functions easier.

* Corresponding author. Email:, william/.

I Email:, t w / - toto/

2 Email:, http://cissun51.cis.nctu. e d u . t w / ~ gis83502/

3 Email:, tw/smyua.n.html


After pilot experiments, we discover that it fails to treat the i n s t r u c t o r / l e a r n e r relationship as a whole. Our system, current W W W - b a s e d courseware as well, strives to solve navigation problems that learn- ers conceive, but ignores more positive aids that instructors can provide. Consequently, not only is instructor's potential underestimated in the domain o f distance education, but also are l e a r n e r ' s naviga- tion problems handled incompletely.

W e re-examine the W W W model, and find that such a c l i e n t / s e r v e r m o d e l fails to support direct interaction between instructors and learners. There- fore, we propose a concept o f m a s t e r / s l a v e models and synchronous navigation control so that instruc- tors can help learners more in distance learning environment.

1.I. Background

Distance education exists for more than one hun- dred years, and there are various theories, media, and

0169-7552/96/$15.00 © 1996 Published by Elsevier Science B.V. All rights reserved PII S 0 1 6 9 - 7 5 5 2 ( 9 6 ) 0 0 0 6 5 - 7


1208 P.-J. Yeh et a l . / Computer Networks and ISDN Systems 28 (1996) 1207-1218

approaches in this field [2]. Whatever technology it uses, a virtual classroom is always the aspiration. Students in this virtual classroom need not gather at the same physical place at the same time, while the same learning effects may be obtained, or even better.

As the World Wide Web (WWW) grows rapidly, researchers begin to incorporate their pedagogical ideas into it. In this way educational system can benefit from the WWW technology, such as multi- media documents, hypertext/hypermedia capability, openness of the WWW world, and popularity of WWW client/server software and HTML authoring tools [3].

However, the WWW has several drawbacks from pedagogical points of view, because it was not de- signed originally for this field. Some, commonly known as navigation problems, are probably inherent in hypertext systems, as discussed by Conklin [4], Wright [5], and many others:

• Disorientation. Too much nonlinear information makes users "get lost in space".

Cognitive overhead. Multi-path and nonlinear structure require more cognitive concentration and decision.

There are still other important issues not supported directly by current WWW-based educational sys- tems. For example, interaction and communication among instructors and learners are required to aid learning, problem solving, and experience sharing; logging of learners' behavior is required for statisti- cal and quantitative analysis; assessment functional- ity is also required to evaluate learning effects and system usability.

Various techniques have been proposed to handle these problems. Book-like overview maps, concept maps, fisheye views [6], etc. can help users under- stand the overall logical structure of large hyperdoc- uments. Guided tours, path mechanism [7], Footsteps [8], etc. can guide users to navigate through large hyperdocuments without too much cognitive over- head. In addition, many educational environments are equipped with text-mode, audio, a n d / o r video facilities to improve interaction and communication. They all help, but most of them are biased in favor of learners and consequently does not address the whole instructor/learner relationship well. With these systems, learners play an active role in the

learning process: they fetch, read, and select material independently. On the other hand, instructors are passive or even invisible: they merely construct course material, put them on the WWW, and then go behind the scenes, providing little positive aids to learners. Therefore, instructors are absent from the actual learning progress of learners. We call this

phenomenon student-centric.

However, to address the whole instructor/learner relationship well, instructors must play a more posi- tive and active role. With such initiative in hand, instructors may guide learners' learning progress through various visual and vocal hints, just as they do in traditional classroom. Without such considera- tion, a pedagogical system on the WWW is no more than a fashionable bulletin board.

1.2. Our solution

We implemented an WWW-based educational en- vironment, the Albatross, as described in our previ- ous paper [1]. In addition to a standard WWW browser, it has several new facilities to address navigation problems. The Overview Map provides an organized road map of the whole course material to address the disorientation problem. The Guide Tool provides logging and prerequisite constraints; when combined with Navigation Hints, it can address par- tially the cognitive overhead problem. In addition, the Notebook provides public and private notes asso- ciated with individual documents so that each user may share ideas and experience. They all start to give positive aids beyond simple information presen- tation.

However, they are intrinsically prepared before,

not dynamic and discretionary during the learning

progress of learners. What we need is not only the former, but also the latter, so that the quality of learning process can be improved.

In this paper, a new mechanism for instructor-ori- ented navigation control is further proposed and implemented. An instructor can setup a learning group. Those who wish to be guided distantly during the study may join a specific group, and then their navigation behavior, such as document retrieval and scrolling, can be guided synchronously by the in- structor. With this addition, some problems may be


P.-J. Yeh et a l . / Computer Networks and ISDN Systems 28 (1996) 1207-1218


partially resolved and are listed as follows:

• disorientation is decreased because the instructor can focus the group participants on a limited set of documents;

• cognitive overhead is eased because the learners can follow the instructor's on-line guidance if they wish;

• interaction is improved because the instructor can make real-time visual hints and guidance; • adaptability is enhanced because the instructor

may adapt the learners' navigation paths to fit in different situations.

The remainder of this paper is organized as fol- lows. Section 2 introduces the concept of syn- chronous navigation control in the context of WWW-based distance education. Section 3 describes our implementation of such architecture and protocol in detail. Section 4 discusses possible application of this synchronization concept. Section 5 enumerates related work. Section 6 summarizes the paper and offers some future directions.

2. Concepts of synchronous navigation

This section explains some features not supported on current W W W system. It then defines terminol-

ogy, roles and activities involved, and finally dis- cusses the mechanism and policy of synchronous navigation control.

2.1. Limitations of HTTP

Some strength and weakness of W W W can be traced back to its underlying transmission protocol: the Hypertext Transfer Protocol (HTI'P). According to current H T T P / 1 . 0 specification [9], participants in any HTTP connection are merely a pair of one client and one server of various kinds (original server, proxy, gateway, or tunnel). Normally, the client is the user agent requesting resources identified by Universal Resource Identifiers (URIs), while the server is the site holding or transferring resources.

This client/server model is adequate for basic data search and retrieval but inadequate for our needs:

Inter-client communication is not taken into ac- count in HTTP.

• HTFP is stateless, but synchronous control re- quires state-awareness.

• An HTTP connection is established at the request of the client and then closed as the server replies, but synchronous control performs better on a permanent connection.



~ . f / /


modeX~ O..n


t l

/ ~ ~ "--~. f e t c h courses .

S ver~

Ordinary WW~/clien~ ~''~ - . ~ w w ~ ser~ (


~-~ query group database


master mode~


- - ~--synchronized navigaiion ---/

synchronization level

i (

" - )


1210 P.-J. Yeh et a l . / Computer Networks and lSDN Systems 28 (1996) 1207-1218

Because of these restrictions, we propose an addi- tional master/slave model which enables syn- chronous navigation control over learners on the WWW. This section describes new roles and rela- tionships of participants in this model.

2 . 2 . R o l e s

Participants' roles and capabilities in our new model differ from that in a traditional client/server model on which current WWW bases. Recall our motivation for synchronous navigation control. The instructor who wishes to guide others distantly may setup a learning group, and those who wish to be guided may join an existing group. In this way, the instructor may guide learners synchronously through navigation, visual and vocal hints. As the scenario goes, several new roles and relationships appear on the scene. To formalize and broaden the range of problem domain, we define the following terminol- ogy.

• C l i e n t : A program that establishes connections for the purpose of sending requests, just as de- fined on HTTP specification.

• S e r v e r : A program that accepts connections in order to service clients' requests for resources, as defined on HTTP specification.

• G r o u p : A logical collection of on-line clients browsing on the same set of documents with synchronous navigation behavior.

• M a s t e r : A client that acts as a group leader; the role is often taken by instructors, moderators, leaders, or peer-tutors.

• S l a v e : A client that acts as a passive group partic- ipant; the role is often taken by learners, follow- ers, or onlookers.

Fig. 1 illustrates the roles and relationships in the master/slave model. Among them, servers are repos- itories of course contents, logs, and other educational facilities, while clients are user agents used to fetch, read, and navigate through that hypermedia informa- tion. These roles remain unchanged as in a tradi- tional client/server model.

Moreover, we introduce several new roles to sup- port synchronous navigation. A client may turn into a master by registering a specific group on the server. Other clients can query on the server to find out existing group lists, something about group mas-


P.-J. Yeh et a l . / Computer Networks and ISDN Systems 28 (1996) 1207-1218 1211

ters, and other related information, as shown in Fig. 2. If a client wishes to become a slave in an existing group, it can select any group of interest to join in by requesting the group master. When a master/slave connection is granted and established successfully, the client turns into a slave and its navigation is synchronized with the master.

After a master/slave connection is established, all control activities for synchronous navigation occur in this connection only, irrelevant to any server. There- fore, servers require no modification and they will not be the bottleneck.

Two issues about the master/slave connection deserve attention. First, since a master guides many slaves in the same group, the cardinality of relation- ship is one-to-many. Second, we model their rela- tionship as an attributed association rather than sim- ple multicast, because there may be different levels of synchronization according to their negotiations.

Being an attributed association gives individual vari- ation and more flexibility for the whole system. We discuss the "mechanism versus policy" issue re- garding this relationship in Section 2.4.

2.3. Which to synchronize?

The main purpose of synchronous navigation is for a master to guide on-line slaves immediately. Synchronous activities vary diversely in forms, rang- ing from full control of hardware to simple notifica- tion of software display. Instead of implementing plenty of synchronization, we focus only on those that are important for distance education.

From the learner's perspective, hypermedia docu- ments are obviously the objects and media of learn- ing materials on the WWW, so they are naturally the target of navigation control. If we observe the learn- ing behavior of WWW users, typical types of docu-


1212 P.-J. Yeh et al. / Computer Networks and I SDN Systems 28 (1996) 1207-1218

ment navigation are easily identified:

• Access to a new object identified by an URL (Uniform Resource Locator). This may be done by keying in a new URL, by clicking on a hyperlink, or by selecting a bookmark/hotlist item from within the browser.

• Access to a visited object. This may be done by clicking on back/forward toolbar icons or menu items.

• Horizontal and vertical scrolling. This may be done by using function keys or scroll bars. • Highlights on special texts or graphs. This is

often done by positioning or dragging the mouse. Therefore we implement the following synchro- nization activities:

• retrieval and display of common documents, • synchronous document scrolling,

mouse positioning, and

common highlights a n d / o r handwriting on docu- ments.

Fig. 3 illustrates these synchronous navigation activities. Here, master A, slave B, and slave C are in the same group. Master A reads a document, and so do slaves B and C. Master A scrolls its document view horizontally and vertically, and slaves B and C scroll as well. Master A highlights on the document, and the same highlights also appear on document views of slaves B and C.

The underlying protocol is discussed in Section 3.

2.4. Mechanism versus policy

The mechanism of navigation control is better separated from the policy. The mechanism concerns protocols and procedures, while the policy concerns enforcement of synchronization rules between a pair of master and slave. Failure to distinguish between them will lead to the loss of flexibility and auton- omy.

Pedagogical theories change from earlier behav- iorism to recent cognitivism and constructivism. Course representations change from linear textbooks to nonlinear hypertexts. Distributed computing and distance education grow rapidly. These all reflect the trends of decentralization and autonomy [2,10]. Dis- tance education values more at learner autonomy in its nature. Therefore, if a master (e.g., an instructor) puts exceeding synchronous control over its slaves (e.g., learners), the motivation and advantages of navigation control will be defeated by compulsion.

Separation of mechanisms allows more flexible learning behavior and makes self-paced learning pos- sible, while on-line guidance still coexists. A mas- ter/slave pair may agree on an appropriate "syn- chronization level" according to the slave's situa- tion, and the policy decides the choices, contracts, and enforcement of various synchronization levels. Thus, the guidance with navigation control becomes assistance, rather than confinement.

The more flexible a synchronization policy is, the

Albatross in master mode Albatross , ~

Albatross in slave mode Albatross

Fig. 4. Illustration of architecture.


P.-J. Yeh et a l . / Computer Networks and ISDN Systems 28 (1996) 1207-1218 1213

more freedom learners may enjoy. An experienced learner, for example, often at will scrolls the docu- ment view and jumps to other URLs. If synchronized too much, he or she may suffer annoying "scroll w a r s " [11]. For such people, we may specify in the rule that their document scrolling and retrieval are synchronized only when the master forces it explic- itly. In contrast, it is reasonable to synchronize most navigation activities of a novice.

"Which set of synchronization policies is more flexible, reasonable, and suitable for distance educa- tion?" Perhaps more experiments and analysis are required so we may answer the question.

3. Architecture and protocol

This section describes the overall architecture and detailed protocol of Albatross implementation.

3.1. Overview

The overall architecture and protocol of this sys- tem are depicted in Fig. 4. Note that each operation is associated with a number. The numbers corre- spond to the same numbers in Section 3.2 where we will discuss the operations in detail.

We can divide the protocol into three categories: group repository interface, per-group interface, and synchronous navigation interface.

Group repository interface (No. 1-5 in Fig. 4) concerns the creation, deletion, query, and other maintenance issues of the group database. The group database is stored in a public WWW server for W W W clients to query. If a client wants to be a master, it can register itself in the database; when it no longer wants to be, it can cancel the entry. All work on servers is done by server-side programs compliant with the Common Gateway Interface (CGI). Since communication in this category in- volves W W W servers, H T r P is used for underlying message transmission.

Per-group interface (No. 6 - 9 in Fig. 4) concerns connections between individual master/slave pairs. After query on group data (No. 4 and 5 mentioned above), any client who wishes to be a slave may

select a registered group and issue the connection request to the group master. The connection can also be released by either participant: the master or the slave,

Synchronous navigation interface (No. 10-14 in Fig. 4) concerns all activities of synchronous naviga- tion control. This is the most important part of the 3 categories, so many alternatives to the same function are provided. For example, all requests contain an optional WITH-ACK field (as shown in Section 3.2 which enables assured synchronization mode be- tween a pair of master and slave. Again the judgment is left as policy; we provide mechanisms only.

As for retrieval and display of common docu- ments, three methods are provided for various trans- mission conditions:

• Direct data transmission (No. 10). The master packages up hypermedia data and transfers them directly to slaves.

• URL notification (No. 11). The master tells slaves the URL with which slaves can retrieve common documents. If transmission time is shorter for slaves to retrieve documents directly from the server, this method performs better.

• URL notification with proxy location (No. 11 with PROXY field filled). The master has fetched documents via the proxy, and tells slaves to fetch them via the same proxy.

In addition, three types of synchronization are provided to aid slaves with on-line and real-time guidance:

, synchronous document scrolling (No. 13, using

SCROLLTO field);

• mouse positioning with text comments (No. 13, using POSITION field);

• common highlights a n d / o r handwriting on docu-

m e n t s ( N o . 13, using B E G I N D R A W /

NEXTDRA W fields).

3.2. Protocol

We explain communication details as follows. To be consistent, we use the augmented Backus-Naur Form (BNF) and basic nonterminals specified in HTTP 1.0 specification [9] to define our protocol for synchronous navigation control.


1214 P..J. Yeh et al. / Computer Networks and ISDN Systems 28 (1996) 1207-1218

1. Create a new group.

Message di~ction:from a clientto aserver. Message ~rmm: < H T T P h e a d e r s > " C R E A T E " S P < g r o u p n a m e > " S I T E " S P < m a s t e r s i t e ~ h o s t : p o r t > [ " A L I A S " S P < m a s t e r s i t e ~ a l i a s > "ID" S P < u s e r I D c r e a t i n g t h e g r o u p > [ < m i s c e l l a n e o u s > ] L F L F L F L F

2. Delete an existing group.

Message di~ction:from a m a s e r D a s e ~ e r . Message ~rmat:

< H T T P h e a d e r s >

" D E L E T E " SP < g r o u p n a m e > L F

3. Response to previous C R E A T E ~ D E L E T E requests. Message di~ction:from a s e r v e r t o aclient.

Message ~rmm: H T T P - v e r s i o n S P S t a t u s - C o d e


t e x t / h i m 1 " *( < o t h e r f u l l - r e s p o n s e h e a d e r s > C R L F S P R e a s o n - P h r a s e C R L F ) C R L F [ < o r d i n a r y d a t a i n " t e x t / h t m l " f o r m a t > ]

Note: The client knows the status of its previous request from the S t a t u s - C o d e field in the ~ message. 4. Query the group list.

Message direction: from a client to a server. Message format:

< H T T P h e a d e r s >


[ < m i s c e l l a n e o u s > ]

5. Return current group list.

Message direction: from a server to a client. Message format:

< H T T P h e a d e r s >

< o r d i n a r y d a t a in " t e x t / h t m l " f o r m a t >

6. Join in a group.


P.-J. Yeh et al. / Computer Networks and ISDN Systems 28 (1996) 1207-1218 1215 Messageformat: " J O I N " SP < g r o u p n a m e > L F " S I T E " SP < h o s t : p o r t > L F "ID" SP < u s e r I D j o i n i n g in t h e g r o u p > L F [ < m i s c e l l a n e o u s > ]

7. Response to previous J O I N request. Message direction: from a master to a client. Message format:

{ "OK" I " E R R O R " ] L F [ < r e a s o n s > ]

Note: If the response is O K , a master/slave connection is established, and the client will turn into a slave. 8. Release a master/slave connection.

Message direction: from a slave to a master, and vice versa. Message format:

" R E L E A S E " S P < h o s t : p o r t > L F

9. Acknowledge previous R E L E A S E request.

Message direction: from a master to a slave, and vice versa. Message format:

" R E L E A S E - A C K " SP < h o s t : p o r t > L F

10. Transmit the contents of a file identified by the URL. Message direction: from a master to a slave.

Message format:

" F I L E " S P < f i l e ' s U R L > T A B < b l o c k s i z e > < a b l o c k of d a t a >

[ T A B " W I T H - A C K " ] L F

11. Transmit " U R L " only.

Message direction: from a master to a slave. Message format: " U R L " SP < U R L t h a t t h e s l a v e i t s e l f is t o l d t o f e t c h > [ " P R O X Y " S P < W W W p r o x y t h a t t h e s l a v e is t o l d t o t a l k w i t h > [ " W I T H - A C K " L F ] LF L F ]

12. Command the slave to show the data it has received so far. Message direction: from a master to a slave.

Message format:

" S H O W " SP < U R L w h i c h t h e s l a v e w a s t o l d t o d i s p l a y > [ " W I T H - A C K " L F ]

Note: It is used when there is too much transmission delay on the slave.


1216 P.-J. Yeh et aL / Computer Networks and ISDN Systems 28 (1996) 1207-1218

13. Synchronize other navigation activities.

Message direction:from a m a s ~ r t o aslave. Message ~rmat:

" A C T I O N " L F [ " W I T H - A C K " L F ]

< a c t i o n >

The (ac~on) is enumerated as ~llows: " S C R O L L T O " SP < p o i n t - x > " P O S I T I O N " SP < p o i n t - x > [ " M E S S A G E " SP " B E G I N D R A W " SP " N E X T D R A W " SP TAB < p o i n t - y > LF TAB < p o i n t - y > LF < m e s s a g e s t r i n g > ] < p o i n t - x > TAB < p o i n t - y > LF < p o i n t - x > TAB < p o i n t - y > LF

14. ACK response to previous No. 10-13 requests.

Message direction: from a slave to a master. Message format:

" D A T A - A C K " L F { " O K " I " E R R O R " ] L F [ < r e a s o n s > ]

4. Applications

Distance learning is certainly the motivation for our synchronous navigation control. Equipped with such facilities, knowledge exploration on distance education environment will not merely uni-direc- tional and learner-biased. Instructors can play a more active and positive role in distance instruction.

The idea of navigation control applies not only to education, but also to many fields. It can be used, for example, to give a manual hypermedia presentation. It can also be used to do an automatic demonstration if navigation scripts are provided. It can even act as a part of an Intelligent Tutoring System (ITS) that is capable of adapting navigation paths to individual's learning behavior and circumstance.

5. Related w o r k

Ideas about common display or, more broadly, about remote control are not entirely new. Some use special electronic equipment to get the total control at hardware level; some require specific operating

systems to achieve the desired effects; still others use proprietary applications that focus on a certain do- main of problems.

Groupware is perhaps the most famous and ma- ture application of this kind. Teleconferencing (e.g., the Colab [11]) and co-authoring (e.g., the DUPLEX [12]) have similar features of common display and annotation. However, they focus more on content collaboration, while our problem domain (distance education) focuses mainly on instructor-oriented nav- igational synchronization. Consequently, problems such as concurrency control and data serializability are not that serious.

Since the W W W is intrinsically distributed, col- laboration over it becomes a hot topic [13]. There are also several conferences and workshops (e.g., the " E R C I M Workshop on CSCW and the W e b " held on Feb. 1996) dedicated to it. We state here only typical work similar to ours.

The Yarn Web [14] extends an existing electronic meeting system to work with NCSA Mosaic. Its " c o m m o n document display" feature is similar to ours. However, it uses functions not generally avail-


P.-J. Yeh et al. / Computer Networks and ISDN Systems 28 (1996) 1207-1218 1217

able on other platforms: remote display capabilities in X Window System, and remote control (though we think the term "forced document loading" is more appropriate) in X version of Mosaic. In addi- tion, the Yam server forks a child process on the server side for each client connection (execution of the child process can be displayed by remote sites through the X protocol), so higher load and resource consumption are inevitable.

Virtual Places(TM) [15] provides a virtual'place where WWW users gather together, take on-line guided tours, and communicate with each other. It does have similar features to ours. However, its target is Internet on-line services, and therefore it lacks synchronization within documents and annota- tion found on most teleconferencing systems.

The WebDesk [16] is a collaborative environment that aims to support synchronous interaction (e.g., teleconferencing), asynchronous message exchange (e.g., electronic mail), and distributed document pub- lishing homogeneously and integratedly. It looks promising judging from its scope and framework,

though the project just begins.

Collaboration was not considered in original de- sign of the WWW (as discussed in Section 2.1, so extensions to WWW clients, servers, protocols, or their combinations are required in order to support synchronous navigation. We embed synchronization mechanism directly into the WWW client, while most systems (e.g., the Yarn Web and Virtual Places) hook themselves on WWW clients. With the former, all synchronization mechanism is performed by the augmented WWW client; with the latter, synchro- nization and inter-client communication are per- formed by the hooked programs. We choose the former because currently there are no standard, portable, and powerful solutions with the latter.

Three popular extensions provide general mecha- nisms that had to be hard-coded into WWW clients before. Common Client Interface (CCI) by NCSA Mosaic [17] and Netscape Client APIs (NCAPIs) by Netscape Navigator [18] both allow external pro- grams to command a WWW client to do something desired in a standard (or de facto) way. However, the commands are initiated by external programs, not by WWW clients. Therefore, communication between WWW clients, which occurs frequently during syn- chronization and collaboration, cannot be done ac-

tively by themselves, but by external programs only. On the other hand, Java by Sun Microsystems [19] does provide inter-client communication (which is i m p o s s i b l e in J a v a S c r i p t ) t h r o u g h the java. net. S o c k e t class family. However, event triggering occurs only on the frame windows of Java applets, not on those of a WWW client. Conse- quently, Java cannot synchronize the whole WWW client.

We may try to implement some functions with these extensions if more powerful they become.

6. Conclusion and future directions

In this paper, we stated several limitations of current WWW-based hypermedia systems for dis- tance education, discussed the need for an instructor-oriented and master/slave model, and in- troduced a new idea of synchronous navigation con- trol. We then proposed architecture and protocol for such functions, outlined possible applications of this concept, and surveyed related work.

We plan to support the model of problem-based cooperative learning in the context of distance educa- tion. Since our Albatross system is currently limited to a single master per group, we plan to turn it toward a more cooperative model. In this model, group participants take turns to synchronize others' navigation, so that they can share ideas and experi- ence more conveniently and efficiently. In addition, facilities for shared and individual knowledge con- struction are also required from pedagogical points of view.

We believe that the aspiration of virtual classroom is further approaching with these additions.


We would like to thank Hsin Pan and Shih-Ping Wang for reviewing this paper. We would also like to thank the anonymous referees whose helpful com- ments and suggestions improve the presentation of this paper.

This work was partially supported by the National Science Council of Taiwan, R.O.C. under Contract NSC84-2511-S009-004CL.


1218 P.-J. Yeh et a l . / Computer Networks and ISDN Systems 28 (1996) 1207-1218


[1] Ming-Chih Lai, Bih-Homg Chen and Shyan-Ming Yuan. Toward a new educational environment, in: Proc. 4th Inter- nat. World Wide Web Conf., World Wide Web J. 1 (1995) 221-230. h t t p : / / w w w . w 3 . o r g / p u b / C o n f e r e n c e s / WWW4/Papers/238/

[2] Chao-Hsiu Chen and Chien Chou, The definitions, theories, and technology uses in cooperative distance learning, in:

Proc. 4th Internat. Conf. on Computer Assisted Instruction

(1995) 11-16 (In Chinese).

[3] Bertrand lbrahim and Stephen D. Franklin, Advanced educa- tional uses on the World-Wide Web, in: Proc. 3rd Internat. World-Wide Web Conf., Computer Networks and 1SDN Sys-

tems 27(6) (1995) 871-877.

[4] Jeff Conklin, Hypertext: An introduction and survey, Com-

puter (IEEE) 2009) (1987) 17-41.

[5] Patricia Wright, Cognitive overheads and prostheses: Some issues in evaluating hypertexts, in: Hypertext '91 Proc., ACM, New York (1991) 1-12.

[6] Emanuel G. Noik, Exploring large hyperdocuments: Fisheye views of nested networks, in: Hypertext '93 Proc., ACM, New York (1993) 192-205.

[7] Polle T. Zellweger, Scripted Documents: A hypermedia path mechanism, in: Hypertext '89 Proc., ACM, New York (1989) 1-14.

[8] David Nicol, Calum Smeaton and Alan Falconer Slater, Footsteps: Trail-blazing the Web, in: Proc. 3rd Internat. World-Wide Web Conf., Computer Networks and ISDN Sys-

tems 27(6) (1995) 879-885.

[9] Tim Bemers-Lee, Roy T. Fielding and Henrik Frystyk Nielsen, Hypertext Transfer Protocol - HTTP/I.0, Internet Draft (February 1996). Protocols/HTTP/1.0/spec.html

[10] Martin Ryder, Instructional Technology Connections, (March 1996). gopher: / / /hO / UCD / dept / edu / IT/ryder/itcon.html

Ill] Mark Stefik, Gregg Foster, Daniel G. Bobrow, Kenneth Kahn, Stan Lanning and Lucy Suchman, Beyond the chalk- board: Computer support for collaboration and problem solv- ing in meetings, Comm. ACM 30(1) (1987) 32-47. [12] Francois Pacull, Alain Sandoz and Andr6 Schiper, Duplex: A

distributed collaborative editing environment in large scale, in: Proc. ACM 1994 Conf. on Computer Supported Coopera-

tive Work (1994) 165-173.

[13] Karen MacArthur, Collaboration, knowledge representation and automatability, h t t p : / / w w w . w 3 . o r g / p u b / W W W / Collaboration/

[14] Tak K Woo and Michael J Rees, A synchronous collabora- tion tool for World-Wide Web, in: Electronic Proc. 2nd

World Wide Web Conf. '94: Mosaic and the Web. h t t p : / / rees/SynCoITol.html

[15] Virtual Places(tm).

[16] Peter Parnes, Dick Schefslrbm and K~e Syimes, WebDesk: The tele-conferencing service of MATES, Position paper for ERClM Workshop on CSCW and the Web (February 1996).


[17] Dave Thompson, Common Client Interface Protocol Specifi-

cation (1995). spec.html

[ 18] Netscape Client APIs. std/index.html

[19] Java.

Ping-Jer Yeh is a Master student at the Institute of Computer and Information Science, National Chiao-Tung Univer- sity 5, Taiwan. He translated the comp.lang.c++ FAQ into Chinese, and is a regular contributor to local journals. His research interests include object-ori- ented technology, distributed systems, and programming languages.

Bih.Horng Chen is a Master student at the Institute of Computer and Informa- tion Science, National Chiao-Tung Uni- versity, Taiwan. Her research interests include distributed and educational hy- permedia systems. She is currently de- veloping an Internet problem-based learning environment based on the Alba- tross system.

Ming-Chih Lai is an information offi- cer in the Chinese army. He received his Master degree in Computer Science from National Chiao-Tung University, Tai- wan. His current interests include dis- tance learning, distributed information management, and educational hyperme- dia.

Shyan-Ming Yuan is a professor at the Institute and Department of Computer and Information Science, National Chiao-Tung University, Taiwan. He re- ceived the Ph.D. degree in Computer Science from the University of Mary- land, College Park in 1989. His current research interests include distributed system design, fault-tolerant computing, CSCW, multimedia environments and ICAL in distance cooperative learning environment. Dr. Yuan is a member of ACM and IEEE.


Fig. I. Roles and relationships (represented in Booch notation).
Fig. I. Roles and relationships (represented in Booch notation). p.3
Fig.  1 illustrates  the  roles  and  relationships  in  the  master/slave  model.  Among them,  servers  are repos-  itories  of course  contents,  logs,  and  other educational  facilities,  while  clients  are  user  agents  used  to  fetch,  read,  and
Fig. 1 illustrates the roles and relationships in the master/slave model. Among them, servers are repos- itories of course contents, logs, and other educational facilities, while clients are user agents used to fetch, read, and p.4
Fig. 3. Synchronous navigation between master and slaves.
Fig. 3. Synchronous navigation between master and slaves. p.5
Fig.  3  illustrates  these  synchronous  navigation  activities.  Here,  master  A,  slave  B,  and  slave  C  are  in  the  same  group
Fig. 3 illustrates these synchronous navigation activities. Here, master A, slave B, and slave C are in the same group p.6