The iPad is going to change the way we use computers. The change is huge, and it affects everybody. I’m going to tell you why in one word: abstraction.

Degrees of abstraction

We can differentiate between tasks that require high and low degrees of abstraction. When you take a pencil and draw a picture of a cup, that’s a low degree of abstraction. It looks like a cup; when you drew it you were thinking of an actual cup; and when someone looks at it they think of an actual cup, too.

If instead of a cup you draw the letter u, you invoke a high degree of abstraction. The shape that you drew contributes meaning in the context of its grouping with other shapes. The process of accumulating many abstractions into a larger meaning is immensely complex; we all learned it when our young brains were fantastically adept at this sort of thing. Even so, learning to read and write took years of study and practice.

Communicating through written language, without doubt, is the most complex and abstract task that we routinely perform. This is equally true for alphabetic and pictographic writing systems; pictographs arguably require less abstraction but more complexity because of the large number of glyphs.

Written text is not the only highly abstract activity we perform. Numbers are abstract, with arbitrary representations. Recall that the roman alphabet we use today long preceded the arabic numbering system. Dates and times are also abstract. “The first Thursday of the month” references a complete abstraction.

On our computers, we constantly switch back and forth between high- and low-abstraction tasks. As I write this, I pause from the highly abstract task of typing text to the non-abstract task of repositioning the window by dragging the mouse.

Now, pay attention here. Moving the window was low-abstraction because I have a low-abstraction input device. If I had no trackpad or mouse, I would have to move the window by typing keystrokes, which would involve quite a bit of abstraction. I don’t think I have ever moved a window via the keyboard. I have no idea how to go about it. I haven’t learned that particular abstraction, so I can’t move the window with the keyboard because abstractions are the only kind of input a keyboard understands.

Here’s the theorem: if the input method matches the abstraction of the task, executing the task is simple; if not, executing the task is complex. Or, if you like: the ease with which a task can be performed is directly proportional to the impedance match between the abstraction level of the task and the abstraction capability of the input system.

How computing devices handle abstraction

Now let’s do a quick review of the progress we’ve made in thirty years of interacting with personal computing devices.

Before Apple, computers used toggle switches for input and lights for output. Looking at such a device today one is repulsed by the high level of abstraction required to interact with it. You have to associate meaning with various patterns of light and switch state. Interacting with the machine seems almost impossibly difficult. In fact the process is probably no more abstract than our writing system; we simply don’t want to undertake the great effort required to master it.

The Apple computer designed by Steve Wozniak was the first personal computer to use a keyboard for input and a monitor for output. This provided an enormous increase in usability by replacing an unfamiliar system of abstraction with a system we already knew.

The keyboard is remarkably adaptable. You can use your typing skills, or you can learn some new abstractions and use the keyboard to play games or make musical tones or emulate a calculator. The keyboard beneath my fingers right now has seventy-eight keys. All but five (the keys for adjusting brightness and volume) are totally abstract. The four arrow keys I consider semi-abstract.

Because the keyboard is designed for high-abstraction tasks, it is terrible for low-abstraction tasks. Our human impulse to use our hands for grasping and manipulating objects must be replaced with an abstraction because abstraction is the only kind of interface that a keyboard provides.

That’s why the mouse-equipped Macintosh was so revolutionary. It gave us two input devices that provide input in both high and low levels of abstraction.

But the mouse is not ideal, is it? There’s still some abstraction involved—the physical object moved and the movement on the display occur in different places. Sometimes I have to wiggle the mouse in order to find the pointer of my display. When I try to draw with the mouse I usually see the brush going a different place than I wanted. After all, the mouse is an extension of the hand, not the fingers. You wouldn’t want to resize a picture by executing the pinch gesture with a mouse in each hand. Other low-abstraction input devices such as trackpads and drawing tablets address some of these limitations. Still, the input sensor is external to the display, so there is necessarily some abstraction involved, and in any event you have to manipulate at least two different devices to provide both high- and low-abstraction input.

The ultimate low-abstraction devices are our fingers, and that of course brings us to the iPhone. Cocoa Touch provides the sense of manipulating objects directly with your fingers. That’s a very satisfying thing to do, and perhaps explains why I prefer to do some tasks on my iPhone when I could do them just as effectively on my Mac. Because the input occurs at the same location as the result, nearly all the abstraction is removed. For low-abstraction input, the touch screen beats the mouse hands down.

