Rob Kremer, kremer@cpsc.ucalgary.ca
This chapter evaluates HyperC in terms of its structure as a class library and also evaluates the application written using the library, Accord, as to its acceptability from the end user's perspective. It also describes the directions further work may take in terms of potential extensions, all of which are dependent on usage studies.
Accord and HyperC are not intended to be finished products, but vehicles for study of what users want in a CSCW package. In this, the work has met its goals in that it appears to be a flexible and modular implementation addressing a large set of the fundamental CSCW requirements. Both extension and module replacement should be easy. But only the actual further development will prove this true.
A major objective of this work was to create a general class library for group work. It is apparent that the HyperC library does not address all of the CSCW needs, but it does make a good start, at least in the domain of shared workspaces. To this end, HyperC provides reasonable hypermedia and concept mapping platforms on which "client" applications can build. A harsher criticism might be that the HyperC library is closely tied to the Accord application and may not be generally useful. It cannot be argued that Accord wasn't the prime motivator of the features that appear in the HyperC library; it was. But this is not necessarily a bad thing, if you subscribe to the contention that good class libraries are evolved, not designed [Basili 92]. Furthermore, the HyperC library is quite independent of the Accord application in that there is very little Accord code (the basic Accord code is only about 600 lines compared to well over 10,000 lines for the entire project) -- Accord is not much more than an exerciser for the class library. Accord merely provides a menu and an MDI (multiple document Interface) environment from which the user can select calls to the library. As an example of the flexibility of HyperC, consider that it would be quite trivial to write a new application that runs as a OLE server to embed HyperC hypermedia nodes in any OLE client application.
The class structure of the HyperC class library is described in chapter 4. Although it appears to be a reasonably good structure, it has been tested on only one application, Accord. Only further extension and use by different applications will prove HyperC to be a good class library. Nonetheless, Accord has been a reasonable test bed for HyperC since Accord has gone through many changes as a result of the feedback from many early end users in field tests. Application changes have been relatively easy, but a few have pointed out design flaws and forced changes to the library itself. I do not believe that the HyperC library is in its final form -- it will go though a long period of evolution as it is used by different applications before it reaches a stable, mature form.
Even within the Accord environment, HyperC is not an ideal structure, owing to compiler restrictions detailed in the next section. Among the points that will prove the design's viability is portability, discussed in section 5.1.3.
The HyperC class structure is quite naturally a multiple inheritance structure, particularly in the graphics library. However, the current implementation of the C++ compiler used does not properly handle multiple inheritance in the case of virtual base classes (often called diamond-shaped inheritance). Therefore, there is at least one case of linear inheritance where multiple inheritance is clearly called for. This is the case (see chapter 4) of GNode having to linearly inherit from RelationalGraphic and SensitiveGraphic in spite of the fact that these are orthogonal properties and objects could legitimately exist that possess one but not the other of these properties (see figure 24). The case could be handled by delegation [Hewitt 85, Johnson 91], but this would cost a significant space overhead penalty.
If Accord and HyperC are to be truly widely used in an organization, it is unlikely that its potential audience will be confined to PC users. Therefore, in order to be usable among the potential users, the system must be portable. The parts of the Accord and HyperC that do not deal directly with the user interface are quite platform independent. The exceptions are file name syntax and the persistent storage mechanism. The first of these, file name syntax, is easy to overcome, as it can easily be handled from a single, multi-platform source file using the standard conditional compilation options (#if, #ifdef ,etc.). The second exception, the persistent storage mechanism, will call for a significant rewrite before porting: since persistent objects are written to streams in binary format using PC native primitive types (integers, floating point numbers, etc.), they will not directly translate to expected semantics on other platforms. It is important for applications on all platforms to be able to share data as users on different platforms will expect to collaborate with one another. This problem will have to be overcome by inventing an independent "port" format or translating from the original PC primitive types on-the-fly. These changes affect only the read and write member functions in each class.
The Parts of Accord and HyperC that deal with interface, particularly dialog boxes, are far more problematic. Fortunately, the graphics library uses only common graphics and mouse and keyboard event primitives that would trivially translate to the equivalent on almost any other windowing system. The ten or so dialog boxes Accord and HyperC use probably have no simple and direct translation in other windowing systems. All dialog boxes are encapsulated within their own C++ classes, and these would have to be custom written for each port. Fortunately, the strict encapsulation means the program interfaces of the dialog box classes would not have to change, so the program would not have to change as a whole.
The reference classes, NodeRef and DB, are quite complex. Originally, they were formally specified (but not verified) in the Z specification language [Hayes 87], however, they have grown since then. These two classes are due to be re-worked. They could possibly be broken up into a larger collection of simpler classes. Furthermore, due to critical nature of these classes (they define the kernel of the hypermedia database), the original formal specification should be updated and verified.
This thesis did not formally study Accord's use -- that is a topic for future research. However, some informal field observations and interviews were conducted. All users observed were from a single large oil company, but from various departments. Most were technically-oriented people such as engineers and computer support personnel, but users also included managers and people from the marketing and personnel departments. While all users had some computer experience, the experience ranged from novice to expert. The situations observed include:
individuals working on a concept mapping task strictly for private use,
individuals using Accord to produce concept maps to be used as overhead projections to a group,
groups using a single projected-screen Accord workstation with an individual acting as "scribe", and
small groups working concurrently on individual workstations in a lab.
This last group may be surprising since Accord has not been extended to support groups working concurrently on the same concept map window. However, the groups were able to partially simulate shared concept maps by agreeing on a common node, linking (directly or indirectly) all their work to this node, and expanding this node to see the other users' work. This group, not surprisingly, expressed a need for more coordination. An example of this kind of concurrent work is given in figure 25, which was produced in a single ninety-minute session by a group of three people who had never previously used Accord. The group eventually picked one of the member's concept maps as the main concept map, and focused on that one. At the end of the session, one of the group members was assigned to "polish" the maps for later presentation to a higher level of management.
All the groups seemed be able to use Accord to a reasonable degree, except for the "scribe" situation: Verbal interaction in face-to-face meeting was too fast for the scribe to track in the Accord interface. A facility was needed to allow unorganized concepts to be jotted down for later consideration. As a preliminary step to addressing this problem, a "hotkey" command has been added that allows one to quickly type in concept names to a series of cascading glyphs without removing the hands from the keyboard. This has not yet been tested in the field.
None of the users interviewed expressed any difficulty understanding the use of concept maps, even though none of them had any previous experience with their use (although some had had experience with paper-and-pencil flow diagrams.) This supports much of the literature's contention that concept maps have prima facie validity. As one user put it, "I appreciate the structure and operation as being closer to the real thought process." Another user compared concept mapping with 'spider webs' (no doubt, the childhood educators' term for concept maps) that his child had been taught in school -- "It's easy if you grasp the 'spider web' concept."
Not only did the users find concept maps easy to use, some commented that they found others' use of concept maps valuable. One manager who participated in a three-way same time, same place Accord session commented, "I was able to achieve my objective and get the supposed owner of an idea to develop and identify his thoughts in a semi-formal way."
Some users expressed difficulty in multiple author situations with "using different words for the same thing" [Shaw 89]. Participants apparently did not have perfect agreement on terminology and definitions. One user suggested that an annotation facility would mitigate this problem, however, it is probably the case that users will not supply detailed explanations of concepts without prompting. A facilitator -- either a human or an AI agent -- may be helpful for merging similar concepts or prompting users for detailed explanations where appropriate. The same user also expressed concern that this problem was going to get worse as more and more "cross-functional workgroups" come into being, owning to the diversity of backgrounds of the participants.
One user noted that concept map training was required for people who hadn't used Accord because "such individuals seemed to panic when we showed them all the branches etc."
As mentioned in the preceding chapters, the interface for concept maps allows the user to manipulate both the interface (visual) objects and the objects in the hyperbase. It does this non-modally by using distinct commands (Show/New, Hide/Delete). However, novice Accord users seem to have difficulty understanding that Accord is not a drawing package, and that concept map objects are representative of (external) hyperbase objects. They are often surprised that changing the name of an object in one concept map will cause the name to change in another concept map on a different hypernode; or that a concept map node link expansion will show links and nodes created by someone else working in another part of the database.
Now that there exists a usable working implementation of Accord, user study of how it is (and is not) used should dictate the direction in which future development should proceed. Informal observation of users at work and user interviews have already suggested several of the directions listed in this section. This section has been artificially divided into "User Studies" and "Extension", but there is no clear distinction between the two categories. The "User Studies" section contains those topics that require more extensive user testing or more extensive user interviews to establish the normal conceptual view of the point. This is not to say the topics under "Extensions" should be implemented without question or post-implementation user study.
Windows programs usually support cut-and-paste operations that place data in and retrieve data from the system clipboard. However the semantics of cut-and-paste is unclear for Accord. The simplest question is "What data can Accord share with other programs?" Accord could paste from the clipboard data of most other programs as annotations, and it already does this for OLE server applications. Likewise, Accord could paste to the clipboard bitmaps (suitable for "paint" programs) or metafile (suitable for object-oriented "draw" programs) representations of selected data. But users may not only want to cut-and-paste between applications, but also between windows within the Accord application. Here, the choice of cut-and-paste semantics becomes much more than between bitmap and metafile. The user could intend any one of the following possible semantic interpretations of a simple cut-and-paste operation:
Superficial Copy: Copy the selected objects as a bitmap or metafile to an annotation in another node.
Shallow Copy: Copy the selected objects as a concept map to the target node; each node and link glyph in the copy refers to the original database object. This is the copy used by Intermedia [Haan 92].
Deep Copy: Copy the selected objects as a concept map to the target node; each node and link glyph carries a new object of the original type and contents with it, and this is placed in the home database of the target node.
One can easily conceive of more variants to the deep copy semantics. It will take considerable user study to establish which of these possible semantics are "normal" to the user, which situations to use them in, or how to let the user choose between them in an non-intrusive fashion.
The semantics of copying selected links from a concept map are somewhat unclear. Figure 26 describes the problem; selected nodes and links are shown as black filled. Case (a), where all the link, source, and destination nodes are all selected is valid and straightforward for both shallow and deep copies. Case (b) should be interpreted as copying the two selected nodes and the single link between them. Case (c) is less clear: does selecting all the nodes imply that the links between them should also be copied? Case (d) is quite clear for shallow copies since it is valid to display a link label without a destination as an indication that such a link type exists but is not fully displayed. But for deep copies, case (d) makes no sense because a link cannot exist without a destination. Case (e), a link label being selected without the source node being selected, is intuitively invalid for both shallow and deep copies.
Related to the problem of how to handle cut and paste operations
is drag and drop operations. When users become used to the direct
manipulation paradigm, they will likely also expect to use the
drag and drop operations between windows, so drag and drop should
probably be supported. The problems are very similar to cut and
paste. For the most part, a user's drag and drop should be taken
as a shallow cut and paste operation. However, the case of dragging
and dropping foreign nodes onto a database view can only be interpreted
as a deep cut and paste since all contained nodes are already
in the database view and it cannot contain glyphs that represent
nodes not in the database.
Accord provides the basic hypermedia operations in the concept maps, such as create, edit, annotate, and delete. Accord also provides database manipulation operations including create, copy, import, export, register and delete. But what other operations are useful to the user? Possible candidates are:
Node copy: Create a new node exactly like the current one.
Node move: Move a node to another database.
Node merge: Merge the objects from two or more nodes into a single node, eliminating duplicates, etc.
Database merge: Merge two databases into a single database, fixing up indexing, etc.
Template copy: Copy a concept map to a new one, replacing all the references with references to new, blank nodes.
Unlock node: Remove a write lock from a visible node, but keep the node visible and read-locked.
Lock upgrade: Upgrade a node lock from read-only to write-locked.
There are many more possibilities. Most of them are actually composites of other, more primitive operations. The problem is which subset is sufficient for convenient use without swamping the user with too many choices? Only studies of how users actually work in this type of environment can answer this question.
This thesis proposes that databases should be presented as special purpose concept maps, but this principle is not contained in the current implementation. The database concept map would look and act like any ordinary concept map except that it would be restricted to always contain glyphs for all hyper nodes in the topic database, and could not display any glyphs for nodes not in the database.
The principle is simple enough, but how can it be made clear to the user, particularly the novice user? What features (such as background color) should distinguish a database concept map from an unrestricted concept map? Should users be allowed to manipulate the spatial layout of a database view or should the layout be exclusively machine generated; and if the later, what algorithm or heuristic should be used for layout? Should annotations be allowed or restricted in a database concept map? Should intra-database links be displayed, not displayed, or filtered, depending on user preference? Should the display of inter-database links be disallowed or displayed as arcs to special "other database" objects? Should each database contain one master database concept map, or should each database contain one-or-more database concept maps to allow for display using different organizational views (spatial layouts)? Should database concept maps be the exclusive interface to the nodes in the database, doing away with list boxes of node names?
All these questions and others (including whether database concept maps are a good idea in the first place) can only be answered by empirical user studies.
The concept maps described in this thesis present a large amount of information to the user:
node names -- by labels in node glyphs
node types -- by shape, fill color, border color and text color of node glyphs
relationships among nodes -- by links
relationship types -- by link labels and colors
group relationships, hierarchical relationships, and other relationships -- by spatial layout.
However, there is more information that the user may wish to see, such as "which database and computer do these nodes reside on?" Furthermore, some of the information is displayed through less obvious means (such as color and shape). One cannot expect novice users to know information like "blue elliptical nodes are issues." The user could have need to display the concept map with additional "auxiliary" information or with the existing symbolic information made explicit. How is this need to be supported?
An obvious method is to allow the display of captions above or below concept map nodes, and to allow the user to select the information displayed in these captions. Another method is to use additional visual attributes of nodes in conjunction with a legend. Yet another method is to add superficial concept map nodes representing the information category values and superficial links from these nodes to nodes possessing those category values. All these methods have their problems, for instance, the first method can add considerable clutter to the display, and the latter two can only reasonably display quite coarse-grained discrete information.
This thesis suggests hierarchical type systems for node content types, link types, annotation types, and node syntactic types. While there is little doubt that hierarchical type systems are simple, straightforward, and useful to computer scientists, it is not necessarily valid to assume this is the case for all the potential users of Accord. Hierarchical type systems are undoubtedly useful for computerized agents acting on the hyperbase, but it is not entirely clear that they add enough value for the typical user to justify the overhead of learning and maintenance. Static (pre-defined) hierarchical type systems are probably not a problem for the average user, but dynamic (user-editable) hierarchical type systems demand much more user expertise when the user is extending or editing the type hierarchy, if the hierarchy is to maintain reasonable integrity.
If users are to be able to create "information nodes" -- nodes that do not necessarily contain any concept map, but only annotations, these will almost certainly be expected to act as not only ad hoc information chunks, but also to play the role of a record in a database application. That is, information nodes will have to take on type (called "node syntactic type" in the previous section) and act as templates for an information repository. Spatial layout will be critical in this application, and users must be able to define spatial layout. This is not difficult under the windows paradigm since moving and resizing are generally entrenched in the windows operating systems and are very familiar to the user.
However, the user may expect to put constraints on the objects in the node window, such as minimum and maximum sizes for particular objects, having particular objects stretch to match the outermost border of a window, or maintaining an aspect ratio of a particular object. An example of this might be a "personnel record" where a photograph remains a fixed size while the margins of the surrounding text fields stretch to match the outer borders of the windows.
Several approaches exist for modeling these spatial constraints including "glue" [Linton 89]. What is needed is a visual method of specifying these constraints that is sufficiently intuitive such that all of the diverse of users of Accord can use it without difficulty or long learning times.
The annotations in the current implementation are system-supported child windows and derive their functionality from the standard system windows functions. However, this leads to considerable limitations, including very limited control over visual attributes during hardcopy printing, and difficulty in implementing variations on the normal system functions. This annotation style will be replaced in the very near future by an implementation taking advantage of the same graphics class library as used by concept maps.
The graphics class library already directly supports short textual annotations, although some distinctive visual attributes will have to be considered to differentiate annotations from concept map nodes. Users will probably expect support for longer textual annotations using scroll bars or some similar device. While this is easy to support on the monitor, is unclear how an annotation with a scroll bar should be printed to hardcopy. Non-textual OLE annotations will be easily supported using the same code used for the child-windows annotation implementation. The graphics class library will have to be extended slightly to enable user-initiated sizing of objects (the current default behaviour is that objects size themselves according to content or by program control).
Besides the independent annotations discussed above, there is an obvious need for annotations that relate directly to some particular node or link label in a concept map (or perhaps even annotations that relate to other annotations). These should have special properties such as being visually related to their owner, existing only as long as their owner does, possibly having their visibility controlled from a control within their owner, and automatically moving relative to their owner movement. The initial proposal is that owned annotations should be visually related to their owner by appearing as balloons -- as used in comic strips to indicate speech. This method takes advantage of a widely familiar technique, and it has been used with some success on the Mac operating system as "balloon help". Owned annotations should probably be "shown" and "hidden" by selection from the owner's popup menu, but there may also be need for hypernode-global "show-all-annotations" and "hide-all-annotations" commands. Owned annotations should probably be "dragable" in the same manner as concept map nodes, and should therefore be moved with the owner only when multiply selected with the owner. However, hidden owned annotations should always move relative to their owners.
Currently, HyperC locks nodes on the basis of a single writer and multiple readers, which yields a less intensive interaction style than the ideal. One could envision a lattice-shaped object version space where multiple writers would lead to concurrent versions of the same object which could be reconciled at some future time. However, the author views object versioning with a great deal of skepticism due to the storage cost. Furthermore, allowing multiple versions does not really contribute significantly to a more intense interaction style, since the multiple writers would not have much awareness of each others' presence or activity.
The ideal multiple writers support would resemble Greenberg's GroupDraw [Greenberg 92c], where each of the writers could see each others' cursors moving on their window, and all actions of all writers would be visible in "real time" on all windows. This interaction style is more intense and certainly yields more awareness of other writers' presence and activity. The use of multiple cursors also supports yet another important channel of communication -- gesturing on the work surface [Tang 91].
As ideal as the GroupDraw interface appears, GroupDraw a is real-time conferencing system while Accord is basically a shared workspace system, so GroupDraw's interface mechanisms may not all be directly applicable to Accord. Accord users should easily "stumble" onto nodes opened by other users and be able to automatically share with very minimal cost to the users in gaining permissions or acknowledgment. Individual Accord users may not want to share their write-locked nodes, or if they are willing to share, may not want to be unnecessarily aware of other users' presence (cursors). Accord may have to allow users to state preferences such as private write-locking nodes, or not displaying others' cursors.
Currently, Accord does not give users much awareness of other users in the workspace (aside from refusing a write lock on a node). Accord should have some easy-to-use mechanism where users can at least get a listing of other users (both writers and readers) who are sharing the workspace [Dourish 92]. An ideal system would supply
a non-intrusive method of making users aware that there are other users in the workspace,
a simple method of allowing a user to get a listing of all other users sharing the workspace, and
support for easily opening up secondary communication channels
with the sharing users, such as private message sending, private
shared windows, or audio or video links.
The current implementation of Accord has no dedicated space on the interface for displaying status information to the user, such as node sharing status, lock status, and settings such as zoom level, and other user preferences. Many windows programs supply a status bar at the bottom of the screen to provide such information. Accord users could probably benefit from a status bar at the bottom of the MDI frame who's visibility could be chosen as a user preference.
A status bar would likely be a good place to display non-critical messages, such as the number of changes that occurred during a verification of a concept map. Messages could either timeout or be explicitly dismissed by the user to revert the status bar back to displaying status information. At present, Accord's only way to display messages is to display them in a separate dialog box that incurs a user cost since the dialog box can obscure the work area and the user must explicitly dismiss it. There are currently many places in the software where a decision has been taken not to display potentially useful information due to the user cost of a dialog box.
Status bar messages could be added to Accord's error message system without affecting any of the other code since all user messages are currently routed through the error message system with accompanying severity information. The severity information could be used by the error message system to determine whether to route the message to the status bar or to a dialog box.
Sharing the workspace is the main focus of Accord, but other communications channels are necessary. Useful interaction will probably only occur when users are together in the same room, when users have a telephone link, or when there is some other supplemental communication channel available. Accord should endeavor to support these additional channels to the extent that it can without prohibitively costly equipment. At minimum, Accord should allow users to send private messages among themselves, perhaps in the form of little popup message windows. "Chat" windows linking the keyboards of two users may also be useful. Using slightly more advanced hardware, voice channels might by set up by Accord, either by dialing into the telephone system or by using microphones and speakers built into the computer itself. Already, video equipment is available on the market that would allow Accord to provide video windows at fairly reasonable cost.
Many Accord users have suggested that they tend to associate size with importance and expressed frustration at the fact that Accord sizes concept map nodes to fit the contained text. In general, more experienced Accord users seem to overcome this reservation and minimize the importance of node concept map node size. However, it remains an open question whether or not being able to control concept map node size really will contribute to the usefulness of the concept maps. It may be that node size is on the level of importance of user controllable layout (which is quite critical [Nosek 90], [Lambiotte 89]).
The interface for user node resizability should not be difficult since the precedent exists from a large number of drawing programs. The one problem with resizability is that nodes intrinsically contain text, and it is unclear what should happen to the text when the node is resized. Should the font size grow and shrink to fit within the surround? Should the font size stay "normal" for "expanded" nodes and shrink for "reduced" nodes? Should the font size always stay "normal" with the text scrolling in "reduced" nodes?
CSCW applications often conjure up the notion of voting tools, group questionnaires, and decision matrices. None of these tools are supported by the current version of Accord. Most of these should not be directly supported by Accord, but should be added as applications written on top of Accord. However, Accord is going to have to provide considerable support for these applications with such things as objects specifically designed to support user voting. Exactly what support is necessary will not be clear until the higher order applications are designed. Exactly what higher order applications are required will not known until after some user studies have determined the users' normal working profiles and needs.
The spreadsheet paradigm has become enormously successful, and many of Accord's potential users are quite familiar with spreadsheets. Could Accord use this familiarity with spreadsheets to advantage? One can envision annotation boxes in Accord nodes that can perform calculations based on the values of other annotation boxes both in the current node and in other nodes. The annotation boxes would be labeled with identifiers so that any particular box could be named using the normal persistent node name and the box identifier. Other than the problem of specifying ranges, such an annotation box could perform exactly like a spreadsheet cell.
It is not at all clear that the spreadsheet paradigm would contribute significantly to Accord; however, it is something to keep in mind. It would appear that such a facility would be useful in many decision-making models.
Accord users can freely invent new node content types and link types, specifying fill colors, border colors, and text colors. Users can also specify suggested link types from a particular node type at the tail of the link. However, there is no way to specify constraints on the node at the head of a link. There is also no way to enforce these constraints. Enforcing constraints on node and link typing is a reasonable requirement -- having nodes and link types obey some semantic constraints makes sense both from a user understandability point of view, and from the point of view of intelligent agents navigating the hyperspace.
The implementation of enforcing such constraints is not straightforward from an HCI perspective. For example, given a consistently typed concept map, if the user changes the type of a node, all of the incoming and outgoing links must be rechecked for consistency and any number of them may require updating (presumably in consultation with the user). The changes to any of these link types may introduce inconsistencies with nodes on the other side of the link, which may, in turn, require updating, etc. All this could easily confuse the user. The option of not allowing the user to change a node or link type to an inconsistent type is not practical because this allows the user to get into a situation where no change is possible. There are many possible solutions to this problem, but only user study will determine which is the most practical for this type of interaction, or if enforcing such constraints is desirable at all.
The current implementation assumes a perfectly open organization
where no one is refused access to anything, and ownership of objects
is never tracked at all. Clearly, this is not the case in most
organizations. Future implementations will have to record node
creators and ownership, record and enforce permissions, and possibly
record all node authors and annotators. Since Accord is a group
software, its security system must recognize the existence of
groups and allow creators, authors, and permission subjects to
be groups and not necessarily individuals.
This thesis has described a C++ class library and application to support interactive use of concept maps in a business environment. As a navigational tool between concept maps, the library also supports a hypermedia environment. The Accord application was used to motivate the features in the class library. Part of the goal of the work was to provide a general purpose CSCW class library, and, while the HyperC library appears to have met this goal, this will not be proven until other applications have been written using the library.
The Accord application was informally tested in several business environments in a large oil company. Users generally found the application to be quite easy to use, and could begin using it after a very brief introduction. All of the users seemed to have an intuitive understanding of concept maps despite the fact that few had ever used them before -- confirming the prima facie validity of concept maps. Users generally had more difficulty with the hypermedia aspects of the application: Novice users tended to view Accord as a drawing tool, and often had difficulty grasping the fact that concept map nodes are also "publicly" visible in shared hyperspace.
The application and class library were designed after surveying related work under the disciplines of CSCW, hypermedia, and concept mapping. Development and detailed design proceeded using iterative prototyping techniques with frequent feedback from the target user community. This could not have been done without the key enabler of developing the application concurrently with the class library. As a result of all this, the current work should form a good foundation for a truly useful suite of collaborative applications using concept mapping techniques.
The work so far has only begun to address the many issues involved,
as is obvious from the sections on extensions and future research.