Proceedings of the 2nd Workshop
on Adaptive Hypertext and Hypermedia
HYPERTEXT'98, Pittsburgh, USA, June 20-24,
1998
Michael Bieber, Roberto Galnares and Qiang Lu
Computer and Information Science Department
New Jersey Institute of Technology
University Heights, Newark, NJ 07102 USA
bieber@njit.edu,
galnares@homer.njit.edu,
qianglu@homer.njit.edu
http://megahertz.njit.edu/~bieber
Abstract:
We take a two-stage approach to engineering applications for the World
Wide Web. First the software engineer performs a Relationship-Navigation
Analysis, analyzing an existing or new application specifically in
terms of its intra- and inter-relationships.
Second, a dynamic hypermedia engine (DHymE), automatically generates
links for each of these relationships and metaknowledge items at run-time,
as well as sophisticated navigation techniques not often found on the Web.
Because the number of links generated can be overwhelming, we need to
filter them based on user task and preference.
Keywords:
hypermedia design, automatic link generation, relationship management, Web
development
Background
We're currently working on an approach to Web Engineering, which We'll
describe in some more detail below. In short, We're taking a 2-step
approach towards moving computational applications to the Web: a
relationship-navigation analysis to determine where the links should be,
and a hypermedia engine that dynamically generates these links at run-time.
By computational applications, we really mean any application that
generates its content in real time, which includes most analytical
applications. Because their documents do not exist beforehand, all
hypertext must be generated dynamically after the documents are created.
Three more notes before turning to flexibility issues. First, we view
hypermedia primarily as supplemental support for applications.
Adding hypertext links, annotation and navigational tools enhances an
application with intuitive ways to access the information in which the user
is interested. Second, nothing about this approach is really Web-specific,
though "Web" is the buzzword that seems to have finally attracted people's
interest in my research. In fact, our first two prototypes were on the
Macintosh and the IBM PC. The current engine prototype is being written in
JAVA with a Web user interface module. Third, this approach works equally
well for adding hypertext to new applications as to existing applications.
Migrating an application to the World Wide Web provides an excellent
opportunity to reengineer it for supplemental hypermedia support.
Flexibility
FLEXIBILITY ISSUE 1:
My approach could easily generate an overwhelming number of links for an
anchor. How can the system produce a reasonable number of links, directed
at the user and his or her current task, and rank ordered by relevance?
FLEXIBILITY ISSUE 2:
One type of generic relationship (link) type the Relationship-Navigation
Analysis finds is a "schema" or "design document relationship." When a
user selects an item of information on the screen, the engine will
determine automatically where in the schema or other design documents that
item is. Then from the schema/design, the engine will determine what
interesting things are related to the selected item. How can the system
figure out which related things are interesting and of these, which
are relevant?
One approach is through machine learning; by monitoring the user, then
over time the system should be able to "learn" about the user's tasks and
preferences. Over time we will probably add such learning to the system.
But we see this more as fine tuning, assuming the user is not so
overwhelmed that he or she will stick with the system for the long
term.
So for now We're leaning towards asking the user what his or her current
task and preferences are. The mapping rules have a "condition" parameter
which can be used to block or activate that rule. The first step of the
Relationship-Navigation Analysis is to determine the possible stakeholders
for the application. The relationships and metainformation found during
the analysis can be marked for specific stakeholders and tasks, and thus
coded in the mapping rules directly. We also are building a user
preference module to serve all the engine's registered applications.
Again, preferences could be coded in the mapping rules directly. All this
is planned, but not designed or implemented yet. We hope to incorporate
these later this year. How should we go about this?
Question and Workshop Goal:
We hope that our team will design and implement task and preference
filtering this fall, as well as schema relationships. But we have not
thought about it carefully yet, nor caught up on the literature about this.
How should we do it? What should we take into account?
Relationship-Navigation Analysis
The Relationship-Navigation Analysis (RNA) technique has 5 steps:
(1) stakeholder analysis
(2) element analysis
(3) relationship and metaknowledge analysis
(4) navigation analysis
(5) relationship and metaknowledge implementation analysis
RNA has two major purposes. On its own, a relationship analysis will
help the developer form a deeper comprehension of the application. This
occurs primarily in steps 1-4. The developer then must decide which of
these relationships actually to implement. Some may provide only marginal
benefit. Others may be very costly or difficult to implement. These decisions
take place in the last step.
While quite useful in its current form, we intend to develop the RNA
technique further by producing specific guidelines for each step and by
reducing the range of options that the developer must consider within steps
2 and 3 of the analysis. These refinements should make the analysis more
systematic and easier to conduct, while allowing it to remain necessarily
open-ended.
Step 1: Stakeholder Analysis
The purpose of the stakeholder analysis is to identify the application's
audience. Knowing who will be interested in an application helps the developer
broadly determine the entire range of important elements and relationships,
and then to focus on these specifically. Especially those applications
with public Web access have a much broader range of stakeholders than many
imagine. Many developers, in fact, find this the most enlightening
part of the RNA. The developer also should identify and understand
the tasks each type of user will want to perform within the application.
These will help the developer focus on specific areas during the RNA steps
that follow.
Step 2: Element Analysis
Here the developer lists all the potential elements of interest in the
application. At one level these include all types of items displayed in
any on-line display (information screens, forms, documents, and any other
type of display), as well as the screens, forms and documents themselves.
The easiest way to start is to examine each screen (or mock-up) and identify
each value and label it contains. Note that developer should identify kinds
or classes of elements, not individual instances. The relationship types
we discuss in step 3 all are for specific kinds of elements. In the decision
analysis domain, for example, these include "model" and "data value" as
opposed to specific models or data values.
Step 3: Relationship Analysis
Relationship analysis concerns inter-relationships, intra- relationships
and metaknowledge. The developer should consider each element of interest
identified in the prior step in terms of each of the following general
kinds of relationships, for each group of stakeholders. Certain relationships
will be useful to only certain stakeholders, and the hypermedia engine
will filter these. Relationships can lead to information inside and outside
the application. Developers should not feel constrained by real-world considerations
of availability or implementation cost and effort. In this step they should
exercise their creativity as fully as possible. Only in step 5 should they
consider how to implement the relationships and metaknowledge found.
RNA currently helps developers identify the following types of relationships
and metaknowledge within an application: schema, process, operation, structural,
descriptive, parametric, statistical, collaborative and ordering relationships.
[Bi98] gives more details for each. Bieber and Vitali [BV97] shows
how several of these general relationship types can supplement an on-line
sales invoice. [Bi98] shows how they can supplement a mathematical modeling
decision support system.
Step 4: Navigation Analysis
Once we identify the relationships, we can think of how the user might
access them. The most straightforward implementation would make each relationship
a link, and then provide simple traversal (users selecting an anchor and
link, and the system displaying the link destination). But certain relationship
types lend themselves to more sophisticated navigation. The concept of
hypermedia includes many other navigation features based on relationships
or links. These include guided tours and trails, overviews and structural
query [BVA97]. In this step of RNA, the developer should decide which
navigation features might best serve stakeholders' needs.
Step 5: Relationship and Navigation Implementation Analysis
Clearly step 3 can generate a lot of relationships and step 4 can generate
a lot of possible navigational opportunities. In this step, the developer
must decide which actually to implement. This step is not the actual implementation,
simply the logical decision of which relationships to implement. Designers
should consider the costs and benefits (actual and marginal) of both implementing
and displaying each. We separate this step from steps 3 and 4 so the designer
can exercise all of his or her creative talents there without constraint
by real world considerations. The designer then writes a mapping
rule (using our specified format) for each of the relationships to be implemented.
Mapping rules specify the commands or algorithms for finding the endpoint
of each relationship.
DHymE (Dynamic Hypermedia Engine)
The DHymE hypermedia engine executes separately from the target application.
We write a wrapper program for each application to integrate it into our
engine architecture. Applications or their wrappers then connect
to DHymE through a Web proxy server. DHymE intercepts all messages
passing between the application and the user interface, and uses the mapping
rules specified above to map each appropriate element of the message to
a hypermedia node or anchor. Our Web browser wrapper
integrates these anchors into the document being displayed and passes it
through the proxy server to the user's Web browser. When the user
selects an anchor, the browser wrapper passes it to DHymE, which returns
a list of possible links (one for each appropriate relationship as determined
by the mapping rules). If the user selects a normal application command
(mapped to an operation link), DHymE passes the command on to the application
for processing. If the user selects a hypermedia engine link (e.g.,
to create an annotation), DHymE processes it entirely. If the user
selects a supplemental schema, process, operation, structural, descriptive,
information or occurrence relationship, DHymE infers the appropriate application
commands, meta-application operations (e.g., at the operating systems level
or schema level) or hypermedia engine operations that will produce the
desired information. If the user selects a user-created annotation,
DHymE retrieves it. Thus DHymE automatically provides all hypermedia
linking (as well as navigation) to applications, which remain hypermedia-unaware
and in fact often entirely unchanged. We currently are integrating
several applications with DHymE, automatically giving each a Web interface
or supplementing its existing Web interface: a personnel requisition tracking
system, a relational database management system, a mathematical model management
system, a transportation spreadsheet analysis system and a multi-criteria
decision support analysis tool. [Bi98] describes these ideas and
an older, non-Web prototype of DHymE in more detail.
Conclusion
We hope that our most enduring contribution is successfully convincing
developers of Web applications (both new and transported from other computer
environments) to take full advantage of linking in their applications.
Time and time again designers have told us that RNA has shown them links
they never imagined in their own applications. Identifying these is the
necessary first step towards implementation. Implemented thoughtfully,
the Web's linking and navigation facilities can go a long way to reducing
the complexity of applications for users. RNA gives developers a
tool for identifying opportunities for supplemental linking within
applications.
The DHymE hypermedia engine automatically generates these links, with little
or no change to the application.
Acknowledgments
We gratefully acknowledge funding for this research by the NASA JOVE faculty
fellowship program, by the New Jersey Center for Multimedia Research, by
the National Center for Transportation and Industrial Productivity at the
New Jersey Institute of Technology (NJIT), by the New Jersey Department
of Transportation, by the New Jersey Commission of Science and Technology,
as well as grants from the Sloane Foundation and the AT&T Foundation,
and the NJIT SBR program.
References
[Bi97] BIEBER,
M., Hypertext Engine: Support for Computational Applications, Technical
Note, 1997.
[Bi98] BIEBER, M., Supplementing Applications with Hypermedia, under
submission, 1998.
[BK95] BIEBER, M. AND KACMAR, C. Designing hypertext support for
computational
applications. Communications of the ACM 38(8), 1995, 99-107.
[BV97]
BIEBER, M. and VITALI, F. (1997). Toward support for hypermedia on the
World Wide Web. IEEE Computer 30(1), 1997, 62-70.
[BVA97] BIEBER,
M., VITALI, F., ASHMAN, H., BALASUBRAMANIAN V., and OINAS- KUKKONEN, H.
Fourth generation hypermedia: some missing links for the World Wide Web.
International Journal of Human Computer Studies 47, 1997, 31-65.
[CB97] CHIU, C. AND BIEBER, M., A generic dynamic-mapping wrapper for
open hypertext system support of analytical applications,
Hypertext'97 Proceedings, ACM Press, New York, NY, April 1997, 218-219.