context-based web application design
TRANSCRIPT
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: [email protected] 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: [email protected] 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.