I recently built a long form piece of content on the history of spaceflight as an experiment in creating long form content using React.js (repo here).
As a result of that work, I’ve spent time thinking about how to think about tracking such a piece of content, and I wanted to share a little of that thought process and what’s inspired it. I’ll also share further findings as data comes in from it.
Do People Read Long Content?
My first real question with this was, do people really read long content on the web?
The whole piece weighs in at 30,000 words, give or take, with individual pieces running at several thousand words each, along with videos, image galleries and more. Each individual part is large, and the total piece is huge. So would anyone actually read it?
Well, as it turns out, yes. In terms of traffic, over a one month period the piece saw a total of 2,550 visits and 3,476 pageviews.
But the way people engaged varied massively depending on context. For example…
|Page||User Type||Segment||Avg. Time on Page|
* Note that pages with non-statistically significant view numbers were removed
Here we have the average time on each page, broken down by whether a user is new or returning, and whether they’re a desktop or mobile user. What quickly becomes apparent is that people were more likely to return on a desktop than a mobile device, and that returning page views tend to be quite long, but also that for those who are new visitors, mobile vastly outperforms desktop for dwell time.
Moreover, around one in ten people who viewed a piece of content then returned to view more. Of those, a smaller group worked their way through the entire piece. So in answer to the first question – will people read really long content on the web, the answer seems to be yes. As long as it’s kept engaging, and broken up enough by various media that it keeps the piece engaging, people will sit and read very long tracts of content.
The second takeaway was that mobile engagement on average massively out-performed desktop, for new users.
This only goes to highlight the huge importance of creating content that works for mobile.
This is far more than just making sure the content fits on the screen though. For example, the most complex piece in the whole thing is the moon landing audio interactive element in the Man on the Moon page.
This piece combines auto-scrolling text, a small stats area and the controls for the audio. Whilst it’s possible to display all this on a desktop, on mobile it just couldn’t work. As a result, the stats boxes go from being a row of four to two rows of two on mobile, whilst the text scrolls stack on top of each other.
I’m also going to experiment with the idea of making the text scrolls into tabs, to avoid users having to scroll between the two, however I haven’t yet found which of these versions performs better.
This goes to highlight though that it’s not enough to just resize elements. Mobile interaction is fundamentally different to that of desktop, and you can’t just shrink or grow things and expect that to be enough.
Each platform needs to be considered in its own right as to how information should best be presented. Lightboxes are a good solution to image galleries on desktop, but they devolve into frustrating experiences on mobile devices. Similarly, pages with small touchpoints might work fine where a user has a mouse and can click on very specific items, but don’t work well on mobile devices. If they’re used, consideration needs to be given on how a user can “undo” an action, in case they mis-click.
The other interesting takeaway has been that Android mobile devices significantly outperformed iOS mobile devices in terms of dwell time.
|OS||Avg. Session Duration|
After annotating device performance with device specification, it became clear that larger devices performed better than smaller ones. It seems that, rather understandably, people with smaller phones fatigued faster when reading longer pieces than those who were on larger phones. As a result, if you’re traffic is heavily iOS based, or targeting a demographic who tend to have smaller mobile devices, shorter content may be a requirement.
Equally, those with demography which skews towards larger devices may be well served with longer, more in-depth pieces.
|Device Size||Avg. Session Duration|
For the above, small is anything less than 5″ screen size, mid is 5-5.5″, and large is 5.6″ and larger. Small devices performed far worse, with mid performing the best and very large screen sizes also getting a lengthy session time.
When broken down further to only include non-bounce visitors, we get:
|Device Size||Avg. Session Duration|
We, however, lose the larger device category, as there aren’t enough visits for me to be happy with the statistical significance for that device size for non-bounce sessions.
Multi-Part vs. Long Form Content
One of the things that makes this particularly interesting as a case study is that it’s essentially a single piece of content, composed of various smaller parts. Users often seem to come with one of two intents: general interest where they want to read about the history of the space race or Apollo projects, in a general sense, or specific interest where users want to look at a very specific moment, like the creation of the Space Shuttle or the Nedelin disaster.
When comparing this to some of the guides on our site, we see something similar. People coming to look for guides on a general topic, although traffic for specific answer type traffic doesn’t seem to work as well. A large part of that I suspect is that our guides tend to be very, very long, and harder to navigate if you want a specific piece of information. As such, if you’re tackling a large subject, I’d suggest writing your content as a single large piece, but then breaking down into smaller components which are more easily digestible for those wanting information on a specific piece, while creating navigation for those who want a more broad overview of a topic.
If you’ve done any similar research, I’d love to hear about it. Also, follow me on Twitter and subscribe to Builtvisible to get notifications on my next post looking at new ways of analysing content built in JS front end frameworks.