[MUSIC PLAYING] JENNY GOVE: Good
afternoon, everyone. I'm Jenny Gove, and I'm a UX
Researcher here at Google. And I work on user experience
of web experiences. PETE LAPAGE: And I'm Pete, a
Developer Advocate on the Web Team. JENNY GOVE: There are lots
of reasons to love the web. For me, it's the scale. It can reach users all around
the world on almost any device, and the only thing
they need is a browser. It's easy to use
and easy to share. There's nothing to install. It's an open ecosystem that
anyone can use or build on. For the past few years,
we've been talking a lot about Progressive Web Apps. PWAs are enabled by a
new set of capabilities that allow us to radically
improve the user experience we provide to our users. We think a great experience
is based on four things. First, the experience must
load fast and feel fast. This is more than just
about how fast something goes across the network but
also how long it takes us to get useful content onto the screen. The experience also
needs to feel integrated. In other words, it needs to feel
natural to the user's device. It needs to launch
in the same way that other apps are
launched on that device and take advantage of the
capabilities of the device, in the same way
that the apps do. For example, using
the Payment Request API to make payments a snap. And the experience
must be reliable. It should always work
because when it doesn't work or when it loads too slowly,
it breaks that user experience, and it really
destroys user trust. Even here in the Bay
Area, believe it or not, there are areas with
poor cell coverage. And there are people
here in the US that have to use
dial-up to get online. And worldwide, more than 60% of
cell phones are on 2G networks. So creating a reliable
experience is crucial. And a PWA is an
engaging experience, and that engaging experience
starts at the very beginning, with a delightful first run
experience for the user. It continues throughout all
of your critical journeys so that they work
perfectly without friction. An engaging user experience
uses the magic of the web. It's indexable, searchable,
linkable, and sharable. The experience is
timely and relevant. And it's precise because it
counts for users' context and what matters to them now. In all these aspects,
but especially on making your
experience engaging, you should work closely
with UX professionals. Use researchers and
designers to identify those critical journeys
for your experience. This includes basics
experiences that are really imperative to get right-- things like asking
for permissions only when you need it, not when
the user first opens the app. And there's no real need to
ask for it at that point. And asking people to
sign up and to sign in at the right time, when
they're appropriately invested in the task that they're
doing, and there's something in it for them
to gain from doing so, not only something for
your business to gain. Other very important
flows to get right are payment experiences
that we alluded to earlier. These have to be quick
and easy and frictionless. Make it easy for the
customers to give you money and for them to
be delighted, not frustrated by a bad experience. I'm going to be covering
this more on Thursday at 10:30 on stage
7 in another tool called Google Pay,
Best Practices for Great Payment Experiences. And of course, removing
friction in forms-- we've talked a lot about
performance of forms before and the user experience of them. But there is still really plenty
of poor experiences on the web, we found out. We did a recent audit, and
that was conducted in Europe on 400 top sites. And we found that
42% of the sites, from across 15 countries, didn't
show the appropriate keyboard for the import type
that was needed. This causes, of course,
significant friction, and that was quite a surprise
to us it was so many. It's a best practice that's
been out there for a long time. PETE LAPAGE: At this
point, shouldn't it be called a standard practice? JENNY GOVE: Yeah, all of
these should, I think. They're very basic experiences. But we're finding that a
lot of the time, people aren't getting them right. We also found that 27%
of sites didn't clearly identify which
fields were optional, and that causes a number
of issues for users. For example, first
of all, the user might be overwhelmed,
just by the number of fields that they
have to fill in, when that's actually not true. And second, they
might get hung up on trying to complete an
experience that actually not applicable to them,
ultimately causing them to give up entirely. So it's critical to make sure
you're following all these best practices of web design-- using the right input type,
using features appropriately. We have a set of
principles here, and we developed through
conducting extensive research that can help guide you towards
creating a more engaging user experience. So you can find
those at that link. PETE LAPAGE: We often refer
to this whole idea as FIRE-- Fast, Integrated,
Reliable, and engaging. And the key to building those
fast and reliable experiences is service workers. Service workers
are now supported in every modern browser,
including Safari and Edge. Apple shipped support for
service workers back in March. And with the recent
update to Edge, just last week, they're
now supporting there too. Browser vendors are also
adding all kinds of new support for new capabilities that really
enhance the user experience. Edge got push
notifications, and they're doing some interesting stuff
with the add to home screen through their store. Firefox now has support
for push notifications and is working on the
web authentication APIs. And Safari is also working on
those new web authentication APIs. JENNY GOVE: So let's take a
look at the very successful PWA that was launched by
the team at Starbucks. It takes advantage of many
of the new capabilities and brings a modern web
experience to their customers. It makes it easy
to browse the menu, customize and place an order,
or pay for an order in store. All right, so I'm
going to go over here. And I'm going to
go to Starbucks. All right, and then
I'm going to sign in, and it should sign
in automatically. I'm using Pete's account here. Pete's going to buy me a coffee. PETE LAPAGE: I try and be
a nice guy once in awhile. JENNY GOVE: OK, and
here we're signed in, and then I'm going to add
it to the home screen here. So I can add that and
let me shut the app. And here it's been
added to home screen. So this is my
Progressive Web App now And it'll launch it from here. OK, so now I'm going
to order my coffee. So it's asking me if I want to
use it for location because it knows I'm going to be browsing
and looking for order. So let's see, I think I'll have
a coffee, perhaps a cafe misto. Let's see if it's on
there There we go. Actually, maybe I'll
go for an Americano. All right, so it wants
me to have a grande. I think I'll make
that a bit smaller. Let's pick a tall. I'm going to go for
a splash of milk. And I think a
little bit of sugar. So let's add that to my order,
and I can change the location here, if I want to. This is my nearest though. I'm going to confirm the
store, add that to my order. Oh, I've got two now. I've got one for you. OK, and let's take a look. So they are actually. And I can check out from there. So I won't leave
them sitting there. We probably won't
go and pick them up. All right, so now let's say
that I was somewhere where I didn't have a good connection. So I'm going to put
this into airplane mode. And this happened to
me recently, actually. I visited London, which
is where I'm from, the UK. And I was going to see a friend. And I knew that Starbucks was on
the way, but I was on the Tube. And I had some time on my hands. I could actually browse
the menu here and see what I wanted to order on the way. So that was a pretty
cool experience. And so it's able to do that. So I can make good use of my
time when I want to do that. So these experiences
extend even to payment. So should I be somewhere where
I don't have a connection-- say, I'm visiting a
different country where I don't have a connection. And I go into the store. When I want to
pay, then Starbucks has also cached
my payment details so that I'm able to pay
in the store right there. So that's Starbucks
Progressive Web App experience. And let's go back to slides. So this improved user
experience has really paid off for Starbucks. One of the ways that
they measure success is by the number of daily
and monthly active users. And that's more than doubled
from their previous experience. So it's really paying off. Users are placing more and more
orders through the web app, with the number of orders
growing by 12% week over week. And because Starbucks
took a responsive approach and made sure that this worked
nicely on desktop as well, they're seeing desktop users
using the web app in order to order ahead so that the drink
is ready when they get there. So let's go back to that
fast, integrated, reliable, and engaging principles
to see why the Starbucks app has been so successful. So your site has to be fast. You've seen this number from
us before, probably many times. But if your site takes more
than three seconds to load, you've lost more than
half of your users. Your site not only
has to load fast, it needs to feel
like it loads fast. And the way Starbucks does this
is to use placeholder content, like you can see here, until
the actual content is loaded. So at first glance, it
looks like things have started to load to the user. Those great placeholders
are really quickly replaced by real content. And on fast networks or when
their content has already being cached, you
won't even see or be aware of those placeholders. Another aspect of
that first experience is the navigation between pages. Navigations feel fast,
and they are fast. It never feels like the
page does a full reload, like they can often on the web. Navigations shouldn't
rely only on the network, but instead, everything should
be precached and ready to go. PETE LAPAGE: So to reduce
the friction of sign in , Starbucks uses the
Credential Management API, which makes sign in as
simple as a one-tap thing. It's a pretty exciting
new API, and AJ's going to be talking
a lot more about it in his talk on Thursday, called
Sign Up and Sign In on the Web. So definitely
check that one out. And as you can see, we've
got the add to home screen. We didn't reset
the phone properly. I'm sorry. That was my fault. JENNY GOVE: No problem. PETE LAPAGE: I was
responsible for that. But you get the add to
screen prompt there. So letting the user know
that they can add this to their home screen. When the user adds your
Progressive Web App to their home screen on
Android, Chrome automatically creates an APK for you, which
we sometimes refer to as a web APK. That web APK means that your app
shows up, not only on the home screen but there in the
launcher and in your settings so that you can go in and see
where the permissions are. You can see how much storage
is being used and so forth. Today, Chrome automatically will
show that add to home screen prompt when the site is
not already installed. The user's interacted with
the site for about 30 seconds, and it meets the
PWA criteria, which means that it's got
a web app manifest, a service worker
with a fetch event. Of course, the easiest way to
test that is to use Lighthouse. In fact, we literally
have a lighthouse set up in the web tent, if
you haven't gone over there and seen it, where you can go
and run your site through it and talk with folks
on the web team to understand what's going on. There's also a talk
tomorrow on Lighthouse and the Chrome UX
report that will go into a lot more detail on
how you can use these tools. Today, before Chrome shows
the add to home screen prompt, it's going to fire up
beforeInstallPrompt event. And this gives you control
over when that prompt appears. For example, in the
Starbucks experience, they don't want that
prompt to show up if I'm in the middle
of ordering a drink. You want the user to finish
what they're doing and then say, oh, hey, add this
to your home screen. You don't want to
distract the user. So in the default event
handler, what you'd do is save a reference to the event
and call preventDefault on it. preventDefault says
hey, don't show up. And you can save that
event so that in a moment, when you're ready to show
it, when you're like, OK, hi, this is a useful
time for this to be visible. You can call prompt
on that saved event. You can also tell when a user
has added your app to the home screen by listening for
the appinstalled event. And so the appinstalled
event will tell you that, hey, yes, they clicked,
I want to install this. And Chrome or whatever
browser was successfully able to add it to the
user's home screen. Now that's today. Chrome is going to automatically
show you the prompt, but it's changing. Starting in Chrome 68,
Chrome is no longer going to show that
prompt automatically. Instead, you're going
to need to listen for that
beforeInstallPrompt event, then trigger the prompt
by calling prompt on it-- on that saved event
with a user gesture. Now to make the
experience reliable, Starbucks used Workbox, with
a combination of precaching and runtime caching strategies. By precaching
their content, they were able to ensure that the key
resources that the app needed to run were always there. They wouldn't have to
wait for the network. Then, as the user
uses the app, they are able to cache
additional content, as they navigate around. Placing an order offline
would be kind of amazing, but it's impossible. So instead, what they
allow users to do is, as we showed earlier, is
you can pay for your order. They use IndexedDB
to store information about the user's
previous orders, about the nearby stores
that they've gone to, and their payment
details so that can always come up and
always be available. JENNY GOVE: Starbucks focused
on the user experience to make their Progressive
Web App engaging. Placing an order has to
be easy so that users can customize their drink
with the many possible options available. Starbucks paid attention
to the fundamental details, like the navigation
stack, making sure that the Back button always
does the right thing. For example, navigating
down several pages. The Back button navigates
step by step back up, rather than jumping
back to the home screen or some other random page. To make these experience
feel more alive, the Starbucks PWA uses
content specific animations and messaging to provide
feedback to the user. For example, after
clicking add to order, it shows a toast,
letting me know that its been added to my bag. As you can see, through creating
a fast, integrated, reliable, and engaging
Progressive Web App, Starbucks have put
their customers first in developing an experience that
meets the user's where they are in the context that they live. They work. They play. To make it simply a
convenient and delightful experience in order to
order a favorite drink. PETE LAPAGE: All
right, so have we burned that FIRE acronym
in your head yet? OK. JENNY GOVE: Back. PETE LAPAGE: I like bad jokes. I got a couple more
set up for you. So be ready. In any event, a bunch
of teams at Google have been working on building
their own Progressive Web Apps. Google Search uses a
Progressive Web App to make it possible for users
to ask questions, when they are offline and then provide
an answer once they've reconnected. It uses service workers,
background sync, and push notifications. By using service
workers, they were able to reduce the number of
external JavaScript requests by nearly 50%, and they
were able to reduce the number of user
interactions that were delayed by loading JavaScript by 6%. So they saw a pretty good
performance improvement. There's also a Bulletin,
which is a new way to create and share
hyper-local stories, and it's all built around
a Progressive Web App. It's a tiny fraction of
the size of a native app, and it's got 100% of
the functionality. They do some really neat stuff
with the Media Capture API so that you can take a
picture or take a video and then post it up to Bulletin. And sharing is as
simple as sharing a URL. And the Maps Team recently
shipped a Progressive Web App. They saw Progressive
Web Apps as a way to radically improve the
experience for their users on low-end devices or on limited
or flaky network conditions. Previously, many
of these users were getting a so-called
light experience that was designed with
mobile in mind, but it didn't take advantage of
a lot of the new capabilities that Progressive Web
Apps has to offer. The Progressive Web
App doesn't have feature parity with
their native app but instead centers around
four key user journeys. Again, see that bad pun? Yeah, I told you
there were a few. Anyways, that they felt
were really important. First, they wanted to
make it easy for users to see their location and nearby
landmarks so that they could get a sense of where they are. Second, they wanted to
make it easy to find places with either Search or on a map. Third, they wanted to make it
easy to see what was nearby and help them
discover new places. And finally, they wanted to
make it easy to get directions so that they could figure out
how to get to those places that they've discovered. And users are
using it even more. The new experience is seeing
20% more successful page loads, compared to the
previous experience. Specifically targeting
low-end devices that team really had to put that
extra effort into making sure that everything was fast. Performance was prioritized
from the beginning. By establishing code size, load
time, and memory benchmarks that could be measured
with every single commit. They use Chrome Dev Tools to
tune memory and performance and tested on slow
networks, always looking for any regressions. And of course, they
needed to make sure that it worked reliably,
even on those flaky networks. So they set a goal to
be mindful of how much data that they were using and
try and keep that in check. So that for users
on expensive data plans, they wouldn't consume
too much of their data. So let's take a look at the
Maps Progressive Web App. So I'll open it up
here, and I've already installed it on here. You can see that-- oh, I guess we should
come out of airplane mode. That would be kind of helpful. And one of the neat
things you can see-- they have that no internet. They give you a
little indication of whether you're online or not. So you can see, this looks like
the standard Maps experience. It maybe not quite
as shiny, but I'm going to go check out and try
and find a place that I've been once or twice before-- sports page. It pops up really
quickly-- almost instantly with the information. It's got that
standard page view. So I can see information
about the things that I'm looking for. And if I clear this out and
then go into offline mode, even though I'm offline,
it remembers the places-- there we go. It remembers the places
that I've been to before. So that if I click on Sports
Page, that's all still there. And it's cached in an IndexDB
table so that it's always there and ready to go. So if we can switch
back to the slides-- great. So with the previous
Maps experience, they really focused to put
as much data as possible into that initial
HTTP request so that they could reduce
the number of requests that had to be made
for the app to start. That meant inlining things
like CSS and JavaScript and HTML templates-- stuff that
they might need for one thing but not for something else. They wanted to have
everything there so that they could get started right away. With their Progressive
Web App, they've refactored the code into really
super fine-grained modules that are only served by the
service worker, when they're needed. So unlike the
traditional experience, it only loads and runs
the code that's needed. If the user doesn't
need directions, it doesn't have to load
or execute that code, meaning everything runs
just that much snappier. Many of the users are
on flaky or 2G networks, or they've got
expensive data plans, and they turn their data on
and off fairly frequently. And the Maps Team
wanted to make sure that that experience for them
worked reliably, no matter what their network
connection was like. To achieve that, they use
service workers to cache the core app shell of
their app and so they can eliminate the network
for that initial stuff. But then they started to
think about how they were going to store the map tiles. Map tiles are about somewhere
between 10 and 20k, each and you imagine as
you pan and zoom, you can start to
load a lot of them. And in fact, you can
load like dozens of them by panning and zooming
pretty quickly. And those map tiles
change frequently. Imagine as new businesses open
and close, as things change, those map tiles are
constantly in flux. So storing those tiles
using the cache's API was going to be a little
bit complex for what they wanted to accomplish in V1. And so what they decided to
do is use the browser cache, but they did it in
a really neat way. As each tile
successfully loaded, they store the details of that
tile in an Index DB table. So later, when the browser
goes to get it again, the service worker
regenerates the URL based on the version
information and is able to go back to
the browser cache. And in most cases, is able
to pull that tile back from the browser cache again. For things like
searches, directions, and that kind of stuff, all
of that is saved in IndexDB. So that's always there
on the user's device, even if they're offline. To help eliminate some
of the chain jankiness that is possible and reduce
the amount of graphics memory that's used, they use the
Layers panel in Chrome Dev Tools to identify elements
that were off-screen and remove them from the DOM. That also shows
them really useful, if you go into 3D mode, the
stacking context of your page. If you're trying to
figure out what's going on with some of the layers
and what's going on there, it's a really useful tool. It's one of my
favorite ones that I've just recently
started playing with, but it's been
around for a while. They also decided to limit the
amount of transparency and box shadows that they have. So for example, the search
box that you see up there is a full-width element. In the normal experience,
it's a floating element that's got the map
tiles drawn behind it. So in this case, they don't have
to draw the map tiles behind it or anything like that. They're able to save
a bunch of memory. One of the biggest
challenges that they faced in building a
Progressive Web App was that the storage APIs
are scoped to the origin. And I didn't realize
this, but Maps is actually served on google.com. It's not served
on maps.google.com So that means it shares the same
storage as, obviously, Maps, but also Search and Chrome's
default new tab page. Any service that Google
serves is going to share that. So they have to be
really careful not to step on other folks' toes. As a developer, one
of my favorite tools is the clear sight data button,
and it removes the service workers, gets you back
all of the saved data, and lets you start from zero. And of course, that
includes the cookies. As I was digging into
this to try and figure out what was going on, I kept
getting signed out of mail, and I couldn't figure out why. And then I went oh yeah. Clearing my cookies signs
me out of all my mail-- was a bit of a pain in the butt. JENNY GOVE: Thanks. OK, so we attribute a lot of the
progression of Progressive Web Apps to mobile, and
mobile has really been the key focus of their
development for Progressive Web Apps today. But while the growth of
mobile has been strong, we mustn't forget
that desktop usage is, in fact, still growing, as
you can see in this chart here. This graph shows that
mobile phone use peaks in the morning and the evening. And tablet also has significant
use in the evening time. Desktop usage is more
evenly distributed throughout the day,
when most people are at work and at their desks. It's mainly led by productivity
apps, many of the key apps we use every day. For example, Google
Docs, messaging apps, like Slack and chat,
and music streaming apps like Google Music or Spotify. Having that
installed native feel can be really important to
users because it gives them the confidence that the app will
be fast, integrated, reliable, and engaging. To achieve this, some developers
have built desktop apps using web technologies
and then used a framework that embed their
application in a custom built web browser. In fact, that's what
Spotify does today. But it feels kind
of redundant to ship an entire browser and your
code, especially given that the user already has
a browser on that machine. Not only have you
significantly increased the size of your
download, but you now have to keep that
rendering stack up to date. You have to patch security
vulnerabilities and more. So you're responsible
for your app and maintaining that
rendering stack, in this case. There is a better way
to create desktop apps and with a smaller footprint and
that emphasizes user experience as well. And that's to deliver
a PWA for desktop. Users have high expectations
for desktop apps, and Progressive Web Apps on the
desktop also need to be fast, integrated, reliable, engaging. You can say that with
me now, I'm sure. That means they launched
from the same place as those desktop apps alone--
so that's familiar to users. But they run also
in an app window. So they look and feel like
other apps on the desktop. And that's why we're working
to bring Progressive Web Apps to desktop. The demo we're going to show
you today is on Chrome OS, but work is already
well and a way to support Windows
and Mac as well. And Windows users can already
install Progressive Web Apps through the Microsoft App Store. So let's take a
look more closely at the PWA experience
on Chrome OS, exploring Spotify's desktop PWA. I'm going to move to
this Pixelbook now. So let's go to Spotify. So now I'm going to
open my web player. And you'll see here
that it asks me if I want to install the app. So I'm going to say yes. And this dialog comes up. I can click install here. And if you look
quickly and closely, you'll see it land on
my shelf down here. So that was pretty quick. There it is. And I'm just going to
close it out and show you how easy it is to launch it,
as if it was my beautiful app experience here. So, Pete, I heard about
the band tomorrow night. Did you hear of Justice? PETE LAPAGE: I heard. I'm kind of excited. JENNY GOVE: Should we
have a little lesson? PETE LAPAGE: Sure. JENNY GOVE: Go with it. PETE LAPAGE: All right, JENNY GOVE: Come on [MUSIC PLAYING] PETE LAPAGE: I
like this but maybe you should just keep going. I know. JENNY GOVE: Ooh,
oh, wow, go off. Come on. PETE LAPAGE: I'd
close the window. JENNY GOVE: Shut for me. PETE LAPAGE: There we go. JENNY GOVE: But the rest
of the demo was good. And I can launch it again. Let's see if it will play. You can see the install
app is gone here because now I'm in that
Progressive Web App, and it's using the
whole of the screen. It's in the app window, and
it's just a great experience that I can launch directly
there from my shelf. All right, let's move
back over to slides. PETE LAPAGE: Cool
getting started isn't different than what
you're already doing. This is not like it's a whole
new class of apps or anything like that. All of the work that you've already done for
your existing Progressive Web Apps still applies. Service workers make
it fast and reliable. You can use push notifications
to keep users up to date, and the add to home screen
uses the same set of criteria, as it does on mobile. The only real difference
is that instead of running in a browser tab,
it's running in an app window. With app windows, there
are no tabs or address bar. It's just your app, and
it's optimized really for the needs of apps, with more
flexible window organization. App windows also
make it really easy to switch between
windows by Alt-Tabbing. I want to point out a couple
of things in the app window that I think are
kind of interesting. As I mentioned, it takes
up the full screen. You've got the standard
minimize/maximize, as you'd expect. And on Chrome OS, the
title bar is themed based on the manifest colors. Speaking of the
web app manifest, I do want to recommend that
you future-proof your apps by adding the scope property. The scope property
defines the set of URLs that the browser is going
to consider within your app. If you leave that
set of your URLs, it'll bounce you out
to a browser tab. This is really important
because in the future, this is going to be used
for determining behavior, like link capturing. Within the menu, there's
also that app menu there that gives you the
URL and a bunch of other sort of useful things
that you want to get into. JENNY GOVE: Now there are some
unique design considerations you need to take into
account for building desktop Progressive Web Apps-- things that don't necessarily
always apply to Progressive Web Apps on mobile devices. Apps on the desktop
have to have access to significantly larger
screen real estate. Don't just pad your content
with extra margin, therefore. But use the additional space
by creating new breakpoints for wider screens. Some applications really
benefit from that wider view. When thinking about
your breakpoints, think about how users
will use your app and how they might resize it. In a weather app, a large
window might show me a seven-day forecast. Then as the window gets smaller,
instead of shrinking everything down, I might get a
five-day forecast. And as it continues
to get smaller, content might shuffle around. I can still see
that same content. It's just optimized
for a smaller display. For some apps, a mini app
might be really helpful. This weather map shows me
only the current condition, and a music player might show
me just the current songs. And the button needed
to change the song. You can take this idea
of responsive design to the next level to
support convertibles, like the Pixelbook
on the Surface. When switched to tablet
mode, these devices make the active
window full screen. And depending on how the
user holds the device-- maybe the landscape
or portrait-- so you need to focus on
getting responsive design made, and that's what matters here. Whether the user has resize
the window or the device has done so because it
switched to tablet mode. Responsive design is critical
to a successful desktop Progressive Web App experience. The app window and desktop
opens so many new possibilities. So work with your designer
and take a responsive approach that adds breakpoints
larger screens, supports landscape or portrait
views, works when fullscreen, or not and works quite nicely
with those virtual keyboards. And what's next? Well, as mentioned,
we're already working on support
for Windows and Mac. And for all the
platforms, we're looking on adding support for
keyboard shortcuts so that you can provide
your own functionality. Badging for the launch icon-- so that you can let users
know about important events that you don't want to display
a full notification for. And link capturing--
opening the installed PWA when a user clicks
on a link that needs to be handled by the app. so keep an eye out for
announcements on the Chromium blog that you see
here for updates and start playing with it today. PETE LAPAGE: All right, so we
have about a minute and a half left to cover the last section. So I'm going to go really fast. I won't actually go that fast. I'll cover the key stuff. We'll get this out
in another video. But for many users, having
an app available in the store is really critical
to your business. And we know that there are a
lot of cases where this makes sense, and that it makes
sense to integrate your web content into your native app. Today, you can do this using
either a web view or Custom Tabs. And each has its own
benefits and drawbacks. I won't go through these
right now and sort of skip through this so that we
can get into a little of the fun details. We've heard from you that
one of the things you want is to be able to show web
content in your native app but have a lot more
control over it. And Trusted Web
Activities allows you to integrate that experience. They're powered by
Custom Tabs, which means that your content
is rendered by the user's up-to-date browser. This isn't a mechanism simply
to just wrap your website and throw it up
onto the Play Store. A simple mistake can cause
some kind of drastic problems. Trusted Web Activities
are designed to make it possible for you
to use the investment you've made in your web app inside
of your Android native app. There are a couple
of requirements. They must be done as
first-party content. So the content has to be yours. You need to add an intent
filter in your manifest, and you need to pass the same
Progressive Web App criteria, as we've talked about earlier. And of course, you need to
follow the standard Play Store guidelines. So there's four things
that you need to do-- well, essentially, two, but
we'll call them sort of four. Set up a set of
digital asset links and that allows you to prove
that your content belongs to you on the web and
then create the activity. The code is here. We will get this up. In fact, I'll just
take you to the link where all of the
details already are. Can I go back one slide, please? Sorry. All right, if you go to
g.co/TrustedWebActivities, all of the notes for this,
including all of the code to get started on this,
is right up there. JENNY GOVE: OK, so let's
conclude this talk so you can get to the party tonight. So I'm bringing
this all together. You've seen today how
Starbucks' Progressive Web App works, how the
team at Starbucks have taken care of
those fundamentals, as well as the delighters
to bring a more convenient and experience and great user
views to their consumers. We've seen how Google is
building Progressive Web Apps. As well, with Search,
Maps, and Bulletin. And how Progressive Web Apps
can improve desktop experiences, through careful design
and use of app window. And finally, you've head
about how you can integrate your PWA into your native app. All these experiences focus
on being fast, integrated, reliable, engaging. And in this, they're
transforming the web on mobile and on desktop. PETE LAPAGE: So if you
remember three things. One, go check your
Progressive Web App and listen for that
beforeinstallprompt event, call show on it. Go try desktop Progressive
Web Apps and out of scope. And if you've got an
existing Android app, go take a look at
Trusted Web Activities. Thanks, everybody. Please fill out
the feedback form. Thank you. JENNY GOVE: Enjoy the party. [MUSIC PLAYING]
Why is Chrome the only browser that can run a web app in a plain window without an address bar?