6.5 User-Interface Errors

 < Day Day Up > 



Anything the user can see or do with the deliverable can be classified in the User Interface domain. Kaner has broken this domain into several sections. The Project Manager and Test Manager should ask some key questions regarding each of these areas to ensure that the tests are built to adequately suit the needs of the business.

6.5.1 Functionality

  • Does the system function as advertised? There are few things more irritating to a user than to have an expectation for the application to do something and find out that it does not. Even worse, the application interface indicates that it does one thing when it actually does something else.

  • Is it proper for the task it supports? In this case, think about the old adage of using a sledge hammer to drive a needle. Does it take four menu selections to change the color of the text? If you hit the back key, does the action erase a character, a line, or a paragraph? Watch for overkill here.

  • Is there anything wrong or missing? What? There is no print feature for your Report Generation Program? Oops! You can just imagine the level of irritation that oversight would cause. Users are very unforgiving about such mistakes. Take nothing for granted when reviewing designs and imagine you are sitting in the user’s work space, trying to get your job done. Visualizing the work effort from the user’s perspective will help in catching these types of errors.

  • Does the user have to do anything extra to make it work? To print a file, imagine having to select a printer, select a paper type, select the paper tray, verify printer communications, and so on, rather than having a default printer established for all of your applications. It really used to be that way!

  • Does it do what the user expects? How many times have you heard a user state, “I thought it would do X, but when I pressed that key the program did Y,” or words to that effect? A good application should not surprise the user by doing something unexpected.

  • Is the functionality excessive or superfluous? Are there menu items in your application designed to make your name appear in sparkly text every time you see it in a report? Does the program allow users to waste time simply by trying to use features that are not listed as requirements in your project documentation? Development groups are notorious for leaving their mark on an application. Be sure this situation is brought under control quickly if you find such things occurring in your organization.

