Long-term Vision Task Force

[tobie]

Focus

The goal of this TF is to assess the impact of external changes (in particular CWV) on the project and make suggestions as to how the project should react to those.

Facilitator

• Tobie Langel (@tobie)

Members

• Sumantro Das (@sumodas)
• Senthil Padmanabhan (@senthilp)
• Jono Alderson (@jono-alderson)
• Jeremy Keith (@adactio)
• Madison Miner (@MadisonMiner)
• Marissa Halpert (@marissa-halpert)
• Kasiana McLenaghan (@KasianaMac)
• Michael Chun (@michaelwomple)
• Jett Jackson(@J-tt)
• Kristofer Baxter (@kristoferbaxter)

Deliverables

• An assessment of the current context and its impact on the project
• Recommendations of how the project should move forward as a result.

End date

2021-06-28

---

• Creation approved by the AC on 2021-06-14
• Recommendations submitted to the AC on 2021-06-28

[MadisonMiner]

I would like to be a member of this task force.

[jonoalderson]

Some thoughts to dwell on in the run-up to us kicking this off:

• For the purposes of this thinking, I'm referring to AMP as the JavaScript framework, and implementation constraints; not the cache(s).

• With the changing/evolving relationship between AMP and Google SERPs (and CWV)*, do we have clarity on AMP's positioning as a 'solution'? Who, and what, is AMP for moving forward? Is this positioning clearly understood, shared, communicated (internally and externally)? Is that consistent with current and historical positioning?

  • What types of sites or business models is AMP suitable for, in what regards? Which is it not suitable for? Is that okay, or is it a problem?

  • If the AMP standard makes a deliberate trade-off between 'best' user experience vs developer complexity, in favour of the former, how does that impact the ecosystem? E.g., the New York Times may struggle to implement a mechanism via AMP which another publisher might not. How much do we (and who is 'we') 'care' that individual sites/businesses/pages are for all intents ineligible for AMP? What are the implications of this?

• Is, or could AMP become, a perpetual polyfill for performance; paving new standards and mechanisms which eventually get absorbed into HTML/CSS/JS etc specs? What would that look like, as a process? Is there a point at which it might be deprecated?

• How does Bento AMP alter the answers to these questions?

• Conversations have highlighted a disconnect between how AMP is described and positioned (via its website, content, etc), and the reality of AMP's current capabilities. E.g., A/B testing via Optimizely was presented as a feature, whereas in reality, this was only a (partially operational) proof-of-concept.

  • It feels like we lack a cohesive, open, shared vision of the roadmap and priorities of AMP-as-a-product. I think we'll need to address this if any output of this group is to be useful/utilized. https://amp.dev/community/roadmap/ exists, but is 'thin', and full of surprises/omissions.

*Whilst we should aim to maintain some separation between AMP and Google's implementation of AMP, it was that implementation that originally drove significant adoption. With that implementation (or factors around it) changing, this should unavoidably impact our exploration.

[marissa-halpert]

I'd like to join this task force. Thanks!

[KasianaMac]

Please add me as well!

[michaelchun404]

I would be interested as well please and thank you!

[J-tt]

I'm very interested, but unfortunately don't have the time to keep up with meetings, so I'll interact just through the issue and keep tabs here.

[tobie]

Hi everybody,

Thanks for your interest in this task force.

I'm suggesting we do kickoff meeting next week at our regular meeting time on Monday. I will send a calendar invite.

In the meantime, if you can share your thoughts here as to what this task force should tackle, I'll compile that into an agenda for us to address during our first call with the goal of defining our focus, deliverables, and timeline.

@sumodas, you brought up some interesting points yesterday during our call. It would ne awesome if you could summarize them briefly here.

This is exciting, folks, looking forward to it.

[jonoalderson]

Some initial thoughts...

A lot of our discussion circle back to asking, "What is AMP?". Until we can answer that, it makes discussions around advice, strategy, audience, success criteria etc, hard to wrangle.

From my perspective, the moving parts in those discussions are (feel free to disagree):

1. AMP is simultaneously multiple things:

