Mockery Blog

I used to have a checking account with Wells Fargo. Overall I was pretty happy with the service, locations, and website. It was a pretty good overall banking experience. There was, however, one extremely grating thing. Every time I used of of their ATMs, it started out by saying, “Welcome, Joel. Please select a language for this transaction,” and presenting options for English and Spanish.

Of course, I have no problem with them providing the option to conduct transactions in Spanish. What bothered me was that I had to tell them every time I used the ATM. Christ, they know who I am; I just put my card in the machine, and they’re addressing me by name! What are the odds I would want to change my mind and use a different language than I used last time I used the ATM? Would that ever happen?

Now, there may have been a technical reason that it wasn’t possible to save my preferred language. From a user’s perspective, though, it just doesn’t matter. It’s annoying having to answer the same question, click the same button, change the same radio button, or do anything else every single time you want to get something done.

I try to remember how irritating those ATMs were when I’m adding new functionality in Mockery. Am I asking my users to do the same thing over and over? Users tend to be less forgiving of minor annoyances when your application doesn’t spit out $20 bills.

As UI designers, we are responsible for playing nicely with the operating systems that our software runs on. While blind adherence to any rule is obviously not a good idea, uniformity gives applications greater learnability and makes users feel at home. If you’re doing something in your app differently than other apps do the same thing, you should have a good reason.

If you’re developing software that will run on multiple platforms, in most cases the technology you’re using will handle rendering controls and widgets in a platform-appropriate way. But using platform-specific design patterns is still up to you. Luckily, most major platforms provide guides for designing UIs that feel right. Here is a list of useful documentation broken out by OS.

Windows

• Windows User Experience Interaction Guidelines include sections on controls, windows, commands (by which they mean menus and toolbars), text, handling input devices, and more.
• The Aesthetics section of the above document, in particular, has some really useful information about UI layout and the graphic design side of UI.
• Microsoft’s overview of the Windows Environment will be particularly helpful for anyone who hasn’t been able to keep up with the Windows UI over the past few revisions.
• MS’s Visual Index of controls provides screenshots and brief descriptions of UI controls as they appear in the modern Aero Windows graphical theme.
• Top Guidelines Violations serves as an example of what not to do in your UI design.
• How to Design a Great User Experience offers 19 pieces of advice. I’m not certain that Microsoft is the best source for advice on creating great UIs, but they have been successful, and most of these points are fairly self-evident.

Mac OS X

• The Apple Human Interface Guidelines are the grandfather of all UI guidelines and pretty much a one-stop-shop for information of best practices in Mac OS UI development.
• The Aqua Interface deals specifically with the controls and widgets available to UI developers on the Mac.
• The Mac OS X Environment provides a run-down on the Dock, Finder, Desktop, and more Mac-specific OS-level features that may be unfamiliar to Windows-only developers or designers.
• The Design Process is a good, quick read with some good, though often obvious, advice.

Linux/Other

• The GNOME Human Interface Guidelines are similar in layout and organization to MS and Apple’s guides, but cover the GNOME desktop environment.
• The KDE User Interface Guidelines provide the same for the KDE environment.

This is not intended to be an exhaustive list of UI reference materials; rather, it is a list of official reference materials provided by platform providers. If you know of other useful platform-specific UI guideline documents, please post them in the comments.

“If I’d asked people what they wanted, they would have said a faster horse.”

- Henry Ford

I just heard that quote yesterday from a pretty smart guy, and I really like it. Some people disagree, but I couldn’t agree more. Sliced Bread Design had a great and very detailed take on it. My favorite bit from it:

So, what should Henry Ford have been asking his customers? Instead of, “What do you want?” he could have asked, “Is there anything you particularly like or don’t like about your horse and wagon?”

You can probably very easily ask someone what software they want you to build, bang out the code, and deliver exactly what they asked for. They might even be really happy with it. But if that’s all you’re doing, what separates you from everyone else? What we need to do is break down user requests into desired implementations and desired results.

Implementations are a means to an end.

