Tip:
Highlight text to annotate it
X
ROMAN NURIK: Hello, and welcome once again to Android
Design & Action.
I'm your host, Roman Nurik.
ADAM KOCH: Hey, guys.
My name's Adam Koch.
And today, we have a special guest joining from London.
NICK BUTCHER: Hey, I'm Nick Butcher.
It's good to be here in person shooting a show, rather than
just a little head across the Atlantic.
ROMAN NURIK: So today's episode is about the
onboarding experience, basically, everything from the
point in which the user, you know, downloads, maybe finds
your app in the Play Store, installs it, and then
starts using it.
So basically, just those kind of initial crucial few moments
between the point in which they install,
and they start running.
We're going to talk about ways to make that optimal, at least
as optimal as possible.
NICK BUTCHER: The old saying, you only get one chance to
make a first impression.
This is what this show is all about.
ROMAN NURIK: Exactly, exactly.
So with that, let's jump into the slides.
NICK BUTCHER: And I'm particularly proud about this
title card we have for onboarding.
Onboarding, get it?
ROMAN NURIK: Yeah, like a snowboard, boarding, you're on
a board, yeah.
[LAUGHS]
NICK BUTCHER: Thanks very much.
It's my contribution.
ROMAN NURIK: [LAUGHS]
So let's get in here.
So the first thing we wanted to talk about is that last
week or, I guess, two weeks ago, we did an episode on our
top 10 anti-patterns or common UX issues that
we saw during review.
And number two, basically one removed from the last one, was
a poor onboarding user experience.
And that included a couple things, requiring registration
up front, using splash screens.
We're going to talk about all the details here.
But we wanted to spend an entire Android Design & Action
episode just talking about this,
because it's so, so crucial.
So the first thing is about splash screens.
Adam, you want to talk about splash screens?
ADAM KOCH: Yeah.
So as you mentioned the other week, don't show them.
[LAUGHTER]
ADAM KOCH: Let's remember our sort of content first
principles here.
A splash screen is really not content, it's just another
roadblock, another hurdle in the way to the user getting to
your application and the actual content in your
application.
Now, of course, some people say, well, I really want to
make sure my brand is recognized, that the user
knows my brand.
Well, in Android, we still think brand is very
important, of course.
But you can use the action bar icon and, of course, theming
and selecting that accent color to really show off your
brand instead.
And as you see here and in the screenshots, Google Play is a
pretty good example of using that icon and this sort of
accent color to really show off the different silos within
the different Google Play Store.
ROMAN NURIK: And I know a bunch of people might think,
well, a lot of people think, that splash screens are
important for when you have, you know, content that you
need to load before you show your UI.
And I'd say my rebuttal to that is you don't necessarily
need to block the entire UI, right?
There's probably something that you can show of value.
At least show the top-level navigation of your app.
You know, you can always show a loading spinner or a really
friendly loading spinner, something that involves your
brand even.
It doesn't have to be the built-in loading spinner.
You can show that in place where content will show up.
You don't necessarily need to block everything and have the
user sit there patiently waiting, just looking at your
pretty logo before actually showing your UI.
It's actually a good chance to let them start exploring and
learning about the different sections in the app rather
than, you know, just showing them nothing.
ADAM KOCH: Yeah, even if the content isn't there, maybe
they can open the drawer, see what's available there.
Maybe they can go to Settings and see what
settings are available.
They can do other things, potentially, in the
application.
ROMAN NURIK: Yep.
OK.
NICK BUTCHER: And I think the worst offenders on the splash
screens are the splash screens which decide to go full, full
screen and completely hide away the status bar.
That's a double--
don't do it.
ROMAN NURIK: Yeah.
ADAM KOCH: Or the ones that are playing sound or
music in the front.
Argh.
[LAUGHTER]
ROMAN NURIK: Yes, exactly.
Actually, one of my favorites is you have this splash screen
up, and then you press back or press home or something,
because you just don't want to use the app anymore.
And then, you know, the splash screen
lasts for three seconds.
But then you press back and, three seconds later, the
actual next screen just shows up randomly because the splash
screen hasn't recognized that you've backed out of it.
So it's just that there are so many things that can go wrong
with splash screens, and they're just a very poor user
experience.
Just don't use them at all.
All right.
NICK BUTCHER: I think we've covered that.
[LAUGHTER]
ROMAN NURIK: Yeah, I think we've beaten that dead horse,
or whatever.
I'm really bad at idioms.
[LAUGHTER]
ROMAN NURIK: All right, anyway.
Let's move on.
So the next thing we wanted to cover is tutorials.
So we're going to spend some time talking about a couple of
main parts to onboarding.
The first will be tutorials, then we'll
talk about login flow.
Finally, I think we'll talk about onscreen overlays.
So for tutorials, one thing, before we jump into all the
details, we do want to mention is that there is pretty good
coverage of a lot of these things in the
Android Design Guide.
So if you visit this link here, you'll see the specifics
on when and when not to show unsolicited help.
So tutorials are one of those examples of unsolicited help,
basically help that you're kind of pushing to the user
without them actively requesting it.
So we very clearly kind of advice against it.
You know, they're interruptions, they're usually
not necessary, and so on.
And so generally, this is something that's covered in
our guidelines.
But besides that, we wanted to kind of add additional color,
I guess, to some of these guidelines and kind of explain
some of the reasoning for them.
So one of the first things you should think about is there's
a couple types of tutorials, right?
There's speedbump tutorials, mandatory tutorials that you
need to kind of go through before you get into the app.
And we'll talk about that in a second.
That's the type of thing that you shouldn't do.
And the reason that you shouldn't do them is,
generally, that it's a sign that you actually may need to
simplify your app.
Maybe there's too much going on.
Maybe your app is just not simple enough.
So certainly, its generally a bad sign if you think you need
a pretty complex onboarding flow.
Some ways around using the speed bump tutorial style is
using something like what Google Play
Movies is doing here.
And it's still, you know, communicating value.
It's still, I guess, expressing the value
proposition of the app, but it's doing so in a very direct
and contextual way.
So info cards is one of the things that
Google Play Movies features--
it's one of the features that they have.
Basically, you know, when you're watching a movie, you
press pause, you actually see information about the
character onscreen.
But the idea here is that we could have thrown up a
tutorial that forces you to go through it,
but we didn't here.
So the idea here was that once you get to the point at which
this starts to become interesting, like the user may
start caring about this at this point, we actually show
this card or this tutorial card.
And they can obviously very easily dismiss it, or they can
just ignore it.
You know, if they just start scrolling down, they'll see
their content.
So it's very passive.
It's not super obtrusive.
But it does communicate the value, and it does it in a
contextual way.
If I was in a different section of the app, perhaps it
would show me a different kind of hint that
there's a feature there.
NICK BUTCHER: I think the key to this kind of goods
tutorial, if you will, is it's non-blocking.
I think anything which is blocking, especially mobile
dialogues-- one of my personal pet peeves--
anything that's you saying to user, hey, I know better than
you what you need to be doing now, is kind of aggressive.
And it kind of breaks any flow or any task they're trying to
accomplish.
So I think, while this is still unsolicited help, I
guess, it doesn't have that blocking feature, which makes
it so much better.
ROMAN NURIK: Yeah.
So just to specifically talk about speedbump style
tutorials, these are the kind of tutorials where-- you see
here an example--
you basically flip through a couple of pages, and maybe at
the end there's a sign-up for something.
But basically, this is not the app.
This is a separate flow before you get to the actual app that
is mandatory.
So this is definitely something that
you should try to--
NICK BUTCHER: I wonder how many of these screens people
actually even read, how many just see this--
ROMAN NURIK: Yeah, swipe, swipe, swipe.
[LAUGHS]
NICK BUTCHER: --and immediately try and home in
on, how do I get past this, and just mash that button.
ROMAN NURIK: Yeah.
And actually, I will say that we should probably admit at
this point that one of our reference apps, the Google I/O
app, has a speedbump.
Not a tutorial, but it's a different onboarding flow.
And it's definitely something we should try to address for
the next release.
But here, you know, some of the things that you should
think about.
If you absolutely have to do something like this, if
management sends down the word that you must have this kind
of tutorial flow, definitely allow immediately skipping.
So don't force the user to go next, next, next, next, next,
and then get started.
So give them the option to skip right away.
Also, and Nick will talk about this in depth later, but if
you're going through a couple screens that tell you about
the app, and then at the very end, you have to kind of make
decisions, like sign up or register or whatever, that's
just another way to stop the funnel of
engagement with your app.
So definitely try to avoid these kinds
of speedbump tutorials.
All right, I think we've talked about speedbump
tutorials quite a bit.
But there's a couple of other tutorial type things you can
do to educate users about your app, to communicate the value
proposition.
The first, and this is very obvious, very simple, is doing
so via your Google Play listing.
A lot of the features that are available in the developer
console are there so that you can kind of have a
conversation with your users at the perfect time, right
before they install, right before they
start using your app.
So things like the product video.
That's very important.
Google Keep is actually a really good example.
When you press Play here, this actually has a pretty high
level of prominence on the page, so it draws your
attention to this.
This video, you start pressing play.
And the video that Google Keep has provided has
a very strong narrative.
It actually walks you through, kind of, one flow, one user
using the app.
It actually talks about the features, but you actually see
the person interacting with the UI.
So actually, it's a nice way to kind of imagine yourself in
their shoes.
You can kind of fill in the gaps.
This is how I would probably use the app.
And then, obviously, screenshots.
The screenshots are a really good way to communicate what
your app does, especially if your UI design is very good
and very clear.
You can immediately kind of understand what the app does
and how it works just by looking at the screenshot.
NICK BUTCHER: One thing I would say on the screenshots
as well is be careful of the order you put them in.
Quite often, I'll see screenshots uploaded for
application, and it seems like they're in the order in which
you might go through the application.
So in some apps I've even seen a splash screen uploaded as
the first screenshot.
And then a login screen.
And then, maybe further down the line, perhaps once you're
into the actual content within the application.
And that's a real shame, because as you can see here on
the screenshot from the web, there's only
room for one or two.
And this is even more exaggerated
when you're on a device.
So you'll probably see the video and maybe one
screenshot, perhaps half of the second one coming in here.
So you really want to be sharing your hero moments, the
thing that really, clearly expresses what this
application is all about first, and then forget about
these other ancillary screens.
ROMAN NURIK: For sure.
ADAM KOCH: And of course showing screenshots for
different form factors.
ROMAN NURIK: Yes.
ADAM KOCH: And don't forget to do that as well.
ROMAN NURIK: Yeah, because, you know, if I'm on a device,
if I'm on a 10 inch tablet, I want to see what it's going to
look like on my device.
ADAM KOCH: Mhm.
NICK BUTCHER: Mhm.
ROMAN NURIK: If I'm on a four inch phone, I want to see
exactly what it's going to look like on a phone.
All right, moving on.
Another way to communicate, again, your value proposition
or educate your users, give them a tutorial about your
content, is through the empty state.
And this is actually one of my favorites, not because this is
specifically my app, but this is one of my favorite
opportunity moments, in the empty states.
So you know, most apps these days have
collections of things.
You know, they have screens where there's collections of
things, collections of movies, collections of, in this case,
extensions for a, clock.
There's lots of different lists.
Too often we see developers missing the opportunity of
that empty state.
When there's nothing in that list, use that as the
opportunity to talk to your user.
Tell them how to add things to that list, why they should add
things to that list, actually put buttons in there in that
empty state that will let them take action.
Fix the problem of the empty state.
Generally, people don't want an empty state.
They want it to be populated, right?
So one of the ways in which you can do that is you can
just simply use that empty state for all sorts of things.
In this example, this is the DashClock app that I wrote.
Before you add any extensions, you get greeted with this
screen here.
And then, you can press this button to add an extension.
As soon as you add something, you kind of start seeing the
full populated list.
And it's very easy to do from a development standpoint.
You basically just provide an empty view for the list.
NICK BUTCHER: Yeah.
Quite commonly, you might imagine-- well, quite often I
see screens which might be like this on the left, but
it's just empty screen with maybe a small plus in the
action bar.
And it's such a missed opportunity.
ROMAN NURIK: Right, yeah.
One thing I will say here is that there's just a bit too
much text here.
Probably just be very visual, not really immersive, but just
be very visual on this screen if possible.
Here, I kind of didn't do that.
Anyway.
So let's move on to the next screen.
Another important way to communicate your value
proposition, to explain to users how to use your app, is
to pre-populate it with, how you like to say, bootstrapped
content, right?
So this is an example from Michael Pardo.
It's an app called Quotes and gives you your
stock quotes, obviously.
And so one way he could have designed this app is that when
you first install it, and you open it up, it just has no
quotes in there, right?
It's a blank list.
And it doesn't show you any interesting data.
Maybe it just shows you the S&P index or whatever.
But what he decided to do here is he decided to actually
pre-populate your portfolio with a couple of
common stocks here.
They have a CAKE.
I'm not sure if that's like Cheesecake Factory.
PIZZA, which is probably one of the delivery services.
And so you kind of immediately see the value of the app.
You immediately see the data you're working with.
You know, obviously, you can very quickly remove them.
You just long press, select them all, and just remove.
Or you can just add to it.
But it's actually just a very nice, simple way to just
immediately get started.
So I think that was it for tutorials.
Any parting words on tutorials before we move on, guys?
NICK BUTCHER: No, I think that's covered it.
ADAM KOCH: Yeah.
ROMAN NURIK: All righty.
[LAUGHTER]
ROMAN NURIK: Let's do it.
Nick, take it away for login registration.
NICK BUTCHER: Yes.
This is one of my pet peeves, the login experience and
registration.
So the first thing, let's say, for a login is that you should
really be delaying it until it's kind
of absolutely necessary.
Just like those speedbump tutorials that we looked at
earlier, it's another thing to do when you already kind of
quite cognitively loaded.
The first time you run an application, there's a lot
going on, right?
You're kind of getting used to it, you know, the way it looks
and feels, the way the navigation is laid out.
You're understanding what the app is doing.
And if you're throwing on all these extra layers of stuff,
then it's just a lot for the ease of the process.
So by far and away, I'd say delay it until
the last moment possible.
And the second point I wanted to make here is people are
probably more likely to actually complete the login if
they can clearly understand why it's necessary.
So an example of this, a great example of this I was showing
here, is the Tumblr application.
So when you install Tumblr, you get the opportunity to log
on, but you don't have to.
You can immediately start using the application.
You can explore different Tumblr blogs, and you can
actually take kind of logged-in type actions.
So for example, here I haven't actually logged into the
application, but I've already been able to go through and
start following people.
And if I were to then decide to log in and sign up, it
would then take all those actions which I've already
done and just merge them into the account I've just created.
So it's a truly wonderful example.
And in this example here as well.
So if once I've followed a blog, if I try to do any
actions that obviously requires login, so if I tried
to like it or comment on something, at that point, it
then says, hey, you need to be logged in to do this.
And I can clearly understand why.
It's demonstrated it's value to me already, and I'm much
more likely, I think, to complete it.
ROMAN NURIK: It's kind of like an inherent--
it's a very contextual almost direct manipulation in the
sense that it's very clear that when I'm pressing this
and I see a sign in dialogue, the reason to sign is because
this won't work without that.
NICK BUTCHER: Right.
ROMAN NURIK: Whereas, if you were to ask somebody to sign
in in the very beginning as part of that tutorial flow,
there's no expression of value, right?
It's not clear.
It's very indirect, if it's even there at all.
NICK BUTCHER: Right.
Absolutely.
OK.
And the next step is when you do go on to provide logon.
Logging on can be kind of a painful experience.
It often involves data entry, which
isn't always the easiest.
And it's often a pain for you as well, having to kind of
manage and secure passwords and so on and so forth.
So an alternative might be to consider using some of the
common logon providers.
People are likely to have a bunch of accounts on their
device already.
So you might have a Google account, a Facebook account,
Twitter account, some of these common providers.
And they offer much faster and easier logon services.
Yeah, we're particularly a fan of the Google+ logon, because
most Android users, well, every Android user has a Gmail
account to sign in to the Play Store.
So there's a good chance they'll be able
to log in with that.
ROMAN NURIK: And another thing is, you know, even with
Facebook, right-- a lot of users have Facebook installed.
When you use their SDK rather than using a separate,
web-based flow, when you use the SDK, you actually benefit
from the user's account already on the device.
You don't even have to actually type in your Facebook
user name and password or Facebook email and password.
You basically touch it.
It knows that you already logged in.
It asks you to confirm and so on.
And obviously, with Google+, it's the same way.
It's actually--
NICK BUTCHER: Pretty seamless.
ROMAN NURIK: Yeah, it's very, very, seamless.
Very much worth it.
NICK BUTCHER: Definitely.
Oh yeah, one point we wanted to make on that is to include
an email alternative.
Some people just aren't that comfortable.
You know, they perhaps might be worried, is this going to
publish stuff my timeline, and so forth.
And some people are just adverse to it.
So you know, while we definitely recommend this as a
great way to go, we would definitely say include an
alternative.
ROMAN NURIK: Yep.
NICK BUTCHER: All right.
And as an aside while we're talking about login, one of my
favorite things is when you actually remove the need to
log in altogether.
And that's offered quite neatly, I think, by Google+,
And so if you choose to go down that route and you
already have a popular web property, if the user signs in
on the web properties in the same Google+ account, it'll
actually pop and offer them, hey, would you like to install
the Android app at the same time?
So it's a great, great discovery mechanism.
But simply, the greatest thing is that the user will be
automatically logged in already in the Android app.
So you skip the need for this altogether.
Fantastic.
ROMAN NURIK: Yeah, it's one of the best ways to remove
friction, right?
NICK BUTCHER: Mhm.
ROMAN NURIK: That's probably what, you know, the business
folks are always thinking about.
It's always about the funnel, right?
How do we maximize the funnel?
NICK BUTCHER: Exactly.
ROMAN NURIK: How do we minimize the
roadblocks in the funnel?
And this is one of the best ways to do that.
NICK BUTCHER: Cool.
So that's particularly fun.
So on from login, we're talking about the
registration steps.
So I want to say here do offer to sign up on device.
I find it quite frustrating when an application hasn't
implemented a registration step, so it kind of boots me
out to a web view or something like that, which might have
worse data entry and form filling capabilities.
So I definitely urge you to include it within your
application.
But try to make it as painless as possible.
So as we were saying, data entry on mobile devices isn't
always the most fun experience, especially at this
critical time when you're trying to get someone to sign
up for your service.
Yeah, think of that funnel.
So you want to keep it as painless as possible.
So here's a kind of concocted example, which is kind of
trying to prove the point like--
[LAUGHTER]
ADAM KOCH: Social security number?
NICK BUTCHER: Yeah, make it as simple as possible.
Don't ask someone to enter an email address on the phone and
then confirm it.
I mean, that's pretty painful, right?
And some other step.
So I'm going to walk you through some improvements to
this screen here.
So the first thing I'd say is to remove repetitive or
nonessential fields here.
So already, this screen is starting to look a little bit
better if we got rid of having to repeat both your email and
password and some extra information, which might not
be completely essential to sign up.
And you can maybe prompt for it later on when they
understand the value proposition of that or on a
different kind of meeting.
So already, this is starting to look a little bit better.
The next step, one of my personal favorites, here is to
suggest an email if the user starts filling it in.
So your Android device knows a lot about you.
He already knows the email addresses, maybe some user
names that you've entered.
So once the user starts typing-- or you could offer
this as a pick from list if you want, then do suggest.
One thing to be wary of--
I've seen some implementations of this where they just see if
there's already an email address on the device, and
then they just prefill it.
But they don't let you pick, which isn't great for users
who have more than one account on the device.
So definitely let them switch between multiple accounts if
they have that.
But yeah, already, this has gotten so much easier.
Just with a couple of key taps, I can just pick from
this list here.
ROMAN NURIK: And one of the questions that, actually, we
discussed earlier was, how do you actually show this list?
Right?
NICK BUTCHER: Mhm.
ROMAN NURIK: Do you show an additional affordance to pick?
NICK BUTCHER: Mhm.
ROMAN NURIK: And certainly, if you use the Google Play
Services SDK, there's actually something called an account
picker that's a dialogue that pops up.
And that actually doesn't require any permissions.
And so if you wanted to show the account picker dialogue,
you could have an additional button next to this field,
rather than a drop down.
But if you do decide to go for a drop down, which is also
very nice, the way I'd probably do this is, as soon
as the text field is focused, drop down the list.
And then, as it loses focus, collapse that list.
As an alternative, you could have a conditional kind of
spinner type affordance on the side that pops up the list.
But generally, it's probably best to just show the list
immediately.
And I think that's maybe how the autocomplete stuff works
by default, but I'm not quite sure.
NICK BUTCHER: Great, cool.
Another side note we've added here is to prefer email to
user names.
I don't know about you, but I just find when I'm forced to
pick a username rather than just use my email address it's
just another thing I'm not going to remember.
ROMAN NURIK: Right.
NICK BUTCHER: Whereas, it all comes back to email at the end
of the day anyway, so you can reset it and so forth.
ROMAN NURIK: Mhm.
The worst is when there's a service where the username is
your email, and it says username.
Just say email.
Just ask for the person's email.
NICK BUTCHER: Absolutely.
And yeah, it works really, really well on Android,
because you're able to create a device for [INAUDIBLE]
as well.
So there we go.
So next up, passwords.
So we've said here, make it optional.
So you can just not require users to enter a password.
You could do something like auto-generating one, prefill
it in, and let them cycle it or something like that.
You could just say it's optional.
Some users will want to set it, some users might not.
But my preferred option would be just to probably omit it
altogether.
I mean, I'm probably going to enter something very weak or
very quick anyway.
I'd rather just, it's in the background.
It's generated, saying super secure or something like that.
And I can always just hit the Forgot Password or Reset
button, should I really, you know, want to get access to
that password or if I've forgotten it somehow.
ADAM KOCH: And maybe later, when you're on your desktop,
when you have a real keyboard, you can get that email and
actually fill out a real password or
something like that.
ROMAN NURIK: Yeah, you get the email like, click here to
actually set a password, or something like that.
NICK BUTCHER: So thinking back to that kind of final analogy
of how many people are going to get through this step.
If think back to that first screen with all those fields
and so on, rather than just one, which is going to help me
fill in the only field anyway by suggesting something and a
button to hit sign up, you've got to imagine that the funnel
is a lot better than this.
ROMAN NURIK: One thing I want to add is with passwords.
One of my biggest pet peeves is when there are passwords
that require symbols and capital letters
and all this stuff.
And generally, it's a bad practice.
But a lot of people use the same type of
password or the same--
it might even be a strong password.
It may be very long.
But you know, people like to use similar passwords, and
when you ask them to start introducing symbols and all
these arbitrary constraints, it actually makes them forget
their password.
I mean, I don't know how many times--
I mean, it's a bank password.
But some of my bank passwords, I mean, I've probably had to
reset them a bunch of times, or my account for cable or
something like that.
Generally, try to enforce it maybe on minimum size but not
so much on symbols.
And there's actually a really funny XKCD about arbitrary
password restrictions.
Basically, I think the result was if you have a very long
string of just regular words like, hello there, my name is
John, or something and if they're completely random
words with no symbols, no anything, the entropy of that
is actually a lot higher than a very short password, let's
say eight characters long, with a whole bunch
of symbols and stuff.
You know, think about that before you require people to
use to provide symbols.
NICK BUTCHER: I think, generally, just don't get into
the game of holding passwords if you can.
I think these social providers, you know, Facebook,
Google, Twitter, spend a lot of time and money and thought
and engineering into keeping things like this secure.
And if you have the option of not doing that, that's pretty
attractive, I think.
You don't want to be the one who loses someone's database
of passwords or something.
ROMAN NURIK: Right, exactly.
NICK BUTCHER: Oh, and one other note, a tiny one here,
is that you can also help the user out by replacing where
the enter key would normally be on the keyboard with some
kind of text which is contextual
to what you're doing.
So you know, you quite program to type and then hit Next or
whatever that button is.
And if that actually does something, and when the user
hits that and it's the same as hitting the onscreen sign up
button, it's just another tiny thing that will help the user
to complete this flow easier.
ROMAN NURIK: Yep.
ADAM KOCH: Yeah, I guess similar to that as well, in
case there are other fields that you need to click, like
maybe a phone number, you can set the data type on that
field appropriately so the keyboard adjusts itself to
sort of optimize for that field.
ROMAN NURIK: Mhm.
You'll actually notice that here this is
an email type field.
So you automatically get the at sign and the dot sign.
NICK BUTCHER: And there's other fields.
We talked about email quite a lot, that you
can query the device.
All right, I mean there are other fields you can query for
for, I think, Ice Cream Sandwich and beyond.
The device has a concept of the user's profile.
So with their permission, you can ask for their first name,
last name--
ROMAN NURIK: And their avatar photo.
NICK BUTCHER: Yeah, avatar to photo.
You can also get telephone number--
ADAM KOCH: Mhm.
NICK BUTCHER: --if you're on a phone type device.
So each of these will cost you a permission, but it depends
if it's critical to your--
ADAM KOCH: How important it is, yeah.
NICK BUTCHER: Then that might ease and increase sign ups.
ROMAN NURIK: All right, shall we move
on to onscreen overlays?
ADAM KOCH: Yeah, sure, let's do it.
So this is pretty quick, but onscreen overlays.
So the general rule of thumb here is avoid them.
[LAUGHTER]
NICK BUTCHER: I think I've seen enough with those kind of
hand-drawn styled arrows coming out.
ROMAN NURIK: Yeah.
ADAM KOCH: Yeah.
Yeah, exactly.
In particular, you know, you should avoid them for common
UI patterns.
So we're talking action bar.
You really don't need to tell the user how to use these
things again.
Yeah, the other thing we mentioned here was the
navigation drawer.
And I don't think we mentioned this yet, but there's actually
a recommended pattern for the navigation drawer.
When the user first loads the app, you can actually open
that navigation drawer for them, just for
discoverability, almost like a tutorial in itself.
NICK BUTCHER: Animate to open a drawer, because that teaches
the gesture.
ADAM KOCH: Exactly.
And then, the first time they actually go and use the
drawer, they close it or open it themselves.
You can set a flag there, and then you don't need to open it
again on future times they open the application.
So you really don't need an onscreen overlay to sort of
help the user discover that Droid can use
another method like that.
ROMAN NURIK: And generally, users are learning things like
the drawer, like the action bar overflow, by using apps
like Gmail, like Google Keep, like Google Drive.
You know, a lot of these apps come pre-installed on their
devices before they ever install your app.
So they're learning these patterns.
There's no need to really kind of educate them further about
patterns they probably already know.
ADAM KOCH: Mhm.
When it comes to help, you know, the perfect place for
that is the overflow menu.
And I think earlier, Roman had a link to the Design
Guidelines, which sort of goes into a bit more detail on how
help should be structured within your application.
ROMAN NURIK: Yeah, it's basically like the difference
between unsolicited help and solicited help.
ADAM KOCH: Mhm.
Users crying out for help.
ROMAN NURIK: Right.
ADAM KOCH: They're going to go to the overflow and find what
they need there.
There are some times where it's appropriate to have
onscreen overlays though.
So custom gestures like sort of very specific gestures to
your application that are just very custom an interesting and
different to other applications, it can be
appropriate.
And a really good example of that here that we have in the
screenshot is the YouTube application.
And so in one of the more recent updates, that YouTube
application actually allows you to basically continue to
browse YouTube while minimizing the current video
that's playing.
And so in the bottom right there, that video would be
playing right now.
And the first time that you see this in the new YouTube
application, it gives you this little overlay so that you can
sort of understand the gestures that you can apply to
that particular video.
So swiping there to the left dismisses the video, and
swiping up actually maximizes the video back into sort of
the fullscreen view.
ROMAN NURIK: Mhm, yep.
ADAM KOCH: So I think this is a really
good use of an overlay.
ROMAN NURIK: Yep.
NICK BUTCHER: OK, so I think that's all we have this week
on the onboarding experience.
So thanks very much for joining us.
And as always, I'm your host, Nick Butcher.
ROMAN NURIK: Roman Nurik.
ADAM KOCH: Adam Koch.
See you, guys.