Why I don't want to be Delicious - Beyond the Unboxing Experience
Ages ago, most blogs I read were abuzz with talk about "the delicious generation". There was talk about "writing your own fucking HIG", about "steak versus sizzle", and many other beautiful and colourful phrases summarizing why and what the "Delicious" group of applications was (supposed to be).
Let's just say that I always felt uncomfortable about the whole concept. Maybe it is because I started programming under classic MacOS, where Human Interface Guidelines were strict, and we had to count every pixel twice before using it for a UI element. Pixels were rare, and colors were few and far between. We had to walk ten miles, uphill, barefoot in the snow just to get an event loop, and even then we had to write it ourselves. And when our app crashed, it took the Mac with it, and we liked it that way. ... err ... sorry, don't know where that came from.
All right, I admit there are some things the delicious apps, and their stepchildren, and Apple's UI experiments in their own mothership-designed apps have given us that I am very grateful for, and which I appreciate:
- A whack over the head reminding us that we have enough colors and pixels these days that we can use a different texture for a popup button without the risk that no user will recognize it as a popup button.
- A renaissance of real-world metaphors, but this time in photorealism instead of as the simplified, idealized toys in MacDraw's and MacPaint's toolboxes.
- A new appreciation of professional graphics design and polish.
- More attention paid to the un-boxing experience and to welcoming new users, including the metaphorical return of the trusted old "Macintosh Intro" and "HyperCard Tour" in the form of welcome screens and tutorial screencasts built right into the applications.
- Heart and soul for our applications, including tiny features that make our users go "wow!" when they realize someone actually thought of that.
- A willingness to part from the well-trodden paths of the letter of the Human Interface Guidelines when there is a good, well-researched reason to do so, and it doesn't violate its spirit.
However, one thing I found consistently missing, was paying attention to users' workflows and efficiency. Most of the attention seemed to have been paid to the initial un-boxing, leading the user into the application, making them go "wow!", providing the basic feature set that was needed to sell an application as whatever kind of application it was supposed to be.
File comparison utilities that were only able to compare two files, without the ability to take into account a common ancestor (heck ... FileMerge and even diff do that out of the box, for free!). Version control applications that require you to select every single file and add it, are unable to retroactively detect moved files, have no support at all for branches and merging, and hence get their asses kicked by an application with an Eclipse-style Java UI. Disk burning applications that made it too easy to accidentally delete a file while scrolling, and that just passed through features of the disk recording framework, and which haven't seen more than a single maintenance update in over two years because they are apparently waiting for Apple to add new features instead of doing it themselves. Book databases that crawled to a halt just around the number of items where it would make sense to start keeping a database of them, and then sold the fix to that issue as a major reason for version 2.0.
All of these applications have one thing in common: They seem great at first, but after you've used them for a while, they fall down flat on their noses. Yes, not everybody uses an application the same way, and yes, not everyone needs the same features, and yes, you need to build up recognition and a brand identity if you want people to remember your application and you want to stay in business. But you also need to actually do for the user what she expects you to do.
And that's why I have decided I do not want to be Delicious.
Do I want a professional-looking, polished application? Yes. Do I want to create a program that is inviting and enticing to the user? Yes. Do I want to provide the best, most intuitive user interface for my users? Hell yeah.
But my application also has to be able to support the user in doing their tasks every single day. It has to cope with the user not quitting it and not shutting down their Mac for a month or more on end. It has to honour their priorities and their data, it has to perform well in real-life situations with real-life data. It shouldn't present cryptic error messages or get stuck in error message loops when an error occurs, and the concept of an "unexpected" error should be anathema. And it should support the user, not just sit by and be idly manipulated. It should have sensible defaults and do the right thing out-of-the-box.
And sure as hell it shouldn't unnecessarily transmit the user's data over the web or evaluate it just so I can present it on a map or announce how much money people have made using my app in the last month (!), redirect every operation on the 'net the users do through my company servers, delete the user's home folder or encrypt their files when my app thinks their license had been tampered with, send their whole address book to my company servers unencrypted without telling them beforehand, or install code that gets loaded into every application just so I get better crash reports.
Could a Delicious application get that right? Sure. Did any of them? Not that I've seen so far. With most of these apps, the graphic designer was driving the bandwagon. The arrangement of things on screen was not decided by how quickly a user can execute several operations that are usually done in sequence. It wasn't decided by how easily the eye can grasp which screen elements go together, what relationship they have, or what the current state of the user's data is. The driving design force seemed to be: Will it be a good demo? or Does it look good?.
Now, if you've paid attention to usability, the commonly-used term is rarely "look". It is usually "look and feel". And the feel is the domain of the interaction designer. And as much as I'd love to say otherwise, the "feel" rarely is delicious. The feel is that gossamer-thin fleeting quality that, after more than twenty years of aping, Windows still hasn't been able to imitate from the Mac, and that the Mac invented without any help from its grandparents at Xerox PARC. The right feel is the thing to strive for, the feeling that the computer is along for the ride with you, the user, that the application is really there to help you, and is a reliable pillar of support, and not just a colourful banner flying in the wind.
Keynote, iMovie, iTunes and Garage Band, Apple's apps that were so obviously the inspiration for some of the UI experiments that the delicious generation entertained, got this right. They made things as simple as possible, but no simpler. Did they make a few mis-steps? Yes, Keynote's "Builds" drawer shamefully hides behind the inspector, waiting to be replaced with a timeline or something similarly easy to manipulate that doesn't cause a huge bunch of stacked up objects in the middle of your window, but the custom UI in Garage Band made it look approachable, frendly, and that weird wooden edge gives it a real feel. And Keynote's simplicity isn't achieved by leaving out text labels and hoping your icon designer is a genius and can cram a complex context into an 8x8 pixel icon badge.
So, think different. Don't do what the cool kids do. Be Non-Delicious and instead just create applications your users love.
In the interest of full disclosure, I should mention that I occasionally do work for Roxio on Toast, so my comments on disk-burning software may be biased. Then again, this is my personal blog. Everything I write is biased.