[MUSIC PLAYING]
KENJI BAHEUX: Hi, I'm Kenji.
I'm a project manger in Chrome.
I work on making
things load fast.
YUSUKE UTSUNOMIYA: Hi, everyone.
I'm Yusuke from gTech Velocity
at Google, helping our partners
with everything web.
KENJI BAHEUX: This talk is
about bleeding-edge API design
to help you create user
experiences that are seamless,
instant, and available.
There is a lot to cover today,
so let's jump right into it--
maybe.
It's coming.
Well, yeah, the [? loading ?]
[? on the screen ?] first,
obviously.
So we spend a lot of
time waiting for things
to load or disappear
on the screen, right?
Especially on mobile,
browsing the web
doesn't feel
particularly delightful
compared to the user experience
you have on native apps.
And there are a few
reasons for that,
but I think the main one is
the way we load websites,
generally speaking, it
is sluggish, typically,
the user experience
that we have on the web.
Let's see why that's the case.
So this is a typical
user experience
that you have on today's web.
You click on the link,
and then, essentially, you
see this blank page,
because the process is
going to fetch the HTML
for the main resource
for the new navigation,
and it can take a while.
So you still wait for
something to happen-- anything.
You don't even know, is it
going to work or not, right?
It could just fail.
And then, eventually, you start
to see like things rendering
and you only use it.
But what happened
usually is that there
are elements on the page
that comes late and shift
things on the screen, which
makes it very hard to use,
because you tap on
something, and then
you tap on the wrong thing.
YUSUKE UTSUNOMIYA:
Kenji, I think you're
absolutely right on this.
I wonder if we could deliver
experiences like the one
that we have on the
slide right now--
experiencing without
wait times, experience
without jumping layouts
or rendering states,
experiences that feel snappy
because they seamlessly
transition you to
your destination.
Kenji, do you think
it's a good idea
to first walk through the
range of options we have
when building new user
experiences today?
I really want to hear a couple
of your good, good metaphors.
I really love [INAUDIBLE].
KENJI BAHEUX: I'm not sure about
good, but we can try it, right?
YUSUKE UTSUNOMIYA: Sure.
KENJI BAHEUX: All
right, so you could
choose to focus all your
resources into building
a native app and develop a
top-notch user experience.
But the problem
with that approach
is that, on average,
this is the equivalent
of building an
experience that only
a small subset of your
users can afford or need.
Installing a native app
is a non-trivial request
because it is, first
of all, time-consuming,
but it also requires a high
level of trust and commitment--
whether that's about
storage, or enabling
a bunch of permissions.
So while you could
skip on native,
you absolutely need a
presence on the web,
especially if you want
to reach more users.
And on the web, you have,
essentially, two options--
MPA, or Multiple Page
Application, and Single Page
Application, SPA.
Let's have a quick
look at SPA first.
OK, so to me, going SPA is kind
of like building a high-rise.
It is complex because you end
up rebuilding key features
that the browser provides
for free, such as history
or restoring scrolling position.
That shared experience can be
nice when you are in the app,
but getting there can take a lot
of time because of all the code
that you need to load upfront.
And that's [? really, ?]
[? really ?] [? big, ?]
because first impression
matters a lot when you're trying
to reach new users.
And as you build
this thing it kind of
falls apart, because as the
site [? of the SPA ?] increases,
it is just too complex.
And so the only
solution you have
is to put this big thing
into multiple SPAs.
And so you're back
to square one,
where you have to navigate
between different user
experiences.
And as we've seen, it's not a
great user expense on the web.
The last thing is that,
when we talked to partners,
it was clear that, for
them, an SPA results
in the loss of productivity
because of the [INAUDIBLE]
dependencies of
a monolithic app.
So for instance, you can't
just fiddle with things
without impacting other things.
And let's look at what MPA
has to offer on your end.
To me, going MPA is kind of
like building a small town.
Each team gets its
own house, which
means that they can focus
on the thing that matters.
They don't need
to reinvent things
that the browser
provides, for instance.
And they can also more
freely tweak their product
to their needs without
worrying of having
to impact other teams.
But MPA are not without
downsides, right?
It's not perfect.
Overall, it is
true that MPA tends
to result in user
expenses that are
higher-friction because
everything is navigation.
And as we've seen, it's a rather
frustrating user experience.
YUSUKE UTSUNOMIYA: Kenji
talked about our desire
of enabling seamless
experiences on the web.
Seamless sounds
very neat, but it
might be hard to understand
what we actually mean by this.
Here's an example from
the Android platform.
It's called shared
element transition.
Essentially, the idea is to use
an element throughout the state
transition to reassure the
user that their action has
been acknowledged
and being acted on.
KENJI BAHEUX: Good example.
Too bad this is only an
Android-native app, API, right?
I'm sure that a lot
of you would like
to build something like that,
especially if you have an MPA.
It's kind of like
an achievable today.
YUSUKE UTSUNOMIYA:
Kenji-san, Kenji-san,
I think I have
something for you.
It's still in the early
days, but with the help
from the broader
community, we think
we have found a way to
create such experiences.
It's called Portals.
We gave a teaser
during last year CDS
and showed off our seamless
vision in IO this year.
The feedback from the
community has been amazing,
and the team has made
significant progress
for enabling same-origin
use cases, which will
be our focus for this talk.
So Kenji, could you please
give us a high-level pitch
on what Portals are?
KENJI BAHEUX: Yeah, sure.
So let's briefly expand the
key concepts behind Portal.
Portal is all about enabling
better navigation on the web.
And in the early
days, every navigation
was done through simple
links like this one, right?
But the downside is
with those simple links,
it's not super appealing.
It's just a bunch
of text and words.
And also, the friction of
navigating gets in the way.
Then, snippets
came around, right?
It's some sort of way to
make the links more appealing
by providing more details
and having a nice visual.
But that said, it's
not much better.
For one, the information
that is available
there could be out-of-date.
And also, it's still
going to trigger
this high-friction navigation
and navigation user experience.
All right-- and eventually,
iframe came around.
So because the
content is now served
by the website you are
linking linking to,
the [? freshnet ?] concern
is not there anymore,
but it's still going to
trigger a high-friction user
navigation.
And so it's not that different
from what we've seen so far.
And this is where
Portal comes in.
As you will see, it's
sort of like an iframe,
except that you can
navigate into it.
So I think this is a better
explanation of it, right?
It's like a frame that you
can open and cross over.
All right, I think that's
enough metaphor for now.
Hands on time.
YUSUKE UTSUNOMIYA:
Awesome stuff, Kenji.
I like how you've
framed those things.
KENJI BAHEUX: I see
what you did there.
YUSUKE UTSUNOMIYA: Exactly.
So the exciting that thing is
Portals for same-origin use
case is coming soon
as an Origin trial.
Just like any
other HTML element,
you can use it directly with
the HTML tag or from JavaScript.
Let's walk through step by
step what Portals could do.
Let's say you have a
page, say foo.html--
all blue, super nice with
its full blue background,
and having foo.html
in the center.
KENJI BAHEUX: This looks
amazing, like Jessie's shirt.
Like it's-- I don't know if
you did that on purpose, maybe?
YUSUKE UTSUNOMIYA: And you also
have another page, bar.html,
which is pretty
similar to foo.html,
but having a different
color and a different URL.
KENJI BAHEUX: I
should have weared
some kind of yellow
thing, right?
YUSUKE UTSUNOMIYA: Exactly.
I know these are looking
pretty beautiful.
We'll use these two pages to
see what Portals could do.
You would first want to check if
your browser supports Portals.
As you all know,
progressive enhancement
is very important
because we don't
want to break any experience
in non-supported browsers.
You can check if a HTML Portal
element is in the global window
object to achieve this.
Next, let's create
a portal element
by document.CreateElement,
setting the source attribute
as bar.html, and adding
some styles of your own,
and lastly, adding the
element to the document.
And boom, you'll see bar.html
embedded in the page.
KENJI BAHEUX: Fantastic.
This is like never seen before.
YUSUKE UTSUNOMIYA: Yeah,
it looks amazing, right?
You can actually
check in the dev tools
that another document is
rendered inside the Portal
element.
In this case, I
added width 100%,
height 100%, transform
scale, and a fixed position,
so it looks just like
the full document is
embedded in the page.
But you can file your
Portal element as you like.
KENJI BAHEUX: Isn't it exciting?
You can now embed other
documents in a document?
That sound a little
bit, like, familiar.
YUSUKE UTSUNOMIYA:
Yes, but what really
gets exciting with
Portals is that it
has this powerful Activate
function built in.
This function will
let you navigate
into the already-rendered
page inside a Portal element.
Let's see it in action.
I'll, then, now add an
OnClickListener to the portal
and see if I could
activate the portal when
the user taps on the element.
And what you get is--
this.
The top-level window navigation
happens, and you magically
navigate into the portal.
It's an instant
navigation experience.
Like I mentioned, this is a
top-level window navigation,
so the URL correctly switches
to the activated page.
I mean, keeping the URL
right is always good
when you work with the web.
So as you can see,
Portals really
makes the loading
speeds disappear.
You don't need to
wait for the page
to render anymore
because it's already
rendered inside the Portal.
KENJI BAHEUX:
Thanks you, Yusuke.
I'm very impressed because you
did make loading disappear.
Like, round of applause.
[APPLAUSE]
However, on the
second [? side, ?]
this is super confusing
because it goes too fast.
I mean, it's like
one of those movies
where they quickly like
shift to a different scene
and you lose the plot.
Look at the target experience
that this is so much easier
to understand.
YUSUKE UTSUNOMIYA: I'm
totally agreed with that.
The good news is,
Portal does enable
the creation of those
intuitive and delightful user
experiences, but you have
to put some efforts to it.
I think this is preferable,
because a platform shouldn't
be in the business of defining
rigid user experiences.
It should empower
you to design what
works best for your
product and your users.
KENJI BAHEUX: Cool.
I really like this concept
of bring your own animation.
It makes a lot of sense.
YUSUKE UTSUNOMIYA: So
what we can do better is,
first, embed the Portal element.
And when the user
taps on the element,
don't activate just yet, and
start animating the portal.
In this case, let's try to
bring back to scale to 100%.
Once the Portal element
covers the full screen--
and by the way, you can see that
the URL is still at foo.html
at this point--
and lastly, activate the Portal.
The instant top-level
navigation happens and the user
has now landed to bar.html.
Like I mentioned, Portal has
nothing to do with animation,
but you can always
animate the Portal
to make the transition smooth.
It could be using key frames
or JavaScript to move around
the element, but in
this case, let's say
we animated the element
with CSS transitions.
The fancy animation function
we have here could be something
like changing the transform
scale, translate x,
translate y, and also setting
the transition duration to 400
. milliseconds.
The animation could look
something like this--
very smooth.
When the CSS
transition completes,
there will be a transition
end event being fired.
Listen to that event,
and then activate.
KENJI BAHEUX: And well, you
now have a smooth transition
despite being an MPA.
That's pretty cool.
But I mean, yeah, it
does look much better.
But what if I don't want
my users to navigate away?
YUSUKE UTSUNOMIYA:
Don't want to force
the users to navigate away?
Kenji, I don't know.
I think you're asking too much.
KENJI BAHEUX: Sorry, I
really can't help it.
But I swear, this is
going to be useful.
So can we do
something about that?
YUSUKE UTSUNOMIYA: OK, yeah.
So the good news is, you can do
that easily with Portals, yes.
Another powerful API
that element provides
is adoptPredecessor.
As you can tell from the
name, after activating Portal,
you will be able to reuse
the predecessor, which will
be the previous page instance.
Let's see how this works.
First of all, you can listen
to the portalactivate event
inside a Portal
embedded document
to check if the
page was activated.
This event is very useful
if you have something
you want to do right
after the activation,
like changing the UI and such.
And the most exciting
pieces that the event
comes with this
adoptPredecessor function, which
you can use to retrieve
the previous page
as a portal element with all
the UI and the JavaScript
states available.
And from here on, you can
add it to the document
and use it like
any other portal.
What I built is
something like this.
Bar adopting Foo as a
predecessor, and then activate.
Foo adapting Bar as a
predecessor, and then activate.
It's kind of like this cat
like spinning back and forth--
endless loop.
KENJI BAHEUX: That's
very cute, but there
are more practical
ways to use this thing.
So let's have a look.
Like this example from Yahoo--
they are using adoptPredecessor
to smooth out the experience
of checking breaking news.
When the news
stories break, it's
very likely that you were
doing something else.
And so having you navigate away
from whatever you were doing
would be a pretty
bad user experience.
But in that case, by using
Portal and [INAUDIBLE],,
you can keep the
context around so
that user knows that whatever
they were doing is still there.
And so they can
quickly go back to it.
You see?
I told you it would be useful.
YUSUKE UTSUNOMIYA:
Very exciting stuff.
While Portals is
a powerful API, I
would also want to point out
some tips when using Portals.
First of all, as we
mentioned, Portal
does not come with
any animation features
by default, which
would also mean
that it's your responsibility to
maintain the 60 FPS animation.
As Uncle Paul has been
saying many times,
stick to changing
transition opacity.
Use will-change to
give a browser hint.
And if you're directly
animating using JavaScript,
user requestAnimationFrame.
Next, accessibility.
In time for the
Origin trial, we want
to make sure the
accessibility works fine
and the semantics works
fine for the Portals.
Also, from some people prefer
reduced motion settings,
so please consider using the
prefers-reduced-motion @media
query to customize
the animation.
In this case, when the user
prefers reduced motion,
the transform transition that
moves the elements around
would be nearly instant.
Last, but not least--
and I cannot emphasize
this more-- but again,
while Portals is a
powerful element,
avoid overloading the
page with Portals.
What you can do here is try
loading a new portal based
on user interaction
and interest--
something like using the
intersection observer
to lazily load a portal
or dynamically creating
a portal on user
interaction, initially
immediately showing the skeleton
UI while the loading completes.
KENJI BAHEUX: All right,
if there is any thing
to take from this
overview of Portals,
it's that Portal is, by
design, a very simple API
because we don't want to get
in the way of your creativity.
And so to give you some ideas of
what you could do with Portals,
we got some UX patterns
and a bunch of demos
from partners to show off.
Let's start with this pattern
that we talked about last year
at CDS, but it's
still a good one.
This works really well
when you know where
the user is going to go next.
And so, this is something
that we build in collaboration
with Hatena.
As you can see, it's
a comic viewer-reader.
And the next chapter is
pre-rendered right there
on the last page.
And so you can seamlessly
transition the user
to the next chapter.
And this is an MPA, right?
This is not an SPA.
This is another exploration done
by Farfetch, an online luxury
fashion retail platform
based in the UK.
YUSUKE UTSUNOMIYA:
Got that right.
KENJI BAHEUX: Got
that right, yeah.
Their goal was to use
Portal to smooth out
the navigation on their
inspirational content page.
They are also using
adoptPredecessor
to the end of the whole sequence
to end the swiping navigation
back to where you have started.
All right, second UX
panel that we have.
This is designed to help users
find more quickly the item
that they want among many.
What goes on here
at the high level
is that there is a portal
all that is offscreen,
and it renders a skeleton UI.
And when you use the
site to check one item,
the main page is
sending the information
that the portal needs
to complete to view,
and the animation is
started, and hopefully,
by the end of which,
everything is in place.
It's pretty-- a good
user experience.
All right, and so
this was just user--
expand on that [INAUDIBLE].
But we have partners
that use that to create
something interesting.
So this one, done by Yahoo
Japan PayPay [? Mall ?] team,
you can see it's a different
zoom in/zoom out animation
that's very fancy.
YUSUKE UTSUNOMIYA: Once
the user taps on an item,
they are dynamic creating
a Portal offscreen.
While the Portal loads,
immediately animating
the existing image and
showing a skeleton UI
of the product detail page.
After the portal loading
completes, activate.
They are actually providing
the same types of experience
in their native apps,
but it's really nice
to see this smooth transition
on the web as well.
So awesome.
Kenji, do we have room
for one more UX pattern?
KENJI BAHEUX: It's
going to be tight,
but maybe we can give it a shot.
YUSUKE UTSUNOMIYA: Cool.
This one it's about providing
a more intuitive and faster way
of consuming content, and
I call it speed browsing.
KENJI BAHEUX: Wow, you
have a trademark already?
YUSUKE UTSUNOMIYA:
Yes, I got that right.
Like the ones that we are
showing on the slides,
as your user reaches
the end of the page.
You can use Portals to
pre-render the next page.
Have it peek from the bottom so
that the user can drag it over
to complete the navigation.
In this exploration, eBay
is experimenting with Portal
to help their customers
quickly browse
through different products.
The current user
experience without Portals
involves a lot of back-and-forth
between the product detail page
and its search results page.
In other words,
without Portals, you
end up loading and rendering a
lot more things which results
in frustrating experience.
"Yahoo Japan News" built a whole
new experience from scratch.
This is a stack of
highly visual cards
that the user can swipe through,
also combined with the ability
to seamlessly deep-dive
into the article itself.
And all of these screens
are separate pages,
and yet there's absolutely
no loading to be seen.
Very smooth, great
experience, and something
very new to the web.
The exciting part is
"Yahoo Japan News"
has published the prototype
as their lab experiment,
and you can experience
their Portals implementation
from the link shown
on the screen.
Of course, it's still
in the early stage,
but we think this new experience
has a strong value proposition
regarding overall UX.
KENJI BAHEUX: All right,
we also received a quote
from the CTO of
Yahoo Japan, which
I'm super excited about
because it does show that there
is a need for an API like this.
Even companies with plenty
of resources and skill
still prefer using MPA
despite all the downsides
we talked about.
And so, having Portals as
part of the web platform
to squeeze out these
expenses is super useful.
So yeah, so Portal will
[? always ?] [? to ?] improve
the user expense thanks to the
smooth transition between web
pages, even on our
MPA architecture.
And the last part is the
one I'm super excited about.
In addition, not only
engineers, but also designers
could use Portals effectively.
So I really feel like
Portals is a tool that
helped democratize seamless
transitions for everyone
and would love to see
what you can come up with
and your feedback on this API.
There is a lot more examples we
could show off, but we will be,
definitely, running out of time.
So thanks to all
our early partners
for their amazing
feedback we got so far
and building
inspiring experience.
Thank you.
[APPLAUSE]
YUSUKE UTSUNOMIYA: I
mean, this is great.
Can we wrap up our session now?
KENJI BAHEUX: I wish,
[LAUGHS] but not quite.
As you've seen, is
true that you can
use Portal to build very
compelling user experience.
But is it really enough?
YUSUKE UTSUNOMIYA: What
do you mean by that?
KENJI BAHEUX: The
problem was merely
building great user
expenses is that there
is no guarantee that your
users are going to find them.
It takes a lot of efforts to
try something new, especially
when you already have your own
preference about how you want
to use your time, for instance.
And so what do you
do in that case?
Well, essentially,
you can do two things.
Number one, lower
the amount of effort
it takes for people
to try something new.
And number two, lower
the amount of effort
it takes for someone
to try something new.
Ideally, it is zero, right?
Let's now look at a few more
proposals and ongoing efforts
that we have that are meant
to help on this front.
All right, so first,
let's start with a way
to make an initial
navigation instant.
Use case-- what
if, by the time you
went on your Japanese
commute, you already
have a whole bunch of content
available on your device?
I think people talked
about it just before.
YUSUKE UTSUNOMIYA:
Yeah, that actually
solves most of my problems.
KENJI BAHEUX: Yeah, OK.
So good news is there
is this new API called
Periodic Background Sync, which
is meant to solve that issue.
And so not only
would the experience
be instant, but it will
also be available--
like connection doesn't
really matter anymore,
because it's already
on the device.
So let's see what this
could mean in practice.
So this is an
exploration done by Gaana
by Tencent [? Internet. ?] Gaana
is the largest music streaming
service in India.
What's interesting here is that
India is a challenging market,
in particular because data has
become a lot more affordable,
the infrastructure has trouble
to keep up with the demand.
And so depending on
the time of the day,
you can end up on a
very slow connection.
And so Gaana wants to use PBS
to smooth out the experience--
so it can fetch
content ahead of time
so that they don't have
to worry about hitting
bad connection through the day.
This is another
example, from Hatena.
They want to use Periodic
Background Sync to proactively
prefetch the latest
edition of a user's
favorite manga or magazines.
And these can be very large,
like 100 megs at a time.
The other thing that's
important to know--
and maybe that's a surprise
for a lot of people--
is that in Japan, more than half
of the subscribers only have
three gigabyte of storage--
sorry, of data-- per month.
After that, they get
throttled to 2G, which
is a very bad user experience.
I've been there.
You've been there too, right?
YUSUKE UTSUNOMIYA: Yeah, yeah.
For about three years, yeah.
KENJI BAHEUX: Yeah.
[LAUGHS] And so the
idea is that you
can use PBS when you are at
home on Wi-Fi to download
this heavy content so that
when you're on the commute,
everything is there.
Isn't that amazing?
YUSUKE UTSUNOMIYA:
Yeah, this is exactly
the feature I wanted
I mean, I love manga,
and it'll be great times--
like, to kill my commute time.
KENJI BAHEUX: All right, can you
run us through the API, Yusuke?
YUSUKE UTSUNOMIYA:
Sure, definitely.
With PBS, you'll be
able to register a sync
event for your service worker.
You can satisfy
your own tag name
and just, like, the
background sync.
In this case, the sample
code is registering
sync-amazing-cats event,
which is very nice.
And here's also-- there's also
a minInterval option where
we can define a minimum duration
between each of the syncs.
And once the event
is registered,
the browser will regularly
fire periodic sync events
at the service worker.
You could then run your own
logic to sync [INAUDIBLE]----
oh something went wrong?--
such as the web resource
and the guest storage,
or application settings
in your IndexDB.
Taking a minInterval
option into account,
the frequency of the
sync event depends
on how frequently the user
engages with your website.
In Chrome, we are reserving
PBS for installed apps, a.k.a.
installed PWAs.
When the event
triggers, please be
mindful of the user
environment-- for example,
storage and data saving options.
Some APIs that might help you
understand if it's a good time
to run the sync logic is
navigator.connection.saveData
to see if it's in
a data saving mode,
and storage API to estimate
the available storage.
Cool, so we now have a way to
download podcasts ahead of time
and also make the transition
smooth with Portals.
Kenji, I think we're
good for today.
KENJI BAHEUX: You
know me, right?
I always want more.
So we're not quite done, right?
I think it's great that we can
have this website practically
fetch content ahead
of time and deliver it
like an instant-available,
great user expense.
But there is something missing.
The problem is that
if all of that work
is done and no one noticed,
what's the point, right?
It's actually wasteful.
But to me, this feels like
a discovery opportunity.
And so we do understand that
building great user experience
takes a lot of effort.
And so we've been thinking of
ways to reward that effort.
In particular, we
think we can help
you reengage with your
users or find new users.
And so more concretely, this
is like early exploration,
but what you're
looking at right now
are ways for us to
surface content that's
available on the device in
the Chrome downloads page,
and also into
Chrome New Tab page.
So we're [INAUDIBLE]
with that, but that's
one of the ways in
which we want to help
user identify that something
interesting on their device.
But to make this work,
we need your help, right?
Only you what's
available on the device
and how to best present it.
And so the good news is there
is a [? nerdy ?] proposal called
content indexing.
And so Yusuke is go to help
me to explain how that works.
YUSUKE UTSUNOMIYA: Sure.
So the prerequisite for
using a content indexing
API is to ensure that you are
your web app uses a service
worker and that at least
a subset of your URLs
can be navigated
to while offline.
And please don't get it
confused-- content indexing API
is not a new storage mechanism.
You can keep on using
a test source for that.
It's a simple way
of indexing content
that is available on the device.
Let's look into the basics.
You can add URLs and
associated metadata
to the index with the
newly-exposed index.add
function in the service
worker registration interface.
For details, you need
to add a unique ID.
and the launch URL, which
has to work offline,
and some other metadata,
which the browser can
use to show a list of readily
available content to the user.
You might want to provide a
Save for Later button to save
and index a piece
of content, or you
might want to add the
contents automatically
when a periodic background
sync event fires.
In addition, the API provides
ways to list and delete
the entries in the index so
that it can keep the index up
to date.
The API will be available
as an Origin trial
soon from Chrome 80, and we
are waiting for your feedback.
KENJI BAHEUX: All right,
having a collection of content
ready to go is quite
convenient, but I think
we can take it a lot further--
hopefully, In those three
minutes that we have left.
So what if we could
have, for instance,
a self-contained
piece of content
or apps that we could
share and distribute,
instead of just having links?
This will allow your user to
find, like, or discover, opt
in, or enjoy like content
in so many interesting ways.
So for a self-contained piece
of content or app to exist,
there needs to be a way to
package all the resources
that thing needs in a convenient
and distributable format.
YUSUKE UTSUNOMIYA: With the
help from the community,
we've been working on
specifying and implementing
such a format for a long time.
We have been using the term,
bundled HTTP exchanges.
KENJI BAHEUX: That's
quite a mouthful.
YUSUKE UTSUNOMIYA: Honestly,
[? http ?] speaking, yes.
So we decided to
name it Web Bundle.
KENJI BAHEUX: That's very nice.
I like it.
YUSUKE UTSUNOMIYA: As
the new name implies,
it's designed for
the web, and allows
you to bundle any resources
into one convenient file, which
you can serve over
the wire or even share
with any peer-to-peer protocol.
KENJI BAHEUX: That's
sounds like some sort
of zip archive for the web.
YUSUKE UTSUNOMIYA: That's
actually one way to see it.
Let's see what we
have for so far.
We have we now have a CLI
to easily build a bundle.
Since it's a bundle, since
it's built with Golang,
you would want to use
go get to first install
the command like tools.
The command gem bundle
gives you many ways
to bundle up web
resources, but I personally
feel the -har option is really
convenient because it just
takes the HAR files and input
to produce a web bundle.
It's super easy.
We are also exploring the
JavaScript implementation
for web bundles as well.
We just released
the very first draft
an npm module
called [? wbn. ?] We
are still in the middle of
brushing up the library.
We hope that you will be able to
integrate this module into your
build pipelines so that
you could easily bundle up
your content.
KENJI BAHEUX: All right, as
I said, a distribution format
enables interesting use case.
In this example, you can see
that I can share with a friend
this amazing game called
[? "Prox," ?] which I having
in Web Bundle format.
And the thing is, I can
do that without internet.
I just need to use
a file transfer app,
and it just works.
I can share with my friend
without any internet.
I can be on a plane,
[INAUDIBLE] somewhere,
or even like [? Jack ?]
[? Archibald's ?] famous Wi-Fi
[? toilet, ?] if you
know what I mean.
It just works.
One more use case I'm excited
about is faster already.
YUSUKE UTSUNOMIYA: Oh,
Kenji, you are so much
obsessed with fast loading.
KENJI BAHEUX: I know, I know.
So the trick is, because
everything is on the device,
a Web Bundle will offer a
much faster user experience.
Let's do a match.
On the left, you
have Web Bundle,
all on the right, you have
[? WebWeb. ?] Ready, fight.
And see, [INAUDIBLE].
I mean, there is
no picture, right?
It's like Web Bundle wins--
amazing.
YUSUKE UTSUNOMIYA:
Just like Kenji, I'm
very excited about this
feature, but you really
have to try it yourself.
The good news is that
we added this USB Type
D-- yes, type Dino--
in your strap bag,
and it contains sample web
bundles and instructions.
You can play around with the
full feature of [? "Prox," ?]
[INAUDIBLE] and [INAUDIBLE],,
wherever you are,
no matter your
network condition,
or even on your flight back
to your hometown after CDS.
KENJI BAHEUX: All
right, to close,
we've talked about
four APIs today.
The first one-- Portal, which
is designed to enable instant
and seamless navigation.
This is going to
be available soon
in an Origin trial for
the same Origin use case,
and we are seeing
tremendous support
from the web developers.
Your interesting
feedback is going
to help us engage with
other browser vendors,
because so far, we've
got no signals from them.
So it's going to be useful.
All right, next one.
Periodic background
sync-- this is
designed to get content
ahead of time on the device
so that you don't have to
worry about connection.
This is already available
in an Origin trial.
We have great interest
from web developers,
and there is some work to do
with other browser vendors.
Content indexing-- this
one is about surfacing
the content that's
available on the device,
and it's going to be available
in an Origin trial soon.
This is brand new.
We want to hear from you.
So please try it out.
Let's let us know if it
works for you or not.
And last but not
least, Web Bundles.
So this is a convenient
format to enable
discovery and distribution.
This is bleeding-edge.
It's only available behind
an experimental flag.
There is some early interest
from web developers,
and some of the other
[? broader ?] vendors
are a bit concerned.
But that tends to be
for a set of use cases
that we didn't talk about today.
If you want to learn more,
come to talk to me later.
YUSUKE UTSUNOMIYA: Cool.
Finally, we've
made it to the end.
KENJI BAHEUX: Yeah.
YUSUKE UTSUNOMIYA: Thank
you so much for listening,
and I hope you're excited
by these new APIs.
Kenji?
[APPLAUSE]
KENJI BAHEUX: Thank you all.
Please check this link for
more details and pointers.
[MUSIC PLAYING]
