Android Design in Action: Design Hangout No. 2

Uploaded by androiddevelopers on 29.01.2013


ROMAN NURIK: All right, I think we're live.
All right, so assuming that we're live, hello everybody,
and welcome to this week's episode of
Android Design in Action.
We don't have a theme or topic this week, or any set of
redesigns today.
What we'll be doing instead is having a hangout with a bunch
of folks from the design community.
I don't know if this is public and free to join--
not free to join.
If you're able to join.
If you, for some reason, cannot join and you do want to
join, just go to the Google+ page for Android developers
and leave a comment on this post, and we'll go ahead and
invite you so that you can join.
So we're just going to have a Q&A general discussion type
event today.
Before we get started, let's do some quick introductions
for folks that are already here.
I'll start.
So I'm Roman Nurik.
I'm on our Android Developer Relations Team at Google, and
I'm one of the co-hosts of Android Design in Action.
ADAM KOCH: Hey guys, Adam Koch.
I'm also one of the co-hosts on the show.
If we go over to London.
So, Nick Butcher here, another Android developer advocate.
And I'm joined by--
CHRIS BANES: Chris Banes is also one of the dev rel for
Android, but I'm a guest this week.
I don't usually come into this.

Who else have we got?
ROMAN NURIK: All right, should we head over to Marie?
I'm an Android designer for four years, and now in Berlin
as creative director for Novoda.
And Juhani?
So I'm Juhani.
I'm a developer, but I'm a design fan.
I've wrote a book Smashing Android UI and write a blog in, and I work for Snapp TV.
All right.
So, Dandre was here, and then he left.
Let's head over to Andreas.
Andreas, do you want to introduce yourself?
Or if you want, do you have any immediate questions you
want to ask?

Or not, OK.
Let's head over to Dandre.
How about you?
How's it going, man?
MALE SPEAKER: Hey, can you hear me?
ROMAN NURIK: Yeah, we can year you just fine.

I'm an Android developer and designer from San Francisco.
ROMAN NURIK: Cool, welcome, man.
And we also have Lucas.
Hey Lucas, how's it going?
Do you want to introduce yourself real quick?

LUCAS ROCHA: Hello, can you hear me?
ROMAN NURIK: Yeah, we can hear you just fine.
So, I work for Mozilla.
My day job is Mozilla, working on Firefox for Android.
And I also created an app called Pattrn.
It's a wallpaper app.
We've got quite a few downloads in Google Play.
ROMAN NURIK: Yeah, it's been featured numerous times.
Good stuff.
All right, let's see who else is here.
I think David Jones.
I'll go ahead and unmute you, good sir, and Ron Elam.
So, if anybody hasn't introduced themselves and
wants to, feel free.
Otherwise, let's jump into the meat of today, which is kind
of general discussion and Q&A.
So before, we actually have a Google Moderator page set up,
and we have a few questions in there.
We'll get to that if there's time, but if anybody has any
initial points of discussion or topics they want to raise,
or questions that you want other folks to provide their
feedback on, please go ahead and ask.
So anybody want to kick things off with their own questions
or points of discussion?

