WebApp Design

1
 Design & WebApps
There are essentially two basic approaches to design: the artistic ideal of
expressing yourself and the engineering ideal of solving a problem for a
customer.
Jakob Nielsen

When should we emphasize WebApp design?

when content and function are complex

when the size of the WebApp encompasses hundreds of content objects,

functions, and analysis classes

when the success of the WebApp will have a direct impact on the success of the
business
2
 Design & WebApp Quality
Olsina and his colleagues [Ols99]
have prepared a quality
requirement tree that identifies
a set of technical attributes
usability, functionality, reliability,
efficiency, and maintainability
that lead to high-quality
WebApps.
Figure summarizes their work.
The criteria noted in the figure
are of particular interest if you
design, build, and maintain
WebApps over the long term.

Quality requirements tree.

Source: [Ols99]. 3
 Design & WebApp Quality
Offutt [Off02] extends the five major quality attributes noted in Quality requirements tree by adding
the following attributes:

Security
Rebuff external attacks
Exclude unauthorized access
Ensure the privacy of users/customers
Availability
the measure of the percentage of time that a WebApp is available for use
Scalability
Can the WebApp and the systems with which it is interfaced handle
significant variation in user or transaction volume
Time to Market
4
 Quality Dimensions for End-Users
Time
How much has a Web site changed since the last upgrade?
How do you highlight the parts that have changed?
Structural
How well do all of the parts of the Web site hold together.
Are all links inside and outside the Web site working?
Do all of the images work?
Are there parts of the Web site that are not connected?
Content
Does the content of critical pages match what is supposed to be there?
Do key phrases exist continually in highly-changeable pages?
Do critical pages maintain quality content from version to version?
What about dynamically generated HTML pages?
5
 Quality Dimensions for End-Users
Accuracy and Consistency
Are today's copies of the pages downloaded the same as yesterday's? Close enough?
Is the data presented accurate enough? How do you know?
Response Time and Latency
Does the Web site server respond to a browser request within certain parameters?
In an E-commerce context, how is the end to end response time after a SUBMIT?
Are there parts of a site that are so slow the user declines to continue working on it?
Performance
Is the Browser-Web-Web site-Web-Browser connection quick enough?
How does the performance vary by time of day, by load and usage?
Is performance adequate for E-commerce applications? 6
 WebApp Design Goals
In her regular column on Web design, Jean Kaiser [Kai02] suggests a set of design goals that are applicable to virtually every
WebApp regardless of application domain, size, or complexity:

Consistency
Content should be constructed consistently

Graphic design (aesthetics) should present a consistent look across all parts of the WebApp

Architectural design should establish templates that lead to a consistent hypermedia

structure

Interface design should define consistent modes of interaction, navigation and content
display

Navigation mechanisms should be used consistently across all WebApp elements

7
 WebApp Design Goals
Identity
Establish an identity that is appropriate for the business purpose

Robustness
The user expects robust content and functions that are relevant to the users needs

Navigability
designed in a manner that is intuitive and predictable

Visual appeal
the look and feel of content, interface layout, color coordination, the balance of text, graphics and other
media, navigation mechanisms must appeal to end-users

Compatibility
With all appropriate environments and configurations
8
 WebE Design Pyramid
user

The appropriate mix of design skills will Interface

design
vary depending upon the nature of the
WebApp. Figure depicts a design Aesthetic design

pyramid for WebApps. Each level of the Content design

pyramid represents a design action. Navigation design

Architecture design

Component design

technology
9
 WebApp Interface Design
Where am I? The interface should
provide an indication of the WebApp that has been accessed

inform the user of her location in the content hierarchy.

What can I do now? The interface should always help the user understand his current
options
what functions are available?
what links are live?
what content is relevant?

Where have I been, where am I going? The interface must facilitate navigation.
Provide a map (implemented in a way that is easy to understand) of where the user has been and what
paths may be taken to move elsewhere within the WebApp. 10
 Effective WebApp Interfaces
Bruce Tognozzi [TOG01] suggests
Effective interfaces are visually apparent and forgiving, instilling in their users a sense of
control. Users quickly see the breadth of their options, grasp how to achieve their goals,
and do their work.

Effective interfaces do not concern the user with the inner workings of the system. Work
is carefully and continuously saved, with full option for the user to undo any activity at
any time.

Effective applications and services perform a maximum of work, while requiring a

minimum of information from users.
11
 Interface Design Principles-I
AnticipationA WebApp should be designed so that it anticipates the uses next move.

CommunicationThe interface should communicate the status of any activity initiated by the user

ConsistencyThe use of navigation controls, menus, icons, and aesthetics (e.g., color, shape, layout)

