Whatever Happened to Predictability? | October 17, 2006
by Jeb Boniakowski
In the olden days, most apps—most of the big apps that you really spent hours of tube time in front of—were organized around the idea of documents. In fact, the whole computer was. It started up with a desktop, and there were a series of files and folders that organized your docs. You double clicked on them to open them, and automagically some document-editing application like Microsoft Word or Adobe Photoshop would be launched. (Actually, in the really olden days, everything was screen-based and computer screens could only display one of two colors so depressing they were funny: a sort of putrid green and a yellowish amber, but that era is known to modernity only through the movie War Games and going to the library). There were also little apps like calculators or system preference panels or CD players that were oriented around a single window, but the serious time was spent in document-based applications.
Like most good things, this paradigm started on the Mac. In fact, according to Joel, pre-Windows era Apple propaganda holds that business Mac users tended to use around twelve apps to do their jobs, whereas DOS users used one or two. (I do wish I had a better cite than an anecdote in a Joel article.) I’m sure some will argue that this is because the feeble Mac apps couldn’t do anything useful on their own. I argue that it’s because you can only fit so many of those stupid plastic hotkey guides on your keyboard at a time. The document apps worked in very consistent ways. The icons for new, save, and print were always the same. The basic interaction paradigm was the same, the Edit menus always worked the same. (I’m using the past tense because even this basic scrap of consistency seems to be headed out the door.) Fundamentally, the doc paradigm’s consistency helped it to be non-scary, a quality I’m beginning to believe should be the primary goal of UI design, above beauty or intuitiveness. Start small: don’t scare the user. When you’ve got that, then you can worry about adding fake smoke to your windows.
The Milkman, The Paperboy, Even Apple
Two big trends seem to have obliterated our hopes for increasingly consistent UIs:
- One is the web browser. Once everyone started using the browser as their main application, the whole document-centric interaction model kind of got pitched (which is hilarious and probably insanely frustrating to the TBLs and RTFs of the world).
- The second is that a lot of the interesting stuff happening on computers right now doesn’t really have a whole lot to do with documents and their editing, or if it does, the normal doc app paradigm completely fails to handle them. I’m thinking of things like media management (iTunes, Picasa), so-called rich internet applications (Google Earth, Bittorrent), and web apps (there’s the browser again).
Media management is a particularly interesting case because people have been working on it for a good long time. It’s instructive to look at the old attempts to cope with things like building MP3 players. Historically, there seem to be two basic approaches to these kinds of apps:
Imitate hardware, like WinAMP or old Quicktime:
Just go crazy, like Audion:
Both approaches also fundamentally try to deal with MP3 libraries in a document-centric way: click a button, you get a list of folders to browse for your MP3s. It’s interesting that what I now think of as the core job of an MP3 app—library management—was totally ignored by all the early leaders in the MP3 player app market. They figured they could let the filesystem do it like the doc apps did.
There is a clear trend in things like iTunes and Picasa towards what I’m calling “screen-oriented apps” for lack of a better term. The iTunes interface is basically like a kiosk. A similar idea is showing up in the OS X Finder (hey, I didn’t say it was always a good idea), Picasa, iPhoto, and a host of other apps. The problem is that there’s absolutely no consistency to the way these apps work, or even look.
In the web app space there is a related trend. Because of the basic interaction model of websites (AJAX be damned) there is a focus on creating sequences of screens to perform tasks. However, even given the extreme limitations of their “platform,” web application designers seem to be hellbent on minimizing consistency despite the fact that it’s nearly forced on them. They do things like custom-style forms, employ non-obvious Javascript to change what’s visible on the page, hijack the browser’s “back” button, mouse right-click, mouse middle-click, and use Flash for all sorts of nonsense like text replacement.
Normally, in a case like this we’d look to Apple, especially the HIG, for guidance. In fact, in the section on when to use brushed metal windows, the HIG even comes close to defining the sort of app paradigm I’m talking about:
You can use a brushed metal window if your application:
- Is a single-window application that provides a source list to navigate information—for example, iTunes or the Finder
- Strives to re-create a familiar physical device—Calculator or DVD Player, for example
- Provides an interface for a digital peripheral, such as a camera, or an interface for managing data shared with digital peripherals—iPhoto or iSync, for example
You should not use a brushed metal window if your application:
- Is a multi-window application—for example, Interface Builder
- Is a document-based application—for example, TextEdit
It makes it sound like Apple’s getting close. The “provides a source list” description is sort of a narrower version of the “screen-oriented” or “kiosk” app idea. The “physical interface” or “interfaces with physical device” use cases are guaranteed to be sort of screen-oriented. But Apple blows it by totally ignoring their own rules in apps like Safari. Nevermind that they have apps like Aperture, which appears to be “a single-window application that provides a source list to navigate information”, as well as one that “provides an interface for a digital peripheral, such as a camera” and yet has the totally separate Apple “Pro” look and feel:
Let’s try to forget Apple’s foray into 1960s station wagon design:
Yes, that’s fake wood. On a computer program. Made by Apple. No, I’m not crying. I have something in my eye.
It’s worth pointing out that even if these were just simple re-skins they would still be bad, especially for non-turbogeek users. Changing the way the software looks all the time, even if it works the same, is throwing the principal of non-scariness to the wind. The user has no reason to believe the software still works the way it used to, so it might as well all be different. It’s my suspicion that even for people who sleep under videogame quilts, changing the appearance of these things all the time ends up slowing them down.
When You’re Lost Out There, And You’re All Alone
So what’s a UI designer to do? When you’re creating a desktop Windows application that has a sort of screen-oriented UI, how do you design something your users will be able to use? In Proto’s case, the problem is actually an order more complex, since Proto’s a toolkit that lets users visually build screen-oriented applications, in addition to partly being one as well. (Proto also has document-like aspects, but in testing, we found that using more document-centric paradigms to interact with them was extremely awkward.)
We try, wherever possible, to follow the principle of least surprise. However, often we don’t have a good idea of what the user’s mental model of our software’s operation is likely to be so we make some guesses. In the visual department, we make a few small tweaks to normal window appearance to try to emphasize the “screen”-ness of Proto Viewer apps: the menu bar has a slight drop shadow to set off the background as being “controlled” by the menu. This “client area” is also set off on the bottom by an ever-present thick status bar, which is also used to hold controls. This is meant to echo status bar based interaction in other “screen” apps like iTunes and Firefox. It is also meant to visually recall Office 2007 which, for better or worse, will probably be a “least surprise” condition for a large number of computer users soon enough. (Or at least for the kind of early adopters who are likely to become Proto users in the near future.)
Mostly though, we have to make stuff up as we go along, and while its certainly fun to design UI elements (as well as being a popular hobby), it’s basically anti-user. The universe of people who can crank out new UI widgets that fit in with the OS well and work intuitively, not to mention being visually appealing, is very small. As far as I can tell, it’s basically just David Watanabe. So Microsoft UI team, If you’re reading this, come on, how big of a deal could it be to jam a few more UI classes into Vista at this point? You’ve gotta give us something to work with here. Developers are lazy: if you build them, we’ll use them. Besides, non-document apps are your future. And while you’re at it, maybe you could get the Office team to, you know, use the system widgets, rather than spending their time inventing the absolute worst “most flexible” toolbar/menu system imaginable (2k3. Not the Ribbon. The Ribbon I’m cautiously optimistic about).