Sometimes we forget that the touch screen is not the only input system on the iPhone. The accelerometer turns the entire device into an input sensor that responds to motion and orientation in three-dimensional space. Together the two systems provide a wealth of low-level abstractions that far exceed the capabilities of the input systems on desktop and laptop computers. There are no peripheral objects to capture input; on the contrary, the notion that input is distinct from output all but vanishes, merged into a single concept that embraces output, input, and the computing device itself.

According to our theorem, the iPhone should be ill-suited for high-abstraction tasks. And it is. I, for one, cannot type with two thumbs. A pocket-size device is simply too small to accept rapid input from ten fingers. For better or worse, that’s how we provide the complex input required for high-abstraction tasks: we type on a keyboard. And you can’t do that on an iPhone.

How the iPad handles abstraction

To recap:

Device	High-abstraction input	Low-abstraction input
Apple II	Excellent	Terrible
Mac	Excellent	Good
iPhone	Poor	Outstanding

As of 27 January 2010 we must add this:

iPad

Outstanding

Outstanding

With the iPad, we have a device that provides the outstanding low-abstraction input of the iPhone, and high-abstraction input that is superior to the Mac. (People who think the iPad is a big iPhone have it backwards; the iPhone is a miniature iPad.)

At the product launch event, we watched people drive a car by turning the iPad like a steering wheel; create a presentation by dragging slides around with a finger; and type text on a qwerty keyboard. All this was done on a device that has no peripheral attachments—a device that, like the iPhone, conflates the notions of input, output, and the device itself.

That’s why the iPad is going to change the way we interact with computers. Most of the recent clatter misses the point. Cameras and tech specs and book prices are the trees; the way we interact with the device is the forest, and I hope people start to see it.

Why do I deem the iPad keyboard superior to the one I’m typing on now? Primarily because the iPad is not limited to just one keyboard. The iPad introduces the concept of different keyboards for different tasks. In the demo we saw the traditional qwerty keyboard, what we might be tempted to call a numeric keypad, and a delightful innovation: a keyboard for inputting date and time information. (“Keyboard” is something of a misnomer on the iPad, as there are no keys; maybe “button board” or just “board” is a better term to denote an infinitely configurable system of processing highly abstract input.)

It’s no coincidence that those three keyboards correspond to the three abstract systems I described at the beginning of this essay. These alternative input systems seem to live in another dimension, popping into our existence only when we need them. We’ll see more of them in the fullness of time. I look forward to the button board designed for musical composition.

The virtues of the virtual keyboard

Some might object that typing on a glass keyboard will never rival typing on a regular keyboard. Let’s reason this through. There are three factors that define a typing experience: the distance that the key travels, the force required to initiate key movement, and the cushion or give when the movement reaches bottom.

It’s easy to see where key travel has been heading.

Back when typewriters were made of iron, the key travel was as much as two inches. Electric typewriters reduced key travel to about three-eights of an inch. (Just guesses; I don’t have either one, and I don’t know anyone who does, so I didn’t measure. But I’ve done quite bit of typing on both electric and mechanical typewriters, including one so old that when you pressed the shift key it raised the carriage instead of lowering the keys, and these numbers seem right.)

I took a ruler and measured the key travel on some keyboards I have around the house. Here’s the key travel data, measured in thirty-seconds of an inch:

Very old mechanical typewriter: 64
1960s mechanical typewriter: 32
Electric typewriter: 12
Keyboard from first-generation iMac: 6
2002 Microsoft keyboard: 5
Keyboard from iMac G5: 4
Keyboard from new iMac: 3
Keyboard on MacBook Air: 2
iPad virtual keyboard: 0

Every reduction in key travel has improved the typing experience. In my view, the iPad marks the inevitable end of a progression that has been happening for the last hundred years. Just as 6/32 seems like way too much travel to me now, I’m sure that anything greater than 0 will seem too much after I’ve used the iPad for a while.

The force required to execute a keystroke cannot be measured without an iPad, and even if I had one I wouldn’t know how to measure it. I expect it is very small, like the iPhone. At any rate, I’m sure that touch sensitivity can be tweaked by the operating system, or possibly by user preference, and the default value will be much less than the value for a mechanical keyboard.

The landing experience, in my unschooled opinion, cannot be judged apart from the force exerted. The harder you have to push to make a key move, the more you need a soft landing. As we grow accustomed to typing on glass, I think we’ll soften the force we apply to our fingers and the experience will be quite natural and painless. I’ve never heard anyone complain that using an iPhone makes their fingertips sore.

