What Makes a Good UI?


Many software companies spend large amounts of time and money researching the best way to design the user interfaces for their software. They use special usability labs run by ergonomic specialists. The labs are equipped with one-way mirrors and video cameras to record exactly how people use their software. Everything the users (subjects) do from what keys they press, how they use the mouse, what mistakes they make, and what confuses them is analyzed to make improvements to the UI.

You may be wondering what a software tester could possibly contribute with such a detailed and scientific process. By the time the software is specified and written, it should have the perfect UI. But, if that's the case, why are there so many VCRs blinking 12:00?

First, not every software development team designs their interface so scientifically. Many UIs are just thrown together by the programmerswho may be good at writing code, but aren't necessarily ergonomics experts. Other reasons might be that technological limitations or time constraints caused the UI to be sacrificed. As you learned in Chapter 10, "Foreign-Language Testing," the reason might be that the software wasn't properly localized. In the end, the software tester needs to assume the responsibility of testing the product's usability, and that includes its user interface.

You might not feel that you're properly trained to test a UI, but you are. Remember, you don't have to design it. You just have to pretend you're the user and find problems with it.

Here's a list of seven important traits common to a good UI. It doesn't matter if the UI is on a digital watch or is the Mac OS X interface, they all still apply.

  • Follows standards and guidelines

  • Intuitive

  • Consistent

  • Flexible

  • Comfortable

  • Correct

  • Useful

If you read a UI design book, you may also see other traits being listed as important. Most of them are inherent or follow from these seven. For example, "easy to learn" isn't listed above, but if something is intuitive and consistent, it's probably easy to learn. As a tester, if you concentrate on making sure your software's UI meets these criteria, you'll have a darn good interface. Each trait is discussed in detail in the following sections.

Follows Standards and Guidelines

The single most important user interface trait is that your software follows existing standards and guidelinesor has a really good reason not to. If your software is running on an existing platform such as Mac or Windows, the standards are set. Apple's are defined in the book Macintosh Human Interface Guidelines, published by Addison-Wesley, also available online at developer.apple.com/documentation/mac/ HIGuidelines/HIGuidelines-2.html. Microsoft's are in the book Microsoft Windows User Experience, published by Microsoft Press, with the online version at msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/welcome.asp.

Each book goes into meticulous detail about how software that runs on each platform should look and feel to the user. Everything is defined from when to use check boxes instead of an option button (when both states of the choice are clearly opposite and unambiguous) to when it's proper to use the information, warning, and critical messages as shown in Figure 11.1.

Figure 11.1. Did you ever notice that there are three different levels of messages in Windows? When and how to use each one is defined in the user interface standards for Windows.


NOTE

If you're testing software that runs on a specific platform, you need to treat the standards and guidelines for that platform as an addendum to your product's specification. Create test cases based on it just as you would from the product's spec.


These standards and guidelines were developed (hopefully) by experts in software usability. They have accounted for a great deal of formal testing, experience, and trial and error to devise rules that work well for their users. If your software strictly follows the rules, most of the other traits of a good UI will happen automatically. Not all of them will because your team may want to improvise on them a bit, or the rules may not perfectly fit with your software. In those cases, you need to really pay attention to usability issues.

It's also possible that your platform doesn't have a standard, or maybe your software is the platform. In those situations, your design team will be the ones creating the usability standards for your software. You won't be able to take for granted the rules that someone else has already figured out, and the remaining traits of a good user interface will be even more important for you to follow.

Intuitive

In 1975 the MITS (Micro Instrumentation Telemetry Systems) Altair 8800 was released as one of the first personal computers. Its user interface (see Figure 11.2) was nothing but switches and lightsnot exactly intuitive to use.

Figure 11.2. The MITS Altair 8800 and its less-than-intuitive user interface. (Photo courtesy of the Computer Museum of America, www.computer-museum.org.)


