Context-Based Web Application Design

Seung C. Lee Department of Finance and MIS

School of Management and Economics University of Minnesota, Duluth

10 University Drive Duluth, MN 55812

E-mail: slee@d.umn.edu Phone: (218) 726-7556 Fax: (218) 726-7516

Jinsoo Park Information and Decision Sciences Department

Carlson School of Management University of Minnesota 321-19th Avenue South

Minneapolis, MN 55455 E-mail: park@umn.edu Phone: (612) 624-1301 Fax: (612) 626-1316

Working Paper Last revised on October 2001

1

Context-Based Web Application Design

Web applications are becoming increasingly complex, just as they are required to

perform more and more sophisticated functions. They often are integrated with existing

applications and frequently utilize various functional logic and software components.

This has led to a call for a more inclusive and comprehensive method for developing

Web-based applications. In response, we propose a context-based approach to the

development. It is founded on an adaptation of the Data Flow Diagrams (DFD) and the

following notions: (1) regardless of its implementation, a Web application is a system

rendering content to the user in the forms of browsable pages; (2) a set of visible and

invisible pages constitutes the context of a subject; (3) the invisible pages are often

associated with certain functional logic and software components; (4) a subject and its

context pages that are interlinked by context links from a compendium; and (5) a Web

application consists of many compendia.

1. Introduction

It is meaningful to distinguish between a Web application and a Web site (Conallen,

2000). From the user’s point of view, however, a Web application is essentially a Web

site because users care only about the content that they actually can browse, not the

underlying implementation that delivers the content. In this sense, a Web application is a

system rendering content in the form of pages that are carefully intertwined via

hyperlinks, which enable users to navigate and exchange information through the

mechanism of the client and server. From the developer’s point of view, however, a Web-

based application development effort should consider both the content users actually can

2

browse and the mechanism in which the content is delivered. In order words, developers

should consider what and how the latest content will be delivered to users. “What” means

Web pages and their contents of a target application. “How” indicates the delivery

mechanism and structure of the application that also deals with ever-changing

information to provide up-to-date contents to the user.

As implied by the above statements, the fundamental medium of content delivery

is a Web page that could be generated by either statically or dynamically. The static

delivery involves a simple request/response mechanism between client and server or the

static service of a Web server. The dynamic delivery is based on a more sophisticated

request/execution/response procedure that involves the dynamic service of a Web server.

It executes logic associated with a requested page and returns the result of the execution

in response to such an event as form submission. The logic may take the form of a

programming function, a software component, or an existing business application.

Designing a Web-based application, therefore, should take account of (1) gathering and

composing content, (2) dealing with changing content, (3) associating the building blocks

with each other for effective navigation and presentation, and (4) incorporating static and

dynamic content delivery aspects into the design.

In this paper we propose a context-based Web application design method that

addresses the fundamental requirements. It deals with them by embracing various

technologies including markup languages, client-side and server-side scripting, software

components, and existing core business applications. Specifically, it considers a way of

gathering content requirements and presents a set of techniques for an effective design,

which will result in an enhanced modifiability, structure, and presentation. As Fingar

3

(2000) points out, the ability to change is now more important than the ability to create

sites, especially, if they are e-commerce ones. Change becomes a primary design goal

and it requires robust architecture whose building blocks can be added, modified,

replaced, and reconfigured. To support designers in achieving the objective, the method

introduces a set of new concepts and classification schemes.

There are three fundamental issues in designing Web-based applications:

information-, navigation or structure-, and presentation-related issues. Addressing the

issues, in fact, wraps them around achieving higher global and local coherence and

reducing cognitive overhead (Conklin, 1987; van Dijk and Kintsch, 1983; Thuring et al.,

1991 and 1995). Tackling the problems associated with coherence and cognitive

overhead is particularly acute as the Web-based applications are becoming complex in

terms of its structure and presentation (Fraternali, 1999). It calls for more effective

techniques to alleviate the complexity to achieve higher global and local coherence and,

hence, to reduce cognitive overhead. In this context, this paper makes three key

contributions. First, it introduces a formal high-level breakdown scheme of a Web

application based on the concepts of access scopes and compendia. A high-level

breakdown of an application using the former gives a global view, while its refinement

into lower-level details using the latter provides a local view of the application. The

global and local views together secure higher coherence and lower cognitive overhead.

Second, upon the notion that a Web application’s basic unit is a page, we further

granulate the Web page into visible and invisible one. A visible page is a browsable page

by the user, while an invisible page is not directly browsable such as a style sheet page.

The invisible page is working behind the scenes to render the visible page. Classifying

4

Web pages into the visible and the invisible, thus, enables us to distinguish “what” from

“how,” which plays an important role in content requirements analysis and continuous

refinements of compendia. Third, the method is partially inspired by the well-known Data

Flow Diagramming (DFD) technique in which individual compendia and context pages

correspond to the DFD processes, and links to the DFD data flows. In fact, designing a

Web application is providing users with the content organized as a set of semantically-

related pages and enabling them to navigate those pages following the global and local

cues represented as a contextual flow of links.

The rest of the paper is organized as follows. We review three major issues in

Web application development in the next section followed by detailed explanations of the

concepts that will be utilized in the course the method development. The subsequent

sections explain the proposed methodology step by step. The paper concludes with a

number of implications and suggestions for future research.

2. Related Work

Aforementioned, there are several important issues in designing Web applications.

Investigating the issues give us some useful insights into the designing Web applications

in terms of design principles and primitives. This section will also review previous work

on Web application design in the context of these issues.

First of all, there are information-related issues—that is, how to gather user

information requirements in developing a Web application; how to compose the gathered

information; and how to deal with changing content. It is well recognized that user

information needs should be thoroughly analyzed prior to developing an effective

5

application. Information requirements analysis typically involves an analyst working with

end users to identify information needs early in the design process to produce more

effective systems (Byrd et al. 1992). Unlike the conventional applications, however,

public Web applications do not have clearly defined end users. This makes it difficult for

the developer to determine user information requirements because the conventional

information gathering techniques (e.g., interviews) may not be suitable. They also focus

on the identification of functions that will produce the information that users need (Byrd

et al. 1992). A Web application, however, consists of both derived and base pages that

are interconnected by hyperlinks. This makes it more difficult to apply the techniques and

requires the designer to be more knowledgeable about a Web application domain to

provide the user with sustainable content.

The sustainable content means several things: (1) it should include essential facts,

definitions, procedures, and processes that meet the application’s objectives, (2) it should

be up-to-date and well structured, and (3) it should evolve over time to reflect advances

in technology and changes in business logic. Satisfying these requirements probably

brings up a more effective and successful Web application. To address the above

requirements under the constraint of ill-defined users, it seems natural that most of the

previous work on Web application design have been centered on content structuring and

its presentation to the user with a minimal attention to information requirements

gathering (e.g., Isakowitz et al, 1995). Although a recent method proposed by Conallen

(2000) has an attempt to identify user requirements based on the well-known use case

approach (Jacobson et al. 1992), it basically assumes that users or actors are well defined

in terms of what system functions they need—that is, what functional cases they use. As

6

defined by Jacobson et al (1992), a use case requires an actor to supply input and the