Furthermore, we won’t need a desk to set the iPad on. An iPad resting in your lap will absorb quite a bit of typing impact. Typing on the iPad won’t be like drumming your fingers on a glass tabletop.

I also suspect that the diminution of key travel and key force over the years has changed the way we position our fingers over the keys. In the old days, you had to type with the tips of your fingers because that was the only way to exert enough force to execute the mechanical movement required. I still remember jabbing a stiffened little finger into the shift key in order to move the entire keyset. When little or no force need be applied, we can type with the balls of our fingers, which have more natural cushion than our fingertips.

The world has changed

The best low-abstraction input system the world has seen, and an infinitely adaptable high-abstraction input system, in a product that is a simple thin rectangle—how that can be anything but revolutionary?

It’s going to be a long sixty days.

Pagehand.com has just released our second application: LaunchCodes, a utility that helps you open files in the creator code application rather than the default application.

I’ve written about my intense disagreement with the decision to drop creator code support in Snow Leopard. Fellow developer Patrick Thomson and I teamed up to produce a tiny, unobtrusive utility that makes Snow Leopard respect creator codes as God intended.

Our objective was to re-introduce creator code application binding without modifying or replacing any system components. Snow Leopard preserves creator code metadata (it must, because the same volume might be accessed by 10.6 and pre-10.6 Macs), so all the utility has to do is intercept the appropriate Apple event and send it to the application identified by the file’s creator code.

Because we refuse to tamper with the OS, our solution is not a drop-in replacement for the pre-10.6 behavior. When you right-click a file with an extension recognized by LaunchCodes, you see that the default application is LaunchCodes rather than the creator code application. And LaunchCodes doesn’t intervene in every double-click on every file; it works only with the extensions that you’ve assigned to it.

LaunchCodes has some features that the pre-10.6 behavior lacks. In fact, I like our LaunchCodes behavior better than the old behavior. The principal feature is that you can instantly turn LaunchCodes on and off via a menu bar icon. If you are engaged in a task where you really do want all files with a certain extension to open in the default app, just one click disables LaunchCodes and returns you to the standard Snow Leopard behavior.

Configuring LaunchCodes on a file extension basis might at first seem an annoying limitation, but in practice it’s a benefit. If two or more applications can open the same file type, it’s a sure bet that the file type is associated with an extension. As a practical matter there are very few extensions that present conflicts between the default application and the creator code application. Most people who complain about the lack of creator code support mention only one or two extensions that disrupt their normal workflow. For many people, configuring LaunchCodes to work with only one extension might be all they need to get Snow Leopard to present the same user experience they enjoyed with previous Mac operating systems. Keeping LaunchCodes out of the picture when it is not needed helps to maintain its tiny footprint.

Even if you like creator code application binding, there are times when it can get in the way. If you open files that were created by other users, as is common when accessing files on a server, you might not want to use the same application that the other user chose when creating the file. For example, if I like to create .html files in TextMate, and a colleague likes to use BBEdit, I do not want to launch BBEdit when I double-click one of his files. With LaunchCodes, you can confine the use of creator codes to files that you created; if this preference is on, and you did not create the file, LaunchCodes deems it to have no creator code and sends the file to the default application.

Finally, LaunchCodes lets you see the creator code metadata for a file. If a file opens in the default application instead of the application that created it, like as not the creating application did not set a creator code. (Alas, Apple’s 10.6 apps are guilty in this respect.) With LaunchCodes, you can see what is happening by option-dragging the file to the LaunchCodes application icon. LaunchCodes will show you the file’s creator code, whether you own the file, the application that will open the file, and the reason why that application was chosen.

We’ve priced LaunchCodes at only $4.95. A few aspects of development were surprisingly tricky, and the app required much more development time than I anticipated. I have no idea whether LaunchCodes will be a commercial success, but it’s already clear that a lot of people are very grateful to have it.

Recently I received feedback from a blind user complimenting Pagehand on its accessibility. This surprised me because accessibility is one of those things I intended to look into one day, and I had not done anything special to make it happen.

Curious, I put Pagehand through its paces in VoiceOver. The exercise left me horrified. Far from deserving praise from this user, I instead deserve severe disapprobation for neglect.

It took a while (and some great help from the accessibility mailing list) to figure out how to fix the worst of my transgressions. For the benefit of others who, like me, are a blank slate when it comes to accessibility support, I’d like to share what I’ve discovered so far.
Read more »

Update: please see our post about LaunchCodes

I’m loathe to criticize Apple, I really am. There’s no other company I would allow so much control over my life. I sit here every day happily coding away in Cocoa and, for the most part, loving it.

