When Google’s Accelerated Mobile Pages (AMP, naturally) arrived late last week, the journalism internet produced a rainbow of responses. We invited a few news developers to comment at greater length, and they dug into the issues with gusto and rigor.

From the Globe and Mail, we have interactive editor Julia Wolfe, who designs and develops medium to large projects and tools to help ease daily work.

Thomas Wilburn joins us from the Seattle Times, where he is one of the two news developers on the Interactives team. He works on highly custom interactive projects and special reports for the newsroom—as he likes to put it, “artisanal, small-batch data journalism.” His team’s most recent project was Shielded by the Law, an investigation into Washington’s “evil intent” law protecting the use of deadly force by police.

And from DocumentCloud, directory of technology Ted Han and developer Justin Reese, who spent a chunk of time last week digging into the AMP code so far—given that DocumentCloud’s tools are widely embedded across disparate platforms, they are particularly affected by changes to content delivery formats. Han has been leading technical strategy and development for DocumentCloud for the past few years, and Reese is responsible for modernizing the look, feel, and interaction models of DocumentCloud’s platform and embeds, as well as writing or modifying the HTML/CSS/JS that drives it.

Questions and Commentary

Q. At first blush, does AMP strike you as a potentially positive addition to the newsroom code toolkit?

Julia Wolfe: Not particularly. I can imagine the upside for newsroom would be an increase in the prioritization of performance. There wouldn’t be such a demand for projects like AMP if publishers put performance first. Readers are frustrated—rightly so—with the amount of time it takes to get an article up. AMP will force us to revisit how much we actually need.

But for those of us working in the news app or data visualization side of papers, this seems like the stunting of a relatively new story telling method. Custom scripts allow us to tell stories of income inequality, difficult tennis calls, and the shape of our cities. The tech lead of AMP admitted that the project isn’t really for that kind of content.

We’ve been told we can get a “click here for…” link. For those of us who lived through the “mobile users click here” era of interactive design, this is devastating. We’re moving back to a time when our work was second-class. We know how much traffic drops with each extra click a reader needs to get there.

So if AMP is useful it’s because it raises the stakes. If we (news developers) don’t figure out faster ways to load our pages for readers, then we’re going to lose a lot of magic. Our work is going to get thrown back into the “special content” section, away from “real journalism.” Hopefully, that threat alone is good enough to change our priorities.

Thomas Wilburn: Most definitely. Not so much on its technical merits, though those are certainly interesting, and I love the use of web components. AMP is basically web performance best practices dressed up as a file format. That’s a very clever solution to what is, at heart, a cultural problem: when management (in one form or another) comes to the CMS team at a news organization and asks to add more junk to the site, saying “we can’t do that because AMP” is a much more powerful argument than trying to explain why a pop-over “Like us on Facebook!” modal is driving our readers to drink.

I also think it’s important that one of the big tech companies is still trying to make this happen on the web. I believe deeply that the fate of journalism in the future is tied to the open web, because it’s the one place where we don’t answer to a gatekeeper. And AMP is fundamentally different from Instant Articles or Apple News, because it keeps our audience in the browser instead of shutting them away in a native window that isn’t under our control.

When we cooperate with efforts like Instant Articles, it puts us at the mercy of corporate entities who don’t share our goals—whose goals may in fact be radically different. Journalism should be upsetting, and Facebook and Apple very much do not want to be in the business of upsetting people. If you think that they won’t try to exert control of your content to make it less controversial, or use you to build an audience and then replace you with something less likely to bite the hand that feeds, you haven’t been paying attention.

For that matter, if you think you can report objectively on Facebook, one of the mammoth, unrestrained corporate behemoths of our time, while still “partnering” with them for hosting and delivery, I have a bargain patch of Seattle desert to sell you.

Ted Han: [Ed. note: Ted gave us a brain-dump instead of strictly answering questions, but as one of our community’s beacons of goodwill, we figure he’s earned the space to ramble a little.]

