agrclassic.com

When I first posted Chapter 4 on the Web, many readers emailed me to say that tabbed dialogs are all well and fine, but they’re terrible as soon as you have more than one row of tabs. Indeed, they’re right. The  biggest problem has to do with the way multiple rows of tabs always seem to violate physics: when you  click on a tab from another row, the tabs all shuffle around like restless schoolchildren on Class Photo Day, as shown in Figures 5-6a and 5-6b.

This violation of realism is distressing enough that the designers of Microsoft’s Visual C++ IDE went to a great deal of trouble to implement scrolling tabs. These have tiny arrows to control which tabs are visible and a neat “torn tab” effect so you notice that there are tabs missing to the right (see Figure 5-7).

The real solution to this problem, I think, is to figure out why you have so many options and eliminate a whole bunch, as discussed in Chapter 3. Nobody likes a dialog with a couple dozen tabs, all with cryptic monikers full of complicated options. But if you simply must have multiple rows of tabs, at the very least, try not to make them violate physics. With today’s faster processors and graphics cards, it’s easy to create a simple animation effect so that the front batch of tabs slides down when you click on the back row. For an illustration of this, see Figures 5-8a through 5-8d.

Taken from : User Interface Design for Programmers

In Chapter 4, I talked about how nifty tabbed dialogs are. Microsoft Excel uses tabs to store multiple sheets in a workbook as shown in Figure 5-2.

Tabs are kind of small, so people don’t necessarily notice them there, but everyone knows how they are expected to work and nobody has trouble using them. For example, in Figure 5-2 it’s obvious that the “Income” sheet doesn’t live in its own file. It’s also obvious that there is no sheet called “Wombats.” And it’s obvious that the way to see the “Income” sheet is to click on the tab that says “Income.” Am I boring you with obvious facts? The great thing about metaphors is that they allow you to “borrow” a part of the user’s mental model of the nature of physical objects in the real world.

When you’re using metaphors, it’s very helpful if the computer program obeys the physical laws of the real world object. Many broken metaphors are the result of a failure to adhere to the “laws of nature,” that is, the laws of the real world object that they are emulating.

Consider the ruler in Microsoft Word for Windows—specifically, the three small doohickeys on the left side which control the left indent, the hanging indent, and the first line indent, as circled in Figure 5-3.

People find these a bit hard to use. Here’s why: if you drag the top doohickey, which represents the first line indent (as shown in Figure 5-4), only the top doohickey moves. That’s what you would expect. But if you drag the bottom doohickey, representing the overall indent, all three doohickeys move, as shown in Figure 5-5. It’s not just an inconsistency— it’s a violation of the laws of nature! In nature, things are either connected or they’re not. If I move my fork, I don’t expect the knife and spoon to move, too!

Taken from : User Interface Design for Programmers

Remember the briefcase from Windows 95? (See Figure 5-1.) That cute little icon that occupied a square inch or so on everybody’s desktop for a few years until Microsoft realized that nobody wanted one? Nobody wanted one because it was a broken metaphor. It was supposed to be a “briefcase” where you put files to take home. But when you took the files home, you still had to put them on a floppy disk. So, do you put them in the briefcase or on a floppy disk? I’m not sure. I never could get it to work.

A metaphor badly chosen is worse than no metaphor at all. Unfortunately, desktop user interface designers feel that they’re breaking some kind of law if they don’t use metaphors, so they would rather pick a wrong metaphor than go without.

When you use metaphors, try to make them behave in predictable ways like objects in the real world.Violating reality is just confusing.

What’s the purpose of a metaphor in the first place? To teach users what the program model is so that the program model and the user model come into agreement. If you use the wrong metaphor, you are actually teaching the user the wrong thing about how the program works, so you’re creating more trouble than you’re solving. There’s some historical evidence that the Windows 95 briefcase metaphor just didn’t work: later versions of Windows have tried to compensate for the bad metaphor by forcing you to read a screen full of instructions whenever you drag files into that dang doohickey.

Guess what? Nobody reads instructions. My new Cuisinart food processor must have three hundred stickers on it that say “Do Not Even Think of Operating This Device without Reading the Instructions, and That Means You!” Which, we know as anthropologists, actually means that millions of people use Cuisinarts without reading the instructions. I’ll go into that more soon. For now, I’d like to talk about broken metaphors like the briefcase and what a doggone nuisance they can be.

Taken from : User Interface Design for Programmers

A problem that seems to vex programmers (especially the ones who neglected to buy this book and read Chapter 3) is dialog boxes with just too many settings to fit on the screen. The only way to deal with this is to create a dialog that changes dynamically. For example, look closely at the Preferences dialog from Netscape Navigator shown in Figure 4-8.

Now, you and I are elite programming hackers with a lot of experience with these kinds of dialogs. So when we look at Figure 4-8, we immediately understand that choosing one of the categories from the left hand part of the screen is going to magically change which options are available on the right hand part of the screen.