The Altair was designed for computer hobbyists, people who are a lot more forgiving of user interface issues. Today, users want much more out of their software than what the Altair 8800 provided. Everyone from grandmothers to little kids to Ph.D.s are using computers in their daily lives. The computers with the most intuitive UIs are the ones that people don't even realize they're using.

When you're testing a user interface, consider the following things and how they might apply to gauging how intuitive your software is:

  • Is the user interface clean, unobtrusive, not busy? The UI shouldn't get in the way of what you want to do. The functions you need or the response you're looking for should be obvious and be there when you expect them.

  • Is the UI organized and laid out well? Does it allow you to easily get from one function to another? Is what to do next obvious? At any point can you decide to do nothing or even back up or back out? Are your inputs acknowledged? Do the menus or windows go too deep?

  • Is there excessive functionality? Does the software attempt to do too much, either as a whole or in part? Do too many features complicate your work? Do you feel like you're getting information overload?

  • If all else fails, does the help system really help you?

Consistent

Consistency within your software and with other software is a key attribute. Users develop habits and expect that if they do something a certain way in one program, another will do the same operation the same way. Figure 11.3 shows an example of how two Windows applications, which should be following a standard, aren't consistent. In Notepad, Find is accessed through the Search menu or by pressing F3. In WordPad, a very similar program, it's accessed through the Edit menu or by pressing Ctrl+F.

Figure 11.3. Windows Notepad and WordPad are inconsistent in how the Find feature is accessed.


Inconsistencies such as this frustrate users as they move from one program to another. It's even worse if the inconsistency is within the same program. If there's a standard for your software or your platform, follow it. If not, pay particular attention to your software's features to make sure that similar operations are performed similarly. Think about a few basic items as you review your product:

  • Shortcut keys and menu selections. In a voicemail system, pressing 0, not other numbers, is almost always the "get-out" button that connects you to a real person. In Windows, pressing F1 should always get you help.

  • Terminology and naming. Are the same terms used throughout the software? Are features named consistently? For example, is Find always called Find, or is it sometimes called Search?

  • Audience. Does the software consistently talk to the same audience level? A fun greeting card program with a colorful user interface shouldn't display error messages of arcane technobabble.

  • Placement for buttons such as OK and Cancel. Did you ever notice that in Windows, OK is always on the top or left and Cancel on the right or bottom? The Mac OS places OK on the right. Keyboard equivalents to onscreen buttons should also be consistent. For example, the Esc key always does a cancel and Enter does an OK.

Flexible

Users like choicesnot too many, but enough to allow them to select what they want to do and how they want to do it. The Windows Calculator (see Figure 11.4) has two views: Standard and Scientific. Users can decide which one they need for their task or the one they're most comfortable using.

Figure 11.4. The Windows Calculator shows its flexibility by having two different views.


Of course, with flexibility comes complexity. In the Calculator example you'll have a much larger test effort than if there's just one view. The test impact of flexibility is felt most in the areas covered in Chapter 5, "Testing the Software with Blinders On," with states and with data:

  • State jumping. Flexible software provides more options and more ways to accomplish the same task. The result is additional paths among the different states of the software. Your state transition diagrams can become much more complex and you'll need to spend more time deciding which interconnecting paths should be tested.

  • State termination and skipping. This is most evident when software has power-user modes where a user who's very familiar with the software can skip numerous prompts or windows and go directly to where they want to go. A voicemail system that allows you to directly punch in your party's extension is an example. If you're testing software that allows this, you'll need to make sure that all the state variables are correctly set if all the intermediate states are skipped or terminated early.

  • Data input and output. Users want different ways to enter their data and see their results. To put text into a WordPad document, you can type it, paste it, load it from six different file formats, insert it as an object, or drag it with the mouse from another program. The Microsoft Excel spreadsheet program allows you to view your data in 14 different standard and 20 different custom graphs. Who even knew there were that many possibilities? Testing all the different ways to get data in and out of your software can very quickly increase the effort necessary and make for tough choices when creating your equivalence partitions.

