A picture may be worth a thousand words, but a prototype is worth a thousand pictures
Prototyping is necessary to ensure that the developed application meets the real needs of the user, which are not always truly captured by some sort of specification document which, in our case, was a paper design. Nielsen [1993] points out that prototyping is useful for early usability testing. The idea is to save on the time and cost to develop something that can be shown to and tested with real students. Moreover, it promotes interaction among different concerned parties such as users, domain experts, and developers. It helps everyone to understand the requirements and it fosters team spirit.
These savings can only be achieved by somehow reducing the prototype as compared to the full functional system: either cutting down on the number of features in the prototype, reducing the level of functionality of the features (i.e., faking them), or reducing both the number of features and the level of functionality to arrive at a scenario that is only able to simulate the interface as long as the test user follows a previously planned path (Nielsen, Tognazzini [1992]). Scenarios are the ultimate minimalist prototype. They are easy and cheap to build, while at the same time not being very realistic. In the remainder of this paragraph, no further attention is paid to scenarios. The following figure, which was adapted from (Nielsen, shows the two dimensions of prototyping:
Cutting down on the number of features is called vertical prototyping since the result is a narrow system that does include indepth functionality albeit only for a few selected features. The advantage of a vertical prototype is that the few implemented functions can be tested in depth under realistic circumstances.
Reducing the level of functionality is called horizontal prototyping since the result is a surface layer that includes the entire human-computer interface to a full-featured system but with no underlying functionality. It is a simulation of the interface in which no real work can be performed. The main advantage of horizontal prototypes is that they can be implemented fast with the use of various screen design tools. Horizontal prototypes offer a complete overview of the entire interface and can thus be used to assess how well it 'feels' as a whole (Nielsen).
The prototype of COOPerator's client application is neither a vertical nor a horizontal prototype. The writing process itself (the mere putting down of words) being the exception, we did not really cut down on the number of features, neither did we reduce the level of functionality. To a large extent, this accounts for the rather long time it took us to build the prototype. Also, the developers may have spent too much time iterating uncontrollably. Tkach and Puttick [1994] warn for this to happen. Moreover, we have once 'thrown away our prototype' (Rudd and Isensee [1994]) and started all over again for two different reasons. To begin with, the prototype just was not right the first time; also, we decided to switch to a more recent version of our prototyping tool during the process. Of course, a smooth upgrade path was not available.
According to Tkach and Puttick, there are two types of prototypes: Analysis prototypes, and domain prototypes.
The analysis prototype is an aid for exploring the problem domain. It is meant to inform the user and show proof of concept. It is, however, not to be used as the basis for development. Therefore, it can be discarded when it has served its purpose. The final product should use the concepts exposed by the prototype, not its code.
The domain prototype is an aid for the incremental development of the ultimate solution. It can be used as a tool for staged delivery of subsystems to users or perhaps to other development teams. It shows the feasibility of the implementation, and will eventually evolve into a deliverable product after testing, documentation, code cleanup, and review.
Alas, the first prototype of The COOPerator should be considered an analysis prototype. The language we used to program it with could not satisfy our needs, it was not robust enough to enable us to create a more sophisticated end-user application. This is particularly frustrating in an object oriented environment as reuse of coded objects is now out of the question (especially since the development of the programming language has been stopped).
This experience stresses the point Rudd and Isensee make: use the best tools, as it will have a significant impact on the succes of the prototyping effort.
Tognazzini claims that prototypes should be build within a short period of time using rapid, inexpensive tools. An object oriented programming language can be a great prototyping tool given that the programmer is an experienced user of the language. Unfortunately, when I joined the team, I had only little experience programming with objects (in Digitalk's Smalltalk/V 2.0) and had never heard of the Actor Professional environment.
However, at Tilburg University and consequently at the Infolab this situation is changing rapidly. I was taught how to program using the popular Pascal language. Nowadays, all students learn object oriented programming in Parcplace's Visualworks Smalltalk system. By keeping track of all the classes produced (according to Tkach and Puttick, typically the task of a library supervisor) at least a wealthy object oriented prototyping environment could be created. And if Object magazine's (70754.1111@compuserve.com) October 1994 issue is right, Smalltalk (no matter what dialect) will continue to grow into a popular commercial product application development.
We have learned a lot so far from building the first prototype. For one, we have been able to give numerous demonstrations for a diverse audience, collecting useful comments in the process. As a result, the first production version of The COOPerator will certainly be a more usable application.
Sjoerd Michels, Tilburg, The Netherlands