Prototyping: Guidelines for Professionals - Njit

pogonotomygobbleIA et Robotique

15 nov. 2013 (il y a 5 années et 3 mois)

203 vue(s)


Puneet Ralhan

CIS 732

Fall 2000


Table of Contents













Paperboard Prototypes



Contextual Prototyping






Protocol Analysis



Cognitive Walkthrough (Norman’s Model)



Communicability Evaluation



Expert Re






Rapid Ethnography



Experience Pr






Hypermedia Management Tools



Interface b
uilders Tools



4th Generation Systems


Oriented Application Frameworks



Shortcomings of current tools























Software customers / users usually find it very hard to express their real requirements
and it is almost impossible to predict how a system will actually be used and how it will
t with other systems in the user’s workspace. Careful requirements analysis along
with systematic review of the requirements helps reduce the uncertainty of what a
system should do but there is no real substitute for trying out a requirement before
ing to it. This is possible if a prototype of the system to be developed is

Prototyping is a development approach used to improve planning and execution of
software projects by developing executable software systems (prototypes) for
al purposes. It is very suitable for gaining experience in new application areas
and for supporting incremental or evolutionary software development.

Prototyping has many objectives including evaluation of the design, functionality and
user interface. Thi
s report will be focusing on the user interface aspect with some
linkage to the functionality. A function defined in the specification may seem useful and
well defined but when the users finally try to use the application they find that their view
was inco
rrect. Prototypes thus let user validate and evaluate their requirements and thus
users can discover requirements omissions early in the process. Rapid Application
Development Methodology uses development of the prototypes by the software team,
working clo
sely with the users in the requirements identification phase. Then these
prototypes are either discarded (throw away prototypes) or enhanced (evolutionary
prototypes) into production systems.

In the last decade the biggest development has been the advent

of the Web based
applications where development times are short, large amount of functionality a must
and the user interface critical. Prototyping techniques have been adapted to serve this
purpose and there is a portion of this report that will be focusi
ng on the Web

Prototype Development

Thompson, Wishbow [1992] state that rapid prototyping allows members of the
development team to confirm whether the product interface (this can include its online
documentation) can be easily learned an
d used. Goals for rapid prototyping include:

Conducting iterative testing and revision early in the product development cycle.
This approach allows user testing to be an integral part of product design.

Using measurable objectives (benchmarks) for user per
formance and attitude.
Empirical measures prevent the endless debate that can sometimes follow user
testing. If subject behavior falls below the benchmark there is little doubt among
team members that something must be done.

Using simple, proven testing te
chniques. The think
aloud protocol method
advocated by Newell and Simon, and discussed frequently in the technical
communication literature allows for efficient data collection. If the coding scheme
is kept simple, reviewing data and reporting results can
be accomplished in a
matter of a few days. Protocol analysis also has the virtue of requiring only a
small subject sample.




A methodology [Purtilo, Larson, Clark. 1991] that can be used for development of
prototypes is:

Identify Objectives: Fi
rst, a definition of the problem to be solved must be
expressed, along with the criteria by which its success is to be judged.

Identify Risk: No realistic software effort can expect a clear and complete
statement as the result of a step labeled ‘define the

problem’, as the above item
might suggest. In the gray and uncertain areas of the problem definition lurk
great risks. These gray areas of risk must be identified and made explicit.

Formulate Prototyping Hypotheses: Once the risk areas have been expressed
the developer is in a position to design experiments to specifically address those
risks. Each experiment addresses a hypothesis concerning the nature and
potential remedy of the risk to a product’s success. The hypothesis should
include explicit linkage

to the parts of the project that may be affected.

Construct Prototype System: A system that implements the hypothesized
solution must be developed. Traditional programming practices are too
expensive to make this practical in many situations. Thus there i
s a need to use
specialized tools that facilitate inexpensive prototyping.

Instrument Prototype: Since the primary purpose of constructing a prototype is to
answer one or more questions concerning its functional or other characteristics, it
will usually be

necessary to gather dynamic information regarding the operation
of the software. In a large prototype, the complexity and volume of information is
likely to exceed the limit of a single person’s ability to comprehend it. It would be
desirable to use autom
ated tools for this purpose.

Experiment: The prototype system must be exercised to determine its behavior
and gather the output from the system instrumentation.

Evaluate Results: The results of the experiments must be evaluated to assess
the efficacy of th
e hypothesized solution.

Repeat. This entire process is repeated until one of three outcomes is reached:


sufficient information has been derived from the prototyping activities to
begin the development of a product


no solution to the problem can be found
or, equivalently, that the solution
would be too complex or costly to be of benefit


the prototype system itself is of sufficient quality to serve as the
quality system or, that it can be modified to serve as the
quality system at less

cost than a full
scale production
development effort.

Often the prototyping phase is considered as a part of the requirements gathering phase
and are outsourced to a vendor (external / internal) and then bids are gathered for the
development of
the production system.


There are three types of prototypes [Sommerville, 1995]

Throwaway Prototypes

Evolutionary Prototypes

Incremental Development



Throwaway prototypes essentially use prototypes to clarify functional / user interface
nts and also help the managers identify any potential risks. Once the prototype
is evaluated and the requirements updated the prototype is discarded and the
development starts afresh. The main problem faced in this approach is when the
management is tempte
d to take the prototype and enhance it into the real application. I
actually have seen this in my professional life and this can lead to problems like