Yes, and no. Any focus on building a performant mobile web experience is great. However, if governed and wielded in a reductive way, AMP HTML may deliver performance by means of a plainer and less interesting web.

The news industry’s relationship with technology has largely been dysfunctional over the past 20 years, and it’s only recently that this dysfunction has begun to unravel. AMP falls into and across many of those tensions and struggles. So, AMP will mean different things to different people within the world of publishing on the internet.

Are AMP’s aspirations good for users? In almost all ways, yes. Google has had a long standing focus on building faster and better performing experiences on the internet, although not all of their efforts have gained wide-spread adoption. We’ll have to wait and see what kind of effect AMP has on the internet and publishers long term.

Is AMP good for CMSes and publishing platforms? Yes. AMP provides additional pressure on publishing platforms to provide better user experiences. Technical decision makers within news organizations can add the ways in which Google and other distribution platforms (like Twitter) plan to use AMP articles as motivation to focus on user experience. That AMP provides an opportunity for news organizations to redefine their relationship with advertisers is also interesting.

Is AMP good for journalists? Life for journalists doesn’t seem like it will change much. AMP appears to have mostly been discussed at the level of the product and platform sides of news organizations. To the extent that journalists already rely upon and trust their product and platform coworkers to build a sane and productive work environment for them, not much will be different.

There is one exception to that statement. The past 5–10 years has seen a burgeoning community of journalists who also write software. Some of the software they write is purely investigative and used during the process of reporting. But there is a substantial body of software which has been written for the purpose of communicating information to the public and show up along side, and in many cases, directly within written pieces of journalism.

