Pagination is better than scrolling for digital texts
February 24, 2011 at 8:06 am 4 comments
This is an interesting argument that I hadn’t met previously: Pagination is better for long digital texts because it’s easier for sustained reading. What are the implications for reading source code? Is pagination (and perhaps formatting via something like Knuth’s WEB) better than a scroll bar?
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.
…
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.
via if:book: a defense of pagination.
Entry filed under: Uncategorized. Tags: computational media, educational technology.
1.
Rob St. Amant | February 24, 2011 at 12:55 pm
I wonder if the author of the linked post knows about empirical studies of the differences between paging and scrolling… I’m using a textbook I like in my HCI course, Heim’s The Resonant Interface, which gives half a dozen references to the literature. It turns out that results are conflicting. Studies from the 1980s suggest that in reading text, paging makes it easier to grasp the structure of a document and, when skimming for information, to recall where on a page a given item was located; a study from 2003 showed scrolling to be faster than paging for continuous reading. Heim believes that familiarity with the Web might have influenced the reading patterns of this generation, though of course it’s hard to say for sure. In general, I think there’s a better approach than this implies (though it could be that the author has left out some steps):
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.
Introspection isn’t enough; we need to look to experimental results.
2.
slger | February 24, 2011 at 1:01 pm
Then there is reading by semantic markup, as in how screen readers work using audio output speech. This blog is navigated by keys ‘h’ through headings, ‘l’ for lists, ’2′ for heading 2 corresponding to posts, ‘e’ for edit box comments, ‘k’ for links, etc. Scrolling seems arcane, even quaint, when you have semantic enabled documents.
Now, this is a computational thinking situation. Pagination and scrolling are representations in pixel space for visual sensory consumption. I have described above semantic navigation for auditory sensory consumption. Both are reading the same content with different gains and losses through the representation mappings and receptors.
Why is pagination versus scrolling an interesting question when the underlying available semantic structure is being ignored? Has the GUI evolved down a path where semantic markup is only exploited for different sensory adaptations? Why cannot you read also by heading navigation plus pages?
Similar comments relate to how visually impaired people often read using DAISY (XML) representations. A book is marked up with levels, headings, paragraphs, sentences, as well as pages. Reading a book has so many natural paths other than pages. And that makes it hard for me to imagine ever being comfortable with a visually only book reader.
May I suggest both code and text reading are better in the semantic domains. Try this with the accessibility features of your platforms, free tools like the NVDA screen reader, and by learning the rules of the road from WCAG 2 standards. A related technology is the Readability.com model for simplifying web reading and rewarding authors of longer web content.
In summary, apply computational thinking with attention to a broader range of sensory capabilities and limitations and we may find some lurking innovations in that design space.
3.
Robert Cooper | February 24, 2011 at 2:42 pm
I am generally going to call shenanigans on this one. For a number of reasons. Granted they are mostly anecdotal, but…
First, lets look at where you generally encounter paginated text:
1. Big content websites like Salon or the NYT.
Pagination here almost always sucks doesn’t it? Isn’t it just courtesy now if you link someone to a feature article, you always link them to the “printer friendly” version?
A lot of this goes to the UI of the paginators: small links at the bottom of the page that require re-gaining hand-eye vs eye-line coordination to click on. Usually on these sites you have to wait for a graphics heavy page to re-snap into place, which puts a noticeable delay in you “next graph” of reading.
2. Book reader applications. Book readers are kind of a different story, but not that much. The one I interact with the most is the Kindle. On the physical device, hell yeah, paginate. But that is mostly because of limitation on the e-ink display, and the fact that pagination is controlled by tactile-satisfying hardware buttons. Good lord, when I use the PC or Android version of the app do I hate it. Especially with too-easy to hit “next page” areas on the screen, it is easily to lose your place if you tap through accidentally. This, I think, is mostly because…
Secondly, I assert people are used to scrolling interfaces.
Granted as someone who works with software all day long, we get use to this. Hundred to thousand line files that we scroll through skimming rapidly. However, I would assert that most people when they are reading something long on a screen have their finger firmly planted on the mouse wheel, and aren’t scrolling when they hit the bottom of the page, but are scrolling almost continuous. You learn to track the shape of the test and generally read each graph individually in a particular area of the screen.
I have noticed, particularly people who are “power users” tend to work this way, but I have no data to back that up. Unfortunately, most “eye tracking” tends to look like this:
http://www.useit.com/alertbox/eyetracking-scrolling-long.jpg
and is not reflective of the scroll position on the page when the points were gathered. I would love to see some real studies of eye tracking with scroll position data overlayed.
4.
Bijan Parsia | February 25, 2011 at 3:33 pm
Robert, I *think* find soft eBook implementation (a la Stanza, eBooks, or Kindle on the iPhone) easier for sustained reading than scrolling. I do a lot of scrolling reading as well…
Pagination sucks on the NYT etc. because of how suckily it’s implemented: The latency in particular.