Timeboxing the News

This Saturday at the Touch the News design challenge at the Mozilla Festival, I was in team 6 with Heather LessonPeter O’ShaughnessyCarlo FrinolliNick SmithGavin McFarland and Chris Warring.

We focused on how people consume news on the iPad with regard to location, time of day and time available to spend on news.

We discussed on the needed changes in font sizes and layout needed for various reading positions, discussed Craig Mod‘s Bibliotype article (A List Apart: A Simpler page) and prototype.

Then we discussed how the news site could use time of day and location as information to learn from various user settings (font sizes, layout) to what categories of news the user is reading at home, work, in the morning, etc. to adjust accordingly the suggestions of related articles.

The major issue we tackled with was: given a known time to spend with the iPad (while commuting, etc.) how do you choose what to read? How do you know what can be read in that time?

The idea was that for example you have 15 minutes available while commuting, you open the (iPad optimised) website of Boston Globe, how do you choose what you read?

In the past year there were a lot of discussions on news apps vs news sites on iPad, on magazines as downloadable issues vs web sites. One thing that users constantly appreciated on a downloadable issue was that each issue had a finite number of pages, and the act of finishing an issue gave them a sentiment of satisfaction.

A site has a potentially infinite number of pages, therefore you won’t have this feeling of satisfaction, especially that you cannot asses the size of an article, the time needed to read.

For (even most of the digital, downloaded) magazines you have the number of pages easily graspable, but on the web, for a long scrolling article (or even a paginated one) in an unbounded medium we have only the scrollbar? that’s good enough when you’re on the article page, but on the homepage, where you have to make a choice what can we have? the number of words?

Inspired by one of the iA Writer features, we thought that reading time instead of number of words would be a good indicator of not only volume but also time needed to engage in a satisfactory manner with an article.

Therefore, given 15 minutes, how do you know which articles you can read from the Boston Globe’s homepage? By listing the estimated time to read next to each title!

But, numbers are ugly, hard to compare across the page. Moreover, our general perception of time is terrible and when we engage with content it is completely skewed (think interesting vs boring, emotional impact, etc.). Fortunately we solved this problem before in the kitchen.

What if we’ll have a timer on the news site? Let’s say I have, hmm, 10, 12, 15 minutes … what can I read in this time?

We have two issues to solve: how to have a visible yet unobtrusive timer on a web page on iPad, and how to align the time set with the time to read needed by each article without showing numbers on them.

The solution was to have the timer as a slider on the left of the display, you pull it down and while adjusting it, all articles on the page will have a small bar on top that will show the time to read of that article versus the time on the slider (for example, timer set at 15 minutes, the full width of a bar on top of an article heading/link will represent 15 minutes, while the coloured portion of the bar will represent the time to read of that article).

This is enough information to visually compare if an article or several will fit in the set time and to allow you to choose the time limit that will allow you to engage with a really interesting article (think I would like to read these 3 articles on the culture section, then make dinner, when would be that … instead of time boxing the reading you reorganise your activities).

Moreover, if an article won’t fit on that interval, it will automatically have instead of the time bar on top, a button to “Read Later”.

Here are the sketches made in the morning session:

Illustrated here are also what is happening if in the middle of an article the timer times out (time to read is estimated, and the app should learn in time the user’s actual time to read, which also is dependent on location, font sizes and category of content).

So, on time out, a semi-transparent pane could be display over the half of the content. The reader can just push it down with a swipe (snoozing the timer), or it can re-adjust the timer slider, or just press the “Read Later” button on that pane. If he does so, these events can be used to measure the engagement with that particular content.

Also, on that semi-transparent pane it is possible to display other choices, for example if the rest of the article might take another 7 minutes to read (estimated on the actual reading speed on that page), suggestions for shorter related articles can be displayed there, or a simple way to share the article with a friend, colleague, etc.

Later in the afternoon session we discussed pros and cons on displaying the time as bars, small clocks, numbers, etc. and Gavin created several mock-up images (see below) to test them on iPad for getting the actual feeling of having (a static) slider and time bars on screen as well to present the concept for the end of the design jam.

In the next days I’ll work on a simple prototype, it will be interesting to get the slider not interfering with page scroll, zoom, etc.