In the old days, programmers focused on writing the useful part of their program and then as an afterthought, they created a simple user interface for controlling that program. Because the programmers already know how to control their own program, they often create a bare-bones user interface that looks as confusing as this:

A:>

At this point, the user is supposed to know not only all possible valid commands to use, but also how to spell and use each command as well. Such bare-bones user interfaces are command-line interfaces because they force users to type in commands one line at a time.

The problem with command-line interfaces is that they're too hard to use:

Command-line interfaces made using programs too difficult for the average person, so user interfaces soon evolved from primitive command-line interfaces to simple menus that listed options for the user to choose, as shown in Figure 10-2.

To choose a command listed in a menu, you had to either press a function key (such as F3) or a unique keystroke combination (such as Ctrl+K+X). The problem with these simple menus was that they gobbled up space on-screen. The more commands a program offered, the bigger the menus got.

The solution to this problem was to organize commands in different menus that would appear only when the user needed them. Such menus typically appeared at the top of the screen and would appear when the user clicked or pulled down the menu, like pulling down a window shade, as shown in Figure 10-3.

Figure II.10-2. Early user interfaces were simple menus of keystroke combinations.

Figure II.10-3. Pull-down menus help organize commands and tuck them out of sight until needed.

The main advantages of pull-down menus are that they hide program commands until you need them, and you could choose a command from a pull-down menu by clicking it with the mouse as opposed to typing a cryptic keystroke command.

Eventually, more programs started using pull-down menus. To make using different programs even easier, programs started organizing their commands under identical pull-down menu categories.

For example, the File menu typically lists commands that manipulate your data, such as Save, Open, or Print a file. The Edit menu typically lists commands for changing your data, such as Cut, Copy, and Paste. By offering standard pull-down menus, users could figure out one program and then quickly adapt to using another program.

The next great leap forward in user interface design occurred with operating systems. In the early days of computers, most operating systems offered only command-line user interfaces, so programs had to create their own pull-down menu user interfaces themselves. Therefore, every program tends to look slightly different even if it used nearly identical pull-down menus.

To create a consistent appearance for all programs and give users the ability to run two or more programs at the same time, operating systems soon abandoned their clunky command-line user interfaces and adapted a graphical user interface (abbreviated as GUI).

An operating system's GUI offered three advantages:

Before GUI operating systems, such as Mac OS X or Microsoft Windows, two programs might both display similar pull-down menus, but one program might display it in black against a white background whereas the other program might display it in red against a blue background. Such visual differences might be functionally trivial, but the jarring visual differences could make figuring out different programs harder for many people.

By forcing all programs to look similar, GUI operating systems made figuring out programs much easier. After you knew how one program worked, you could easily switch to another one.

Unlike command-line interfaces that force users to memorize and type commands, GUI user interfaces always display commands on-screen so the user can point and click with the mouse to choose a command.

The simplest way to display a command to the user is through a button. Because buttons can take up so much space on-screen, buttons are most useful for displaying a limited number of commands to the user, such as two or three possible choices, as shown in Figure 10-4.

Figure II.10-4. Buttons can display the entire command name.

The problem with buttons is that they take up screen space, so using more than a handful of buttons can crowd the screen and confuse the user. So rather than bombard users with screens full of buttons, programs generally use buttons to offer choices that users need to make immediately.

For example, when quitting a program, the program may ask the user if she wants to save her file before quitting. So the limited number of choices are only: Don't Save, Save, and Cancel.

The most popular way for displaying multiple commands to the user is through pull-down menus. Pull-down menus organize commands into categories, such as File, Edit, Window, and Help.

Unfortunately, pull-down menus aren't easy to use when a program has hundreds of possible commands. As a result, commands often get buried within multiple pull-down menus.

To solve this problem, many programs group related commands within submenus, but now you have the problem of trying to find a command buried within a submenu, which is buried in a pull-down menu, as shown in Figure 10-5.

Because pull-down menus can get overloaded with so many commands, user interface designers started displaying commands as icons and grouping icons together in toolbars that usually appear directly underneath pull-down menus, as shown in Figure 10-6.

Figure II.10-5. Submenus reduce the number of commands in a pull-down menu but make it harder to find a command.

Figure II.10-6. Icons, organized in toolbars, allow one-click access.

The advantage of icons is that they take up much less space than buttons with command names written inside them. The disadvantage of icons is that users have no idea which icons represent which commands.

As a result, most programs display short descriptions of each icon's purpose if you move the mouse pointer over that icon. So if you move the mouse pointer over a disk icon, the program might display the word Save underneath in a little window to let you know that clicking the disk icon represents the Save command.

Another way to organize icons is in a toolbox on the side of the screen, which is popular for accessing groups of commonly used commands, as shown in Figure 10-7.

Figure II.10-7. Toolboxes provide another way to group icons for easy access.

Besides giving a program commands, users also need to give a program data to use for calculating a useful result. At the simplest level, users can just type in data they want to give the program. To accept typed-in data, user interfaces need to display a text box.