NICK BUTCHER: No one's got any questions?
Perfectly satisfied.
JUHANI LEHTIMAKI: I have a topic we can discuss, but I
don't have any questions.
Juhani, you want to go ahead and introduce the topic?
JUHANI LEHTIMAKI: So, the up and side navigation, or the
drawer navigation.
It's great, right?
But it's quite messy right now.
So we've got to figure out how to [INAUDIBLE], because now
even Google applications work quite differently.
Google+ you can't swipe, and YouTube you can't swipe to
other navigation apps and so on.
I wonder if you guys have a recommendation what you feel
the interaction should be.
Should you reserve a bezel swipe for it, or does swipe
always work?
And my personal opinion about the icon is that it's the up
icon, but I know you guys haven't--
but let's see what's going to happen with that.
Mostly about the interaction like swiping and stuff, how
you feel as to that?
ROMAN NURIK: So I guess we could probably talk about the
navigation drawer, and I'll probably take up some time.
And that was actually the number one
question in the moderator.
I think it got something like 20 votes.
I actually put together a little bit of, not really
It's the unofficial recommendations from our team
about what we've been recommending to folks publicly
as well as internally.
And we could probably start with that.
So let me just share that real quick, and then as you guys
want to talk about what your feelings are towards the
subject, then feel free.
So I'm going to screen share my tiny little guide on
navigation drawers.
I don't know if you guys can see that.
You guys can see that?
ROMAN NURIK: So the current guidelines are, basically, a
drawer is a slide out menu that allows users to switch
between views of your app.
And it's obviously exposed using the action bar's app
icon with the up current and revealed by an edge swipe.
And actually in some cases like the YouTube app, it's not
really an edge swipe, it's a full screen swipe.
Anyway, that makes sense, and personally, my opinion is that
it makes a lot of sense to do a full screen swipe when there
aren't competing gestures.
For example, if you don't have swipe to dismiss--
Actually, hold on.
AJ just joined.
Let me go ahead and unmute AJ.
Hey AJ, how's it going?
So when you don't have swipe to dismiss, or you don't have
other horizontal gestures like for example a map as your
primary content view, I think it makes sense to do a full
screen swipe, because that's probably what people are
trying to do anyway.
That's just, again, really my opinion.
And the current guidelines say edge swipe, and I'd say that,
by default, you should probably just
used the edge swipe.
The other thing is that--
where is it--
only suitable for the topmost level.
So another thing that folks sometimes use drawers for--
and hold on, let me unmute David.
He just joined.
The other thing that people use drawers for is to provide
exposed global navigation throughout the app.
For example, if I'm in a detail screen three levels
deep somewhere, what if I want to expose global navigation,
let the user do a full context switch?
And sometimes folks use drawers for that.
I don't think that that really fits in with how they're meant
to used on Android, but certainly it's something
that's become popularized.
So the current guidelines don't really call for exposing
drawers in deeper levels, but it's definitely something that
we can explore.
If you guys have feedback or arguments either way in this
direction, feel free to speak up.
NICK BUTCHER: It's my position that it's kind of dictated by
the content somewhat.
If you have a strong hierarchy to your content, then I feel
like the up button should always take you up through
that hierarchy of content, and it shouldn't be
exposing the drawer.
That's fair.
Anybody else?
Any other thoughts?
Actually, this is one thing that's pretty common right now
is using the drawer for global access and using, instead of
the up icon or the up counter in the app icon, using the
three horizontal lines.
And I know you guys can't really see who's talking
because I'm sharing the hangout screen, but--
Something like that is a little more common on other
platforms, and so it's definitely something that I
think that we should try to standardize on at some point
in the future.
Actually, a little point about the three horizontal lines is
somebody called that the hamburger icon, because it's
basically two buns and meat patty in between.
But yeah, it's definitely something that's been used
throughout, and I think that users understand what it is,
the three horizontal lines, but really the current
guidelines are for the app icon and the up counter.
Well, let me just jump into some of the unofficial stuff
before I take this screen off, so you can
see our faces again.
So, like the current guidelines say, only at the
top level, the up counter and app icon, it should also not
slide the action bar.
So this is a point of contention.
This is definitely something that is a little inconsistent
right now across Google Apps.
So the Google+ app, for example, does slide the action
bar out of the way to make room for the drawer.
The YouTube app does not.
We definitely recommend not sliding the action bar out of
the way, and I think there's really two reasons for that.
The first is that, from a framework standpoint, from the
development standpoint, it's actually kind of
difficult to do that.
And it kind of imposes extra effort and extra work to get
that done, and some people say, in that case, let's just
recreate the action bar.
Let's just reimplement the action bar so that we can
slide it out of the way.
And that's not really something that you should be
doing, because there's a lot of nuances with how the action
bar's implemented.
So you should try to avoid implementing the
action bar on your own.
The other point is that the action bar is really kind of a
core navigational anchor.
It's really the number one structural component of an
app, I'd say.
And so moving that out of the way slowly deteriorates this
relationship the user has with that action bar.
Making sure that it's stable is very, very important, and
if you start moving it out of the way and sliding it away
and so on, that could potentially deteriorate the
So those are the two points that I'd say about sliding the
action bar.
And then, again, edge swipe or full swipe, and then the other
thing that folks sometimes put into the navigation drawer is
things like settings and help.
And we really don't recommend putting things like settings
and help there, because those are really meant to be in the
action overflow.
The action overflow is those three vertical dots in the
action bar that, when you press them, you see additional
actions that you can take.
And so settings, help, about, feedback, terms of service,
privacy policy, things like that, those are really
overflow items.
And so we feel that those should belong in an action
overflow and not in the navigation drawer.
So these are the unofficial other items I'd add to our
official guidelines.
But certainly--
let me just turn off the screen share there--
in terms of where we're going with the guidelines, I think
that there's definitely a lot that we can add to the current
set of guidelines, and that's something that we'll be doing
in the future.
It's just a question of time and resources.
So hopefully at some point, we'll do that.
Anybody have any other thoughts on
the navigation drawer?
I just did a big spiel and took a lot of time to talk
about it, but if you have any thoughts, feel
free to speak up.
ADAM KOCH: One quick thing I wanted to mention is how you
said, don't move the action bar out of the way.
That works in with how you also mentioned that settings,
about how it should be in the overflow.
I see a lot of people put those things in their drawer,
because they've slid across the action bar, and now the
overflow's no loner accessible.
So that's another good reason to keep the action bar in
place so that you can keep that overflow still