uncontrolled changes during the prototyping stage, design compromises while adding
new features and mis
sing features like security, performance & reliability at base levels.
Since the prototype is not the final product the cost of iterations should be kept well in
control because of the tendency of the development team to go into too many details of
the app
lication and then tempting to reuse some of that application in the final product.

Evolutionary prototyping is based on developing an initial application and then iterating
through multiple user evaluations and improvements. The important aspect of this i
s that
the application has to be written in an environment that allows such development. A
good language for such application development would be Visual Basic or Powerbuilder.
The important aspects are that the design should be updated thoroughly at every

iteration to avoid any possibility of compromises being introduced in the application.

Incremental development is the methodology where each delivered production software
is taken as a prototype and after the evaluation by the users the changes and sugg
and incorporated in the next release. This is a useful in the environment where the
development cycles are small and the user group is anxious to get some functionality for
being able to work. The main drawback in this methodology is that the system
architecture needs to be determined initially and any changes to the architecture could
lead to compromises in the application robustness/reliability.

Baumer, Bischofberger, Lichter, Ziillighoven [1996] concluded that:

The reuse of prototypes for the deve
lopment of a target system can only be
recommended if the development tools produce prototypes with clean system
architecture. Many presentation prototypes are planned as throw always for this

There is a strong trend for one team to carry out the e
ntire development cycle.
Due to lack of know
how many organizations are still dealing with different teams
for prototyping and the development of target systems.

A newly emerging trend is to use prototypes as a vehicle for developing and
demonstrating vis
ions of innovative systems. This source for innovation can be
tapped not only for individual software projects but also for various kinds of
marketing research and field studies.

Another way of looking at prototypes is [Wiegers, 1996]



A horizontal prototype consists of a superficial layer of a user interface, revealing the
parts of the system that the user will see with little underlying functionality. Such a
prototype could be equated with a movie set with realistic street scenes w
ith two by fours
holding up the street fronts. Reason of creating a horizontal prototype include exploring
interface styles, determining if adequate functionality has been planned for, assessing
usability and identifying required navigation paths between d
ifferent parts of the



application. This application actually goes down to level of detail necessary for being
able to give the users accurate information for being able to evaluate the user interface
and navigational parts.

A vertical prototype consists o
f a complete slice of functionality for a limited portion of the
whole system. Such prototypes are useful for validating design approaches and
exploring alternative architectures for high
risk projects. For example a vertical prototype
of an application mi
ght actually take a functionality and implement the user interface,
middle layer (network communication) and some of the functionality of the backend
databases. Once the soundness of technical approach is established the rest of the
application can be deve

Paperboard Prototypes

Paperboard prototypes [McConnell, 1998] are an approach that is very useful for
developing early understanding of the user interface requirements. In this approach the
developers or the end users can start by developing pictu
res of the screens, dialogs,
toolbars and other elements they would like the user interface to have. Developers and
users meet in groups and draw simple screens on flip charts. The work involves
redrawing the prototypes on the flip charts until the users a
nd developers agree on the
systems appearance and functionality.

This approach offers several advantages

Users can develop prototypes on their own

Users don’t have to know prototyping software

Prototypes can be generated and modified rapidly

es are very inexpensive

Paperboard prototypes also eliminate some of the most common risks associated with
prototyping. On the developer side, they eliminate the need of unnecessarily
overextending the prototype and of spending too much time fiddling with

the prototype
tool. On the user side the paperboard prototypes eliminate the risk of the users thinking
that the prototype is the finished product.

One disadvantage of the paperboard prototype is that some developers and users
simply can’t visualize the

software on the paper mockups. This is a strong disadvantage
since the essence of the prototypes is to help users visualize the finished product and if
in a development effort it becomes apparent that there are cognitive gaps between the
understanding of
the paper prototypes between the developers and users then this
approach should be abandoned and the effort should begin on software prototypes.

Contextual Prototyping

Stary [2000] talks about developing prototypes using the context of use of the
ion. The contextual development differs from traditional user interface

It focuses on the context of usage the user population rather than on the
technical features required for interaction. However, the latter come into play
when transformin
g context specifications into user
interface code.

It considers design to be a non
linear process based on activities (re)engineering
work processes rather than performing traditional software
engineering tasks.



The understanding of end users and their o
rganization of work require a conceptual
framework of context
sensitive components of interactive systems. The TADEUS
framework puts the following components into mutual context:

Task model: The task model comprises the decomposition of user tasks
ng to the economic and the social organization of work.

User model: The user model details the individual perception of tasks, data
structures and interaction devices, as well as task/role
specific access modalities
and permits to data.

Problem domain da
ta model: The (problem domain) data model provides the
static and dynamic specification of the data
related functionality.

Interaction domain model: The interaction model captures all devices and styles
that might be used by the users in the course of int

Application model: The final specification is an application model. It integrates a
synchronies structure and behavior specifications.

A novel representation an interpretation scheme allows in TADEUS to integrate different
perspectives (includi
ng the application context) through semantically linked models. In
addition, the specification of the entire application can be executed for prototyping
purposes. Another novelty concerns the relations between elements of the models and
between the models.

They are automatically checked at a high level of operational
semantics with the help of a series of algorithms. In addition, the software architecture of
the environment is open to embed existing specification techniques and interaction
platforms and als
o generating frameworks and code.

Prototype Evaluation

Prototypes evaluation is a critical part of the prototyping process and there are two parts
of prototypes evaluation

User evaluation and Expert Evaluation. There are many User
evaluation technique
s including surveys, focus groups, application usage feedback,
ethnography observations etc. One of the most effective methods of user evaluation of
prototypes is