• A set of (opinionated) rules for authoring web stuff
• A set of resources that reflect/support those rules (e.g., https://cdn.ampproject.org/v0.js)
  • Arguably, this might also be considered to include https://amp.dev/.
• A mechanism to access privileged caching mechanisms (E.g., Google's AMP cache)
  • A mechanism to access privileged Google search result types (but not anymore)

When we talk about AMP, it's still unclear which of these overlapping pieces we mean. Externally, there's still a perspective that these are all the same thing, and that Google's change of requirements for "news carousel" access is the de-facto death of AMP.

There's a lot of movement happening across AMP, in many directions, but it's still unclear what our goals, objectives, or success looks like. What's the mission? What's the vision? What's the direction?

2. There are mixed perspectives, experiences, and varying qualitity-of-fit across these areas. Generalizing:

• The anecdotal research we've seen suggests that small teams of "average" web developers have relatively good experiences with AMP:

  • They use it because it's easier to achieve performance goals with it than with other approaches, and;
  • Use a "pure AMP" approach (with no alternate template/url), where AMP is their primary front-end framework.
  • This approach appears to be driven, at least in part, by senior folks in their organizations (and/or clients).

• That said, anecdotally, many small sites and many (most?) "normal business website operators" rarely know/care what AMP is/does.

  • Their development teams, hosting companies, CMS vendors, and ecosystem developers may use/recommend/implement AMP standards on behalf of their clients/end-users; but those end-users aren't engaged.

• And many large (publisher) sites resent AMP.

  • They feel like they were forced into it, and they want to drop it because they believe they don't need it / don't want to maintain AMP (templates, functionality).
  • There's a perception that AMP is unfairly rewarded / non-AMP pages are unfairly penalized, in the context of Google's handling of AMP pages in their search results.
  • For them, AMP is a set of (unwanted) constraints; either technically, or ideologically. Often hard to integrate with existing business requirements (or, conflicts technically/ideologically with those requirements)

We have (many, other?) different audience types here, whose experiences and requirements differ greatly. AMP is a different thing to each of these audiences, but our positioning of AMP doesn't reflect these wildly different use-cases.

3. Bento AMP & self-hosting resources may change this landscape:

• If everything becomes truly component-based, and adoption is a gradiated rather than absolute thing, then:

  • AMP could reinvent as a 'best of breed components library' for performance/privacy/etc.
  • Teams of all sizes could cherry-pick components based on their needs, without the need to aggressively segment audiences and targeting
    • Canonical AMP (or even "AMP templates" as a broader concept) could be marketed as a niche option for eager adopters.

• Self-hosting resources closes off one of the final performance gaps between "cached AMP" and origin AMP, which;

  • Enables sites to achieve near-equivalent performance at origin, vs in Google's cache.
  • Solves for many of the ideological oppositions to Google's cache, without compromising on / whilst achieving comparable performance.

4. We've some ideas on what AMP could be:

• "A polyfill for performance?"; where the focus is to provide a framework for best-practice development techniques which are otherwise hard to achieve/support impact, etc (e.g., native image lazy-loading, adoption of new CSS techniques like content-visibility, etc).

• Similar to how jQuery initially made node targeting more accessible, and eventually normalized querySelectorAll.

• Could we extend to *"A polyfill for everything" *which extends this beyond just performance? How would this be a different thing from Bento AMP?

• We're back to different use-cases:

  • For large publishers, might AMP be a way of opting into experimental standards?
  • For small sites, might AMP be a turnkey performance guarantee?

• We've discussed if AMP could become an intentionally self-deprecating roadmap; a set of specific web/performance problems which AMP aims to solve, at which point AMP's job is done. This raises some questions:

  • How/when is it "done"?
  • How is this different to, e.g., Chrome standards?

• Does any of this require a change in our ("our"?) current direction, advice, or focus?

[KasianaMac]

Really looking forward to this discussion today, and appreciate your initial framing of this conversation @jono-alderson. I think that's largely right. However, there is one item that I would like to highlight as we go into this discussion and think about AMP's future vision and focus: how we frame the fundamental tradeoffs that AMP is making.

AMP should leverage developers' knowledge of their users, not dismiss it

I've worked with AMP both at a publishing startup, driving forward with ~10 FTE engineers, and at the Times, which I would venture to guess has more engineers on staff than any other US publication. I have run into persistent challenges in both positions (while noting, of course, that this is my personal observation and not the official position of either company).

As a product manager, I think pretty obsessively about my user. Not only that, I also engage in user research, comb through usage data, read public reports, and generally spend my day thinking about how to best serve the news to readers/subscribers. As a result, I don't think that we should frame AMP as navigating a tradeoff between the 'best' user experience and a streamlined developer experience, and/or the nefarious desire of publishers to place a bunch of slow/obtrusive/privacy-invading ads on the page. That may have been relevant when AMP was starting out, but particularly as publishers move towards a subscriber-first business model, that framing just doesn't make sense. Today, publishers like the Post or the Times explicitly win by best serving users. Even at primarily ad-supported publications, the strong desire is to implement advertising in a way that serves users, who have a surfeit of choices about where to get their news. Creating a great user experience makes it more likely that someone will come back and engage with a publisher's site again and again.

By contrast, by making it opaque/difficult/slow to extend AMP pages beyond the most basic use cases, I think that AMP is actually impeding the 'best' user experience. I don't believe that a user is served by pages that treat developer's own cookies as coming from a third party, nor by pages that don't recognize their logged-in status, nor by hamstringing a publisher's ability to use A/B testing solutions to improve their pages. It feels paternalistic to have AMP say that they are making a tradeoff between a user's experience and developer complexity - our developers are largely working in service of the user, so their difficulty in developing that experience is simultaneously degrading the user experience. The interests of our users and our developers are largely aligned.

As we think about what AMP should be moving forward, I think it's important to update our mental model about publishers interests, and stop framing AMP as the champions of a great user experience against publisher's short-sighted, monetization-hungry desires. I'm confident that the product managers of the New York Times have a better sense of how to serve our subscribers than AMP does. I think it would be immensely beneficial if that knowledge was seen as a resource by those directing the development of the AMP platform, rather than dismissed as a desire to prioritize the developer experience.

[jonoalderson]

Some interesting thoughts to pull out here, for sure, in particular:

• User state context (logged in, logged out, member of X testing segment) is poorly supported.
• Cookie stuff is poorly supported (is this a child of the above?)
• The positioning and framing of AMP (to, in) the market definitely feels off, in various places; the 'paternalistic' angle in particular.

[jonoalderson]

One more consideration, and a potential lightbulb moment...

How much is the perception of a paternalistic/combative relationship is a potential 'hangover' from Google's legacy 'ownership' of the project? How much of how AMP is framed, run, etc, is (still) accidentally(?) inheriting positioning, opinions, etc, from Google's previous (and continued) influence? What, of that, is good, bad, right, wrong, or should at least be considered?

To your point about the NYT knowing its users better than AMP; It could be argued that Google's search ecosystem doesn't really care about NYT subscribers; they only care about their broad audience, and whether those users get a fast (and good, relevant, etc) page. They don't really care 'who' wins, as long as someone does. That's historically led to a lot of "us vs them" mentality in that space. How much of that thinking - and the positioning of the relationship between AMP, publishers, developers, and users - might we be accidentally (still) inheriting, and iterating on without intent?

For example, we use words like 'requirements' and 'validation' frequently throughout AMP - perhaps because the project evolved out of an ecosystem where there are binary 'right' and 'wrong' approaches (because Google wields enough power to make and enforce those definitions). We've not challenged any of this because we've only iterated AMP, and never designed it.

So what if, for example...

• We had 'recommendations' instead of requirements?
• We look at Bento as a way to re-frame AMP entirely as enhancements, rather than as a set of constraints?

The more I look at it, the more I think that aspects of the framing, language, positioning, marketing, documentation and more, all start from the assumption that 'AMP knows best', perhaps because Google has a habit of thinking that Google knows best?

Food for thought.

[KasianaMac]

I think that nicely sums things up, and moves my comment from framing a problem to starting to point towards some solutions.

[jonoalderson]

Some interesting data: https://twitter.com/aleyda/status/1396021867434160128