1. Prototyping
Puneet Ralhan
CIS 732
Fall 2000
12/18/2000

2. Table of Contents
INTRODUCTION.................................................................................................................3
PROTOTYPE DEVELOPMENT.............................................................................................3
Methodology................................................................................................................4
Types ...........................................................................................................................4
Paperboard Prototypes...............................................................................................6
Contextual Prototyping...............................................................................................6
PROTOTYPE EVALUATION................................................................................................7
Protocol Analysis.........................................................................................................7
Cognitive Walkthrough (Norman’s Model).................................................................8
Communicability Evaluation.......................................................................................9
Expert Reviews............................................................................................................9
USER PARTICIPATION ....................................................................................................10
Rapid Ethnography....................................................................................................11
Experience Prototyping.............................................................................................12
TOOLS ............................................................................................................................12
Hypermedia Management Tools................................................................................13
Interface builders Tools.............................................................................................14
4th Generation Systems.............................................................................................14
Object-Oriented Application Frameworks................................................................15
Shortcomings of current tools...................................................................................15
WEB APPLICATIONS PROTOTYPING................................................................................16
BENEFITS........................................................................................................................17
FINAL THOUGHTS...........................................................................................................19
REFERENCES:..................................................................................................................20
Articles.......................................................................................................................20
Books.........................................................................................................................21

3. Prototyping
Introduction
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
interact 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
committing to it. This is possible if a prototype of the system to be developed is
available.
Prototyping is a development approach used to improve planning and execution of
software projects by developing executable software systems (prototypes) for
experimental 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. This 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 incorrect. 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 closely 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 focusing on the Web
Applications.
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 and 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 performance 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 techniques. 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.
3

4. Prototyping
Methodology
A methodology [Purtilo, Larson, Clark. 1991] that can be used for development of
prototypes is:
• Identify Objectives: First, 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 is 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 automated 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 the hypothesized solution.
• Repeat. This entire process is repeated until one of three outcomes is reached:
o sufficient information has been derived from the prototyping activities to
begin the development of a product
o no solution to the problem can be found or, equivalently, that the solution
would be too complex or costly to be of benefit
o the prototype system itself is of sufficient quality to serve as the
production-quality system or, that it can be modified to serve as the
production-quality system at less cost than a full-scale production-quality
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.
Types
There are three types of prototypes [Sommerville, 1995] –
• Throwaway Prototypes
• Evolutionary Prototypes
• Incremental Development
4

5. Prototyping
Throwaway prototypes essentially use prototypes to clarify functional / user interface
requirements 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 tempted 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 missing 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 application 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 is 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 suggested
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 development 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
reason.
• There is a strong trend for one team to carry out the entire 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 visions 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] –
• Horizontal
• Vertical
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 with 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
5

6. Prototyping
usability and identifying required navigation paths between different 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 of 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 might 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 developed.
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 pictures 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 and 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
• Prototypes 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
application. The contextual development differs from traditional user interface
development:
• 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 transforming 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.
6

7. Prototyping
The understanding of end users and their organization 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
according 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 data 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 interaction.
• 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 (including 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 also 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 techniques 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, start 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 quickly
7

8. Prototyping
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 from
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 analysis 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 thoughts 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. Some
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 recording sometimes
the analyst just takes notes since the recording could be influencing some
subjects
• 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 also
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 misunderstandings 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 human interaction with artifacts. The model
describes five states (goal, intention, action, perception, evacuation) and three
distances:
• 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
8

9. Prototyping
• 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
models.
Communicability Evaluation
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 to
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:
• Tagging 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 evaluation
were identified based on literature about explanatory design.
• In the interpretation 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 execution.
• 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-to-user message. A
semiotic engineering 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 and 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 elements 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
9

10. Prototyping
to keep the egos and confidence of the design team in perspective and help improve the
design and not just criticize the design. Some of the methods used for expert reviews
are –
• Heuristic Evaluation: The application is compared to some standard interface
guidelines like Scneiderman’s eight golden rules.
• Guidelines 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 Walkthrough: The experts stimulate the users walking through the
application and try to understand the regular usage cases along with exception
handling
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
design/interface.
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 development 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 needs 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, within 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, requirements 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 characterize 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 and developers, which confers existence on
them.
• 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 explanation and so forth.
10

11. Prototyping
• 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
considering.
• User representatives who are not specialists are able to conduct prototyping
activities and gather data, provided they have 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 management
• 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
Millen [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 limiting
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 common 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 translator 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
described 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 informants 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 methods.
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, streamlining 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 innovation
and good product design. Undoubtedly, the time pressures and constraints for HCI
11

12. Prototyping
design teams will continue to increase. Practical use of ethnographic methods, therefore,
depends on whether the methods can be adapted successfully to provide useful
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-hand
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. Experience 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 explore 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
Prototyping 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 focused 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 an 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 cannot 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 experiences others will have, brings a subjective richness to bear on design
problems.
Tools
A number of prototyping techniques have evolved over the past decade. Static
prototyping, also called low-fidelity prototyping, relies on mockups, storyboarding and
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 guidelines
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]
12

13. Prototyping
There are several types user interface prototyping 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 consisting
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 real 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 specification 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.
• Object-oriented application frameworks are class libraries that comprise 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, and 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 abstract 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 environment called Hyperform were presented by Wiil & Leggett
[1997].
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 distributed 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 categories of issues must be addressed
in future HBMS work:
13

14. Prototyping
1. Models and Architectures: Issues of scalability, extensibility, architectural
openness, computation, interoperability, distribution, and platform heterogeneity
are of critical importance.
2. Node, Link, and 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.
3. Browsing/Query and Search: Optimizing the synergy between hypermedia’s
navigational approach to data access 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.
4. Version Control: Effective 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.
5. Concurrency Control, Transaction Management, 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 critical
importance
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
Interface 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 / Microsoft 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 Dreamweaver 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 prototypes 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 Windows using different user interface objects /
widgets and have plenty of add-ons available that can help suit these applications for
special environments.
14

15. Prototyping
These applications have excellent usability and can be used for both prototyping and
development. 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.
Object-Oriented Application Frameworks
These are commercial 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] reports 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-programmers
• are extremely user friendly. Actually after a one-day CHI tutorial, 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 design 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 capture 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 solutions 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 editing 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
15

