"Go Away..." Redux: Simplifying the Complex

Well, it's official. The "Go Away or I Shall Replace You with a Very Small Shell Script" post is the runaway hit of the season. It's the most popular — or at least the most commented on — post on this site since "Getting Back to (Search) Basics," which is odd considering how different the two articles are: One is a simple, utilitarian shell script; one is an opinionated rant. Strange what strikes a nerve. But that's not really what this post is about.

In the "Go Away..." post I postulated, in essence, that perhaps this latest generation of users seems to be less tech-savvy than mine because they've had technology handed to them on a silver platter. I was pissed off and in my annual funk, or bitch-mode, or whatever the Hell it is that makes me so irritable 'round this time of year, and I needed to vent, and my logic skills were not at their finest. My brilliant theory may have been somewhat half-baked (although I still think it's kind of interesting). In the comments, people either agreed with me or didn't, and if you disagreed with me and I flamed you in any way, I want you to know that, though I'm not exactly apologizing for it, your comments are truly appreciated. I try to respond to every comment on the site, because responding forces me to rethink and restate my position on things, and that tends to get my brain a-workin' and that's always good (even when it keeps me writing 'til 4 AM). So on thinking about my theory in "Go Away..." and the the comments therein, some things occurred to me that I'd not considered in the original rant, and these lead down some interesting systems-philisophical roads.

The basic idea that I want to talk about here is simplicity. I realized that as time has gone on, maybe users are less tech savvy not because they're jaded and spoiled — no, maybe they haven't changed at all. Maybe it's because technology has grown so much more complex. I know that in our lab this is the case. When I first started this job, nearly six years ago, we were using Mac OS 9. Overall, as you probably know, OS 9 was a far less capable OS in terms of network capabilities, multi-user capabilities and reliability. But, man, was it easy to administer! Mac OS X is vastly more useful — has vastly more capabilities — but it's also infinitely more complex, and therefore more difficult to setup and maintain. Apple has done a great job of making OS X almost as easy to use as OS 9, from a user standpoint, but the simple addition of a multi-user environment, for instance, (not to mention the UNIX layer, networked home accounts, permissions and the like) has made it more difficult to use than previous Mac operating systems. And this additional complexity has spread throughout the entire lab, thus making the lab itself more difficult to understand and use. I once had a girlfriend who preferred McDonald's to Wendy's because the Wendy's menu offered too many options. In a complex world there is a certain appeal to simplicity.

Apple has done an absolutely amazing job in the realm of simplification. Mac OS X, as incredibly complex as it is, is still the easiest OS in the world to use. Mac hardware — even the pro hardware — is unbelievably easy to set up. And the unmitigated success of the iPod over literally all its competition — even cheaper, more feature-laden players — is proof positive that simple sells, and that Apple is the master of this philosophy. I first understood this when Safari was introduced a few short years ago. Here was a browser from which they'd stripped out numerous features, but which (after the release of the tab-enabled version) I found myself using as my primary browser. Though I did recently switch, for certain unavoidable professional reasons, I still prefer the Safari experience to that of any other browser. And part of the reason is because of its simplicity. Safari is a joy, in large part because it's simple and easy as Hell to use. You find this approach in every Apple product. It's a hallmark of the brand, and it's the reason Mac users are so loyal.

When I started this job I was a Macintosh SysAdmin. Mac only, in a mid-sized, very cross-platform networked lab with a separate SysAdmin for each platform. Over time we've restructured the staff, and in recent months responsibility for the whole lab has suddenly come under my purview. I now spend a lot of time thinking about how the lab is currently constructed and how I want it to be in the future. Right now, things work pretty well overall, and our network is quite powerful. There's a lot a user can do to leverage the power of this network if they have some understanding of how it works. The problem is, there's no way they can possibly understand how it works with their limited time and access. In "Go Away..." I said that, to a certain extent, people need to understand the tools of their trade, and I stand by this. But how well do they need to understand? How deep should their knowledge run? Should the car mechanic have a complete and thorough understanding of the way each and every individual car part is machined or manufactured? Should the car owner? Probably not. And I would argue that users of our lab should not need to have much understanding of the nuts and bolts of its construction in order to make use of the majority of its power. The functionality of our lab, like with an Apple product, should be almost self-explainatory. This is what I think about when I think about how I want our lab to be: How do I make the complex simple?

