Usability Has Not Caught On
Eric Y. Theriault
November 11, 2001
Software usability has been discussed on many occasions, however, it is still being ignored.
There have been a number of books on designing user interfaces1,2. These books describe the most ridiculous examples of bad user interfaces. So ridiculous, in fact, that in many cases, it appears that these examples have been made up simply to demonstrate a point. Unfortunately, however, this is not the case.
There are several reasons why these poor designs actually make it into software. In some cases, a prototype is developed quickly to illustrate a concept, and the prototype's user interface is considered "good enough" or the time and/or resources required to make it better are simply not available. But a more common problem in this area is that developers are exposed to a significant amount of software, and developers get the feeling of being "experts." Although developers see lots of user interfaces, it does not make them experts. There are many good and poor interfaces around, but what people often forget is that a good interface in one context, is not necessarily a good interface in another context.
Why Standard Look and Feels Exist
Many people in the software industry remember the days before Microsoft Windows. The days in which a "graphical user interface" was a program that showed a menu and allowed you to select things from that menu. Following this era was a text-based graphical user interface that was similar, in some respects, to today's graphical operating systems, such as Windows, MacOS, and XWindows. The keyword in this last sentence is similar. The problem with these early interfaces is that between two applications, things that looked the same did not work the same.
Borland's products included a textual user interface that featured many of the components that are used today. One example is the difference between Borland's pulldown-menu and Microsoft's DOS's "EDIT" pulldown menu. Although they physically appear similar, one difference is that with Microsoft's tool, the ALT key works as it does with today's pulldown menus, in which it highlights the left-most item, and from this, you can use the arrow keys to use the menus. Borland's pulldown menu, on the other hand, did not highlight anything when you pressed ALT, but ALT and the pulldown menu's hotkey pressed together would. This is a minor diffe4rence in the look and feel, however, in a world were the keyboard was more significant than it is today, this difference could be significant, especially considering where other applications were completely different in this regard.
The entire premise behind the graphical user interface standards implemented in operating systems is to basically establish a common way of working, such that any user can pick up your application and use it, without wondering, for example, how the scroll bar works. In some areas, this has been successfully done, however, we are still lacking in many ways.
Skins: Good or Bad?
One fairly recently obscurity in the look and feel area has been "skins." Possibility made popular by Java's Swing library's ability to change look and feels on the fly, or perhaps by applications like Apple's QuickTime which attempt to look more as physical players in the real world, skins are starting to become a popular extension to software. The idea of skins is good, and COOPER would probably state that this allows power-users some flexibility to give your software an edge and make them feel more powerful.
A major problem with skins is that skins do not follow convention. Consider Winamp's default skin and its Play List, for example. The bar to the right has two arrows at the bottom, and the size of the bar changes per the number of songs you have added to your play list. With this definition, it appears to be a scroll bar, using the style that COOPER recommended with the arrow buttons. However, the entire bar does not work intuitively. If you click in the area bellow the current position of the bar, you would expect the software to react by scrolling down a page-worth of media, but actually, the bar goes exactly where you have clicked. To add confusion to this, the keyboard's arrow keys do not move from song to song, but rather changes the order of the song. The player's "Maximize" button is also not intuitive, especially since you cannot really see that it is not a maximize button.
Another major trend with skins is to make software look like a web browser. Consider McAfee's VirusScan 6.0, in which only the buttons appear to be clickable, although some buttons are white, others cyan, and still others are light blue. In some areas it seems familiar again, like the Scan Settings or the Drive Selector. Default buttons and things that applications generally have are completely lost. While scanning, you can click on practically anything, however, you get this little message stating that if you leave this area, the current operation will be canceled. And dragging files onto the application does nothing, no matter where you are. For scanning viruses, I find this interface completely unintuitive. Although there will be some, I do not believe that most people will actually use VirusScan unless they believe something is wrong, and this should hopefully not be so often. In light of which, the interface should allow users to quickly do what they need to do, as COOPER recommends.
Issues with Porting Software
Another aspect of look and feels and skins is software portability. Many software firms are ignoring markets other than the Windows market, or if they actually do acknowledge them, will release software that looks and feels like their Windows equivalent packages. Software for a platform should look and feel like that platform.
Metrowerk's CodeWarrior is a C++ compiler originally for MacOS only. In the last 10 years, they have expanded their market to include Windows, Solaris, Linux, and several others. My largest problem with their solution is that their IDE on Windows and Linux is exactly the same as that on MacOS. For example, the property menu does not have an OK or Cancel button. This is fairly standard on Windows; the use of the "X" in the corner is not always what you would expect, and the inability to cancel what you have done is never good. Furthermore, if you exit Metrowerk's CodeWarrior on Windows without savings, it comes up with an unfamiliar dialog box. The dialog box presents you with "Don't Save", "Save", and "Cancel" buttons. This dialog is unnatural, considering that most Windows applications will present you with a similar dialog window with a "Yes", "No", and "Cancel," however, under MacOS, the former is considered correct behaviour. The MacOS interface, in this regard, is arguably better, however, this unfamiliar dialog is always alarming.
Furthermore, Object Insight's JVision runs on Windows, Solaris, and Linux, however, the Linux version3 looks exactly like the Windows version, but this is not the only application like this. In JVision's case, it is unfortunate that I cannot use my normal Linux editor to edit code or to use the familiar middle mouse button to paste when using this application. There are many other applications that also go down this route. Arguably this is better for documentation and other developmental reasons, however, this decision impacts usability significantly.
What users expect to see
User interface design, however, does not limit itself to what users actually see. A user interface must also support what users expect to see and also things to make their usage of the application easier.
For example, let's consider the PalmOS. One reason to purchase a handheld is to be able to replace those clumsy paper notebooks that are not searchable and avoid lugging your laptop to group meetings. One thing that most people will write in their notebooks is today's date. The problem with PalmOS's Menu application is that the date is only available via a shortcut, and that is a short cut that most people do not know about4.
Different people take notes differently. Some people will jot down an agenda, and jot down notes under those. Some people use alternate colours based on some criterion or underline concepts. These abilities are completely lacking from the PalmOS medium, which therefore does not lend itself to these types of nodes.
Office meetings are generally not lengthy5, 6, and your notes should not be extremely long, however, students will probably take notes of their reading assignments. Such reading assignments can span one or more chapters, and hence logically, your notes should be together on your handheld. Well, PalmOS appears to have a length limitation of approximately 4096 characters per memo. When you attempt add more than this, it will start to beep. This may sound like a lot at the beginning, however, in my experience, some notes that I have taken have exceeded four such memos. Being a software developer myself, I fully understand where this limitation probably comes from, however, being a user, I do not understand why this limitation was not hidden from the implementation. For example, a far better implementation would have been to string pages of 4096 together until the view of the final document was formed. Ironically, if you paste7 a document larger than 4096 characters using PalmOS Desktop on Windows, the PalmOS Desktop will automagically split the document appropriately for the handheld. I wonder why a similar solution was not implemented on the handheld, which I will discuss momentarily.
PalmOS also comes with a date book, in which you can schedule a time to an event. For example, one could schedule in a meeting and the length of this meeting. The date book also allows you to add notes to these events. This ability, however, does not permit you to share these notes with your coworkers via the PalmOS's "beam" concept8, nor does it permit you to import and export documents from your memo pad, unless you copy and paste, which causes duplication. The PalmOS date book furthermore does not permit you to insert spanning events, for example, if you are traveling and wish to denote this, you will have to enter an entry for each day that you are away. This can be a rather time consuming task, especially if you travel often.
The date book does not integrate well with the rest of your applications on PalmOS. For example, the date book does not integrate with your To Do list, which can be useful in many contexts. This is, however, available in Handspring's Date Book+. It is unfortunate, however, that PalmOS does not include such a utility itself.
All default applications with PalmOS support the ability to "beam" documents to another device via the infrared port. Some add-on applications, however, are lacking support for this. For example, AvantGo is a web-browser, in which you can specify channels for it to download into your handheld, and it does not support this feature. It is rather unfortunately, considering this would be an interesting way to share your resume.
PalmOS handhelds come with a desktop application, however, in many cases, the desktop application and the handheld are different. For example, on the handheld, when you are browsing your list of memos, you can click and drag a memo to a more appropriately order. This functionality, however, is not available in any form on the desktop. Furthermore, when you add a new memo on the handheld, it will always be the last. On the desktop, the new memo is the first in the list of new memos that you have added since the last synchronization, which gives you a lot of extra work for nothing if the order is important.
Lastly, when entering information on the handheld, it is very likely to do spelling mistakes. The Graffiti language or even the keyboards available for handhelds are error prone in my experience. The Desktop, however, does not have a mechanism for dealing with this. The only way to check your spelling is to export the memo into an application, such as Microsoft Word9, and copy the memo back into the Desktop.
As another example, the Logitech Internet Navigator keyboard includes a Mute button. When pressed, the word "Mute" will appear on your screen, no matter whether the audio will be in a muted state or note. The only way to distinguish between when the volume is muted is when the "Mute" is red; When the volume is not muted, the "Mute" is displayed as green. This interface is confusing and takes a little tinkering with your keyboard before you realize what is going on. A better design would have been to have a picture of a speaker when the volume is not muted, and a picture of a speaker with an X through it when the volume is muted. This would dovetail better with Microsoft's Volume Control panel, and also address the issue of localization.
Summary
Software usability is not like most engineering areas. Desktop computers are not used for single purposes and the more that users can infer from other applications, the faster they will be able to use and understand your application. People do not like learning new things, and can feel frustrated if they do not understand it. New applications can be overwhelming, especially to people whose lives do not evolve around computers.
When designing a user interface, ensure that users can infer what any non-standard components do. If you are using skins, ensure that the software still acts the same as the same application without skins. Skins do not allow you to change the way users think it should work.
Making the application run is not the entire job of porting an application to another operating system. If you are to be successful, you must make that application native, and in these cases, it is usually best to bring in someone with significant and diverse experience with that operating system.
When introducing new products to the market, make sure that the application is configurable if it is dependent on third party applications. Make sure that you consider other uses for the application, and help simplify those activities to make the user's experience better. Be sure to use your applications as much as you can, so that you can learn potential problem areas and design workflow enhancements.
Your application must be user centric and address the users' needs. Part of the user's requirements should be the usability of the application, and this should be a priority.
[1] Johnson, Jeff. "GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers." Morgan Kaufmann Publishers, 2000.
[2] Cooper, Alan. "About Face: The Essentials of User Interface Design." Hungry Minds, Inc., 1995.
[3] I presume that the Solaris version is similar, although I have not tried it.
[5] Or so management books suggest6.
[6] Maguire, Steve. "Debugging the Development Process." Microsoft Press, 1994.
[7] This does not happen if you are typing vigorously, though.
[8] Unless you beam the entire event, which is not usually what you want to do.
[9] The desktop also does not permit you to prefer another word processor.