a defense of pagination 12.09.2010, 3:37 PM
posted by bob stein
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.
Posted by bob stein on December 9, 2010 3:37 PM
cata on December 9, 2010 4:13 PM:
I can't say I agree with this at all, because scrolling is strictly more flexible than pagination. If you prefer the screenful-at-a-time paging, then all you need to do is hit Page Up or Page Down on your keyboard (or include a gesture/button/glyph to do the same on your reading device.) I do so frequently.
Gary Frost on December 9, 2010 8:32 PM:
Another reason to paginate longer screen text is the useful collative of signature marks. Such signature marks were once used as assembly guides for the gatherings in print books, but they can also work as navigational enhancements for the screen.
Regardless of the selected font size, a serial signature mark would pace off the given chapter. Such a device would ease jumps across content that are so easy with a physical book, but so crippled with screen books.
Marc Köhlbrugge on December 10, 2010 7:09 AM:
We've been developing our own eReader (see site for details) and of course the question whether to paginate or not came up during the design process as well.
After some experimentation we ended up with 'paginated scrolling'. Instead of scrolling continuously you scroll in steps (pages, really).
This has the advantages of pages, but makes more sense conceptually in that the book is simply one long column of text instead of a mixture of multiple horizontal columns arranged in z-space which most eReaders use.
Not sure one is better than the other, but we had some special requirements which made it the right fit.
Bill Seitz on December 10, 2010 8:08 AM:
One devices with keyboards, don't most people just scroll a whole screen by tapping the space-bar?
So if touchscreen browsers/OS would just settle on a gesture or something to do the same thing, would that make the pagination model unnecessary?
Gary Frost on December 10, 2010 1:42 PM:
Book length works benefit from pacing guides; feed-back of overall position in the work. Screen based navigation is focused on content as a stream while print is content is divided by pages and chapters and by continuous physical advance through a text. I mention the legacy feature of the signature mark (location in a gathering transposed to location in a chapter) as a hint for navigational enhancement on screen. There are others as well including the first word of the following page printed at the tail of the previous. Such features seem antiquarian but they are very suggestive....
Werner Donné on December 10, 2010 6:04 PM:
Scrolling a page at the time IS pagination, but with the disadvantage of crude page cutting. Sadly enough quite a few e-readers seem to behave like this when they are trying to paginate.
Kenneth Shear on December 12, 2010 2:25 AM:
Pagination actually has two functions in online books -- one is to help keep the page and the second is to enable the reader of an ebook to communicate better with the reader of a printed copy. I think the second is actually more important. If the ebook reader doesn't have page numbers, then it's very difficult to communicate the location in the book with a person reading a printed version. Citation also becomes much more difficult. Since at least 80% of book sales are still printed versions, if people are going to discuss book, the page number remains crucial. Therefore, at our book site, www.libertary.com, we present each chapter as a scrollable web page, but we mark the pages within the chapter by fairly unobtrusive dotted lines. (Libertary is an experimental new approach to publishing with about 40 books available to read free online as of now.)
Page numbers also help with scrolling. When you have a long webpage loaded in a browser window, the best way to move down is using the pagedown key which should just jump a screenful of text. But if anything goes wrong, it's a big headache to figure out where you were if there's lots of text. Having page numbers can help if you've noticed what page you're on. This is pretty much the same as, if you're reading a book and drop it -- if you've noticed the page number you can get back to where you were.
With regard to mobile devices, the lack of a page up/down control is simply a deficiency in some, but not all, mobile browsers. For example, if you download the Dolphin browser for Android, while you're in the browser it uses the phone's volume key as a page up / page down control. It's a clever fix for the scrolling problem on mobile phones -- only a matter of time if you ask me before the standard browsers will adopt it, but meanwhile, hats off to the Dolphin folks, if you like reading on line.
Lisa Betel on December 13, 2010 2:38 PM:
"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."
Something very like this was a feature of books from some of the earliest handwritten manuscripts to about 1800, when the steam-driven press came into use. They are called catchwords, and make reading old books a real pleasure.
Jamie ONeal on January 5, 2011 9:18 PM:
It's great to see this discussion. There is a great deal of psychological background that relates to the issue of pagination. Particularly in the area of cognitive load and comprehension, the spatial construct of a text plays an important role in the recall of information. In reading a paper article, it's normal to remember that the bit of information you need was in the upper left corner of a page... which, as it turns out, is your brain's way of organizing information. Some very interesting studies on recall of information (in text, as well as in stories and the mental construct of another world) can be found at:
Bower, Gordon, and Daniel Morrow. “Mental Models in Narrative Comprehension.” Science: New Series 247 (1990): 44-48. JSTOR. Web. 25 January 2009.
Kerr, Matthew, and Sonya Symons. “Computerized Presentation of Text: Effects on Children’s Reading of Informational Material.” Reading and Writing 19 (2006): 1-19. EbscoHost. Web. 31 July 2009.
These and others were included in my dissertation. "Multi-Modal Reading for Low Level Readers", completed August 2010, at the University of Central Florida. Fundamentally - scrolling eliminates the advantage of spatially oriented recall. I also noticed that this newsletter does not full justify the text. Again, this is a visual cue for the reader to orient, due to the staggered nature of the end of the lines. My tired eyes thank you for that.
bowerbird on January 21, 2011 5:51 PM:
> If you prefer the screenful-at-a-time paging,
> then all you need to do is hit Page Up or Page Down
> on your keyboard (or include a gesture/button/glyph to
> do the same on your reading device.) I do so frequently.
the problem, as werner notes, is that the "page cutting"
is very "crude". there is usually a line or two (or three)
that is redundant, and it's often inconsistent how many,
so that the eyes have to scroll the text to find their place.
this is the type of mental energy that inhibits reading...
worst is when _half_ a line (top or bottom) is displayed.
and of course the problem gets multiplied -- severely --
when it is _pictures_ that are chopped in half at a break.
otherwise, yeah, page-up/page-down work just _dandy_! ;+)
> One devices with keyboards, don't most people
> just scroll a whole screen by tapping the space-bar?
"most people" don't even know that command works, bill.
including, i would guess, cata up above, who otherwise
would've mentioned it when discussing the same thing...
besides, this command also does a sloppy "cutting job"...
> This has the advantages of pages, but makes more sense
> conceptually in that the book is simply one long column
> of text instead of a mixture of multiple horizontal columns
> arranged in z-space which most eReaders use.
i've never considered pagination to be _anything_but_
the chopping up of "one long column of text", so i'm
not sure i see what the conceptual revolution is here...
but i'll take a look at it, and see what i think...
(or i guess i won't, because openmargin isn't open yet.
but it appears to be quite similar to bookglutton.com.)
> Pagination actually has two functions in online books --
> one is to help keep the page and the second is to
> enable the reader of an ebook to communicate better
> with the reader of a printed copy. I think the second
> is actually more important. If the ebook reader doesn't
> have page numbers, then it's very difficult to communicate
> the location in the book with a person reading a printed version.
gosh, i'm glad the topic finally came around to something important.
these are the "pagination" issues that i thought were going to be
discussed when i had initially read the heading for this blog-post.
it never even _occurred_ to me that the relatively minor issue of
pagination in e-book viewer-programs would be the _actual_ topic,
since i thought that issue had been decided way back decades ago.
(face it, bob, you _did_ decide that issue way back decades ago.)
i'm also chagrined to observe that, after a year of thinking about it,
this is the best that joseph pearson could come up with? sincerely?
i mean, monocle is a nice piece of work, so i would have expected
that its programmer would exercise thought at a much deeper level.
so let me come directly to the sore spot: yes, we _should_ actually
implement both modes in our viewer-app programs, so that the
end-user can choose the one that they want. and no, that's _not_
because we, as programmers, are incapable of deciding which one
is better. pagination is _clearly_ better. but that doesn't mean that
it's better in _every_ situation, for _every_ user, on every _book_.
we give end-users _options_ because these other situations exist,
and because we aren't some fascist control-freaks who insist that
_we_ make all of the decisions and end-users just do as we say...
we give end-users options so they can do what they want to do,
even if it's _not_ the "best" thing, the most optimal, or whatever.
but now let's get back to the points that kenneth is making...
we offer page-numbers in our e-books so that _communication_
can be enabled between people using e-books and paper-books.
to go directly to the point, every one of our e-books must be able to
assume the pagination of the "canonical" printed version of the book.
i'm sure someone will want to argue with me about this... save it.
i'm not interested. i've thought about it for decades, and i _know_
i'm right about this issue. eventually everyone will agree with me.
because the alternative is to sever ourselves from print being useful,
and that's a sacrifice that we have no reason or willingness to make.
> Citation also becomes much more difficult.
citation is probably our most important means of "communication",
so yes, this is true by definition.
but there's something more important underlying "citation" as well,
and that's that our _legacy_ of print uses citation-by-page-number.
when we digitize an old book, all of its pointers are _page-numbers_.
we have to face the facts that we don't even have enough money to
_correct_the_ocr_ when we digitize these old books, so we sure don't
have enough money to convert all the page-number citations to links.
so it's a cold hard necessity that we'll have to keep the page-numbers.
> Since at least 80% of book sales are still printed versions, if
> people are going to discuss book, the page number remains crucial.
even when books are printed only on occasion, print-on-demand,
and never in large runs anymore -- that is, it's all "born digital" --
page-numbers will remain vital. if we don't have page-numbers,
we'll have to invent another kind of _pointing_mechanism_, and
we'll all have to agree on it, which probably won't _ever_ happen,
so we just need to stick to page-numbers. even for born-digital,
with a paginated copy as "the canonical version" posted online...
> at our book site, www.libertary.com, we present each chapter
> as a scrollable web page, but we mark the pages within the chapter
> by fairly unobtrusive dotted lines. (Libertary is an experimental new
> approach to publishing with about 40 books available to read free
that's one way to do it. i'll have to look at it to see what i think of it...
ok, back later, after having looked at one book there at libertary.com,
"how we got here" by andy kessler, and now i'm confused, kenneth...
first of all, as you noted, you break the long webpage into segments.
we can call them "pages" if you like, except you have missed the part
about a mechanism in the viewer-program which allows the reader to
easily move from page to page. i said up above this was the "minor"
interpretation of this post's heading, but i didn't mean by that that it's
_unimportant_. it's very important, so much so that it is _obvious_,
yet your implementation doesn't include any pagination mechanism...
i suggest that you look at the pagination methods on ffffound.com...
they allow users to press "j" for the next photo, "k" for the previous,
which means each photo comes up nicely positioned, with none of the
irritation that comes from having to look at a photo that's been split...
"h" also allows you to go to the top of the page, "l" goes to the bottom,
unless you're already at the bottom, when it goes to the next webpage.
("h" will also take you to the previous page if you're already at the top.)
indeed, the "paging" methods found at ffffound.com are likely the best
example you can find showing the superiority of paging over scrolling.
and joseph pearson will be enlightened to see the two methods are
co-existent on the same webpage, so the user can choose either...
so now, back to libertary.com... so kenneth said straight up that he
feels the second reason for pagination is the important one, where
pagination serves as the _synchronization_mechanism_ between
the electronic version of the book and the printed version of it...
but in comparing the digital version of kessler's "how we got here"
at libertary.com with the printed version(s) being sold at amazon,
i found the pagination breaks _differed_. so what gives, kenneth?
i've put up some public-domain books that were digitized. like this:
this is how _i_ think the synchronization should be done...