Screen shot 2010-12-10 at 12.03.33 PM.pngThe following is reprinted, with permission, from if:book. It was posted by Bob Stein. Blockquotes omitted:

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.

— J

16 COMMENTS

  1. Howard, 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 (the legacy indication of the gathering transposed to an indication of relative position in a screen 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….

  2. @gary frost

    pacing guides; feed-back of overall position in the work.

    Locations and/or percentages and/or progress bar. I haven’t yet met an ebook reader without one.

    The rest of your comment I didn’t understand.

    I really don’t get this need to hold onto the “page” as a construct, except as it relates to people thinking ebooks are just print books wrapped in extruded polypropylene.

  3. Howard — it was written more or less in response to the following statement on a mailing list:

    “This may sound naive but I’m interested in seeing scrolling at least for the sake of it being “different”. My fear/guess is that many of these HTML readers implement traditional pagination for the sake of tradition and I see an opportunity to do something new (or at least try).”

    As the author of a paginated web-based ereader (Monocle), I thought I might defend my decision. But you’re right: some of the context is lost here.

    Errolwi — a civilised disputant might offer examples?

  4. I have found that i do prefer page turning to scrolling, to the point that I’m willing to pay for newpaper/magazine content (nook sells the ny times) even when i can read the same content for free on the web. I thought this was a great explanation of why that might be – I was unable to put it into words.

  5. It appears that ‘scrolling’ has been interpreted as meaning ‘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.’ ONLY. Any implementation that limited control inputs to these methods would indeed ‘suck’. Page Up/Down (actually Screen Up/Down) inputs work well for web pages longer than a screen, while having scroll controls available to change where the ‘screen-breaks’ are. There are generally logical breakpoints (e.g. chapters) which can helpfully be inserted in an otherwise ‘infinite y-plane’.
    As an interface concept it looks workable.

  6. The issue he is addressing is one of interface design and his goal is to produce a long-form reader that maximizes immersion. To maximize immersion it necessary to minimize user distraction in the form of application interaction.
    He is arguing, and convincingly to me, that displaying long form text in chunks is an effective approach because of intrinsic merit and not merely because it reflects “tradition” or follows print book conventions.
    To put it at its simplest, he is arguing that scrolling (vertically or horizontally) requires more user interaction and more user attention to the mechanics of the application than block-display navigation.
    Human communication has evolved over time into the current convention of words, sentences, paragraphs and sections because it is effective and accomodates human cognitive limitations, not just because (like qwerty keyboards) of familiarity.

    For anybody doubting this, try a simple exercise. Find a PC reading app with autoscroll capability and mask the display so that only a three line window of text is visible.
    Most people find reading *anything* in such an environment requires more attention and concentration than a larger display with more visible context cues. It is the same reason extremely long run-on sentences and paragraphs are frowned upon. It is the same reason most people find tiny font size and tight margin-less formatting vaguely discomforting. There is only so much attention we can devote at one time to information consumption; some folks have higher capacity than others (speed-readers!) but we all have limits. Proper interface design needs to accomodate those limits and Mr Pearson is simply arguing that paging is an effective technique to achieve that.
    He isn’t arguing a matter of personal preference but one of ergonomic fact.

    My own take is that where long-form contentent presentation is concerned, paging displays will continue to dominate scrolling displays long after print books fade into history.

  7. fjtorres gracefully expresses the unobtrusive pacing prompts built into physical books. In so far as “dedicated” book readers build on print refinements such non-distractive haptic prompts should be migrated to book reading on the screen.

    Of course the design agenda, to mimic or not mimic print book reading, is an open question. My own view is that prospects open to un-print like, multi-function reading are so promising and alluring that hand-held devices will move away from a dedicated development. I also consider that some of the attributes of print, across features such as constraint, persistence, legibility, navigation, will be resistant to crossing the screen threshold.

    My view is also influenced by a suspicion that print and paper books have a future. I also suspect that screen books will add momentum and incentive to continued refinement of print. (counter-culture, no?) Until the recent advent of the Google book store all e-book advance has been financed with print revenues. And the back-side of screen delivery relative to subsequent print-on-demand is not clear.

    As a final remark note how wide a range of comment and discussion has been generated by page vs. scroll navigation. I suggest this no accident. Not only is the interplay of print and screen more interesting than isolated discussion of device development, or e-book marketing and distribution. The social implications of culture transmission based on scroll vs. codex has come up before.

  8. Boy I’m glad I’m not the only one who doesn’t understand what’s being discussed. To me, it sounds like the article could be alternatively titled: “Which is better: Scrolling through a book continuously, or clicking to turn the page.”

    My preferences for the way an e-reader displays text:

    – I don’t like scrolling through a book. I want to hit one key to turn a page.
    – I REALLY don’t like when a word or sentence from a page is repeated on the next page.
    – I do like when an eReader provides some sort of progress bar or something to show how far I am in the book, but I don’t like page numbers as the method of doing it, because the page numbers can change based on what device I’m reading on, or what font size or screen orientation I have.

    I’m still not quite sure if that’s what we’re talking about…

  9. Huh? I’m no longer able to use my trusty old Sony Clie–
    software to transfer ebooks to PDA doesn’t work on Win7, and Palm isn’t going to be upgrading it–
    but I *loved* the Clie’s scrollwheel. I’ve spend many many hours reading with text scrolling up and my thumb on the scrollwheel.

    Perhaps it worked because I could hold the PDA and scroll with just one hand. I liked to read lying down. Perhaps scrolling doesn’t work as well if you have to read sitting up, with two hands holding an ereader.

    I should perhaps also note that I’m extremely nearsighted, and I read the Clie’s small screen with my glasses off, three inches from my nose.

    I’ve been too poor to buy a replacement for the Clie, but when I do, I’ll probably go for something small … like using an iPod Touch as an ereader. Would love to be able to buy something with a scrollwheel.

  10. It’s true that the concept of a “page” has become muddled. Consider on readers with pages, most notably iBooks, changing font, type size, leading, or margin size can drastically change the page count. As well, it can drastically change the % of the material completed and thus make the progress indicator jump quite a bit if it’s based on some concept of arbitrary length (e.g., pages).

    When the progress indicator is based on non-arbitrary lengths (e.g., the number of words or paragraphs) then sizes, white space, and other design features have no accidental bearing on progress.

    The importance of progress tracking is purely psychological. Some people see a really thick book on the store shelf and migrate to it. Others see it and avoid it. Neither person will probably consider the font, text size, layout, or other features that determine the number of pages. Their reaction to the book’s thickness is purely based on a psychological premise: either the book is complex, or it’s engaging, or it’s too long, or whatever.

    In the digital world, there is no telling whether a book is long or short. I doubt most readers could tell you how many words are in either Moby-Dick or some modern mystery. Therefore, advertising that an e-book is 80,000 words will be meaningless unless marketing types start educating the market.

    More important to the discussion, perhaps, is what design benefits may we, as readers, derive from multi-column pages, two-page spreads, or pagination in general compared to scrolling?

    I’m already tired of poorly designed e-books and reader software that supports ridiculously long lines, poor character and line spacing, and lack of layout design. Books are more than the words, the best ones are also the design. Think of the design as being the performance of the text, as a narrator is the performer of the text for the audiobook version.

    So, yes, I want to be able to choose which method is best for presentation. However, I want to do that from the design side of the equation, not just the reader side.

  11. The original poster’s main complaint against scrolling was the disadvantage of easily losing your place in the text as you scroll down and the last line you read moves up. He described this accurately:

    “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.”

    However, the problem becomes minimal when you give your reader an easy means to recognize that last line by sight so that s/he does not have to start reading it again. My method for providing this easy recognition where you were in a block of text is to make that text less uniform than the typical long and gray and monotonous-looking printed paragraph.

    Most of the initial software offerings for making ebooks relied on scrolling, so I formatted my ebooks into relatively short paragraphs of varying lengths, with non-justified ragged right margins, and I highlighted one or more words in each paragraph in red not only to emphasize those words but above all to provide a visual anchor to the eye as it follows the last line during its move up the screen. You can see typical examples of this scroll-friendly formatting at http://phaistosgame.com/PhaistosOne01.htm or at http://recoveredscience.com/quantumpast.htm.

    A few of my readers commented on this feature and usually found it helpful to make their reading easier. So, when you compare the advantages of page-turning versus scrolling, you may want to include such an improved form of scrollable text in your options.

  12. I am sorry Peter but that red thing sounds truly ghastly ….. 🙂

    It seems to me that there are two aspects of this page number issue. One global and one local. But they could both be solved together …

    The Global aspect involves a location in an eBook that can be transmitted from one reader to another irrespective of the eDevice they are using to read the eBook. This location clearly needs to be independent of the screen size and font size.
    The Local aspect involves a location in the eBook that only I as the reader need to use so that I can return to that location in case I lose it – for example if both myself and my wife are reading the same book at the same time (something that is not that unusual).

    In my view there is room here for an “invisible reference number”, assigned within the eBook, that is attached to each sentence or each paragraph, independent of it’s appearance on the specific eDevice. This number can then be made visible with a touch of the finger on an “i” icon in the toolbar or something similar. This would be unobtrusive and yet easy to access and use for reference by using the same “i” icon and entering the number into a search box, bringing the reader back to that point in the eBook.

The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail newteleread@gmail.com.