لطفا منتظر باشید ...
A Brief History of User Interfaces
You might think that user interface design is a history of continuous innovation. In fact, user interface design is actually marked by a series of distinct eras. Typically, in each era one predominant approach develops. Then, at some unpredictable time, a lone programmer or innovative programming team creates a truly new user interface model that dazzles the world. In the months that follow, hundreds of developers rush to create similar but mutually incompatible versions. This process of false imitation continues until the next revolution.
So what are these eras of user interface development? It all began very simply.
The Command-Line Era
Almost everyone who has any experience with computers has at least glimpsed the fabled command line. Today's novice users instinctively think of it as some "back door" way of accessing features that are forbidden and hidden from most people. Even advanced computer users are sometimes bound by the superstition that a command line lurks behind the scenes in the latest Windows operating system, secretly controlling things.
A command-line interface is the power user's dream. Of course, even power users have to learn somewhere, and most forget that the command line was not an easy tool to master.
The command line is, in many respects, the original way of doing things, and it's arguable that it's not so much an interface design as a lack of any user interface, at least in the sense we use the term today. Command lines began as the basis for operating systems like DOS (see Figure 1-1) and UNIX, were the basis for early database applications like dBase, and continue to proliferate in unusual places.
Figure 1-1: The archetypal command-line interface
For example, the Visual Studio .NET interface provides a Command Window that lets you interact with the IDE or execute simple lines of code against the currently running application. Besides a few rudimentary enhancements (like auto-complete), it's still a basic command-line interface (see Figure 1-2).
Figure 1-2: The command line in Visual Studio .NET
Command-line interfaces are characterized by the following traits:
Ultimate control. Users can do anything in any order, so long as they remember the "secret codes."
Ultimate lack of structure. Users not only have to remember what to do, but what order to do it in. In DOS, just moving a file to a new directory can be an agonizing multistep operation. By default, the command line assumes that each operation is atomic, and it doesn't associate one task with another.
A "hands off" treatment of user. With a few minor exceptions, there's no helpful prompting, tips, or guidance.
No metaphors. This makes it easy to grasp the basic process (type in words, press Enter), which never changes. However, it makes it impossible to guess how to do a related task based on a previous one. (For example, if you know how to copy a file in UNIX, you still don't know how to delete it.)
Today, a command-line model could still turn up in one of your user interfaces, but it's unlikely.
The Question-Answer Model
The question answer model is one of the oldest user interface models, and it's still alive and well in the modern world. Its principles are the polar opposite of a command-line interface:
You are prompted at every step of the way. Thus, you don't need to remember what the program requires. However, you are also immediately stuck if you are missing a piece of information, as question and answer programs are usually unidirectional-if you can't move forward, you can't go anywhere.
You have no control. This can be either a blessing or a curse. If the program has an accurate idea of your needs, you are in a "benevolent dictator" scenario, which makes your life considerably less complicated. But if the program makes the wrong assumptions, you have no way to fight it.
You have ultimate guidance. Some kind of instruction is provided at each step in the process.
You still have no metaphors. Well, that's not exactly true-sometimes a superficial metaphor is used where the program invites you to imagine that a friendly guide is asking you a series of questions, and trying to do what you need.
The question-answer programming model has a valuable place in the world today, and it's seen commonly in Windows program with wizards. Wizards lead you through a set of questions, and then perform a complicated task for you.
As you've no doubt discovered, there are useful wizards (like those that set up hardware on your computer). There are also less useful wizards that seem to be more complicated, demanding, and restrictive than the program itself (like those that create documents for you in some popular graphics programs). Figure 1-3 shows the wizard Windows uses for adding new hardware.
Figure 1-3: A genuinely useful wizard
Tip
One good habit is to implement a wizard in your application only after you have created a standard Windows interface. This ensures that you don't end up inadvertently coding the application functionality inside the wizard itself, and it gives the user the maximum amount of flexibility. Some programmers even recommend leaving wizards out entirely from a first release of a new application.Question-answer programs are double-edged swords that can frustrate as much as they please. The next few sections outline a few key principles that can help you use this model.
Ask what the user can tell you
It makes sense to ask a user to tell you what company made his or her printer. However, it doesn't make sense to ask a user whether you should convert tabs to spaces for DOS print operations. Instead, just pick a suitable default. Remember, no one likes to be asked a question they can't answer. When it comes to novice computer users, they might just give up altogether, or stop reading other prompts.
Restrict it to a single task
A wizard works well for a single task that can only be accomplished in one way (like adding a printer driver). As soon as you start adding an element of variety or creativity, the wizard can't keep up. Don't think that you should be proud of a complex wizard that branches out conditionally to use different windows depending on previous user selections. All you've done is created a traditional single-screen DOS program, where tasks must be completed in separate windows and in a set order.
Beware of forcing your preferences
Every wizard has its own hard-coded patterns. The user never has a choice about what order to answer questions or supply information, and that lack of control can frustrate anyone who wants to approach the task differently. Be forewarned, especially if you are using a wizard for a complex task: you are enforcing a single way of working according to your assumptions and biases. If it doesn't match the way the majority of users want to work, it will only make them miserable.
The Menu-Driven Model
The menu-driven model is the most easily recognizable user interface model. It came to popularity with document-based programs like DOS word processors, and then took over nearly every application with the Windows operating system. It's easy to see why: menus represent an attractive compromise, allowing you to prompt users without restricting the way they work.
Commands can be performed in any order. You have the same freedom you have with the command-line interface.
Information is on the screen to prompt you. You are never left on your own, and the very grouping of elements can sometimes help you remember what you want to do. For example, if you want to change spacing in Microsoft Word you might not know it has anything to do with paragraphs, but you would be able to decide that the Format menu is probably the best place to start your exploration.
Menus are one of the dominant interface elements in Windows programming, and they allow absolutely no room for experimentation or innovation. To create a menu, you copy Microsoft Office as closely as possible, even adding a vestigial File menu when your program has nothing to do with files or documents. Similarly, you would do best to emulate basic options like Edit, View, Window, and even Tools before you start adding menus organized around program-specific concepts. You learn more about Microsoft's role in your user interface design a little later in this chapter.
The GUI Era
Shortly after the menu excitement subsided, everyone fell in love with pictures, buttons, and the worlds of the Macintosh and Microsoft Windows. The GUI era introduced an avalanche of concepts and user interface elements, several of which are often summarized with the acronym WIMP (windows, icons, mouse, and pointers). One key innovation in the GUI era was the introduction of the mouse, which provides more points of entry for interacting with an application (as in, "I want to click here"). Another change was the shift to realistic representation-for example, word processors that show a close approximation of how a printed document will look. A central idea in the GUI era was to base user interfaces on real-world metaphors. For example, if you want to delete a file, drag it to an icon that looks like a trash can because that's what you use to dispose of rubbish in the real world.
Of course, some things are much harder to convey with pictures than others (for example, no application provides an icon that accurately suggests "synchronize my email"). At the same time that the GUI era arrived, user interface design started to be treated as a genuine science.
Some of the hallmarks of GUI era include:
Visual clues. A button with a grey border seems to pop off the window-it just looks pushable.
Real-world analogies. A tabbed dialog box looks like a set of tabbed pages in a binder, Sticky-notes in Microsoft Outlook look like sticky-notes. Most contact management software tries to look like a wall calendar and an address book (see Figure 1-4 for an example). The idea is that the user already knows how to use these things in the real world.
Figure 1-4: A metaphor-based calendar and organizer
Learning can be transferrable. For example, if you learned how to delete a file, a program can provide a trash can that lets you delete a product record, and you might be able to guess how to use it instinctually based on the similarity. (Of course, metaphors enforce their own biases. Knowing how to format a paragraph won't help you format a floppy disk.)
All these points are essentially an effort to make a program so logical it's almost instinctual. The goal is for a user to require no special training, and just be able to apply assumptions garnered from other programs and the real world when learning a new application. Of course, because the focus is on the user, you need to know quite a bit about how an average user thinks before you can create the interface. This philosophy still holds today.
The GUI model provides a great deal of freedom for the developer (some might say too much freedom). In the Windows world, designing a first-rate user interface has less to do with inventing metaphors, and more to do with following established conventions.
