I’m heartened by the rumor that Apple is now struggling with how to add cut and paste to the iPhone. I’m heartened not because Apple is going to add cut and paste–but because (so the rumor goes) the delay comes from Apple sweating the details of the UI design:

The trouble it is having is implementation. How to easily call up a copy or cut option and then the paste action. It’s probable that the zoom bubble (the one that brings up the edit cursor) is the issue as it has removed the obvious tap and hold position from Apple to use for a pop-up menu of some sort. Text selection is another difficulty to sort out. Certainly, the cursor could be added to the menu selection; however, Apple wants to keep this as simple as possible and that added step would not lend itself to simple.

John Gruber observes in his comments about the LG Voyager being a potential iPhone killer that it is crap:

I actually got to use one of these turds for a few minutes at Macworld two weeks ago, and it’s a joke. You know the iPhone-like home screen? The one LG and Verizon show in all their promotional photos? That’s actually not the main UI of the phone. That’s just the interface for accessing secondary features of the phone. The main UI is just like that of any other crap LG phone, and one of the “apps” you can launch is the iPhone knock-off “shortcut” mode. And, when you open the slider, the inside screen has a third different UI. The overall experience is worse, way worse, than that of a typical LG phone.

I’m also reminded about the complaints about the BMW iDrive:

Since that time we’ve driven the new 5 and 6 Series and found similar issues with iDrive. I noted one specific issue while trying to adjust the audio system’s bass and treble settings (after wading through multiple LCD screens, of course). In this case, the graphical representations of the bass and treble settings on the LCD screen, along with the actual changes in the settings, were lagging behind the action of my hand turning the iDrive dial. So as I tried to listen for when the bass and treble were properly adjusted, I noticed that although my hand was turning the dial, no change in settings was occurring, either on the screen or in the sound quality. Naturally I tuned the dial further when I saw this and then — WHAM! — the system caught up quickly, pushing the sound of David Bowie from a Barry White-like low to an Alvin and the Chipmunks-high in a fraction of a second.

Two thoughts occurred to me as I experienced this. First, how ironic is it that BMW has invested all those countless man-hours and untold resources in creating the latest batch of high-fidelity Harman Kardon sound systems, only to pair it with a user interface that makes it nearly impossible to properly adjust the tonal qualities? Second, this has never happened to me in a $20,000 Honda Civic, a $12,000 Hyundai Elantra or a 31-year-old $1,700 Saab Sonett.

To me, all of these illustrate the basic problem most software developers and software designers have with User Interface design. To most developers I’ve known, a user interface lands somewhere between iCandy (oooh, look at the pretty animation when I press the ‘OK’ button) and a sort of graphical ‘man’ page where instead of just telling you about the command-line flags, you can click on them. And while on a desktop computer, treating UI design as a sort of a secondary and nearly worthless exercise in visual flash sometimes produces products that are tolerable to users (because most users today suffer from computer Stockholm Syndome where they idealize their abusers), it is the kiss of death for any mobile or auto-based user interface which uses a different set of interfaces than a desktop keyboard and mouse.

Sadly, while there are only a few rules that really need to be adhered to and (like Jesus’ famous axiom about loving God and loving thy neighbor) all the rest flows from these ideas–most developers don’t understand these rules and don’t appreciate why we should do them. So users get subjected to the BMW iDrive, which on the 3 series has three different ways to escape from a sub-menu, depending on which sub-menu you are in. (And of course, two of those give no visual feedback as to which method you should use: it’s simply assumed you somehow know the magic sequence, which you are to guess while hurdling down the freeway at 70 miles/hour, navigating traffic and watching out for obstacles which can kill you.)

Consistant Interface Language. Every user interface requires a consistent interface language–by which I mean that when you are at a particular point in the interface, performing the same action results in the same result.

Take, for example, the humble dialog box. Thirty-something years of dialog boxes, and we all just “intuitively” know what is supposed to happen when you click the “OK” button in a dialog box: the button briefly flashes, and the window closes itself (meaning the window removes itself from the screen, and the window that was behind it comes forward, hiliting itself to indicate it is active), with the settings in the dialog box saved away or updating the state of your application.

