September 23, 2019
Progressively Improving E-Commerce (Chrome Dev Summit 2017)

Progressively Improving E-Commerce (Chrome Dev Summit 2017)


[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]

2 thoughts on “Progressively Improving E-Commerce (Chrome Dev Summit 2017)

Leave a Reply

Your email address will not be published. Required fields are marked *