Does Facebook Instant Articles really threaten the web?
Native app rendering is the antithesis of responsive web design. Will it destroy the web?
Facebook recently announced “Instant Articles”, a new way for content makers to publish content directly into Facebook for a much faster experience. The word in the name “instant” highlights its main selling point to publishers: speed. Here’s a quote.
“Mobile web articles can take an average of eight seconds to load, by far one of the slowest parts of the Facebook app. Instant Articles provides a faster and richer reading experience for people in News Feed.”
The response from the web community has been strong. While some blame Facebook (and other social media networks) for slowing the web down themselves with the myriad of badly performing social media tools. Others have blamed development teams for not caring about performance and creating slowly loading webpages.
My initial reaction was similar to many others on twitter: that this was an existential threat to the web. I now think this is an over reaction and the problem isn’t about speed but about content. In short: I’m not going to be panic learning Objective C (or Java) anytime soon.
This is because:
- Instant Articles is right now just an experiment.
- The Instant Article format looks more suited to the “long form” format rather than for general usage.
- App development workflow in general is not robust enough to support a busy newsroom.
Instant Articles is an experiment.
The people interviewed on the Facebook marketing website aren’t thinking of sacking web developers just yet. Here are two quotes:
“We’re participating in Instant Articles to explore ways of growing the number of Times users on Facebook” Mark Thompson, CEO of New York Times.
“The Guardian is keen to test how the new platform can provide an even more engaging experience for our readers” Tony Danker, International Director, Guardian News & Media
They’re experimenting. This is the general concensus given by managers I’ve spoken to about this within the BBC too. Product teams are right to experiment. While newsrooms continue the shift to digital there is still no definite business model on how to do online journalism right. The people who in my mind are doing online journalism best is Buzzfeed. Buzzfeed definitely see themselves as a vertical content business. Instant Articles fits in with their mantra of following the user rather than seeing themselves as a platform and expecting users to come to them.
The Instant Article format looks more suited to the “long form” format
Online journalism is more complex than putting text and images together to publish online. BBC News worked out how to make basic responsive stories in 2011. We launched a v1 product in 2012 that listed stories in index pages and then displayed text and images in a story page. We’ve spent the entire time since trying to work out how to make all our other content responsive.
Timothy B Lee from Vox said about Instant Article: “The value of a New York Times article is in its content, not the design of the webpage that surrounds it.” This is true, but only if the content is text and pictures. Online journalism is constantly diversifying. Live event pages and topic pages are now just as likely to be used to report on a story today as a standard story page. The card format (being used to great effect at Vox and Circa) is also growing in popularity.
It’s interesting to look at the initial feature set Instant Articles is offering:
- Instantly zoom into high-resolution photos and tilt to explore details.
- Watch auto play video come alive as you scroll through the article.
- See where the story happened by exploring interactive maps.
- Hear the author’s voice with embedded audio captions.
- Like and comment on individual parts of the article, inline.
This is already a nice list of features, but is this going to be it? It looks much more suited to creating long form content (which BBC News are experimenting with).
An “interactive map” feature sounds interesting, but I wonder if it will fit all the needs of every journalist that Facebook hopes to publish content via Instant Articles. At the BBC we publish a massively diverse array of types of content. Along with text and images, a standard story page on the BBC has the following features:
- Tabulated data
- Image gallery
- Video and audio players
- Lists
- Question/answer lists (definition lists)
- Quote boxes
- Tweets
- Pullouts
- Document links (i.e. to PDFs)
The Visual Journalism team within BBC News enhances these standard story pages with the following content types:
- Long form
- Interactive video
- Unique, custom built interactive infographics
- SVG based Infographics
- Calculators (enabling user input)
- Charts
All of these content types are responsive. We also like to iterate over these quickly. The Guardian, New York Times and Buzzfeed (just to mention a few of the publishers taking part in Instant Articles) also have their own massively diverse range of content formats.
For Instant Articles to replace what my team and all the development teams responsible for the 3 other publishers above would require a huge development investment by Facebook and for these newsrooms to either align their content creation workflows or massively simplify them. This is obviously never going to happen.
The story page as a format is also becoming increasingly irrelevant to online journalism. The story page format worked in the old world where a journalist was sent somewhere, wrote up their notes, filed their story, had it checked by an editor, and then added it to tomorrows newspaper.
The options on how to cover a story has increased massively, diversifying what now a constitutes a “story page”. It will be interesting to see how the publishing mechanism for Instant Articles works.
App development workflow in general is not robust enough to support a busy newsroom
Web and native have their own strengths and weaknesses. Native’s strengths are:
- Creating a interface that does one thing really well
- Customizing the experience to the user
The web’s strengths are:
- Reach
- Providing a different experience on every view
In the on going “web vs native” war of words, I’m often told that native is faster because it only has to download the content. Its ability to require just the data and none of the information about how to render that data is an advantage. While the nature of web development has a tendency to reinforce this biased view of webpage performance, its not always a disadvantage, especially when you have to support a newsroom.
The ability to quickly create something new, or something like the previous thing you published but slightly different, allows the content of a newsroom to be highly flexible. The web development process can customize itself around the demands of journalists. An app that renders all of its content natively cannot even begin to compete with this.
Within my team in news we will regularly get development requests that come in at the beginning of the day that will need to be completed within a few hours or to be released at the end of the day. The web is ideally suited to these kinds of demands, native app rendering is not.
Responsive web design (#RWD) also reinforces this advantage. The key strength of #RWD is that you create a feature once and it then becomes available on all of the devices you support. If you use apps then you have at least two codebases (iOS and Android) and so your development effort is duplicated.
Native vs web rendering
Ultimately I believe Instant Articles is an advertising solution looking for content. And while the model of publishers putting content onto Facebook works well with video, I think Instant Articles won’t be the existential threat web developers currently worry it may be.
While I’m definitely pro web I still believe we need apps. However apps need more flexibility than native rendering provides. A hybrid approach, where parts of an app’s UI is generated natively and other parts via a web view is a better strategy.
By mixing the strengths of both we can create experiences that deliver the customization an app gives us, while providing the level of immediate customization the web allows. Index pages, where the layout is mostly predictable but would benefit by being customized to the user, makes a good candidate for native rendering. Story pages though, where we need to give journalists more options and react to their needs immediately, would benefit by being rendered on the web.
We don’t need instant articles, we need flexible articles.
By @tmaslen