But I have to say that Apple has made a huge, dumb mistake in dropping creator codes from Snow Leopard.

Years ago when I was a middle manager in an organization, the people in my division had Macs. We were doing very well until a new boss replaced our Macs with PCs. Many frustrations followed, not least being unexpected behavior when double-clicking on a file.

“Windows is not as smart as Mac,” I kept telling my charges. “When you double-click a file, the Mac knows what do because the file has a hidden creator code. Windows has only the extension to go by.”

Now it is 2009 and when it comes to double-clicking a file, OS X is as dumb as Windows.

As I write, I have two Macs before me, one running 10.5 and the other 10.6. On the 10.5 machine I do this:

In BBEdit, make a new file and save it as test.txt.
In BBEdit, make a new file and save it as test.html.
In BBEdit, make a new file and save it as test.css.
In Nisus Writer Pro, make a new file and save it as test.rtf.
In Pixelmator, make a new PNG file and save it as test.png.

When I double-click each of those files:

test.txt opens in BBEdit.
test.html opens in BBEdit.
test.css opens in BBEdit.
test.rtf opens in Nisus Writer Pro.
test.png opens in Pixelmator.

That is exactly the behavior I want.

Now I repeat this exercise on the 10.6 machine. The results:

test.txt opens in TextEdit.
test.html opens in Safari.
test.css opens in DashCode.
test.rtf opens in TextEdit.
test.png opens in Preview.

Snow Leopard takes one of the Mac’s most elegant features—launching the correct application for a file—and desecrates it.

This situation is particularly egregious with respect to PDF files. Let’s say a PDF file contains application-specific data (as the PDF spec allows). When I double-click that file, which application do I want to open it? Let’s take a wild guess: I want to open it in the application it was intended for. I want to open it in the only application that can read its app-specific data. I sure as hell don’t want to open it in a generic PDF reader.

I can hear Preview smirking, “All your PDF are belong to us.”

I never create an html file with the intention to view it right away in a browser. I create it because I am working on a web site and I’m going to deploy the file to a server when I’m finished. The same goes for .css files and images.

If I choose a specific text editor from among the several on my Mac when I create a new .txt file, that’s a pretty good clue that I want to use that same editor to edit that file. Does anybody create a text file in one application with the intention of editing it in another?

Nisus Writer Pro and TextEdit both create .rtf files. I’ve never had a problem with that. If I create a .rtf file in Nisus, then I’m likely do complex things with the file (tables, columns) and I want henceforward to open it in Nisus. If I create a .rtf file in TextEdit, then it’s bound to be a simple file that I can keep editing in TextEdit. I want, forever, to open the Nisus file in Nisus and the TextEdit file in TextEdit. Is this concept somehow challenging to understand?

I would like to know what problem Apple thought they were solving by dropping creator codes from Snow Leopard.

The closest thing to an explanation I’ve been able to find is this statement from an Apple engineer:

“When I save a JPEG file in an image editing app, and later open it, I expect it to open in Preview (or whatever my default image viewer is), not the image editing app.”

Now, that engineer is a man whom I know, like, admire, and respect. I hold him in the highest esteem. But in this case, he is just comically wrong. Does he really think that workaday blokes who create a file always get all their work done in one go, and never have to edit the file again, and go on their way rejoicing and henceforward opening the file in a generic viewer?

Want some salt in that wound? Listen to this:

“For documents that are recognized by multiple apps, the user has the power to bind a particular document to any app they wish, using the file inspector in Finder. So at least for this purpose the creator code is not needed.”

Two words come to mind: puh leez. In what universe do people create a file and immediately, whistling with merriment, go to Finder and change the application binding for that document?

When you’ve used a Mac for over twenty years, and it has always done the right thing, and now it often does the wrong thing, the feeling is a lot like betrayal.

It is still true that daily I sit here happily coding in Cocoa. But every day I double-click a file that opens in the wrong app, and then I seethe with the fury of the burning sun. Apple, how couldst thou?

If I made a mistake like this, I’d be mortified. And nobody would buy my software. Nor should they.

Microsoft retail stores are going to open soon, and I can’t wait.

I simply love going to an Apple store and browsing through all the cool Apple hardware: Macbooks, iMacs, the Mac Pro, Time Capsule, iPods, iPhones.

So when the Microsoft store opens, I want to go get my hands on all that cool Microsoft hardware, like Read more »