For some reason, this type of indirection was incredibly logical to the programmers who designed it, but many users didn’t understand it. The problem? Well, most people are not elite programming hackers.

Most people would never guess that choosing something from the list on the left is supposed to change the contents of the dialog on the right: there’s no visual reason to think that. In fact, what most people think is that the list on the left is nothing more than another setting, and they are afraid to touch it because it seems like a pretty scary setting that they don’t understand.

When you do usability tests with dialogs like that, and you ask people to change one of the settings not actually shown on the main page (in this case, “Navigator”), you’ll find that a remarkable number of people just can’t figure out how to do it. When Microsoft did a usability test with a similar dialog from an old version of Microsoft Word, only 30% of the users succeeded at the task. A full 70% simply gave up without accomplishing the task they were given.
So, the Microsoft Word team switched to the famous tabbed dialogs like the one shown in Figure 4-9.

When they tried the tabbed dialogs in the usability lab, usability shot up from 30% to 100%. Let me tell you from experience that there are just not a whole lot of things that you can do that will improve your usability from 30% all the way to 100%.

Tabbed dialogs are a great affordance. It’s really obvious from Figure 4-9 that you have six tabs; it’s really obvious which tab you’re on, and it’s really obvious how to switch to a different tab. Given the remarkable success of this metaphor and the fact that the code for tabbed dialogs is built into modern operating systems and available practically for free, it’s a wonder you still see applications that don’t take advantage of them. These applications suffer from actual, measurable, real world usability problems because they refuse to get with the program.

Figure 4-10: The Napster 2.0 user interface has five separate screens (Chat, Library, Search, Hot List, and Transfer), and you use the buttons at the top to switch among them. This is an obvious candidate for tabs. Here’s the weird thing: the Napster code is actually using the Windows tabbed dialog control, but for some reason, it’s running in a funny mode that displays as buttons rather than tabs. So Shawn Fanning, the Napster programmer, could have literally flipped one bit to get a more usable interface.

Taken from : User Interface Design for Programmers

The Kodak engineers are just trying to persuade you to hold the camera with both hands, in a position that ensures the camera will be more stable and even keeps stray fingers from blocking the lens by mistake. All this rubber is not functional; its sole purpose is to encourage you to hold the camera correctly.

Good computer UI uses affordances, too. About ten years ago, most push buttons went “3D.” Using shades of grey, they appear to pop out of the screen. This is not just to look cool: it’s important because 3D buttons afford pushing. They look like they stick out and they look like the way to operate them is by clicking on them. Unfortunately, many Web sites these days (unaware of the value of affordances) would rather have buttons that look cool rather than buttons which look pushable; as a result, you sometimes have to hunt around to figure out where to click. Look at the very top of the E*TRADE home page shown in Figure 4-6.

On the black banner at the top, The GO and LOG ON buttons pop out and look like you can click on them. The SITE MAP and HELP buttons don’t look so clickable; in fact, they look exactly like the QUOTES label, which isn’t clickable.

About four years ago, many windows started sprouting three little ridges that look like a grip on the lower right corner (see Figure 4-7).

It looks like the kind of thing somebody would put on a slide switch to increase the friction. It affords dragging. It just begs to be dragged to stretch the window.

Taken from : User Interface Design for Programmers

Well-designed objects make it clear how they work just by looking at them. Some doors have big metal plates at arm-level. The only thing you can do to a metal plate is push it. You can’t pull it. You can’t rotate it. In the words of usability expert Donald Norman, the plate affords pushing. Other doors have big, rounded handles that just make you want to pull them. They even imply how they want you to place your hand on the handle. The handle affords pulling. It makes you want to pull it.

Other objects aren’t designed so well and you can’t tell what you’re supposed to do. The quintessential example is the CD jewel case, which requires you to place your thumbs just so and pull in a certain direction. Nothing about the design of the box would indicate how you’re supposed to open it. If you don’t know the trick, it’s very frustrating, because the box just won’t open.

The best way to create an affordance is to echo the shape of the human hand in “negative space.” Look closely at the (excellent) Kodak DC-290 digital camera, shown in Figures 4-4 and 4-5.

On the front, you can see a big rubber grip that looks like your right fingers should fit there. Even smarter, on the back in the lower left corner you can see an indent that looks uncannily like a thumbprint. When you put your left thumb there, your left index finger curls snugly on the front of the camera, between the lens and another rubber nubbin. It provides a kind of comforting feeling you haven’t felt since you sucked your thumb (and curled your index finger around your nose).

Taken from : User Interface Design for Programmers

Overview

Developing a user interface where the program model matches the user model is not easy. Sometimes, your users might not have a concrete expectation of how the program works and what it’s supposed to do. There is no user model.

When the user model is incomplete or wrong, the program can use affordances or metaphors to show the user its model.