Controlled autonomyThe interface should facilitate user movement throughout the WebApp, but it
should do so in a manner that enforces navigation conventions that have been established for the
application.

EfficiencyThe design of the WebApp and its interface should optimize the users work efficiency, not
the efficiency of the Web engineer who designs and builds it or the client-server environment that
executes it.

12
 Interface Design Principles-II
FocusThe WebApp interface (and the content it presents) should stay focused on the user
task(s) at hand.

Fitts LawThe time to acquire a target is a function of the distance to and size of the
target.

Human interface objectsA vast library of reusable human interface objects has been
developed for WebApps.

Latency reductionThe WebApp should use multi-tasking in a way that lets the user proceed
with work as if the operation has been completed.

Learnability A WebApp interface should be designed to minimize learning time, and once
learned, to minimize relearning required when the WebApp is revisited. 13
 Interface Design Principles-III
Maintain work product integrityA work product (e.g., a form completed by the user, a user
specified list) must be automatically saved so that it will not be lost if an error occurs.

ReadabilityAll information presented through the interface should be readable by young

and old.

Track stateWhen appropriate, the state of the user interaction should be tracked and stored
so that a user can logoff and return later to pick up where she left off.

Visible navigationA well-designed WebApp interface provides the illusion that users are in
the same place, with the work brought to them.

14
 Aesthetic Design
Dont be afraid of white space.

Emphasize content.

Organize layout elements from top-left to bottom right.

Group navigation, content, and function geographically within the page.

Dont extend your real estate with the scrolling bar.

Consider resolution and browser window size when designing layout.

15
 Content Design
Develops a design representation for content objects
For WebApps, a content object is more closely aligned with a data object for conventional
software

Represents the mechanisms required to instantiate their relationships to one

another.
analogous to the relationship between analysis classes and design components described
later.

A content object has attributes that include content-specific information and

implementation-specific attributes that are specified as part of design 16
 Architecture Design
Content architecture focuses on the manner in which content objects (or composite
objects such as Web pages) are structured for presentation and navigation.
The term information architecture is also used to connote structures that lead to
better organization, labeling, navigation, and searching of content objects.

WebApp architecture addresses the manner in which the application is structured to

manage user interaction, handle internal processing tasks, effect navigation, and
present content.

Architecture design is conducted in parallel with interface design, aesthetic design and
content design.
17
 Content Architecture
Grid
structure
Grid structure
Linear
structure

Hierarchical structure
Network
structure Hierarchical
structure

Network structure
18
 MVC Architecture
WebApp architecture describes an infrastructure that enables a Web-based
system or application to achieve its business objectives.
Jacyntho and his colleagues [Jac02b] describe the basic characteristics of this
infrastructure in the following manner:

Applications should be built using layers in which different concerns are taken into account;
in particular, application data should be separated from the pages contents (navigation
nodes) and these contents, in turn, should be clearly separated from the interface look-and-
feel (pages).

The authors suggest a three-layer design architecture that decouples interface

from navigation and from application behavior.
They argue that keeping interface, application, and navigation separate
simplifies implementation and enhances reuse. 19
 MVC Architecture
The model contains all application specific content and processing logic,
including
all content objects
access to external data/information sources,
all processing functionality that are application specific
The view contains all interface specific functions and enables
the presentation of content and processing logic
access to external data/information sources,
all processing functionality required by the end-user.
The controller manages access to the model and the view and coordinates the
flow of data between them.

20
 MVC Architecture
co n t ro ller
manages user request s
select s model behav ior
select s v iew response
user request behav ior request
or dat a ( st at e change)
browser v iew select ion

m o d el
encapsulat es funct ionalit y
encapsulat es cont ent object s
incorporat es all webApp st at es
client

HTML dat a dat a from model

updat e request
view ext ernal dat a
prepares dat a from model
request updat es from model
present s v iew select ed by
cont roller

serv er
21
 Navigation Design
Begins with a consideration of the user hierarchy and related use-cases
Each actor may use the WebApp somewhat differently and therefore have different
navigation requirements

The use cases developed for each actor will define a set of classes that
encompass one or more content objects or WebApp functions

As each user interacts with the WebApp, she encounters a series of navigation
semantic units (NSUs)
NSUa set of information and related navigation structures that collaborate in the
fulfillment of a subset of related user requirements
22
 Navigation Semantic Units
Navigation semantic unit
An NSU is composed of a set of navigation elements called ways of navigating (WoN) [Gna99].
A WoN represents the best navigation pathway to achieve a navigational goal for a specific type of user.
Each WoN is organized as a set of navigational nodes (NN) that are connected by navigational links.
In some cases, a navigational link may be another NSU. Therefore, the overall navigation structure for a
WebApp may be organized as a hierarchy of NSUs.