“Of course”, you say, “dialog boxes are always supposed to do this.” But think: who was the first person to decide that this was supposed to be the behavior of a dialog box? I mean, we could have immediately saved the state of each button change in the dialog box right away–and the “OK” button would be superfluous. We could have made updating the state of the dialog box triggered by closing the box. Hell, we could have made creating a dialog box automatically append a new menu in the Macintosh menu bar, unhiliting the rest of the menus–and accepting (and dismissing) the dialog could have hinged upon pulling down the dialog box menu bar and selecting the “Dismiss” item.

But instead, we click “OK.” (Except for some applications on MacOS X, which actually uses the “update as soon as the control is clicked” mode.)

Today that design language is so ingrained into the very fabric of our being that the idea of adding a new menu bar (or perhaps updating the Window’s “Start’ button with state to manipulate the current dialog box) sounds so counter-intuitive that we immediately dismiss the very idea.

That is what I mean by “interface language”: we have so ingrained into us the idea that there is one way to do something that we mentally cannot conceive of a different way to say the same thing.

On a desktop computer, of course, decades of interface language has burned itself into us: we use a mouse one way: we know the difference between left click and right click, we know what a button is and how it is supposed to behave.

But what about a mobile device, or a car–where there is no mouse and no cursor to drag around on the screen? That’s when you have to invent a consistent language of gestures and actions–and stick to it.

The BMW iDrive and the LG phones both suffer from the same problem, as does Windows Mobile 5’s dialog box actions: how you dismiss a dialog box or a modal state vary depending on what you’re playing with. To pop out of a menu state on the iDrive in the “settings” menu you press the menu key. In the navigation screen you select the “return” arrow by sliding left or right until you hilite the navigation component of the screen, and pressing the knob. In the entertainment console you select the “return” arrow by sliding the knob up or down until you select the return arrow.

On Windows Mobile 5, to dismiss a dialog box you either press the hot-key with the “Cancel” label above it, or you press the hot-key with the “Menu” label, press the up/down arrows until you select “Cancel”, then press the ‘enter’ key in the middle of the arrow keys.

And by varying each of these actions, you make it impossible to figure out what to do without looking at the device and figuring out what mode you’re in–which, on a BMW driving at high speed in traffic during a rainy day–is fucking dangerous!!!

All for want of a meeting with a designer who said “the menu key will pop the sub-menu up a level.”

This is even important with desktop applications. Even though much of the low level language for desktop applications have been codified by convention (“OK” dismisses a dialog box, ‘double-click’ opens a thing, ‘click-drag’ of a selected item causes drag-and-drop), for some specialized applications the interface language is less well defined. Anywhere where you’re subclassing JComponent or NSView you need to think about the interface language you’re using–and if it is consistent everywhere.

Eye Candy Enforces Relationships. By this I mean that eye candy exists in order to provide subtle cues as to the relationship between objects on the screen.

Look at the iPhone. Applications zoom in and out from the middle of the screen (a visual metaphor for task switching that is consistently used), submenus slide from side to side (a visual metaphor for drilling down a hierarchical structure), secondary pages flick from side to side (a visual metaphor for selecting different pages–such as Safari pages or home screen pages), and application modes or commands are selected by picking the black and white icon along the bottom of the screen.

Because of the consistency it takes a new user a few minutes to “get the lay of the land”–and then suddenly you go from “new user” to “iPhone user.” The language is easy to get as well: once you understand flicking from page to page, you can create multiple Safari windows, multiple home pages, multiple picture galleries… It’s easy.

Unfortunately some of the eye candy in other applications do less to help form relationships between behavior and action–and the lack of eye candy can sometimes hurt understanding. For example, when you click on a dialog button, you expect an immediate reaction: even if the action is turning the mouse cursor into a “wait” cursor. It can make the difference between thinking an application is doing something and thinking the application has crashed. On the iPhone, clicking the “search” button in Google Maps immediately replaces the button with a spinning wait cursor: you know it’s doing something. On many mobile devices, however, after selecting a state the embedded application just “sits there”, leaving you wondering if you just broke it: the delay after using voice command and getting a response from the BMW iDrive, for example, leaves you hanging on wondering if you said the right phrase.

What is particularly sad–and the Verizon phone demonstrates this in spades–is that a lot of eye candy (especially with mobile devices) is driven by marketing rather than by good user design: the Verizon phone has a sort of “iPhone-like” navigation screen that serves no purpose whatsoever–except to look good in the Verizon ads. Otherwise, it’s useless eye candy that actually detracts from the two other user interfaces used by the phone.

