Could Safari Reader Help Sites Become More Profitable?

When a Web page loads, my mind immediately tries to start making sense of it. What is this page about? What part of this page is important? Is this the information I was looking for? Is the lead-in clear enough to continue reading? Even before I start reading, I use the visual clues to help identify where I should be focusing my eye. The style and brand of the site helps my brain process what type of information this page has. Who is it by? When was it written? Is it published by a company or institution? Who is this written for?

Satisfied that I’ve found the right article, I commit to reading, but if the layout column is too wide, text too small, or lines squished together, my eye can easily tire. It should be an immersive experience, and it’s easier to get hooked if the page is well designed. If it’s a complex topic, any little distraction from reading slows me down. It’s frustrating to lose my place because the lines are too long, or because page elements obscure text, or the visual style is too monotone; it all takes away from the experience. These are all issues that Safari 5 addresses with a new feature called Safari Reader. 

Safari Reader creates a distraction free high contrast overlay. Big, bold text is set in the elegant Palatino typeface. Reader easily fixes much of what can make great—but poorly laid out—content a chore to read. I think this could be a boon for websites created with less of a focus on design. 

For example, page-breaks have their purpose. They give the reader a pause to catch her breath before continuing on. Text that scrolls on and on can be daunting, and if it looks like too much for one sitting, I may not even start. However, the overuse of page-breaks to drive up advertisements come across as clunky, disrupt the flow of piece, and forces my brain to switch back and forth between navigating and reading. Apple’s AJAX loading of multi-page articles is the best feature in Reader. It clearly defines the page-breaks minimally, takes just a moment to load each subsequent page, but never pulls me out of the article.

I’ve run tests here at TMO to determine how long people stay on pages. The first group were people who spent just enough time to figure out what the page was about and left, the second group were people who spent enough time to read the full article, and the third group were people who are either fast readers or left mid-way through reading. What if Reader makes the page easier to read for some people in the first group? They’re probably not clicking on ads, as they only spend enough time for a quick first impression. What if Reader helps them get into an article they might have previously skipped? Hopefully they’ll get something out of the article, perhaps want to comment, learn more about this topic, and spend some more quality time on the site. They’re moving on with a positive notion of our brand and what we have to offer, including our sponsored messages.

In my experience, ads are most effective when I’m looking for more information. If I think I’ve found what I’m looking for, my blinders go on in order to focus. Afterwards, ads can be useful to bring me to competitive products and services I might not have researched or heard about yet. Adblockers are horrible because they never give the ads a chance to deliver their message. I don’t think Reader is necessarily evil for hiding ads. It’s an extension of what we do anyway when we read, and when you’ve finished, the ads are waiting for you on your terms.

Reader 1.0 has Some Room to Grow

I love the concept of Reader; however, I think the implementation falls short. In my tests, it doesn’t always work as expected. I’m currently trying to figure out why bylines on TMO articles don’t show up in Reader. How many paragraphs does it take to activate? What if there are multiple sections (div tags) of paragraphs? What elements does it strip? Some documentation on how it matches, filters, and behaves would be greatly appreciated.

Even if it were documented, I don’t think it should be built into Safari. With Safari’s new extension support, this would make a great open source sample extension. Or better yet, provide it as one of the HTML5 demos. That would give site developers an easy way to implement the functionality while still remaining in control. As a JavaScript add-on, developers can customize it to refine what Reader displays, how it works, and we can add callbacks to provide extra functionality when it’s used. We’re left playing a game of trial and error to figure out how each of our pages will look in this new renderer that’s installed by default with every new Mac.

Overall, it’s a great idea that I think will increase the amount of reading that happens on the Internet. Right now, the burden is on website owners to figure out how it behaves on their site, and that’s causing some frustration with people who are accustomed to the fine-grain control that well documented, soon to be standardized, HTML5 provides.