user experience

I once saw Adam Engst, of TidBITS fame, hold a talk called Hacking the Press at the Advanced Developers’ Hands-on Conference (the first successor to MacHack). It was a great introduction to how the press works, told with the average programmer in mind, translating the life of a journalist into words we geeks can understand. I don’t remember much of it in concrete details, but whenever the topic of press releases comes up, I realize that I know much more about this stuff than by all means I should, so I guess Adam managed to insinuate himself into my brain quite well.

Recently, Nik Fletcher of Realmac software gave a great interview about press kits, press releases and related matters on the MDN Show Podcast, and I realized that all that great information that was provided there was missing one important answer that I probably first heard from Adam:

Why do I need a nice press kit?

Nik and Scotty were kinda struggling with vague benefits, like “being nice” or “convenience”. But nothing hammers home the point better than a bit of enlightened self-interest:

There are oodles of Mac applications out there. Moreover, there are tons of good ones among them. And all of them send out press releases to the same three score or so journalists who, like Adam, have pull in the Mac world. All of these applications are equally worthy of coverage. So, all those journalists are sitting there, sifting through huge piles of press releases for both bad and good applications, picking out the worthwhile ones. And once they have those, they have to go over these releases again and again, and find the ones they will finally cover in the space they have.

Some choices are obvious: If it’s a “big”, well-known product, it gets covered. If some other similar product has been in the headlines somehow, or hasn’t been in the press (or that particular publication) for a while, a product may get covered to “fill that slot”. Photoshop not done much for you lately? Great! More coverage for Pixelmator and Acorn! After all, users are still looking for good painting and retouching applications. Similarly, if a problem is on the journalist’s mind at the moment, an application that addresses this issue is more likely to be covered.

But what if you don’t fit that pattern? Well, you have to compete with the rest of the worthy apps. It’s a tough call. Now, if your application has a gorgeous press kit with beautiful screenshots/box shots/whatever of your product, and provides a lot of background information and links to relevant articles on Wikipedia etc. that the journalist can make use of for their article, that may just tip the balance in your favor.

We all know how cool it is to find a list of links and information about a particular topic: You start on one Wikipedia page on embroidering and suddenly you’ve read half the site, getting to modern computing via the Jacquard loom, and you’ve learned some interesting things in the process.

You’ve just helped the journalist find an angle that helps cover your product. They can write a witty little intro piece about embroidering, how far it’s come, and if you’re lucky they’ll say that your embroidering application is what all this has naturally led to. Even if the journalist has to truncate the article and that stuff goes away again, the journalist will remember. There’s a personal experience that now connects the journalist to your application, and helps you when it’s up against similarly worthy opponents the next time:

“Let’s see what interesting things the EmbroiderWorks press kit for their new product contains…”

Yes, I’m aware I’m illustrating the ideal, hit-the-jackpot case. But the bottom line remains: When it comes to being covered in the press, you are not just competing against similar applications, you’re also in competition with every other application out there. Many of these are as well-executed as yours.

Having a well-structured, discoverable press kit with the best user experience you can come up with, including URL clippings (.webloc) to lead them to your web site at a double-click, including spec sheets, including a collection of dictionary entries and sources for any required domain knowledge, maybe even including suggestions for articles on topics that include your application, but also others … all of that can help you get ahead of the others and turn a tie into a win.

One important aspect of interaction design is determining typical usage patterns for your application. What many people overlook here, is that these patterns don’t just happen inside your application, but may also be influenced by what happens outside, in the real world, in the user’s home. As an example, let’s take a feature that a friend of mine implemented in Toast 8:

As you are no doubt aware, Toast is a disc burning application. Most of the user interaction here is pretty straightforward: You drag files into a window, and then click a button to burn the disc. And this point is exactly where it gets complicated: when you burn a disc, your computer gets busy. Not only does it have to encode video content if you are burning a DVD, and decode the original data. After that it also has to write all that data that that was generated to a silver disc.

A lot of data is moved around during this, and you do not want to put additional strain on your machine, for fear of causing the CD drive to run out of data and creating a coaster. Of course, there is buffer underrun protection, but if your Mac starts thrashing, your backup CD could still become a coaster. So what many people do, is just leave the computer alone for a while and go to the other end of the room to do something else.

Knowing that the user does that is what gives you an opportunity to create a better user experience: Imagine the user is, for example, vacuuming the room, or cooking lunch, or reading a book. They will occasionally glance at the computer display, to determine whether disc burning has finished.

Now, today’s progress bars are roughly 16 pixels tall. Not really suitable for reading from across the room. Furthermore, when the window isn’t frontmost, progress bars actually turn a pale gray and become slightly transparent. This makes it a lot harder to read to them from a distance, since pale gray and the white of the track merge into the background. So, what my friend did for Toast, was to create a custom progress bar control that was not only bigger and had stronger colors when inactive, but also showed different colors for the different phases of progress.

This not only made it easy for the user to spot the progress bar from across the room, it also made it obvious whether Toast was currently verifying the disc, or whether it was still writing the lead-in or whether it was actually in the process of burning a particular track.

As with any custom user interface, one has to be very careful here. There is a reason why progress bars turn pale in the background: all of the user interface is designed so that color and strong lines will draw you to the current, focused window first. Since Toast actually needs color to make the current phase obvious from across the room, it was decided to not have an animation in the progress bar, which would otherwise have overwhelmed the user interface while the user is sitting in front of the machine.

