Instapaper Blog

Preview: Instapaper on iPad

I’m probably supposed to keep this secret and build everyone’s anticipation to hype this up. Oh well. Maybe I’ll do that for the Instapaper edition for Apple’s next revolutionary computing platform.

First: Instapaper is definitely coming to iPad.

Second: Instapaper is coming to iPad very soon. Possibly even on day one — yes, I’m going for it — but that’s optimistic.

Third: Instapaper Pro will be a universal iPhone/iPad application. That means that you only have to buy Instapaper Pro once to have it on both devices, and the iPad edition will be available to all Pro purchasers at no additional charge when it’s released.

You probably have some questions.

What does it look like?

The short answer: It looks like Instapaper Pro, but bigger, and with slight interface tweaks and redesigns where appropriate.

The longer answer: It looks like this.

See? No huge surprises, except maybe that I changed to dark toolbars. No multi-column reading, no fake book-page animations, and no giant newspaper graphics.

I’ll probably move the reading-view toolbar to the top in the future, like most iPad apps, but I don’t yet know how I’ll hold the iPad when reading.

The biggest visual changes were made to the landscape-orientation list screen:

Honestly, I’m not crazy about the iPad’s split-view mechanics from the videos, especially the way they differ between portrait and landscape. But this is how Mail works, and Instapaper has always been navigationally designed like Mail. (Tip: If in doubt, follow Apple’s lead.)

Plus, exposing the folders more obviously in the interface will promote usage and reduce requests to implement features that I already have. (You’d be surprised.)

Everything you’d expect from Instapaper Pro is there, including dark mode, pagination, and adjustable fonts:

Instapaper Pro on the iPad is still the same app: you already know how to use it. It has just been modified in a few places to better fit the form factor and platform paradigms.

Why is it designed this way?

When everyone else was stalling their iPhone development for months in order to redesign entire applications for the iPad, I made the obligatory cardboard prototype and mocked up a bunch of radical interface departures.

Ultimately, none of them were very practical. Some worked well, but only with ideal content (which, in practice, is rarely the case except in the Editor’s Picks folder). And I didn’t want to commit to any huge risks because I don’t have an iPad to test them on.

Once I nailed down a few definite iPad-friendly features, I realized that I could port all of them to the iPhone version of Instapaper Pro. And if I did that, all of my customers (and I) could use these great new features now.

So, rather than rewriting my entire interface for the iPad over the two months that we’ve had, I spent the first few weeks finishing and launching the 2.2 update to my iPhone app, a major undertaking that added a lot of great features, using techniques that would allow me to easily adapt all of the features to the iPad. And I spent the remaining time adapting my interfaces, rewriting or modifying where necessary, for this new platform.

I’ll experiment with more radical interface changes in the future, once I’ve had time to actually use the iPad for a while and figure out what really works on it, what doesn’t, and what the hardware can handle.

Why now?

Developers have been put in a difficult position: if we submit our applications for review and sale before we’ve ever used an iPad, we can be in the App Store on (or near) day one. But we won’t have had a chance to test our applications on a real iPad — we’ll just need to rely on Apple’s reviewers to tell us whether they work. This is risky, since we don’t even know some critical details about the iPad yet, like how much RAM it has or how quickly it will execute our animations and number-crunching.

So we’re left with two options:

1. Release the app for day one, but it might be buggy or non-ideal in a few areas.
2. Release the app after we’ve had a chance to test extensively on a real iPad, but it may not be available for many weeks after the iPad’s launch, during which time our current and new customers will be clamoring for a native version, and they’ll be stuck using the pixel-doubled version.

The second option seemed more sensible at first. That was my plan at the beginning.

But then I saw the pixel-doubled version of my app in the simulator.

It sucked, and it was completely unusable by my standards. I don’t think I’ll want to run any pixel-doubled apps on my iPad in practice.

As far as I’m concerned, Instapaper isn’t really available on the iPad until it’s native. (This also influenced my decision to make it a universal iPhone/iPad app: I don’t want anyone subjecting themselves to the iPhone edition in pixel-doubled mode.)

While I could have taken the conservative option and waited until a month or two after the iPad’s release before launching Instapaper for it, an iPad without native Instapaper Pro is not a device I want to own.

And I’m buying it on day one.

So I’m doing my best to make the day-one submission deadline. Even if the first version ships with a few edge-case bugs, I’d rather have that on my iPad for a couple of weeks than no Instapaper at all, and many customers have told me that they feel the same way.

This is a risky decision, but I feel that this is the right thing to do for me and my customers, so I’m going for it. If any bugs do crop up in the first version, I appreciate your patience and trust that I’ll fix them quickly. Thank you.

Bugfix update 2.2.1 now in App Store

Instapaper Pro 2.2.1 is now in the App Store.

This is a bugfix release that fixes crashes related to dictionary lookups, the in-app browser, missing articles, rotation locking in the folder view, and sending to Tweetie.

Scrollback

Before Instapaper Pro 2.2, I got frequent emails from customers who were upset that they had inadvertently tapped the status bar, which scrolls to the top of the article and loses their position. I understood completely, since losing your read position is a form of minor data loss.

Most of them were unaware that this is a systemwide gesture on the iPhone OS: if you tap the status bar in any screen that contains a table view or web view, it scrolls to the top. It’s quite useful if you know about it and expect it, but alarming — and, in Instapaper’s case, destructive — if you don’t.

Application developers can selectively detect or disable this gesture for most scrolling views except web views. The best I could do, and only after a lot of poking around, was to either disable it entirely (which is bad for people who actually use it), or detect when it was initiated but without the ability to selectively prevent it. So, when I detect the status-bar tap, I temporarily store your position, wait for the scroll-to-top to execute, and give you this option in the bottom toolbar for 5 seconds:

Including this wasn’t a clear-cut decision for a few reasons:

• It differs from systemwide behavior, which is usually the wrong choice.
• Implementing it without calling undocumented methods was very difficult and took a surprising amount of work. The first submission of Instapaper Pro 2.2 was rejected for an undocumented call for this feature that I had forgotten to remove.
• There’s no good word to put on that “Cancel” button. (I’ve actually canned features for reasons like this.) “Cancel” itself is problematic — are you canceling the scroll-to-top, which the right button already does? — but it was the best I could come up with for now, and it’s automatically localized to different languages by the OS. (The runner-up was “Stay”, which I may consider switching to in the future.)

But preventing user data loss — in this case, the scroll position — is so important that I had to include it.

So far, this has proven worthwhile: I’ve already received thank-you messages from a numerous users specifically about this feature. I was afraid nobody would notice it, but it looks like that was unfounded.

I elected not to use the “shake to undo” gesture for this feature. Most iPhone owners don’t know about that gesture, and even for those who do, there would still need to be something to tell them that undoing the scroll-to-top was even an option for them in Instapaper.