Protocol Analysis.

Protocol Analysis

Protocol Analysis [Turoff, Michie] is one of the most

effective methods for assessing the
usability of an information system and for targeting aspects of the system, which should
be changed to improve usability. The central part of protocol analysis is the complete
recording (in written, audio, and/or video
form) of the interaction of a user with a system,
while that user "thinks out loud" in order to allow the recording of his or her perceptions,
reasoning, and reactions to the system. The analysis is then provided by the researcher,
who examines a number of

these cases and reaches conclusions about aspects of the
system that cause problems for users.

Protocol Analysis requires only six to eight such recorded observations in order to reach
conclusions, and the procedure may be completed in a week or less, s
tart to finish. This
gives it great advantages over methods such as surveys and experiments, which
generally require a hundred or more subjects, and can take weeks, months, and even
years to complete. For a relatively small amount of effort, a designer can

discover any basic flaws in the design and has considerable chance of exposing more
subtle problems.



The technique of Protocol Analysis includes the following steps

Identification of the Subjects: The appropriate subjects have to be selected
the user group. The focus is on getting a fair representation of all the user groups
who will be using the application and there should also be an attempt to get at
least three subjects of each group to eliminate any sampling errors. Since
protocol an
alysis is conducted with each iteration of the prototype it would be
desirable to get different people involved in every phase.

Identification of Task: Central to protocol analysis is the task to be performed.
The task could range from gathering user thoug
hts on the screen shots to
actually having them use a system that has implemented the entire interface
without much of underlying functionality. The objective once again is to get each
group to interact with the aspects of the system that most impact them.

problem areas could be included for multiple groups.

Instructions to Users: Users should be given good instructions including the
assurance that the exercise is on the evaluation of the system and them. Often
the users are afraid to speak their mind
and their fears should be allayed.

Execution of Protocol Analysis: In this step the users actually go through the
steps identified in the task sheet and they are asked to “think aloud” as they
perform their task and are recorded. Instead of Audio/Video re
cording sometimes
the analyst just takes notes since the recording could be influencing some

Post Task Interview: Subjects are interviewed at the end of the task and are
asked specific questions about different choices that they made. They are als
asked to fill a survey that gathers details on different aspects of the design.

Analysis: Finally the designers take all the data and try to identify patterns in the
problems faced by the users. Also each transcript is reviewed to see if some
specific mi
sunderstandings exist.

Protocol Analysis is a technique that can be adapted to suit the individual organizations
and the cost savings in terms of future redesigns and usage of new applications usually
outweigh the expenses of conducting the experiments.

Cognitive Walkthrough (Norman’s Model)

Rizzo, Marchigiani, Andreadis [1997] explored conducting cognitive walkthrough based
on Norman's model of action. The Cognitive Walkthrough is a task based inspection
method widely adopted in evaluating user interface
. It consists of stimulating a user
interaction with the system. The Norman’s model of human action provides a sound yet
simplified theoretical framework of design and evaluation. It allows the definition of some
basic cognitive steps in the analysis of hu
man interaction with artifacts. The model
describes five states (goal, intention, action, perception, evacuation) and three

Referential distance, as for output evacuation, refers to the amount of mental
effort needed to translate the form of the

information displayed by the system into
a form which allows the operator to grasp its meaning

Semantic distance, as for the output evaluation, refers to the amount of human
information processing needed to translate the meaning of the output of an action

in the terms of the intention it serves



Interferential distance is the cognitive processing needed to put in relationship
the information processed in action execution and the information available as
result of the action

The subjects were asked to walk
through the applications and then they were asked to
fill a questionnaire that was designed to measure the various distances and that let the
designers understand some of gulf of execution in their mental models and users mental

Communicability Ev

Prates, Barbosa and de Souza [2000] propose a method of communicability evaluation
is a method based on semiotic engineering that aims at assessing how designers
communicate to users their design intents and chosen interactive principles, and thus

complements traditional usability evaluation methods. Semiotic engineering perspective
is that user interfaces are perceived as one
shot, higher
order messages sent from
designers to users. The authors claimed that the degree to which a user will be able
successfully interact with an application and carry out his tasks is loosely related to
whether he understands the designers' intentions and the interactive principles that
guided the application's design.

The process that was defined for this included

the following steps:

is the process of relating a sequence of interactive steps to an utterance
(from a predefined set), in an attempt to express the user’s reaction when a
communication breakdown occurs. The tags used in communicability evaluatio
were identified based on literature about explanatory design.

In the
step, the evaluator tabulates the data collected during
tagging and maps the utterances (communicability tags) onto problems
categories or design guidelines. The general

lasses of problems identified are
navigation, meaning assignment, task accomplishment, missing of affordance
and declination of affordance. Utterances may be mapped to such distinct
taxonomies as Shneiderman’s eight golden rules or Norman’s gulfs of execu

In the
semiotic profiling
step, the evaluators proceed to interpret the tabulation in
semiotic terms, in an attempt to retrieve the original designer’s meta
communication, that is, the meaning of the overall designer
user message. A
semiotic engin
eering expert, due to the nature of the analysis, should perform
this step.

The communicability method not only identifies problems, but also gives the designer
hints to a solution. The utterance category narrows down the possible causes of the
problem a
nd the tagged pieces frequently provide the designer with evidence of the
users intuitions about a solution. By identifying interface elements whose meaning users
were unable to grasp (missing of affordance) the designer may choose to represent
those eleme
nts differently.