system to exhibit an observable output. Use case analysis is basically for an application

domain for which the users are well defined so that all the necessary use cases can be

identified by applying conventional requirements analysis techniques. Web applications

other than intranet and extranet have no clearly defined users. In fact, a Web application

should deal with procedural and process content as well as factual and definitional one.

For the last two types of content, the major input is simply the name of an anchor page.

This implies that Conallen’s (2000) method could be more useful for intranet and

extranet applications that deal with well-structured business processes.

As well known, Web applications enable users to navigate the hyperspace non-

linearly. The mechanism behind the non-linear access is a navigation structure of a Web

application—that is, in general, a tree-like network of pages connected by links that

provides a navigational environment. Navigation-related issues, hence, deal with the

following questions: Where am I?, Where do I go?, and How do I get there? (Rivlin et al.

1994). Stated other way, the issues are reduced to: how to present effective navigational

cues to the user; how to offer content in a semantically related manner; and how to create

effective and efficient connections among pages for easy navigation and hence better

comprehension. In cognitive science, comprehension is often characterized as the

construction of a mental model that represents the objects and their semantic relations

(van Dijk and Kintsch, 1983). The amount of mental effort for the construction of a

mental model, thus, determines the comprehensibility of the user (Thuring et al., 1995).

There are two crucial factors that influence this process: coherence as positive

influence (Thuring et al., 1991) and cognitive overhead (Conklin, 1987) as negative

7

influence on comprehension. A document is coherent if a user can construct a mental

model that corresponds to facts and relations in a possible world (Johnson-Laird, 1989).

In constructing a mental model, two types of coherence are especially important: local

coherence from which users infer “local” connections that link pieces of information

together, and global coherence from which users infer “global” connections that are

conclusions drawn from a set of local connections (van Dijk and Kintsch, 1983). On the

other hand, cognitive overhead is "the additional effort and concentration necessary

maintain several tasks or trails at one time" (Conklin, 1987, p. 40). This might be caused

by the limited capacity of human information processing as pointed by Miller (1956). In

light of Web applications, such efforts primarily concern user disorientation, navigation,

and user-interface adjustments. (Marchionini and Schneiderman, 1988; Thuring et al.

1995).

In the context of coherence and cognitive overhead, the navigation-related issues

can be summarized as (Thuring et al., 1995): (1) higher local coherence, that is,

appropriate indication of semantic relationships between information units and reduction

of the impression of fragmentation; (2) higher global coherence, that is, aggregation of

information units and providing adequate overview of the Web application; (3) lower

user disorientation, that is, indication of the user’s current position, backtracking to the

user’s current position, and presentation of the options for reaching new nodes; and (4)

facilitation of navigation, that is, support for navigation with respect to direction and

distance. Direction means forward and backward navigation and distance is the depth of

traversal either by stepping adjacent links or jumping to non-adjacent links.

8

In addition to the matters in Web application design, another concern is related to

providing users with effective interfaces that reflect the previous issues. Most of the

design literatures on Web applications have focused on the underlying data model,

including the Dexter Model (Halasz and Schwartz, 1994), RMM (Isakowitz et al. 1995),

and Conallen (2000). Although the data model is an important concern, user interface is

equally important matter that must be articulated and addressed. It is concerned with the

visual presentation of content to users. Sometimes, the user interface has been the last

issue to be considered. It is, however, at the presentation layer that the information in the

underlying data model actually finds its way from abstract machine space into the user’s

perception (Kahn, 1995). In designing user interface, the following should be considered

(Hardman and Sharrat, 1990; Kahn, 1995; Rossi et al. 1995): (1) global structure and

controls such as spatial division and visualization of content; (2) local structure and

controls such as text column and media stage, marking links, link tips, media stage and

media browser, story header, and story footer; (3) the interface appearance of each

navigational object seen by the user. This means that the same navigational object may

have different representations in different situations; (4) other interface objects that

activate navigation such as go-to buttons; and (5) user’s perception of the user interface.

3. Methodological Background and Preliminaries

This section describes foundational concepts that will be used for developing the

proposed method. First part of this section explains page types that are a fundamental unit

of Web applications, which is followed by detailed mechanisms by which the pages are

organized and identified. Finally, the third part explains link semantics from which we

derive six link types used to connect various building blocks.

9

3.1 Page types

Unlike the approaches adopted by previous Web application design methods (e.g.,

Isakowitz et al. 1995; Conallen, 2000), ours is fundamentally different in that it classifies

Web pages into visible and invisible pages based on the belief that, from the user’s

perspective, the essential elements of a Web application are individual pages. A visible

page means a browsable page by the user, while an invisible page is a non-browsable

page but works behind the scenes to render a visible page. This classification plays an

important role in the content requirements and structure design phases. As we will see

shortly, the former considers only visible pages—that is, the content requirements

analysis is performed solely based on what users actually can browse.

If a page becomes visible only by either the interpretation of a user agent or an

invocation of different client software (i.e., other than user agent such as a presentation

software), the page is called a base page. If a page becomes visible by being generated on

the fly via a server-side execution of logic embedded in a page, a component, an existing

business application, or a combination, the page is called a derived page. Thus, a visible

page can be either a base page or a derived page, both of which in turn are classified into

either an interactive or a non-interactive page depending on whether the page contains an

interactive element such as a form. In other words, a visible page, either base or derived,

may be comprised of any combination of its plain description, one or more links to other

pages, and one or more interactive elements. The plain description could be very simple

such as a message, a prompt, a confirmation, and/or a heading that works like a status cue

in a conventional application. For example, a table of content or a simple heading might

10

be the case. This means, of course, that the content of a visible page includes not only its

plain description but also links and other elements.

Like visible pages, invisible ones are divided into three categories: server page,

client-side control page, and server-side control page. A server page is a page that

contains a server-side script that is processed by its interpreter before the Web server

returns its processing result to the client. A server page may contain logic in the form of a

statement, a function, or a subroutine. A component or an existing business application

may be involved in the course of execution of a server page. A client-side control page

such as an external cascading style sheet has several characteristics. First of all, it is

hidden from the user of a Web application (i.e., not directly browsable). Second, it

controls cosmetic aspect of a page the client displays. Third, it is invocated by the client

and, hence, by no intervention other than the “response” of the server. Fourth, it may not

require explicit user intervention such as clicking a link. Once a user requests a page that

is associated in some way with a client-side control page, the target page automatically

sends another request for the client-side control page to get a designated effect. A server-

side control page such as an “include” file has also several characteristics that are similar

to those of a client-side control page. First, it is also hidden from the user. Second, it

controls the way the server performs a certain function and renders a desired output to the

user. Third, it is invocated by the server, and, hence, by no intervention of the client other

than the “request” of the client. Fourth, it does not require explicit user intervention such

as clicking a link. Just like on the client side, once a user requests a page that is

associated with a server-side control page, it automatically includes the server-side

11

control page for a designated control. Unlike visible pages, however, invisible pages are

not divided into base or derived pages. Such page classifications are shown in Figure 1.

Web Page

Visible Page

Invisible Page

Base Page

Derived Page

Server Page

Client-Side Control Page

Server-Side Control Page

Interactive Page

Non-Interactive Page

