Visual Elements
Some developers seem to go out of their way to make their programs difficult to read or understand. Often this is in a quest to make the program appear new, different, or, pardon the term, "cool". Novelty has its place, without it, we never would have achieved graphics interfaces. However, when applied without the aim of enhancing the user's interaction, it usually results in degradation of the interface, ranging from mild hostility toward the developer's choice of colors, for example, to eye strain and concomitant headaches from trying to read inappropriate fonts.
Last updated 19-September-1999
| Jim Brooking sent us a number of images from Popkin Software's System Architect. Two of the images illustrate a particularly unusual and particularly bad means of providing dialog resizing capability. The images are too large to include here, so we've provided a separate page to contain them. If you've ever had to struggle with how to provide resizeable dialogs, be sure to check this page out so you can avoid Popkin's technique. |
 We've come up with a new rule for program developers: You must at least LOOK at your designs before inflicting them onto your users. This image was taken from a tutorial released to members of a very large organization to instruct them in the use of a new software management system. As is clearly evident in the image, the choice of font, color, and background have made the tutorial almost completely unreadable, and therefore, absolutely useless. Try to read the text in the image, and note the intense effort required. The only excuse for such a pitiful combination of screen characteristics is that the developer never looked at his or her creation; as such, there is no excuse. |
| Berco Beute sent us this image of a dialog in Microsoft's Outlook Express Newsreader: |
| The dialog is presented when the user wants to send a message to more than one newsgroup. There is one not insubstantial problem, however, there is not enough space in the windows to show the full names of the newsgroups! A horizontal scrollbar is provided, but as is evident in the image, the scrollbar is useless. And, in typical Microsoft design style, the dialog is not resizable. The designer screwed up, the quality assurance department screwed up, and apparently, Microsoft's usability testing division screwed up by not finding such an obvious fault. |
 Leif Almberg sent us a screenshot from IBM's NetFinity, an application for supervising networks and remote computers. The screenshot was itself a huge mess of framed controls, taking up the entire screen. Because of their desire to fit everything into a single dialog, IBM's designers had to make some sacrifices. One notable example is that the designers sacrificed the user's ability to read some of the controls, such as the list of potential alert conditions, shown here. The user can scroll through the list one alert at a time, and will have to scroll both left and right to view the items. IBM would be hard-pressed to make this control any less efficient.
|
 The Regional Preferences applet in Windows95 sports a couple of features that make it difficult to for the user to see what he or she has done. In the first place, they decided to give the sample fields a disabled appearance, rather than a read-only appearance. Had they decided to use the standard text color rather than the disabled text color, the second problem might be more evident: they did not provide enough room in the fields to fully display the specified format. The sample values should have 4 digits to the right of the decimal, and the negative value should be sporting a closing parentheses. Oops! |
Users of Microsoft's Office97 products will recognize this new interface "feature". For some inexplicable reason, Microsoft has decided to add a border around menu titles when the cursor passes overhead, resulting in changing the menu title's appearance to that of a command button. Before adding this feature to your applications, bear in mind that it provides absolutely no usability benefit. It is simply an unnecessary distraction, that has the very undesirable effect of capturing the user's attention away from the task at hand.
Microsoft added the "feature" only to make their applications look different, not unlike the gradient-shaded title bars used in Office95. We can only hope that this practice is as short-lived as the gradient title bar. Our advice: don't waste your time trying to make your menu titles act like Microsoft's; your time can be better invested in improving the interface. |
 Microsoft's Access97 sports another variation on unnecessary distractions. As the cursor passes over the tabs on the main database window, the caption is displayed in a brighter color. Not unlike the dynamic borders on menu titles in Office97, the practice of dynamically changing the color of interface elements provides no benefit to the user, but has the undesirable effect of capturing his or her attention away from the task at hand. Microsoft's own uncertainty over the practice is clearly evident from the fact that they chose not to use the new technique on the command buttons on the dialog, nor did they employ the practice on other tabbed dialogs in Access97. |
 