I look to Apple for ideas along these lines. How does Apple streamline and simplify the use of a product or a piece of software? There are a few ways. Firstly, they remove the unnecessary. If it's something people aren't using, they strip it out or they hide it. Apple is really good at deciding what the most important features of a product are and stripping out — or at least hiding to a certain degree — everything else. Everything you need to know is right there in front and working as 99% of people would expect, and more advanced functionality is hidden away in places where more advanced users know to look. So that's step one: remove the cruft. Take out everything we don't need and present a limited set of the most essential options.

Step two is what I guess I'd call sensibility: presenting things in a logical and intuitive manner. Once we've boiled functions down to the essentials, how do we present them to the user in a straightforward and easily understandable way? This step is hard because it requires a good understanding of users in general, and of our particular user base specifically. How do our users tend to use the computers in our lab? A great way to find this out is to ask them. I try, when I'm implementing a new feature — or updating an existing one — to ask a sample of users how they'd use the feature, or how they'd expect it to function. I also look to Apple again for inspiration. How does this feature (or a similar one) work in a Mac product? Why did they choose this method? What about it makes sense? If you can get a sense of how users are using your lab and the computers therein, you can then implement new features in a way that's easy for them to learn and remember.

Step three is consistency. Final Cut Pro is a great example of Apple's consistency. I've been using FCP since version 1. We're on version 5 now, and yet I've almost never had to relearn how to do anything in the program. With all the myriad new functions added in the last seven or eight years, almost every command functions exactly the same way it did in version 1. The interface layout is almost the same in every way. Apple may add features, but they're insanely consistent when it comes to maintaining usability from version to version of FCP. It's this kind of consistency that makes continued use of Apple products a very organic and easy affair. Similarly, in the lab, o nce we implement a new feature in a sensible way, maintaining the way that feature works from semester to semester should be as consistent as possible. This is not always easy, and sometimes even Apple themselves are to blame for broken consistency. God knows, differences even between Panther and Tiger have complicated the consistency problem for me and my users, and there's not a lot I can do about this sort of thing. But as long as general consistency is considered and maintained whenever possible, and combined with sensible implementations, it goes a long way to simplifying use and creating an environment that "Just Works." An example of where sensibility and consistency have broken down in our lab is the numerous password servers we employ. We have seven or eight (I can't even remember anymore) different password servers for the various platforms and web application on out intranet. This means that passwords for Macs are stored on a separate server than those for Windows or Linux or any of the other authenticated systems in our lab. This is neither sensible nor consistent. Users' passwords match at the outset of their enrollment here, but a change on any one platform will render the set of passwords inconsistent between platforms, and this is extremely confusing to users. I've spent untold hours working on (and writing about) this problem and plan to implement at least part of my solution this summer. Suffice to say, inconsistency in user data and workflow does little to simplify lab operations, and does a great deal to complicate them. And this makes the lab much harder to use than it should be.

The final step in simplifying the lab is education. Once intuitive, sensible, consistent features are implemented, we need to tell people how they work. Fortunately, if your implementations are truly intuitive, sensible and consistent, this shouldn't be that difficult, and should be something you don't have to do over and over again. Instructions on how to use the lab should be simple, clear and to the point. They should be illustrated whenever possible. And they should be documented online somewhere that is intuitively, sensibly and consistently accessible. Relearning the network should be as easy as opening and skimming a web page.

What we're really talking about here is the user experience. I think, personally, my job as a SysAdmin and Lab Administrator, at its heart, is really all about creating a user experience. Right now, in many ways, the user experience in this lab is more akin to Windows than it is to Mac OS X. There are too many steps to do simple tasks, things don't work as you'd expect, and there's a lot of confusion about how things work. Hopefully, it's getting better. Unfortunately, there is probably no way for me to make every change I want to make in one fell swoop. Changes to our existing infrastructure need to made, to some extent, with legacy users in mind. Plus there just isn't time to plan and implement everything at once, nor would it necessarily be wise to do so. So we move in baby steps. Occasionally leaps and bounds. But always piecemeal. In the end we hope to have a vastly simplified and, as such, vastly improved user experience that allows our users to focus less on how our lab is set up behind the scenes and more on how they can use it to do their work. That is what I see as "my job."

Thanks again to readers and commentors on this site. You've given me a lot to think about and I appreciate it.

Another blogger, software developer Daniel Jalkut, posts some similar (and similarly long-winded) thoughts on simplification from a software development perspective on his Red Sweater Blog.

Yet more. Seems to be a hot topic these days. (Via Daring Fireball.)