In these cases, you are going to have to find ways to give the user clues about how something works. With graphical interfaces, a common way to solve this problem is with metaphors. But not all metaphors are created equal, and it’s important to understand why metaphors work so you know if you’ve got a good one.

The most famous metaphor is the “desktop metaphor” used in Windows and the Macintosh (see Figure 4-1). The computer screen behaves something like a real world desk. You have these little folders with little files in them, which you can drag around into trash cans, and cute little pictures of real world objects like printers. To the extent that this metaphor works, it’s because the little pictures of folders actually remind people of folders, which makes them realize that they can put documents into them.

Take a look at Figure 4-2, a screenshot from Kai’s Photo Soap. Can you guess how to zoom in?

It’s not very hard. The magnifying glass is a real world metaphor. People know what magnifying glasses do. And there’s no fear that the zoom operation is actually changing the size of the underlying image, since that’s not what magnifying glasses do.

A metaphor, even an imperfect one, works a lot better than none at all. Can you figure out how to zoom in with Microsoft Word, as shown in Figure 4-3?

Word has two tiny magnifying glasses in their interface. One of them is on the Print Preview button, which actually zooms out, and the other is on the Document Map button, whatever that is. The actual way to change the zoom level here is with the dropdown box that is currently showing “100%.” There’s no attempt at a metaphor, so it’s harder for users to guess how to zoom. This is not necessarily a bad thing; zooming is probably not important enough in a word processing application to justify as much screen space as Kai gives it. But it’s a safe bet that more Kai users will be able to zoom in than Word users.

Taken from : User Interface Design for Programmers

Every time you provide an option, you’re asking the user to make a decision. This means that they will have to stop and think. That’s not necessarily a bad thing, but in general, you should always try to minimize the number of decisions that people have to make.

This doesn’t mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their Web site will behave, or anything else that is integral to the work that the user is doing. In these areas, go crazy: it’s great to give people choices; by all means, the more the merrier.

There’s another category of choice that people seem to like: the ability to change the visual look of things without really changing the behavior. Everybody loves WinAmp skins; everybody sets their desktop background to a picture. Since the choice affects the visual look without affecting the way anything functions, and since users are completely free to ignore the choice and get their work done anyway, this is a good use of options.

Taken from : User Interface Design for Programmers

This is the kind of thing that nobody does on purpose. And there are a lot of computer users out there who can’t get themselves out of this kind of mess. Almost by definition, when you accidentally reconfigure one of the options in your program, you don’t know how to rereconfigure it. It’s sort of shocking to see how many people uninstall and then reinstall their software when things start behaving wrong, because at least they know how to do that. (They’ve learned to uninstall first, because otherwise all the broken customizations are likely to just come back).

“But wait!” you say. “It’s important to have options for advanced users who want to tweak their environments!” In reality, it’s not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don’t use one computer. I use all kinds of computers. I use other people’s computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn’t propagate, so it’s not even worth the trouble.

Most advanced users use several computers regularly; they upgrade their computer every couple of years, and they reinstall their operating system every three weeks. It’s true that the first time they realized they could completely remap the keyboard in Word, they might have changed everything around to be more to their taste. But as soon as they upgraded to Windows 95, those settings were lost. Besides, they weren’t the same at work. So eventually they just stopped reconfiguring things. I’ve asked a lot of my power user friends about this; hardly any of them do any customization other than the bare minimum necessary to make their system behave reasonably.

Taken from : User Interface Design for Programmers

The toolbar was so successful that the Excel team did field research using a special version of the software which they distributed to a few friends; this version kept statistics on what the most frequently used commands were and reported them back to Microsoft. For the next version, they added a second row of toolbar buttons, this time containing the most frequently used commands. Great.

The trouble was, they never got around to disbanding the toolbar team, who didn’t seem to know when to leave good enough alone. They wanted you to be able to customize your toolbar. They wanted you to be able to drag the toolbar anywhere on the screen. Then, they started to think about how the menu bar is really just a glorified tool-bar with words instead of icons, so they let you drag the menu bar anywhere you wanted on the screen, too. Customizability on steroids. Problem: nobody cares! I’ve never met anyone who wants their menu bar anywhere except at the top of the window. But here’s the (bad) joke: if you try to pull down the File menu and accidentally grab the menu bar a tiny bit too far to the left, you yank off the whole menu bar, dragging it to the only place you could not possibly want it to be: blocking the document you’re working on as shown in Figure 3-4.

How many times have you seen that? And once you’ve done this by mistake, it’s not clear what you did or how to fix it. So, here we have an option (moving the menu bar) that nobody wants (ok, maybe 0.1% of all humans want it) but which gets in the way for almost everybody.

One day a friend called me up. She was having trouble sending email. “Half the screen is grey,” she said.

Half the screen is grey?

It took me five minutes over the phone to figure out what had happened. She had accidentally dragged the Windows toolbar to the right side of the screen, then accidentally widened it as shown in Figure 3-5.

Taken from : User Interface Design for Programmers