Expert Reviews

Expert Reviews [Scneiderman, 1998] on the other hand are usually conducted on
prototypes before they are released for evaluation by the users. The objective is to fix
some basic design issues even before the users identify
them. It is necessary to have
experts from outside the design team since the peer reviews usually don’t identify as
many problems as the expert reviews do. Nonetheless the experts should be instructed



to keep the egos and confidence of the design team in p
erspective and help improve the
design and not just criticize the design. Some of the methods used for expert reviews

Heuristic Evaluation: The application is compared to some standard interface
guidelines like Scneiderman’s eight golden rules.

elines Reviews: The interface is checked for conformance to the
organizational guidelines for interface design.

Consistency Inspection: The different parts of the prototype are evaluated for
consistency of color, layout, terminology etc.

Cognitive Walkthro
ugh: The experts stimulate the users walking through the
application and try to understand the regular usage cases along with exception

Expert reviews are very useful in the early stages of prototype development and can
help significantly reduce
the prototype iterations required before the users sign
off on the

User Participation

User participation is central to the process of prototyping. Users are expected to commit
as much to development of the prototypes as the software d
evelopment team.

Bowers, Pycock [1994] did a study of multiple transcripts user
designer design process
and made the following observations:

Users in the user
designer cooperative setting rarely express or have to express
‘requirements’ (or wants or need
s or desires) directly. Frequently, the designer
will anticipate troubles in advance of their occurrence or provide a formulation of
them once they have occurred, Similarly, users will offer their contributions as
queries as to what is possible, doable, wi
thin their capabilities or within those of
the designer or machine. This and other phenomena indicate that users and
designers are orienting to each other’s skills and knowledge in ways that obviate
the need for direct requests or refusals. In a sense, req
uirements are a
negotiated product of argument and resistance.

Reformulating each other’s contributions and the other phenomena are quite
natural features of ordinary discourse as different parties make themselves and
their understandings plain. To charac
terize related phenomena developing a
system can involve designers ‘configuring the user’ just as they configure the
system and vice versa.

Requirements are produced as requirements in and through interaction. It is
social interaction between the users an
d developers, which confers existence on

User participation in design can be characterized as meeting between two
‘language games’ (that of the designer and that of the user’s world of work); the
games are not always played on a level playing field.

Close relations between designers and users in work
like settings are not itself
enough, for the exact manner of this involvement matters too. What designers
and users make of what they respectively find in such settings may differ or
require mutual expl
anation and so forth.



There should be encouragement of reflexive participatory design in which both
designers and users can become aware of the means by which requirements are
interactively produced.

Harker [1993] did a study of a large distributed system

development and reported three
issues relating to the use of prototyping as a part of user centered strategy are worth

User representatives who are not specialists are able to conduct prototyping
activities and gather data, provided they hav
e received some training and
assistance with the development of systematic development.

The prototypes developed by the user community provided direct and convincing
evidence about the job design and work organization issues for transmission to
the user ma

The case demonstrated that user managers encountered resistance to requests
for technical change from the software developers, who felt that organizational
changes were more appropriate than technical changes for many issues.

Rapid Ethnography

illen [2000] introduced "rapid ethnography" which is a collection of field methods
intended to provide a reasonable understanding of users and their activities given
significant time pressures and limited time in the field. The core elements include limiti
or constraining the research focus and scope, using key informants, capturing rich field
data by using multiple observers and interactive observation techniques, and
collaborative qualitative data analysis.

It has been argued that there has been a comm
on misunderstanding among HCI
professionals about the analytical nature of ethnographic research. While often
misconstrued as simply a method of field data collection, ethnography is rather form of
analytic reportage, with the ethnographer acting as a tran
slator or cultural broker
between the group or culture under study and the reader.

Many of the concepts from the rapid appraisal methods mentioned above are useful in a
discussion of ethnographic methods for HCI professionals. Rapid ethnography, as
ibed below, grew out of field research experience on a number of different projects,
and is based on three key ideas:

First, narrow the focus of the field research appropriately before entering the
field. Zoom in on the important activities. Use key inform
ants such as community
guides or liminal group members.

Second, use multiple interactive observation techniques to increase the likelihood
of discovering exceptional and useful user behavior.

Third, use collaborative and computerized iterative data analyze


There are several examples of rapid HCI methods. The most widely known would be the
class of techniques that collectively support rapid prototyping of new interfaces. This
includes requirements gathering end of the development process, streamlin
ing user
modeling and usability testing. The use of ethnographic methods in various parts of HCI
development will continue to grow. Understanding the context of the user environment
and interaction is increasingly recognized as a key to new product/service

and good product design. Undoubtedly, the time pressures and constraints for HCI



design teams will continue to increase. Practical use of ethnographic methods, therefore,
depends on whether the methods can be adapted successfully to provide use
information in a timely fashion.

Experience Prototyping

"Experience Prototyping" [Buchenau, Suri. 2000] can be described as a form of
prototyping that enables design team members, users and clients to gain first
appreciation of existing or future

conditions through active engagement with prototypes.
Experience is a very dynamic, complex and subjective phenomenon. It depends upon
the perception of multiple sensory qualities of a design, interpreted through filters
relating to contextual factors. Ex
perience Prototyping can valuable for three different
kinds of activities:

Understanding existing user experiences and context: Experience Prototyping
here is applied to demonstrate context and to identify issues and design
opportunities. One way to explor
e this is through direct experience of systems

