One Size Doesn't Fit All

The photography industry is just like the software industry... Recently, a woman came up to me to ask me some questions about her camera. She noticed the Nikon D300 I was using and figured I must know something. She had just bought a Nikon D40 kit with two lenses. She was on vacation and had it shipped to her hotel, so it had literally come out of the box hours earlier. She wanted to know ...

• Why didn't it show her anything on the LCD on the back when she was taking pictures? She was trying to hold it out in front of her to take pictures.
• How did you zoom? She'd looked all over for the zoom buttons and couldn't find them. It didn't make sense to her that she would be zooming by rotating the barrel of the lens.
• When would she use the other lens that came in the kit? And, where was it? Back at her hotel, of course.

There were other things too. The kit had come with a camera bag, which was back at the hotel with the extra lens. A lot of good they were going to do her there. I gave her a bunch of tips she wasn't asking for, and, just as I was suggesting that maybe she should buy a UV filter to protect her lens, she wiped the front of the lens with her sweater. Aargh! I hinted to her that maybe she had bought the wrong camera. Maybe I was too polite.

The D40 is a great camera for its price. It's a great starter DSLR. But not for her. She didn't understand it, none of the advantages of a DSLR mattered to her, and she'd spent twice as much money on it as she would have spent if she'd bought the right camera -- like a Nikon P80 or the Canon S5, or maybe even the Canon SD850 that I got for my kids. They're all great cameras. If you read the reviews of the first two on Amazon, many of the reviewers criticize them for being what they are. They, like the D40 owner, miss an important point: the manufacturers make different models because they have different customers.

Restating the obvious, you should buy the camera that's right for you.

If you're shopping for a camera and don't know what to buy, start by making a list of the criteria that matter to you (e.g., size and weight, zoom, resolution, viewfinder, live view LCD, flip-around LCD, interchangeable lenses, controls and menus, price). Put these in order of importance. Then, rank each of the cameras that you are thinking about by each of these criteria and see which one comes out on top. You may well find that two similar cameras from different manufacturers rank at the top. Then, it's a matter of feel. Try them out. Kick the tires. See which you like better. You can't go wrong with any of the major manufacturers.

There is no "best" product.

The same thing is true in the software industry. Consumers frequently have the perception that a given product or web service is the "best" or that they think that in order to be the "best," a product has to meet everybody's needs. Marketers tend to perpetuate this myth. But it is a myth. A major difference in the software industry is that many companies only offer a single product in a given category (or only one product, period). To get a different product, you have to go to another company.

In the case of Sampa, we have a web service that allows people to easily build private, personal web sites to connect with their friends and families. It's not a floor wax or dessert topping!

If you want to socialize with strangers, go to Facebook or one of the many social networking sites. If you want to send messages to your friends every 10 minutes, go to Twitter. If you want to share all your photos and commune with thousands of other photographers, go to Flickr. If you're a business wanting a web presence to sell things online, go to Ebay, Amazon, or a multitude of other companies. There's no shame in sending a customer to another place where they'll be happier. But, if you want to build that private web site for your friends and family, go to Sampa, because that isn't what Facebook, Twitter, Flickr, etc., do.

There is no "best" product for everyone. If you're a customer, figure out what you actually want to do and pick the product that fits.

If you're a developer, find your customers and meet their needs. If you try to satisfy everyone, you'll satisfy no one.

The Not So Big ...