6.5.2 Communication

  • Is information missing from the system? Does the entire online help system consist of a copy of the table of contents from the cellophanewrapped user manual sitting on your desk?

  • Is online documentation available to support the application? Worse than incomplete help, having no help at all for a software deliverable can really get a user into a negative frame of mind! The first thing most of these users do is pick up the phone and burden your internal support with more work.

  • Does the product have any undocumented features? Does pressing the Ctrl-Alt-Left key sequence in your application show several animations of bears dressed as hillbillies line dancing outside their shack? Or does it show something even more ridiculous? An even worse scen-ario to consider is something like a developer adding some special reporting features to a program that users could really benefit from, but not enabling those features until a requirement is submitted asking for them. Where is the logic in that?

  • Does the program present incorrect, misleading, or confusing information? A good example here would be a menu item indicating use of a hot-key sequence. When the user presses the hot-key sequence, the menu item immediately below the one on the menu the user saw and selected is activated.

  • Is the help documentation adequate? A well-known computer manufacturer once used to brag about its product documentation being delivered in terms of linear feet of paper stacks. Can you imagine trying to find out how to do something by sifting through four linear feet of paper? Or even worse, how about having the four linear feet of documentation all being made available online, without any hyperlinks, indices, or cross-references?

  • Are there spelling or typographical errors in the online documentation? Does it make sense to you? It would be emburrassing to find such blatant errors in online documentation, wouldn’t it?

  • Are there bugs in the program display? When your mouse hovers over a command button, does the program lock up or do something unexpected? Does the text overrun the display area? Are the colors funky? All of these display issues can really undermine user satisfaction with a deliverable.

  • Is the display layout correct? Does it correspond to what the design and requirements documents have stipulated? If not, why would it be acceptable to a user? This situation is preventable. Design reviews allow the user to look at mockups of the displays and approve or disapprove before the layouts are coded.

  • Would any areas of the program be considered useless? Consider scenarios such as having an option for directing the printer output to a flatbed plotter and subsequently realizing that your company does not even own a plotter! The solution to the situation here is not to go out and buy a plotter!

  • Are the menus organized logically? They should be organized along standardized recommendations. Were they developed in a vacuum? Did the users stipulate a menu organization that defies logic? Did the developers try to implement cute menus for something different to do? Sanity checks on this before and during the coding process are advised.

  • Do the menus have adequate wording, spelling, shortcuts, and so on? An example here would be a File | Print menu option being referenced as the File | Direct output to printer/fax or some other unexpected wording.

  • Should missing commands be added? What? Are you sure you really want to save your work? After only spending two hours working on that manuscript? Sanity checks during design reviews prevent calamities such as this (it has happened before, really!).

  • Is the program too rigid? The program should not make the user feel like it is “my way or the highway” when trying to get something done. Situations like this occur as a result of bad design and should be corrected as soon as they are discovered.

  • Can the user tailor the interface? Still don’t like the funky colors? Okay. Just ensure that the user does not also encounter something like “press F6 and reboot” to change colors when he or she is trying to tailor the interface. Sometimes, programmers think very little about what a user will experience when working on a system. I have found many of these issues are resolved by having programmers occasionally work side-by-side with users in order to gain a new perspective on what it is like to actually sit down and use their work.

  • Is the tailorability too much or too little? Can I change the color of each of the 32 labels on my display to my liking? Is it really necessary for a report to contain sparkly text or marching ant borders? Sometimes, sanity checks performed in a design review will prevent the occurrence of such overkill.

  • Is command-line input supported, and, if so, is it documented? Consider the following actual output from the Microsoft Windows 2000 operating system[13], then ask yourself if a command-line sequence is absolutely necessary or not. In today’s computing environment, this type of input should be rare and used sparingly:

      COPY [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B]    [+ source [/A | /B] [+ ...]] [destination [/A | /B]]    source       Specifies the file or files to be copied.  /A           Indicates an ASCII text file.    /B           Indicates a binary file.  destination  Specifies the directory and/or filename for the new file(s)    /V           Verifies that new files are written correctly.  /N           Uses short filename, if available, when copying a file with                non-8dot3 name.    /Y           Suppresses prompting to confirm you want to overwrite an                existing destination file.  /-Y           Causes prompting to confirm you want to overwrite an                existing destination file.    /Z           Copies networked files in restartable mode.    The switch /Y may be preset in the COPYCMD environment variable.  This may be overridden with /-Y on the command line. The default is  to prompt on overwrites unless the COPY command is being executed  from within a batch script.    To append files, specify a single file for destination, but  multiple files for source (using wildcards or file1+file2+file3  format).    C:\WINNT\SYSTEM32>"/> 
  • Are command-line input sequences too complex? See the previous example once again!

  • Is the system performance acceptable? Did it take 30 seconds to change the color of each of the 32 labels? When your users save work, does it take inordinate amounts of time for them to be sure the program has saved the work? Is the system so slow that operations times are referenced by the C&D method (i.e., come back after two cups of coffee and a donut)?

  • Does the output generated by the system meet user expectations? It is sometimes difficult for a developer to understand why a senior executive does not like to read 6-point font on a 20-page report. Many developers like to work with very large monitors and often state that the report looked great when they looked at it. You get the idea. To meet user expectations, the developers should exit the trenches and go see what the user has to work with. That can often save a lot of headaches.