NICK BUTCHER: Keep it to navigation option as well.
I think, because you have this extra real estate, people get
tempted to dump all sorts of extra information in there.
And I think that really waters down the power as a
navigational tool.
I tend to think of it as very similar to the spinner
navigation like you might see in Google Maps, for example.
It's a similar thing, but if you have a larger list of
items, it can become unwieldy in that spinner
and harder to do.
So I think the draw can be a good alternative there, as
well as not sacrificing some real estate.
So don't be tempted to just chuck any old thing in there
because you have some more space and a vertically
scrolling container.

JUHANI LEHTIMAKI: So I'm just wondering if you guys have had
any chance to do any usability testing of how users see the
site navigation with the context of back button.
Because I know if you guys tried the [? Word ?]
application, I don't know if they fixed it, but when it
first launched, the site navigation actually was very
difficult to use because it didn't make sense.
When you backed, you actually had to skip screens.
I think the Google application is quite good, but I don't
know if I'm just a special user or how users in general
feel where the back should take you after you navigate
within the site menu.
ROMAN NURIK: I don't know too much about the research we've
done specifically around navigation drawers.
I'm sure that we've done some amount of research, but I
don't really know the details.
I know we did a whole bunch of research on the action bar and
up icon, and that was a few years ago.
Maybe two years ago we did a big study on that, but I think
that a lot of our guidance is a result of direct user
testing with that.
But the navigation drawer, I'm not really sure what kind of
formal testing we've done on it.
So I don't really know how to answer that question.
NICK BUTCHER: I think a lot of the weirdness with back
navigation falls out from whether or not you make it
globally accessible as well, because if you have
applications such as, say, Spotify or something like
that, which let's you get to the side drawer from anywhere,
then you can build up these incredibly long back stacks,
which gets quite complicated.
Whereas if you do stick to the guidelines, Roman's unofficial
guidelines, of only making it available from top level
navigation screens, then you don't get these very, very
complex navigation stacks, and I think the back button
becomes a lot clearer.
ROMAN NURIK: That's a fair point.
Do you guys have any thoughts?
Again, since this is a kind of a discussion and Q&A, I don't
want to just be spewing out recommendations from our team.
I'd love to hear you guys' thoughts on what's the right
way to do it, or even like, if you don't like the up icon,
and this is definitely something that's been brought
up before, if you don't like using the up icon or the up
counter for this purpose, what are the things have you
thought about, and things like that.
So this is not just for official guidance.
If you guys have thoughts, please do share.
NICK BUTCHER: Yeah, Ed Lee in the comments chimes in that
the burger menu is getting quite common.
Even Chrome uses the icon.
NICK BUTCHER: I think Chrome uses the icon
in, is it in iOS?
ROMAN NURIK: Oh, the hamburger icon.
They use that on the desktop basically for the overflow.
I'd say it's a little different.
You can't really compare two very distinct platforms.
Like if you look at the desktop platform verses
Android, there are definitely different norms on each.
So even the iconography, even the direction of if there's a
search icon, where the handle is.
Is it to the left or to the right?
Even little things like that, they can
differ across platforms.
So I'd say that it's more important, I'd say, to be
consistent with Android rather than consistent across
different platforms.
NICK BUTCHER: So yeah, it's not in Chrome, sorry.
It's on
If you go to on mobile, you get the burger.
ROMAN NURIK: That's fair.

