Leveraging Existing Hypertext Functionality to
Create A Customized Environment for Team
Albert M. Selvin
Network Planning and Engineering Systems Laboratory
NYNEX Science & Technology
400 Westchester Ave.
White Plains, NY USA 10604
Effective comprehension of problem domains by teams requires both structured and
unstructured approaches. This paper describes a modeling technique that marries an
issue-based hypertext tool with a structured systems analysis approach. The
principal contribution of this technique is to combine the activities of structured
modeling with facilitated exploratory conversation about the issues raised by the
modeling effort, as well as other issues of importance to the project team. The
technique links the two kinds of discourse together in a free-form, multi-dimensional,
searchable database, without requiring programming skills or excessive administration.
The intended users of the technique are participants in efforts to model complex
problem domains (such as business process redesign or computer system
implementation). The approach provides rules and specifications for model-building,
specialized hyperlinking techniques, and other methods to allow construction and
maintenance of effective "model-bases".
Not all work in a model-building process is the work of actually populating a model
with model elements. Much of the group work that occurs in a model-building effort
consists of discussion, argument, brainstorming, and other more or less informal
communication about the models. This includes conversation about what to put in the
model, what issues are raised by the model, what work needs to be done in connection
with the model, how does the model relate to other aspects of the project, and so on.
Most modeling tools do not include support for these activities, and, more
significantly, do not provide any way of recording, displaying, or maintaining these
discussions as part of the overall modeling representation. Modeling and conversation
are seen as, and supported as, separate activities requiring separate (if any) tools. This
has important negative implications for development of group understanding of both
the models and the problem domain, the communicative ability of both the project
team as a whole and the team's individual members, the storing of rationale for key
decisions about model elements, model construction, project management, and design
elements, and other areas of a project.
The technique described in this paper represents an exploration of the benefits to be
derived from a combination of the rigour of structured system development
methodologies (such as Yourdon structured analysis  or CommonKADS knowledge
modeling approaches ) with the need for holistic analysis of problem domain (i.e.
analysis that addresses organizational, social, and other human issues along with more
technical aspects), explicitly addressing, and including, the freer-form, looser,
conversational work necessary for a team to understand the modes they are building.
This is enabled by harnessing and extending the hypertext functionality of a
commercially available issue-based hypertext tool.
The technique is designed to facilitate a back-and-forth movement between structured
and unstructured modeling and interpretive activities, and between formal and informal
modes of team communication. The goal is to integrate these modes so as to achieve a
high amount of synergy between structured and unstructured team activities. Informal
communicative activities are crucial to the success of a project in both the short and
long term. Project teams can benefit from explicit support of those activities,
particularly in the linking of the results of those activities to the models that the team
The technique was applied and refined in three projects over the course of a year,
involving, besides the developer, 44 participants in various roles for various durations.
Involvement ranged from half-day modeling/discussion sessions to full-scale modeling
efforts lasting several months.
THE SOFTWARE ENVIRONMENT
QuestMap(TM) is an issue-based hypertext tool. Developed as an outgrowth of
hypertext research at MCC in the 1980s, QuestMap provides a hypertext
infrastructure, a rhetorical method for mapping discourse, and an approach to
facilitating group discussions of complex issues [3, 4].
IBIS rhetorical structure
IBIS, or "Issue-Based Information System", is the rhetorical methodology that
underlies QuestMap. IBIS involves making distinctions between Issues (questions),
Positions (ideas about or possible answers to those questions), and Arguments (pros
and cons to the positions), and making the appropriate semantic links between the
icons, or "nodes", that represent these ideas. QuestMap allows the user to create
free-form IBIS maps and lists.
The complexity of QuestMap's hypertext engine is kept hidden from the user, while
providing a useful set of functions via an easy-to-use interface. In brief, the features of
most importance here are the following:
- the ability to create hyperlinks by copying a node from a map or list and
pasting it into another (there is, in fact, no"copy" made, but rather the same
node is now present in more than one "view")
- a "Containing Views" feature that allows the display of a scrolling list showing
all the views (maps or lists) that a particular node is "contained" in. The
scrolling list is also a set of hyperlinks; users can click on any of the views listed
and the system will take them to the node of interest in that view
- each node contains a "Contents Window" that allows users to enter additional
information about the node, including keywords that can be used in searches of
the database. Contents windows are made visible by double-clicking on the node
- a search engine that can display nodes containing certain keywords in scrolling
lists, that can then be sorted according to various criteria. The lists are
themselves sets of hyperlinks, as users can employ the "Containing Views"
feature to locate the nodes of interest in context
The technique described in this paper consists of overlays onto the basic IBIS
structure provided by QuestMap. The overlays support both a structured modeling
framework and the connecting of that framework to "normal" IBIS conversation
mapping. The technique has two interrelated components: specialized maps and lists
that are structured according to particular rules, and techniques for building and linking
elements of maps and lists, such as hyperlinking strategies, node coding, templates,
and labelling conventions.
Specialized map and list types
There are three types of specialized maps: models, which are structured
representations of aspects of a problem domain; lists, which collect coded model
elements in list form; and other map types such as project management overlays and
general discussion maps. Each map type has several elements and simple rules
governing their construction and use. Note that there are no software mechanisms to
enforce model-building rules or provide consistency/coherency tests.
The modeling technique makes use of IBIS conventions. The activity of model-
building, and the models themselves, follows a question-and-answer format. The
questions (generally speaking) are part of the defined templates for that model type,
while the expected answers conform to the rules established for that model type. The
questions and templates were derived from both structured modeling approaches and
from experimentation and discussion with groups engaged in modeling. For example,
questions about objects and their attributes were inspired by formal object-oriented
analysis, such as Jacobson's methods  while questions about organizations and
roles were originally based on elements of the CommonKADS Organization Model
. Questions about problems and opportunities were generated by both the
analyst/facilitator in response to issues raised by the participating groups, and by
members of the groups themselves.
Types of models
There are five types of structured model maps described here: Organization,
Communication, Task/Process, Resource, and Problem/Opportunity models.
Much of the power and usefulness of this technique lies in the ability to link model
elements themselves directly into unstructured discussions, so that the discussion and
the structured model are two clicks away from each other. Multiple layers of activity
and context are thus enabled and preserved. Participants can shift between "modeling"
and "discussing" a particular aspect or issue many times in the course of a working
session, without having to change tools and without losing the results of either
- Organization models describe the social structure at work in a problem
domain. They are intended to allow participants to gain understanding about the
roles that different groups and individuals play in the problem domain
- Communication models show the formal and informal communication between
roles. They may also be used to represent the communication between human
users and computer systems, or between systems and other systems
- Task/Process Models represent the sequences and attributes of tasks and
activities in the problem domain. They have several levels: a process or
workflow level map will show the sequence of tasks, while a task-level map
shows the attributes of a single task
- Resource Models represent the attributes of physical resources used or
consumed in the problem domain. There are many kinds of Resources: examples
include systems, tools, paper forms, electronic parts, and vehicles. People are a
special class of Resource; they are neither used nor consumed (at least, they are
not modelled as such!)
- Problem/Opportunity Models come closest to "conventional" IBIS maps. They
are places where the issues that have come up in the course of modeling other
aspects of the problem domain are discussed and analyzed by the project team
following typical IBIS uses. Issues that arise in the course of reviewing and
discussing Problem/Opportunity Models may also serve to inform subsequent
Specialized lists combine QuestMap's search engine with the coding and labelling
conventions described in this document. Lists can be used to produce documentation,
to serve as menus or catalogs, and to show the progress of aspects of the modeling
effort. The discussion below describes two types of specialized lists.
- Open Issues lists As participants work through models or issues, they frequently
encounter areas that require further research or work before the team can complete a
model or resolve an issue. By placing an open issue code in the Contents window of
the unresolved node or an adjoining node, an instant list of such open issues can be
created or updated, no matter where in the database such nodes occur. This approach
to issue tracking and management has the advantage that the context of issues is
preserved, and available at any instant via the Containing Views hyperlink feature
- Catalogues Up-to-date catalogues of different types of model elements can be
produced simply and easily. Uses of this type of list include, for example, catalogues
of all Roles, Tasks, Objects, or Communication models that participants have built to
date. Catalogues can be used to print documentation of a modeling effort's results, to
provide scrolling menus of model elements (these are especially useful during model-
building sessions, when linking in attributes of model elements -- for example, they
provide a simple way to locate all the Objects that might be involved in a particular
Task), and as gauges of progress -- a "Node Count" feature provides the number of
nodes in a particular list
Other map types
There are a wide variety of potentially useful specialized map types that could
support this approach. The flexibility of the software tool and approach means that
new types of useful views can be defined on the fly, with full interlinking capabilities
to existing maps and lists. One type of specialized map that has proven useful are
project management overlays. As with modeling activities, project management
represents an area of project work where free-form, exploratory discussions alternate
with and inform structured activities (and vice-versa). In the case of project
management, those activities include defining schedules, deliverables, project tracking,
status reporting, and so forth. Linking exploratory discussions about project
management issues with the results of those discussions (e.g., linking discussions
about the topic "what should our deliverables be?" with maps showing the agreed-on
deliverables), as well as with artifacts of actual project work (e.g., models), is helpful
in integrating the various strands of a project.
Effective hyperlinking allows the creation of cross-references, multiple views, and a
rich and robust model set. The more it is useful to understand an aspect of a problem
domain in multiple dimensions, the more it is useful to create hyperlinks. A node that
has a certain meaning in a specialized map or list can play different roles in other maps
or lists. Hyperlinking shows, reinforces, and manages this multidimensionality of
meanings. The other techniques discussed in this document are in support of, and
achieve their true leverage through, these hyperlinking strategies.
An example: In modeling a Role named Technician, the team has identified "Service
Order", one of the information objects that the Role comes into contact with, as one
of a Technician's attributes. Service Order is itself modelled on an Object Model map,
with its own attributes, including a Problem/Opportunity attribute titled "Not
implemented correctly". Service Order also appears as an object attribute on a Task
Model map for a Task named "Installation". The object also appears as an entry in a
Catalogue of Objects. Finally, the team has identified Service Order as one of several
objects for which there are "Implementation Problems" (in a Problem/Opportunity
The node named "Service Order" appears in all four maps as the result of Copy-Paste
actions (i.e., the team has copied the node and pasted it in the each map shown here.
When a user selects the "Containing Views" option while pointing one of the
appearances of the Service Order node, the software will tell them all the other places
that Service Order appears.
Hyperlinking in practice
The general procedure for hyperlinking is to create a link (i.e., paste an existing node
into one or more additional maps) whenever there is a relationship that the team
believes is or may become significant or meaningful to understanding the problem
domain, managing the project, or communicating effectively.
This kind of hyperlinking can, in itself, produce new understanding. By continually
asking the question "Where (else) should we link this element?" the team, in effect, is
asking "Where is this piece of information significant?" Thus, the team is continually
interpreting the significance of individual model elements, relationships between
elements, and relationship of the models to the goals of the project.
The extent and volume of hyperlinking that a team undertakes should be driven by the
project's goals and the time available for modeling, along with other factors. There are
always trade-offs between model extent and model usability.
Node coding involves placing codes in the Detail field of the Contents window of
particular nodes. The codes enable searches, cross-references and the on-the-fly
creation of specialized maps and lists without the manual work of assembling them
node-by-node. Because subsequent searches will find coded nodes wherever in the
database they may lie, teams effectively "seed" other model types and catalogues by
entering a code whenever they create a node of one of the specialized types.
To ensure that entries on maps, lists, catalogues, and hyperlinks support effective
browsing, searching, and perusal, a number of labelling conventions should be adhered
to. These conventions apply to some node and map labels and descriptions. For
example, maps containing models of individual Roles should be labelled with the name
of the Role followed by the word "(Role)" in parentheses. Thus subsequent
Containing Views selections and Catalogues will be easier to read and understand.
Templates are a way to facilitate the creation of model maps or other specialized
maps that follow a structured format. The formats consist of a set of questions that
are asked of model elements. These questions can be saved in templates and brought in
to new model maps. For instance, the process of modeling a Role can be jump-started
by importing the Role Model template.
Teams charged with designing effective business process or technology interventions
need access to all the rich detail about their problem domain without being
overwhelmed by its complexity. They gain their understanding of the "big picture"
through understanding the meaning of the elements of the domain, at many levels of
granularity. Such meaning is not inherent in the elements themselves; it must be
produced through collaborative analysis and conversation. Ideally, tools could support
each mode (modeling and conversation) with full hyperlinking capabilities as well as a
rich set of representational possibilities. Because it was based on off-the-shelf
hypertext technology, the technique described in this paper, of necessity, relied on a
limited representational palette and other restrictions in representational and
hyperlinking capabilities. Future efforts could expand on either side of the equation to
provide more powerful toolsets for team analysis.
 E. Yourdon, Modern Structured Analysis, Englewood Cliffs: Prentice
 B.. Wielinga, A. Schreiber, J. Breuker, KADS: A Modeling Approach to
Knowledge Engineering, KADS-II Consortium (ESPRIT Project P5248
KADS-II), Document Identifier KADS-II/T1.1/PP/UvA/008/1.0.
. E. J. Conklin, M. Begeman, gIBIS: A Tool for Exploratory Policy
Discussion, in Proceedings of CSCW '88, Portland, Oregon, September
1988, and ACM Transactions on Office Information Systems, October 1988.
. K. Yakemovich, E. J. Conklin, Report on a Development Project Use of an
Issue-Based Information System, in Proceedings of the 1990 Conference on
Computer-Supported Cooperative Work, ACM 1990.
. I. Jacobson, M. Ericsson, A. Jacobson, The Object Advantage : Business
Process Reengineering with Object Technology, Workingham: Addison-
 R. de Hoog, B. Benus, C. Metselaar, M. Vogler, Applying the Common
KADS Organization Model, KADS-II Consortium (ESPRIT Project P5248
KADS-II, Document Identifier KADS-II/T M6/DM6.1
This paper appears in the
Proceedings of the Second International Workshop on Incorporating Hypertext
Functionality into Software Systems, held in conjunction with the
ACM Hypertext '96
conference, Washington, U.S.A.