A typical response to my reasoning goes something along the lines of: “Yeah, but with Beryl, Linux looks even better!”

The computer scientists I talk to just don’t understand that user interface is about how the program acts, not how it looks. And really, I think that’s why there’s so much terrible software out there: these are the people who are building it!

The Five Minutes Left Test

In five minutes, you’ve got to leave for a doctor’s appointment, but there’s this thing you’ve really got to get done first, and you need iFoo to do it.

You’re stressed and in a hurry. Is iFoo going to make you even more stressed, or is it going to sit you down, give you a slap, and tell you everything’s going to be okay?

The sad truth is that unless I’m very familiar with it, almost every piece of software is going to do the former. I’m in a hurry, but now I’ve got to figure out how to use this thing. More specifically, I’ve got to figure out how to express what I want to do in terms it can understand.

Doing It Right

The difference between mediocre software and superlative software is the language it speaks. Stressful software makes users express what they want to do in its terms; excellent software works on the user’s terms. It doesn’t make the user know what to ask or how to ask it, and most importantly, it doesn’t get in their way.

A number of principles are key to getting this right.

First and foremost is the principle of least astonishment. Essentially, actions shouldn’t surprise the user. They should work consistently across applications, they should be undoable, and what works elsewhere should work everywhere.

The next level is the principle of the four-star waiter (no Wikipedia article on that, I’m afraid). When you’re at the Ritz, and you’ve put all the marshmallows into your hot chocolate, you don’t have to ask for more. When you turn to grab another, the waiter has already silently refilled the bowl. Clippy and his wizard friends are an attempt to imitate this dapper young man, but they do a terrible job because they’ve forgotten about the silent part.

Your application should anticipate the user’s needs and—without confusing or obtruding—act appropriately. Things like remembering a window’s position or the previous input to a form are only the first step. iChat manages your away status for you, asking as few questions as possible. iTunes keeps your iPhone continuously in sync, and if you run out of space, it’ll leave off things like photos before more critical data like contacts or addresses. Twitterrific focuses tweets directed at you because it knows you want to read them.

The next important step is minimization of interaction. You can start by reducing the number of actions required to perform tasks, but that’s not good enough. When I want to broadcast a thought, I use Twitterrific more often than MarsEdit not so much because of number of steps but rather as a result of how many things I have to deal with. Every control, label, and window makes your application more stressful to use; every time I have to change focus (especially window focus), you’re breaking my flow a little. Safari is good because its interface is tiny. We like Twitter because it has one text field. iMovie ‘08 is a poster child for reduction to a tiny number of core actions.

Get Out of My Way!

This is really a matter of flow—flow is the most important thing. Flow is how we move, and it’s why people sometimes prefer a notepad over an electronic document. When you want to note something, you write it on the pad, and put it in your pocket. You don’t have to make up a filename or where it should go. You don’t have to worry about remembering where to find it again later. You don’t have to think about quitting the app when you’re done.

Flow happens when you perform a task, thinking only about what to do, not how to do it. This is why people like things like emacs and vi so much: after the (considerable) learning curve is over, they can move like lightning, slowed by the speed of their ideas rather than by the speed of their tool. When focus isn’t in the right place, when a modal dialog pops up, or when a button isn’t placed near the data it affects, it breaks flow. You have to stop thinking about the grand unified theory you’re writing long enough to explain to the computer what you mean.

That’s the real price of bad software.

When a personal finance program sucks, that’s annoying. But my blogging software gets in my way, so I write fewer posts. And when I can’t figure out how to change the time signature midway through my piece in a music composition tool, I stop composing. The music stops playing in my head. I look around. I get out the manual. All this because the icon for the tool in question wasn’t good enough!

As software becomes more powerful, it becomes more essential to creation—to making things. And if your software is doing anything to distract your users from their magnum opus, the world is never going to hear it. They’ll hear something just slightly inferior; you will have been responsible for confusing the creator at some pivotal moment.