MARIE SCHWEIZ: Mostly, if I see swiping navigations, I'm
cleaning the concept.

People are sending me concepts and want feedback from me, and
I say mostly it's messy to put all the functionality in this
menu, and everything is fine.
And if you have something like a shopping application, they
do the whole functionality for a shopping basket and all this
stuff in the swipe menu.
And then they want a secondary action bar to handle
functionalities for the shopping basket
and all this stuff.
And mostly, if you're cleaning up the navigation, the
secondary action bar is gone.
That's what I learned in the past.
MALE SPEAKER: Yeah, I mean, using the drawer as the main
navigation, I use it as a last resource.
I mean, if you don't have any other way to show visually on
the app the sections, go there.
But I think it's very, very easy to just throw everything
in there and forget about it.

MARIE SCHWEIZ: It's not right.
MALE SPEAKER: It's not right, because the users
are not seeing it.
And if the users are not seeing, they're probably not
going to remember that that is there.
So I think it's a trend.
It's obviously a trend.
A lot of people are using it.
MARIE SCHWEIZ: I don't think so.
I think it's like, OK, we don't know how we build real
mobile use cases, and then we put all the menu and we have
the whole system on Android.
ROMAN NURIK: But it is a trend, right?
It's definitely a trend that folks are doing it.
And I think that, like AJ says, it's becoming more and
more like a default.
And what it should be is really a last resort.
And I think that there are two points I want to make there.
The first is that sometimes there are drawers that have
three items in the left pane.
You swipe it open, and there's three items there.
Drawers are really just replacements for
tabs in that case.
So it's really just an alternative presentation of
horizontal tabs at the top of screen.
And so at that point, why don't you just simply use tabs
or use a spinner?
I mean, that's less heavy weight and
more immediately visible.
And the other point I wanted to make is that this actually
reminds me of one of the problems that we saw with
original menu button on older devices.
One of the problems was that people were putting core
functionality into something that wasn't immediately
visible and something that wasn't immediately clear what
functionality was available.
And so you would press the Menu button and hope that
there's interesting stuff in there, hope that the thing
that you're trying to do is in there, and it wasn't
immediately on screen.
One of the reasons we actually came up with the action bar
pattern was to put more fundamental actions and
navigation on screen.
And I think that with the drawer, we're seeing kind of
the reverse of that.
We're putting less and less stuff on screen for the
purposes of making or optimizing the
real estate for content.
But I think that there's probably a better balance to
be struck in a lot of cases between content and Chrome.
You still want to show the key, most important navigation
in some way, as well as your content.
But I'd say that what AJ says is right.
It shouldn't be a default.
It should really be kind of a last resort.
If there's no other pattern that works really well, then
the drawer may be an option.
MARIE SCHWEIZ: It was because the product managers say, we
want catalog in our shopping application.
We want a category view.
We want all the stuff we want in this little small
application, and then you have too much.
They can develop a mobile application with maybe three
useful functionalities.
That's the mobile case.
That's the reason why we have mobile.
I'm maybe in a store, and I will order the shoes at home,
delivery service.
So one case, just ordering.
And I think the messy point, or the too much
functionalities, it's a little bit Windows Explorer.
ROMAN NURIK: Yeah, I think it's really up to us as the
designers to talk to folks like that and say, you do
really need to optimize around the core competencies and core
best use cases of your app.
Like, make sure that the two or three things that users are
expecting to do with your app are really easy and
And if folks that are asking for these apps to be built
say, but we need like seven, eight, nine different
functions, then I guess it's the job of the designers to
say, given those nine functions, how do we best
present these not as functions but has as flows and as
benefits to the user.
So I'd say, maybe it's our job to pare things down to the
most important, and then put other things in.
Put other items like secondary functions into the overflow or
into other navigational elements.
NICK BUTCHER: I quite like it when an app has a tight focus
and doesn't try to do everything.
Why not launch a second app, perhaps,
for a different thing?
MARIE SCHWEIZ: Yeah, or you have the tablet case, more on
application and more functionalities on tablet.
CHRIS BANES: That's true, actually,
you've mentioned tablets.
Also it makes it easier to do a master detail flow on
tablets, because you can show that drawer by default on a
tablet, and you have that same UI, so you can reuse
everything, so it just makes it easier.
NICK BUTCHER: Yeah, and YouTube does that really
nicely as well.
So it uses this responsive design so when you have a
certain amount of horizontal real estate, the drawer is
opened by default.
CHRIS BANES: There are positives to it.
MARIE SCHWEIZ: What I've said in the past is, OK, other
systems like iOS working really straight.
They're working a step deeper, deeper, deeper in the
application, and Android works a little bit more chaotic, but
every time, step very close to the user.