the prototyping goal is to achieve a high fidelity simulation of an existing
experience, which can’t be experienced directly.

Exploring and evaluating design ideas: The main purpose of Experience

in this activity is in facilitating the exploration of possible solutions
and directing the design team towards a more informed development of the user
experience and the tangible components which create it. At this point, the
experience is already focuse
d around specific artifacts, elements, or functions.
Through Experience Prototypes of these artifacts and their interactive behavior
we are able to evaluate a variety of ideas and through successive iterations mold
the user experience.

Communicating ideas
to an audience: The role of Experience Prototyping here is
to let a client, a design colleague or a user understand the subjective value of a
design idea by directly experiencing it. This is usually done with the intention of
persuading the audience that a
n idea is compelling or that a chosen design
direction is incorrect.

People's experiences with products and systems are a complex integration of personal
and circumstantial factors. People will have experiences with the prototypes that the
designers canno
t hope to predict entirely. Nevertheless, understanding, exploring and
communicating the experiential aspects of design ideas are central activities in design.
Experience Prototyping, while it creates only approximate and partial simulations of the
real ex
periences others will have, brings a subjective richness to bear on design


A number of prototyping techniques have evolved over the past decade. Static
prototyping, also called low
fidelity prototyping, relies on mockups, storyboarding
paper and pencil strategies. This is followed by dynamic or high fidelity prototyping with
the construction of the actual interface using User Interface Builders. The various
manufacturers as well as windowing systems come with user interface design gu
as to how to make the system user
friendlier. These builders also generate programs for
the user interface layer, which can directly be integrated with application, and data
layers. [Turoff, Michie]



There are several types user interface prototyp
ing tools. There are four basic types of
prototype tools [Baumer, Bischofberger, Lichter, Ziillighoven. 1996]

Hypermedia management tools provide an interactive environment for
developing simple information systems with graphical user interfaces consisti
of cards, stacks of cards, links, and event handling scripts. The combination of
links and scripts makes HyperCard a powerful prototyping tool; links can be used
to quickly connect a set of drawn user interface states into a mock
up application
while re
al functionality can be implemented with scripts.

Interface builder tools serve to define user interfaces on a high abstraction level
either textually or with a graphical editor. They support the creation and laying
out of user interface elements and the s
pecification of the reaction on events.
Only interface builders that provide a graphical editor are of interest for
prototyping purposes.

4th generation systems are a complete development environment for information
systems. A 4GS usually provide tools for

graphically designing data models and
user interfaces, an integrated interpretive scripting language, and various other
tools such as report generators, program editors and debuggers.

oriented application frameworks are class libraries that compris
e an
abstract, reusable design for interactive document centered applications as well
as concrete implementations of the functionality that is common to such
applications. Application frameworks make it possible to develop user interfaces
based on complex
direct manipulation in a short time. They are suited for
prototyping of user interfaces that cannot be composed of standard components.

Hypermedia Management Tools

Development of hypermedia is a complex matter. The current trend toward open,
extensible, a
nd distributed multi
user hypermedia systems adds additional complexity to
the development process. As a means of reducing this complexity, there has been an
increasing interest in hyperbase management systems that allow hypermedia system
developers to abs
tract from the intricacies and complexity of the hyperbase layer and
fully attend to application and user interface issues. Design, development, and
deployment experiences of a dynamic, open, and distributed multi
user hypermedia
system development environ
ment called Hyperform were presented by Wiil & Leggett

Hyperform is based on the concepts of extensibility, tailorability, and rapid prototyping of
hypermedia system services. Open, extensible hyperbase management systems permit
hypermedia system
developers to tailor hypermedia functionality for specific applications
and to serve as a platform for research. The Hyperform development environment is
comprised of multiple instances of four component types: (1) a hyperbase management
system server, (2)

a tool integrator, (3) editors, and (4) participating tools. Hyperform has
been deployed in Unix environments, and experiments have shown that Hyperform
greatly reduces the effort required to provide customized hyperbase management
system support for dist
ributed multi
user hypermedia systems.

Hypermedia systems pose several difficult data management problems. Most of these
ultimately can be derived from the fact that hypermedia is a complex amalgam of
information, structure, and behavior. Five broad categ
ories of issues must be addressed
in future HBMS work:




Models and Architectures
: Issues of scalability, extensibility, architectural
openness, computation, interoperability, distribution, and platform heterogeneity
are of critical importance.


Node, Link, a
nd Structure Management
: Data management facilities for
hypermedia must address issues relating to object identity and naming, as well
as constraints to ensure object and structure integrity. In addition, support for
object composition, contexts, and views

are critical. The management of data
types including spatial, temporal, image, sequence, graph, probabilistic, user
defined, and dynamic is essential.


Browsing/Query and Search:

Optimizing the synergy between hypermedia’s
navigational approach to data ac
cess and traditional query and search must be
addressed at the hyperbase level. Important issues include the introduction of
multilevel store indexing techniques, agency, hyperbase heterogeneity,
extensibility, and optimization.


Version Control:

support for versioning requires an understanding of
precisely which entities need to be versioned and when version creation occurs.
In hypermedia, there are opportunities to version structure as well as information.


Concurrency Control, Transaction Manage
ment, and Notification:

The types of
interactivity and operations that characterize hypermedia systems create a
requirement for managing short, long, and very long hyperbase transactions.
HBMS support for collaboration and sharing of information is of crit

Mercifully, there are a plethora of hypermedia development tools which though not as
complex as Hyperform are commercially available and can be tailored to support any
level of requirements of the users.