If you’ve written something fantastic, though, it’ll become an extension of the artist’s hand, just like a paintbrush. It’s an extra tool that enables him to solve new problems and produce even better results. It’s something to strive for—it’s why I write software.

Learning

Fortunately, it’s not impossible to get a sense of your users’ flow.

Step One: You don’t count. You’re not confused by anything (one hopes) because you wrote the app. Your experiences will only catch blatantly obvious flaws. Use them as an initial filter.

Step Two: Your imagination, however, does. Write user stories. Write them for every conceivable use case. Throw out the ones that you don’t want to support. Declare that the ones which remain are the only cases you care about, and stick to that.

Step Three: Watch real users. Some of the most useful experiences I had during Pixen’s development were when I sat down an entirely new user in front of it and watched them go. You’ll see exactly works and exactly what’s confusing. You’ll discover new user stories or (with enough samples) gain the confidence to trash others.

Iterate, iterate, iterate, and never allow anything to grate or confuse. Never tell a user “well, I guess you can do that, but you have to go do these other two things with the whozit first, then click refresh.”

And whatever you do, don’t need a Knowledge Base.

step two:

step three:

Not that we’re going to win or anything, but the performance and optimization implications of trying to solve this problem have been absolutely fascinating. A few details on the datasets that need to be analyzed:

• 17,700 movies
• 480,000 users
• 100,000,000 ratings
• 2 GB of data (700 MB stored optimally)
• Density of the movie-user ratings matrix: 1.18%!
• If computing the similarity between two movies takes 0.01 seconds, it takes 18 days to finish computing all pairs!

So that’s a little intimidating. There are a couple golden rules on performance that I’ve always been careful to follow:

1. Code first; optimize later.

   Don’t write your code thinking about every little performance hit. Make it work. If you focus on making it fast in the first iteration, you’ll never finish the first iteration, and your code will be really ugly.

2. Don’t optimize without knowing what’s slow.

   A lot of the time I think I know what’s slow, but half the time, I’m wrong. Shark knows what’s slow. Instruments knows what’s slow. Make sure you ask before diving in.

Golden Rules Aren’t Always Right

The really great thing about working on the NetFlix Prize is that basically all my software engineering assumptions and practices have had to go totally out the window.

The first observation, given these numbers, is that Ruby is not going to work even the tiniest bit. Which is really sad since it’d make life a lot easier. I’m using Python instead, with Numpy for computation. Most of the heavy lifting, then, is in C.

The fascinating thing about working on these algorithms is that I’m writing code that would normally work just fine: most of it’s O(n) or O(log n). But now I’m finding for the first time that the constant coefficient is actually mattering because it’s being executed a hundred million times. Every line of code has to be carefully scrutinized for speed considerations, and every loop is the potential for absolute disaster.

Last night I found myself writing a very simple regularization algorithm. The naïve implementation in Ruby was about eight lines. But the implementation I have now is still too slow by an order of magnitude and took more than four hours to write.

Moral of the story? If you’re a consumer software developer, you should probably be following the standard software engineering “golden rules” for optimization. But maybe all of us should work on a project at least once that gives us some appreciation for what Google has to go through to deliver us search results in a couple hundred milliseconds.

We covered a number of topics in the area, including the recent updates to the HIG, paper prototyping, error UIs, and—my favorite—machine learning in UIs, so you should definitely have a listen if you’re interested in user interface.

It’s the same size as the MacBook! Only thinner! And lighter! This isn’t a real subnotebook!

Okay. Imagine if it were 9 inches across instead of 12. What would this do for you?

Would it be easier to transport? It’s still not going to fit in your pocket, unless you’re a scary kind of guy who wears ginormous trenchcoats. You’re still going to need to put it in a bag to move it around. It’s basically the size of a notebook or normal paper, so it’s hardly going to be the limiting factor in bag size.