ROMAN NURIK: Marie, still there?
I think Marie may have frozen.
MALE SPEAKER: She's frozen.
When she gets back, we'll let her finish that thought.
But before we move on-- we have five minutes left--
does anybody else have any?
NICK BUTCHER: I think there will be
moderator questions, or?
ROMAN NURIK: Yeah, we should probably
jump into the moderator.
When we return, she can finish her thought.
Before I jump into the moderator, does anybody else
have anything they'd like to bring up?
MALE SPEAKER: Can I talk about the quick return bar?
ROMAN NURIK: Sure, yeah, go ahead.
MALE SPEAKER: There's basically, the pattern that
you presented in the code, and I shared one that does an
implementation like in Google+ where it's on the bottom.
NICK BUTCHER: OK, Lars did one of those, right?
Lars forked it.
MALE SPEAKER: Sorry, what was that?
NICK BUTCHER: Yeah, Lars forked your code, didn't he?
Roman, what's his name?
ROMAN NURIK: Lars Vogel?
NICK BUTCHER: [? Birkman ?].
ROMAN NURIK: Oh, Lars, [? Birkman ?], OK.

That's cool.
I haven't seen it yet.
So Dandre, did you want to make a point about its
usefulness, or do you have any questions about it?
MALE SPEAKER: Yeah, I was curious, like, so there's a
little bit of weirdness about scrolling up bringing
something from the bottom, but the advantage, of course, is
that it's on the bottom, so it's a lot
closer to your finger.
Maybe if you were scrolling up, you'd just scroll up a
little, and it's right there.
And if you're on a tablet or something, or if you scroll
up, and the thing's at the top, then
it's really far away.
So I was curious, what's the ideas about, should it be on
the top or bottom, or if it were just a
weird pattern at all.
ROMAN NURIK: Well, I think that the placement, it's
generally better to put it at the top.
It's a little more natural.
I'd say that the Google+ app in general, when talking about
things that Google+ app does, it's a little more
experimental on the UI side.
They're definitely trying lots and lots of those things.
And some of them work really well.
Some of them are really just experiments that
they'll pull out.
So I wouldn't say that follow the Google+ app to the T as to
what it does.
But specifically in this case, I think one of the reasons
that they moved it down is that the iconography that they
were using wasn't as clear as it could be, and then they
wanted to show text as well.
And then at that point, the bar itself became quite large.
So it became just a little bit of a burden at the very top of
the screen.
So they moved it to the bottom, but I don't think that
that's really finalized.
I don't really know if it's finalized.
But certainly it's something that we're still exploring,
but I'd say that by default, you should probably use sticky
bars at the top unless it's really following your
scrolling gesture.
So if you're scrolling down and you want to show something
at the very bottom like, for example, I don't know if this
is very common, but jump to the top or jump to the bottom.
If it's showing up in the direction you're scrolling,
that would probably make sense.
So, if you're scrolling up, probably showing something at
the top is better.
NICK BUTCHER: One exception that I quite like is the
Foursquare app does something quite nice where, as you're
scrolling down your feed, if you go back to the top, it
actually pops up some kind of filters at the bottom, which
is actually a quite nice way of doing it.
So it doesn't do it just with the general scrolling up, but
just when you reach the very top, it pops in,
which I quite like.
ROMAN NURIK: That's fair.
Marie, did you want to finish your thought real quick?

