[MUSIC PLAYING]
ARTUR TSURKAN: Hi everyone.
My name is Artur.
I am a product
manager on Android.
ARUN VENKATESAN: Hi, everybody.
My name is Arun.
I'm in dev relations.
ARTUR TSURKAN: And
we're here to tell you
a little bit about
Android Slices--
a new API introduced
as part of Android Pie.
So there's going to
be a couple of things
that we're going to cover today.
The first is an introduction--
or we can say a reintroduction
to Android Slices, some user
experience best practices
in constructing
your Slices, also
some more details on search
indexing best practices.
And finally, through
the EAP that we've
been running over the
course of the summer,
we've compiled a list of
important developer gotchas
for you to keep in mind for when
you start building Slices when
they become available.
So let's start by
reintroducing Slices.
Before we get into
it, I just want
to remind you of
some resources that
are already available for
you to start looking at.
We introduced Android Slices
at this year's Google I/O.
And so you can find more
documentation details
at g.co/Slices.
As well, you can also
look up our I/O session
video Android Slices--
Building Interactive
Results for Google Search.
And that'll give you
a lot of information
on constructing Slices,
building a custom template,
and building your
UI for your Slice.
But as a quick
refresher for today,
Slices are a new way
for you to present
remote app content in Android.
Think of Slices as
embeddable apps snippets,
which can be easily
inserted inside another app
or as part of the system.
Slices are meant to work across
multiple possible surfaces,
and the whole idea
of Slice is to be
able to constrain
but still provide you
with a lot of power in
how you express your app
across multiple contexts.
Slices can contain a variety
of different components
that you provide,
including text and images.
But they're also very powerful.
They're not just static
pieces of content.
They can house real-time
data, interactive controls,
and also talk back to your
app on user interaction.
And so all of these different
examples that you see here
are examples of Slices
that you can build.
I mentioned that
Slices can be embedded
across a multiple
number of contexts.
And we're really
excited to be bringing
Slices to Search as the
first surface for you
to insert your Slices.
So as users are typing their
query in Search on Android,
you'll be able to enhance the
predictions offered by Google
with live, personal content
from your apps constructed
through the Slices you create.
There are two types
of Slices that you'll
be able to provide in
search predictions.
The first are for
app name queries.
So if someone's
searching for your app,
you can accelerate them to a
canonical part in your app.
So for example,
for YouTube, maybe
the desired goal is to help
users get back to the video
that they were just watching.
Another use case is for
any kind of general term
beyond your app name.
And so in this
instance, users can
be typing for mobile
data or data usage,
and the Settings app will
present them with toggles
to toggle their settings
regarding data usage.
So how do we build these Slices?
Well, let's start with default
Slices or app name Slices.
It's actually very easy to
build an app name Slice.
First, you just construct a
Slice as you normally would.
Android Studio's
recent updates include
tooling to get you started.
And what will happen when
you create a Slice is you'll
generate a definition in your
manifest, like this one, as
well as an extension to
the Slice provider class.
And that'll provide details
of how the system can
find your Slice and what kind of
template to offer to the system
when it does.
To make this Slice
map to your activity--
or to make this Slice
map to your app name,
you have to add
the Slice content
URI to your main
activity and make
sure to specify this in the
metadata field, as pictured
here.
So this tells the system, hey,
this is a Slice that I want
to point to this main activity.
And here is the
content URI from which
you can reference that Slice.
The implementation
details for general terms
are a little bit different.
So first, you actually don't
provide the same linking
in an activity as you would
for an app name Slice.
Instead, you're going to use
updates to the Firebase App
Indexing APIs to
expose your content URI
for a specific set of keywords.
So using the Firebase
App Indexing APIs,
you will construct an indexable
as you normally would,
that will have
maybe a public URL.
It will also have the name
for that indexable content,
some very targeted
keywords for users
to find that content,
a description.
And then finally, with the
update to the Firebase App
Indexing APIs, you will be
able to add your content URI--
your Slice URI for
this indexable.
And so when the user is
searching for the keywords
that you specified,
Search on Android
will replace that prediction
with the Slice specified
by the content URI
in this indexable.
Finally, in order
for indexables to be
translated from their public
URLs to their content URLs--
content URIs, excuse me--
you'll need to override the
[? on ?] [? map ?] [? intent ?]
to a URI method in
your Slice provider.
And this just lets you talk
between these two formats
in order for your
content URIs to be
visible as a search prediction.
Overriding this
method also allows
us to provide you, the
developer, with the flexibility
to define whatever
URI schemas are
most important to you
without necessarily attaching
them one-to-one.
Great.
So now we know how
to build a Slice
and also how to expose
it to Search on Android.
Let's go into a little
bit more details
on what makes a
good Slice and what
are some user experience best
practices to keep in mind.
So the first is try to focus
your Slice on one task or a set
of tightly related tasks.
Avoid making your Slice
do too many things,
and make sure that
content in the Slice
is coherent regardless
of where it's embedded.
So keep in mind that
though Slices are currently
embeddable as a search
prediction for now,
we'd like to think that
the Slices that you build
should be reusable in many other
parts of the operating system.
And you should consider,
when building your Slice,
for those possibilities.
So the example on
the left really
tries to focus a Slice on being
able to consume and preview
one video.
The Slice on the right
tries to now generalize it
to a couple of
other functionality,
like channel selection, and
so forth, and really stretches
the definition and
use of a Slice, which
we discourage you doing.
Try to keep interaction
with a Slice lightweight.
Highlight only the most
important fixtures--
features, excuse me.
And make sure that the
actions that you're
presenting to the user are using
clear and familiar iconography
so they can understand what
these actions represent.
Avoid making your Slice
do too many things
in terms of the
actions that you have.
And so the Slice
on the left mainly
focuses on users just listening
to the content of playlists,
and maybe also offers
some the ability
to like certain
[? comment. ?] The Slice
on the right starts
really leaning
into all the different items you
can do with all those playlist
items.
And that's probably
functionality
that's best served to
be done within your app.
When sharing your Slices
to different platforms,
make sure you're surfacing
recognizable features
and content so that
users know that they're
able to query for them.
And when they do query for them
and see it as a prediction,
they can understand how
it might have appeared
for that particular query.
Arun is going to go into a
lot more detail as to what
those different cases are,
but as a general principle,
try to keep that
the case, and avoid
promotional or advertising
content in your Slice.
And finally, have
your Slice focus
on accelerating
critical user journeys,
and try to make sure that the
Slice helps the user accomplish
as much of that journey inline
as possible without having
to go into your app,
by providing all
of the necessary information
and necessary actions
that the user would need
to accomplish that action.
And so you can see
consistently with all the cases
on the left, what's
happening is the user
has all the stuff that they
need to know to understand what
the Slice is for, what kind of
information it's representing,
what kind of actions I can
do with that information--
like changing the song,
adjusting the temperature,
or adjusting the brightness--
and they don't necessarily
need to click into
the app to do that.
The Slices on the
right are missing
some critical pieces
of information,
or some critical component
as part of that user journey
and requires users
to basically--
it adds an additional
point of friction for users
to complete the task that
they want to complete.
So that was a lot of information
on how to generally build
great Slices.
There's going to be a lot of
critical advice for building
great Slices for Search that
Arun is going to go into.
ARUN VENKATESAN: Thanks, Artur.
So here are some of the main
buckets when you think about
use cases for building Slices.
Use cases should be
familiar and hyperrelevant,
such as requesting a ride
on a ride sharing app.
Use cases should be targeted,
rather than surfacing
all content in your app.
And finally, build Slices
to recall and re-engage
with content that the user's
already previously seen,
rather than just
discovery-oriented use cases.
Next, we'll see
some more guidelines
around the type of
content that you
could surface in Slices and the
data that needs to be indexed.
Slices should be targeted
and personalized.
Consider the example
of a video streaming
app that shows Slices when a
movie that a user is searching
for is available in their app.
The app could index movies
liked by the users previously,
or just movies curated based
on users' in-app behavior.
Do not create an index license
for all movies in you database,
or even just the top 200 movies.
Slices should give users
meaningful controls
or information.
As an example, a
ride sharing app
is building Slices so that users
can request rides to places
that they're searching for.
In this case, create an index
Slices for ride requests
based on users' past
history, or just ride request
to current popular
places near the user,
such as concert venues.
Avoid creating and
indexing Slices for as many
places as possible in the
user's geographic area.
Slices should give users
timely information.
Let's say that a smart
home map is building Slices
so that users can control
lights in their home.
The app could serve as
a light control Slice
when the user's
likely in their home.
It's not recommended to
create and index Slices
for controlling lights at
any time or in any place.
Here are some more examples
of the type of app content
to index and display in a Slice.
A food ordering app
can easily fetch
development, real-time data,
such as food price, when
the user refreshes the Slice.
Similarly, a news app Slice
can index and display morning
digest to their readers.
Travel and local app
Slices can enable
users to view their personal
content, such as bookings
and upcoming hotel and
flight reservations.
Let's now see how to
keep your Slices fresh.
When a Slice is indexed,
the indexable object created
includes both the Slice
metadata as well as
a cached snapshot of the Slice.
And in order to ensure that
the Slice that you provide
to search [INAUDIBLE] complete
is always accurate and is not
stale, you should set a
time to live in your Slice
This time to live field as
used by the Google search
app to ensure that stale
caches are not displayed.
In this code example
here, the time
to live for the weather Slice
is set to one hour expiration.
And of course, if
your Slice has content
that is not time sensitive, just
use a time to live of infinity.
In order to present
fresh data to the user,
also periodically re-index
your Slices in the background
when content changes, and
only when content changes.
Do not re-index more
than once per day
to avoid battery issues.
Earlier, Artur showed us how to
set keywords for general terms
Slices using the Firebase
App Indexing API.
So what are some of the
best practices for keywords?
Limit keywords to 10 per Slice.
And account for
likely permutations--
for example, music volume
instead of media volume.
But don't account
for all misspellings.
This is probably the most
important-- avoid keyword
stuffing.
So use the minimum
number needed per Slice.
See, your app Slice will be
demoted in search rankings
if you use too many
irrelevant keywords that users
don't end up tapping on.
So what determines if
your app Slice appears
when the user searches for a
keyword in the Google Search
app?
This is the biggest question
we get from developers.
The most important signal
is the number of times
that the user uses
your app on the device.
It's also important
that the user
has viewed the content
previously and interacted
with it.
And finally, in order for us to
know that the user interacted
with the content on your
Slice, log user actions
through the App Indexing API.
We'll conclude our
session today by sharing
some of the lessons learned
from the Slices early access
program.
Content URI versus deep
link URLs can be confusing.
As Artur mentioned, content
URIs are mentioned with a Slice
and start with content://,
whereas deep link URIs are
associated with an indexable
and start with http or https.
Content URIs use
the package name,
whereas deep link URLs
follow the website
or the reverse of the package
name, as shown in the example.
Finally, when you see a
content URI, think of a Slice.
Keywords must be included in the
Slice title or subtitle, else,
the Slice will not
be displayed when
the user searches for keywords.
This is done in order to
ensure that relevant content is
displayed to the user when
they search for something.
How do you handle location?
Slices do not provide
location to apps
and therefore use the
last cache location
while displaying a Slice.
Re index your keywords
based on the last location.
However, also note
that indexables are not
instantly updated.
And frequent indexing may
lead to battery issues,
as we mentioned before.
So keep in mind
the best practices
for handling location
changes for your app,
and just apply them
to the Slices as well.
It's recommended to keep the
Slice initialization short.
The onCreateSliceProvider
method is
called for all registered
Slice providers
on the applications main
thread at launch time.
And therefore, do not
perform lengthy operations,
for the application
startup will be delayed.
If you have multiple
indexables, as
in the case of apps
with multiple Slices,
pass in all the
indexables together,
as we show in the code example.
And also make sure to
test your indexables.
If one indexable is invalid, the
entire update call will fail.
So here is a small code
snippet that shows it--
how to pass multiple indexables
to the Firebase App Indexing
API.
So now that you built your
Slice, how do you test it?
Use the Slice viewer
debug APK to view
how your Slice appears in UI.
That's all we had for
the talk for today.
We would like to
give a shout out
to all developers in the
Slices early access program.
Thanks for attending, and have
a fun rest of the session.
[APPLAUSE]
[MUSIC PLAYING]
