Digital Libraries: The Power of Prototypes
By Roy Tennant -- Library Journal, 5/15/2006
I love prototypes. Prototypes allow you to be creative without the detail that accompanies building a production system and often kills enthusiasm. It is, in other words, just the fun part.
I recently grabbed about 75,000 MARC records that were conveniently sitting on a work server and wrote a small Perl program to parse out the bits I needed. Using the MapReduce algorithm designed to lessen the complexity of large data sets, I processed that data to write out a file that had all the values for Title, Date, and Subject and which records had those values all in one line per key/value pair. Once I wrote a very simple interface, I had constructed a prototype library catalog faceted browse system in less than a day.
One of the benefits of a prototype is that the small investment does not require a large return in order to be worthwhile. The investment does not even need to be as high as in this prototype. There are several different methods of prototyping, and all offer benefits.
Paper or virtual?
A paper prototype is really what it sounds like—a paper depiction of a system and its functions. It often consists of a series of screens that the user would see. Paper prototypes can be a low-cost and easy way to test an idea with a user group before investing in developing the actual system.
Virtual prototypes look and act like the real thing through “smoke and mirrors” techniques. The most common example is a set of web pages that mimic the planned functionality by implementing only one set of interactions.
A virtual prototype for a search system may consist of an entry page that offers the planned search options. But no matter what is selected when searching, it would always display the same results since it is just sending you to the next page rather than actually performing a search. Therefore, usability testing of virtual prototypes is limited to coaching the user through a particular path that you’ve set up in advance and collecting feedback on that path.
Functional prototypes
Working prototypes are useful for gathering feedback on functionality but may lack touches like good graphic design. Therefore, usability testing of a functional prototype may focus more on user satisfaction with system options, results display, and labeling of options than on the user interface.
Functional prototypes can also be used to investigate the viability and desirability of a particular system. You can gain early experience in what may be technically required to implement a particular system, as well as the system’s merits. A successful prototype can be something you build in a day and throw away, if by doing so you discover that something is not worth doing or you learn something useful.
All of these may be valuable within the life span of any particular project, or you may choose to use only one variety of prototype. Deciding which to work with may include the amount of time and effort required to build the prototype vs. the desired outcome, the importance of the system being designed, and whether feedback on functionality or on layout and graphic design is desired.
Prototyping tools
You will need a basic set of tools for developing functional prototypes. Many can work with just knowledge of a web scripting language (typically one of the “Ps”: Perl, Python, or PHP). You may also want to use either indexing software such as Swish-e or a database like MySQL. Also, there are many open source content management systems such as Drupal that can make it easy to throw up a full-featured web site with very little time and energy.
No matter which variety you use, prototyping can be a useful and efficient way to explore functionality and design in the very early stages of a project. Such feedback can prevent serious and expensive course corrections later, or, more important, keep you from releasing a system that inadequately or erroneously addresses the need you sought to serve. Never underestimate the power of a prototype.
For more on the wired library, see the netConnect supplement mailed with the January, April 15, July, and October 15 issues of LJ
| LINK LIST | ||
| Drupal drupal.org |
MapReduce labs.google.com/papers/ mapreduce.html |
MySQL mysql.com |
| Paper prototyping www.uie.com/articles/ paper_prototyping |
Swish-e swish-e.org |
|
| Author Information |
| Roy Tennant (roy.tennant@ucop.edu) is User Services Architect, California Digital Library. He is author of Managing the Digital Library (Reed Business Pr., dist. by Neal-Schuman) |