Interface builders Tools


development tools are essentially of two types

Drawing Applications and
Web interface development tools.

Some of the applications that allow drawing the interface include applications like
Microsoft Paint (included in windows), Microsoft Word / Micros
oft PowerPoint (available
in the MS Office suite) and Visio (from Microsoft). These are common applications and
the user community is usually very well trained in these tools and can draw the
interfaces on their own. The shortcoming of these tools is that
they are not intended for
interface design and it might actually be worth a while to train some of the user
community on the advanced interface design tools.

Web Interfaces can be implemented using applications like Microsoft FrontPage and
Macromedia Drea
mweaver which though not an advanced hypermedia management
tools are sufficient for designing web application interfaces. Along with these tools there
is also a need to use advanced graphics packages but those don’t come into play until
the final prototype
s are being delivered.

4th Generation Systems

There are many commercial 4GS tools from different vendors. Two of the more popular
tools are Microsoft Visual Basic and Powersoft Power Builder (from Sybase). These are
tools that allow interface design for W
indows using different user interface objects /
widgets and have plenty of add
ons available that can help suit these applications for
special environments.



These applications have excellent usability and can be used for both prototyping and

The problem is that often there is a temptation to take the prototype (which
has undergone multiple uncontrolled changes which have compromised the design) and
develop it into a production system.

Oriented Application Frameworks

These are commerci
al application frameworks that allow drag and drop development of
applications from widgets. One of the examples of these is the Java Beans Development
kit (Sun). There are also other applications being used for research like JWeb
[Bochicchio, Paiano. 2000

There are other object oriented tools that though not quite suitable for prototyping are
sometimes used for prototyping. These include Java Builder (Borland), Visual Café
(Symantec), Visual C++ (Microsoft) and Visual Age (IBM).

Schmucker [1996] repo
rts that there are visual programming tools available that:

are commercially
available, robust development tools

are cross
platform tools

are completely visual

are usable by non

are extremely user friendly. Actually after a one
day CHI tutoria
l, an attendee
would have little problem getting started in their use immediately.

Shortcomings of current tools

There are many shortcomings of the current prototyping tools. Tscheligi [1995] reports
the following shortcomings in the current interface de
sign tools:

The capture bottleneck: During the initial stages of a design, designers typically
hold brainstorming sessions in which ideas are drawn on whiteboards.
Individuals also make rough notes and sketches in their drawing pads. It is
difficult to cap
ture notes from a non
computer medium to get them onto the
computer medium.

Managing components: As a design progresses many prototypes are produced
which address various aspects of the user experience. It becomes increasingly
difficult to integrate solut
ions and relate them to each other.

Managing collaboration: It becomes increasingly difficult to integrate the work of
individuals with the collective work as a design progresses. Collaborators need to
see each other’s work as well as to have access to ed
iting their part separately.

Designing dynamics: Motion and transitions are an integral part of a visual
interactive experience. Without easy access to designing visuals in dynamic
forms, only limited new interaction designs can be achieved.

Other Aspects
: Many of the existing tools do not provide templates or paradigms
editing metaphors, mental models, and navigation. The current tools are not quite
sophisticated and you still have to program to do anything interesting.

Muñoz, Miller
Jacobs [1992] state
that often prototyping efforts concentrate only on the
UI aspects of a software product. In many cases, the UI is designed and implemented
separately from the "functional core" of an application. However, the whole functioned
process, not just the “look an
d feel” of the UI, determines usability. Prototyping tools



would be more useful if they allowed prototyping of the functional parts along with the UI.
User interfaces must be designed on the screen rather than on paper. The only way to
see how elements int
eract is to see them interact. How else can users make wise
decisions about the complexities of color, layout, icons, typography, windowing,
interaction dynamics, and design integrity. It is simply not possible to design a
competitive user interface withou
t powerful prototyping tools from the start.

Web Applications Prototyping

Web Applications are really no different than the regular application with the difference
being that the user base is usually much bigger and user interface flaws can have
icant impacts on the e
business aspirations of the organization. Secondly, the
development cycles are usually very small and the evolutionary prototyping technique is
very appropriate for web applications.

Design of large web sites can be a very complex t
ask if not supported by a suitable
theoretical model. A good structural model, in fact, is able to precisely define the
information of this kind of multimedia applications and the related patterns. Moreover,
through a good design model the designer is able

to precisely formulate his/her ideas,
discuss them revise them, without actually starting any implementation. The modeling
activity necessarily implies rough initial ideas, revisions, versions, etc. For these reasons
a design supporting environment, allo
wing the modeler to be effective and precise, is

There are several reasons why an environment supporting design/prototyping, and not
necessarily implying implementation, is useful [Bochicchio, Paiano. 2000]:

Support in the early stage: Design
needs to be checked, tested, discussed and
revised several times before it is competed.

Multidelivery: More and more it happens that the same content must be delivered
in several different ways: off
Iine, on
line, with different levels of depth and
teness, etc. If this is the situation, it is clear that design must be
completed independently from any implementation that, afterward, can proceed
in several different ways.

Technological flexibility: More and more delivery environments for the web are
erging; mostly for the multimedia aspects, for the graphic, for the interface etc,
so that new possibilities are open every day. Given this situation having to
choose a specific deliver), environment, or be cut out from new exciting
possibilities, as would

inevitably happen in a full
scale development environment,
is not advisable.

Design advanced options: Sophisticated applications requires advanced design
features, for which fully automated implementation could not be devised. It would
be negative to not
include those features in design, just because automatic
implementation could not support them.

