diego's weblog

there and back again

“I broke it” vs. “it’s broken”

“I don’t know what I did.” (Cue ominous music.)

These are usually the first words that non tech-nerds will utter when asking for help with a computer problem. The printer was working, now it’s not. A certain toolbar has always been there. Now it’s not. Double-clicking on an icon used to load a certain application, now it doesn’t. A network drive used to be available, now it isn’t. And on, and on it goes.

Let’s step back for a moment — quoting from my post a couple of weeks ago, cargo-cult troubleshooting:

There’s an interesting aside to this in terms of why we assume that the problem is on our end first, rather than the other. It’s what I call the “I broke it vs. It’s broken” mindset, of which I’ll say more in another post, but that in essence says that with computer systems we tend to look at ourselves, and what is under out control, as the source of the problem, rather than something else. This is changing slowly in some areas, but in a lot of cases, with software in particular, we don’t blame the software (or in this case, the internet service). We blame ourselves. As opposed to nearly everything else, where we don’t blame ourselves. We say “the car broke down,” not “I broke the car.” We say “The fridge isn’t working properly” as opposed to “I wonder what I did to the fridge that it’s no longer working”. And so on. We tend to think of Google, Apple, and pretty much anyone else as black boxes that function all the time, generally ignoring that these are enormously complex systems run by non-superhuman beings on non-perfect hardware and software. Mistakes are made. Software has bugs. Operational processes get screwed up. That’s how things are, they do the best they can, but nothing’s perfect.

This is perhaps my biggest pet peeve with computing devices. Whenever someone tells me “I don’t know what I did,” I give them the fridge example and they say, “good point… but… this was working before.” They see the point, but they still blame themselves. And it drives me crazy. (Note: As I mention in the paragraph, some of this comes from a sense of infallibility we assign to web services, but that’s a slightly different topic and so I’ll leave that for yet another post. What I want to discuss here has to do with personal computing devices themselves).

This didn’t happen by chance. Software as long placed seemingly impossible choices on users. I still chuckle at DOS’s “Abort, Retry, Fail?” option when, say, a DIR operation failed. Of course, there’s a meaning to each of those options (nevermind that in practice it didn’t make much of a difference which one you chose, since they usually happened when there was a hardware failure).

Now, this is fairly common with new technologies — early on there’s many more low level details that are exposed to the user that allow them to create problems. The difference with software is its malleability and the fact that we chose, early on, to expose this malleability to every day users, and many of the initial metaphors were low-level enough that they could easily be misused, like, say, the filesystem (a bit more on that below).

Granted, software does present more opportunities for a user to make a mistake and “break things” than your average fridge, but in my mind that’s not an excuse. Software should be flexible, yes, but it should also be resilient to user choices, allowing easy recovery and an understanding, on the part of the device, of state.

Frequently the source of the error is a hardware problem. These days, automatic updates can also break software or misconfigure settings. This isn’t the user’s fault. Many other times, it was, in fact, something the user did that “broke it.” But my argument is that even in that case it’s our responsibility as software designers to build software that is resilient, if you will, to user choices. Back to the fridge for a moment: you can break a fridge by doing things that, for example, push the motor too hard, or if you’re smashing the controls inside, but it requires time, it’s not easy, and it can’t happen in a split second while you are distracted.

The filesystem is a great example of this problem. It’s too easy to make mistakes. While using it, you have to pay attention not just to the task at hand but also have to devote a significant amount of attention to the mechanics of doing it to make sure you don’t, say, wipe out some unrelated documents while trying to create a new one. That’s why I really like the idea of what Google has done with Google Docs and what Apple is trying to do with iCloud in general, pushing the filesystem out of the way to leave in place just a document metaphor, closer to what’s in place in iOS (for an in-depth discussion of this topic, you should read the iCloud section in John Siracusa’s excellent OS X 10.8 Ars Technica review. And if you haven’t yet, read the whole thing while you’re at it.) These new approaches aren’t perfect by any means. Behavior and functionality are still wonky at times and it’s hard to let go of an interaction metaphor that we have been using for decades, but we have to start somewhere.

