Proceedings of the 2nd Workshop on Adaptive Hypertext and
Hypermedia
HYPERTEXT'98, Pittsburgh, USA, June 20-24, 1998
Computer and Information Science Department
New Jersey Institute of Technology
University Heights, Newark, NJ 07102 USA
bieber@njit.edu, galnares@homer.njit.edu, ql5@njit.edu
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.
hypermedia design, automatic link generation, relationship management, Web development
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 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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
[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.