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