Recently I recorded an hour-long video (12 gigs) on my iPhone 4s. I didn’t like the result, so I trashed it. All my iPhone apps thought it was deleted, but it was still there. It showed up as “Other” in iTunes. iMovie could see it and import it. It was an orphan file, invisible to iPhone apps and iTunes, impossible to delete, and taking up 12 gigs of storage on my iPhone.

I tried restoring from a backup, but the file had got into my backup and simply reappeared, orphaned as before.

The Apple Store geniuses, to my surprise, could not fix it. I thought they might have a utility that can access the iOS file system. They said that I would have to restore to factory original, and re-install all my apps. Of course, that would lose all my app data.

If a new iPhone suddenly loses 12 gigs of storage, Apple should fix it, in my opinion.

I fixed it myself and here is what I did. This post is as much a reminder to myself as a guide for others. If you botch your phone, don’t blame me.

First, I located the offending file in my backup. The backups are in ~/Library/Application Support/MobileSync/backup/. In my case it was easy to find the file by sorting the contents of the backup folders by size. I simply dragged the 12-gb file out of the folder (and later removed it).

Then I restored the iPhone to its factory condition. At the end of that restore, I told iTunes to go ahead and restore from the latest backup. iTunes flashed a brief message about the backup being corrupted, but it proceeded anyway and restored all my data.

The takeaway point here is that simply removing the file from the backup and then restoring from the backup does not remove the orphan file. You have to do a clean restore and reset the iPhone to factory condition, delete the orphan file from the backup folder, and then restore from the backup.

There’s been a spot of blithering and blabbering lately about whether iOS developers ought to start developing for Android. The tenor of the Android argument seems to be that big numbers are good. “Ultimately, application vendors are driven by volume,” said Eric Schmidt.

That statement might make sense if you think that all software is written by big soulless corporations whose only motivation is profit. You can pretty easily knock that idea in the head. The App Store sells half a million apps. Just browse through them to see all the apps from small, independent developers. A quick look at successful apps—say, the Apps Starter Kit—shows that indies do very well. Excluding Apple itself, the only company with more than one product in today’s starter kit is the one-woman shop Sophiestication.

I don’t know whom Eric Schmidt thinks writes software, but it’s clear to me that a one- or two-person company has plenty of things to think about other than pure profit.

For one thing, if most indie developers were totally income-driven, they would never have chosen to become independent developers in the first place.

John Gruber pointed out that “developers like iOS. They use and prefer iPhones and iPads personally, they like Cocoa, and they like the App Store.” Makes sense to me. Marco Arment noted that going Android means investing months of time to learn the platform, doubling the support workload, doubling the maintenance workload, satisfying the requirements of three additional marketplaces, and maintaining compatibility with an ever-changing array of devices.

We all know that brilliant engineers like Jeff LaMarche write for both platforms. I think guys like Jeff are in the minority; the independent developers whom I know (as opposed to contract developers) eschew writing for Android because they don’t want to or don’t need to.

Even if we posit that iOS developers really do need more sales, and are willing to double their workload to get them, the principal question is not “Will I make more money by porting my app to Android?” but rather “Will I make more money by developing another iOS app?”

Some writers have chided Apple for releasing Siri as a beta. They claim that the bugginess and lack of polish connoted by the word “beta” evidence a breach of elegance that is unworthy of Apple.

I wonder who would complain if Siri had been called “Siri 1.0″ instead of “Siri beta.”

Consumers have, by now, seen enough 1.0 apps for the term to have its own connotation. When I see a 1.0 app, I (and I expect many others) expect something that is not as feature complete as one would really like it to be, with perhaps some infrequent bugs and an insufficiency of real-world testing. I expect the 1.0 app to be merely the first in a string of releases that will over time bring the app to completeness. I accept that developers cannot keep their projects in beta forever, and at some point have to ship the product, imperfect though it is.

I’ve bought my share of 1.0 apps and on the whole I’m grateful for the use of them in their 1.0 condition without having to wait for the more complete version.

In short, I expect more from a 1.0 app than from a beta, but I do not expect a lot. Siri, with its foibles, works quite well enough for me at the moment. Far be it from me to tell how Apple how to market its products, but one has to wonder if using “1.0″ rather than “beta” would have nipped some criticism in the bud.

After a couple of weeks with my iPad, I have to say that I am disappointed with its virtual keyboard.

I never learned touch typing (whatever that means; is there another kind? Slam typing?). I get along very well without thinking about which finger goes to which key. On the iPad, my fingers go to the correct place as accurately as they do on a real keyboard. The loss of tactile feedback doesn’t slow me down at all, except for the shift key, as I will describe in a moment.

What slows me down—way down—is typing anything other than lower case a to z, space, comma, and period. Those, of course, are the characters you can type with one keystroke. Anything else requires either the shift key or a switch to a different keyboard layout, accomplished by two large keys on the main keyboard and two small keys on the auxiliary keyboards.

The shift key slows me down because Apple has been very sparing in representing the state of the key. Pressing the shift key draws its arrow with a blue fill. That’s a curious choice, because when my finger is on the shift key I cannot see its arrow at all. Yes, there are two shift keys, but my eyes want to go to the one under my finger.

The glyphs on the keys are all upper case. I would have liked the key glyphs to be lowercase, switching to uppercase when the shift key is pressed. That would tell me immediately what is going on, even if some keys are obscured at the moment.