Interactive Page

Non-Interactive Page

Figure 1. Page classification

3.2 Component types

Web applications are becoming increasingly complex as companies try to cash in on the

Web technologies to create an infrastructure for a whole new way of doing business.

They are extending their business processes beyond company boundaries through

integration with their business partners’ and customers’ business processes. The major

issues in the course of such extension are achieving coherence and managing complexity

and change inherent in Web applications (Fingar, 2000).

Classifying Web pages could be a way to address the issues. Another way may be

using software components that are widely available through third-party vendors or core

business processes embedded in existing business applications. A component means a

software component including executable files, applets, Java class files, static libraries,

and DLLs. They are usually embedded in pages by certain handles. Core business

processes residing in existing business applications can also be considered components

that can be integrated into a Web application through some published interfaces.

Regardless of the form of a component, it plays an important role in delivering visible

12

pages, supporting invisible pages, and/or performing necessary functions. In this paper,

components are broken down into three categories: client-side component, server-side

component, and application component. The client-side component could be divided into

two types: host-dependent components such as a client-side script function, and client

system components such as an autonomous media player. In a strict sense, an internal

client-side script function—such as calculating lease payment, providing a calendar, or

validating a form—may not be a component. Although it is not a separate entity from the

“hosting” page, we consider it a component for a design purpose because any internal

script can be converted into an equivalent external one. A client-side component can be

triggered either implicitly (e.g., by a file extension) or explicitly (e.g., embedding a

specific media player using a tag). In a similar sense, the server-side components are any

components that provide a functional support to a server page (e.g., file uploading or

database access component). The application components are core business processes of

existing business applications wrapped as components to expose interfaces to a Web

application. For the sake of simplicity, we might treat a whole existing business

application as a component.

3.3 Compendium and context

The structure of the Internet resembles “hub-and-spoke” of a wheel. A hub may be a

peering point where the incoming traffic from a source is switched to the outgoing traffic

for its destination. There are many peering points (hubs) on the Internet, and they are

connected each other. Each peering point has a set of connections (spokes). At the end of

each connection are sources and/or destinations of the Internet traffic. The nature (e.g.,

speed) of a peering point is determined by the characteristics of its connections, sources,

13

and destinations. We apply this structural metaphor to the proposed Web application

design method. In other words, we can think of individual elements of the Internet

structure as corresponding elements of a Web application. A source corresponds to a link

page, a destination to an anchor page, a spoke to a link, and a hub to a subject or theme

described by its context pages and links. A Web application, therefore, can be considered

a collection of related subjects (i.e., procedural, process, factual, and definitional themes).

Just as the nature of a peering point is determined by its comprising elements, a subject in

a Web application is determined by one or more context pages and links and vice versa.

To represent this point in more general manner, we introduce two concepts: compendium

and context.