If you're buying or building a house, go buy this book right now: The Not So Big House by Sarah Susanka. If you're building software, I also recommend it.

  To me, there are a lot of similarities between architecture and computer science. It's hard to work in software and not have heard of Design Patterns, by the "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides), which was inspired by another architecture book: A Pattern Language by Christopher Alexander. Personally, I'm a big fan of Frank Lloyd Wright and his approach to architecture (though I wish he'd been taller). Susanka has started a whole cottage industry after the success of The Not So Big House. She has a web site, http://www.notsobighouse.com, and a number of follow-on books, including Creating the Not So Big House, Inside the Not So Big House (about details within your home), Outside the Not So Big House (about landscaping and gardens), and Not So Big Solutions for Your Home. She also wrote The Not So Big Life, a book about philosophy and and living that has received mixed reviews. Maybe she should have stuck to architecture.

But what she has to say really does resonate with software. In short, Susanka says that you should build spaces that you actually need and will use, not with spaces that you're supposed to have. Build for the way you live, not the way other people live, or the way you're supposed to live. How many houses have you been in where the owners have rooms they never use? The formal living room with furniture nobody sits in, or the formal dining room with the elegant but uncomfortable chairs that have never seen a meal, or the large, cold foyer that people walk through, or avoid completely because they're coming in the side entrance (I remember visiting one house where the front door was covered with cobwebs, it had been so long since it had been used). Build for comfort, not for scale.

To use one example that I see all the time, a large kitchen isn't better -- it's simply bigger. When we redid our kitchen, I did the design myself and I'm proud to say that four people can comfortably work in it at the same time without bumping into each other, pretty remarkable for a kitchen that is only 160 square feet (and more than a third of that space is taken up by the cabinets and appliances). It does have an adjacent eating area of another 130 square feet, but if you include that area, you can add another person or two. It is by no means what you would call a "gourmet kitchen" (no Wolf range, no Sub-Zero freezer), but we included things that made us comfortable and that we would use — my wife's top wishes were a bay window, two sinks, and a broom closet, while mine were a pizza oven and a dedicated space for rolling out pizzas. And we left out things that we didn't want. The kitchen is not organized in the classic sink-refrigerator-stove triangle (it's more like a pentagon). We have very few overhead cabinets and there's no built-in desk, despite the fact that the saleswoman selling me the cabinets really thought that we needed them. Even if you're not building (and most of us aren't), you still have a choice --it's in the way you organize the space. We didn't build our house, but we use every room in our house every day. If you can't say the same thing, reconsider how you're using your space.

Getting back to computers, if all this sounds like it's what we should do with software, it is.

• Build features that are actually needed and will get used.
• Build for the way users actually use the software, not the way we'd like them to.
• Bigger software isn't better -- it's just bigger.
• Organize what you do have in ways that make it all as usable as possible.
• If it's not working, reconsider how you're using your space.

It Just Takes One Good Way

Can't decide which way is the right way to provide access to a feature? Just support them all! We know that users have a hard time figuring some things out. It must be their fault. We also know that users, in general, don't read documentation. Obviously, that's their fault. But, if we support a lot of different ways to access the feature, surely one of them will work for users.

Take this example. How do you edit the blog post in this user interface?

Let's see. You can click on the pencil icon for the blog post ...

... or you can right-click on the blog post and choose Edit from the context menu ...


... or you could click on the blog post to select it and then click on the pencil icon on the toolbar.


Two of those three methods have an unlabeled icon for a non-standard operation (Edit), so it's just as well that there are three different methods. Oh, wait, I forgot. You can also double-click the line.

One Good Way

Instead of providing multiple not-so-great ways of editing the blog entry, why not just provide one good way?

If you provide a method which is clear and consistent, you don't need to provide alternatives. Notice I'm so confident you can find it, that I didn't even bother highlighting it like I did in the earlier examples.

Then why do we still support double-click?

Good question. We probably won't document double-click, but double-click happens to be a near-universal standard for editing. If a user does double-click the row, what would they expect to happen? Our choices are: something else, nothing, Edit. Let's take this point-by-point:

• something else - this is pretty unlikely. Double-click almost always means Edit.
• nothing - the user double-clicked. What is the chance that they did it just for fun?
  
• Edit - this is almost certainly what the user expects. Whenever possible, we should do what they expect.
  

But isn't it a good idea to provide multiple access points?

Sure, but that doesn't mean multiple ways at the same location. It means that there may be completely different places in your user interface where access to a feature makes sense. While changing this, we did add another access point -- at the blog entry itself. If you view the blog and you have permission to edit an entry, then an edit icon appears next to the title of the entry.

Notice that it's a larger icon than the ones used earlier, so as to make it stand out better. You won't see this icon on other blogs, so that helps too. If you move the mouse over it, it highlights and a tooltip appears that reads "Click to Edit this Blog Entry."

In Summary ...

The principles are simple:

• When providing access to a feature, provide a single, clear method in any given location.
  
• If users expect to get access to the feature in multiple locations in your user interface, then there's a good chance you should be meeting their expectations.
• If users expect a standard mechanism (like double-click) to work for accessing a feature, then you should probably make it work -- but don't rely on this for making the feature discoverable.
  

Avoid Too Much Salt

I watched National Treasure last night with my family. This morning, my son and I watched the DVD extras. Before the deleted scenes section, the director, Jon Turteltaub, told us that the original cut of the movie was four hours(!) long. In comparison, the final cut was just over two hours.

We all like sugar. We all like salt. But, if you have too much salt, the cake isn't going to taste good. -- Jon Turteltaub.

He explained that, individually, each of the scenes that they cut were good. He lamented that some great performances were removed, including some by actors who no longer appear in the movie. But, as a whole, all the extra scenes made the movie worse, not better. It's the same with software. It's not any good if you ship the four-hour version of your software. It's big and confusing, loaded with things that don't advance the goals of your users, which is always (always!) to accomplish their objectives, not yours.

• Cut anything that doesn't move your product in the right direction.

It's really hard to edit a movie after it's in theaters. And it's really hard to cut features after you've shipped them. You can one-up Jon Turteltaub by cutting features before you write (or shoot) them. Don't let great work end up on the cutting room floor because you weren't willing to cut features.