For the last few weeks I’ve been beta-testing my friend John Eddie’s iPhone app, Years. It’s now been released. I recommend it.

Years quickly became the iPhone app I use most frequently. I hadn’t realized how often I simply want to look at a year’s calendar. Not a month, not a week, not a bunch of detail about appointments, but just the current year, scrolled so today is in the middle.

That’s exactly what Years does. It defaults to the current year, and allows you to view other years. There’s a month view where you can scribble on a date to mark it.

Years points up the problem with most calendar apps: they do too much. There’s no end of enhancements you can add to a calendar: appointments, alarms, view as list, and so on. Those are useful features and I’m grateful that Calendar provides them.

The brilliance of Years is its restraint: it recognizes that most of the time, I just want to look at a calendar. Apple’s Calendar app displays at most one month at a time, so I frequently have to flip between months. It’s not really a calendar, but rather an appointment book.

Years reminds us that some useful things work best when they remain simple. How many weeks until Christmas? What day of the month was last Friday? How many days until we leave on our trip? That’s the sort of question I ask every day, and the answers have never been as easy to find. With Years, there’s no punching around to get the correct month and layout. It just pops up the calendar I want.

I wonder how I got along without it.

When I learned that Steve Jobs received a liver transplant, I realized that I had not signed the organ donor card on the back of my drivers license.

I’ve often wished I could thank Steve for fostering this wonderful Apple world in which I spend so much of my life. I don’t imagine that sending him a get well card or a bunch of flowers would do either of us any good. So I’ve resolved to sign up to be an organ donor.

Steve’s health situation brought home to me how many people have to watch their life slip away day by day while hoping desperately that an organ will become available. We’ve all read about the lengthy waiting lists. Invariably, the lists have been reported as mere numbers: 80, in this state, 200 in that state, and so on. But this is not about numbers, is it? It’s about human lives, about real people whose approaching death can be prevented only by the kind act of a stranger.

If you are a Mac fanatic, I encourage you to resolve this moment to sign an organ donor card.

I have just returned from the best conference of all time. NSConference 2009, in Hatfield, U.K., was perfect in so many ways I hardly know where to begin.

The facility: The deHavilland Conference Center seem to have recruited their employees from the Society of Happy Helpful People. The room was just right, the food was excellent, the beer was real, and my stay there was delightful.

The speakers: I’ve written about how programmers are smart. The speakers were the smartest of the smart. The presentations were engaging, informative, useful, and well planned.

The organizers: The entire event reflected Scotty’s infectiously jolly character. As it turns out, he’s quite an organizer, too. For a first-time event, the smooth and efficient operation was remarkable. His motto could have been, “All needs anticipated, all preferences accommodated.”

The design competition: The conference closed with an inspired idea: two teams of developers were given a set of requirements and had to design, but not build, an application. It was all the fun of Iron Coder without the work. Scotty kept saying the idea might be a disaster. It wasn’t.

The attendees: NSConference 2009 was populated by developers from all over Europe, with a few North American infiltrators added to the mix. What made the group especially cohesive was our shared experience with the loneliness of being a Cocoa developer. Here in Kentucky I am certainly never going to meet another Cocoa developer, and I’m sure my European counterparts know the feeling. We don’t have a NSCoder Night to attend. Our wives and girlfriends might listen sweetly as we talk about AppKit, but it’s not the same, really. So, you throw a hundred of these guys together and you can be sure they are going to have a great time.

All the folks I met at the conference write code and inhabit a spot somewhere along the trajectory of application development: from the thinking about it stage, to the actively working on it stage, to the selling it and making money stage. At other conferences I’ve attended there were writers and CEOs and representatives from big companies mingled among the coders. At NSConference, we were all coders.

And that might explain why, from the opening moments of the conference, we were all talking about next year. It’s just inconceivable that such a wonderful event would be a one-off; there simply has to be one next year. Banks may fail and economies may sour, but please oh please let there be NSConference 2010.

When the taxi driver took me to the train station on the morning after the conference, he shook my hand and wished me a pleasant journey. It had to end just that way. The taxi driver’s little pleasantry was emblematic of the time I spent in Hatfield.

The friendships forged at NSConference 2009 will last a very long time. Thanks, Scotty.

Funniest thing I’ve read recently: today’s letter to the editor from a guy complaining that our local paper is too liberal:

In a little over two months, President Barack Obama’s administration committed more missteps and faux pas than in all of Bush’s eight years, yet hardly a word of this is mentioned in your paper. If it wasn’t for Fox News, I wouldn’t have known about it.