IBM introduced a CD player application designed to look like a plastic CD case. Apple introduced a multimedia player application designed to look like a handheld electronic device. Now, MoneyTree Software introduces ReadPlease 2000, the latest in the gratuitous application of inappropriate metaphors: a text-to-speech application designed to look like a Palm Pilot. What the heck is happening to the software industry?.

ReadPlease 2000, which can be downloaded from http://readplease.com, is an application designed to convert written text to human-like speech. As such it could probably be a very useful application. Unfortunately, the utility of the application is likely to be lost due to MoneyTree's slavish adherence to a meaningless metaphor.

We invite your feedback. Comments on this review can be sent to readplease@iarchitect.com.

Inducted 11-July-1999

Sigh...

In theory, an interface designer adopts a metaphor as a means of making the application easier to learn. This theory is based on the premise that the user will be able to transfer his or her knowledge of a familiar object structure to the new application. In practice however, an interface designer often adopts a metaphor as a means of expressing his or her model of how the system is organized. That the metaphor might make the application easier to use is often an after-the-fact and unsubstantiated rationalization of the design.

This is certainly the case with ReadPlease 2000. The designer took great pains to make the interface look like a hand-held PDA (Personal Data Assistant). Even the green color typical of the LED screens used in PDA's was adopted (despite the fact that the resulting color combination makes the text more difficult to read). The only PDA characteristic missing from the design is the effect of glare on the screen. All of this attention to the design of a PDA then begs the obvious question: what is it about the design of hand-held PDA's that would make it easier for computer users to use a text-to-speech synthesizer application?

The answer is of course: nothing. The typical PDA user was already a highly experienced computer-user before he or she first picked up a PDA. The typical computer-user, on the other hand, has never picked up a PDA. Thus, there is no knowledge to be transferred to the interface of one to the other. We can therefore rule out usability as a reason for adopting the PDA metaphor in this particular application. The only reason the designer adopted the PDA metaphor in this particular application was because he or she was familiar with PDA's, and felt that emulating one would make this application look "Kewl".

"Kewl", like beauty, is in the eye of the beholder, and some users will conclude that the designer has successfully achieved his or her goals. Others will conclude otherwise. I for one do not consider a primarily black interface to be attractive. I particularly do not find black text against a green background in a black window to be attractive, and I especially do not consider purple-highlighted text against a green background in a black window to be attractive. What I find least appealing of all this is that despite the fact that I have a monitor that supports 16 Million colors and an operating system that allows me to specify my color preferences, ReadPlease 2000 subjects me to the dubious aesthetic preferences of its designer.

I find that being subjected to these colors because of the designer's slavish adherence to an inappropriate design metaphor to be most unappealing. The green color of the display window was selected to emulate the green window of the PDA display. Adopting this color in ReadPlease 2000 represents one of the fundamental problems in applying real-world metaphors to the design of software: the software becomes subject to the limitations of the real-world device. The green color of the PDA display is the result of a number of compromises that necessarily had to be made in order to have an inexpensive display in an extremely restricted amount of physical space. Adopting these characteristics into desktop software designed to be displayed on a CRT monitor or Active Matrix display is nothing less than absurd, especially when one considers that the result makes the text more difficult to read, and that PDA manufacturers would kill to be able to provide the same richness that these displays allow.

At some point, the designer of ReadPlease 2000 recognized the limitation of the visual metaphor, and provided a means to change the color of the display window (a feature notably missing from the PDA on which the design is based). The green button in the lower right-hand corner of the ReadPlease 2000 interface allows the user to change the background color of the display window to one of four preselected colors (preselected, that is, by the designer). There is nothing about the button to indicate its association to the background color of the display window, and interestingly, the button is given the incorrect tooltip "Adjust Brightness". One color that the interface does not provide is the standard Windows Window Text color that the user has specified to be used system-wide to indicate that a window permits text entry. The default display of ReadPlease 2000, together with its almost invisible text cursor, is likely to inhibit new users from discovering that text can be directly entered into the window.

The provision of the green button is taken directly from the physical design of the Palm Pilot itself. This same button is provided on older PalmPilots to turn the device on and off. On newer PalmPilots, holding this button down toggles backlighting. Attempting to adapt this physical control model into a desktop software application will only lead to problems for users experienced with the actual PDAs.

This behavior is entirely inconsistent with the user's expectation of window resizing. The only reason for this inconsistency in this particular application is that the designer was mistakingly trying to protect the visual integrity of the metaphor, rather than considering the user's purpose for resizing the window.

It would appear that the designer did not want to completely waste all that space that the PDA border consumes, so he or she decided to utilize it. The border provided a convenient place for the designer to needlessly repeat the title of the application, to needlessly provide the name of the software publisher, and to needlessly provide the time of day (to the nearest second). None of these provisions adds value to the text-to-speech application; they are merely attempts to fill the space that exists only because of the designer's adherence to the PDA metaphor.

One thing that will take a bit of getting used to is the Speed control.

• it does not provide an indication of the minimum or maximum values
• it does not provide an indication of the current position relative to the minimum and maximum values
• it does not indicate the extent of movement necessary to effect a desired change
• it requires a circular movement of the mouse, something mice are particular ill-equipped to do.

Interestingly, the options dialog of the application provides slider controls to change the playback speed. Here, sliders provide a far more intuitive and usable interface in much less space than the shuttle control.

The main interface of ReadPlease 2000 also allows the user to change among four pre-selected voice configurations: Mary, Mike, Sam, and Marilyn the adult entertainment star shown here (this latter observation is merely a reflection of the image used to represent the voice, and not a reflection of the characteristics of the voice itself). The voice selection control is particularly unusable, most notably due to its built-in lag time. Two buttons are provided to allow the user to scroll through the available voices. After clicking on a button, the user must wait ten seconds before the application responds. During this time, the interface provides no indication that the application has received the input. In addition, the control provides no indication as to how many voices are available. The only way to determine the number of permissible voices from the main interface is to "scroll" through each; when it wraps around to a familiar image, the user will know that he or she has seen all of the alternatives. Moreover, each time a voice is selected, the application automatically starts to read the text in the display area, starting at the beginning for each voice selected; changing voices on the fly is not possible.

Sorry--you-have-not-selected-any-text
I-am-unable-to-read-it-to-you.

The options dialog does not provide a Close or Cancel button, and instead, only provides an OK button. If the user wants to cancel any changes he or she has made in the options dialog, the changes can only be undone by manually resetting them back to their original settings. The user must select the OK button to return to the main interface, regardless of whether or not changes have been made. Additionally, as with most of the controls in ReadPlease 2000, there is a huge delay from the time the OK button is clicked until the dialog is closed.

ReadPlease 2000's unique architecture is immediately apparent when attempting to acces its Help file. Selecting Contents from the Help menu does not open the Help file as would be expected, but instead causes the Help Tab in the Options dialog to be displayed over the main interface. At that point, the user can again ask to see the Help file, or can ask to be taken to the ReadPlease website. Note that as with the Options dialog discussion above, the size of the Help Tab in the Options dialog is dependent on the size of the main interface; if the user resized the main interface smaller, portions of the Help Tab will not be readable.