A text box is nothing more than a box for the user to click and type something in it. Text boxes are commonly used when the program needs data that can't be predicted in advance, such as asking for someone's name, as shown in Figure 10-8.

Figure II.10-8. Users can type any information inside a text box, including invalid data.

Text boxes are great for accepting any data, such as names, passwords, or search phrases, but text boxes also allow users to type in invalid data. To weed out invalid data, write extra code to verify that any information typed into a text box is actually valid.

If the type of data the user can give to the program is limited to a fixed range of choices, it's better to use one of the following user interface elements instead:

Restricting choices to one option with radio buttons

Radio buttons get their name from old car radios that let you assign a favorite radio station to a button. So rather than tune in your favorite radio station manually, you had to press in a radio button, and the radio would jump to a pre-set radio station.

User interface radio buttons work the same way. Each radio button represents one possible choice, and the user can pick only one of them, as shown in Figure 10-9.

Figure II.10-9. Radio buttons display choices, but only let you pick one option.

The main advantage of radio buttons is that they show the user all possible choices, so instead of typing in the data (and risk spelling it wrong), users can just click the radio button that represents the data they want to give a program.

Restricting choices to two or more options with check boxes

Radio buttons are useful for restricting the type of data the user can give to a program. However, if you want to display all possible choices but allow the user to choose two or more of those choices, you can use check boxes instead, as shown in Figure 10-10.

Figure II.10-10. Check boxes can display multiple choices and pick more than one option.

The drawback of both radio buttons and check boxes is that they take up space on-screen. Displaying 4 or 5 radio buttons or check boxes on-screen is reasonable, but displaying 20 or 30 radio buttons or check boxes can get cumbersome.

Displaying multiple choices in a list box or combo box

If you need to display multiple choices, you may find it easier to display all those choices in a list box. A list box can either display all choices or a limited number of choices.

If the list box is large enough, it can display all choices. If the number of options is more than the list box can display at once, the list box displays a scroll bar so users can scroll through the list of all available options, as shown in Figure 10-11.

Figure II.10-11. List boxes display a list of options.

Similar to list boxes are combo boxes, which combine the features of a text box with a list box. Like a text box, a combo box lets users type data directly into the program. Like a list box, a combo box also displays a list of options that the user can choose, as shown in Figure 10-12.

Figure II.10-12. Combo boxes let you either make a choice or type data directly.

Restricting numeric choices with a slider

If users need to give numeric data to a program, they can type the numeric values in a text box. However, if you want to restrict the range of valid numbers that the user can type in, you can use a slider.

A slider moves along a ruler, with the position of the slider determining a specific numeric value or setting, as shown in Figure 10-13. Not only can sliders limit the range of a number that users can give a program (such as from 0 to 100), but sliders can also define the increments of numeric data.

Figure II.10-13. A slider lets users visually choose a numeric value or setting by dragging a slider along a ruler.

So if a slider restricted values from 0 to 100 with increments of 0.5, that means the user could give the program numbers such as 0, 0.5, 1, 1.5, 2, 2.5, and so on.

User interfaces can show information to the user in a variety of ways, such as through text, graphics, or even sound. Typically, a user interface displays data in a window where users can manipulate that data and see their changes directly, as shown in Figure 10-14.

Figure II.10-14. A user interface displays data in a window that users can manipulate whether that data represents text, numbers, pictures, or sound.

Using any program is like talking to the computer. You first tell the computer what you want to do (start writing a letter), the computer obeys (loads your word processor) and then waits for you to do something else. You give another command to the computer (to format text you just typed), the computer obeys and then asks what to do next, and so on.

Normally when you give a command to a program, the program responds right away. However, sometimes the program asks the user for more information. For example, if you give the command to print a document, the program may want to know how many pages to print. Whenever a program needs more information to carry out a command, it displays a dialog box, as shown in Figure 10-15.

Figure II.10-15. Dialog boxes ask the user for more data before carrying out a command.

A dialog box is the computer's way of saying, "I'm trying to obey your instructions, but I'm not quite sure exactly what you want." Some common dialog boxes are used to

The Open dialog box lets you click a filename that you want to open. The Save dialog box lets you click a drive or folder where you want to store a file and then type a name for your file. The Print dialog box lets a program ask the user how many pages and copies to print as well as the page size or orientation.

One problem with designing a user interface is fitting everything in a single window. To help organize a user interface, many programs use either boxes or tabs.

Boxes draw lines around items on the user interface, such as multiple radio buttons, and visually separate items, as shown in Figure 10-16.

Figure II.10-16. Boxes draw lines to separate and organize different user interface items.

Another way to organize a user interface is to use tabs. Each tab can display entirely different user interface items (buttons, text labels, check boxes, and so on). When you click a different tab, the tab shows you different user interface items, as shown in Figure 10-17.

Figure II.10-17. Tabs let you organize and display different user interface items in the same window.