16. Prototyping
process, not just the “look and 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 interact 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 without 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
significant 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 task 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, allowing the modeler to be effective and precise, is
essential.
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
completeness, 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
emerging; 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
therefore not modeled in the schema, but they are rather described through
words, diagrams and ad-hoc means.
16

17. Prototyping
• Visual Communication bandwidth: One of the biggest problems for deriving an
actual implementation from a design, is the need to implement, for sophisticated
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-the-large and design in-the-
small
• 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
structures
• it allows the use of a purely functional interface, 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.
• Make navigation controls and orientation displays clear.
• Get your message across effectively.
• Use a consistent visual language.
• Ensure that your site is presentable and up-to-date.
• 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 want to read: reading speeds are more than 25% slower from
computer screens than from paper.
Benefits
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
prototypes are developed
17

18. Prototyping
• 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
systems
• The prototypes 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 users 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 prototype 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 excited 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 thrown 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, market 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 following
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 delivery 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 prototyping
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
functionality 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 problem detection: Practitioners rate prototyping as providing better
facilities for finding problems at an early stage of development than a waterfall
model.
18

19. Prototyping
Final Thoughts
There is no doubt about the value of prototyping in development of user interface. 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.
• Prototyping must be treated as a separate project with it’s own lifecycle –
o Establish Prototype Objectives
o Define Prototype Functionality
o Develop Prototype
o Evaluate Prototype
o Repeat Development and Evaluation of prototypes until a consensus is
reached on the 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 recognize 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 – user
developed prototypes 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 suits 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 of the current research includes:
• Development of new models for evaluating user prototypes –
o Communicability Evaluation [Prates, Barbosa and de Souza 2000]
o Cognitive Walkthrough using Norman's Model [Rizzo, Marchigiani,
Andreadis 1997]
• Development of new models for understanding user mental-models -
o Rapid Ethnography [Millen 2000]
o Experience Prototyping [Buchenau, Suri. 2000]
• Development of new prototyping tools -
o Hypermedia Management Tools like Hyperform [Wiil, Leggett. 1997]
o Web Prototyping tools like JWeb [Bochicchio, Paiano. 2000]
o 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
and perhaps lead to highly automated prototyping methodologies.
19

20. Prototyping
References:
Articles
[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 Computing 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
17 - 19, 2000, Brooklyn, NY United States.
[Harker. 1993] User participation in prototyping. Susan Harker. Communications 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.
David 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
3 - 7, 1992, Monterey, CA USA
[Nielsen, Wagner. 1996] 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.
Proceedings 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-in-the-large. James Purtilo,
Aaron Larson and Jeff Clark. International Conference on Software Engineering.
Proceedings of the 13th international conference on Software engineering. May 13 - 17,
1991, Austin, TX USA.
[Rizzo, Marchigiani, Andreadis. 1997] The AVANTI Project: Prototyping and evaluation
with a Cognitive Walkthrough based on the Norman’s model of action. Antonio Rizzo,
Enrica Marchigiani, Alessandro Andreadis. DIS ACM. 1997.
20

21. Prototyping
[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 - 19,
2000, Brooklyn, NY United 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 documentation.
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] Hyperform: A Hypermedia System Development Environment. Wiil
and Leggett. ACM Transactions on Information Systems, Vol. 15, No. 1, January 1997.
Books
[McConnell, 1998]. Software Project Survival Guide. Steve McConnell. Microsoft Press.
1998.
[Scneiderman, 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.
[Turoff, 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.
21