Jakob Nielsen’s “cards vs. scrolls” analogy is interesting for iPhone and iPad usability decisions.
Instapaper Pro’s reading view presents a scrolling interface, but pagination temporarily and dynamically splits it up into virtual pages (like Nielsen’s “cards”) for easy reading. The critical difference between Instapaper and other reading apps on the iPad, including iBooks and Kindle, is that Instapaper’s pagination can be toggled off and switched to scrolling at any time.
To me, this made sense: web pages are Instapaper’s content, and they’re natively long, unpaginated columns. The long column is the actual form of this content, and the pagination is simply a more convenient form of scrolling tacked on top of it.
Instapaper enjoys a few advantages as a result of this structure: for instance, it’s the only paginated reading app I know of that lets customers select a block of text that spans across a page break1, because as soon as a text selection is started, Instapaper temporarily turns off pagination and allows the content to be scrolled normally.
Text selection is important to Instapaper customers so they can copy, email, take note of, or blog about passages from what they’re reading.
In practice, this implementation requires Instapaper to forgo certain features, like multiple columns2, consistent page numbers, and most fancy page animations. But I’m willing to break from the print metaphor whenever necessary to allow modern niceties to enter the product.
On the actual Kindle 2 device, selections can span page breaks. But not on the Kindle iPad app, because they’re using UIWebView (like me), and it’s simply not possible to do in any sort of remotely practical way with their implementation of pagination. ↩︎
I’ve been unable to find an iPad app with multi-column text that allowed text selection at all, let alone across column breaks. Even in Mobile Safari, when displaying CSS3 columns, it’s nearly impossible to get a selection to span a column break. ↩︎