لطفا منتظر باشید ...
Handling Complexity
Some programmers (and many more management types) believe the myth that when users complain that an application is too complicated, it's because a specific feature is not prominently available. The immediate solution is often just to slap a new button somewhere that will supposedly make it quicker to access features and thus render the program easier to use. Unfortunately, life (and user interface programming) isn't that easy.
For example, consider the sample audio recorder and its "improved" version, both shown in Figure 1-6. It may be a little quicker to open and save files, but is the interface actually easier to use?
Figure 1-6: Two approaches to an audio recorder
In reality, when a user complains that an interface is confusing, it's rarely because it lacks a few quick shortcut controls or time-saving features. Rather, it's almost always a sign that the user interface is not logically organized. Adding more buttons to the audio recorder doesn't just make the interface look ugly; it also makes it seem impossibly complicated.
Segmenting Information
Deciding how to divide a product's functionality into separate applications, windows, and controls is the most important user interface decision you will make. One common pattern is to group different types of information into similar management windows. For example, a database application might have an add/remove/configure window for configuring customer records or product records. Other applications use a task-based approach, with a wizard that steps through multiple steps leading to a single goal. Before beginning an application, you should identify the most obvious logical divisions, and build your application along those lines.
Some other principles are outlined here:
Use the common Windows analogies. These are "obvious" metaphors (for example, document icons represent files) and shouldn't require any imaginative power.
Don't let metaphors take over your program. For example, you shouldn't find a cute way to reuse a metaphor when it will just make a program more confusing. (An example of this problem is the Macintosh's use of a trash can to delete files and eject floppy disks.)
Use the right controls to offload the work. Controls like the TreeView, ListView, and DataGrid can handle the basic user interface infrastructure.
Hide unnecessary information.
Appearing complex is being complex. A program appears logical when it does what the user expects. Keep this in mind, and you can create the illusion of an intuitive program.
Inductive User Interface
Microsoft has a new methodology designed to make user interfaces simpler by breaking features into individual self-explanatory windows. Each window is used for one task, rather than the common combined window that incorporates a set of tasks related to a single type of information. This type of interface, geared for the lowest (and most common) level of computer user, often combines web-style forms and requires more windows than usual. A current example of inductive user interface (IUI) design is Microsoft Money 2000.
IUI is in its infancy. No clear conventions exist, and it's fairly labor intensive to design. For most programmers it makes sense to ignore IUI until it is a better established and more conventionalized model (and one with more .NET support). You can read the initial IUI guidelines in the MSDN (online at http://msdn.microsoft.com/library/en-us/dnwindev/html/iuiguidelines.asp).