Design incompleteness: For advanced applications, there are specific features,
which can't be described by even the best design model. These features are
ore not modeled in the schema, but they are rather described through
words, diagrams and ad
hoc means.

Visual Communication bandwidth: One of the biggest problems for deriving an
actual implementation from a design, is the need to implement, for sophistic



applications, high visual communication bandwidth, consisting of complex
graphic objects, special effect, animations, local interactions, etc.

The JWeb [Bochicchio, Paiano. 2000] system is an extremely modular and flexible
design environment and does

not follow strict procedural guidelines. It is a design
environment with fast prototyping capabilities with the following features:

it supports design of the hyperbase and of the access structures

it supports a clean separation between design in

and design in

it allows to build an environment repository, based on a relational DB to hold the
multimedia contents

it allows to try several configurations, both for the hyperbase and access

it allows the use of a purely functional i
nterface, but it is also possible to test
several high quality pre
defined interfaces

it allows to "execute" the application (using a small example of actual data, or
fictitious data) in order to "visualize" the implications of the design.

There are some
general rules for designing prototypes for web applications [Nielsen,
Wagner. 1996] [Heller, Rivers. 1996]

The techniques of HCI design still apply.

Design for readers with low bandwidth connections.

Account for the way different readers see your pages.

ke navigation controls and orientation displays clear.

Get your message across effectively.

Use a consistent visual language.

Ensure that your site is presentable and up

Accommodate your readers all over the world

Build a place where readers will
want to contribute.

Give readers something to do.

People have very little patience for poorly designed web sites

Users don’t want to scroll: information that is not on the top screen when a page
comes up is only read by very interested users.

Users don’t w
ant to read: reading speeds are more than 25% slower from
computer screens than from paper.


The benefits of developing the prototypes early in the software process include (taken
from [Sommerville, 1995])

Misunderstanding between the software
developers and users may be identified
as the system functions are evaluated

Missing user services may be generated

Difficult to use / confusing services may be discovered

Software development may identify incomplete / inconsistent requirements as the
otypes are developed

A working, albeit limited, system is available to quickly to demonstrate the
feasibility and usefulness of the application to management



The prototypes serve as the basis for the requirements for production quality

The prototyp
es can be used to initiate early user training

Test cases can be generated based on the prototypes while the system is still
being constructed

Prototyping can lead to reduction in the expectation gap [Wiegers, 1996] with every
iteration of the prototype.
Expectation gap is the difference in what the develop builds
and what the customers expect. During the first prototype evaluation there is usually a
large expectation gap but with each iteration it reduces and finally there will be harmony
in what the user
s and expecting and the developers are building. The expectation gap
can be expressed as both functional and user
interface differences.

Prototypes should lead to user excitement and desire of the product [McConnell, 1998].
The first version of the proto
type will rarely get the users excited but the developers
should encourage the users to give feedback for the revision of the prototypes and let
them know that their feedback will be considered in the redesign. Refining the prototypes
until the users are e
xcited about it supports the creation of the software that will
ultimately be highly satisfactory rather than the software that will merely “satisfy
requirements”. It might seem like a large effort is being spent on something that will
eventually get throw
n away but this upstream activity is a good investment in avoiding
costly downstream problems.

Baumer, Bischofberger, Lichter, Ziillighoven [1996] reported that the benefits that arise
from applying prototyping to acquire information about feasibility, ma
rket interest or to
gain experimental experience have been recognized and actually some of their
investigated projects did not even have a target system as a major goal.

Verner, Cerpa [1997] did a survey of Australian companies and concluded the followin
benefits for prototyping based development over waterfall development:

Communication with Users: Prototyping scored higher than the waterfall
approach for communication with users. Prototyping allows users get to know
more about the product before delive
ry and this gives them the opportunity to
request changes if they do not like the proposed system.

Flexibility of Design Produced: Practitioners find that design flexibility is greater
with a prototyping approach. This agrees with other findings that proto
provides design flexibility during the development process, especially when users
and developers are inexperienced with the kind of system being developed.

Functionality: Practitioners rate prototyping as providing significantly better

than systems produced with a waterfall approach. However it must
be noted that respondents said that much of the prototyping is being done within
a waterfall approach and the use of both approaches together should result in
improved functionality.

Early p
roblem detection: Practitioners rate prototyping as providing better
facilities for finding problems at an early stage of development than a waterfall



Final Thoughts

There is no doubt about the value of prototyping in development of user interf
ace. Some
of the important rules for prototyping include:

Prototyping must become part of the project plan. The development team must
estimate the time, staffing levels, and resource levels as if it were as important as
any other part of design process.

ototyping must be treated as a separate project with it’s own lifecycle


Establish Prototype Objectives


Define Prototype Functionality


Develop Prototype


Evaluate Prototype


Repeat Development and Evaluation of prototypes until a consensus is
reached on th
e Functionality and User Interface

Prototyping must be agreed upon means for determining the product’s external
design specifications (that is, the "look and feel") and for confirming the core
functionality of the product. The development team must recogni
ze that there is
no substitute for iterative user testing of the product prior to coding.

Organizations should invest into evaluation and training on different prototyping
tools. The prototyping should ideally be divided into two aspects

developed p
rototypes and software team developed prototypes.

Organizations should explore different prototyping techniques and then adapt
some of them as organizational standards. Different project managers should
have the freedom to choose the technique that best su
its their needs.