Would it be easier to use? Yes, if a smaller keyboard makes it easier to use. I don’t know about you guys, but I have full-sized fingers, and they like a full-sized keyboard. And the screen resolution on 12″ PowerBooks makes me cry.

Would it be more powerful somehow? Come on. The motherboard is already the size of two playing cards.

Honestly, I don’t understand the little-tiny-laptop thing. Devices are either pocket-sized or bag-sized. Anything in between is really just bag-sized pretending to be… I’m not even sure what. Levitation-sized? That would be pretty awesome, but unlikely until the MacBook Lighter-than-Air.

He also makes a very important point:

Unless you’re a member of the small demographic that thinks “There’s gotta be something better than Safari for news feeds”, you’ll never discover NetNewsWire.

You should care about this not just because it means a better experience for users. You should care because it means more customers for you.

Why can’t I watch this video?

On Ubuntu, if you open an .avi for which you don’t have the codec, it will fetch it and install it.

On Mac OS X, if you open an .avi for which you don’t have the codec, QuickTime will give you an entirely useless error message. It won’t even tell you what codec you’re missing, so you can’t Google it.

Our own private DLL hell

Say a sinister hacker submits a patch for Sparkle with a security hole in it. Sparkle has maybe a couple hundred thousand users. That’s a lot of vulnerable computers.

Now, if we were using Ubuntu, a week later, our system would say: “You’ve got 9 updates available. Install?” And the user would go, “Yeah, sure.” His system would be safe, and he’d never know how close he came to total annihilation.

But no. Every one of a couple hundred apps has its own copy of Sparkle. Or RBSplitView. Or Growl. We’ll gloss over the ancillary problem of wasted disk space—a meg or two for each app. One app’s got Sparkle 1.0, another’s got 1.1. Some people are probably still running apps with Sparkle 0.1, riddled with bugs. It’s not like they’re dependent on a particular version or anything. No, they just haven’t bothered to include the updated version of the framework.

Oh dear, oh dear. How do we fix this?

Ooh! Ooh! We could have the app install the library into ~/Library/Frameworks, but only if it’s newer than what’s in there. But then every user has a different copy. We could put the framework into /Library/Frameworks, but that would require authentication. And every app’s distribution still includes all its dependencies.

Even with that hacky solution, the framework in question still wouldn’t get updated until the user ran some app that had been released recently enough to have included the new version of it. Developers still have to constantly check to see if there are updates available for the libraries they’re using.

What the hell is a disk image, anyway?

A simple user story on Ubuntu:

I have a .torrent file. What the heck is that? I guess I need a program that opens them.

I open Synaptic, search “torrent”, check one of the resulting boxes at random, and then I can open the file.

A really stupid user story on Mac OS X:

I have a .torrent file. What the heck is that? I guess I need a program that opens them.

I go to Apple > Mac OS X Software. This opens up Safari, where I search for “torrent”. This actually doesn’t turn up any useful results (what the hell?), but say it did. That brings me to another page, where I click Download. I have to click through a sheet acknowledging that I am, in fact, downloading a program. I click the Downloads stack on my Dock, click the disk image. I drag the application to Applications to install it. Then I go to the Applications folder and execute the app from there. To clean up, I eject the disk image. Then I click the Downloads stack on my Dock, and drag the disk image to the trash.

I don’t really care so much about the length of the operation, even though it clearly takes less time on Ubuntu. I don’t even care about flow, though it’s important to note how in OS X, the user has to click through modal sheets and switch between a number of different apps. I care about the knowledge required to execute these stories.

In the case of Ubuntu, the user just has to know that Synaptic Package Manager is the thing to use to install programs. They don’t need to know how to use it: the interface is self-explanatory so long as they can think to open it. Even knowing that much is asking a good deal.

In the case of OS X, the user has to know the following things:

1. There’s a Mac OS X Software… menu item under the Apple menu. Or how to get to the Apple Downloads web page.
2. That search box on the top menu of the Apple’s site can search for downloads in addition to everything else on Apple’s site—this is not particularly intuitive.
3. That downloaded things go to the Downloads folder on the Dock.
4. How to “install” an application. This involves knowing how to open up another Finder window and navigate to Applications if a symlink is not included.
5. How to launch an installed application properly: from /Applications, not from the disk image.
6. That the disk image can and should be cleaned up by dragging it to the trash.
7. That the disk image needs to be ejected before the trash can be emptied.

Every extra piece of information the user is expected to know makes it more likely that the story will break down and lead to frustration. I see my father and some of my friends putting disk images in Applications and just mounting them and running the app from the image whenever they want it. I see people never deleting their downloaded files, leading to really cluttered folders.

But moreover, I see people having no idea how to complete this relatively simple task.

Working toward a solution

In my mind, an operating system’s merits can be judged by how easily problems can be solved on it. Applications help us solve classes of problems: a BitTorrent client allows us to download .torrent files; personal finance applications help us stay on top of our money; Transmit lets us talk to file servers.

We’ve got all these apps to solve all these problems, but where’s the app to solve the problem of getting the tool to solve the problem we’re currently facing?

The three issues I’ve described above are linked, and they have a common solution.

This is a chicken-and-the-egg problem, though, folks. We can’t just make an app that helps people install apps because a lot of people will never know it exists. A lot more people wouldn’t be able to install it, even if they did know it existed.

We need something more fundamental.

I’ve been thinking about how best to solve this for a while, and I don’t have everything together yet, but it seems to me that Spotlight is a tool for solving some kinds of problems. It could easily become a general tool users turn to to solve problems.

One simple example: A search for “torrent” would do well to return Transmission and friends, even if they weren’t installed. And clicking a result should download and run the app (in a sandbox), not bring the user to the site. Maybe something a little like this shoddy mockup, but with better icons:

But to do this properly, one needs to display some extra information and buttons in the Spotlight results GUI. It doesn’t support this, of course. This design is complicated more by the Show All menu item using Finder.

This is obviously a complicated problem, and much more thought is required. I have no idea what the UI should be like; please don’t let that mockup deter you. Here are some basics of the design I’m excited about, though:

• I want to be able to run an app without installing it. A sandbox is probably technically infeasible but would be really neat.
• Getting to an app on my system that runs a torrent and getting to an app I don’t have that runs a torrent are tasks trying to solve the same problem. Let’s approach them the same way.
• Users don’t know or care what libraries or frameworks are. Handle dependencies behind the scenes.
• These apps are like web apps: when you run them, they are always the latest version (cached for offline use). There is no software update.
• This system should be a system-wide service so that—for example—QuickTime can always have the codec needed to play the video in question.
• Code signing everywhere for everything.

If you’re interested in this problem, I’d like to chat with you about it. My contact information is along the sidebar.

>> NSWorkspace.sharedWorkspace.getFileSystemInfoForPath_
isRemovable_isWritable_isUnmountable_description_
type_("/Volumes/SparkleCaster/English.lproj")
=> [true, 1, 0, 1, #<NSCFString "hfs">, #<NSCFString "hfs">]

Now we’ve just got to do something about that really ugly method name…

For Mac development, there’s lots of places to go. #macsb is an old standby, but I’ve just recently discovered the magic of Twitter. I know, I know, I’m way behind. But if you head over to Twitter and sign up, you can see what a lot of awesome programmers are up to and connect with them in a really easy fashion. It’s like a big family, full of joy and swearing at Xcode!

Among the awesome new things are inspect methods for NSString, NSArray, NSNumber, NSDictionary, and others, so you can:

Aleph-One:Sparkle andym$ irb -r osx/cocoa
>> OSX::RUBYCOCOA_VERSION
=> "0.13.0"
>> OSX::NSDate.date
=> #<NSDate 2007-12-03 17:29:21 -0800>

Why isn’t this mentioned on MacOSForge::Ruby?