Joseph Pearson of Inventive Labs, the developer of Monocle Reader and Booki.sh recently wrote an eloquent explanation of why we should bother to maintain some form of pagination even in the digital era. [this originally appeared on the private Read 2.0 list serve, re-posted here with permission.]
I’m perplexed by the suggestion that we chose pagination “for the sake of tradition”, since pagination is the one and only difficult problem with building a browser-based reader. It’s actually the only thing Monocle does, and I didn’t waste this year doing it without reflecting on it.
I’m delighted by the proposal that someone should build a serious scrolling browser-based reader, because I’ll have somewhere to send people who ask this question. And I’m greatly amused by the idea that we should inplement both modes and make it the reader’s choice — as if a responsible software designer COULD actually shrug their shoulders and say “Damned if I know, you decide.”
The software designer has to make the call — has to ask: “what is the best way to read content with these characteristics?” I’ve spent a lot of time thinking about it. Back in March I wrote up some notes on it, but didn’t publish them. I’ve pasted them below.
Nb: Monocle has a scrolling mode for “legacy browsers” that attempts to get around the problems with scrolling described here. Open a Booki.sh book in a recent Opera to see it. I’ve been told it “sucks” (thanks Blaine!), which is probably true.
I love it when old user interface metaphors, veterans of a pre-digital era, comfort food for the catastrophe, are suddenly usurped by a better mode, one that takes advantage of all the opportunities of a free graphical user interface, one that really has no necessary real-world analogy. I love it because it proves our readiness for the world that confronts us, and I secretly love it because [December: some line about old people redacted].
So pagination of text is a big bold target, right in front of us. On the surface of things, dividing text into pages chains us to an old and unnecessary constraint: the dimensions of a printed page.
I agree with that — to an extent. But the obvious answer to it (one that now also has a long history) has some problems. This answer says that I’m going to give you an infinite y-plane (at least), which you will move up and down through by scrolling, dragging or more recently flicking.
Let’s put it under the umbrella term ‘scrollable’. Scrollable content works very well for two or three screenfuls of content, because it lets you adjust, pixel by pixel or line by line, to your changing context. You can say “I want this thing on the screen, and this nearby thing on the screen at the same time”, which is often useful — particularly if the content has varied elements like buttons and links and images as well as text. That is to say, scrollable content generally works very well for web pages.
But for anything of real length, it is seriously hard work. It’s important to realise what you’re doing when you’re scrolling. You’re gazing at the line you were reading as you draw it up the screen, to near the top. When it gets to the top, you can continue reading. You do this very quickly, so it doesn’t really register as hard work. Except that it changes your behaviour — because a misfire sucks. A misfire occurs when you scroll too far too rapidly, and the line you were reading disappears off the top of the screen. In this case, you have to scroll in the other direction and try to recognise your line — but how well do you remember it? Not necessarily by sight, so immediately you have to start reading again, just to find where you were.
If that doesn’t sound familiar, it’s because you’ve been burnt by it a few times, and have long ago adjusted your behaviour. Instead what you do is scroll so that the line you’re reading is higher up, but still nowhere near the top, so that a misfire can’t occur. You almost never scroll a screenful at a time — typically you scroll clusters of five to fifteen lines. But what’s the outcome of this? You’re doing a whole lot more work, interacting far more often than for a simple page turn.
With zoomable touch interfaces, like MobileSafari, this has a bigger impact, because every time you scroll the zoomed-in content you’re reading, there’s a chance you’ll flick at just slightly the wrong angle and cause the content to crop on one edge, making it temporarily unreadable. The effect is annoying.
Beyond this, even if you have startling accuracy, still you are doing a lot of work, because your eyes must track your current line as it animates across the screen. For sustained reading, this quickly gets physically tiring.
Pagination works for long text, not because it has a real-world analogy to printed books or whatever, but because it maximises your interface: you read the entire screenful of text, then with a single command, you request an entirely new screenful of text. There’s very little wastage of attention or effort. You can safely blink as you turn.
If you’re clever, there’s one affordance you could add to a pagination interface: the ability to linger over the last line during the execution of the command to see the new screenful. This gives us a greater sense of efficiency, of reading and turning at the same time, which scrolling in its kindest assessment can sometimes achieve.