From what I have heard, this feature has been welcomed by the overall user community. Many of the professional users seem to be starting a burn job on one machine and then continuing to work on another.

I recently came across a backup application that not only used a small progress bar, but also had it on a blue surface. This didn’t just interfere with the partly transparent progress bar in a background window, it also made it hard to distinguish the blue background from the blue part of the progress bar. It was hard to see where the bar started and ended, only the little white “unfinished” area was still clearly visible.

I sent the developer an e-mail with a suggestion for fixing this. If you are a developer, I encourage you to look at your progress bars. If any of them shows for a longer time, it might be a good idea to ensure that it can be read more easily from across the room. You don’t have to go as far as the Toast developers went, but simply choosing the bigger progress bar size in Interface Builder, and making sure there is enough white space around the progress bar that it can easily be spotted, and its edges can easily be made out from a distance, would already help.

A post on macSB made me stumble across a couple of nice articles on usability in open source software. They’re not only relevant to open source, but also to any other software design. Often users ask for a particular feature, and then a programmer just has to know when to say ‘no’ and when to say ‘yes, but…’

A programmer can’t just add every requested feature, and a programmer can’t just leave design up to the users. Designing software is the programmer’s job. Generally, users are exceedingly smart people, with lots of qualifications any of us can only dream of, but few of them are software engineers or user interaction designers. They needn’t be. The programmer has to accept user feedback and do some more work on it to turn it into a design that is not only possible to implement, but that also accounts for other factors the user may not have been aware of when he made the request.

But just like a typical user is not a programmer, a programmer is rarely a typical user. Some of the articles below elaborate on both of these aspects. The former is generally characterized as needing the ability (or the hierarchy, or the infrastructure) to say ‘No’, and the latter is in one of these characterized as “Designing for Aunt Tilly”. I’ll link to each article, then make a few comments. They open in a new window, so feel free to read them and then come back.

While this article is a nice, short introduction with some good examples and 5 DO’s and 5 DON’T’s, it suffers from being a little imprecise and simplifying the problem somewhat. For example, a coherent design is needed, yes, and committees sometimes have to make compromises that end up making nobody happy, true, but still I wouldn’t make a rule like “Get a benevolent dictator”.

You don’t want someone who bosses people around, even with the best intentions. Instead, you want a professional servant of the people who is so well-respected that people will just listen. You want a person with qualifications. Be it just that this person has shown before that they can design an application, be it that this person has professional credentials as a lead programmer, interaction designer, executive producer or whatever else the project might ask for at a particular time.

You need someone that people trust. But of course you also want someone who is worthy of that trust, who is willing to stand back and listen to users or contributors, and is able to see and accept what good they bring to the project, but who will then be able to make the unpopular decisions, too, and make sure they’re followed through.

My guess is that Jono DiCarlo would agree with that, and that this is what he meant by “benevolent dictator”. After all, someone may be needed as a tie-breaker, because even an arbitrary decision from a dictator (or better, arbiter or ombudsman) is better than everything stopping in its tracks because the team can’t come to a decision. But I’ve seen a project fail because its benevolent dictator decided things with the best of intentions, but just didn’t have the trust and respect needed.

As I mentioned above, most users have other qualifications than being programmers, or system administrators or whatever. They are trying to get actual work done, and our software is just a tool to do that. They don’t have fun installing it, or configuring it, or activating it on every install, or writing scripts to schedule a recording of a TV show.

They want to see a great 5-year story arc, or write a great novel, create a funny movie about comic book characters. Hence, our programs should respect and support the user, and get out of the way otherwise. The user should be free not to have to learn about network interfaces and determining the computer’s IP address just to watch a movie on their iPhone. Or, as ESR so aptly put it, the user should have the luxury of ignorance of all the hard work your program is doing behind the scenes.

Eric S. Raymond’s article has its own flaws, but John Gruber summarized them much better than I could do. Because ESR’s article proves itself: ESR is the one-eyed among the blind, just like we are as programmers: The task he’s doing, and where he demands that it be made to suit Aunt Tilly, is a task Aunt Tilly would never try to do. That doesn’t mean Eric’s point is wrong, but it shows us that we can’t rely on ourselves to assess usability for typical users. We’ll just have to remember test our designs on actual users occasionally.

Steven Garrity does a nice summary of the important points again, and adds that designing for real users is different from designing for the stereotypical “power user” or doing dumbed-down versions for some imaginary “average user”. If we design for discoverability, ease of use and ease of learning, we don’t need various “user levels” or “Advanced” areas that can be uncollapsed.

If we provide smart and sensible defaults, and keep unnecessary or conflicting options out of the UI, we can create applications that do the right thing for users just beginning to learn our programs, while once they become more comfortable with our programs, they will start looking for and discover additional options. And at this time, they will be able to also understand these options. We don’t have to design for several users at the same time, we essentially design for one user progressing through time, we design for the fourth dimension.

But this isn’t done by hiding buttons or shortening menus, this is done by hiding things in plain view, just at a little distance. The most-used, most important things are in the main window, in plain view. Some bigger, some smaller, all in an order that fits with the user’s reading order as well as with the order in which the user will probably need them (without enforcing this order, of course).

Secondary things go in popups and other menus, and things that are used rarely or not by everyone can be put in secondary windows that have to be explicitly shown, but which are obvious to a person looking for this feature (like the Apple DVD Player’s “zoom” feature, which sits in a small floating palette, and which lets you see more of your image, bigger on the screen, but with the black bars cut off).