لطفا منتظر باشید ...
Helpful Restrictions
Most programmers fall into the category of "power users" of computer systems. It's for that reason that it sometimes comes as a bit of a surprise when programmers learn that one of the kindest things they can do for a user is to impose restrictions. To a developer, restrictions often seem to run contrary to the goal of application programming- they make a program "less able" to do things. However, when you use intelligent restrictions you may curb the overall abilities of your program, but you increase the efficiency and confidence of the average user.
Restricting the User's Ability to Make a Mistake
If you aren't careful, a great deal of code can be wasted attempting to detect and deal with errors. The problem is that once a user error has occurred, there is no elegant way to report it to the user and help the user continue. No matter how carefully worded or helpful the error message attempts to be, it's likely to make the user feel foolish, guilty, and frustrated. (In fact, usability studies show us that users will probably just click OK or Cancel as soon as the message appears to clear it from the screen, and then try the same thing over again.)
It doesn't matter whether you display this message after the user clicks the OK button or (worse yet) as soon as a field loses focus. Mentally, the user has moved on to the next task, and the error message is an interruption.
A better approach is to spend your energy preventing errors from happening in the first place. For example:
Limit the number of characters a text box can accept, and use the key press event to make sure invalid characters are ignored.
Use drop-down lists when the user is selecting one of several predefined choices.
Disable (or "grey out") invalid options. In the case of a complex application with many menu options and toolbars, you may need to centralize this task in some sort of state function or link different user interface elements. You see examples of both techniques in later chapters.
Tip
Many of these options represent a tradeoff between usability and maintainability. For example, enforcing field length restrictions in a text box can cause quite a headache if the allowed length of the underlying database field changes. A better approach may be to dynamically determine the length of the field from the database when the form first loads. This ensures that you won't need to recompile your code when the database changes, but it also forces you to write (and test) additional code.
Restricting the User's Choices
Another common myth in user interface programming is that the more advanced an application is, the more options it should provide. Some developers even believe that if you can't decide between two different ways to provide a feature, you should do both, and allow the user to choose. Unfortunately, this type of logic (deciding not to decide) is shirking your duty as a user interface designer. The end user will not have the same in-depth understanding of the application, and may not even know that a configuration option is available or how it works. Adding more options dramatically raises the number of possible problems, and guarantees a lack of consistency across different installations.
The basic rule is that if something appears more complicated, it is more complicated. Adding gratuitous options can make simple operations complicated. Think of the incredible complexity of nonconfigurable devices like a car or a microwave. If microwave users had to navigate through a series of menus that gave options about the pitch of the "food ready" beep, the intensity of the interior light, and the time display mode, the common household appliance would suddenly become much more intimidating. Even more practical enhancements, like allowing the user to fine-tune power levels, preset cooking time a day in advance, or set the platter rotation speed probably aren't worth the added complexity.
Heavily customizable applications also bury genuinely useful options in a slew of miscellaneous, less important properties. Few users dig through the whole list to find the important options-you actually reduce the usable features of an application as you add extraneous elements. Most options can either be eliminated and handled by a reasonable default, or should graduate to a prominent place where the average user can configure them. Remember that every time you give a user an option you are forcing the user to make a decision. Many users become increasingly unsettled and less confident as they pass by options that they don't understand.
Restricting the User's Imagination
If you've ever worked at a Help desk, you probably understand that the human mind thinks in terms of cause and effect. The human bias to identify underlying reasons for events is so strong that users actually invent explanations for mysterious problems or unexpected behavior with their applications, even if these explanations seem wildly fantastical to a more experienced user.
When designing a program, you need to restrict this natural tendency. Some ways you can do this include:
Give feedback for long tasks. Some possibilities include a continuously updating dialog box message, progress bar, or status bar text. When feedback isn't arriving, most users assume the program isn't working.
Show; don't tell. The average user generally views long-winded dialog boxes that explain what will happen next with mistrust. It's far better to avoid written explanations, and find another way to convey the information (or just direct the user to an important area of the screen). For example, many drawing programs now use thumbnail previews that allow users to see the result of an action before it is started.
Avoid the super-intelligent interface. People love to see the demon in the machine. Even in a painstakingly designed application like Microsoft Word, automatic features for capitalizing text and applying formatting often confound users of all levels. Don't assume your application can determine what the user intends to do. Automatic fixes and modifications are not only likely to frustrate the user by removing control, they can also insult users.
Always include a print preview. Just about every user wants to see what the finished product will look like, even when all the information is already on-screen. With .NET, it's easier than ever to create a preview that matches the pagination and formatting of the final copy.
These tips can't redeem a terrible interface. However, if used when needed, they can bridge the gap between an attractive application, and one that's truly usable.
