email us call +43-1-523 35 98-0 contact GP GP designpartners GP logo
a mirror of the »interface hall« of shame by iarchitect.com this is a mirror of the »interface hall of shame« by isys information architects inc.

ReadPlease 2000

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


ReadPlease 2000

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

Dubious Color Combinations

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

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


The choice of colors used in the application is merely one artifact of relying on a real-world metaphor. An additional artifact is the impact the design has on expected system behavior. ReadPlease 2000 is presented to the user within an application window (this could be considered the PDA-in-a-box metaphor). The application window is resizable, but the user quickly realizes that the resizing of the ReadPlease 2000 window is unlike the resizing of any other window. ReadPlease 2000 utilizes proportional resizing. The user that attempts to widen the display will find that the height is increased as well. Moreover, and unlike any other application on the system, the individual screen objects within the display are resized accordingly. Thus, resizing the window to increase the amount of text visible in the display has the unexpected and unwanted effect of increasing the size of all the controls in the window. The end result is that the controls consume a huge amount of real estate, which reduces the amount of real estate available to display the text, which is the user's original purpose for resizing the window.

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.

Display Resizing

Resizing WasteThe adherence to the visual metaphor has additional screen real-estate concerns. PDA's have a border surrounding the display, so the designer of ReadPlease 2000 added a similar border. This border serves no purpose other than to maintain the visual metaphor and in so doing, needlessly consumes an inordinate amount of screen real estate. Because of the inappropriate use of proportional screen resizing, increasing the size of the display has the effect of proportionally increasing this border, resulting in an even greater waste of screen real estate.
Utilizing Wasted Space

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.


Slides ControlsThe main interface of ReadPlease 2000 allows the user to directly change various settings of the player. A slider control, for example, was appropriately chosen to allow the user to change the volume. Additionally, a slider control is provided to allow the user to change the font size of the text contained in the display area of the interface. Unfortunately, whereas the volume control responds immediately to the user's input, the font size slider has a built-in lag time, often lasting several seconds, before the control responds to user input. This lag appears to be due to some complex programming manipulations necessitated by the program's non-standard graphical architecture. While waiting for the slider thumb to catch up to the user's input, the entire interface can be clearly seen to be redrawn, perhaps several times. The appearance of the menu titles, for example, change to disabled, then return to enabled appearance. In addition, all of the text in the display area of the interface is programmatically selected when the user initiates a font-sizing operation, and remains selected after the resize is completed. This latter "feature" requires the user to specifically de-select the text after any font-sizing operation. The end result of this programmatic approach is that the font-sizing control is particularly awkward to use.

Speed Shuttle?!The main interface of ReadPlease 2000 also allows the user to change the speed of playback. Unfortunately, rather than using a slider control, the designers selected a shuttle-type control, similar to those found on high-end video equipment. The designer could not have selected a control that would be any more unusable than the shuttle control. The designer was aware that the speed control would be problematic, as indicated in the following statement in the Help file:
One thing that will take a bit of getting used to is the Speed control.
The Help file author, however, felt that the only problem was that the speed control has a built-in 3-second delay before the speed is changed. The delay is but a minor problem with the control, especially when one considers that almost all of the controls have a lag. The real problems with the speed control are that:
  • 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.


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


Menu in real-timeThe designer's aesthetic preferences extend beyond the adherence to the PDA metaphor. The menus used in ReadPlease 2000 are particularly attractive, utilizing a gradiant shaded background and colorful icons. Unfortunately, these "features" come at a huge price for the user: as tested on a Pentium 150 running Windows 95, ten seconds will pass from the time the user clicks the File menu title until the menu is displayed. In order to achieve these aesthetic features, the designer could not utilize the operating system's own menu drawing facilities. The end result is shown in the real-time animation shown here: the menus become absolutely unusable. This is an unacceptably high price to pay for aesthetics, and one that this author finds particularly unattractive.

Playing a non-selectionPerhaps due to the fact that ReadPlease 2000 utilizes non-standard menus, or because the designer was unfamiliar with rules for good GUI design, the application allows the user to select commands that do not pertain to the current situation. In this case, the context menu (dislayed when right-clicking on the text area of the display) allows the user to play the currently selected text, even when no text has been selected. We only mention this because of the rather humorous result: ReadPlease 2000 provides an audio error message to the effect that...no text has been selected:

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

Options Dialog
The architecture of ReadPlease 2000 can be downright confusing at times. The options dialog, for example, is presented within the same apparent dialog as the main interface, rather than in its own dialog as the user would expect. Unfortunately, this means that the size of the options dialog, and its readability is determined by the size of the main interface. If the user had resized the main interface to a small size, the options dialog can be nearly unreadable, thus requiring the user to resize the dialog.

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.

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

Another Help Menu
There is a good deal more that one could criticize about the ReadPlease 2000 user interface, but we hope to have illustrated the main problems with its design. It should be clearly evident that usability was not an important objective for the designer. Instead, the designer was only interested in the aesthetic appearance of the interface. If that meant that the user had to wait 10 seconds for a menu to be displayed, or if the user would be confused by the controls or the application architecture then so be it. Hopefully, more designers will recognize that the importance of the interface does not rest in its appearance but in the ease with which users can accomplish their goals. Sadly, the emphasis on making it look "kewl" to individuals without visual impairments makes the application almost completely unusable by those individuals who could most benefit from its underlying technology.

© 1996-2000 Isys Information Architects Inc. All rights reserved.

Reproduction in whole or in part in any form or medium without express written permission is prohibited.

GP designpartners provide this mirror — for educational purposes only — as the interface hall of shame is no longer maintained or available at its original home, www.iarchitect.com [a domain apparently abandoned and taken over by a search spammer ...].

you can view this file in its original layout: readplease.htm.

please drop us a line if you happen to know anything about the whereabouts of brian c hayes of isys information architects, the author of this »interface hall of shame« [and fame].