For the purposes of this experiment, I consider my reading enjoyable if I don't want to give up and use the screen later out of frustration with mispronunciations, poor prosody, and interruptions. At the same time, I consider my driving safe if I do not look at, touch, or think about my iPad any more than I would the car radio. These requirements might sound quite difficult to satisfy. But, as I've suggested before and have once again found, you can get quite a bit of utility out of a combined audio display plus simple touch interface.

Training

To save life and limb, I first practiced using Instapaper via VoiceOver at home until I felt I had mastered the basic gestures. I don't remember exactly how long I spent on this training, but I'm sure it was significantly less than an hour.

Daily Setup

When time permits at home and work, I load up my Instapaper account with articles I want to read. Before I leave home or the office, I open the Instapaper app on my iPad and let it cache my articles for offline viewing. It usually finishes in a matter of seconds, long before I head out the door.

In my car, I pick the first article I want to read before I put the key in the ignition. (I might as well use the display when I can.) I prop my iPad up in locked landscape mode between the stick shift and the emergency brake handle on the center arm rest. I tap the home button three times to enable VoiceOver (a shortcut enabled in the Accessibility settings). Then I start the car, put it in gear, and start my drive.

Reading

Using Instapaper with VoiceOver requires very few gestures. A few one-finger swipes to the right skips me through the minimal UI at the top of the article. When I hear the title, a two-finger swipe down the screen starts VoiceOver reading the article continuously.

If I find my attention wandering, a one-finger swipe to the left backs VoiceOver up. If I hit a particularly dull section, a one-finger swipe to the right skips to the next paragraph. Another two-finger swipe down the screen starts VoiceOver reading continuously again from the new location.

Sometimes my commute is long or the article is short. If I finish reading the first article, I select another by doing the following:

• I feel for the top-left corner of the device with my fingers. This is no more complicated than searching for the buttons on my car radio.
• I touch the screen a little down from the top-left. This action selects the "Articles" button. If I miss, I tap around a bit more until I hear "Articles."
• I double-tap anywhere on the screen to activate the "Articles" button.
• I tap anywhere on the far right of the screen to select any article title in my to-read list. The list is large in landscape mode and hard to miss.
• I listen to the titles of the other articles in my list using one-finger, left and right swipes to navigate the list.
• I double-tap anywhere on the screen to select the last article announced.

As complicated as any of these sequences sound, I learned them with minimal practice. I can now perform them all without a single glance at the screen.

Discovered Settings

I did encounter a few gotchas along the way related to my default iPad settings.

Max-out the volume

I can hear VoiceOver well as long as the windows are up and I set my iPad volume at the maximum. Granted, my Civic's engine is a mouse compared to your V8 or Hemi. But the Civic's soundproofing isn't top-of-the-line either.

Lock the screen rotation

My commute in RTP is bumpy enough to cause the iPad's rotation to change if left unlocked. (I kid you not.) VoiceOver considers the switch so important that it stops reading, announces the change, and then often forgets what it was doing beforehand. Locking the rotation avoids this hassle.

Disable WiFi finding

With WiFi network finding enabled, my iPad manages to find quite a few networks during my drive. The network connection popup interrupts VoiceOver's reading when it appears and requires quite a few finger gymnastics to dismiss. After it's gone, I find that VoiceOver often forgets its place in the article. Disabling the "Use available networks" option sidesteps this problem entirely.

Curtain the screen

The iPad screen is an undesirable distraction and battery drain while driving. VoiceOver has a nice feature to counter it: the screen curtain. Triple-tapping with three fingers turns the screen black, saving both precious battery and human life.

Possible Improvements

My commute system is definitely not perfect. Here are couple thoughts on how it could be improved.

Skip the chrome

It would be great if a two-finger swipe down the screen started VoiceOver reading the article text immediately. Having the ability to hide the Instapaper chrome via a preference or to skip it using VoiceOver would add a little more "insta" to my setup.

Continue to the next article

A "Next" button at the end of an article would save me the complex gesture sequence required to pick another article. Such a button would be a useful shortcut during screen use of Instapaper as well, avoiding the out-and-in navigation to the articles list required today.

Outcome (So Far)

My continued use of VoiceOver plus Instapaper for over a month without a driving incident or foolish look at the screen is the best evidence I have in support of my hypothesis. I am finding the commute time quite convenient for attending to my Instapaper queue and my reading has been enjoyable.

Because of the success of the system during short commutes, I attempted something similar during two recent car trips lasting over 10 hours each. During both trips, I used VoiceOver to read many chapters of The Night's Dawn in iBooks. I found myself enjoying the reading for well over 6 hours each time as I drove through the night (10 PM to 9 AM). Surprisingly, the reading voice helped keep me awake rather than lulled me to sleep.