Comfortable

Software should be comfortable to use. It shouldn't get in the way or make it difficult for a user to do his work. Software comfort is a pretty touchy-feely concept. Researchers have spent their careers trying to find the right formula to make software comfortable. It can be a difficult concept to quantify, but you can look for a few things that will give you a better idea of how to identify good and bad software comfort:

  • Appropriateness. Software should look and feel proper for what it's doing and who it's for. A financial business application should probably not go crazy with loud colors and sound effects. A space game, on the other hand, will have much more leeway with the rules. Software should neither be too garish nor too plain for the task it's intended to perform.

  • Error handling. A program should warn users before a critical operation and allow users to restore data lost because of a mistake. People take the Undo/Redo feature for granted today, but it wasn't long ago that these features didn't exist.

  • Performance. Being fast isn't always a good thing. More than one program has flashed error messages too quickly to read. If an operation is slow, it should at least give the user feedback on how much longer it will take and show that it's still working and hasn't frozen. Status bars, as shown in Figure 11.5, are a popular way to accomplish this.

    Figure 11.5. Status bars show how much of the work has been completed and how much is left to go.


Correct

The comfort trait is admittedly a bit fuzzy and often can be left to interpretation. Correctness, though, isn't. When you're testing for correctness, you're testing whether the UI does what it's supposed to do. Figure 11.6 is an example of a UI that isn't correct.

Figure 11.6. This software has a completely useless Abort button.


This figure shows a message box from a popular page-scanning program for Windows. The box appears when a scan is started and is supposed to provide a way for the user to stop the scan mid-process. Unfortunately, it doesn't work. Note that the cursor is an hourglass. An hourglass means (according to the Windows standard) that the software is busy and can't accept any input. Then why is the Abort button there? You can repeatedly click the Abort button during the entire scan, which can take a minute or more, and nothing happens. The scan continues uninterrupted until it completes. If clicking the Abort button with the hourglass cursor did stop the scan, would that be a bug? You bet it would!

Correctness problems such as this are usually obvious and will be found in your normal course of testing against the product specification. You should pay attention to some areas in particular, however:

  • Marketing differences. Are there extra or missing functions, or functions that perform operations different from what the marketing material says? Notice that you're not comparing the software to the specificationyou're comparing it to the sales information. They're usually different.

  • Language and spelling. Some programmers are poor spellers and writers and often create very interesting user messages. The following is an order confirmation message from a popular e-commerce websitehopefully fixed by the time you read this:

    If there are any discrepancies with the information below, please contact us immediately to ensure timely delivery of the products that you ordered.

  • Bad media. Media is any supporting icons, images, sounds, or videos that go with your software's UI. Icons should be the same size and have the same palette. Sounds should all be of the same format and sampling rate. The correct ones should be displayed when chosen from the UI.

  • WYSIWYG (what you see is what you get). Make sure that what the UI displays is really what you have. When you click the Save button, is the document onscreen exactly what's saved to disk? When you load it back, does it perfectly compare with the original? When you print it, does the output perfectly match what's previewed on the screen?

Useful

The final trait of a good user interface is whether it's useful. Remember, here you're not concerned with whether the software itself is useful, just whether the particular feature is. A popular term used in the software industry to describe unnecessary or gratuitous features is dancing bologna. Think of a sausage bouncing around on the screencompletely unnecessary!

When you're reviewing the product specification, preparing to test, or actually performing your testing, ask yourself if the features you see actually contribute to the software's value. Do they help users do what the software is intended to do? If you don't think they're necessary, do some research to find out why they're in the software. It's possible that there are reasons you're not aware of, or it could just be dancing bologna. Those superfluous features, whether they be in a solitaire program or a heart monitor are bad for the user and mean extra testing for you.



    Software Testing
    Lessons Learned in Software Testing
    ISBN: 0471081124
    EAN: 2147483647
    Year: 2005
    Pages: 233

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net