link12 link24
NN2
NN1
NN4 NSU

link13 NN3 link34

23
 Creating an NSU
<<navigat ion link>>
request alt ernat ive

<<navigat ion link>>

recommend component (s)
<<navigat ion link>> Product Component
select Room <<navigat ion link>>
Room show Product Component

<<navigat ion link>>

<<navigat ion link>> show descript ion
ret urn t o Room
<<navigat ion link>>
purchase Product Component
<<navigat ion link>>
BillOf Mat erials
view BillOf Mat erials
CompDescript ion

<<navigat ion link>> Market ingDescript ion

purchase Product Component
phot ograph
t echDescript ion

video
schemat ic
24
 Navigation Syntax
As design proceeds, your next task is to define the mechanics of navigation. A number of options are available as you
develop an approach for implementing each NSU:

Individual navigation linktext-based links, icons, buttons and switches, and graphical metaphors..

Horizontal navigation barlists major content or functional categories in a bar containing appropriate links. In
general, between 4 and 7 categories are listed.

Vertical navigation column

lists major content or functional categories

lists virtually all major content objects within the WebApp.

Tabsa metaphor that is nothing more than a variation of the navigation bar or column, representing content or
functional categories as tab sheets that are selected when a link is required.

Site mapsprovide an all-inclusive tab of contents for navigation to all content objects and functionality
25
contained within the WebApp.
 Component-Level Design

WebApp components implement the following functionality

perform localized processing to generate content and navigation capability
in a dynamic fashion
provide computation or data processing capability that are appropriate for
the WebApps business domain
provide sophisticated database query and access
establish data interfaces with external corporate systems.
26
THANKS

27
OOHDM: Object-Oriented Hypermedia Design Method
Daniel Schwabe and his colleagues [Sch95, Sch98b] originally proposed the Object-Oriented Hypermedia Design
Method (OOHDM), which is composed of four different design activities: conceptual design, navigational design, abstract
inter- face design, and implementation. A summary of these design activities is shown:

abst ract int erf ace implement at ion

concept ual design nav igat ional design design

Nodes, links, access Abstract interface

Classes, sub-systems, structures, navigational objects, responses to executable
w o r k p r o d u ct s relationships, attributes contexts, navigational external events, WebApp
transformations transformations

Classification, Resource
Mapping between Mapping between
composition, conceptual and navigation and provided by
d e si g n m e ch an i sm s aggregation, navigation objects perceptible objects target
generalization environment
specialization

Modeling semantics Takes into account user Modeling perceptible Correctness;

of the application profile and task. objects, implementing Application
d e si g n co n ce r n s chosen metaphors. performance;
domain Emphasis on cognitive
aspects. Describe interface for completeness
navigational objects 28
 Conceptual Schema
OOHDM conceptual design creates a representation of the subsystems, classes, and relationships that define the application
domain for the WebApp. UML may be used to create appropriate class diagrams, aggregations, and composite class
representations, collaboration diagrams, and other information that describes the application domain.
cu st o me r se le ct s co mp o n e n t

ProductComponent
co mp o n e n t re co mme n d at io n partNumber
re q u e st e d partName BillOfMaterials
partType
description identifier
price BoMList
numberItems
Room createNewItem ( ) priceTotal
getDescription ( )
roomName getTechSpec addEntry ( )
dimensions deleteEntry ( )
exteriorWindows editEntry ( )
exteriorDoors name( )
computePrice ( )

Sensor Camera ControlPanel SoftFeature

BoMItem

quantity
partNumber
cu st o me rco n t in u e s partName
partType
co mp o n e n t se le ct io n price
Order cu st o me r
re q u e st s p u rch ase addtoList ( )
orderNumber deletefromList ( )
customerInfo getNextListEntry ( )
billOfMaterials
shippingInfo
billingInfo
29
 Navigational Design for OOHDM
Navigational design identifies a set of objects that are derived from the classes defined in conceptual design.

A series of navigational classes or nodes are defined to encapsulate these objects.

OOHDM uses a predefined set of navigation classesnodes, links, anchors, and access structures [Sch98b].

Access structures are more elaborate and include mechanisms such as a WebApp index, a site map, or a
guided tour.

Abstract Interface Design and Implementation

The abstract interface design action specifies the interface objects that the user sees as WebApp interaction occurs.

A formal model of interface objects, called an abstract data view (ADV), is used to represent the relationship between interface
objects and navigation objects, and the behavioral characteristics of interface objects.

The ADV model defines a static layout [Sch98b] that represents the interface metaphor and includes a representation of
navigation objects within the interface and the specification of the interface objects (e.g., menus, buttons, icons) that assist in
navigation and interaction. 30
THANKS

31