The use of web technologies range from large, custom-built features like [the New York Times’ award winning Snow Fall down to apps with a primary text narrative that include additional contextual data like Marketplace.org’s Fig & York (which uses embedded data from CensusReporter).

There is a robust and creative continuum of examples of how journalists have used the web to demonstrate and explain which notably include a great deal of work from NYT’s Upshot, to the South China Morning Post’s explanation of China’s ghost cities, to KQED’s explainer on traffic as well as many others.

The AMP team’s response that news apps or large features like Snow Fall which sit on one side of this continuum should be seen in their full context on a news organization’s site is understandable, but where the line gets drawn in the continuum of interactivity is a thorny open question.

AMP’s answer so far, no interactivity except through an open source directory of approved plugins, doesn’t quite fit the way that journalism has evolved and hopefully will continue to evolve.

Restrictions on news developers’ uses of HTML and Javascript may have an impact on the kind of journalism that will be feasible for them to do in the future. What is and isn’t possible in future is the largest unanswered question within the scope of AMP HTML.

Is AMP good for 3rd party developers? Mostly, no.

3rd party developers include platforms like Twitter, Instagram, DocumentCloud, CensusReporter, and many others. All of these platforms, including DocumentCloud provide ways to embed components into news stories to provide context, evidence, or information which journalists use to communicate with the public (or just gossip about which politician or celebrity said what when).

3rd party developers also include ad platforms (including the ad platforms which Google runs). And ads are where much of the discussion about user experience on the web falls.

AMP HTML sets the baseline default for all content to be images or text essentially. Any additional interactivity or behavior must go through AMP HTML’s white-listing process (which is thus far controlled by Google).

In the case of forcing advertisers to produce better and less obnoxious ads, AMP & Google’s plans may provide a great incentive and mechanism to encourage better, slimmer ads (someone else can answer whether this is good for advertisers or not).

For non-advertiser 3rd party platforms like DocumentCloud, installing a white-listing process on the web is not a net positive. While AMP HTML’s process is substantially more transparent than any of the other major social media distribution platforms (at least AMP’s documentation is public, Facebook and Apple!), we have yet to see what the approval process will look like in practice. And at least initially, AMP’s documentation and launch partners heavily favor large, incumbent tech platforms.

Justin Reese: No.

But it strikes me as (in Ted’s apt words) a useful proxy for an important conversation about the value of performance in reader experience design.

Performance is a feature that has been increasingly degraded by designer/developer’s rich—sometimes wastefully rich—experiences and the business’s increasing capitulation to bloated and poorly-engineered ad/analytics platforms, especially as mobile traffic—where performance is most important—has become the dominant reading platform. The delta between readers’ priorities and publishers’ priorities has thus been widening, to both parties’ long-term detriment.

Ad blockers threw the conversation about this delta into overdrive, but seems to have mostly driven an arms race, with publishers taking the affront as license to dodge the ad blockers rather than address the delta. The value of AMP (along with Facebook Instance Articles and Apple News) is that they’re more akin to a peace treaty: Hey publishers, instead of capitulating to ad blockers (thus losing revenue) or trying to dodge them (thus subverting readers’ expressed priorities), why not align your priorities with readers’? By limiting yourself to these diplomatic words and phrases, y’all can speak a common language and find common ground.

So in a sense, the best possible outcome is that AMP is disruptive enough to shake the boardroom into understanding the importance of performance in platform decisions (and making the hard business decisions this demands), but that developers are allowed to implement those decisions in standard HTML instead of adding yet another delivery format to their export pipeline.

Q. What are your big unanswered questions about AMP?

Wolfe: What does the internet literally look like after AMP? The first round of examples weren’t all together inspiring. Quite a few people on twitter saw a throwback to geocities, only minus all the bubbly bright stuff that made the early internet so fun.

Future of journalism, 2012: “Snow Fall”. The future, today, via #AMP: Geocities, but without animated gifs and horrible fonts.

— Pedro Burgos (@Burgos) October 7, 2015

I like ugly fonts, a million different kinds of buttons, and the constant expectation of surprise. AMP, as I understand it, attempts to achieve efficiency through uniformity. There’s something incredibly sad about that.

I’m also curious to hear how those involved with the project feel about splintering the web. Will we have different web communities based on device? Or based on platform (Facebook v. Google v. Apple)? There’s no way most content will make it’s way onto every version of the web we have in front us. If they all survive, who sees what?

Wilburn: It’s unclear to me right now how the governance model works, and that worries me a bit. Who gets to decide which custom elements are accepted into the common runtime? Do we get a say in how those components function? Which corporate partners are accepted for tracking or ads? Right now, if you use the CDN version of the library, it looks like the only authority is “Google.” And while I’m happy to use their search engine, I don’t think I really want them to be my new CMS vendor.

I also have a lot of questions about the caching that Google says will happen for AMP pages. What triggers it? How is it hosted? Do I need to configure anything? I’m not a middle manager, so give me technical details. The documentation for this thing is awful, and while I think the caching is actually the least interesting part of AMP, it’s indicative of the level of half-assed support Google currently has invested in this. Even for the JavaScript component, I have to go spelunking around GitHub repo to answer questions that I see people asking, which is unacceptable.

Reese:

• What’s the long game for AMP vs. HTML, in the eyes of the AMP developers? Is HTML to become a ghetto of bad performance, a Flash-like relic of our barbarian past?
• The same business decisions that allow AMP to even exist (“fine, we’ll reduce our ad/analytics down to X”) could apply to the HTML version; so at the point where they’re applied to the HTML version, what’s the performance delta between AMP and HTML, and is it worth the complexity of supporting AMP as an output format? Or rather: how many of AMP’s performance gains could be had without relying on AMP-specific components, the JS library, and Google’s AMP CDN?

Q. Are there ways to achieve the (assumed) upsides of AMP without the (assumed) downsides, for your team?

Wolfe: I honestly don’t know. The enormous upsides to AMP (which, despite my crotchety attitude, I do see) require a certain level of ruthlessness. Newspapers are large institutions and have to represent many parties. That might mean tracking scripts, complicated ad tags and a whole ton of media. Projects like AMP might make sense from the platform perspective, but ignores important components to making great content.

Wilburn: Definitely. In fact, I think one of the interesting aspects of this project that hasn’t really been adequately communicated is the fact that news organizations can easily fork AMP for their own purposes. You don’t have to use the CDN version of the runtime that’s under Google’s control: you can grab the repo from them, use the standard components where possible, add your own elements when necessary, and still use the spec as defense against adding third-party scripts and invasive trackers.

That said, the interactives team at the Seattle Times probably won’t use AMP directly at all. Our whole mission is to take advantage of everything a browser can do to tell stories–we’re already using best practices for fast pages, and almost everything we do requires custom JavaScript. But our stuff can’t go in our existing CMS either: we’ve had to find workarounds like responsive iframes or just hosting our own pages wholesale. AMP isn’t really aimed at content like ours, which is a splashy but tiny percentage of everything the news industry puts out. It’s aimed at the article pages that IT departments write, where all our standard text content goes. Because generally, those pages suck.

Reese: I would be much more pleased with AMP if it was a spec for Google’s best-practice recommendations rather than effectively a new non-standard format. By using standard HTML/CSS/JS as the building blocks, they’re starting on the right foot, but the reliance on a Google-decreed AMP JavaScript library, use of separate AMP-specific URLs, and encouragement to use a Google-provided CDN are all worrying aspects.

Of course, as a series of best practices, AMP would probably have much less leverage, so if we have to go through a phase of “let’s all write this AMP bullshit to shake the dead fruit from the performance tree” (??), then it might be a worthwhile gauntlet. But this smells like WML 2.0.

Q. As questions of performance and slow third-party code become more central in the business conversation, are you finding it any easier to make changes that serve readers better?

Wolfe: I think we’re getting better. The biggest shift has been departments coming together more, communicating needs which can help to eliminate redundancy. Performance wise, there’s probably nothing worse than keeping product and editorial apart. It creates a culture where both can end up jamming several things in. When you work together, everyone is focused on the big picture.

Wilburn: To be honest, I’m not optimistic that there is a business conversation around performance. I think we talk about a lot, as journalists, because we’re plugged into the trends and we love talking about ourselves. But I’m not convinced that news management is paying attention, or if they’re willing to make it a priority. I still have a lot of conversations where speed gets lip service, but we still cut “just this one” corner for business benefit X. Cut enough corners, and eventually you’re right back where you started.

Like so many things that we think are technical problems, these are actually questions of political will and support. My team can make changes in the name of speed and innovation, because we answer only to the newsroom and we control our own platform. But we work outside the CMS, which answers to many masters, and that means it won’t improve unless there’s strong leadership around respecting our readers. If AMP succeeds at all, and I’m not convinced it will, it’ll be because its hardline stance on performance and third-party code can provide arguments for that leadership to advance.

Han: In the case of forcing advertisers to produce better and less obnoxious ads, AMP & Google’s plans may provide a great incentive and mechanism to encourage better, slimmer ads (someone else can answer whether this is good for advertisers or not).

For non-advertiser 3rd party platforms like DocumentCloud, installing a white-listing process on the web is not a net positive. While AMP HTML’s process is substantially more transparent than any of the other major social media distribution platforms (at least AMP’s documentation is public, Facebook and Apple!), we have yet to see what the approval process will look like in practice. And at least initially, AMP’s documentation and launch partners heavily favor large, incumbent tech platforms.

Reese: It’s definitely a challenge, but a really useful one. The trajectory in content design has been toward richer experiences, yet strictures like AMP pull strongly in the opposite direction. This is actually a really useful struggle: publishers and designers will constantly want to push the performance bounds of devices, while readers (especially the long tail of older-device readers) will constantly want us to understand our priority in their lives: stuff to briefly fill the time on subways or between emails and occasionally to learn substantively about a topic.

By making performance such a priority, even at the expense of rich experiences, it reminds publishers/designers that performance aligns as much, and maybe more, with readers’ priorities as rich experiences and new content formats.

We’ll Be Back

Thank you to all our participants—we’ll be revisiting performance-focused third-party platforms and initiatives later in the year as more information becomes available, so stay tuned.

• Share on Twitter
• Share on Facebook