Customers are not going to make clear distinctions in feature requests between desired implementations and desired outcomes. It is up to us to do make that distinction, because if we can come up with a better implementation that produces the same result, we both win. A customer may ask for a dialog, but what he/she’s really asking for is whatever that dialog lets them do.

Applying this to Henry Ford’s quote, if we had a customer ask us for a faster horse, we could simply break down the request into implementation and outcome. The desired outcome is fairly clear; get me and my stuff from point a to point b faster. The desired implementation? Some kind of rocket-powered superhorse. The outcome is what the customer is willing to pay for, though; the implementation is merely a suggestion. If you can can come up with a better implementation (and Henry Ford sure did), people will not be disappointed.

As a developer, it’s easy to become fixated on details; they’re our bread and butter. That’s why it’s important to take a step back when analyzing customer requests and remember that users have exactly the opposite fixation. They’re willing to work with just about any implementation that lets them accomplish their task. We need to give them what they really want, whether or not it’s what they asked for.

I play guitar left-handed, which is kind of a pain in the ass when it comes down to it. I can’t play anyone else’s guitar and they can’t play mine. When I go to the guitar store, there are usually only a couple of lefties and they’re usually pretty unspectacular.

Most times when I mention this to people they ask me why I didn’t just learn to play right-handed. After all, it would be my left hand that would be doing the “hard” part. And, in fact, I tried it when I was first starting. Thing was, it just felt wrong. I didn’t enjoy it until I flipped the guitar over and played it the way it felt right. Years later, I’m still happily shredding.

The suggestion to “just play right-handed” is well-meaning but wrong. There is a reason that right-handed people (almost) universally play guitar right-handed. There is a real connection between plucking and strumming and the dominant hand. It just works that way for most people. Fighting to overcome that natural tendency is not fun, and when playing music is not fun people do not learn to play. I think you’d be doing a disservice to an aspiring guitarist if you told him or her to flip the guitar over and play it the other way because that’s just the way it’s done.

Software, I think, is a lot like that. You can force people to try to accommodate your interface. If your app is important enough to them, they may even fight their way through the pain and continue to use it. But if you continually tell people to do things in a way that is uncomfortable and unintuitive for them, people who are just getting started are going to bail out and give up on you because it’s not worth the pain to them. If I ever get tempted to cut a corner UI-wise, I’m going to try to remember how it felt to try to play that right-handed guitar 15-odd years ago when I was getting started.

One of the snags I run into most often when I talk to people about Mockery is the terminology involved in designing UIs. What one person calls a mockup (or a mock-up) another person may call a prototype or a wireframe. While they all amount to more or less the same thing, here’s some clarification on how I see the terms:

A mock-up is an image of a product used to flesh out ideas and solidify the design, done (ideally) before implementation begins. It isn’t intended to work at all; it is just a representation of what the finished product should look like.

Naturally, then, some confusion comes in when the term “prototype” is used to describe a mockup. A prototype is, to my mind, a functional (albeit crude) implementation of something used to prove it can be done and to test the technology involved. The key bit is that it should work. And that’s part of the problem with prototypes: the fact that they work means that all too often the prototype becomes the release. It’s happened to me before, and it’s reason enough to

Wireframe is a term I hear used synonymously with mockup a lot; it seems that a wireframe is a very light, fast mockup without much or any visual flair.

All in all it doesn’t really matter, but I do have to explain what a mockup is more often than I would expect. Hopefully getting the word out about Mockery will help.

Anybody have any thoughts on what we should call all of this stuff?

Update: http://www.melissabernais.com/blog/wireframes-v-mock-ups-v-prototypes/ describes Melissa Bernais’s take on this really well. I agree with her on all of these; our definitions of prototype are a little different but not incompatible.

I learned about the launch of StartupToDo.com yesterday at the Joel on Software discussion boards. It seems like a smart idea.

Basically, it provides and to-do lists for software startups to follow. These are designed by experts and intended to work sort of like a paint-by-numbers for building a new software business.

It sounds really smart to me, as there are so many things that you just have to know when you get started. I think they will probably be successful.