Rick: AMP can spark controversial debate, and I want to encourage that here!
... Everyone is this room has the same goal: make the web great :-)
... Explains ampproject.org.
... Some of AMP’s choices and implications considered controversial

Majority of the world’s computing happens on phones.

Web gets 12% share

Warning for people in the room: web is an afterthought

Chrome saw this as a threat, which partly led to PWAs

<tobie> tobie present+

Phones rely on a physical connection, finger on the screen

When jank happens, people stop engaging

Facebook tested this, and it happened.

Jank happens according to Google stats

Experience is less enjoyable, people stop engaging

Where are people instead: walled gardens

in native apps

<tantek> also relevant to this discussion, trends toward web bloat: https://danluu.com/web-bloat/

Basic flow of using the web hasn’t changed. Tap, wait, scroll.

But apps people spend time in have changed

Kenji: on mobile, the experience is linear, unlike on desktop (browser tabs)

<rbyers> Slides: https://docs.google.com/presentation/d/1LLnkQnpFZUVSiRfLCNQpmsavwOd_ICO9r0NPq_KbduY/edit

Patrick: Do people not use many tabs? I do

Rick: People use few tabs, do one thing at a time

Kenji: people will have many abandoned tabs open, though
... You lose context when you navigate to a website from e.g., Twitter
... (image of a projector as an analogy) Gap between web and native apps

Rick: web is flexible, but on phones the experience ends up being not so great

Pages tend to take many seconds to load

On the other hand, you have walled gardens with many constraints, but it helps create a consistent experience

People use the youtube native app way more than web apps

Brendyin: is this across platforms?

Rick: yes
... not here to market AMP. It seems to have worked. Question for this group: is there a way to get the benefits of AMP without necessarily using it?

Tantek: AMP made some markup format decisions.

Have the stats based on which the AMP team made their choices been published? Nope.

Rick: That’s why the Chrome team got engaged

We want to make the web great for everybody

According to W3C TAG study: AMP poses a real threat to the open web

Publishers don’t own their publishing origins anymore, analytics data

Need to invest in the web. TAG recommended investing in preloading, web packaging

Want to give an update on what we have done

Instant loading: requires flexible distribution to enable privacy-preserving pre-rendering

If I search for cancer treatment, the preloading should not leak this through pre-rendering

Guidance from the TAG: invest more in web packaging

Context originally was passing web apps around

If I have the Twitter PWA installed, share it to someone else and be sure it was not modified

User shouldn’t have to care where the bits came from

Kenji: Important is who wrote the bits, not who shared them.

Rick: Had a session on web packaging this morning

Many discussions happened

In Chrome behind an Origin Trial, customers can sign up and test it in prod

Love feedback on it

Alex: Are people doing this in practice?

Rick: Working with people

tomayac: Food network and Pinterest started testing

Rick: users prefer seamless interactions. Play with it, play with the news carousel

People don’t have to wait

It’s very slick

Kenji: Before we had this, in Japan at least, some companies enable this, but through native apps.

Such apps have seen a huge success

Gets a lot of engagement

Brendyin: Is the Google AMP URL really coming from Washington Post, or from Google?

Rick: All URLs go through AMP CDN

Kenji: Google Search would have to trust them

Easier to trust ourselves

Rick: To preserve the privacy, the pre-rendering has to come from a trusted CDN

Cloudflare has an AMP cache, Bing has one

Tantek: How do you measure that users actually prefer this? It’s a claim.

Rick: One signal we look at in Chrome is abandonment rate, some of the things were not shared

Tantek: If they abandoned, maybe they have just achieved their task

Chaals: Or they were not interested

Rick: We should try to get these stats

Tantek: Can’t take this seriously without the methodology to be opened

Kenji: Good feedback, need to take this back to the AMP team

Rick: Understand if people are happily spending their time is a hard thing

Tantek: Users prefer seamless transitions to mass propaganda. While true, it doesn’t mean the former is good

Chaals: A lot of unknown variables

Rick: How happy are you about how you just spent your time. Hard to measure

Alex: Are we going to be able to develop and ship technology that can compete with native apps?

Can we change the way people interact?

Rick: Is this better than native apps?
... Security and privacy issues aside, people should be able to do this

Bigbluehat: Attribution and distribution are a mix

Attribution and distribution might be the same thing. I work for Wiley, so you feel like you’re there and the content comes from there

If you decouple this, this perception changes. Trust in CDN is broken

Wiley has to make this choice

Multiple players in the trust matrix, not sure the reader is in the driver’s seat

Kenji: We teach users to trust a “fake” location bar That’s bad

Today, publishers trust us not to change the content

We could perfectly change the content, but don’t

<scribe> New York Times will not trust my blog

Tantek: Phishers can build websites that look like users, so users may fall for visual illusions

<tantek> that look like the blue bar shown in the Google AMP UI

Kenji: Sign the content, and you can be sure that the URL is correct

Bigbluehat: I am overtrusting too many people. This model trains people to centralize my trust

Alex: This is a choice. What is the server on the other side of the link

Nothing about web packgin right now would cause a raw navigation

It’s more a subnavigation

Brendyn: People use Google search as a URL bar

Alex: Publisher has choice, it’s an opt-in model

Which pages you choose for web packaging is up to you

You should not use private content

Gives you integrity, not privacy

