Let's say there's a four-step process in an application. That process has been the same for years, and the steps must be processed in a very specific order. Now imagine that some usability bad ass (yes, such people exist) found a way to merge two of the steps, so that now it's only a three-step process. That'd be pretty cool, right? That person could rightly expect to be showered with rose petals, caviar, and really nice socks. Well, just recently, I've noticed a change like this; in the event no one else does, here are your virtual rose petals, caviar, and really nice songs, Mr. or Mrs. Usability Guru.
Here's the situation. At the ATM by my house, the machine always prompts you to select a language before you can do anything else. You select a language, enter your PIN, select the type of transaction, and enter the amount. That's the way it works; that's the way lots of ATMs work. Well, it seems completely obvious now, but what some smart soul did was to streamline the language selection/PIN entering steps.
Instead of asking the user to select a language, processing the choice, and then asking the user to enter the PIN, now it only asks you for your PIN. But the smart part is, it does it in two different languages. When you first roll up to the machine, it says "Please enter your PIN," and then right underneath, it says the same thing but in Spanish. Each language has its own button for you to click once you're done. Depending on which one you click, not only does the machine know your PIN, but it now knows the language you wish to read. Pretty cool stuff.
This impresses me because ATMs are a really well-known problem space. Certain steps must be done in a certain order, and there's not a lot of room for UI advancements. Well, someone at Bank of America (or some other place, perhaps) figured out. Get your freak on, ATM usability personnel!
Either the UI world is passing me by, or I'm just beginning to understand the boundless nature of my own stupidity. I'll wager on a little bit of both. I make that point because I realized today that what I thought was a universal standard amongst end-user applications is not a standard at all. In fact, it's a tangled mess of gobbledy-gook. Okay, you're dying from anticipation: what on earth am I speaking of? Well, only the most exciting feature of any application, the keyboard shortcuts.
Programming is maybe the laziest job in the world. I don't know of any good ways to compare laziness across professions, but I think on one point alone, we take the cake: programmers are so lazy, sometimes it's too much work to even use the mouse. "What, you mean I'm supposed to move my right hand 3 inches to the right, click something, and then move it back to the keyboard? What is this, a prison camp?!" (I can say all of this because I'm far worse about it than most.) For years now, application developers have recognized this laziness and actively encouraged it through the use of keyboard shortcuts.
The way I thought keyboard shortcuts worked was that when you opened up an application, the menu bar at the top became populated with a grouping of menu items. In each menu item, a letter would be underlined; this underlined letter informed the user which key could be hit in combination with the Alt key in order to access that menu item. If you see the F is underlined in File, then you recognize that Alt+F activates the File menu. I just assumed that's how all applications worked.
And then today, while using Visual SourceSafe, I realized that I was far too busy to move my hand the few centimeters' distance to the mouse; I needed to start using the shortcuts. I looked up at the menu, and to my shock, I saw that nothing at all was underlined. What the heck? What happened to shortcuts? For the love of God, who will think of the lazy, unkempt superdorks? I got so riled up, I stormed out of work, in search of an inhaler and a bottle of tequila.
I do battle with SourceSafe a lot, and I just assumed this was another of its faulty points. I even got a post started on it and how crazy it was that SourceSafe didn't adhere to general usability guidelines like underlining the keyboard shortcuts in a menu. I was on a roll, let me tell you. Just at that point, I noticed something unpleasant: Internet Explorer didn't have its shortcuts underlined by default either. In both cases, you have to first hit the Alt key in order to view the shortcuts. No longer was I mad, I was now incredibly confused.
In the next several minutes, I opened several apps to check default menu bar behavior. Firefox, MS Word, and Konqueror all underlined the shortcuts; Acrobat, Windows Explorer, and XEmacs did not. There is absolutely no consensus here.
There is no conclusion here, except that I find it very interesting this hasn't been standardized yet. If it's enough to cause a minor-grade hissy fit with me, one would think that underlining shortcuts would've become standard long ago. But if it took me this long to develop a minor-grade hissy, I may just be inventing problems. To me, underlining by default is the right way to go; that way the user has to do as little thinking as possible. Much like Cheddar vs. Monterey Jack, this issue is still up for debate.
Well, as anyone who visits The Onion or SI.com could tell you, bizarro usability is alive and well. For the unaware, bizarro usability is my idiotic term for when a company makes the deliberate decision to move away from usability. Both SI and the Onion now break most of their longer articles into multiple pages, since more pages means more advertising. It's slightly annoying, especially if you, like me, built your own mouse from pine cones and mud, and experience great difficulties in following links. Nevertheless, it's not too bad. Not only that, but the decision is justifiable, since profitability usually carries more weight than usability. So, if it's not too annoying and the decision is justifiable, why are my panties in a wad? Do I just have permanently wadded panties? I'll leave the second question for your own personal speculation.
Bizarro usability is okay when it's motivated by profit, but it's never good, I think. Bizzaro usability annoys your users, and your users are where you get your revenue. Do you think then that it's sustainable in the long-run to annoy these people? Imagine owning an X Box game that shoots a little bit of tomato sauce on your carpet every time you play it. It's not that big a deal, but do you think you'd play that game several times a day? Well, if your carpet is made of spaghetti, then yes; otherwise, probably not. If you really, really wanted to play it, you'd grit your teeth and start it up anyway, but there's never a situation where you're happy to see that tomato sauce coming at you.
As a user, I can say that if I'm continuously annoyed by one site, I'll quickly find a similar site that doesn't annoy me. I'm rational like that, and I think most people are the same. Does SI really think they possess the only site where I can read which athlete was arrested for possession of panda tranquilizers? Continue to annoy me and we'll see how quickly I can add athletes-and-panda-tranqs.com to my list of bookmarks.
Bizarro usability like this forces me to think about going to the site. Before, when I visited the Onion, I would think, "Show me some funny!" Now I think, "Crap, it's time to do some clicking." Is that really what these sites want me to be thinking? In the short run, I'll put up with these minor annoyances. Give me a few weeks of it, and I will eventually get fed up and go elsewhere. As more people go away, these sites have to add more ads to make up for the lost money. Eventually, it's just one guy going to the site, and the site makers pay to have a billboard installed in his bedroom. Not a good situation.
I think then that this kind of bizarro usability can only be a short-term situation. It's just not sustainable for very long. You can't make it permanent policy to annoy your users from now on, because there's bound to be a less annoying alternative out there. You know, maybe one that shoots lemon juice onto the carpet instead of tomato sauce.
In an attempt to plague my life with anxiety, someone arranged it so that any tool I use at work must be the least user-friendly tool available. As soon as someone invents a text editor that shoots spears at the user at random intervals, there's no doubt I'd immediately have to start using it for my job. I don't know who to blame for this situation, so I will start with the members of the band Foreigner. Among the worst of these tools is Adobe Acrobat. How such a sluggish, crash-prone viewer has become a de facto standard both puzzles and enrages me. Once again, I blame the members of the band Foreigner.
As I was saying, I have plenty of usability complaints about Acrobat. Most of these stem from the fact that Acrobat is a document viewer that operates in a vastly different way from the world's most popular document viewer, the web browser. In a web browser, if you want to select a chunk of text, you can click and drag your mouse. In Acrobat, if you try this method, you scroll down the page. There are so many of these little vexations in Acrobat, I think an entirely new number called the Acrobat should be placed somewhere on the number line between a trillion and infinity. "How many bugs are in this code?" "Ohh, I'd say around Acrobat." "For the love of Pete, just how incompetent are you?!"
Ironically, one of the most infuriating of these usability issues may not even be Adobe's fault. It really, really pains me to say that, but I think it's true. As part of my job, I read a lot of development white papers (eg, stuff off Microsoft's Patterns and Practices website). These are typically distributed in pdf format. Invariably, the pages of these papers are numbered, but the numbering is a few pages off from Acrobat's page numbering. Acrobat starts counting from the very start of the document, whereas the document doesn't start counting until after the title page and the table of contents.
What's the problem here? Well, imagine you're looking at the table of contents for a particular item. The table of contents says it can be found on page 45. In Acrobat, you enter the command to go to page 45. It works perfectly, except you don't go to the right page 45. Acrobat takes you to its idea of page 45, which is a few pages away from the document's idea of page 45. Do this a couple of times a month, and you'll soon find yourself nursing your very own irrational hatred for a 70s rock band.
Clearly, a mistake exists here. The document is numbered two separate ways, and there's no way to translate the numbering from one way to the other. A user cannot help but be confused over something like that. Whose fault is it, though?
It's hard to blame Adobe, since their numbering is completely consistent with their concept of a document. It's also hard to blame the organization responsible for the document, because their numbering is also competely consistent with their concept of a document. What gives then? The fault, I think, lies in the collaboration between the two.
When you view a PDF document, the document is a joint presentation by both Adobe and the organization behind the document. One side creates the document, the other side displays it. When the document gets converted into PDF, we get the disagreement with the numbering methods. Knowing absolutely nothing about the subject, it seems to me like there needs to be a way, in that conversion process, of adjusting one set of page numbers so it's consistent with the other set. That way, there's only one set of page numbers and no more user confusion. (I don't know the specifics of implementation, but I can think of a few different ideas here.)
I think is an important usability idea, that problems may arise from collaboration. It's entirely possible that each entity is completely consistent and easy to understand, but the moment it comes into contact with another, that can all change. It's unreasonable to expect the user to navigate these changes gracefully. No, that burden should fall on the collaborators' shoulders. The collaboration isn't complete until the interaction between entities is completely consistente and seamless. Or, if the fault isn't theirs, then perhaps the members of the band Foreigner are responsible. Whatever, I'm open to suggestions.
Over the past couple of days, I've had the opportunity to watch a few first-time users try to import a CD into their iPods. One of them, in fact, happened to be a handsome chap named Cody Powell. Each user experienced no problem in getting the import started, at least until iTunes started playing the CD. Immediately after the users noticed this, panic set in. "Am I importing the CD to my iPod, or am I playing it on my computer? If I hit stop, will it stop importing or stop playing?" If it's that confusing, 'Play songs while importing' shouldn't be the default.
Excepting that, iTunes is great. It makes me wonder what Nullsoft could've done with Winamp, if AOL hadn't squashed the project.
A while back, I wrote about bizarro usability, which is when developers deliberately make something less usable. I said then that I could understand doing this, in light of business concerns. I found another example of this on the ACM Queue website (which always features lots of cool stuff). If you click on any multi-paged article (like this one) and select on printer friendly format, you get the article without all of the junk from the site, but it's only one page at a time. In the forums on the site, someone asked why you didn't get the entire article in printer friendly format and one of the staff members wrote (can't find the link) that's because there'd be no point in buying the magazine if you could view the entire articles like that. When I read that, I immediately began to dance the bizarro usability dance, which features a lot of swivelling, dipping, and unplanned muscle spasms.
However, before I could get too cocky with the concept of bizarro usability, I came across an instance of it that clearly isn't motivated by profitability. In fact, I have absolutely no idea why it was implemented. I suspect the explanation is really, really complicated and would make me want to hit myself in the face with my laptop battery, though.
In the Pragmatic Programmer book, one of the tips they share is to learn a text editor really well. Since these guys are usually spot-on with their stuff, I decided to give this one a shot. As such, I loaded up Emacs, the only text editor capable of flying the space shuttle, and got to torturing myself. After using it for a bit, I realized that I liked Emacs. Even if the key combinations were difficult to remember, the sheer capability of the package impressed me greatly. And then, I went to close the program and I suddenly became very, very confused.
Here's an experiment we can do together. Open up a new, blank file in Emacs and type a character; it doesn't matter what you type. Now, use Control-x Control-c to close the program. At the bottom of the window, Emacs displays a nice little message "Save file /home/cody/newfile? (y, n, !, ., q, C-r or C-h)" Let's ignore the fact that I have absolutely no idea what any of those letters mean except for the first two. We've just been messing around here and we don't want to save anything, so we type n. Emacs still doesn't let us quit; it has yet another message. "Modified buffers exist; exit anyway? (yes or no)", it says. We want to exit anyway, so we type y to exit. And now, the cherry on the cake: Emacs doesn't like that. It bleats, "Please answer yes or no." Unlike the previous prompt, y isn't valid here, WE HAVE TO ACTUALLY TYPE YES.
Huh? What? Why? Do what now?
To me, that entire exiting process is way too complicated. I expect programs to get out of the way when I want to exit, not badger me endlessly until I give them some input that matches their inconsistent prompts. I'm not sure if this bizarro usability or not, though. Without question, it is not usable, but is it deliberately not usable? I can only suspect the answer here is yes. Emacs has been around for 20 years and one must think that at some point, a developer would've become exasperated with this and tried to simplify the exiting process. For whatever reason though, this change never propagated down to the end user.
Considering the organization and the functionality involved, this complication wasn't introduced because to boost profitability. In fact, I have absolutely no idea why that hurdle exists and I can only hope that an Emacs guru can put me on the right track. Whatever the case, I am compelled to think there are times when bizarro usability can be justified and times when it can't. It's justifiable when necessitated by business concerns, as seen with ACM Queue. Maybe there are other situations where it's justifiable also, but it doesn't seem like the Emacs example is one of them.
As bad as it is, I don't plan on looking around in the Emacs source for this code. The stuff contained in there is probably powerful enough to kill me on the spot.
As you can see, I'm kicked my unhealthy obsession with OO for an equally unhealthy obsession with UML. I just can't help myself! I woke up this morning and heard a booming voice bellow, "Let it be usable!" At first, I thought it was a sign from above, but it turned out to be my neighbor screwing around with his PA system. Once I discovered that, I considered disregarding the whole usability thing, but do I really want to get on the bad side of a neighbor with a PA system? Hell no.
Usability, according to the folks at dictionary.com, is the effectiveness, efficiency, and satisfaction with which users can achieve tasks in a particular environment of a product. In all honesty, I don't even see the point for the word when the definition just rolls off your tongue like that. Recently, in my travels across the web, I began to think about the consequences of usability. It might not shock anyone, but usability is a trade-off. That should be evident to any UI developer; that which is usable is not always that which is easy to code. Sometimes, you have to sacrifice simplicity of code for usability. That's an obvious usability trade-off, but are there any others that are more subtle? You bet your sweet bippy.
Like a lot of folks, my web usage at work is monitoring through the use of a proxy server. We have a certain amount of discretionary browsing time we can use each day, and this time is triggered whenever we visit certain sites. No, by certain sites, I'm not referring to naked lady sites, but to entertainment, sports, and shopping sites. Okay, fine, whatever: none of my coworkers are excited by this, but it's manageable.
One of these certain sites is theonion.com. They've been doing great stuff for years, and a Wednesday ritual of mine is to check out the new issue. Part of their site is the Onion AV Club, where they review movies, music, and books. I stop by there every week too. A couple of weeks ago, I noticed something sinister on the review pages: the reviews were now broken up, so that each had its own individual page (and thus its own set of ads). This makes it even more difficult to view this part of the site, because those of us whose browsing is monitored now must use up even more of our discretionary browsing time. Certainly the people at the Onion aren't as nefarious as Lex Luther or Dr. Evil, but the new arrangement does make it harder to view the site for some of us. In taking a step backwards, the Onion ostensibly engaged in Bizarro Usability.
Making this decision, the folks at the Onion had to decide between advertising revenue and optimum usability. I'd wager this is a common dilemma for popular websites (clearly, I'd have no idea). In a business setting, one can't mindlessly beat the drum for usability; business needs must enter into the calculus also. Occasionally, these business needs will necessitate the use of some bizarro usability of our own. To me, there's nothing wrong with this, as it's this very same revenue that keeps me from tapdancing for change down on the corner. Usability is a great goal, but because of inherent trade-offs like this, it can't be pursued recklessly. Now if you'll excuse me, I need to find a place to rent a PA system.
At work, I'm primarily a User Interface developer. That means, instead of working with cool stuff like algorithms and databases and murderous cyborgs, I spend my days trying to make buttons do the right things. Some don't care for that type of programming, but I do; I find it gratifying to watch something I made work on the screen. I don't know many other UI programmers, but I suspect that if I did, we'd go out to bars en masse occasionally. At these bars, we'd huddle together over appletinis and artichoke dip, and we'd tell war stories. "I once got my multi-threading so screwed up, my computer exploded and singed all my toe hair off!" We'd laugh and slap each other on the backs, but not too heartily, for we are delicate programmers. It sounds like a night of revelry to me.
Then, as our outing began to wind down, someone in the group would whisper, "What about usability?" Everything would stop, like a scene from a western where a stranger strides into a bar and declares, "I'm looking for the man who shot my pa, Grizzly Bear Bill!" We'd all stare at the floor and shrug uncomfortably, because usability is scary.
Why scary? Well, usability is a nebulous field. Sure, academics try to apply all sorts of metrics to it, but they can't obscure that the concept of usable isn't universally agreed upon. There are some guidelines that you kind of work with, but it's a lot more like alchemy than chemistry: all you can do is to try your best and hope you don't blow yourself up in the process.
As such, usability isn't really the domain of programmers. Part of the reason I like programming is because it eschews any notion of ambiguity; the bit is either there, or it isn't. Usability is completely orthogonal to that concept. You can't lump screens into usable and not usable, but shuffle them around into a million fuzzy categories on which no one can agree. It requires an entirely different frame of mind from programming, where the focus isn't on correctness, but on acceptability. I find it frustrating to shift between the two mindsets, and I suspect other UI programmers could agree.
If anything, usability seems like a more appropriate duty for the folks on the other side of the hall: people who live to make Word documents and Powerpoint presentations. As I see it, analysts and program managers exist to simplify things. They carve off little bits of the program and present them to us in easy-to-swallow paragraph form. They focus entirely on how software should work, not how it is actually implemented. To me, that makes them the true usability experts.
Okay, so the analysts/PMs are usability experts; that doesn't mean the burden of usability is suddenly lifted from the shoulders of us UI guys. What it DOES mean is that we, as UI programmers, have a very valuable resource within shoe-throwing distance. The next time you're starting to get exasperated about usability, don't go to the coder sitting next to you for answer. Go to the guy in the snazzy pants who has Clippy prominently featured on his desktop. By going to those with better answers, we can't simplify the concept usability, but we can simplify the way we approach it. That leaves us more time for the important stuff, like coding and appletini binges.