There are many more areas in which this kind of shift has to happen, but since in the end it all comes down to data, it’s really, at the core, a difference in how we approach data creation, modification, and deletion. creation should be painless, modification should almost always automatically maintain version information, switching between versions/states should be easy, deleting information should be very difficult, and, in a few select cases, pretty much impossible (if you think this is extreme, consider, do you have the option to delete your computer’s firmware? Not really, and for good reason, but the firmware isn’t the only critical component in a computer). This can apply to UI state, system settings, device setup, display preferences, you name it. Incidentally, all large-scale web services have to implement these notions one way or another. Bringing down your entire web service because of one bad build just won’t do. :)

We know how we got here. For a while, we had neither the tools not the computing power and storage to implement these ideas, but that is no longer the case. It’s taken a long time to get these concepts into our heads; it will take a long time to get them out, but I think we’re making progress and we’re on the right path. Here’s hoping.

4 responses to ““I broke it” vs. “it’s broken”

  1. Boris Mann August 4, 2012 at 11:26 pm

    I’ve begun to call this the shift to “casual computing” (echoing casual gaming). Computers have been hard because they are professional tools. As computing goes casual, things must get simplified.

  2. d August 5, 2012 at 8:49 am

    Interesting analogy, but I don’t think the word ‘casual’ captures the context correctly. Non-nerds (ie non-tech-nerds) use computers as much and for many “professional” tasks with more depth than nerds do. For example, a fiction writer will use word processing software in a way that most nerds never will. Same with, say, accountants and excel. Or video editing. The non-nerds are really the “professionals” in many cases, but they’ve been exposed to concepts (like filesystem management) that are completely unnecessary for the task that they want to accomplish.

    • Boris Mann August 5, 2012 at 9:06 am

      Right, but that is deep vertical usage, rather than broad horizontal usage. AKA task based, as it has been called. Tech nerds rely on broad horizontal usage & expertise, which is what I was thinking of as professional.

      The horizontal tasks such as email, photos, calendaring, and, as you point out, managing a file system – are entirely casual today, whereas they used to be professional or enterprise use cases.

      Still not quite the right words, but getting there.

  3. nick barr (@nsbarr) August 5, 2012 at 7:57 pm

    “Many other times, it was, in fact, something the user did that ‘broke it.’ But my argument is that even in that case it’s our responsibility as software designers to build software that is resilient, if you will, to user choices.”

    This argument is dead-on —— designers need to remove opportunities for the user to have a broken experience. Software should aspire to be as durable as cars and fridges.

    But the fact that users assume agency when something breaks, ie., “I broke it” rather than “it broke” is actually a victory for user experience. Why?

    Only machines break on their own. Consider a teapot, a picture frame, your eyeglasses. These things don’t break on their own, or break down — they require “user error” in order to break down. In a separate post you talk about skeuomorphic design as an attempt to make software replace actual objects. I agree with this, and by extension I think it’s good design when we treat our broken software like a broken teapot rather than a broken machine.

    I think the future of bad user experiences will entail doing away with the “broken” metaphor altogether. Increasingly, “I broke it” will turn into “I misspoke” or “You misunderstood.”

    To understand why, consider the master-servant relationship users have developed with software, starting with Clippy in 1997 and continuing on to Siri in 2012. Look at how Chrome profusely apologizes for crashed tabs, like a personal assistant desperate to keep his job.

    This humanization of error does more than just ease user frustration. It creates a scapegoat and a distraction for the real problem. The real problem is poorly designed software. But by presenting a cheerful interpolator, a Clippy or a Siri, the user is more likely to attribute the bad experience to poor communication. “Sorry, I didn’t quite get that,” “I think you meant,” “Can you repeat that,” “I seem to have misplaced,” etc.

    In fact, this was Clippy’s secret success — tons of people say, “Clippy sucked” but fewer say “Office ’97 sucked.” In this way, software designers can use the notion of a virtual butler to protect their brand: there’s nothing wrong with the software, we just need a better assistant to help you get the most of it. (I wonder how 2001: A Space Odyssey would have changed if HAL acted more like Clippy…)

Follow

Get every new post delivered to your Inbox.

Join 366 other followers

%d bloggers like this: