Creating UX that “Just Feels Right” with Progressive Web Apps (Google I/O ’17)

Articles

Creating UX that “Just Feels Right” with Progressive Web Apps (Google I/O ’17)


[MUSIC PLAYING] OWEN CAMPBELL-MOORE: Hi, my
name is Owen Campbell-Moore. I’m a product manager
on the Chrome team, and I work to make sure
that the web is the best platform that it can possibly be
for both developers and users. And today I’m
going to be talking about creating user experiences
that just feel right when your users are using
them on their mobile devices, and doing that with
Progressive Web Apps. And so before I jump
in to talk about UX, I want to take a moment
to talk about why I think the web is such an
exciting and fascinating platform to build
for as developers. So you will have all heard
yesterday in Sundar’s keynote how Chrome now has
over two billion monthly active users, which
is just a huge number. And that’s just Chrome alone. When we look at the whole
spectrum of the web, we see that there are
over five billion devices running web browsers. And so this means that if
you’re building for the web, there’s this incredible
large potential addressable audience that you have, this
amazing potential reach. I think that’s a really
fascinating and unique property that the web has. And there’s been a huge
rate of development in the last few years. Performance has
gotten so much better. In the last year alone,
according to the Speedometer benchmark, JavaScript
performance on Chrome for Android
is now 35% faster. And so I think that these
improvements in performance mean that it’s possible
to do a lot more than it was possible to do previously. And another thing that
I love about the web is how it’s fundamentally open. There’s no one company
that’s in control and decides what happens on the web. It’s really thousands
of developers across lots of different
companies and web browsers and open standards organizations
that are all working together to push the web forwards. And it’s really been designed
over the last 20 years to have this amazing
property where users should be able to click one
link and immediately have that content streamed
to them so they can access it instantly. No need to kind of bundle up
10, 20 megabytes of resources, upload them to a
store, and then have users go through some
kind of install process to download and get
that onto their device. And that’s a really fascinating
property for the platform, in part because it means that
your users can potentially just tap a link and
be in your experience immediately– which means you
can reach a lot more users. And from a purely
business perspective, it means that customer
acquisition costs are much lower. So in the last few years, we’ve
seen this huge shift to mobile. And in particular, this
has been interesting because Native has really
been great on mobile. It’s taken advantage of
the unique capabilities of those devices. And on the web, you
had this great reach. Users could tap a link
and try your experience, but there was no way
for that user that to get the features that they’ve
come to expect on mobile, to be able to get push notifications
and a home screen icon, and all of these aspects
that allow users to come back over and over again. And so that’s been a
really big focus for us in the last few years. And in addition,
the shift to mobile has been a really big
shift in interaction. Previously on desktop,
users had a keyboard and they had a mouse, and
everything was indirect. You were moving a mouse, which
moved a cursor on the screen. But now we’re on mobile,
users are dragging things and they’re swiping things. They’re tapping
things on the screen. And this means that the
quality of experience just has to be that much
higher because when a user is physically manipulating
something on the screen, it really has to respond
and do what they expect to create a good experience. So this is what I’m going
to be talking about today. Specifically, how do
we design for the web, especially for mobile devices? So this will build upon
general UX principles and general principles of good
mobile design and good design. But it will focus
specifically on the challenges and unique opportunities
presented by the web. So this talk was
named “How to build user experiences that just
feel right on mobile devices.” And so to dig into
that, I think we’ve all had lots of experiences on
the web where we open a page and we’re scrolling, and it’s
just not really responding. And we tap it. It feels kind of kludgy
and slow and old-fashioned. And so this is a kind of
common emotion and feeling on lots of websites. And so I want to kind of think
about those are the symptoms and can we really dig in and
understand those symptoms and understand the
causes for those such that we can look at how
to go and address them? And so the first common
symptom that we see is that sites often
aren’t reactive. So here you can see
I’m tapping a link on developers.google.com. And I’m kind of waiting,
and I’m waiting. And I’m on a mobile
device, so who knows what my network is like. And really, this wait
is almost indeterminant. This is kind of in contrast
to when things were developed on desktop, and probably
this was developed on a desktop device, where they
were running a local server and they tapped the button,
and in half a second the next page was there
and it just felt fine. But on mobile devices
and real world networks, that’s just not the case. And so often sites just don’t
feel like they’re reactive. Next, sites often
aren’t predictable. So here you can see we’re
looking at the Google I/O website. I’ve opened the hamburger
menu, and then I’m trying to swipe it away. But it’s not
responding to my input. It’s not swiping away. To me, this is a little bit
like working in an office that has old pull doors everywhere. And then one day, someone goes
and installs a sliding door. But they think, oh, I’ll put
a pull sign on it and a handle because that’s what all
the other doors have. So that’ll be good. And obviously, that’s
going to create a very confusing and
frustrating experience, and that’s something that
we often see on the web. And thirdly, users often
just aren’t in control when they’re on the web. So here you can see me
loading an article, scrolling, and then it’s kind of
jumping underneath me. I’m sure we’ve all had
this experience when we’re trying to read or
we’re trying to tap a link. And then everything just
shifts underneath us as the content appears and
loads in elsewhere on the page. This is also a very
common experience that we’ve seen and
is a big problem. Another good example of where
the user isn’t in control is if they’re on a
list of, say, products on an e-commerce sites. They tap an item
and then realize they tapped the wrong one. Now they’re waiting three,
five, 10– actually, the average page load time
on mobile is 19 seconds. So that waiting a really
long time for that page. They know it’s the wrong
one, so they hit back. And now they’re staring
at the screen wondering, is the page I was
tapping on loading? Is the back page loading? Do I need to hit back again? What’s going on? And this can turn a minor
mistake into an experience where they accidentally leave
the whole site because they hit back too many times. And so really users
often aren’t in control. And these are some of the
big issues that we see. And so today I want to share
a secret with all of you. Are you already? So the secret is that
websites can feel amazing. So this is actually a pretty
well-kept secret, I think. And so there’s
this huge amount– the history of the
web means there’s this huge amount
of legacy content that was really not designed
with mobile in mind, not designed for the
networks and the interaction. And this means that the vast
majority of existing content just isn’t designed
for the modern world. And I think that this means
that a lot of the time we experience the
web in this way and therefore think, oh
well, this is how the web is. This is how it feels. This is how it must be. And so, if you take away
one thing from this talk, it’s that websites can really
feel amazing and can do more. And here’s a great
example of a web app that I think does a lot more. So here we have Twitter.com. They recently launched this
as a Progressive Web App a couple of months
ago, so you can try it on your mobile device. And you can see, as I’m tapping
the tabs, it’s very responsive. I can tap compose, tap
through all of the tweets. And this is actually simulated
on a very slow I think 2G or 3G network. And it all just
feels really good. You can actually
see that it’s also running in this kind
of immersive mode where there’s no omnibox. There’s no distracting
browser UI. And that’s another feature
of the Progressive Web App. Since I’ve added to home screen
this lightweight install, I have the icon. And once I launch it
from the home screen, it runs in this kind of rich,
immersive mode, which creates a really nice experience. And so this is a nice
example of what’s possible. And so I said that this
is a Progressive Web App. And so what are
Progressive Web Apps? Well, at their core, they’re
really just radically better web experiences. And they are
fundamentally enabled by a new set of browser
standardized capabilities and APIs that have been shipped
over the past few years. For example, Service Worker
is this amazing new API that allows web sites to
really fundamentally take control of the
networking on the page in order to make it
performant and fast and reactive regardless
of the network condition, even if the user
is fully offline. Essentially, it lets
you kind of keep a stored copy of your web
app on the user’s device so as they’re using it,
you’re not downloading every page each time, or
downloading the whole app every time they browse to it. And another thing
that I think is really important about
Progressive Web Apps– actually besides
the capabilities and the technical aspects– is the idea of it as
a label and a thing that we can aspire towards. We have this big problem on the
web of this legacy content that doesn’t work very well, and
I think that by having this label– where we can say these
are Progressive Web Apps, these are great experiences– we can reset expectations for
ourselves and our companies and for our users that
things can be great. And so that’s one of the reasons
why I think PWA is so exciting. And so over the last 18
months, we on the Chrome team have had the great
opportunity to work with a bunch of the
world’s best developers in rebuilding their mobile
sites as Progressive Web Apps, or just coming to the web for
the first time– from Twitter launching Twitter Lite to Lift
launching their Progressive Web App for the first time. And in that process,
we’ve had a chance to really understand
the common problems and look at the demos
and the prototypes and work out what works well. And we’ve boiled down
three key principles that we called the Feel Good
Principles that we think really explain what makes a web
experience feel good to users as they using it. So the first
principle is reactive. Sites should be reactive
to use as input. Really the word responsive
would have been better in here, but responsive web design
is already a thing. And so reactive is the
word we’re using today. Secondly, sites
should be predictable, and they should offer
predictable user experiences that users can expect
and understand. And thirdly, users
should always be in control of their experience. So let’s dig into this
first one, reactive. Sites should be reactive
to users’ input. And when we’re talking
about reactivity, I think first it’s important
to think about perceived performance. Because we’re really talking
about performance here, and what counts as how
users experience it. And so there’s this
quote that I love from a classic paper
in this field, which says “human perception
of time is fluid and can be manipulated in
purposeful and productive ways.” So this is a quote that
comes from a great paper about designing loading
bars and about how to create good experiences
of loading bars that make users feel like
the experience is really fast and avoid them
feeling frustrated. And that research,
amongst lots of others, has demonstrated that user
perception of time is fluid. And so as we’re thinking about
building reactive websites, we should be thinking about
how users perceive performance. Knowing the page loads
in 5 seconds is great, but if users can think that
it loads just in one second because we can use some
tricks, that’s even better. And the data actually
backs that up and says the users do engage
more thanks to this perceived in performance. So the first example
I want to show is kind of like
what we saw before, a transition that’s
blocked on the network. Here you can see me
tapping a listing, and then I’m waiting really an
indeterminate amount of time until suddenly the
next page appears. And so this can be frustrating. And here we can
see actually what Housing.com, the Progressive
Web App here, has done. Where, when the user
taps on a listing, they’re immediately
taken to the next screen. The information that
was known before– the image and the title– is re-used on that next
screen, and the user is given an idea of the
structure of the page so they can start
understanding that, take a few seconds to process
that whilst the download is happening. And so this is a really big
improvement in user experience, and it’s a pattern that
we’ve seen very successfully being used across lots
of Progressive Web Apps. Next, a big issue that we’ve
often seen with Progressive Web App developers is trying to
do responsive touch feedback and finding that it’s
just not really responding to the user’s input. So here, if you
look really closely, you can see that I’m
tapping on this Demo button on the Material UI docs page. Material UI, by the way,
is an implementation of material design for
the React framework. So as I’m tapping Demo, this
should be a material button. There should be a nice ripple. And in fact, if you look at
the code there is a ripple. But when you go on a low-end
phone and you just tap it, there’s not. And so, why? To understand this,
let’s take a look at a simplification of the
code for how this would look. Here we have the button,
and we add an event listener for the click event. And when the user
clicks on that button, we’re going to add a
class to the button. This class will
trigger that animation. And then we call
render next screen, and this probably does
a bunch of react code preparing the next screen
and then swaps it in. Now the problem here is
that when you actually set a class on
something in JavaScript, that doesn’t actually
happen immediately. And in this case, the
render next screen code is what we call blocking
the main thread. It’s doing so much busy work
that the change to the class actually doesn’t get
time to be applied. And so this is kind of a
weird quirk that we have. But it’s fairly simple to solve. The way to solve it
is to use this trick that we call a double
requestAnimationFrame, or a double RAF. And so here what we’re
doing is, after we at that class we
say to the browser, hey, wait until the next frame. And then we say wait
until the next frame again and then start rendering
the next screen. And so what this does is
it ensures that that CSS change has been applied. It’s made it off onto
the other process. And then when we call
render next screen, it can block the main
threads, but the animation is already going. And it won’t be
blocked by that work. And so this is a
really good trick that I’d recommend you
think about whenever you are implementing tabs or
buttons or really anything that the user should expect
to get a response from. Think about using
this to make sure that things don’t get blocked. So if you’re testing
your sites always on the latest Pixel
or the latest iPhone or on your desktop, you often
don’t notice these issues. But when you try them on the
really low-end mobile devices that realistically a
lot of users are using, these issues can really
become a problem. And so here we can see the docs
page with that fix applied. I’m tapping the Demo button, and
there’s a nice material ripple as you would expect. Next, I want to talk about
kind of infinite lists. So infinite lists
are a common feature that we see on sites
especially with feeds. Sites like Twitter
or Facebook or Tumblr often let you scroll
infinitely through a list. And here you can
see a page where I put 1,000 of these rows. And I’m trying to
scroll through it, and it’s such rendering
blank for a lot of it, which is really weird. And I found in reality,
when I was writing some code to keep adding
elements to this page, it got really sluggish
and slow, and the memory got really large. If you go on a site
that uses one of these and you just keep scrolling and
watch the memory information, you can see these sometimes take
multiple gigabytes of memory, which just grinds
everything to a halt. So this is a problem that we
need to be thoughtful about. And so there’s a
solution to this, which is to use what are
called virtualized lists. Essentially, this
is a technique that means when that component
goes off the screen, it’s actually
removed from the Dom. It’s removed from the page. And so really only the things
that are within view and a few on either side are rendered. And actually here,
this is a page with 100,000 elements on it. And so this can really
scale very well, and it was a key
that actually Twitter found when they were
building Twitter Lite, that was key to making sure that
that list scrolls really well and the user can sit there and
use Twitter for a long time and have it be performant. So virtualized lists
is a great tool. Next, one of the big
questions that we get when we talk about
building reactive websites is how do I do
native UI on the web? And for Android
developers, this often means how to do
material on the web? And so I want to give
a quick shout out to a few different
implementations of material that you can go
and take a look at. At the top, we have
the Polymer Elements. So this is a set
of elements built by Google, built by
the Polymer team that implement material design. And the Polymer
team are here today, so you can go and chat with
them in the mobile web tent and hear all about it. Secondly, if you’re
interested in React, there’s this
implementation Material UI that we saw a little screen grab
from earlier, which is great. So you can check that out. And if you want to be a bit
more framework agnostic, then Google has also published
the material components for Web. And these aren’t tied
to any framework. They’re vanilla
JavaScript and CSS, and you can pull them into any
project that you’re working on. Now I can’t really talk about
building reactive web sites without touching
on load performance since the first time a
user comes to a site, their first experience is part
of it being reactive to what they’re trying to do. And so here on the left,
we can see the improvement that the major company
OLX saw in India when they launched their
Progressive Web App and used some of these patterns. So there are these
techniques that if you’re not familiar with, I recommend
that you go and just look up. The first one is
the PRPL pattern. This is about a way of ensuring
that you’re loading resources effectively and reusing
them effectively to make everything very fast. Secondly, there’s
service worker caching. So service worker is one of
those new standardized APIs that’s been added
to the web recently that allows the
controlling of the network. And so this is really good
for when the user comes back to your site. You can have the resources
already available on the device. And third, server
side rendering. So these days people are
building a lot richer experiences on the web. They’re very app like. They have a big framework
and lots of resources. And sometimes this
means that, if to get that very first render
you have to download all of those
resources, then it’s going to be a slow first render. And so there’s a technique,
server side rendering, where you can render the
first view on the server and send that down and then– we say hydrate it
on the client– once the other resources
have been loaded in it, make it interactive. And talking about this kind
of first load performance, given that we’re
talking about design, I think it’s really
important to touch on fonts. So as designers, fonts
are a really valuable tool in our toolkit for creating
these great experiences. But on the web, there’s
this common problem where fonts can be a megabyte,
two megabytes in size. And so if you want
to really rely on that font for the first
load of your application, you can end up with
something like you see here where everything is downloaded,
all of the text is there, but the font isn’t
yet downloaded. And so it’s unstyled. It’s blank. And this is a big problem. So there’s a couple
of tips that I would recommend thinking about. Firstly is to consider
using device fonts. So these days devices ship with
a large set of default fonts. And often just by
choosing between them, you can get a good
artistic expression that you’re interested in. Secondly, if a
custom font is really important to you for
a header or a logo, consider using an
image or an SVG. Often these can just be
like 10 kilobytes instead of a megabyte, and so this can
be a much better trick to use. And thirdly, another good
pattern is to use custom fonts, but use them on
subsequent loads. So once they’re
available, use them. Until they’re available,
make sure that you’re not. And if you’re pulling
fonts from Google Fonts, there’s an option
that lets you do this. So just keep your
eye out for it, and make sure that
you’re trying your site on really slow networks. You’re trying that
first load and checking how the fonts are working. Now, I’ve given a
bunch of different tips on how to build your
sites and make sure that they feel reactive. I want to share a couple
tools to make it easier to make sure that you’re
hitting all of these. The first is Lighthouse. So Lighthouse doesn’t
do all of the things that we’ve talked about
in terms of helping with skeleton screens and
responsive touch input, but it does help a
lot with many aspects, and we’re building
on it rapidly. So Lighthouse is a
new Chrome extension built by the Chrome team
that you can run on any page, and it gives you this
personalized report that explains how all the different
aspects of it are working and gives you pointers about
areas that you should look at, areas of opportunity. There are another couple tools
which are worth mentioning. Page Speed Insights
is another Google tool that helps you understand the
performance of your page loads. And Web Page Test is a
great non-Google tool that helps you say, what’s
the experience like of loading my website on Moto
4G in Bangalore? And it’ll give you
back a video of it loading and traces
and timelines and help you see how that’s working. So this is a really
powerful tool for understanding,
real world, how users would experience your site. So that was about how to
make sure that your site is reactive to the user’s input. Next I want to talk about how
to make sure it’s predictable and that your user experiences
are understandable. So here we saw the example
earlier of a hamburger menu that the user is
trying to swipe away and that just doesn’t swipe. So this is a problem. And here, instead, we can
see the Progressive Web App recently launched
by the company Wego. This is built using Polymer
and the Polymer Elements. And so here, I am able
to drag the left nav. I’m able to fling it, and it
works just like you’d expect. So here’s another example
similar to the hamburger menu. There are tabs on
this site, and I’m trying to just swipe
between those tabs as I’ve been trained to expect. But it’s not working. And so this is a
confusing experience. So instead of that,
here is the docs page for react-swipeable-views, which
is a performant way of having these swipeable tabs
or swipeable views somewhere in your application. So go and check
this out if you’re looking at doing swipeable
views for some reason. But actually there’s
another tip that I like to think about when
thinking about navigation, which is sometimes it’s
best just to keep it simple. With both the hamburger
menu and with those tabs, we have this implication of
gestural navigation, which can be challenging to do
a good job, especially if you’re interested in serving
users on low-end devices. And in fact, the hamburger
menu has a number of usability problems
around discoverability of the items in that menu. So sometimes it’s best
just to keep it simple. There’s this pattern
called a bottom navigation, which doesn’t have
the same implications of gestural swiping. It’s also much easier to tap
for the user with their thumb, and it’s more discoverable
because they can see immediately what’s available. So think about keeping it simple
with the bottom navigation instead of going really
deep on the other areas. So the next aspect
of predictability I want to talk
about is this gotcha that we called the blue
flash, which incidentally I think sounds like a
great superhero name if anyone needs
one for any reason. So the blue flash, what is it? So here we can see, I’m tapping
on the hamburger button, and I’m tapping to dismiss it. And the screen is kind of
flashing blue in that area. So why is this happening? Well, this turns out, again,
to be due to the legacy content on the web. We had this big problem in
the early days of the web where the user with
tap on some content, and then they’d
be stuck waiting. And so we made this
decision to have links go blue for a
brief amount of time so the user knows that
the tap was recognized and that they know
that they need to wait. But these days, when we’re
building these rich experiences that are going to be responding
to user input immediately, this blue flash is really
just a distraction, and it takes away
from the design. So if you want to
blue flash, great. You get one by default. If you
don’t want to a blue flash, it’s really easy to fix. You just add this
one line of CSS– webkit-tap-highlight-color. And then this is
an rgb alpha value. The zero at the end
means the alpha is zero. It’s transparent. So this makes the blue
flash transparent. So this is just a small
example of the polish that you can bring
to your websites. Now thirdly, the user
should always be in control when they’re on your site. And so earlier we saw this
example of loading an article and it jumping out
from underneath us, which is probably a common
experience that we’ve all had. So the alternative to that is
what we call the stable load. This is where images
and dynamic components have their size
pre-determined such that the browser
knows how to lay out everything on the screen even
before they’re downloaded. And so this is the solution,
just specify those sizes. And it really allows the user to
interpret the page better, not accidentally tap
on the wrong thing. Another case where
I personally find I’m kind of taken out of
my context and diverted is sometimes with
permissions on the web. So there is this
pattern that I’m seeing a lot at the
moment where I’ll land on some kind of e-commerce
site or some news site, and the first
thing that I see is a bar appear at the bottom
saying that the website wants to send you notifications. At this point, the user really
doesn’t have any context to make this decision. They don’t know what
you’re going to send them notifications about. And you probably have multiple
calls to action on the page. Here, there’s different
browse buttons. So it’s unclear what
we’re expecting users to do at this point. Instead, I really like
what Twitter’s done, which is where– when you tap
on their notifications tab– if you haven’t previously
enabled push notifications, they show this
full screen overlay asking the user if they
want to opt in and get push notification. Incidentally, push
notifications are one of the new features, the new
standardized features brought by Progressive Web Apps. So you can now build
web experiences that can send
native notifications on Android and on desktop
that look and feel just as you would expect. So those were the
Feel Good Principles. Site should be reactive
to users input. They should have
predictable user experiences and not set up things that
are going to trip up users. And users should always be
in control fundamentally. And what we’ve seen actually
in the last 18 months from companies shipping
new Progressive Web Apps that follow these
principles is really good results. We’ve publish a whole bunch on– if you Google Progressive
Web App case study, you’ll find a whole bunch from
lots of different companies. This is just a few– 100% increase in session
duration from Forbes, 170% increase in page
views from Twitter, and 76% in higher
conversions from Alibaba. So this is potentially a very
major impact on business. Now I want to talk quickly
about how better UX is now being built into browsers
and how you can do things that you couldn’t
do before thanks to these new capabilities
being built in. So the first of
these is Smart Lock. So Smart Lock is
this capability that means that if a user has
ever logged into your service on any device, native or on the
web, then when they transition to another device they can
be automatically logged in without needing to remember
their username and password. We find that when users are
presented with a login screen, that actually the
majority of them often just leave the
site at that point and they don’t ever make it
through that login screen. And so this is a really
key part of your flow that you can optimize
with this new capability Smart Lock, which is also called
Credential Manager if you’re looking at up. Next, the Payment Request API. So the data shows
that approximately 65% of users on mobile that
get to a checkout screen don’t end up completing
that checkout. And when we ask them
why, most of them say that it’s because the
form was too long or too hard to fill in. And so Payment Request
lets you tell the browser what the price is and
what the product is, and then the browser will render
this native form that’s already filled in with all of
the user’s information that we already have. The user can just
tap pay, and then you get all of that form
information back. You get the credit card
details, the address, all of those things
that you would expect, but the user it have
to retype them in. And so this can be really
big impact on e-commerce. And thirdly, Service
Workers allow you to build experiences that
work on flaky networks really performantly or even
when fully offline. So here you can see Konga. This is a Progressive
Web App in Africa, where they’ve shipped
their experience such that if the user goes offline,
they can look back at items they’ve looked at previously. They can you know
take their phone home and show their partner
what they were looking at even without internet. And actually, with
their experience when you’re on that
product listing page, they give you a
phone number to call, and you can actually
call that phone number and convert on that item without
internet at a later point. So these are some
of the new things that are possible on the web. In fact, in the last
year alone, we’ve shipped over 215 new
APIs on the web– new APIs like Web
Bluetooth and Image Capture that gives you full control
over the camera and the focus and aperture. So if you’ve ever thought, oh,
I can’t do that on the web, I have to do native
for some reason, just go back and take a look
and see if it’s now possible. Because a lot of
things really are. The web has come
a really long way. And finally, I’d like to share a
kind of debate that’s currently going on on the
web in this area. So there’s this common
question that we get– should I tweak my PWA
to visually fit in with Android or iOS? Especially when running in
immersive mode, what are users, what do they expect? I think this is a really
fascinating question. It’s very philosophical. Some people would argue
that the web should evolve its own aesthetic and its
own design patterns and users should become accustomed
to web design as a concept. Other people would argue
that you should fully adjust how your experience
works on iOS and Android like you would a native app. At the end of the day, the
user is holding the phone and it looks the
same, so why should we draw this user experience
barrier based on technology– JavaScript versus Java? It should be about
the form factor and the user’s context, which
I think is another great point. A really interesting
example of one company’s way of handling this– so this is the
Progressive Web App from the city of Barcelona
for their tourists. It works offline. You can store different sites
and the information and maps. And what they’ve
done is they’ve kept the same fundamental structure
across Android and iOS, but they’ve tweaked the design. They’ve changed the
colors and the typography. They’ve centered the header. And they’ve really made
it feel a little more native while keeping the
fundamental underlying structure the same. This is a really
interesting pattern, and I think this
is an area where a lot more exploration needs to
happen, a lot more discussion. If you have thoughts about
this, I’d love to see blog posts and see people trying
different things. And finally, if you’re
interested in going out from here and building
a Progressive Web App, trying out what
it’s like, there’s a couple of ways I’d recommend
looking at getting started. The first is the Polymer CLI. So Polymer recently
released a new command line tool that makes it really
easy to get up and running. It gives you all of
the basics of an app, including service
worker caching, all those various aspects. And then on the React side,
there’s this great tool– Create React App,
which lets you get started with React
without setting up a whole build process. You don’t have to deal
with Babel or Grunt or Gulp or any of those things. And in fact, Create React App
just announced at Google I/O that any web apps built
with Create React App will be Progressive
Web Apps by default. They’ll have service
workers built in and do a lot of these things
just straight out of the box. So these are two really
good places to get started. And remember that
when you go out and start building these
things, use skeleton screens and those kind of
techniques to make sure that your site is reactive
to the user’s input. Consider keeping things simple
and using a bottom navigation instead of the gestural inputs. Or if you do the gestural
input, be thoughtful about it so your site is
predictable to users. And use techniques
like stable loading to ensure that your site
isn’t jumping around underneath user’s
fingers in order to keep the user in control. And so, I think we have
a couple minutes now for Q&A if you’d
like to stick around. But otherwise, I’ve been Owen. You’ve been a
wonderful audience. I hope you enjoy the rest
of I/O. Thank you very much.

Leave a Reply

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