6.5.3 Command Structure and Entry

  • Does the program support a consistent, understandable command structure? Inconsistencies in an application lead to user frustration. This can create an unfavorable impression of the entire project effort. Be sure to validate the use of common command structures across all segments of the application and ensure that these command structures adhere to some known standards.

  • Does use of the command structure save or waste time? If it takes 11 keystrokes to execute a command on a menu, there is likely going to be great dissatisfaction among users of your product. Old mainframe applications were often composed of nested screen displays. To move from one part of the program to another meant going from screen to screen to screen until you got to where you wanted to be; however, if you knew from the first screen you wanted option 1, option 4 on the second screen, and option 7 on the third screen, the menu at the top of the first screen would allow you to type something like this: =1,4,7. The system would immediately go to the result of option 7 on the third screen. If this does not sound so hot to you, remember that back in those days, sharing time on a computer often produced quite a delay going from screen to screen. It became the de facto method of navigating mainframe menu structures because it saved time.

  • Are the menus adequate for navigation of the complete system, or are there dead-end paths from the menus? Does the menu structure have frivolous commands embedded within it? Every menu item should correspond to a destination in the program. Likewise, each destination should allow you to return to the menu that brought you to that point.

  • Is the keyboard used logically? At first glance, this may seem like a stupid question; however, consider a key sequence of Shift | Alt | $ being used to execute a report. Okay, so the report is an income statement. Get it? Income? $? Now, you know where the programmer’s head was at when this system was devised. These types of design issues can be caught and avoided in user review sessions and usability studies. Do not leave it up to the programmer to decide how or what the user should do to execute an option. Go back to the users to find out what they want. Try not to let these things slip through the test process. Great frustration and ridicule will be vented upon the project team for simple issues like this.

6.5.4 Missing Commands

  • Does the user get locked into a state where he or she cannot transition from one part of the program to another? There is nothing quite so terrible or damaging to the credibility of a development team as having a user hate your application because it sends him or her into dead zones. Always ensure bidirectional traversal in menu structures.

  • Are there means imbedded into the system to prevent disaster, and does the system support error handling by the user? An example of this would be something like printing a quarterly sales report and suddenly noticing that the printer has run out of paper. Obviously, you would hope the program would notice too, but alas, all 200 pages of your quarterly sales report must spool out before the program regains control. There was no facility in your application to stop the current print job because it was not part of the basic requirements document. Imagine how frustrating a situation like this could be to your end users, who are trying to get a report out to the Sales VP to roll up numbers for the quarter. Situations like this beg for design reviews to catch the problem before it happens. Fixing this at the time of development is trivial, but recovering from the damage that is caused by not catching it until after a user reports the problem is certainly no trivial matter. Credibility will certainly have been destroyed.

  • Are there nuisance issues to deal with? Imagine a situation where every time you wish to read that quarterly sales report on-screen you must change the background and foreground colors to make the text readable. Programmers had no requirement for setting text and background colors and sent the output to a standard display; however, on your particular monitor the colors appear funky. You can muddle through, of course, but you find it much better and easier on the eyes if you can change the colors and make the text more readable. Now, imagine a situation where there are no options in the application to allow you to change the funky colors! Additional damage to your team credibility occurs.

  • Can the user quit when he or she decides it is necessary? It is definitely hell week. You press the F3 key to return to the previous menu; however, because you could not change the funky colors on your display, you did not notice the foreground text, which was only one shade of color different from the background text—you know, that text that said press Esc to exit. You press F3 again and again. After a few minutes both you and the terminal you were working on have become unplugged!

6.5.5 Program Rigidity

  • Can the user tailor the program to suit his or her needs? Think about the funky colors again. This topic does, however, go well beyond colors. Report format changes or output customization, menu selections that are most frequently used being more accessible, selection of a different printer, and so on should all be considered before getting out of the design review.

  • Can users feel as if they are in control of the session? If the program operates such that users are made to feel as if they are on a Death March every time they try to use the system, design specifications have probably failed to achieve desired usability goals. Users are most happy when they feel as if they are masters of their universe. Ensure that you take steps to let them rule their domain by providing them with the ability to do exactly what they need and exactly what they want to enhance productivity. Look for ways to improve on existing environments or use new, standardized, time-tested interfaces that will deliver the desired results.

  • Is the system hostile to experienced users? The best example of this situation is having a user who is starting to learn a new application. The design team was thorough enough to think to include pop-up help for every option, button, and dialog that was viewed during use. This was great the first few times you used the application, but after you have seen the pop-up help shown 400 times this week after pressing the print button, I am willing to bet that you do not care to see it again—at least not today. Am I wrong?

  • Are there repetitious steps? You select a menu item from the main menu of your application. A dialog box pops up. Hit F1 to continue. Another dialog box pops up again. Hit F1 to continue again. Ad infinitum. Get on with it already!

  • Are limits imposed on the user that are unnecessary or ridiculous? You select the print option to print your report. The printer spits out page one. A dialog box pops up. Hit F1 to continue. The printer spits out page two. Another dialog box pops up again. Hit F1 to continue again. Ad infinitum. You get the idea. If not, after about the 25th page, you will.