According to Cambridge Dictionaries Online (http://dictionary.cambridge.org),

the term compendium is defined as “a short but complete account of a particular subject,”

while Oxford English Dictionary Online (http://dictionary.oed.com) defines the term

context as “the parts which immediately precede or follow any particular passage or text

and determine its meaning.” For example, the meaning of “fly” depends on its context.

According to the definitions, a compendium has a subject, and the subject is accounted

for by its context. In the case of our method, the context is given by semantically related

pages and links. Thus, a collection of semantically related pages that accounts for a given

subject can be called the context pages, and a set of links that associate the subject with

its context pages can be called the context links. Stated other way, a subject is accounted

for by its context pages and context links. Up to this point, a subject is an abstract. We

need to make it concrete. To do that, we can consider a page called a subject page, which

is an operationalization of an abstract subject. The subject page for a subject could

14

contain a simple description or an overview of the subject. Therefore, a particular

compendium consists of its own subject and the subject’s context and is operationalized

by a subject page, its context pages, and its context links. This implies that the name of a

compendium may be the same as that of its subject. For example, a “placing order”

compendium could be operationalized in terms of a subject page “placing order,” context

pages for “getting customer information” and “selecting deliver option,” and context

links for connecting the context pages to the subject page. A compendium may have a

nested form in which other related compendia are included. Now, it can be said that a

Web application or a Web site can be thought of an assembly of compendia, each of

which has its subject (often the subject name is the same as the compendium name), a

subject page, and its context pages, and its context links. A compendium can act as part

of context of other compendia. The concept of compendium is different from that of the

use case, which is the basis of Conallen’s (2000) design method. His method focuses on

functional aspects of a Web application, while our method is centered on the

informational aspect of a Web application. Figure 2 summarizes the concepts explained

above.

WebApplication

Compendium

Compendium

Compendium

Subject

Subject

Subject

Context Page/Link

Context Page/Link

Context Page/Link

Figure 2. A structural view of Web Application

3.4 Link Semantics

A link is an associative connection defined between information elements. Links are

established between information elements within a page as well as across pages and

15

compendia. Links distinguish the Web from other means of organizing information. On

the other hand, an anchor identifies the precise endpoint of a link. The endpoint can be a

page or a bookmark within a page. A page that contains a link is called the link page, and

a page for which a link is destined is called the anchor page. A link can have multiple

endpoints especially when a link is conditional. For example, a link can point to a

different page depending on a conditional situation (e.g., rotating ad banners). In the

user’s point of view, however, a link with any number of endpoints appears to be one.

A link may have a meaning depending on what the link refers to. For example, if

a link refers to a base page, it simply requests the Web server to retrieve and send the

requested page back to the client. This is different from a link that triggers a certain

component or that executes logic contained in a page. This implies that, based on the

semantics of a link, we may classify the link into many types as the World Wide Web

Consortium (http://www.w3.org/DesignIssues/LinkTypes.html) does, which defines 15

link types. Additional link types are possible if we further elaborate the semantics (e.g.,

Isakowitz et al, 1995; Conallen, 2000). Various links types can be useful in representing

detailed semantics of the link and hence the precise context. They might, however,

introduce complexity to the design of Web applications because the designer should

identify semantics of every occurrence of a link in depth and also keep track of the entire

link types employed. In any case, link types would be more meaningful if they are used to

show global and local structures, and to enhance global and local coherence of a Web

application, and hence to reduce cognitive overhead of the user. The proposed method

collapses possible link types into six context link types: anchor (<a>), coordinate (<c>),

form (<f>), redirect (<r>), trigger (<t>), and build (<b>).

16

Each link type is of course used to provide a connection, for example, between

context pages within the same compendium, between pages across compendia, between a

page and a compendium, between compendia, and between a page and a component. We

can think of semantic link types binding together compendium, pages, and other

elements. The semantic link types enable us in a systematic manner to represent a

navigation structure and presentation mode (e.g., sequential or non-sequential) during the

design of a Web application. Some link types like ‘anchor’ may be called an explicit link

type in the sense that its anchor page is directly rendered to the client with or without

firing other links, while some others such as ‘redirect’ can be considered an implicit link

type that is often hidden or non-descriptive to the user and usually fires other links

contained in the anchor page. In this sense an explicit link that does not fire another link

might be called hotspot. The returned page by an implicit link may or may not contain an

explicit link.

The anchor link type is created by an anchor tag and used to represent a

connection between elements of a Web application. It may simply cause a server to

retrieve a page or fire other link types. A bookmark within the same page is a different

form of the anchor link type, while a bookmark to a different page can be considered

simply an anchor link type. An anchor link might sometimes be associated with a query

string and a cookie. Both a link that sends a query string to the server and a link to a page

that plants a cookie may be thought of a variant of the anchor link type. The coordinate

link type connects a page to a client-side control page or a server-side control page to

make the two pages work effectively as a whole for a well-controlled rendering. In other

words, two or more pages act together to bring in content in a smooth concerted way. The

17

trigger link type is necessary to accommodate components. As Web-supportable

functions expand, more and more components are intertwined with pages through links.

Clicking on such a link passes data to and triggers a component to be executed (e.g.,

playing an audio clip). The trigger link type is used to represent such kind of link

semantics, which is implemented as either a hyperlink or an instantiation. The build link

type fits into a situation where a requested page generates another page on the fly in

response to an event. In today’s dynamic and interactive Web environment, many Web

pages are generated in runtime to take into account certain conditions. A good example is

creating a billing statement based on an order or a personalized page based on personal

preferences. Sometimes, a build link may pass data stored in a “global” variable of a

server-side script. Unlike the build link type, the redirect link type brings up another page

without intervention of the user. Finally, the form link type is created by a form tag and

represents cases where a link page contains a form with a submit button that is associated

with an anchor page.

4. Overview of the Methodology

In this section, we present an overview of the proposed Web application design

methodology. It is made up of several phases each of which has a few steps. It consists of

following phases: content requirement analysis, compendium refinement, structure

design, implementation, and testing and evaluation. The requirement analysis phase

consists of three sub-phases: higher-level content requirement analysis, higher-level

compendium definition, and lower-level compendium definition. The high-level content

requirement analysis phase is further divided into two different tasks: information

decomposition and access scope definition. The compendium refinement phase details

18

each compendium defined in the lower-level compendium definition sub-phase. The

structure design phase also consists of three sub-phases: solidification of compendia,

corroboration of the solidification, and the development of link data dictionary. The

structure design phase provides detailed navigation path design in terms of compendia,

context pages, context links, and components. Finally, although implementation, testing,

and evaluation are undeniably important in developing applications, they are beyond the

scope of this paper. Figure 3 provides an overview of the methodology.

Figure 3. Overview of the methodology

5. Content Requirements Analysis

As discussed earlier, the users of the public Web applications are largely undefined. In

the case of private Web applications, users are already known so that it might be helpful

for the designer to gather content requirements using some conventional requirements

analysis techniques. This is not the case for the public Web applications such as an e-

commerce application. We suggest a feasible technique in this section.

The Internet was originally intended to grow on open standards and open source.

This has inevitably resulted in the relatively lower barriers to imitation (Makadok, 1998).

19

Although the rules are changing as more and more Internet-related patents and legal

battles are looming (O’Reilly, 2000), getting (not copying) ideas from existing Web

applications would be an acceptable behavior. There are numerous Web applications or

sites are available to visit, and they are becoming part of daily lives of more and more

people. This implies two things: (1) a vast number of real applications could inspire

designers to “get” ideas about content requirements; and (2) a large number non-trivial

Web sites that have evolved and been massively tested by a vast number of users may

provide clues for “sustainable” content requirements.

Upon recognizing the implications, the designer may examine some exemplar

Web sites that are similar to the target application to be designed and get some ideas what

should be the essential content for the application without violating any laws. This sort of

technique may be called the “inspired assimilation.” This probable technique would have

some advantages over merely depending on the designer’s knowledge about the target

application. First of all, there would be a lower possibility of omitting some essential

contents because the referenced Web sites have most likely been evolved on the user’s

continuous feedback. Second, the users of the exemplar sites would already be familiar

with the content so that they would be more comfortable with and expect to have the

elements they have already gone through. Although the number of Internet users keeps

growing, the existing users will become part of the target audiences for the proposed

application. Third, it would be much easier to add content being specific to the proposed

application to what has already been identified through the inspired assimilation.

The inspired assimilation-based content gathering technique may be augmented

by another technique called the model-based approach (Taylor, 1995). The goal of the

20

model-based application development approach is to construct application models that

show the structure, processes, and resources of a business as simply and directly as

possible. Based on the approach, the designer may be able to identify required content by

applying the conventional information gathering techniques (e.g., Byrd et al. 1992) to

those who are directly involved in the business processes and practices. Although they

might not the direct users of the proposed application, the designer could at least have

some insights into what are required contents for the application. The model-based

approach may only be supplemental to a more sophisticated content requirement

gathering technique because, unlike information rendering in print, the counterpart on the

Web is partly dependent on user preferences.

5.1 Higher-level content requirements analysis

We have suggested a technique for gathering skeletal content requirements. Once user

content requirements are gathered through the use of any technique or the designer’s

knowledge about the target application domain, the next thing to do is arranging the

requirements in line with the notion of global and local structures mentioned above.

This sub-phase explains how to classify the requirements into a set of higher-level

abstractions. For this purpose, we will focus on the identification of subjects and their

arrangements in a hierarchy disregarding context pages and context links for a while.

Traditionally, a large complex body of information or knowledge has been organized into

one of or a mix of linear, network, and hierarchical forms. As pointed by Simon (1962),

complexity frequently takes the form of hierarchy. He convinced that hierarchical

structure is a major facilitating factor enabling us to understand, to describe, and even to

see complex object and their parts. Managing complexity, therefore, inevitably entails

21

certain kinds of classification schemes in both global and local levels for a given body of

information or knowledge. According to Cook (1996), classification begins with

rounding up all the information elements that are related to one another and separate them

out using higher-level abstractions. Following the process, we round up the similar

information elements, create high-level abstractions, and gradually refine them into

lower-level details. This sub-phase is comprised of several steps.

5.1.1 Informational decomposition

First of all, it is possible for a single Web application to have many application domains.

For example, an e-commerce application may have a customer support application

domain, a supply chain management application domain, and a storefront. For illustration

purpose, however, we only consider a single application domain. Once an application

domain is identified, we perform the three activities at this step: (1) identification of

domain-level subjects, (2) decomposition of the domain-level subjects into level-0

subjects, and (3) further refinements of the level-0 subjects. First of all, we identify

domain-level subjects of a target Web application—that is, major higher-level subjects of

the domain. When we decompose a target Web application into domain-level subjects,

we may think of two groups of subjects: descriptive (factual/definitional) and prescriptive

(process/procedural) subjects. The former corresponds to hyperdocument (Engelbart,

1995), which requires the user to click appropriate links to find out related information

about the subject and its context pages. By contrast, the latter requires the user to follow

given steps for more refined results—and often requires some input as well. For example,

some subjects such as “search”, “user authentication”, or “ordering process” requires

explicit user inputs rather than simple clicks. For the second part of this step, we

22

decompose all the domain-level subjects into their composing lower-level subjects using

a colon separator (i.e., Domain:Products, and so on) and arrange them into hierarchies.

Note that some domain-level or its lower-level subjects may be dependent on another

subject or an event, and may appear repeatedly. For example, an “order” subject should

be identified under a “product” subject or “service” subject, and a “search” subject may

appear repeatedly along with many subjects. Figure 4(a) shows partial breakdowns of a

hypothetical e-commerce application domain (i.e. storefront).

Figure 4(a). Partial breakdowns of a hypothetical application domain.

Figure 4(a) breaks an e-commerce application domain into several information

chunks in terms of their subjects. Figure 4(a)(i) lists domain-level subjects, and 4(a)(ii)

and 4(a)(iii) show a refinement of the two domain-level subjects: “products” and the

“search.” Figure 4(a) does not show context pages and links for the subjects. Some

subjects are factual, while others are procedural in that a procedural subject requires user

input. Regardless of subject types, we focus on content or presentation to be delivered to

23

the user. For example, the “search” subject in Figure 4(a)(iii) actually represents the

interface for a search, which might be implemented with two options—Web search and

site search. A search itself would involve an execution of certain logic in the

implementation phase.

Figure 4(b). Refinements of Figure 4(a)

Figure 4(b) shows the refinements of the Domain:Products:Books and

Domain:Products:Search into lower, comprising subjects. We continue to refine

identified subjects for a given application domain until further refinements are

impractical—that is, a subject at its lowest refinement should be detailed by its context

pages and context links. The final shapes of hierarchies would vary depending on the two

factors. The overall depth and breadth of the tree (in fact, a tree-like network once we

take account of links) depend on the level of complexity and the size of the proposed

Web application domain, both of which could be measured by the depth and breadth of

24

the domain-level and its subsequent-level subjects. For example, the number of clicks

required getting to a particular subject or page could affect the depth of a hierarchy. In

addition, as Fingar (2000) points out, the degree of changeability of content and structure

also determines the breadth and depth. In fact, they have a trade-off relationship: a deeper

(shallower) structure would require a narrower (wider) breadth and vice versa. To

enhance the degree of changeability, we should achieve loosely coupled subjects both at

the top level and the subsequent levels. We suggest that a developer may start with fine-

grained hierarchies and then modify depending on the implementation strategy and the

size of the application in terms of the breadth and depth of subjects. Note that hierarchies

don’t have to be balanced.

5.1.2 Defining access scope

Aforementioned, a particular compendium consists of its own subject and the subject’s

context and is operationalized by a subject page, its context pages, and its context links to

the context pages and other compendia. A subject name actually represents a

compendium name and may become a heading for a group of subjects or a link text—that

is, each subject of the hierarchies is operationalized as a compendium together with its

context pages and context links. This requires defining the access scope. An access scope

is defined in terms of subjects, not of context pages and links. It defines the range of

access for a given Web application. Wider access scope might entail crowed links on a

single page but a shallow depth and, hence, requires smaller number of clicks to a

specific destination. It is possible for a Web application to have at least three access

scopes: main scope, common scope, and aggregate scope.

25

The main scope is necessary to accommodate so-called homepage. It works as a

gateway to other subjects. It may include the subjects in all levels of the hierarchy if an

application is relatively small or some of the levels in the hierarchy if it deals with a large

number of subjects. The common scope defines a common set of subjects that would

appear as hyperlinks on every page including homepage. It works like a fixed menu bar.

For a small application, the subjects included in the main scope might be the same as

those in the common scope. The aggregate scope also defines a collection of subjects. It

may not be practical to represent a subject as a very deep structure (i.e., deeply stratified

subject). For example, the aggregate scope of “products” would span only the subjects of

Figure 4(a)(ii) or up to the subjects of Figure 4(b)(iv) if the application had to have only a

few titles for a given subject (e.g., 5 best-seller tiles for gravity, relativity, etc.). This

implies that a big subject may have many lower-level aggregate scopes in addition to a

top-level aggregate scope. The number of aggregate scopes also depends on the main

scope, common scope, and implementation strategy.

Figure 5 shows a main, a common, and an aggregate scope and their relationships

based on Figure 4. Figure 5(a) and 5(d) show partially expanded scopes. For example,

subjects other than products in this main scope should be expanded, if needed, to their

lower-level subjects. In fact, the number of levels in each scope has been arbitrarily

determined for explanation purpose. The exact number of levels should be dependent

upon the implementation strategy (e.g., depth and breadth). We should define one or

more aggregate scopes (not shown) for “physics” and other subjects in Figure 5(d). For

instance, we might define one more aggregate scope of “physics” that includes up to

“gravity” subject in Figure 4(b). The subjects in the main scope will be shown as

26

hyperlinks on the homepage, while the subjects in the common scope will be shown on

every page regardless of subject and context. Note that a dependent subject “order” has

not been shown in any scope. This will be taken into account later in the structure design

phase.

Mainscope

What's new

Special offers

Products

Search

Authentication

Terms of use

Privacy policyComplementaryservices

Books

Movies

Music

Computers

Games

Software

Health

Garden

Houseware

Commonscope

What's new

Special offers

Products

SearchComplementaryservices

Aggregatescope ofproducts

Books

Movies

Music

Computers

Games

Software

Health

Garden

Houseware

Aggregatescope ofbooks

Science

History

Children

Nonfiction

Fiction

Physics

Chemistry

Mathematics

Biology

Engineering

(a) (b)

(c) (d) Figure 5. A main, common, and aggregate scopes (partial)

5.2 Higher-level compendium definition

Defining high-level compendia involves mappings of the access scopes identified above

into high-level compendia that will consist of only subject pages of the subjects in the

access scopes (access scope subject pages). A high-level compendium is denoted as a

rectangle, and its comprising subjects denoted as ellipses. We use the lines to simply

27

show relationships between an access scope subject page and comprising subjects

because link types for them are not yet defined. The lines will be replaced with

appropriate link types later on. Figure 6 shows high-level compendia for the main and

“physics” aggregate scopes (“physics” aggregate scope is not previously shown). Note

that, in some cases, mapping an access scope such as the common scope into a high-level

compendium is not likely to have an access scope subject page. In that case, we just use

the name of the scope as an anchoring point.

Mainscopesubjectpage

Products

What'snew

Specialoffers

Search

Terms ofuse

Authentication Privacypolicy

Complementaryservices

Books

Movies

Music

Garden

Games

Software

Health

Houseware

computersPhysics

aggregatescopesubjectpage

Gravity

Relativity

Time Light

Energy

Book 1

Book 2

Book 3

Book 5

Book 4

(a) (b) Figure 6. High-level compendia for the main and physics aggregate scopes

5.3 Lower-level compendium definition

Defining lower-level compendia form the higher-level ones requires two separate tasks:

articulation of the non-leaf subjects (e.g., “Products” subject in Figure 6(a)) and that of

the leaf subjects (e.g., “Book 1,” “Book 2,” etc. in Figure 6(b)) contained in higher-level

compendia. The former is a simple task—that is, add a subject page to each of the non-

leaf subjects in Figure 6(a). For each of the leaf subjects, identify its subject page and

context pages. We may not need separate diagrams for the refinement of the non-leaf

subjects, but we should represent a leaf subject as a compendium diagram (see Figure 7).

Note that a subject is different from a subject page. The former is an abstract theme of a

28

compendium, while the latter acts as an anchoring point to its lower-level compendia or

context pages. A subject page provides an overview for a given subject. We will again

denote a rectangle as a page. We should not, at this moment, be worried about page and

link types defined earlier. We just focus on only whether or not a context page is visible.

Figure 7. A compendium for the 'Book 1'

As we can see in Figure 7, there are seven important points. First, a compendium

for a given leaf subject should include only visible context pages that are semantically

related to a given leaf subject. The reason is that we should separate “what” from “how”

of an application design. We might think of “rating book” and “writing review” as

context pages of “Book 1.” It depends on complexity of rating and writing processes. If

they involve many steps, then it would be better to separate them as a subject. We, at this

step, do not concern invisible pages and components that would be used to generate

visible pages. Second, the subject page in a compendium should be distinguished from

other context pages by appropriately naming such as “Book 1 subject page.” Third,

although it is quite possible for all the context pages to be contained in a single subject

page, especially base context pages—which will be explained later, we should separately

identify as all the context pages as possible. This is because identification of all the

context pages separately gives a couple of advantages: (1) the designer does not have to

29

worry about which pages should be combined into the subject page; and (2) an

enumeration of all the individual context pages gives much higher flexibility when the

designer later sorts them out to be included in a subject page or remained as separate

context pages. Using a single page to describe a subject, however, is really an

implementation issue. Fourth, it is recommended to show the path that identifies the

hierarchical location of a subject at the top of a compendium, which is shown in Figure 7.

Fifth, once we define a compendium for a leaf subject, it can be reused for similar

subjects (e.g., the compendium for “Book 1” can be reused for other books). Sixth,

certain context pages such as an image might have similar alternatives (e.g., same image

with different sizes and angles). To handle this kind of case, we may use overlapped

rectangles. Finally, when we define compendia, we do not concern the order of context

pages. For example, the “Author video interview” page in Figure 7 may be browsable by

a user only after the user visits the “Author profile” page. The page orders should be

taken into account in the next phase.

6. Compendium Refinements

Now it is time to introduce context pages and context link types to refine the compendia

that have been identified for a target Web application domain. To incorporate page and

link types into the compendia, we will use the following symbols (Figure 8). As we can

see, however, a subset of available page and link types is used to refine them. The rest of

the page and link types will later be brought into consideration in the structure design

phase.

30

Base non-interactive

Baseinteractive

Derived non-interactive

Derivedinteractive

<a>

<f>

Anchor

Form

Figure 8. Symbols for the compendium refinement

Note that the link types in Figure 8 can be used to show unidirectional,

bidirectional, and conditional links. It is a design issue whether we should show a

bidirectional link between two pages or letting the user press the backward button on a

browser to go back from an anchor page to a link page. Whether a link is conditional is

determined by the context of a given compendium. In addition, we may have a situation

where two or more pages must be sequentially accessed. This means not all context pages

are directly linked to the subject page of a compendium. We will use a unidirectional

arrow only if an omission does not make sense. Figure 9(a) shows the result of a

refinement of Figure 7, and Figure 9(b) shows a refinement of the “Writing review”

compendium (not shown previously).

Figure 9. Refinements of compendia

31

Figure 9(a) shows a subject overview page for the “Book 1” and three other pages

that are linked via the anchor link type (i.e., denoted as <a>). The “Excerpt” and the

“Author profile” pages should be derived non-interactive pages if those pages should be

generated by executing certain logic—that is, for instance, rendering those pages by

retrieving data from a data store. We need some detailed explanation about Figure 9(b).

First of all, it has used the form link type to connect context pages (i.e., denoted as <f>).

It allows a user to submit a certain input that would be processed by another page. In

general, the form link type implies that there is an intermediate page like a server page

between the link and the anchor pages (e.g., login information submitted from “Login”

context page must be verified before rendering “Writing a review” page, although it is

quite possible to implement verification and rendering in the same page). The verification

page is an example of the invisible server page described earlier. Incorporating an

invisible page will be explained in detail in a later section along with other context link

types. Second, “Writing review subject page” has two anchor pages: “Quick register” and

“Login.” Either one would be selected first depending on whether a user has already

registered. This is an example of the conditional link because a user who has already

registered can bypass the “Quick register” context page. In addition, we can see a

bidirectional link between the “Writing review subject” page and the “Login” page. It is

bidirectional because if a login attempt fails, the user must go back to the subject page.

Notice that it is also a conditional link. Third, there is no direct link between the “Writing

review subject” page and the “Writing a review” page because a user must go through

either the “Login” page or “Quick register” page to get to the “Writing a review” page.

This is an example of a sequential access mode. In fact, there are two possible access

32

modes that are operationalized as two corresponding presentation modes, including

sequential and non-sequential. Fourth, the path information in Figure 9(b) is “domain”

because we assume “Writing review” subject has been identified at the domain level. It

might be put under each book subject, but is not recommended because of two reasons:

(1) it is a dependent as well as a repeating subject. We should repeat it under every

“book” subject when we define an aggregate scope. This may cause a cluttering; and (2)

it does not directly provide a context for a book subject. Fifth, each context page is

represented using one of the four page type symbols (i.e., base non-interactive, base

interactive, derived non-interactive, and derived interactive). In addition, the subject page

is also shown as a symbol. This means that all subject pages, regardless of a subject

characteristic (i.e., non-leaf or leaf), should be represented as appropriate page symbols.

7. Structure Design

This phase deals with three tasks: (1) solidification of each compendium by adding

“foreign” compendia and context pages, if any, for individual compendium navigational

structure; (2) corroboration of the solidification by considering context page rendering

processes, which incorporate invisible pages, components, and context link types

including trigger, coordinate, build, and redirect; (3) development of link data dictionary

(LDD) that identifies data passed along with any link type. Overall result of the structure

design will show association between compendia, between a page and a compendium,

between pages in different compendia along with data being passed among them. We will

still focus on visible pages and two link types (i.e., anchor and form) for the first task. For

the second and third task, however, we will consider all other page and link types. We

will again denote a compendium as an ellipse.

33

7.1 Solidification of compendia

In refining compendia, we focus on context pages that directly describe a given subject.

A given compendium, however, is related to other compendia and pages that would

indirectly describe its subject. The “foreign” compendia and pages may be dependent,

repeating, or independent ones. For example, Figure 9(a) requires, at the minimum, one

additional page that allows the user to place an order. To identify them, it might be useful

to consider compendia or pages in terms of two groups: descriptive and prescriptive. The

former would include factual or definitional content, while the latter would have content

related to a procedure or process. We may, then, perform two analyses to identify foreign

context for a given subject via the descriptive and prescriptive content analyses. As an

example of the descriptive analysis, we can consider books with a topic similar to that of

the book for which a user has placed an order. The prescriptive content analysis may be

done through an analysis of an established business process/transaction in a way it is

related to other business processes/transactions (e.g., Teng et al, 1994). For example, a

user who has reserved a seat on a plane is likely to reserve a rental car. In this situation a

compendium for the rental car reservation becomes a foreign context for a compendium

of the airline reservation. Figure 10 is an example of a solidification based on Figure 9.

34

Book 1subjectpage

Excerpt

Author videointerview

AuthorProfile

App:products:books:science:physics:gravity

<a>

<a>

<a>

Writingreviewsubjectpage

Guidelines

Writinga review

Previousreviews

Login

Quickregister

(a) (b)

<a><a>

<a><f>

<f>

<f>

Confirmreview

<a>

App

Order<a>

Rating

BookmWriting

review

<a>

Book n <a>

<a><a>

Privacynotice

<a>

MainCommon

<a><a>

Figure 10. A solidification of Figure 9

The shaded ellipses in Figure 10 represent foreign compendia, and the shaded

page in Figure 10(b) represents a foreign page. It could be either the entire compendium

for a privacy policy or a context page of the compendium that is specific to the activity of

writing a book review. In this example, the compendium “Book m” in Figure 10(a)

denotes compendia for books written for a topic similar to that of “Book 1,” while “Book

n” in Figure 10(b) represents any book if every book listed on the page provides an

opportunity of writing a review. Figure 10(a) also contains the main and the common

compendia defined above. They perhaps appear on every page including the subject page.

Pages in Figure 10(b) may also need the two compendia. We did not show such

association to avoid cluttering. The main compendium name as a link text will lead the

user to the homepage and the common compendia works as a common set of menu

probably on every context page. Another thing to note is that we might need a link to a

third-party application or page. We may use any symbol to represent it. The symbol

35

should contain the third-party application and/or page name in it. Figure 10 is a simple

solidification, but an actual one would have more complex structure.

7.2 Corroboration of the solidification

This step completes the previous step by detailing how visible pages are rendered in

terms of components, invisible pages, and various link types. It does not deal with logic

contained in the invisible page. Logic design should be done in a later stage. We

introduce more symbols for this step (Figure 11), which will be used along with

previously defined symbols (Figure 8). All the characteristics of the link types in Figure 8

equally apply to those in Figure 10.

Server page Client-sidecontrol page

Server-sidecontrol page

Applicationcomponent

Client-sidecomponent

Server-sidecomponent

<t> <b> <r> <c>

Trigger Build Redirect Coordinate

Figure 11. Additional symbols for the corroboration of the solidification.

The trigger link type in Figure 11 may or may not be clickable, and build,

redirect, and coordinate link types are in general not clickable by the user. For example, a

form validation script function is triggered automatically on an event, while simple

viewing of a calendar implemented as a script function is done through a click. As

explained earlier, there are four types of visible pages. A base page, either interactive or

non-interactive, will involve only client-side control pages and client-side components,

while derived pages will be associated with all of the link types, components, and

36

invisible pages. It is important to note that this step is only concerned about context

pages, not compendia, for a given compendium. The foreign context of a compendium is

not corroborated. Figure 12(a) and Figure 12(b) show a corroboration of Figure 10(a) and

10(b), respectively. The two client-side components shown in Figure 12(a)—WMP and

RA—can both be used to play the video clip (i.e. Author video interview) or one of them

can be chosen. And we might also combine several pages into one depending on the

implementation strategy. For example, the four pages in Figure 12(b)—“Record review”,

“Data access”, “DAC” (data access components), and “Confirm review” can be

implemented on a single page. However, we need a detailed association of pages before

any specific implementation. We also need to combine a “form validation component”

into its “host” page (see Figure 12(b)).

Book 1subjectpage

Excerpt

Author videointerview

AuthorProfile

<a>

<a>

Order<a>

Rating

BookmWriting

review

<a>

<a><a>

MainCommon

<a><a>

CSS

<c>

<c>

<c>

WMP RA<t><t>

App:products:books:science:physics:gravity

Figure 12(a). A corroboration of Figure 10(a)

37

Figure 12(b). A corroboration of Figure 10(b)

7.3 Development of link data dictionary

As pointed out by Senn (1989), there are many advantages in using a data dictionary for

an application development. A link data dictionary records data elements and data

structures. Data element names, data descriptions, aliases, length, and data values are

used to describe data elements, and data structures are built on four relationships of

components that may be either data items or other data structures. The four relationships

include sequence, selection, iteration, and optional relationships. We do not repeat the

basic structure here (for more details, see Senn, 1989, pp.184-204). In this step, we define

data flows over the six context link types and describe pages that require embedded logic

for a specific functionality. Figure 13 shows examples of each item for a link data

dictionary based on Figure 12(b).

38

Link data flow name: Registration info

Description: A user registrationinformation

From compendium: Writing review

From page: Quick register

From component: n/a

To compendia: Writing review

To page: Record quick registerTo component:

Data structures: Registration

n/a

simple reg info

need-to-know

preferences

Data structure name: simple reg info

Description: pieces of userinformation for aquick reg

Contents: email address

first name

last name

Figure 13(a). Sample link data flow dictionary entry

Figure 13(b). Sample link data structure dictionary entry

Although we only need a few pieces of information for a quick registration, we

also show, in Figure 13(a), additional two data structures (i.e., need-to-know and

preferences) for illustration purpose. The “simple reg info” data structure is described in

Figure 13(b). It shows only a sequence relationship. Depending on data structure,

however, we may need to show various relationships mentioned above. Individual data

elements should be described using a different form (see Figure 13(c)), and individual

pages being either visible or invisible and components being built from scratch should be

described using another form (see Figure 13(d)). For a logic summary, we may use

Structured English first and be detailed by Pseudocode.

2

Data element name: last name

Description: A user's last name

Type: AN

Length: 20

Range of values: From To

List of specific values (if any):

Other validity details (if any):

Page name: Record quick register

Component name: n/a

Description: Upon receiving auser's simple reg info,it writes it to adatabase table

Input: simple reg info

Output: 'Writing a review' witha user's last name onit

Logic summary: Structured English/Pseudocode

Figure 13(c). Sample form for describing link data element

Figure 13(d). Sample page/component dictionary entry

8. Discussion

We introduced some new concepts and classification schemes. They are not

“concepts for concepts.” Those concepts and classifications play a major role in

separating “what” from “how” aspects in developing Web-based applications. We can

also obtain the higher-level architecture by applying the concepts of main, common, and

aggregate access scope. The three access scopes succinctly suggest how the high-level

structure and presentation of an application would look like. Adding flesh to the skeletal

view entails refinements of the three access scopes into short but complete accounts of

subjects called compendia. Each element identified in the access scope corresponds to a

subject. The resulting refinement enhances modifiability and maintainability because

each compendium concerns its own subject, context pages, and context links. Organizing

an application into compendia also enables us to associate them with each other based on

semantic relationships among subjects and their context pages. It also makes it easier to

change the structure of an application by adding, deleting, or updating compendia as the

2

application evolves over time. The modularity obtained by applying the concepts of the

access scope and compendium can prevent a “ripple effect.”

In today’s Web applications, many Web pages that are rendered as a consequence

of a certain process and procedure are generated on the fly in response to certain events,

while some pages that contain facts and definitions are implemented as static pages. The

former was dubbed the derived page and the latter the base page. In addition, more and

more components are incorporated into Web-based applications (Fingar, 2000). This

implies that there are many “workhorse” pages and components operating behind the

scenes to provide dynamics. They are often invisible or not directly browsable by the

user. The users of a Web application do not care about what is working behind the

scenes, but they really do about what they actually see. The granulation of pages and

components, thus, made it possible to accelerate the idea. It enables us to identify “what”

by considering only the visible pages and then move to “how” through the incorporation

of the invisible pages and various components.

It is the hyperlink that actually distinguishes Web applications from other types of

applications. It can be said that a Web application is a nervous system in which signals

are carried by links to every part of the system to make it alive. This implies that not only

important is the identification of system parts, but also critical is the discovery of nerves

connecting the parts and the content of their signals. We introduced six context-link types

based on link semantics for the “nerves” themselves and the link data flow dictionary for

the “signal” content. The link types are useful in identifying associations between

compendia, between pages, between a page and a compendium, and with components of

them. They also are helpful in understanding how pages are generated by what

3

mechanisms as well as in reducing the number of clicks because the “picture” of a

compendium given by the connections through the link types provides a flexible

environment for implementation.

Overall, application of the new concepts and classification schemes are essential in

securing consistent global and local views of a Web application defined as well as in

achieving a higher global and local coherence. Furthermore, a complete context of

compendia and their semantic associations with other context can reduce the cognitive

overhead.

9. Conclusions and Suggestions for Future Research

Developing a Web application is simply beyond the converting a document into a markup

document. It involves more and more Web-related technologies and requires integration

with other technologies. It often implements fairly complex logic either through

components or within pages or both. Moreover, due to an inherent characteristic of the

Web, the size of an application can grow infinitely. The developers of Web-based

applications seem to get a sizable amount of pressure on delivering high-coherence and

low-cognitive-overhead applications along with “sustainable” contents. As a

consequence, developing Web application is getting complex and time-consuming

(Flurry and Vicknair, 2001). The paper is the result of a contemplative effort whose

primary goal is to provide a “sustainable” method for Web-based application

development. Nevertheless, we might not be able to conclude without some caveats that

eventually suggest what future research directions are.

First, though some intentional, we omitted a lot of details in the course of

adaptation of DFD in developing the method. Specifically, we did not mention two

4

elements: external entity and data store. We purposely skipped this element because it

seems that there were a few external entities for a Web application—at most, external and

internal users and external applications or pages. In a more sophisticated adaptation, we

might also consider individual compendia, pages, or components as external entities

when we create associations between two different compendia, between two pages in

different compendia, and between components and others. Second, we assumed that

software components were out there. We did not consider how to find and compose

appropriate components into a Web application. Component-based development involves

at least four tasks: building, searching, customizing, and composing (Mili et al. 1995).

Third, we skipped page content design, which is an important aspect of a Web-

application. This may include identifying individual content elements, positioning them,

determining the sizes of pages, and incorporating other interface elements. Finally, this

paper lacks detailed implementation and testing guidelines. Although implementing the

design specifications resulted from the application of this method, in most cases, would

be a straightforward mapping process, it would be a complete method provided there are

detailed implementation and testing procedures. Despite the factors, we believe that the

method that has been developed by rigorously applying a number of new concepts and

classifications should provide consistent and manageable design specifications for Web-

based application development.

References

Byrd, T. A., Cossick, K. L., & Zmud, R. W. (1992). A Synthesis of Research on

Requirements Analysis and Knowledge Acquisition Techniques. MIS Quarterly,

16(1), 117-138.

5

Conallen, J. (2000). Building Web Applications with UML. Reading, Massachusetts:

Addison-Wesley.

Conklin, J. (1987). Hypertext: An Introduction and Survey. IEEE Computer, 20(9), 17-

40.

Cook, M. A. (1996). Building Enterprise Information Architectures: Reengineering

Information Systems. Upper Saddle River, NJ: Prentice Hall.

Engelbart, D. C. (1995). Toward Augmenting the Human Intellect and Boosting Our

Collective IQ. Communications of the ACM, 38(8), 30-33.

Fingar, P. (2000). Component-based frameworks for e-commerce. Communications of

the ACM. 43(10), 61-66.

Flurry, G., & Vicknair, W. (2001). The IBM application framework for e-business. IBM

Systems Journal, 40(1), 8-24.

Fraternali, P. (1999). Tools and approaches for developing data-intensive Web

applications: A survey. ACM Computing Surveys, 31(3), 227-263.

Halasz, F., & Schwartz, S. (1994). The Dexter Hypertext Reference Model.

Communications of the ACM, 37(2), 30-39.

Hardman, L., & Sharrat, B. (1990). User-centered Hypertext Design: The Applications of

HCI Design Principles and Guidelines. In R. Mcaleese and C. Green (Eds.),

Hypertext State of the Art, Intellect, 252-259.

Isakowitz, T., Stohr, E. A., & Balasubramanian, P. (1995). RMM: A Methodology for

Structured Hypermedia Design. Communications of the ACM, 38(8), 34-44.

Jacobson, I., Christerson, M., Jonsson, P., & Overgaard, G. (1992). Object Oriented

Software Engineering: A Use Case Driven Approach. Wokingham, England:

Addison-Wesley.

Johnson-Laird, P. N. (1989). Mental Models. In M. I. Posner (Ed.), Foundations of

Cognitive Science, Cambridge, MA: MIT Press, 469-499.

Kahn, P. (1995). Visual Cues for Local and Global Coherence in the WWW.

Communications of the ACM, 38(8), 67-69.

6

Makadok, R. (1998). Can first-mover and early-mover advantages be sustained in an

industry with low barriers to entry/imitation? Strategic Management Journal. 19(7),

683-696.

Mili, H., Mili; F., & Mili, A. (1995). Reusing Software: Issues and Research Directions.

IEEE Transactions on Software Engineering, 21(6), 528-561.

Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two: Some Limits on

Our Capability for Processing Information. The Psychology Review, 63(2), 81-97.

Marchionini, G., & Schneiderman, B. (1988). Finding Facts and Browsing Knowledge in

Hypertext Systems. IEEE Computer, 21(3), 70-80.

O,Reilly, T. (2000). The Internet patent land grab. Communications of the ACM. 43(6),

29-31.

Rivlin, E., Botafogo, R., & Schneiderman, B. (1994). Navigating in Hyperspace:

Designing a Structure-based Toolbox. Communications of the ACM, 37(2), 87-96.

Senn, J. A. (1989). Analysis and Design of Information Systems, New York: McGraw

Hill.

Simon, H. (1962). The Architecture of Complexity. Proceedings of the American

Philosophical Society, 106(6), 467-482.

Taylor, D. A. (1995). Business Engineering with Object Technology. New York: John

Wiley & Sons.

Teng, J. T. C., Grover, V., & Fiedler, K. D. (1994). Business Process Reengineering:

Charting a Strategic Path for the Information Age. California Management Review,

36(3), 9-31.

Thuring, M., Haake, J. M., & Hannemann, J. (1991). What’s ELIZA Doing in the

Chinese Room Incoherent Hyperdocuments - and How to Avoid Them?

Proceedings of Hypertext ’91, 161-177.

Thuring, M., Hannemann, J., & Haake, J. M. (1995). Hypermedia and Cognition:

Designing for Comprehension. Communications of the ACM, 38(8), 57-66.

7

van Dijk, T. A., & Kintsch, W. (1993). Strategies of Discourse Comprehension. Orlando,

FL: Academic Press.