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.

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:
• 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 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.

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 (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
• 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 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.
• 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 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]

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 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.

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 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 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
• 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 it’s own lifecycle –
• Establish Prototype Objectives
• Define Prototype Functionality
• Develop Prototype
• Evaluate Prototype
• Repeat Development and Evaluation of prototypes until a consensus is reached on 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 –
• 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.

[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.

[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.