Doing More with Structured Navigation

With a little code, I think I could use VoiceOver plus Safari to go beyond reading simple, saved text articles. Imagine pre-processing your email, feed reader headlines, Twitter timeline, and so on into a single HTML document marked with simple structural elements like headings. Visit this page in Mobile Safari before leaving home or the office. Enable VoiceOver and set its Rotor Control to skip by headings. Start reading and use single-finger up / down flicks to navigate among the various sections.

I've also thought about tossing some JavaScript on the resulting page. Consider a section containing only email titles: a summary view of your morning inbox. A double-tap while VoiceOver reads the current title activates the standard "onclick" handler on the title's HTML element. Perhaps that click moves the focus to the body of the email stored somewhere else on the page. Maybe a double-tap on the body returns the focus back to the title.

I think I've only scratched the surface of what's possible. I intend to explore more.

No Liability Clause

I sadly think I have to say the following.

I accept no liability for any damages or losses suffered as a result of actions taken based on information contained herein. If you're dumb enough to read, compose email, play games, browse the web, etc. using your mobile device while driving, you cannot blame me when you crash and burn.

Consider these two snippets. The first shows chaining on a single deferred. The second shows chaining with a new deferred returned within the chain.

var d1 = functionReturningADeferred();
d1.then(function() {
    console.log('first success');
}).then(function() {
    // scheduled on the same deferred as the first
    // runs if the first handler completes without an exception
    console.log('second success');
});

var d2 = functionReturningADeferred();
d2.then(function() {
    console.log('first success');
    return anotherDeferredReturningFunction();
}).then(function() {
    // scheduled on deferred from anotherDeferredReturningFunction
    // runs when the second deferred's callback is invoked
    console.log('second success');
});

Try #1: Error handlers everywhere

I recently wrote some code in which my deferred callback handlers returned new deferreds for chaining, but where any deferred in the chain might have its errback() invoked. I wanted my handler chain to cease firing after the first occurrence of an error with one and only one handler invoked for that error. I naively started with the following recipe:

var d = functionReturningADeferred();
d.then(function() {
    console.log('first success');
    return anotherDeferredReturningFunction();
}, function() {
    console.log('first error');
}).then(function() {
    console.log('second success');
    return yetAnotherDeferredReturningFunction();
}, function() {
    console.log('second error');
}).then(function() {
    console.log('third success');
}, function() {
    console.log('third error');
});

To my surprise, when the very first deferred's errback() was invoked, the console output declared:

  first error
  second success
  third success

Likewise, when the second deferred's errback was invoked, the console output was:

  first success
  second error
  third success

I quickly realized my mistake: my error handlers did not return new deferreds. Therefore, each additional then() call in my chain registered handlers to be invoked by the success or failure of the previous set in the chain.

Try #2: Error handlers throwing errors

I next tried the following approach:

var d = functionReturningADeferred();
d.then(function() {
    console.log('first success');
    return anotherDeferredReturningFunction();
}, function(err) {
    console.log('first error');
    throw err;
}).then(function() {
    console.log('second success');
    return yetAnotherDeferredReturningFunction();
}, function(err) {
    console.log('second error');
    throw err;
}).then(function() {
    console.log('third success');
}, function(err) {
    console.log('third error');
    throw err;
});

This code showed improvement, but still did not have my desired behavior. An errback() on the initial deferred produced the following output:

  first error
  second error
  third error

An errback() on the second showed the following output:

  first success
  second error
  third error

After a little more thinking, I realized the same problem plaguing my first approach was in effect here. My error handlers were still not returning new deferreds. The chained handlers were still operating on the success or failure conditions of their predecessors.

Solution: One terminal error handler

Finally, I hit upon a pattern with the behavior I wanted:

var d = functionReturningADeferred();
d.then(function() {
    console.log('first success');
    return anotherDeferredReturningFunction();
}).then(function() {
    console.log('second success');
    return yetAnotherDeferredReturningFunction();
}).then(function() {
    console.log('third success');
}, function(err) {
    console.log('any error');
});

A errback() on the first deferred now resulted in the following output:

  any error

An errback() on the second produced in the following:

  first success
  any error

Why does it work?

Any error early in the chain falls through the chain until it reaches an error handler. Placing the error handler at the end of the chain guarantees it and it alone will fire after any errback() in the chain.

Try it yourself

I created a easy-to-run jsFiddle that demonstrates the second and third patterns mentioned in this post. Let me know if you find any other interesting behaviors.