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