6.5.6 Performance

  • Is the program too slow, is responsiveness sluggish, or does the program bog down and die a slow death when load is placed on the system? Performance degradation can be caused by a variety of factors. It is the design team’s responsibility to set performance standards in the design documents and the Test Team’s responsibility to check them. On new systems, this testing of performance standards usually occurs and the system often initially works with flying colors; however, after being in production for a month or so, users begin to notice wait times. Perhaps testing failed to account for the additional load placed on the database server during monthly report generation times or during the monthly close of the corporate books. This happens more often than you would think and can be prevented by taking more time in the beginning of the design phase to understand how and when the application will be used.

  • Does the application support process optimization features like type-ahead or macros? Most users salivate at the thought of having and using any type of system shortcut or time-saver they can to make their work easier. Conducting pre- and postimplementation usability studies can help ensure you have happy users on your system.

  • Is the system overloaded with graphics or features that make performance suffer? The golden rule here is to always be conscious of the time a user needs to spend in accomplishing any given task on a system. Impeding progress by throwing up multimedia that is superfluous to accomplishment of the task is almost always viewed negatively. Do not forsake completion of basic program actions in lieu of cute graphics or helpful animations. First of all, most users will readily agree that getting the desired results tops their priority list. Second, if they lose time by allowing aesthetics to hinder the delivery of their desired results, most will tell you to forego the aesthetic changes. The best course of action is to provide users with a mechanism to choose how to prioritize their time. Then, if it takes a bit longer because they like looking at a dancing dog, they will not complain about it to you.

6.5.7 Output

  • Can all desired data be output, and can the output be directed to where the user wants? Imagine how frustrating it would be to have a weekly commissions report generated, and you, as the Sales Manager, are looking to see who your top performer for the week is going to be. When the report generates, however, you find that sales representative names have been omitted from the report. A lot of good that report will do! Let’s take this a bit further and suppose that the names were present on the report. You are so pleased with the results that you want to print it out in color and include it as part of your slide deck for the weekly meeting with your VP. What? No option for printing to a color printer? This stupid program cannot do anything I want! Helpful Hint: Remember this stupid example during the design review!

  • Is the output format adherent to a standard, or is it proprietary? There are many standards out there to choose from: XML, RTF, SGML, HTML, and so on. Don’t try to create another one without ensuring that one of these will do the job for you.

  • Is the output generated appropriate for the audience? Use different report formats for various levels of the organization. Ideally, find a one-size-fits-all type of solution suitable for all audiences, but don’t get caught asking yourself if you are absolutely certain your CEO will enjoy seeing your departmental icons embedded in his or her upchannel reports. He or she will probably not want to see that kind of material in reports!

  • Can output layout be changed or controlled? In many instances, users need only a few columns of data from a report. If at all possible, design the application so users can choose which columns appear in the report and save those features to prevent having to define the same report each time they want it printed.

As you can see, there are quite a lot of factors to consider when beginning the testing process, for an application. Ideally, these considerations were first made in a design process and the Test Team is not discovering each of these examples during initial prerelease testing. If that is the case, be assured, your costs are going to skyrocket, and you will likely not hit your budget targets for this project.

So far, one of the most important points I have tried to drive home in this chapter is to make sure you and your team spend enough time during the design process to avoid these types of errors. We have only discussed User Interface type errors at this stage. Now that you know what to look for in the interface domain, let’s take a look at some other types of errors and see what else we can do to salvage our project budget.



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

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