One important aspect of prototyping is that the objective of the prototypes should
be declared initially and the user group should be made aware of the risks of
trying to convert a throwaway prototype into a production application.

Some o
f the current research includes:

Development of new models for evaluating user prototypes


Communicability Evaluation [Prates, Barbosa and de Souza 2000]


Cognitive Walkthrough using Norman's Model [Rizzo, Marchigiani,
Andreadis 1997]

Development of new
models for understanding user mental


Rapid Ethnography [Millen 2000]


Experience Prototyping [Buchenau, Suri. 2000]

Development of new prototyping tools


Hypermedia Management Tools like Hyperform [Wiil, Leggett. 1997]


Web Prototyping tools like
JWeb [Bochicchio, Paiano. 2000]


Java based Object Oriented Application Frameworks

Particularly, the new tools that are being developed will reduce the time and cost
expense of prototyping and will lead to more and more use of the prototyping techniques
d perhaps lead to highly automated prototyping methodologies.





[Baumer, Bischofberger, Lichter, Ziillighoven. 1996] User Interface Prototyping

Concepts, Tools, and Experience. IEEE Proceeding of ICSE
18. 1996.

[Bochicchio, Paiano.

2000] Prototyping Web Applications. Mario Bochicchio & Roberto
Paiano. SAC, ACM. 2000.

[Bowers, Pycock. 1994] Talking through design: requirements and resistance in
cooperative prototyping. John Bowers and James Pycock. Conference on Human
Factors and Co
mputing Systems. Proceedings of the CHI '94 conference companion on
Human factors in computing systems. April 24

28, 1994, Boston United States

[Buchenau, Suri. 2000] Experience prototyping. Marion Buchenau and Jane Fulton Suri.
Symposium on Designing
Interactive Systems. Proceedings of the ACM conference on
Designing interactive systems: processed, practices, methods, and techniques. August

19, 2000, Brooklyn, NY United States.

[Harker. 1993] User participation in prototyping. Susan Harker. Comm
unications of the
ACM. Volume 36 , Issue 6 (1993).

[Heller, Rivers. 1996] Design Lessons from the Best of the World Wide Web. Hagan
Heller & David Rivers. CHI 1996.

[Millen, 2000] Rapid Ethnography: Time Deepening Strategies for HCI Field Research.

R. Millen. DIS ’00. ACM. 2000.

[Muñoz, Miller
Jacobs. 1992] In search of the ideal prototype. Richard Muñoz and Harold
H. Miller
Jacobs. Conference proceedings on Human factors in computing systems. May

7, 1992, Monterey, CA USA

[Nielsen, Wagner. 19
96] User Interface Design for the World Wide Web. Jakob Nielsen
and Annette Wagner. CHI 1996.

[Prates, Barbosa and de Souza. 2000] A Case Study for Evaluating Interface Design
through Communicability. Raquel Prates, Simone Barbosa and Clarisse de Souza.
roceedings of the ACM conference on Designing interactive systems: processed,
practices, methods, and techniques. August 2000, Brooklyn, NY United States.

[Purtilo, Larson, Clark. 1991] A methodology for prototyping
large. James Purtilo,
Aaron Lars
on and Jeff Clark. International Conference on Software Engineering.
Proceedings of the 13th international conference on Software engineering. May 13

1991, Austin, TX USA.

[Rizzo, Marchigiani, Andreadis. 1997] The AVANTI Project: Prototyping and eva
with a Cognitive Walkthrough based on the Norman’s model of action. Antonio Rizzo,
Enrica Marchigiani, Alessandro Andreadis. DIS ACM. 1997.



[Schmucker. 1996] Rapid Prototyping using Visual Programming Tools. Kurt Schmucker.
CHI 1996.

[Stary, 2000
] Contextual prototyping of user interfaces. Chris Stary. Symposium on
Designing Interactive Systems. Proceedings of the ACM conference on Designing
interactive systems: processed, practices, methods, and techniques. August 17

2000, Brooklyn, NY Unit
ed States.

[Thompson, Wishbow. 1992] Prototyping: tools and techniques: improving software and
documentation quality through rapid prototyping. Michael Thompson and Nina Wishbow.
Proceedings of the 10th annual international conference on Systems documenta
October 13

16, 1992, Ottawa Canada

[Tscheligi. 1995] Creative Prototyping Tools: What Interaction Designers Really Need to
Produce Advanced User Interface Concepts. Manfred Tscheligi. CHI 1995.

[Verner, Cerpa. 1997] The effect of department size

on developer attitudes to
prototyping. J. M. Verner and N. Cerpa. International Conference on Software
Engineering. Proceedings of the 1997 international conference on Software engineering.
May 17

23, 1997, Boston United States.

[Wiil, Leggett. 1997] H
yperform: A Hypermedia System Development Environment. Wiil
and Leggett. ACM Transactions on Information Systems, Vol. 15, No. 1, January 1997.


[McConnell, 1998]. Software Project Survival Guide. Steve McConnell. Microsoft Press.

an, 1998] Designing the User Interface

Strategies for effective human

computer interaction. Ben Scneiderman. Third Edition. Addison
Wesley. 1998.

[Sommerville, 1995]. Software Engineering. Ian Sommerville. Fifth Edition. Addison
Wesley. 1995.


Michie]. The Design and Evaluation of Interactive Systems. Murray Turoff and
Eileen Michie. Draft Copy.

[Wiegers, 1996]. Creating a Software Engineering Culture. Karl E Wiegers. Dorset
House. 1996.