The prototype has some neat ideas, but one aspect I think is misguided is the change from pagination to scrolling. Instead of offering a simple button that allows people to jump from page to page, the full article is shown, and the user is asked to scroll while reading it. The video explains this decision by pointing out that people read e-mails or blogs using scrolling devices, and that Instapaper uses scrolling. I find this argument unconvincing.
Sometimes, We Need to Scroll
Scrolling is used when an application displays content of unspecified length and formatting (or, conversely, when content creators don't know what application and screen size is used to view their content). It's a way of making something fit when it doesn't fit.
I don't know what device you're reading this on. Perhaps you're reading this on a PC with a huge display. Perhaps on a cell phone. So it's impossible for me to layout individual pages, and you're very likely forced to scroll to read what I've written. The content in the video, on the other hand, was clearly designed specifically for the device it was shown on. It would be entirely possible to layout individual pages.
Pages Make Sense
I have been reading books on digital devices for over a decade now, starting with a Newton. Some of these devices have had book readers which scroll instead of jumping from page to page, and the user experience on those was not good. I find it almost impossible to read text while it is scrolling, so typically, I interact with such devices by constantly switching between reading and scrolling. I read some or all of the text I can see, then I scroll until the screen is filled with unread text. This process is error-prone. Some devices have erratic scrolling which makes it hard to scroll to where you want to go1. Other times, it's easy to lose track of where exactly you were in the text while you're scrolling. And at any rate, the user is doing work that the computer could be doing.
When reading an article on an electronic reading device, most people are likely to constantly switch between reading as much as possible, and scrolling to the next "page". Replacing a simple pagination system (where you hit one button to fill the entire screen with unread text) with a complex scrolling system (where you put the burden of replacing read text with unread text on the user) is probably a bad trade-off.
Changing Font Size
Ryan McCuaig writes:
It's hard for me to imagine that these devices wouldn't include some sort of type size adjustment for reading accessibility, which for any magazine-style layout usually sends us back to scrolling.
I think in the case of font size changes, a better solution would be to add layout hints to the source, indicating areas where page breaks are disallowed, areas were page breaks work fine, how many columns to put on a page depending on font and page size, and information about where to put images if page breaks go "through" them.
I think the main goal is not to create layouts which work perfectly on a given screen size, but to make reading a good experience by allowing people to replace all of the text they've just read with a screen full of new text without forcing them to scroll "by hand".
Jumping from page to page is easier than scrolling through an article. It makes sense to format content into individual pages that match a device's screen, or to add metadata which allows the device to format the content into individual pages.
Some people have written in, telling me that they prefer to scroll and read at the same time. So instead of taking my word for it, it would probably be a good idea to do user testing using either method, to figure out which solution most people prefer, or to offer both solutions: layout the content in pages, but let users both jump from page to page, as well as scroll though pages.
The P800's web browser, for example, would scroll about one line of text too far when you turned the scroll wheel four notches, so at most, you could scroll about 75% of the screen without missing anything. ↩︎
If you require a short url to link to this article, please use http://ignco.de/230