Prototyping: Guidelines for Professionals
Prototyping
Puneet Ralhan
CIS 732
Fall 2000
12/18/2000
Table of Contents3Introduction
3Prototype Development
4Methodology
4Types
6Paperboard Prototypes
6Contextual Prototyping
7Prototype Evaluation
7Protocol Analysis
8Cognitive Walkthrough (Normans Model)
9Communicability Evaluation
9Expert Reviews
10User Participation
11Rapid Ethnography
12Experience Prototyping
12Tools
13Hypermedia Management Tools
14Interface builders Tools
144th Generation Systems
15Object-Oriented Application Frameworks
15Shortcomings of current tools
16Web Applications Prototyping
17Benefits
19Final Thoughts
20References:
20Articles
21Books
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 users 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.
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 products 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 persons
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:
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 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
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 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 dont 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 cant 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.
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 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 (Normans 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 Normans 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
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 users 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
Shneidermans eight golden rules or Normans 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 designers 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 dont
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 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 Scneidermans 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 others 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 others 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
users 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.
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 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 cant 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]
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:
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
hypermedias 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 dont 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.
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 others 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.
Muoz, 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 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.
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 dont want to scroll: information that is not on the top
screen when a page comes up is only read by very interested
users.
Users dont 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
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.
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 its own
lifecycle
Establish Prototype Objectives
Define Prototype Functionality
Develop Prototype
Evaluate Prototype
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
products 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
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-models
-
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 and perhaps lead to highly
automated prototyping methodologies.
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.
[Muoz, Miller-Jacobs. 1992] In search of the ideal prototype.
Richard Muoz 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 Normans 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 - 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.
