The Needs of the Users
Back in the old days of computers, there were no users. Who needed users? The only ones manly enough to approach the hallowed inner sanctum of the computing systems were the programmers. Only they touched the
Then came the '80s, with its
Greatest American Hero
-inspired attitude and its personal "personal" computers. Now there were users everywhere. They were like the Blob, only with fewer computing skills. But they were the masters because most programs were written for them. Programmers rarely used the programs they wrote; they were simply the interface between the
Users have a lot of needs, most of which can't be met by a computer. But for those that can, the needs come in five
Data and Information
Your ability to provide
is the raw information stored by your program:
When the user demands data back from the computer, you have three options.
Although the first two choices are indeed tempting, the third option is the best. And given the amount of data that your application will likely manage, you will have to dole out the interaction with it a bit at a time, and in an appropriate sequence. This is process .
Through the implementation of a valid process, you not only control the user's data, but also you control the orderly interaction with that data. Most users need to supply or retrieve only a small portion of their data at a time. But when they do, it will usually be in the context of some process. For instance, in an order-taking situation, the user (1) enters or confirms the customer's contact information, (2) enters or updates the order details, and (3) prints or
If your program
As a programmer, it is your job to make the computer, and the software that runs on it, as usable as possible. And while you may not be able to control many of the basic system features, you are the king when it comes to your own software.
The more ease and usability you design into your programs, the
Since then, I have subconsciously feared the development of programs that I felt were too large for a particular system. So when I went to work on Visual Basic, I brought to my projects some of this apprehension. I tried to make my programs easy to use, but I also held back on the number of forms I would add to my projects. It wasn't an irrational fear; the original versions of Visual Basic did impose limits on code size, the number of unique variable names, and the maximum number of forms. I once hit the limit on the number of unique variable names, but I never came close on the number of forms. Still, I held back. I was sure that if I added too many forms, my users would require medical attention for smoke inhalation.
There did come a day when I escaped my phobia of form-laden applications. And on that day, I came up with the following rules for my own programs.
These rules are generic enough to work with any type of application, and in-your-face enough to make them meaningful to us, the programmers, and to them, the users.
Microsoft constantly touts innovation , and the ability to innovate has moved software products forward at a tremendous pace. But unfortunately, users can handle only so much innovation at a time. Consider the telephone. I inherited an old oak-boxed telephone from my grandparents (see Figure 3-1).
Figure 3-1. What a great phone!
It's a fun phone and so simple to use. When you want to make a call, you pick up the handset and crank the handle on the side of the unit for about three or four seconds. When the operator comes on the line, you tell her whom you wish to call. What could be simpler? What could be more user-friendly? What could be more expensive than an operator-assisted call? But it was simple, and everyone instinctively knew how to use it.
Today's phones use buttons instead of cranks. Most of the buttons are simple digits that let you directly dial a specific phone number. But there are other
Getting back to software: Even new and innovative programs must retain some commonality with the operating system, and with other installed programs. As you speak to users about their needs and think about the great advancements in software technology you will provide, don't forget about commonality. Don't forget about one of the user's
Beyond the general user needs required of every project, there are needs specific to each project. As an application designer or software architect, this is where you
Once the users discover that you have a real interest in their needs, they may dump on you. They might start listing off a whole wish list of features, more features than they could ever use. That's okay. When they hear how much time it will take or how much it will cost to implement, they may back off of a few requests. The important thing is to document everything . Write down what the user asks for, combine it with a reasonable time schedule (always) and cost estimate (if required), and return it back to the key user for confirmation. If possible, have the user sign a document that says he agrees with the specific requirements listed in the document.
It is essential that there be
on the project design, at least for the initial phase or release. Because user's needs are so often a moving target, it is
Expert One-on-One Visual Basic 2005 Design and Development
Visual Basic 2005 Cookbook: Solutions for VB 2005 Programmers (Cookbooks (O'Reilly))
Microsoft Visual Basic 2005 Step by Step (Step by Step (Microsoft))
Beginning VB 2005 Databases: From Novice to Professional (Beginning: From Novice to Professional)