MARIE SCHWEIZ: My network is not really stable today.
ROMAN NURIK: That's all right.
We'll follow up over on Google+.
MARIE SCHWEIZ: No problem.
I see that you can handle the topic very careful.

ROMAN NURIK: So let's see.
Dandre, did you have any other questions on the quick return?
It's not really a formalized pattern, the quick return, and
actually that name is just something that me and Nick
came up with.
It's not really a formal thing.
But certainly, I think, in general when there's something
that's not documented in our official guidelines, we have a
bug filed internally to make sure that it gets documented.
It's just a question of time and resources.
So at some point, we'll have probably some more guidance on
quick return.

MARIE SCHWEIZ: I have a question about resources.
MARIE SCHWEIZ: So mostly, I'm working for-- in the past--
now I'm employed by Novoda, but in the past, I'm working
for a lot of creative agencies.
They're doing something like catalog, or shopping, or
tools, or gadgets, or automotive, or sports brands,
all this stuff.
And I try to show them how Android works.
Big thanks to my friend [INAUDIBLE]
who took maybe 30 screen shots from Ice Cream Sandwich.
And I have now 30 screenshots with his private mail account
and all the private stuff.
But I use this stuff to show the [INAUDIBLE] and the
designers, look how Android is today.
And what I really need is maybe just screenshots from an
actual system, a Nexus 4.
I haven't done Nexus 4.
I have just older phones.
I prefer the older phones actually, not just because
they have keyboards.
ROMAN NURIK: I think AJ is signing an agreement, right?
MALE SPEAKER: Yeah, I mean, right now, it's really hard to
find screenshots of the Nexus 10 resolution.
You can't find it.
I can't.
There are no--
MARIE SCHWEIZ: Or just how a system application looks.
HTPA comes in, you'd better, guys, have a couple of
screenshots first.
ROMAN NURIK: I will say this.
So if there are specific screenshots
that you guys need--
I mean, it's obvious that we can't all buy every device.
If you guys need certain screenshots at any point, just
let us know publicly.
We'll share publicly.
We're more than happy to do that.
And we have a bunch of test accounts.
So I know that this isn't like an official resource, but this
is definitely something that we can help
with in one off cases.
But certainly, we do plan on updating the design site with
this kind of stuff.
So I don't know if it will be full resolution, but
certainly, we want to make sure the design set is up to
date so that you can share at least those screenshots, those
framed screenshots with your product managers
and clients and such.
NICK BUTCHER: Yeah, I'd always say whenever I start working
with a designer whose not worked with Android before, I
always encourage them, if they can, get hold of a device and
just get used to the patterns and so on.
I know that might not be possible, depending on your
clients or whatever it is, but that's going to be the first,
best solution.
If not, there's always the emulator, but--
MARIE SCHWEIZ: I can tell you, from time to time, I never get
my device back.

ROMAN NURIK: I think we're losing our room, and I think
we're a little over time.
So let's stop there and continue sometime in
the next few weeks.
I think we should do more of these, and probably on deeper
dives into specific subjects.
But thanks everybody for joining, and definitely we
have food for thought and more bugs to file in terms of more
design research things to come out with.
So again, thanks for joining, and we'll see you
hopefully next week.