Musings on Consistency in OS Design

I'm a bit behind in my browsing and posting, but I wanted to note that Pierre Igot has posted parts 2 & 3 of the Mac OS X Hall of Shame. I take these articles as object lessons -- examples of things I wouldn't want to repeat, and an opportunity to get a different perspective.

In part 2, Pierre starts off with a discussion of the dock's bouncing behaviour (I believe the best description was “like a Jack Russell f**ing Terrier”). Now, dock bouncing aside, there's a thread that runs through Pierre's examples in this installation of the Hall of Shame: consistency. “Huh?” I hear you say, “I can see that the last one is all about consistency, but the first two?” Well, here's where college classes in literary criticism (“lit-crit”) come into play -- the fine art of extracting a theme from a text when you're 99% sure the original author never intended that theme to exist. Bear with me.

An operating system is many things. A kernel, a collection of device drivers (even “poorly debugged” ones), a couple of APIs here and there, sure, those are good. But to a user (remember them?), what is it that an OS does for them? For the purposes of this discussion, I shall postulate that an operating system is a promise of consistency.

Let's start with the obvious one: consistency in interaction. Pierre's third example covers this very well (look, if you haven't read the article, you better go do so, and come back. I'll wait... okay, welcome back.). When I sit down in front of an app on Windows, I expect to be able to select some text and hit Ctrl-X to cut it, and Ctrl-V to paste it. If those don't work, I'm pretty ticked. All of my “learned behaviours” are out the window. I have to spend some time to learn how the new app does things that every other app does. Well, unless that app is more-or-less indispensable, it's going to find its way off my PC pretty darn fast.

This sort of functional consistency is everywhere and is key to the overall experience. This consistency is part of what it means to be a “Windows app” or to be be “Mac-like” (violating this notion is the great sin that Word 6.0 for Mac was -- apparently rightly -- accused of committing).

Windows, like everything else, has some issues here. This past Christmas I was watching my mother navigate her way around Windows. The most fundamental thing she had a problem with was knowing when to single-click and when to double-click. I developed a rule for her to use: Put the mouse over the object. If the object, or the mouse, reacts (changes colour, highlights, looks like a button, gets an underline), then click it once. If it doesn't, double-click. For the most part this works, but frankly it's a lame rule (and in list boxes, for instance, it isn't foolproof).

The point though, is that the operating system has a fundamental responsibility to establish the rules of consistency, to document them both in words (Style Guides) and deeds (internally applying the rules across the components of the operating system). An amazing number of OS developers (from all camps) don't even realise that they have this responsibility. Windows hasn't lived up to the responsibility particularly well. The Windows Style Guide hasn't been given the attention it deserves, and hasn't really been updated for Windows XP (not to mention, it's really hard to find). Across the Windows components, you'll find lots similar things that aren't consistently implemented.

Occasionally, this responsibility for documenting consistency is explicitly shirked, as in the first Hall exhibit of Pierre's article, wherein he notes that Apple developers have said (paraphrasing) that it is up to application developers to choose how they interact with the OS X dock. That may be true, but the OS components define the standard, and its difficult for anyone to do something different. Often, application developers assume that if the OS does something some way, then it's the right way -- I mean, they must have done tons of usability studies, right? It sometimes takes a certain confidence in oneself to do something differently from the way the OS does it. Additionally, the OS often provides support in the core APIs for doing things in a certain way, and doing things a different way becomes harder, and really, who cares if the dock icon bounces like a deranged puppy dog -- it gets their attention doesn't it? (Hmmm... one day, I'll post about the OS's putative responsibility to protect users from over-aggressive programs. Stay tuned).

Consistency, however, extends into another realm. Not only do users expect a program to open when they double-click on its icon, but they expect it to open every time. They expect that if they carefully formatted a document and saved it, it will look the same way when they open the document the next time. In CS classes, we called this “deterministic behaviour”. Fundamentally, the user has a defined a mental model of “the way things should work” and they expect that the OS will conform to that model. The model was formed by a combination of the “promises” that the system gave them, and subsequent observation. One key promise that a modern OS gives it that when an update is installed, it will fix problems, not create new ones (aha, I bet you were wondering how I'd get Pierre's final item into this discussion). When updates do not perform as expected, they break the consistency model and users are clearly dissatisfied. Interestingly, a broken update breaks two separate consistency models: the “updates shall do no damage” model and the model of whatever functionality was broken by the bad update.

One way to think about this consistency issue is to use what psychologists call a cognitive model -- a model for how people think about things (disclaimer: I am not a psychologist by any stretch of the imagination, so I'm probably going bastardize the concept). Think of how people use a computer as the building of a set of rules: given a set of conditions and actions, expect a certain result. These can be very abstract: if I put a mouse over an object and it react, single-click on it. Or they can be very specific: when I'm in notepad, if I need to see the status bar, I have to turn off “word wrap”. Obviously, the more abstract a rule is, the more situations it can be used in. Now the user's objective (and the designers) should be to keep the ruleset as small as possible, and hence, to provide more abstract rules than specific rules. The smaller the rule set, the easier it is for people to learn, and to use the system. If a user can apply a set of rules learned elsewhere, all the better. The first trick is getting people to learn a rule -- sometimes this is by explicitly stating it, or simply by consistently applying the rule and having the user learn it by experience. The other trick is get the right rules -- the most productive or most positive rules. For example, if a user applies a system update, and it hangs the system, they've learnt a rule: never apply system updates. Not exactly the rule that was intended...

Microsoft has felt the brunt of this kind of adverse rule-building recently. A few bad patches over the past few years have created a reputation in some areas that we're unable to consistently deliver solid patches. Now, when, because of widespread security attacks, we need people to be patched, some don't trust us and resist, thereby putting themselves in danger.

So, in the final analysis, we learn why consistency is truly valuable: trust. Consistency breeds trust. And trust is, ultimately, what we as OS developers need from our users, and what, frankly, we as Windows developers, don't have enough of.


Now... aren't you eager to find out about the theme of Part 3? Well, I'll save that for another post, but I'll give you a teaser: it's a different aspect of consistency... namely, “Compatibility and the Art of Rebuilding a Road”.