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.)[End of scribe.perl diagnostic output]