[MUSIC PLAYS]
ROWAN MEREWOOD: Hello.
I'm Rowan Merewood.
Yeah.
SAM DUTTON: And I'm Sam Dutton.
And yeah, we'd
like to really talk
to you about some of the
revolutionary changes we're
seeing in e-commerce.
ROWAN MEREWOOD: Yeah.
You've seen a lot of
e-commerce sites demoed today,
and we really think this
is just the beginning
of the conversation because the
pillars of the PWA technologies
that you've seen,
we really think
these are fundamental to
improving the online shopping
experience out there.
SAM DUTTON: Indeed.
You know, at the heart of
the e-commerce revolution
is this huge growth
in mobile computing.
The shift to mobile
has completely
transformed the landscape
for online retail.
You've seen this, right?
A couple of years ago, depending
on whose stats you look at,
mobile overtook desktop.
And this is a huge shift for
e-commerce in particular.
Not just that, but we're seeing,
of course, this huge growth
in the number of people online
who generally don't actually
use desktop or laptop devices--
not just mobile,
but mobile only.
And just bear in
mind that mobile only
doesn't mean that everyone
is doing e-commerce
on high-end smartphones.
New phones like
the Geophone here
and the Alcatel GO FLIP,
they're hugely popular,
and they're becoming a very
appealing and accessible
upgrade for many
users, not least
the hundreds of millions
of feature phone users
who now want to shop online.
And all this is, is
a major challenge
for e-commerce developers.
And just to be clear,
online shopping
is already a huge deal.
Last year, mobile commerce
was worth something
like $123 billion
in the US alone.
Globally, the mobile
share of e-commerce
is growing really fast.
In the US, mobile accounts
for nearly a quarter
of all e-commerce, and
we're seeing similar figures
for other countries.
Now, it's no surprise, given
the rise of mobile computing,
that a majority of
commercial traffic
is coming from mobile devices.
Now, what is surprising,
perhaps, here
is how much of mobile e-commerce
is happening on the web
rather than in native apps.
Retail on mobile and
desktop web already
gets a relatively high
proportion of user time
compared to other verticals
where people are more
inclined to use mobile apps.
This data from a
recent UK study shows
that retail has a relatively low
share of app minutes compared
to other verticals.
There's another growing problem,
I think, for native apps here.
The reality is
that, unless you're
one of your customer's
best-loved stores,
you're unlikely to find a
place on their home screen.
And I think this is,
like we've heard,
where the mobile
web really shines.
You get reach for e-commerce
without that barrier to entry.
However, conversion
rates-- people
who actually complete
a purchase-- on mobile,
on the mobile web are far lower
than for desktop websites.
Mobile conversions are about one
third of desktop conversions.
And this is, I think,
a fundamental challenge
for the web.
The web has gone mobile,
but convergence on mobile
remain low.
Of course, this is not all about
negative experiences on mobile.
People have positive reasons
for completing purchases
on desktop devices or in store.
People use different devices
at different times of the day,
in different contexts, and
platform share actually
varies quite a lot
between retailers.
There are even
seasonal differences.
I just learned actually
that, in the US,
there's this big increase in
mobile usage for purchases
between Black Friday
and the end of December.
It's interesting.
But the fact is that the
shopping experience on mobile
has left a lot to be desired.
We've all done this
kind of stuff, yeah?
And e-commerce,
as I realize now,
is all about removing
friction, and we
need much better
integration with devices
and with platforms.
Another way of cutting
this is to look at time
spent online versus
money spent on mobile.
Simply put, people in the US
spend most of their online time
on mobile but much more
of their money on desktop.
Now, given the success of
online retail already on mobile,
a better shopping experience
represents a huge opportunity
for the web.
So how do you get
started with that?
Rowan, please tell us.
ROWAN MEREWOOD: I'm
glad you asked, Sam.
Seamless transition.
OK.
[LAUGHTER]
I want to open up my section
with an overused cliche, which
I will seamlessly shoehorn into
an e-commerce context for you.
And it's this.
If a customer doesn't
convert on your site
and no one is around
to measure it,
does it actually
make a difference?
People are on your site.
They may even be buying things.
But if you're not
measuring it, you
can't make an informed
decision about what to change.
So we've told you about
setting a performance budget.
I want you to do that.
And I want you to be measuring
things like low-level metrics,
like page load.
That's useful, but it's
not the whole story.
Also, look at the holistic
metrics like [? Serma ?]
was showing you, like
time to interactive,
because that's more
indicative of the user's
actual experience.
However, none of this
actually means anything
if you measure these
signals purely in isolation.
There's no value.
When we've constantly reiterated
the performance message to you,
the foundation of it
has been that users are
abandoning those slow sites.
There's a real consequence
for poor performance.
So what you need to do is
use your own business metrics
to create your
definition of success.
Those metrics, the
technical metrics,
are then tracking your
progress towards it.
Of course, the problem
with all of this is people.
Once you give people and
especially developers a score
to work towards,
they're going to focus
on trying to hit that score.
And that leads to
this kind of thing.
If I'm incentivized on
performance metrics,
then I can optimize for
page load, bandwidth,
time to interactive, and so on.
And in fact, here it
is, the world debut.
This is Turbo Shop.
This is the fastest e-commerce
experience in the world,
and it looks like this.
It's a text box where you
pop in the product ID,
and you just press Buy.
A search box and a button,
we know this pattern works.
This is going to
change the world.
Now, I hit all my
performance targets,
so the business
metrics are going
to be equally amazing, right?
No?
A slightly extreme
example, but I
do see this kind of thing
happening in the real world.
It might be that
it's just cutting
the number of images
that are in your image
carousel to reduce bandwidth.
Or maybe you have
a database query
that is quite intensive
fetching a list of products,
so you limit the number of
products that's returning.
The thing is people will cut
critical content in order
to meet the performance metrics
they're being incentivized on.
So what you need to
understand, then,
is what's the right
business metric here.
To work that out, you
have to understand
what people are actually
trying to do on your site,
and here are a few examples.
Firstly, 90% of the
users coming to your site
are going across multiple
devices to make a purchase.
So sure, it's easier
to measure conversion
if it all happens
on the one device,
but it's really not
the whole story.
And when I say
embrace that, I don't
mean just make a good experience
on mobile and a good experience
on desktop.
I mean really support
me moving between those
as part of that journey
because browsing on mobile
and then purchasing
on desktop is actually
a fairly common pattern.
And it's not always just
cross-device either.
87% of people are
checking online
before they head into a physical
store to make the purchase.
So don't assume just because
I didn't convert on the site
that that doesn't mean success.
And finally, you can
mirror that back again.
When they're in
the store, they're
right back on their phones
looking for information
about the products that
are in front of them.
So I want you to
measure conversions,
but I also want you
to think about where
the customer goes after that.
If you've got the experience
right, they are coming back.
Maybe they're even telling their
friends or colleagues about it.
So you need to
dissect your pages
to understand how those
components are affecting
the conversion for
different user types.
Do they read the reviews?
How many carousel images
are they looking at?
And provide ways to tie
that online experience
to the in-store
experience as well.
Because basically,
the message here
is that the technical
metrics are just
a tool for tracking progress
towards the business value
you are trying to deliver.
Don't just blindly try and
pursue these performance
targets because
we've told you to.
Always be re-evaluating
your metrics
to ensure that they're
incentivizing the goals
that you really care about.
OK.
That little bit of
intro out of the way,
let's dive into the
first and most obvious
aspect of an e-commerce
site, which is actually
showing people products.
The message I want
to convey here
is really just an
architectural one.
For implementation,
I kind of want
you to take everything
you learned in Addy's talk
and [? Serma's ?] talk
and just apply it here.
Then, go home.
But remember the
business objective
you're trying to
achieve because it
can be tempting to find
creative interpretations of some
of these metrics.
For example, here's
an anti-pattern
that I've seen on
a few sites, which
are going to remain nameless.
And it's when you start
adopting an app shell-style
architecture, it's incredibly
helpful in getting that time
to first paint down,
and it's tempting to say
that it's a meaningful
first paint as well.
I mean, we got the
brand up there.
We had an indication
of progress.
But what I came for
was the product.
So don't let your code structure
dictate the way that you
display content on screen.
Fix this by ensuring that you
understand the performance
budget for your
shell and that's not
delaying your other content
by waiting for the shell
to actually boot up.
Additionally, there's this
one, and I still see this.
And this is unstable loading.
So you got your critical content
there first, and it's great.
It's glorious.
It's this cat that lives down
the street, which obviously you
want to see a larger version of.
So you get right in, and you're
just about to tap and bam,
we pop an ad in right
under your finger.
[LAUGHTER]
SAM DUTTON: I like the dog.
It's beautiful.
ROWAN MEREWOOD: We need more
cat pics, not more dog pics.
Honestly, when people
stop doing this,
I can stop including
it in presentations.
Not only is this
annoying to your user,
but all that additional
rearranging of elements
is hurting your page
performance as well.
So make sure, like [? Serma ?]
said, if possible, you
include everything
you need to do
the layout of that page
in your first request.
You can actually see
this approach in action
if you take a look at how
AMP renders its content.
Even if you're not
implementing AMP,
you should learn from the
lessons of what they do here.
By mandating a static
layout, it means
that the runtime can
calculate the elements that
are going to appear
in that first viewport
and optimize to load
those resources first.
Images get loaded on demand.
Ads are always loaded with
a really low priority.
And these best practices
come through when you
look at some of the AMP format.
So here you can see
a little snippet
where we've got an IFrame.
We've set the height and width.
We provide an image
in the middle,
which is going to give ourselves
fallback while it's loading.
But AMP also defines this
layout component, which
provides some rules
like responsive,
fail, and fixed, and so on
that allow that flexibility
in the display of the
element but in such a way
that it's still
possible to determine
the layout without the
content there already.
As the format has grown, we've
been adding more elements
to address the needs
of different verticals
like e-commerce.
The amp-bind component is what's
enabling the behavior up here,
i.e. clicking a different color
to change the product image
and so on.
These examples come from the
aptly named AMPbyexample.com,
so you can go there to find
way more detail about this.
And as well, earlier,
[? Tau ?] mentioned overstock,
where they've added AMP
for that category pages.
Now, that stable loading that
I talked about in the layout
means that I get that
real meaningful content
in front of me near instantly.
And to tie it back to
the business metrics
I was talking about, they've
seen an 8.3% jump in conversion
from these pages.
Looking at the
screenshots, though, images
are pretty prominent here.
Now, the AMP image tag provides
a number of optimizations
out-of-the-box, but what about
your publishing on the wider
web?
Well, luckily, Sam has
some opinions about this.
SAM DUTTON: Yes, indeed, I do.
Product image is a fundamental
component of just about
every e-commerce site.
Successful online stores
display dozens of product images
on every landing page.
And now, as you've heard from
[? Eva's ?] presentation,
you need to develop load
strategies for all your images.
But of course, e-commerce
is kind of different.
Product images aren't
just for decoration.
Whatever devices or
platforms or e-commerce
frameworks you're targeting,
you really, really
need to optimize your images.
We review a lot
of websites, and I
think it's fair to say
that better use of images
is the single
biggest improvement
that many e-commerce
sites can make.
With image optimization, small
changes can have a big impact.
And as we know, that data
bloat can increase data cost,
but also can eat
into memory, which
can have a really detrimental
effect, especially
on lower-spec mobile devices.
And as actually Sam [? Sicone ?]
will describe in his talk,
image loading can actually--
load and decode can actually
delay JavaScript pausing.
So you need to be really
careful about this stuff.
Using the wrong
image format, there's
a particularly common
cause of data bloat
that we see on e-commerce sites.
This example is from a
well-known shopping site.
The biggest images,
it turns out--
and I looked in the Dev tools--
are photographs saved as PNGs.
This second one here is
like a photo of a cat
that I managed to easily
reduce to around 13k just
by resaving as a
high-quality JPEG,
compressing with ImageOptim.
This is a huge deal for the
mobile web and e-commerce.
Another common problem we
see on e-commerce sites
is product images saved with
dimensions larger than needed.
You should, of
course, save images
using pixel dimensions that are
appropriate for target display
size and pixel density,
and this can significantly
reduce data cost.
But like I say,
also memory usage,
which is, of course,
a particular problem
for low-spec devices.
In this example, actually
quoted from Addy Osmani's book
about images.
He's just published his e-book.
Twitter made some
changes, and they actually
reduced decode time for a lot
of their images on the timeline
from like 400 milliseconds
to 19, which is huge,
really, by making just a
really simple change there,
getting image sizing right.
Of course, not loading images
at all is a great solution,
or not loading images
until they're required
can solve a lot of data cost
problems for image-heavy sites.
But you do need to be careful.
With product lists
like infinite scrolling
or otherwise, it can be really
sensible to avoid pagination,
but we do see this on a
lot of e-commerce sites.
There's nothing worse
than being forced
to wait for images to
load while you scroll.
Don't do this.
This kind of jank
loses customers.
Now, the new
Intersection Observer API
that I think [? Marico ?]
and Monica, I think,
showed briefly
earlier can provide
a much less janky experience.
This API gives
JavaScript the ability
to respond when elements are
about to enter the viewport.
Let's see that in action.
And we'll see some kittens.
This is Lars and Little Puss.
Anyways, in this demo,
the image is actually
only loaded when it
gets to within 100
pixels of the viewport.
And you can see, of course,
the image actually loading
from the Dev tools
network panel.
It's pretty easy to
code this kind of thing.
In this example,
I've added the data
source attributes to each image
specifying the image to load.
And then in the JavaScript, you
create the IntersectionObserver
and set it to watch
for one or more images,
and then set the
source when they're
about to come into view.
In this example,
the root margin is
set so that the callback
loads images 100 pixels
before they reach the viewport.
Of course, you can't
always guarantee
images will load in time,
especially when you're
considering fluctuating
connectivity.
As you've seen on lots of
sites, a nice technique
to improve perceived
performance is
to load a low-resolution
placeholder
before the full image.
Facebook, Medium, lots of
sites have done really,
really ingenious
versions of this
in different kinds of ways.
One of my favorite takes on this
actually, just seen recently,
is image-trace-loader.
I don't know if people have seen
this, but you can see it here.
This is using a node module that
creates SVG placeholders which
can then be used in line.
It's really nice.
One thing that's actually
struck me looking
at lots of e-commerce sites
is the sheer number and churn
rate for images.
I just counted, and
Amazon has something like,
I think it's 81 images
on the first load
of its home page on mobile and a
whopping 290 images on desktop.
ROWAN MEREWOOD: That
is a lot of cap.
SAM DUTTON: It is.
It's astonishing.
So as well as, obviously,
individually optimizing hero
images, you'd need to automate.
You must automate
image production.
And thankfully, there
are a lot of really good
free and paid-for
tools and services
to create and optimize images.
The point here,
I think, is that,
to handle images at
e-commerce scale,
you must incorporate
good optimization tools
in your workflow.
It's kind of fundamental.
So finally, you really need
to also build image testing
into your workflow, and
Lighthouse makes this really,
really simple,
identifying images
that could be better compressed,
better sized, or otherwise
optimized.
People love high-quality
images on retail sites,
so they can really help
drive retail traffic.
But you need to make sure
that they don't weigh down
your website.
ROWAN MEREWOOD: Oooh.
Thank you.
OK.
That was a pretty intense blast.
SAM DUTTON: I can keep
going if you want.
ROWAN MEREWOOD: No, no, no.
SAM DUTTON: A subject
dear to my heart.
ROWAN MEREWOOD: We cut like
80% of our content already.
We've shown you some products
with beautifully-optimized
images, but that first
product isn't always the one
you want to buy.
You may actually want
to navigate around
the rest of the site.
So we should probably
think about doing that.
Now, I feel like
e-commerce occupies
this space somewhere
between content consumption
and a task-oriented application.
If I'm consuming video
content, then the player
will buffer ahead, ensuring
that, say, the next 30 seconds
of video are loaded for me.
So as I explore your
site, I want the content
I visited to be appropriately
cached so I can come back
to it, and ideally
I want the content
I will visit to be preloaded
so it's ready when I get there.
Of course, bandwidth
isn't free, so I'm not
going to be happy if
you go ahead and preload
every single possible
link off of the page.
One way you can go
about doing this,
if you have a service
worker in place caching
your incoming requests, is
that you can use the link rel
prefetch tag.
Now, what this means
is that prefetch,
the browser will fire off
a low-priority request
for the resource you've
specified in its idle time.
And this means you
can safely start
to warm up the next
set of resources
without impacting the
user's current experience.
The difficult part here
is not doing the prefetch,
it's choosing what to prefetch.
So like I was saying
before, you need
to use your metrics
to determine what
are these likely next steps and
build a threshold in for when
you want to fetch them.
Now, you can also just choose to
add items to the cache directly
yourself.
As Jeff mentioned, the
cache API is actually
available from the window as
well as the service worker.
This is useful if you want
to trigger this behavior
in response to a user action.
So for example, if you have
products that are often
purchased together, once
I add one to my basket,
you could go ahead and
precache the other products
so that they're ready for me
to browse through immediately.
The other thing that
you could also do here
is just trigger a fetch request.
So if you already have
a fetch handler that
is handling your
caching, especially
if you're doing
something more complex,
then firing the fetch lets
you encapsulate that behavior
all in the fetch handler and
just do the caching there.
While this is more
powerful, you do
need to be a bit more careful.
These requests are
just sort of fired
as soon as you specify
them, so you're
responsible for scheduling them.
And be careful not to mix
in this kind of approach
with the preload
and prefetch as well
because you can easily
trigger duplicate requests
for the user.
So that's some
browsing and exploring,
but what about if I already
know the product that I'm
looking for?
SAM DUTTON: Yeah.
That's where search comes in.
Findability is crucial for
successful online retail.
I'm not going to
talk about SEO here,
but what I want to talk about
is search within your website.
The need for search
really differentiates
e-commerce from other
types of sites and apps.
This is one of the
task-oriented aspects
of the e-commerce experience.
As you can see from this
chart, search on shopping sites
could do a lot better.
This is a survey of
top-50 retailers.
And it shows really quite
high levels of frustration,
basic problems with search.
Product search really
needs to improve.
Even just to match data
beyond product names
would be an improvement
for a lot of sites.
And a good start
with this really
is just to look at
your search logs
and see how people are
actually searching.
And I think there's a common
theme in a lot of this.
It's like resilience
to differences
in online behavior,
the variety of ways
that people search for
products in this case.
So Rowan talked about
caching static content
or preemptively caching
resources dynamically
to make sure not to
interrupt the customer flow,
but what about search
for e-commerce websites?
People have a perception
that native apps can
work without connectivity
or under flaky connectivity,
and not the mobile web.
But that's changing.
Wouldn't it be great if
search could work offline?
Search that could handle
flaky connectivity
is not available on
any e-commerce site
that we're aware of.
We would like to
be proven wrong,
but this seems strange to me.
Places with intermittent
connectivity like transit,
public transport, for
example, are exactly
the kind of contexts
where people
might want to search or
browse your products.
There's a reason why there's
advertising on subway trains
and buses and so on.
Of course, there are caveats.
Price or availability
data can become stale,
and data caching can only
work for a limited number
of products.
Content is also limited.
You can't preemptively cache
hundreds of product images,
let alone like videos
or other heavy content.
What data you choose to cache,
choose to make available
for search depends
on your users,
and you could really
make a choice here.
Now, there are lots of ways
to do search that I'm not
going to talk about--
backend search engines
like Solr, Elasticsearch,
newer full-stack frameworks
like Firebase's Firestore,
for example.
What I want to show you
is one simple way to build
client-side,
offline-enabled search--
not because this is the best
or the only way to do it,
but just because it shows
that network resilient
search is actually possible.
So here it is in action, product
search which is super fast,
and it actually works
seamlessly online or offline.
Images load if they are cached,
or otherwise you just get text.
Now, this demo uses a
JavaScript library called
Lunr, which is based on Solr.
As they say on the tin, it's
not as bright but much, much
smaller.
The core idea is that you
build an index on the server
or on the client and then use
that with a minimal JavaScript
library to implement
full-text search.
Now, what's nice is that the
index with the product data
is JSON, and it can be
stored using the cache API.
And that makes it really,
really simple to implement.
And you can even
include, like I say,
the data with the index
in a single JSON file.
The major constraint
is that the index
is often for a set of
data significantly larger
than the data itself.
But that can still
be very manageable
since JSON compresses
really well with GZIP.
In our tests, we found that
combining the index and product
data for a thousand items took
a bit over 300k compressed.
About 2/3 of that is
actually the index data.
So that's pretty good.
In the example I've
used, I've actually
used something
called Elasticlunr,
which, as you can
see here, compresses
to a very tidy six kilobytes.
Lunr can actually be used
to enable full-text search
in other contexts
like with IndexedDB,
with wrappers and framework,
stuff like Dexie and PouchDB.
Let's just take a
look at the codes.
First up, you need to
build search index data
from your product data, and
you can do that on the server
like I have here using node.
Alternatively, you could
actually fetch the product data
and then build the index on
the client like I've done here.
Second, to enable that network
resilience I talked about,
you can cache the index
locally using the cache API.
Here's some service worker
code to do just that.
Here, I've specified
an array of resources
to cache in service
worker event listeners.
And here's the code for caching
and handling fetch requests.
And then you can get
your index data, load it,
and you're good to go.
And remember that the index
data, including the product
data, is now cached,
so you can still
do search even if connectivity
goes up the spout.
Finally, the bit that matters.
There are lots of
options for search,
but it can be as simple as this.
Like I say, we'll give you a
link to some offline search
demos at the end of
this presentation.
Now, I understand
it's just a demo,
and this approach is certainly
not suitable for every site.
The point here is that it's
possible to build experiences
that work really well
despite erratic connectivity
or no connectivity at all.
Service worker and the cache
API mean that network resilience
is becoming the norm for
good web experiences,
and I think e-commerce
really needs to embrace that.
ROWAN MEREWOOD: Cool.
OK.
I feel like there's kind
of an extra session there.
SAM DUTTON: Maybe in
the bar afterwards.
ROWAN MEREWOOD: Sam will
do that at the after-party.
And now, we're into the
homestretch, which we're
going to do really quickly.
[LAUGHTER]
Which is, we're actually going
to add something to our basket
and we're going to buy it.
At least, we're going
to try and do that.
The problem is over
half of US consumers
are abandoning their carts.
That's due to small screens,
too many fields to fill in,
poor connectivity,
or poor performance.
So this is getting to the heart
of that 66%-lower conversion
figure we showed
you at the start.
We want to try and
solve this problem.
If users are abandoning
the site because it's
a subpar experience, obviously
we should address this.
However, like we saw, people
want a cross-device experience.
So we should embrace
that as well.
Users should be able to choose
where they want to shop.
And that's the key.
It should be a choice,
not just because we've
made the alternative
horribly unusable.
So let's start with
filling in forms.
You may remember the
stats from earlier today.
If you don't, then here's a
reminder of how many times
we help people there.
This is eight billion
sign-ins assisted per month.
I think the number this morning
was actually nine billion,
but I can't even
imagine eight billion,
so eight, nine billion--
SAM DUTTON: A lot of people.
ROWAN MEREWOOD: Yeah.
It's a lot.
Basically, what this
translates to is
I would like you to mock
up your forms properly.
And seriously, it's
so trivial to do this,
and it makes your users-- it
makes my life a lot easier.
It's not just the autocomplete.
It's giving me the right
keyboard for my email address,
my credit card
number, and so on.
In fact, those of
you with your laptops
and access to your code,
check this right now.
Get it implemented.
I will review the PR for you.
SAM DUTTON: We promise to
LGTM all those requests.
ROWAN MEREWOOD: I saw
you all with laptops.
I know you can do this.
And of course, like I said
before, it's not just--
I mean, I assume you have a
metric for how happy I am--
but maybe that's not
the most important one.
You probably want to measure
some other things as well.
There's an approach from Paul
Kinlan that you can use here.
It makes use of the
webkit-autofill pseudo-class.
So you can hook a
listener onto that,
listen for your input events.
[INAUDIBLE] you can now detect
when autofill has been used.
In the end, we're still
filling in forms, though.
We're still sending passwords
and credit card numbers
over the wire.
We've improved the
user experience,
but the underlying
problems still exist.
Now, you seen Payment
Request a few times today.
What I want to highlight here is
the journey from those forms--
at the basic level, this
is programmatic access
to retrieving those
saved card details.
So now, you have this
browser-level, standardized way
of retrieving card data and
shipping addresses and more.
But beyond that,
it's also beginning
to provide that integrated hook
into native payment requests
like Android Pay and so on.
You move past
transmitting card numbers
to something that is both
simpler and safer for you
and your users.
So just a quick
reminder, another video.
It's almost like they
knew we need to speed up.
So they're like, just skip that.
Skip it.
[LAUGHTER]
SAM DUTTON: It's tragic.
These are just
files on the page.
How can you need to
request access for that?
ROWAN MEREWOOD: So
this is what you do.
You set up your data
first, your payment method,
the transaction, the
shipping request, and so on.
You create the payment
request, passing that data in.
When you call show, this is
what triggers the request
to be displayed on screen.
And then, when that
promise resolves
when the user has
completed that,
you either handle
the completed request
and send it to your
payment processor
or you handle any errors.
Now, Payment
Request, as you saw,
is also available on desktop, so
I can have the same experience
there.
But what about taking
my basket with me?
I just don't want to
browse on my phone and then
re-add everything on my laptop.
And like I told you,
Chrome will help you there,
but you're still making me
go through the extra effort
of pressing a button to do that.
Credential Management
API is, again,
moving from that autofill to an
interface to store and retrieve
the credentials.
And then, as you can see here,
I'm basically hitting the page,
checking to see if I've
got some credentials.
And if I do, then
I'm passing them
to my normal sign-in
process to log my user in.
With the announcement of our
one-tap sign-up and sign-in
libraries, you can build on
top of that to streamline
the process even further.
So now, my identity is just
something that seamlessly
travels with me, and
I'm going to expect
a personalized
experience everywhere.
Chris [? and Tau ?]
mentioned Starbucks earlier.
So you can see how they've
started with Credential Manager
API to automatically
retrieve my save credentials
and sign me in as soon as I
hit the site, no interaction
required.
So to be honest, I can't
really do any thinking
before I've had a coffee, so
I'm enthusiastic about anything
that makes this process
as seamless as possible.
SAM DUTTON: Yeah.
Thanks, Rowan.
Anyway, so we've taken
you from viewing products
through browsing search right
up to check out, but, of course,
that's just a tiny slice
of the entire problem.
I just wanted to
check, actually.
We were wondering,
is there anyone
in the audience who's
actually ever worked
on an e-commerce site
or an online store?
Oh, my god.
OK.
That's quite a lot of people.
ROWAN MEREWOOD: Yeah.
That's good.
SAM DUTTON: OK.
Well, look, we have a
lot of Googlers on hand
who've worked on
payments and credentials
and are really expert
in online retail.
So please come and chat to
us in the forum or wherever.
We'd really like to
hear your experiences,
what you want from the
platform, and what's missing,
what we can do to help.
ROWAN MEREWOOD: Yeah.
And I mean, this is
really just the beginning
of the conversation.
It's not just us.
We've been talking to
retailers to try and learn
about their challenges.
We've been talking to
e-commerce platforms
like Magento who are busy
transforming their product
into a PWA platform.
They're around today
and would be more than
happy to chat with you as well.
Now, speaking of
slices, we wanted
to find a way to keep serving
up even more of these examples.
AUDIENCE: Boo.
ROWAN MEREWOOD: So
we're building--
that was an actual boo.
[LAUGHTER]
I feel like that's
an achievement.
SAM DUTTON: Here come
the beer bottles.
ROWAN MEREWOOD: We're rebuilding
the progressively improved
e-commerce, or PIE Shop, as
a platform for sharing this
with you.
So you can follow along with
our progress there on GitHub.
SAM DUTTON: Right.
Yeah.
We've also put
together a document
to accompany this
talk, which has links
to a lot more information,
including the demos you
couldn't see earlier.
And also the PIE Shop project
and all the resources we've
referred to today.
ROWAN MEREWOOD: Yes.
So thank you for listening.
You can find us
later on Twitter.
We'd love to chat more.
Goodbye.
[MUSIC PLAYS]
