Lessons of “Why Software Sucks”
I’m not a usability engineer of any sort, and I don’t pretend to be. I still couldn’t resist buying a book titled “Why Software Sucks” by David Platt, though. This is a raucous read that I recommend to everyone, developer or not.
Platt excoriates us, like Buddy Rich to his marching band, in a hilarious and memorable way. The first half of the book contained three main technical lessons, which I outline here. The second half, namely the final three chapters, are themselves potentially the subject of a separate post.
I first read this book during The Project, and attempted to apply some of the lessons where I could.
- User Interfaces Suck
Platt wisely started the first chapter with an appeal to the every day user and highlights the reasons why a lot of people get frustrated with computers:
1. You are not dumb. User interfaces really do suck, and they shouldn’t.
2. They suck because they’re designed by programmers, who don’t realize that their users aren’t like themselves.
3. Because of point 2, their interfaces are intentionally complex, and they expect you to like dealing with that, which you don’t (see point 1).Platt’s first target is the innocent Notepad application, my first IDE. Simply put, Notepad sucks, according to Platt, because upon exiting with changed text, you are prompted if you want to save changes.
(Familiar, yet lazy)At first blush, this sounds ridiculous. You changed the file; you need to save the changes, right? In fact, this very reaction, my reaction, is so routine and in-grained because of people like me. And this is Platt’s point.
Notepad is meant to remind you of an actual notepad. When you scribble something on a new leaf of paper, are you prompted to save? No; you wrote it, and so it is there. You close the notepad and put it in your pocket.
(I carry one on me all the time at work)Platt contends that this be the case for Windows Notepad. And, I agree with this for additions of text only. If I edit existing text, I’d still like to be prompted. That way, I can discard the changes.
This was a nice segue into Platt’s next example of software that sucks. Have you ever been prompted for confirmation on anything? Are you sure you want to empty the Recycle Bin? This sucks. Again, it is kind of ridiculous. It is so common that we aren’t even aware of it anymore. And this is the problem. Platt favors an undo feature in lieu of constant and useless confirmation dialog boxes. And on this topic, he is right on the money.
Consider Vista’s User Account Control. If you are the average user, this is a mere annoyance and is soon defeated (on a side note, I actually like UAC, because it evokes Unix-style security. And I do pay attention to it. Every time!).
Platt’s general recommendation for the industry is to employ usability experts throughout the lifecycle. Just like testing should be integrated, I too believe that a usability process has to run in parallel to the main development process.
On The Project, well…honestly, an undo feature wasn’t even on the radar. I had a few confirmation dialogs, and Platt is absolutely right in accusing me of being lazy. The trade-off was made in favor of time and delivering the product at all. But until I read this book, I didn’t even consider it a trade-off, but rather the status quo.
As far as usability experts, I am not one, and there was of course no way I could bring one on board. I tried to simulate this by developing non-functional prototypes before main development. I incorporated feedback from those meetings into the real UI. The prototype and the final product ended up being pretty similar. In addition, after each sprint, I incorporated UI feedback from user testing.
Notepad and confirmation dialog boxes everywhere fail because they ignore the human element of the picture. It’s a people problem.
- Websites Suck
The second chapter continued along the same theme as the first, focusing this time on sites that impede their users, rather than help them get something done quickly.
When a user gets to a Web site, the site’s functions and capabilities need to be obvious. The user has to immediately see what the site can do for her, and what she has to do to make it do that.
Web sites exist to serve their users. You can see now that good Web design is possible and at least occasionally does happen. When it doesn’t, it’s because designers don’t understand their users, even though they should.
Real world violations in this chapter were brutal. UPS really took it on the chin. Its website forces every visitor to choose their country before they can use the site to do anything. Platt’s word choice and delivery is so good, it deserves a second blockquote:
But if one in ten of those 145 million (UPS’s daily traffic) hits goes to the country selection page, and if selecting the country takes an average of five seconds, UPS.com wastes an entire human lifetime on this foolishness every single month.
Priceless.
Starbucks is also a target. Its store locator feature is not intelligent. If your initial search yields no results, it returns and tells you as such. Again, at first blush, it seems intuitive. What else is it supposed to do?
Platt contends that it should re-try your search with a wider search radius, since that is what the user is going to do anyway, in successively larger quantities, until a match is found. This is pure genius, but it doesn’t take a genius to figure this out. Had Starbucks done adequate user testing, surely this trend would have shown up on the other side of that one-way glass.
Does anyone make Platt’s cut? Yes. Google. Google automatically, based on your IP address, figures out where you are and loads the Google page for that country. If the guess is wrong, the link to change your country is readily available. In the cases of both Starbucks and UPS, don’t make me think.
As far as The Project, the before-mentioned user testing and prototypes revealed to me that I needed auto-completion text boxes, as well as multiple ways to get to often-used functions, like adding equipment of certain subtypes, right-click context menus, and editing equipment. These sorts of feature additions never would have occurred to me.
Usability testing is key to the process. Software fails when it fails to address the human problem.
- Security Sucks
The third, fourth, and fifth chapters focused on security, and again Platt pins the issue as more of a human one than a technical one:
Once a user feels that her hassle budget has been exceeded, she’ll find a way to bypass whatever rules the programmer has established, probably without distinguishing the wise ones from the stupid ones.
Noticing a theme here? It’s the people. The people are the problem.
Platt takes a shot at a feature of Windows that defeats me every time. If you have the urge to double-click the time on the Task Bar to view the Windows Calendar, you’d better have admin rights on the machine. At work, we don’t, and you get the nice dialog that you have to be an admin to edit the system time.
(admins only!)OK, true. But all I wanted to do was check what day the Fourth of July falls on in 2016. Why can’t I see a disabled calendar? There is no reason. So what will an abused user do? Log in as an admin, and now the principle of least privilege is thwarted.
The same goes for the myriad of passwords that today’s user has to deal with: your user account, your email, your IM clients, your message board accounts, your bank account, … it goes on and on.
To deal with this, the user will take the same route and either write down the credentials on a Post-It, or make all passwords the same. I am minimally guilty of the latter, but either one defeats the security that a private password affords.
In this case, nobody yet solves the problem. Platt advocates a single sign-on service like Windows Live, Open ID, or the current credit card system. I can’t say I disagree.
On a broader scale, Platt endorses that default configurations protect users by default, and force them to turn off some feature. A good success story cited is Windows Update. It is enabled by default, serves as minimal hassle to the user, and has to be explicitly turned off by the user, making it a conscious choice.
On The Project, I think I got it right, given my constraints. I did not contribute yet another username and password to the user’s hassle budget. Instead, I tried to re-use the user’s existing network credentials.
Originally, I was going to have the user log in with these same credentials. When that fell through the cracks, I took this a step further. The user is already logged onto the network if they are running the app. There is no need to ask for their password again. All I need to do is check their username to see if they are authorized to use the system. This way, they are not hassled whatsoever. Jackpot.
At least I didn’t resort to Platt’s other suggestion: using a condom on your Ethernet port.
(ah, my first time)
“Why Software Sucks” is a great book for developers and normal people alike. It has definitely ruined me for bad UI. I find myself being a lot more impatient and intolerant of a lazy interface, whether it was designed by me or someone else.
