|
October 20, 2004
You Are Not Your Users
On the other hand, if there were a list of 30 or so entries, and users commonly would select all, then the alternatives would be to either use the ListBox and make sure users are aware of how to do the multiple selects (perhaps using a hint that shows up when the mouse hovers over the ListBox) or use the CheckBoxList and add a link to select all items. One option for ASP.NET development is a third-party component (in this case, from Meta Builders that allows you to use a DataGrid as a CheckBoxList, but with the addition of a Select All box, which is the checkbox in the header of the figure below:
If your application is important to users, even a lousy interface could become usable by a majority of them. Joel Spolsky points out that even Napster, a program that violated a number of usability standards, was once one of the most popular programs in the world. This is not an excuse to not care about usability; however, it does point out that depending upon how important your application is, you might or might not have an application fail by virtue of a bad user interface. Depending upon the number of users, the tradeoff between doing usability testing and just putting software out there and hoping for the best may lead you to usability testing. If your expected user base is 10 people, perhaps just hoping they will figure it out, or spending time helping them figure it out, might be worth it. If, however, you are rolling out an enterprise-wide application to hundreds of users, your Help Desk will thank you for making sure your application targets your users and works as they would expect.
In addition to using list boxes, here are some other things that you and I will understand but our users likely will not:
- Where processing takes place. These days, processing can take place on the client, on the server, or both. Where the processing takes place matters, because if we are processing on the server, we expect the application not to work if we are not connected. Our users will just expect the application to work.
- Modes. We understand that if we are in a disconnected mode, some things may work and some may not. While providing a "New User" mode that is easier to use and discover than the "regular" mode might be a good thing, it might confuse users who inadvertently end up in an unexpected mode.
- Installation programs. Whenever "normal folks" install a program, they expect that something bad could happen that they could not fix. For instance, my son just installed Windows XP Service Pack 2, and shortly thereafter his wireless quit. Now, he had some difficulties with his wireless a couple of months ago, and there is every possibility that the installation had nothing to do with the problem. However, it would be fruitless to try and convince him of that. Installation programs should do exactly one thing: Install the program so that the typical user can use it right away, and it must allow a reasonable way to uninstall the application. Mobile applications often miss the mark here. You install many applications from a connected PC onto a Pocket PC, yet you need to uninstall the application from both the PC and the Pocket PCsomething users do not expect.
Testing for Success!
The solution to creating usable applications is simple: Try it out on your users. Try out the entire life cycle of the application. If the application will be installed by the users, test the installation and verify that it works properly on the hardware and OS they will use. See if the options you offer are understandable to the folks installing the application. Looking at a dozen or so users, do they ever use the Custom installation options? No? Then remove the option, as you will likely confuse some users with no benefit.
What is the first user experience like? Do they seem to know exactly what to do? If the first use is difficult, but subsequent uses seem to be smooth, determine how frequently users will use your application. If it is used for filing quarterly information, ease of use is critical. If it is to be used every day, and the application is an important part of their job, then perhaps initial ease of use is not as important as ease of extended operation.
If both the hardware and software are new, there is a greater challenge. When I got my first Pocket PC, I could not find the stylus right away. I used my fingers for perhaps an hour before I saw the stylus in the antenna. Using the SIP (the simulated keyboard) was another challenge, especially when I had not perfectly aligned the touch screen. In this case, no application could overcome my lack of familiarity with the device. Still, there are special device-specific things that you can look for while using the application. If you have a large text area on a Pocket PC, is it so large that when you click on the text box, the form scrolls so that you cannot see the top of the text box and the keyboard? Do you minimize the amount of typing required?
So, while you are not your user, you can get some insights by watching them work and paying attention not only to what they say (they may want to spare your feelings) but also to what they do.
Doug Reilly runs a small consulting business, developing mobile and
Web applications (and sometimes mobile Web applications) for
organizations in the healthcare field. He can be reached at doug@accessmicrosystems.net.
Previous Page |
1
|
2
|
|