Provide Immediate Feedback. This should go without saying–but it doesn’t, as adjusting the base and treble on a BMW using iDrive demonstrates at times.

On MacOS X System 9 and earlier, the highest interrupt thread in the interface went to…the mouse cursor. Meaning that no matter what the computer was doing, no matter how much CPU was in use, if the user moved the mouse, the mouse cursor was updated. Period. Immediate feedback caused the Macintosh to seem responsive–even though MacOS 7 and earlier ran on a computer that was (by today’s standards) unimaginably slow.

You’d think that by turning a knob you should get an immediate response: you turn the volume knob and the sound gets louder or softer in direct response. But today with multi-tasking and multi-threaded embedded systems which do not guarantee real-time processing, sometimes this isn’t the case: for the first 15 seconds as WinCE Automotive boots on the 325i’s iDrive system, turning the volume knob doesn’t necessarily result in changing the volume, and pressing the “next track” button doesn’t necessarily go to the next track.

And this is a frustrating problem.

By sticking to these three items: consistent interface language (or, what button you press does the same thing regardless of what mode you’re in), useful eye-candy reinforcing contextual relationships (rather than being driven by marketing), and immediate feedback (even if that means putting up a “hang on a second” alert) helps reduce frustration and provide a nice experience to users.

It’s a shame that most people don’t do this.

That’s why I’m heartened that Apple is delaying cut and paste to the iPhone: it’s more important to get the details right than hack something together. After all, for something like a UI interface change, if Apple screws it up, they’ve screwed up the iPhone. And while code to add a button and change the behavior of a drag operation would take a good programmer maybe a week to mock up, it could destroy a multi-billion dollar business if it’s not done the right way.

At Daring Fireball, John Gruber hopes that the Amazon’s Kindle fails because the books being sold by Amazon are wrapped in DRM and cannot be loaned or reasonably transferred to another format.

I appreciate and understand his misgivings. I really do. I have three walls full of books which is evidence of how much I appreciate the power of the written word. And there are some books which I hope will always remain in book form which, in my opinion, are timeless: mathematics and mathematical reference books, books on algorithms, classical books on philosophy–all of which deserve to be presented on the printed page, and saved and cherished like a fine wine which can be endlessly savored without the bottle ever going empty.

But to me there are three classes of books, and (pardon the heresy that I’m about to speak) only one of which deserve the permanence of the printed page. There are timeless works: Donald Knuth’s “The Art of Computer Programming” for example, which deserve to be printed on paper and bound in a book.

Then there are ‘trash’ entertainment novels; books which will be read for enjoyment and, chances are, stored in a basement until they are rediscovered years later soaked through by a water leak, occupying space which could have been used by something else.

And there are ‘reference’ books: technical books which describe a technique, programming API, chip set, or other thing which will find itself out of date perhaps a half dozen years from now.

For the first type of book, yes: I want to own them in book form. I want to put them on my bookshelf on display, take them down and refer to them. They speak volumes as to the type of person I am and the type of person I hope to be, and they are books I hope to pass on when I no longer need them. My copy of Aho, Sethi and Ullman’s “Dragon Book” contains information which was valid twenty years ago and will be valid twenty years from now–even when new techniques are invented which improve on the basic design. Knuth’s books are also essentially timeless, even though today most modern programming languages incorporate many of the algorithms as part of a standard run-time library, if only so one can know how these things work. Numerical Recipes will always be useful.

But there are a number of other books which are not so timeless. Any book on writing software for MacOS 7 is simply a waste of paper and, the dogma that all books are timeless and important aside, really richly deserves to be turned into pulp and recycled into drink containers for fast food restaurants. While my copy of Logic: Form and Function is still quite useful after being first published nearly a half-century ago, my copy on the pre-election biography of George W. Bush (published in early 2000) was a waste of shelf space and was recycled years ago. And who really needs a book on Windows 3.11 software development and using DDE for exchanging messages between top-level windows?

So the concern that John Gruber has with respect to the Kindle may be well founded–but there are quite a few “disposable” books out there that really are ephemeral–and if they were to disappear a decade after they were published, would probably never be missed other than by those people who like collecting obscure historical footnotes.