Does convince us (Google) that the content is yours

Rick: Web packaging gives publishers an opt-in to a model where they own the content, but it can be distributed from elsewhere

Ian: Important distinction: it’s example.com’s domain

<rbyers> 1-

Bigbluehat: Chrome on mobile: search or type URL

URL request will be recorded

Unclear if it’s a search or a navigation

I keep my search and URL bar separate

Conflates two things into a location bar

Not sure what I am doing

Nhassan: question around what happens to the optimizations?

Will browsers have all these features, and AMP becomes irrelevant?

Rick: We got some more features to get through. The core idea is to fix the web, and AMP can become “just” a component library

Kenji: Privacy preserving is important and today it can’t be done/

Web packaging can help fix that gap

Qingqian: Similar navigation and preloading. Solutions need not to hurt the developer or publisher relationship and also improve the user experience

It’s a goal of AMP

Rick: Worried about some misunderstandings

Bigbluehat: Suddenly all your typings go to somewhere (about the location bar / URL bar confusion)

Kenji: No plans to go somewhere else

BrendynA: Browser bar looks like search bar, confusing

Rick: Where are people sending what they’re typing is confusing, agreed

Without web packaging, site A knowns when I click through to site B

Site B can opt-in for site A to pre-fetch content in a privacy-preserving way

And then site B appears instantly

The exact same information is being sent

When I am saying site A, I mean Google search

Alex: This is not different to the status quo

the content was hosted by A already

The knowledge about that traversal is the same

Bigbluehat: Further aggregates power to the distributors

Rick: Once the page loads, the analytics scripts etc. fire

Bigbluehat: I guess my issue is that I don’t like the status quo

Rick: Peer distribution can happen

Everyone who has a link to the content can distribute it. The referrer is in the same position

Aggregators have the eyeballs

This is part of the debate, signed exchanges are democratizing, everyone who has a link can distribute content for me for free, as a free CDN

All other approaches ask you to give away that power, like Facebook instant articles

Kenji: You lose your power to do your own analytics

Qingqian: JavaScript can fix the origins

Rick: This is a way of fixing, we don’t need to give away that power

Lesson 2: Can we extend more fluent interactions when navigating between different sources?

Transitions

TAG advised to look at promotable iframes that could become full pages

Kenji and I came up with a new HTML element called <portal> that can be activated with a method

Github repo with explainer is ready

Kenji: You can feel that you navigate to a new website with the current model. With portal, the transition is seamless

The address bar updates at the end of the navigation

Nhassan: How are image positions determined?

Kenji: The demo might be a little far fetched

Rick: The site is already running, it was pre-rendered

BrendynA: This is very similar to Facebook’s feed approach.

Rick: If you want to centralize all, then you can solve this. But our job is to solve this without centralizing

BrendynA: Google wouldn’t have to do this

Rick: Actually, we have to

Tink: Is there a user interaction that triggers the preload

Tobie: Scrolling could trigger it. Privacy preserving rendering enables you to do this.

Tink: I wonder if there is a challenge for people who are using a screenreader and scroll all of the time

Tobie: When you scroll, Google prerenders, does not necessarily have to be a user action

Tink: Could too many actions be triggered

Kenji: It would work the same way as today. Today, when you trigger an action, the preloading happens

Rick: Lesson 3: Constraints are key to reliably good UX

CPP by Tim Kadlec

Rick: We have built feature policy

Feature that turns off footguns

Simple example is that ads can vibrate your phone, terrible

Feature policy to disallow ads from doing this

iframes could be disallowed from sync XHR

A couple of policies shipped, but new ones coming

Images are huge, maybe there could be a policy to avoid oversized images

Reporting mechanism vs. making it visible

Adding more knobs, also composing content from different origins made safer

Scrolling in ads disallowed

The feature policy is a property of the page

whoever owns the page can determine the policy

Distributors could force opting in to feature policy

CDNs can’t change the policy

Tobie: Caching sites have restrictions

Kenji: One example is the unsized media.

One requirement could be to enforce this

Qingqian: the feature policy may be needed to be settable by the distribution

Rick: Lesson 4: Performance needs to be predictable

If you have someone, they need to be able to reason about the performance of the content

Chrome collects aggregate performance data

Chrome User Experience report, allows people to reason about performance

Can go to the database and check your performance against your competitors

Malte, head of the AMP team, wrote about standardizing this for any page

so AMP would be one way, but not the only

If portals and web packaging are supported, everyone can be part of the news carousel

Alex: there is going to be a public workshop hosted by the new york times

Kenji: End of January

Rick: Happy to hang out, end of session

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Baidu_person/Qingqian/
Succeeded: s/methof/method/
Succeeded: s/Baidu_person/Qingqian/
Succeeded: s/Kadlex/Kadlec/
Succeeded: s/require/enforce/
Succeeded: s/technology that can compete with AMP/technology that can compete with native apps/
Succeeded: s/is controversial, and that’s good!/can spark controversial debate, and I want to encourage that here!/
Succeeded: s/AMP without using it/AMP without necessarily using it/
Succeeded: s/What we look at in Chrome/One signal we look at in Chrome/
Present: tantek Qingqian kbx Léonie (tink) bigbluehat kinuko
No ScribeNick specified.  Guessing ScribeNick: tomayac
Inferring Scribes: tomayac

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)