Tip:
Highlight text to annotate it
X
NAZMUL IDRIS: Welcome to this episode of UXD,
where we will show you three steps
to make your mobile applications awesome.
In this episode, we're going to be covering the first step.
I'm your host, Nazmul Idris, a developer advocate
on the Android team.
And I have a very special guest with me today.
PATRICK LARVIE: Thank you, Nazmul.
My name is Patrick Larvie.
I'm a researcher here at Google.
And I have a lot to say about mobile.
NAZMUL IDRIS: Ha.
You've come to the right show.
The first thing as a developer that you
need to understand about delivering a good user
experience, that it's always about the user
and never about your application.
So how many times have you seen applications
demand to be updated?
Demand to be rated?
Demand new forms of payment?
And demand your attention for a variety of reasons?
Now if you have a valid business need to push out a new feature
or collect feedback from users, you especially
need to be mindful of the demands you're
making on your user's attention.
So Patrick, what is the right way
to demand attention from the user?
PATRICK LARVIE: Well, this is a really good question.
And nothing substitutes for a good subtle knowledge
about how users are interacting with your apps.
So if you haven't done a little user research,
I would suggest that you go do some
before you tackle the step.
But I think, first of all there's
a distinction that we really need to make.
There are times when you absolutely
need your user's attention.
Maybe you have an update.
Maybe there's something that's absolutely
critical about continued use of the app.
You need their attention.
There are other times when you just
want your user's attention.
It's really important to distinguish these two.
Because you don't want to wear out your welcome.
You don't want to be that app that's constantly
making demands on your user, whether you need it or you just
want it.
NAZMUL IDRIS: That makes sense.
PATRICK LARVIE: Think about it.
If your app-- it's just like the story
of the boy who cried wolf.
If you have an app and you're constantly
alerting your user about things like,
were you aware of this new feature?
Are you aware that we have a new payment option?
Are you aware that we have some new colors for your fonts?
NAZMUL IDRIS: Right.
PATRICK LARVIE: The time when you need that user's attention
because there's an update, there's a mission
critical update, that user is going to ignore you.
NAZMUL IDRIS: That makes sense.
So what are some things that developers
need to keep in mind when they're
asking their users to pay attention?
PATRICK LARVIE: Well, first of all,
let's share some examples about wanting versus needing.
And I think the first thing is it's really important
to imagine that your app doesn't just
rely on the phone's battery.
It doesn't just rely on the network connection.
It doesn't just rely on the computing
capacity of that device.
It also relies on another finite resource,
which is your user's attention.
Let's say that the app has just gone through an update.
And that update is available to be released.
Let's say, in fact, that you the most awesome pizza ordering
app in the world.
I am a big fan of that pizza app,
because that delivers the best pizza every time.
Think about this.
If you have an update, it's something critical.
Let's say that you're going to release a new feature that
allows the use of text message to communicate between driver
and the person ordering the pizza in order
to make sure that delivery occurs on time.
But this requires a new consent from the user
because the user has to say yes, I give you consent.
I consent to the use of the text messaging app.
Think about this.
When is the best time to direct that user to the Play Store
to update that app and to provide a new consent?
Is it when they're ordering pizza?
NAZMUL IDRIS: Probably not.
PATRICK LARVIE: Probably not.
The goal here is to turn a demand-- I must have consent
in order to roll out this new feature-- into an invitation.
NAZMUL IDRIS: No, that makes sense.
That makes sense.
So you might want to provide users
that have older versions of your application
with a message inside of the application that
tells them there's a new version that's coming
and what benefits they're going to get when they upgrade.
Like in this case, the SMS feature.
So another thing you might do is that if you have their email
address, you might consider sending them
a short targeted message.
And again, only to folks that are
using the old versions of your application.
Again, to give them a reason for why they need to upgrade
and the benefits they're going to have when they actually
perform the upgrade.
PATRICK LARVIE: That's right.
You want to avoid the situation where the person discovers
a need for a critical update at the moment when I'm really,
really hungry and I want that pizza.
That's not the moment.
Another limited resource to take into consideration.
As we all know, mobile devices can only operate for so long
before they need to be recharged.
NAZMUL IDRIS: Exactly.
PATRICK LARVIE: Again, we think of this as a constraint.
But I think app developers should
think of this as an opportunity.
Because this provides you with an opportunity
to delight your user.
And it's an opportunity to think about how
awareness of the phone's limitations
can be a way that you can work with your user,
rather than against your user's device.
NAZMUL IDRIS: That makes sense.
And again, speaking of finite resources,
battery power is not the only one.
But there's also network bandwidth.
There's network availability.
The amount of memory in the machine, CPU utilization.
And also outside of the machine, the user's attention.
PATRICK LARVIE: That's right.
I think it's really important to be aware of the device's state
at moments when this is critical to your app.
For example, let's say you are an app developer with the most
awesome cat video app ever.
You know that your user is queuing up some awesome cat
apps to watch.
But you're also aware that user's battery is down
to about 20%.
This is actually an opportunity.
It sounds like this is going to be a disaster for your app,
right?
No.
This is a moment when you might engage your user in say,
you know, at the current rate you're going,
this is only going to go on for about five minutes.
Might we switch to a lower resolution?
Might we queue this for later?
There are lots of ways that the app developer can
say, all right, I'm aware of the limitation of this device.
I'm going to turn this into an opportunity for my user
to reengage rather than being the app that's
on when the device crashes.
NAZMUL IDRIS: That makes sense.
And as we know, the internet was invented
to share cat pictures and videos.
PATRICK LARVIE: Yes.
NAZMUL IDRIS: So now in addition to battery, another thing--
actually, while we're talking about battery.
One of the biggest drains on batteries is GPS.
And I think it's important for developers to keep in mind
when they should ask for high resolution readings that
consume a lot of battery life versus when they can do
with coarse readings that don't require a lot of battery life.
So for example, in that pizza ordering application
you mentioned, it might be appropriate
at different moments in time in the user interaction
for that pizza ordering application
to ask for really high resolution,
location information from the GPS.
Which might drain battery, but it'll
be for a short period of time.
But for 90% of the time or even longer
when the application is just sitting,
and you haven't ordered a pizza.
There is absolutely no reason for that thing
to constantly ask for high resolution location
updates, which will actually drain battery.
PATRICK LARVIE: That's absolutely right.
Again, you don't want to be the app that users remember
as the one that crashed their device, as the one that
drained their memory.
And what Nazmul is saying makes absolute sense.
Nothing irritates me more than when
I see my GPS turn on for absolutely no reason when
I have 5% battery left.
NAZMUL IDRIS: Exactly.
PATRICK LARVIE: Remember, you want
to look for opportunities to delight your user.
You also want to look for opportunities
to avoid the situation where your app is involved in a crash
or in a critical incident.
Because it doesn't matter if the user was only watching your cat
video app for five minutes before their device
turned off because it didn't have any more battery.
NAZMUL IDRIS: Right.
PATRICK LARVIE: The user is going
to remember that app forever as the one that
drained my battery.
NAZMUL IDRIS: Yeah, exactly.
And even if it was, let's say, that pizza ordering application
that was at fault.
But because the user perceived that the cat video application
was the one that was running when the battery went down,
that's all they're going to associate
with that negative event.
And negative events stick with us
much more than positive events.
PATRICK LARVIE: That's right.
Here's a slightly different take on this topic.
There are times-- and this is a want.
There are times when you want to get feedback from your users
on how they like your app, or how the app is performing,
or things that they think your app could do to be better.
Resist the temptation to ask your user to rate,
share, like, or otherwise comment
on the app at critical moments.
Let's go back to the pizza app for a moment.
Let's say that you know that that user habitually
selects pizzas, orders pizzas, chooses favorite pizzas,
and has them delivered.
What's the right time, what's the seducible moment
in the usage life cycle to reach out to that user?
Is it while he's ordering the pizza?
Is it while he's waiting for that pizza to be delivered?
Is it while he's eating the pizza?
No.
This is, again, an opportunity to turn
a demand-- you need good ratings.
You need feedback.
But you want to turn that demand into an invitation.
You know when that pizza was delivered.
I would say starting about 60 minutes post-delivery, that
might be a decent time to ask.
NAZMUL IDRIS: That makes sense.
So in addition to the three issues we talked about, here
are some more best practices for developers to think about
when they're actually building their applications.
So coming back to this issue of updates.
Let's say that you have updated your application,
like that pizza ordering app, and you more permissions.
But also as you've updated the new version,
there's some changes you've made to the back end.
And you need to basically move users off of the old back end
into the new back end.
So it's critical in this situation
to actually make sure everybody has migrated first
before you turn off the old web services that you have running.
And that is actually something developers, or some application
developers, don't take into account,
which leads to a pretty bad user experience.
So when users of the older applications
go to actually run them, they just
stop working, which is pretty awful.
And so you have to keep in mind that it takes time for updates
to reach all the users of your application.
So make sure that you're checking
to see how many times your old web services are being used,
and so on, before you actually decided to turn them off.
So another thing you might want to do
if it's a really critical upgrade
and you can't really wait, consider actually
giving them an explicit notification.
And this way, at the very least, when they need it,
they won't be surprised that it's not working anymore,
because you've actually done the work
and you've actually notified them ahead of time
that they do need to perform this update.
PATRICK LARVIE: And this is also an important topic
for developers to remember, because notifications
can be super helpful.
There are lots of opportunities to inform and to engage
your users through notifications.
But it's equally important that you
don't have to turn everything into a notification.
So let's say you've done your research.
You know how your users are engaging
with your pizza delivery app.
And you know how to time that.
There are good ways and less good ways
to reach out for the rating or for some feedback.
You know that you've done it.
The users had the pizza, and the pizza's been delivered.
It's about 60 minutes.
That's the right time to reach out to them.
That may also be the right time to give them
other notifications related to, for example,
changes in payment.
It might be an opportunity for other kinds
of noncritical-- changes in payment options, changes
in selection of pizzas.
Other kinds of noncritical things,
you might consider batching these intelligently
and delivering them at a time you know that the user is
in a state of mind to pay attention to them.
NAZMUL IDRIS: That makes a lot of sense.
So I guess the most important thing
is that the timing is critical and that understanding
the difference between what is engagement
and what is an interruption.
So like in this situation, if for example, I
need to rate my pizza, like how the delivery was.
It's not that the feature is a bad thing.
I do need that feedback.
But the presentation and the timing
of when that feature is surfaced in the user experience
determines whether the user actually is delighted by it
or is actually is somewhat annoyed by it.
PATRICK LARVIE: Right.
We can take an example of a notification that
can be either an interruption or an opportunity
to engage depending on its timing.
Pizza app.
Let's say something fundamental is
changing with that pizza app.
It's going to use text messages to help locate where I am
and to communicate with the driver.
This is a fundamental feature change.
It requires the consent.
If I receive an email about that,
and I know that before I go to order my next pizza,
that's an opportunity to engage your user and say,
hey, I know why you're asking for consent.
I know that this benefits me.
Awesome.
I can't wait to order another pizza.
If I find out that I have to update the app
and provide consent as I'm ordering a pizza,
that's now an interruption.
Very same notification.
Context determines whether that's
an interruption or an invitation to engage.
NAZMUL IDRIS: That makes perfect sense.
So again, as a developer then, it's critical for us
to stop blowing fog horns in the user's face
for every single event that might happen.
I've seen this in some applications
where notifications are used as a way to debug things.
Which is obviously a very negative thing.
And I've also seen persistent notifications, for example
in Android, used to basically notify
the user that an application is running
or something is connected.
Those are really bad and they need to go away, right?
PATRICK LARVIE: That's right.
So back to the story about the little boy who cried wolf.
Or Chicken Little who's telling you that the sky is falling.
If I see that I have a persistent notification
from your app, I'm going to think this app is telling me
the sky is falling.
I'll fall for it once.
Maybe I fall for it twice.
I will not ever attend to that again.
And the time when you have something really,
really critical that you need to tell me,
I'm not going to pay attention.
NAZMUL IDRIS: That makes sense.
PATRICK LARVIE: So batching them intelligently.
Finding the right moment in the cycle of product usage
to reach your user when that user is likely open and able
to react.
These are critical aspects of mobile user experience.
NAZMUL IDRIS: Yeah.
I think the batching notifications
is kind of like a subtle distinction
where let's say that you have determined there is a good case
to notify user.
For example in Gmail.
I have an email.
I need to know that I have an email.
But let's say I've received five emails.
It would get really annoying if I
would get five individual notifications for five
different emails from Gmail.
So what Gmail does is really nice,
which is it actually consolidates those five
emails into one notification.
And it says, hey you have five emails waiting.
And it does so for different accounts.
PATRICK LARVIE: Yeah.
I know that the people watching this have had this experience.
I order from a service that offers two-day delivery.
And that service, which a lot of you use,
tells me at every step of the way about each of the items.
I don't really want to know unless, A, there's
a problem, or B, it's about to arrive at my door.
This is a great opportunity to batch.
You want to be the notification-- your app wants
to be the notification that I receive just before I'm
delighted because I've opened my package
and I got what I wanted.
NAZMUL IDRIS: Exactly.
PATRICK LARVIE: I think there's another opportunity here,
thinking about batching and timing.
And I like to think of this as think before you sync.
There's nothing more irritating to make than when I'm-- again,
I'm on the bus.
I'm usually on my way home.
I've got about 20% battery on my phone.
And all of a sudden, all of my apps starts syncing.
I can see the battery declining.
I know that I'm not going to be able to send another text
message.
Don't be that app.
The opportunity here is to use the available data, the data
that's available to your app, to know a little bit about what
your user's patterns of activity are.
By using what we think of as attention profiling,
you can change how your notifications occur
and how certain kinds of activities
are batched and carried out.
NAZMUL IDRIS: No, that makes sense.
So now this data, this attention profiling data,
it can be collected in a variety of ways.
Like we could actually have analytics running or actually
pieces of code that are basically generating
analytics data, that are running on the device that then send
all this information to the server where it's stored,
deeper analytics can be run.
And then patterns can be predicted
that actually notify the application about how
a user actually interacts with it.
Now, this data can then be used to determine
when scheduling operations should happen
between the application running on the device
and whatever back end it's connecting to, right?
Now alternatively, if developers don't
have such sophisticated ways to make this happen,
there's a simpler solution.
Which is let's say you have an RSS reader application.
And you have like hundreds of feeds that you subscribe to.
It would be appropriate for that application to ask you
when you first run it, how often do you want it to update?
Do you want it to happen for every single change
in your feeds?
Do you want it to happen once a day, twice a day, once a week,
and so on.
So there's high tech solutions to this and low tech solutions.
But the important thing is to set the appropriate expectation
and also determine like, for example,
what the user's expecting so that you don't disappoint them.
Even with these constrained resources that we have.
So now, let's say that you do collect
a lot of really high quality attention profiling data.
You can also consider providing this information
to all the connected devices that the user has.
So that means that if you have a signed-in experience,
you can actually take advantage of the fact
that you know something about how your user is using
their particular devices or applications on their device.
And then you can use that data to drive the experience
on all the devices they're signed into.
So for example with signing in with Google,
you can create a pizza ordering application
that you run on your phone and on your tablet.
And then depending on how you use your tablet and your phone,
both those apps get smarter.
So that's something which is, I think,
a really big opportunity that developers can take advantage
of.
And these analytics, the analytics data
that can give you ideas of how the user uses the device, when
they use it, where they are when they're using it,
can give you strong signals about when
you need to sync information.
When you need to prefetch information.
When you think that you should queue notifications.
Let's say you are asleep and if the device knew that,
then perhaps it would not send you notifications
while you're asleep, right?
PATRICK LARVIE: I'd appreciate that.
NAZMUL IDRIS: As soon as you wake up.
Yeah, exactly.
So these kinds of things will allow you to deliver delight
to users of your application.
So that's all we have time for in today's episode.
Stay tuned for the next two, where
we'll give you the other two steps
in making your applications awesome.
And thank you so much, Patrick.
PATRICK LARVIE: Thank you, and thank you for your attention.