Most people find computers hard to use because the user interfaces of most programs are too confusing. Usually the problem lies with the fact that the programmers know how their program works, so they automatically assume that everyone else must also know how the program works, too. Essentially, too many programs are written by programmers for other programmers and ignore the ordinary user.

Before you design your user interface, you must determine what your users expect. A program designed for other programmers (such as a compiler or a debugger) can have a drastically different user interface than an educational program designed for 6-year-olds.

No matter who the typical user might be, the user interface's sole purpose is to communicate with the user. Just as you'd talk to a college professor differently than you'd talk to a 6-year-old child, so must you adapt a user interface to the person most likely to use your program. After you know who the user is, you'll know the best ways your user interface can "talk" to that person.

At any given time, the users should know what they can do. Unfortunately, poor user interfaces either

The command-line prompt is an example of a poor user interface that expects that the user already knows all valid commands and how to spell them. If you don't know which commands may be valid, the user interface won't help you.

Even worse than sparse user interfaces are user interfaces that show too much information, such as the pull-down menus in Figure 10-18. The program in this figure displays an Attribute submenu within the Text menu title.

Figure II.10-18. This program's pull-down menu lets you view a bunch of submenus that you can't access.

However, every option on the Attribute submenu appears dimmed, which makes the Attribute submenu useless. Why bother showing the users commands that they can't use? Not only does this frustrate the user, but the user never knows when any of the Attribute commands might appear undimmed and available for use.

A well-designed user interface should always show all possible choices and not overwhelm the users with choices they can't pick anyway.

User interfaces are meant for people to use, and it's no surprise that people make mistakes. Sometimes they type in the wrong data and sometimes they give a command that they didn't really want to give.

If you make a mistake, you should be able to

Unfortunately, too many user interfaces don't let users undo their mistakes, which can make the user anxious and timid because he's afraid that if he does something wrong, he can't ever reverse his mistake. As a result, anxious and timid users tend not to trust a program or use it to its maximum capabilities.

Even worse is when user interfaces provide cryptic feedback if the user does something wrong. Examining the error message in Figure 10-19, can you tell what you might have done wrong and what you can do in the future to make sure this error message doesn't appear again?

Figure II.10-19. A cryptic error message is meaningless and frustrating because the user never knows how to avoid this problem in the future.

Cryptic messages can make users feel as if the program is scolding them. As a result, users are less likely to enjoy using the program and probably won't take full advantage of all its features either, if they even bother using the program at all.

User interfaces should tolerate and expect that the user will make a mistake and then find a way to recover from these mistakes gracefully. This can be as simple as having the program beep if the user tries to type his name instead of his Social Security number, or having the program display a descriptive error message that not only tells users what they did wrong but also tells them what to do right.

By doing this, a user interface can give the user confidence to experiment with a program and learn its features without reading a 300-page manual. Instead, the user can gradually figure out how to use a program with the program guiding him every step of the way.

One reason why franchise restaurants are so popular is because people know what to expect when they eat there. User interfaces also need to make a great first impression on users and then remain consistent so users generally know what to expect from a program at any given time.

For example, suppose a program displays a toolbox of icons on the left side of the screen. Now what happens if the user chooses a command and suddenly the toolbox of icons either disappears or appears in another part of the screen for no apparent reason at all?

Having the user interface suddenly change its appearance or behavior while the program is running is certain to confuse and annoy users. By staying consistent in appearance and behavior, a user interface can be predictable so the user feels more comfortable using it (just as long as the user interface was designed properly in the first place).

Ultimately, the user interface must make it easy for the user to achieve a specific result from the program, whether it involves creating greeting cards, editing digital photos, or typing messages into a blog. If the user interface doesn't make the main purpose of the program clear and easy, users don't know or understand what to do.

The program in Figure 10-20 is designed to help people create stories, but rather than display its various tools for story writing, this program forces users to choose a file to open first. At this point, most users will wonder which file to choose, where to find a file, and why they need to open a file if they're using the program for the first time?

Figure II.10-20. Before you can use this program to create a story, you must choose a file first.

Rather than focus on the user's convenience, the program in Figure 10-20 focuses on the program's convenience and forces the user to make things easier for the program instead of the other way around. By not focusing on the main task (creating stories), this program forces users to work harder to use the program than they should.

After users start working with a program, they need to switch back and forth between viewing their data in different ways. For example, a Web browser lets users view Web pages (data) and new or previous Web pages easily by either typing in a new Web site address or clicking the Back and Forward buttons. By making it easy for the user to do what she wants, the user interface aids the user without drawing attention to itself.

At any given time, users should always be able to view their data in a previous state (such as seeing the preceding Web page) or view their data in a new way (such as seeing a new Web page or changing the size of text on the current Web page). By making it easy and predictable for users to manipulate data, a good user interface can make even the most complicated program simple to understand and eventually master.

There's no "perfect" user interface because every user interface must cater to different types of users. However, by following user interface design guidelines, you can make sure your program not only looks good but also helps the user get some work done with your program, which is the ultimate goal of any program.