Most of my irritation with letter case comes from Apple’s attempt to press the shift key for me, for example after a full stop. Even with auto capitalization turned off, the keyboard still tries to type uppercase letters when I don’t want it to. For example, if I type “In summary, I propose that” and decide I want to change I to we, when I delete the I the shift key is engaged and I end up typing We instead of we.

The auxiliary keyboards slow me down because they do not stay on screen long enough for me to learn where all the characters lie. To type a plus sign you have to tap the .?123 key to bring up the numeric keyboard, then tap the #+= key to bring up punctuation keyboard. By the way, .?123 is an odd label. You can already type . and ? from the main keyboard.

To type a + requires four taps: the .?123 key, the #+= key, the + key, and finally the ABC key to get back to the main keyboard. At that point my concentration is gone, and whatever I was going to say next has to be thought out again.

After a couple weeks I have made no progress toward learning the whereabouts of any auxiliary keyboard keys other than the numerals at the top of the numeric keyboard.

Many people, perhaps most, type a ! or ? more frequently than an apostrophe. I am not among them. It takes three taps to get an apostrophe in place. And although the proffered glyph is a properly curved apostrophe, the rendered glyph is a plain straight abomination.

Worst of all, despite all those keyboards there are no arrow keys. Selecting a single character by dragging, or placing the insertion point at a particular spot, is just not easy. I use arrow keys all the time on a regular keyboard, and I want them on my virtual keyboard.

One of my big frustrations vanished when I discovered that you can type an apostrophe by flicking the comma key upward. What a clever and useful feature! How did I miss it? Was it mentioned somewhere? At any rate, I submit that the flickable key idea can be incorporated into the entire keyboard in such a manner that the virtual keyboard rivals, and perhaps excels, the tactile keyboard.

Here’s how it would work.

1. Every key would respond to up, down, left, and right flicks in addition to taps and holds (a hold pops up a menu for certain keys, showing diacritical options).

2. The four characters produced by the flicks would be drawn on the key.

3. The shift key and the auxiliary keyboards would be removed.

4. Taking the place of the shift and keyboard keys would be keys for managing the selection and cursor position, and keys for families of quotation marks, parentheses, and hyphens.

Forgive me, but I cannot resist calling these flickable keys flickeys.

Here’s how a flickeyboard might look (click for a full size view):

Obviously, this is a US flickeyboard; localized keyboards would differ in the placement of some symbols. How it works should be self-evident. A few ideas merit a closer look.

Flicking down on any letter renders it in uppercase. Flicking downward with two or more fingers anywhere on the keyboard toggles Caps Lock, which is identified by swapping the uppercase and lowercase labels on the flickeys.

The top row of flickeys mimics the operation of the top row of keys on a standard keyboard. Numerals 1 through 0 are right where you expect them to be; you simply flick upward to type the numeral. Flicking to the left produces the symbols associated with holding the shift key while typing a number key. Flicking upward with two or more fingers swaps in a numeric keypad.

Flicking to the right produces some symbols that appear on the iPad punctuation keyboard. Currency symbols are grouped together; in a happy coincidence the yen symbol appears with the letter y and the euro symbol appears with the letter u. Multiplication, division, addition, and equals symbols are placed on three adjacent flickeys.

In this mockup, the second row of flickeys has not been assigned any characters. That’s 27 possibilities.

A quotation mark key replaces the left shift key. With one key you can easily type the four typographer’s quotes, or the abominable straight mark. This, I submit, is an improvement over the shift-option-bracket combinations used on a Mac desktop.

Flicking upward on the bottom row of letters mimics the option key combinations used to type diacritical marks.

At the right of the third row, three punctuation keys provide related symbols. The comma and semicolon use the same flickey. Full stops—period, exclamation, and question mark—appear on the period flickey, as does the colon. The rightmost flickey provides hyphen, en hyphen, em hyphen, and underscore.

To the right of the space bar, two keys provide matching delimiters: parentheses, brackets, braces, and angle brackets.

The space bar shows a command symbol to denote that holding the space bar in conjunction with a another flickey mimics the command key; space-z invokes undo, space-v invokes paste, and so on.

The leftmost key on the bottom row does nothing when tapped; it responds only to flicks, and it moves the cursor left and right, or line up and line down. Up-left and down-right flicks mimic the Home and End keys.

The select key (which is not a flickey), when held, turns any cursor movement into a move-and-select. It works in conjunction with the key to its left, or with taps in the document. For example, you can select from the cursor to the beginning of the line by holding the select key and tapping at the beginning of the line. In other words, it creates selections exactly as the shift key does on a regular keyboard.

If users find the layout too busy with all those labels, one possible solution is to toggle the visibility of the flick labels by means of an added key or a flick. Another is to put an opacity slider to the left of the a key.

The flickeyboard takes advantage of the iPad’s ability to do things that cannot be done on a conventional keyboard. A single, simple, intuitive movement replaces the typewriter-era paradigm of holding a modifier key while tapping a character key. You see all the characters all the time, unlike physical keyboards that require a keyboard viewer application to show you where some characters hide.

It shouldn’t be too terribly difficult for someone to write an app that would let us try out this concept. A github project, perhaps?

(Edited 24 April 2010 in response to Uli’s comment.)

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:

As of 27 January 2010 we must add this:

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.

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 »

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 absolutely love TedTalks. They’re perfect for viewing on the iPhone, and easy to obtain as podcasts. But the old iPhone treated them as audio files if you tried to move them into a playlist. You had to sync all the podcast episodes, and they can accumulate very quickly.
Read more »