Web Engineering

Michael Bieber

New Jersey Center for Multimedia Research,
National Institute of Transportation and Industrial Productivity, and
Computer and Information Science Department
New Jersey Institute of Technology
University Heights, Newark, NJ 07102 USA
bieber@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.  This leads him or her to better understand the application's complexity and richness, as well as better provide the kind of access and metaknowledge users desire.   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 (e.g., guided tours, overviews, structural query) on top of these links.  The links and navigation, as well as annotation features, supplement the application's primary functionality.

Motivation

As the World Wide Web and its programming tools mature, we increasingly find analytical applications with Web interfaces and other Web sites with content generated instead of hand-created. This includes the large class of legacy systems which organizations are rushing to convert to Web interfaces [Be95]. This paper concerns application design for all such systems. It also addresses the danger that developers will endow these systems with a paucity of links instead of embellishing them with the rich layer of linking and navigational opportunities which the Web could support [BV97].

Furthermore, developers of these analytical applications often struggle with the need to present complicated information in a way users can best understand it.  Often the developers will rely on insightful visualization techniques and good user interface design. These approaches are not trivial, and for some applications cannot convey information simply enough for all users, especially students, novices and those unfamiliar with the low-level details of the application domain (such as a non- technical manager who must make decisions based on a developer's work). Even for applications with straightforward information displays, users may still have questions about what a particular item means or how it was determined.  Logically each element within a Web application might be considered a potential starting point for information exploration. The ability to explore a piece of information in more detail could help users resolve doubts about or simply better understand both that item, as well as the analysis or display of which it is a part. Users may wish to dig deeper around data values and symbols they see, labels on graphs or user input forms, options in pop-up lists, information users enter as input (before actually submitting it), or even on the menu commands and other controls they can invoke.

To complicate the developer's job, users often have different mental models of an application (and its underlying domain) than the developer (application analyst or software engineer). Even when developers work closely with users, the end result might not be equally intuitive for all users or serve each user's individual tasks equally well. A user may wish to access a particular display, function or piece of information which he or she believes is immediately relevant to the task at hand, but which the system does not make accessible from the current screen or immediate vicinity.

Providing links that represent application relationships that give the user access to what he or she wants is one of the main purposes of hypermedia.  We take a two-stage approach to engineering applications for the World Wide Web.  First the developer performs a Relationship-Navigation Analysis, analyzing an existing or new application specifically in terms of its intra- and inter-relationships.  This leads him or her to better understand the application's complexity and richness, as well as better provide the kind of access and metaknowledge users desire.   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 (e.g., guided tours, overviews, structural query) on top of these links.  The links and navigation, as well as annotation features, supplement the application's primary functionality [BK95, Bi98].
 

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, Ni95]. 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.  [Bi97, CB97] also provide some background on the engine.

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

[Be95] BENNETT, K. Legacy systems: coping with success. IEEE Software, January 1995, 19-23.

[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.

[Ni95] NIELSEN, J. Multimedia and hypertext: the Internet and beyond. AP Professional, 1995.


last modified: 4/6/98