As further evidence of Microsoft's uncertainty regarding the application of its new dynamic interface elements, one need only contrast the "Coolbars" used in Office97 applications against the "standard" toolbar used in Office97 itself. Coolbar buttons do not become buttons until the user passes the cursor over them. Toolbar buttons, as used in the Office97 toolbar, need no user intervention; they are immediately identifiable as controls. Do we detect dissention, or is it just careless design?
|
|
||||
WebZip utilizes a navigation toolbar much like that used in this particular Web site. While we can see the need for such a toolbar on a complex Web site, we think the idea is misplaced in a relatively simple desktop application (in our opinion, they were simply trying to imitate the look of a Web site, but that's another discussion altogether...).
We included this example because it illustrates two visual problems. The first is that the navigation toolbar is scrollable, but the designers essentially hid this fact from the user. The designers opted to eschew the standard scrollbar, and utilized one of their own design, one which few users would be familiar with. Here's a good rule of thumb to follow when designing your own controls: Use the controls that are provided by the operating system. The user is already familiar with them and will readily understand their purpose and rules of operation. The second reason we included this particular example became evident when we finally realized that the navigation toolbar was scrollable: WebZip provides a "Quick Start" option for new users, which uses a Wizard-style interface to explicitly describe how the program is used. Unfortunately, this option is the last item in the navigation toolbar, and is not visible until the user has stumbled upon the custom scroll control. Here's another rule of thumb: Don't hide the features that make your program usable. |
We first noticed the menu animation "feature" in Visual Basic 5.0, and could only laugh at the absurdity of it. Actually, it wasn't the actual feature itself that we found absurd, but the fact that Microsoft actually paid someone to come up with the idea, then decided to put it in all of their mainstream products (e.g., Office97).
Since the designers seem to have a great deal of time on their hands, perhaps it would be better spent increasing the usability of Microsoft products rather than providing useless gimmicks to wow their pre-teen customers. |
Certain toolbar buttons in PowerBuilder employ a rather unusual technique that we felt made the product more difficult to learn. As shown in the illustration, certain toolbar buttons have an associated drop-down control that causes a sub-toolbar to be displayed. This in itself is not particularly bad design, but we found the fact that the toolbar image itself changes to reflect the selected option caused us to forget how to get back to the original selection.
|
Once again, we have to thank the boys and girls in Redmond for conceiving of more completely useless features that can only serve to impress each other during recess. For those users that prefer to play with their software, the dockable menu in Office '97 is undoubtedly kewl! We on the other hand, prefer to work with our software.
With gimmicks like this, is it any wonder that Word now consumes 120 MegaBytes of disk space?
|
|
"consistency makes the interface familiar and predictable" (The Windows User Interface Guidelines for Software Design, Microsoft Press)
 Our hope is that most Visual Basic 5.0 developers will learn about consistency from Microsoft's Design Guidelines rather than from using Microsoft's products. The image above is a compilation of various dialogs used in the VB5 programming environment. In many parts of the program, the VB5 development team relied on Microsoft's then newly adopted practice of locating command buttons horizontally aligned in the lower right corner of the dialog boxes. Unfortunately, the developers responsible for a large number of the functions in the product were not aware of the new "standard". In addition to the various positions illustrated here, dialog boxes provided by third-party add-ons to the product (e.g., Crystal Reports) utilized even more creative locations. |
This is image selected from Compuserve's WinCim e-mail applet, and illustrates a typical problem that results when improperly using controls as indicators rather than as controls. One of the benefits of many Windows controls is that they can serve as both control and indicator. However, when the designer uses a control only as an indicator, a variety of problems are likely to result. In this case, the user is unlikely to notice that the disabled checkbox to the right of the Attach button is actually indicating that an attachment has been selected. In contrast, the Auto-File checkbox clearly indicates that a copy of the message will be automatically filed.
This theme will be repeated several times throughout the Interface Hall of Shame: If something is important enough to be displayed to the user, make sure that the user will be able to see it.The number of recipients is clearly displayed on the screen, the state of the Auto-File option is clearly displayed on the screen, but whether or not the user remembered to attach the file he or she intended to send is barely indicated. |
Visual Forms is a visual editor for creating HTML forms. It utilizes the now familiar drawing tools metaphor, but omitted some of the necessary visual clues that indicate what you are doing at a given point in time.
The most notable omission is that the program does not provide any feedback as to the drawing mode that you are in. Most applications that use this metaphor provide a modified cursor which indicates the selected tool; in Visual Forms, nothing appears to happen upon the selection of a drawing tool, that is, until you click somewhere on the design form. At that point, as shown in the illustration, a dialog window quite unexpectedly appears, rather than the image you intended to draw. Additionally, unlike most drawing applications, the drawing mode is persistent, that is, after drawing one object, you will always be in that mode until you select a different drawing tool. The persistence wouldn't be much of a problem if the cursor indicated that you were in a particular drawing mode, but without that feedback, the user is likely to inadvertently draw quite a few objects. Since the pointing cursor is exactly the same as the drawing cursor, the user is often likely to create a new object when all he or she intended was to point and select an existing object. |
This image is from the GIF Construction Set, and lists the files selected to be included in the animated image to be created. The user can add and delete files at this point in the program, but unfortunately, the designer's didn't provide enough space to read the entire file name. In this example, the files are labeled 'base9a.gif' through 'base9k.gif'.
In case you were wondering, you cannot scroll to the right; what you see is what you get. To add insult to injury, one-third of the form is taken up with the company's logo. |
Not to be outdone, Microsoft Access 2.0 decided against sizing the control to contain its data. This combo box is provided in the development environment and lists all of the subroutines and function names used in a particular form or code module. Access allows the developer to use up to 40 characters for function names, yet for some inexplicable reason, only displays the first 15 or so.
|
Our guess is that the designer of WebForms, if given his choice, would rather be in a studio painting landscapes. The overuse of 3-D effects throughout the application reminds us of the Arizona desert: wide sweeping valleys interspersed with mesas of varying heights.
In this case, the overuse of 3-D effects makes the window unnecessarily cluttered and confusing. Users will wonder if the various depths represent some sort of significance, when in fact, they merely represent the whims of the programmer. As shown with the command buttons at the bottom of the window, the misapplication of a sunken 3-D border surrounding a raised object nullifies the command button's intended border. When you find yourself about to unnecessarily clutter your windows with irrelevant visual effects, try to remember this timeless phrase: Keep it Simple Stupid. |
Microsoft Paint provides a good example of why it is important to make disabled controls appear disabled. To add text to an image in Paint, the user must first use the Text tool to define an area to receive the text. The Text function however, is not available when an image has been zoomed. Most users are unaware of this because the Text tool gives every indication that it is indeed available.
In the example illustrated here, the user is trying to add a line of text to a zoomed image of a sunset. Notice that when the Text toolbutton is clicked, it takes on a clicked appearance, but Paint rapidly reverts to the previously selected control. Thus, in attempting to add text to the image, the user inadvertently drew an irregular black line through the image. After performing such an inadvertent action, most users would assume that they did not click the text tool button. They will try clicking it again, attempt to define the text rectangle, and ... #$%#@~! - there's that darned slash again. When a tool, or a command is not available, do the user a favor by making it look unavailable. |
The Text function in Microsoft Paint demonstrates another example of mixed signals. Once you have defined the text area, you can enlarge it, but you cannot make it smaller. The cursor symbol, shown as a line with arrows to the right and left, is misleading, since it does not allow you to move to the left. We are at a loss to explain why you cannot make the area smaller, and we are particularly perplexed as to why Microsoft chose to place a "Two-Way Traffic" sign on a one-way street.
|
One aspect of Paint that can make it particularly difficult to use is that the image does not automatically scroll as you attempt to move objects beyond the current boundaries of the viewable area. As shown in the illustration, the object still appears to be moving beyond the viewable area, but since the area does not automatically scroll, the user has no idea of the object's position relative to other information in the image. When this occurs, there is nothing the user can do about this except attempt to paste it into a "safe" area, undo the paste, scroll the window to display the appropriate area, then begin the move or paste operation again. Unfortunately, if you have a particularly wide image, it may be impossible to move an object from one side of the image to the other.
|
Some of the network options in Time & Chaos must be REALLY IMPORTANT. Why else would the developers have displayed them in all uppercase? Avoiding uppercase is one of the first rules of netiquette because it is universally interpreted as shouting, and immediately indicates that the writer is either a pyramid marketer ("GET RICH REALLY QUICK!"), or a first-time user ("HOW DO I SEND A MESSAGE"). In perceptual terms, the use of all uppercase makes the information inherently difficult to read. DON'T USE IT. |
The designers of Midi Orchestrator decided to buck the industry standard of placing status messages and context-sensitive help in a status bar in the lower left corner of the screen, and decided to place them in the title bar instead. As the cursor moves over a control, a description of the control is displayed in the title bar. Midi Orchestrator is an otherwise excellent product, but it has an extremely complex display: there are 161 controls on the main window. Move the cursor more than 2 or 3 pixels, and a different message will be displayed. Make a sweeping movement with the mouse, and the title bar of this otherwise wonderful application becomes a strobe light. This type of information is best displayed using Tooltips which have a built-in delay, such that the message is displayed only after the cursor has paused over the control. They have the additional advantage of being displayed in close proximity to the control. Even then, make sure the control needs a description: displaying "Adjust channel volume" for a control labeled "Volume", and "Total Length of song" for a control labeled "Total length" does not add much to the user's understanding. Here's another rule of Windows design: the title bar is used to display the title. Status messages and context-sensitive help should be placed in the lower left corner of the screen. At least Midi Orchestrator used a different font for status messages; this, and the fact that it changes so often, distract the user's attention (painfully so) to the title bar. More typically, users don't look to the title bar for help; they've come to expect that the title bar will contain the title, and help will be displayed in the lower left corner. If you need to display status messages, display them where they will be seen. |
Hewlett-Packard writes software to support a wide variety of platforms, so we can be somewhat forgiving of their indiscretion with the placement of menu titles for Windows software. Under the Windows operating system, the Help menu should be the right-most menu title. This does not mean that it should be placed all the way to the right, as shown above. In a relatively small window, the distance is not very significant, but on a maximized window, the menu could be missed. We've included this example because we still see questions in programming forums asking how this technique is achieved in the Windows operating system. The answer: don't do it. |
The designers of IBM's RealPhone application felt that the user would benefit if the application wasn't "cluttered" with such distracting items as control labels and instructions. Instead, the designers opted for the use of so-called "Hover Help" throughout the application. (Why they didn't use the industry standard "Tooltips" is beyond us). Tooltips are a very important innovation in interface design, if used appropriately. As indicated here, IBM abused them, making them not only ineffective, but highly distracting as well. The tooltips (we cannot bring ourselves to use the term 'Hover Help') are used to compensate for the complete non-intuitiveness of the application, and as a result, provide far too much information to be effective. Worse than that, the tooltips are only displayed for approximately 3 seconds: they disappear before the user can finish reading them. RealPhone has earned a very special place in the Interface Hall of Shame. We consider it among the worst interfaces we have ever come across. Click here for more information. |
|
| This image, from Webforms, simply hurts the eyes. Labels are not aligned to the fields they are associated with, causing the eyes to zig-zag around the screen as the user attempts to locate a field of interest. The choice of color to distinguish labels from editable fields further adds to the headache. Further, placing help information (will not appear on...WHAT?) in the labels just adds to the mess. Given that their status bar is too difficult to read, they probably decided that this was probably the next best place for it. |
If you really want to make things difficult for your users, just slap a screen together without regard for order or organization. This image is taken from IBM's Aptiva Communication Center, and demonstrates to us at least, that the developers simply wanted to get the settings on the screen, rather than make it easy for people to adjust the settings. There is no flow to the screen; your eyes just jump around from place to place as your brain tries to elicit some sort of order. A well-designed screen, in stark contrast to this image, uses position, alignment, and grouping to organize the information, to provide an information flow. This not only makes it easier to locate a specific piece of information, it relieves the brain from having to subconsciously apply order. Some hints:
|
In this example, from Time & Chaos, the user might not be aware that the recessed, low-quality images to the right are actually command buttons. The curious user might find that clicking on the left image opens a File Open dialog, and the right image previews the selected wave file. If the user clicks the Preview image (we can't really call it a button) before a file has been selected, the click would have no apparent effect, leading the user to believe that the images are simply just curious images.
The best way to let your users know which aspects of your interface are controls is to make your controls look like controls. The three objects at the bottom - now they look like command buttons. |
Microsoft's Internet Explorer provides a clear example of novelty without reason. One of the reasons that graphical user interfaces are easy to learn is that the interface controls look and behave as controls; they appear as though they can be manipulated. Architects have often removed or confused such visual cues for the sake of novelty. Each of us has experienced the end result: the embarrassed glance around to make sure that we were not observed trying to push open a door that must be pulled open. Aside from the usability aspects, there are the aesthetic. Whereas the toolbars in Word or Excel, for example, could be described in engineering terms as 'sexy' or 'elegant', the toolbar in Internet Explorer could only be described as the equivalent of a torn, soiled sweatshirt. |
Visual Labels is a useful (as distinct from usable) little application that similarly indicates a disturbing trend away from direct manipulation. The labels 'Save' and 'Cancel' are indeed controls. Given their names, it's a good bet that the users will understand that clicking them will perform the respective function, but otherwise there is no other indication that they are controls: the cursor does not change when over the labels, and when clicked, there is no visual change to the label to indicate that it has been clicked. Fortunately, there are only a few commands available, otherwise the command bar would require a lot of space.
Undoubtedly, the popularity of the Internet has contributed to this trend. What developers need to realize is that basic technology of the Internet is a huge step backwards. HTML, the language of the Internet, offers the designer extremely limited control over the interface. Rather than making our desktop applications look and act like Internet Web sites, we should be trying to make the Internet more like our desktop applications. |
Here's another example of truly bad internet features making their way into desktop applications. The image is from Typograf, a shareware font-management application. The image contains only a very small portion of a form that simply lists Internet font-related sites. Interestingly, while the statements look like Internet links, the program does not provide Internet support; clicking on a blue line on the form will not take you to the listed Internet site. Even worse, the application does not allow the user to directly copy web addresses from the form; you would first have to write it down on paper, then type it into your browser.
Trying to make a desktop application look like browser can only lead to confusion. In trying to extend the misdirected browser metaphor by applying a background image, the designer intentionally makes the information more difficult to read. While you may not be consciously aware of it, your eyes are struggling to extract information from the various contrasts in the image; eventually this leads to eye strain and headaches. If the information is worth putting on the screen, make it readable. |
The 'About' window of eZip Wizard by ediSys provides a couple of very useful features: the ability to connect to their web site, and the ability to send them an e-mail directly from within the application. Unfortunately, many users will be unaware that such functionality exists. These functions are accessed not by clicking one of the seven command buttons on the form, but by clicking on the URL or e-mail address themselves. There is no visual indication that these functions exists. The designer decided to emulate the look and functionality of web-based hypertext links, but he or she forgot to include the primary affordance used in hypertext links: the cursor changes when passed over links. The cursor does not change when passed over the addresses on this form.
|
Many programmers admit to this problem in their early GUI applications. In this image, the developer has chosen to give the section labels a raised appearance. That's one way of ensuring that the user doesn't confuse them with the editable fields, but does it come as any surprise that users try to click on them?
|
Then again, some arguably experienced developers/designers continue to make a variant of the same problem. This image has been taken from the Find function of Microsoft's Exchange, a Windows95 mail application. In this case, the labels really are command buttons; the designer must have figured that using the command button as both a button and a label would conserve screen real estate. The funny thing is though, the same thought wasn't applied to the Look In field at the top of the window.
The practice of using command buttons as field labels represents particularly bad interface design. By using a single control for multiple purposes, you confuse the user and make it difficult for him or her to develop associations between the graphical objects and their functions. One additional problem is that you make keyboard access difficult, since by placing the mnemonic on the command button, there is no way to access the field it serves as a label for, without invoking the command button itself. |
 This example was taken from the installation of Drawing Board LT, a shareware CAD program. During the course of the installation, several hundred files are copied to your hard drive. Rather than indicate the progress of the entire installation, the authors decided that it was more important to indicate the installation progress of each file. The end result of this design descision is that the user has absolutely no idea as to the state of the installation. Most of the files are small (less than 10KB), causing the filename to be overwritten with such rapidity that it is impossible to read the name of the file. That's not too much of a problem, since ... well, "Who cares about the names of the files as they are installed?!" The more shameful aspect of the installation is that the fluorescent green progress meter becomes a completely useless distraction. It flickers with such rapidity that you are forced to turn your eyes away, or better yet, leave the room before installing the software. |
Here's one of those interface "features" that most users wish had never been invented. MsgBox Mayhem is a programmer's utility to help design those nasty error messages. Selecting an icon for the message causes the icon to blink - forever.
Here's a good rule of thumb to follow: . It is extremely distracting, and should only be used to draw the user's attention to the most severe conditions, such as: "Your computer is on fire". |
HTML Transit is an award-winning, very useful application that converts a number of file formats to HTML for use in web sites. When first loaded, it presents a visually pleasing interface. Unfortunately, "useful" and "visually pleasing" do not necessarily translate to "usable". One problematic aspect of the program is that it gives the appearance of a multiple-document interface (MDI) application, as indicated by the File menu, but also acts as a dialog box, as indicated by the command buttons on the main window. In all other MDI applications, when the user has selected "New" or "Open" from the File menu, the contents of the window will display the contents of the file. In HTML Transit however, selecting "Open" only gives the appearance of changing the title of the window, and selecting "New" does ... nothing. In either case, the contents of the main window does not change. The new user is likely to select "New" several times, then, after concluding that the program does not work, uninstall the program. The basic problem with the program is that it does not provide visual feedback that the operation was successful. The user must open one of the various dialog boxes associated with the command buttons (in the left column) to see the information associated with the template. Clicking any of the buttons in the right column will generate an error message unless the user has specified settings elsewhere in the program. This is an entirely confusing structure that is likely to cause InfoAccess to lose quite a few potential customers. |
The Microsoft Explorer demonstrates how inconsistent use of icons can potentially lead to problems. The toolbar icon for the Delete command appears remarkably similar to the Window Close button (in the upper right corner), and is exactly the same as the Cancel icon in the widely-used but frowned-upon Borland-style command buttons.
|
© 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: visual.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].
