Tip:
Highlight text to annotate it
X
ROMAN NURIK: Hello, and welcome to another episode
of Android Design in Action.
I'm your host, Roman Nurik.
NICK BUTCHER: And hi, I'm Nick Butcher.
ROMAN NURIK: And in today's episode,
we're going to talk about 10 more navigation anti-patterns.
And when we say 10 more, we say that because we actually
recorded a previous episode of the show, where
we went into 10 of the most common UX issues--
user experience issues-- that we saw.
And some of those issues were specifically
related to navigation.
So in this episode, we'll talk about 10
more navigation anti-patterns that we've since thought about,
I guess, since that episode.
Nick, do you want to talk a little bit more
about the background here?
NICK BUTCHER: Yeah, sorry yeah, of course.
And if you didn't catch the previous episode,
we went into the background that part of job
is to work with a bunch of clients
and look at all kinds of applications out there.
And we come across all kinds of issues and variations
on a pattern, some of which work, some of which don't.
One of the things we often see is
when people that are new to Android design, they quickly
pick up things like the visual language of Android,
but they sometimes don't completely
internalize the navigation patterns
and completely grasp the nuances and some
of the consequences of deviating from these patterns.
So we wanted to give you the benefit of all this experience
and highlight some of the pitfalls we've come across,
and what you should watch out for
and what you can do instead.
ROMAN NURIK: Exactly.
All right.
Without further ado, let's get started.
OK, so 10 more navigation anti-patterns.
The first that we're going to talk about
is navigation in the action bar overflow.
So this is getting to be less and less common,
which is great.
But the idea here is some of the apps
that we've seen have put their primary navigation-- so
for example, Home, Store, My Items,
the different categories, Browse, things
like that-- basically the core way to navigate
your app-- they've put this onto the Action Bar overflow.
And this is really the wrong place to put your navigation.
There are a number of reasons for this.
The major reason is that now most apps don't do this.
Most apps follow the guidelines and use more standard UI
patterns for exposing their top level navigation.
We'll obviously talk about those,
things like the Navigation Drawer, things like tabs.
But really, this is the wrong place to put it.
Another reason is actually on older devices that
don't have the Action Bar overflow,
it would be hidden under the Menu button.
And there are lots of issues with the Menu
button-- the hardware menu button.
We won't get into all of them today.
But this is definitely one of the navigation anti-patterns
that we thought it was pretty common.
But luckily it's getting less and less common.
NICK BUTCHER: Yeah, generally, it
goes against the organization of having navigation
on the left and actions on the right
that all the other apps on the platform
are training users to look for.
So users not finding certain sections in your apps,
if you find this pattern, it could
be that they're just looking for it elsewhere.
ROMAN NURIK: So the second navigation anti-pattern
that we want to talk about today is
using UI patterns in the wrong order,
or having the wrong navigational hierarchy.
So we have a couple of major UI patterns
for exposing navigation, things like the Navigation Drawer
the Action Bar Spinner and tabs-- action bar tabs,
or just regular tabs.
So there's actually a pretty strict ordering with how you
should use these-- in which order you should use them .
And we basically, when you look at your app in terms
of its informational hierarchy, you'll
generally create something like a tree, right?
So at the top, you'll have Home, at the second level,
you'll have your major sections, and within each section,
you may have subsections and subsections and so on.
So one of the things that we've actually seen a handful of apps
do is use these different UI patterns to represent
different levels of that information hierarchy.
Now, the wrong thing to do would be
to use, say, tabs to represent the top level, and then
the Action Bar Spinner to represent,
say, the next level, and then, for example,
the Navigation Drawer to represent
the third, or deepest, level.
So this is actually just the wrong way to do it.
On Android, these three UI patterns actually
follow pretty rigid level-- or a pretty rigid hierarchy.
So instead of doing something like this,
the correct hierarchy would actually
be to always have the Navigation Drawer represent
the top-most level of your application hierarchy,
and then, if you have an Action Bar Spinner, that
should be the second level, and finally, if you have tabs,
they should be the third level.
Now, if you don't have a Spinner, if you just
have a Navigation Drawer and tabs, such as with Google Play
Music-- then it would just be the Navigation D
Drawer and then tabs.
But really, your tabs and your Spinner
should never precede the Drawer.
The Drawer always should represent the top-most level
of the application hierarchy.
NICK BUTCHER: So this is a somewhat contrived example,
that we have three different levels of hierarchy--
of navigation hierarchy in this application.
You probably would generally want to avoid that.
And perhaps you might do something
like having two levels of hierarchy
in your Drawer via a classical section, which
we'll cover in a section.
But, if you do have that kind of complex hierarchy,
then do respect this.
You generally want to go for a top-downward scan.
So the highest level is a natural mapping
to the root of your navigation.
And one wrinkle, is, you'll see here,
that the Drawer is obviously underneath the Action Bar
The difference being that when you open the Drawer,
Action Bar's expected to transform.
So in this instance, you would get only app-wide options.
So in this case, Spinner would disappear.
You'd probably just have the application name itself
and any actions not relevant to the entire application
should disappear from that.
So generally follow that top-down approach
and you'll be OK.
ROMAN NURIK: And another thing with the Drawer
is that we did have another episode specifically
about using the Navigation Drawer.
And we had, I believe, Rich Fulcher and Jens Nagel
from the Android Design team, that
talked a little bit about how to use the Drawer and in which
cases it's most useful.
So definitely take a look at that episode
if you have more questions about using the Drawer.
OK, with that, let's move on.
NICK BUTCHER: Absolutely.
So the next pattern that we wanted to cover
is talking about tabs.
So tabs in Android have a very strong mental link
to horizontal swipe.
So whenever you see tabs, you absolutely
expect to be able to horizontally
swipe between content.
So for that reason, if you do have
some kind of paginated content, you
do want to be careful about putting that
within tabs, of because you're going
to have some swipe ambiguity.
When you see tabs, you expect to be able to swipe
to change between them, not to move the content within it.
ROMAN NURIK: So one thing to add here
is that if it's a part of the tab-- it's maybe
a small section that's swipe-able--
let's say you have a horizontally scrolling
photo gallery or something like that.
If it's a part of the tab, then it's generally OK.
There are cases where it's possible to do this.
The issue here is that the entire tab contents
are another left and right swipe region.
And so it creates this ambiguity between,
am I swiping between tabs or am I swiping between pages?
In cases like if you have a map, where it's not really swiping
between pages you're, panning a surface, it's also OK.
But it's, again, something that you may want to rethink,
because there will be that ambiguity.
But in this case, this is just one of those textbook cases
of ambiguity really messing with the standard Android pattern--
or standard Android interaction of tabs being directly linked
with their contents.
So instead of doing this, another way
to solve this issue is to, instead of
doing horizontal paging, you can do a vertical scrolling type
thing for the tab contents.
So basically, anytime you have nested horizontal swiping,
really try to think, is there a better way to present this?
Maybe it's breaking out the content into a separate screen.
Maybe it's using a different interaction-- vertical
scrolling versus horizontal paging.
But really think about that, because that
is something that can create that ambiguity.
So the next anti-pattern we're going to talk about
is deep or persistent tabs.
These often go hand in hand.
So first, let me talk about deep tabs.
When we say deep tabs, we compare deep versus shallow
tabs .
On Android, tabs should be shallow.
What that means is that there shouldn't
be too much navigation within tabs.
Maybe you have a view switch, like you change the sort order
something, or something like that.
Or maybe you have scrolling, and whatever.
But you really shouldn't have any sort
of hierarchy or history within the tab.
What that means is, in this example,
let's say you're looking at the contents of a tab,
and you select one of these grid items.
You should take the user to a new screen.
You shouldn't actually take the user--
or update the contents of the tab with the whatever
you just clicked on.
And then when you press back, it would go back here.
This is not something you want to do.
This is actually something we would
call a deep tab, a tab that has hierarchy or history.
And so the reason for this is that, first of all,
this is just a platform norm.
This is not something that's generally done on Android.
But the second thing is that, what
happens when you swipe to other tabs
or switch between different tabs?
You actually leave your tabs in all sorts of weird states.
And the behavior of what happens when you get back to tab
isn't really well defined.
Should you reset the tab back to its top level?
Should you stay where it is?
You really don't want to have too much state going on.
And really this is actually a recurring theme.
When your app has too much state that the user has
to keep in mind, or too much state
that it's maybe unexpected to the user,
that's going to result in confusion.
So these are things you want to avoid.
And so for that reason we, generally
consider tabs as shallow on Android.
Another similar point here is persistent tabs.
So persistent tabs are basically tabs
that behave like global navigation that are always
there throughout your app.
And so the problem with this-- and they
can either be in the top or the bottom.
When they're on the bottom that's even worse because,
again, tabs on Android should be at the top.
But persistent tabs, regardless of where they are,
are problematic, because that's not really
how global navigation should work on Android.
Especially with things like the Back button.
What happens when you switch between tabs
and then do stuff within tabs?
The Back button behavior is no longer really well defined.
And so it's not really a platform norm, as well as
there's a lot of confusion that will result from it
to have tabs that are persistent across the app.
And for that reason, one of the reasons
that we created the Navigation Drawer was
to allow apps to create these kind of global context switch
type UI patterns, or UI's, where to switch
between some deep part of one section
to a whole other section of the app,
you can use the Navigation Drawer,
which is available through an edge swipe.
So really, to summarize this very long-winded argument,
avoid persistent tabs that are there throughout,
and avoid deep tabs, basically tabs that have hierarchy.
Anything to add, Nick, before we move on?
NICK BUTCHER: You covered that pretty well.
ROMAN NURIK: OK, well let's do it.
I'm going to talk about-- actually, real quick--
NICK BUTCHER: This is what you need to do.
ROMAN NURIK: Yes, yes, yes, that's right.
We had some examples of ways to mitigate this.
So in this previous example, you had your tabs
show the contents of the thing you just clicked on.
In this next example, instead of showing the tabs,
you basically take the user to a whole new screen
with a whole new Action Bar and an Up caret or an Up button
And then to get back to where the user just was,
they would just press the Up button.
And then, of course, if you have a Navigation Drawer,
you can always expose it here through an edge swipe.
So that's a deep and persistent tabs.
Nick, do you want to talk about back traversing across tabs?
NICK BUTCHER: Yeah, absolutely.
So as Roman was saying about having these shallow tabs,
we have consider moving between tabs
to be a very lightweight action.
It's not something that's going to actually drop history,
as it were, drop something into your navigation history.
So therefore the Back button should not unwind your moving
between tabs like this.
So in this example here, if you're on the third tab
and you were to tap or swipe between them,
tapping shouldn't unwind you.
In fact, if you embrace the fact of having to swipe between it,
it would feel pretty unnatural for a tap of a Back button
to unwind a swipe button.
So that's one of the reasons why we say not to do that.
ROMAN NURIK: Exactly.
And a similar area where the Back button shouldn't do, maybe
what you think it should do, is when
you're changing between different Drawer sections.
So for the Drawer, you may think if I switch from section one
to section three to section four,
pressing Back should switch between those.
But actually the platform standard here,
again, for the Back button, is basically,
when you switch between sections in the Drawer,
you should actually reset your task stack.
It's almost like you've entered in a different app.
And that's really what the navigation Drawer is good for.
If you look at an example, like Google+, for example,
the Google+ app, when you switch between different sections,
you're almost entering different apps.
And the navigation Drawer is really
good at these types of scenarios.
But the guidance here is when you switch between sections
in the Drawer, pressing back should probably either
kick you out of the app, or, if your users
are getting confused by why is this leaving the app,
it should maybe take you to the top-most section.
So for example, Home.
So if I go between Home and Browse
and Search and Store and Categories,
pressing back from Categories should really only take me
back Home and then to the Home screen, or just
the Home screen.
Anything to add, Nick, before we move on?
NICK BUTCHER: No, I was just going
to say that's a really powerful point,
I think, is that if you do have one natural Home one place
where you should always expect users to want to come in
on and probably get back to very easily,
it's OK to have one level of Back inserted.
It's that fresh task stack to take them back through that.
So they have that stability of really easily getting
back to that natural Home position from a sub section.
But otherwise treat changing sections similar
this to changing tabs.
It's not going to have a history in it.
ROMAN NURIK: All right.
Let's move on.
Deep Navigation Drawers.
Do you want to cover this one, Nick?
NICK BUTCHER: Yeah, the next one is one of my pet hates.
It's probably a smell, really.
If you're having to do this pattern here,
of having deep navigation structures in your Droid,
it probably means your navigation
needs to be simplified somewhat and maybe perhaps
broken up into different sections
or different applications perhaps, or something
like this.
But the idea of a Navigation Drawer
is it's a stable list of navigation targets, which
you can always get to and jump to and stuff.
And you don't want to put any cognitive load on the user
to actually remember where they were
or where they've come through.
And it wants to be a stable thing that when
I open the Drawer, and I can have my Home option
or have whatever option to navigate to.
So you want to avoid having different steps,
or even seeing secondary Drawers popping out
from the first Drawer, which is also pretty crazy.
So do try and avoid this.
An alternative way of actually having
some kind of subsection behavior-- and I think
we hinted at this earlier on-- it
is OK to have these expandable items.
And the reason this is kind of OK
is because it's not this huge content switch.
You're not completely replacing the contents of the Drawer,
but it's sort of new and enforcing the users
to keep up with where they are in their [INAUDIBLE].
But it's just an in-place expand which
shows the user slightly more options.
So that is cool.
ROMAN NURIK: And we have a little bit more guidance
on what the exact touch target should be,
exactly how they should behave in the design guide.
So if you go to developer.android.com/design/pattern/navigation-drawers.hmtl
I think it is, or just search for Navigation Drawers Android
Design, you'll see some more details about exactly how they
should behave.
Based each line item should actually have two touch targets
if section one has its own landing screen.
But anyway, there's another alternative.
Nick, do you want to talk about that one?
NICK BUTCHER: Sure.
So an alternative might be instead
of putting all the navigation in a Drawer,
you might break out to another [INAUDIBLE] subnavigation.
In this example on screen here, we're
in the screen you get to when you switch sections.
You have some more navigation type activity there as well as
content.
Or, as we talked about earlier on,
you could combine another navigation pattern.
So for example, you might use the Drawer
for your major navigation sections
and then use a Spinner, perhaps, for subsections of that.
So don't feel like just because you're
using a Drawer that you have to have all your navigation forced
right into that in the same place.
Think about other ways to allow subsection navigation.
ROMAN NURIK: And a good example of that,
again, is Google Play Music.
When you go into-- it's a Drawer-- you
see things like listen now and then My Library Under My Li
Library you see things like Artists, G Genres, and so on.
That could have been in the Drawer,
but that was actually placed into tabs.
The nice thing about tabs is that you can actually really
quickly swipe between those different sub sections.
So definitely think about different ways to this.
One thing I should mention here is we specifically
called out content one, content two in these little wire
frames because you don't want to just
have purely navigational elements on here.
You should add a little bit of content to the screen.
You don't want to turn into a dashboard type thing, where
you see a bunch of big icons or a bunch of big text blocks.
And one of the ways you could do that,
obviously, is to show content.
Another is to just show images.
Show dynamic images representing that section.
I think an example of that is Google Play Newsstand.
I don't remember off the top my head.
But definitely don't just throw text on the screen.
NICK BUTCHER: And you're talking about the explore tab
[INAUDIBLE].
ROMAN NURIK: Exactly.
All right.
Our eighth item here is bad Drawer transitions.
So there are a couple things like this involves.
When we say transition, we both mean the animation,
the actual visual change, as well as the transition from one
screen that has a Drawer to another screen that doesn't.
And actually I think the next two items are related to this.
Basically, let's say you open up the Drawer,
and you touch section one, you shouldn't actually
be taken to a new screen with an Up caret.
Basically, there's a strong guidance that says,
any screens that are represented in the Drawer-- so for example
here, section one, section two, section three, and so
on-- when you actually get to the screens
they should also show a show the Drawer indicator.
So the first issue here is that you don't actually
see the Drawer indicator, you see this up caret instead.
So that would be incorrect.
But another slightly more subtle aspect of this
is the transition.
When you go between section one and section two ,
you shouldn't see this standard default zoom up transition that
takes that you see when diving into content or showing a new
activity, showing a new screen.
You should, first of all, try to suppress that transition.
So it should be really fluid.
It's almost like, you touch something,
the Drawer closes, and then the content
of the section you just selected just fades in or appears.
It shouldn't be is jarring kind of zoom up
animation that changes the Action Bar
and does all this stuff.
Another thing to think about, more
for developers is-- and this is a question we
get all the time-- is, should I have a multiple activity
or multiple fragment app when I'm using the Drawer?
And there's no easy answer.
There's no right answer.
It really depends on the situation.
So if you guys have suggestions for the developers out there,
feel free to comment.
My suggestion would be just examine the difficulties
and whether or not it makes sense for your app.
I would think by default start with multiple activities
with replacing the transition, but having a single activity
with multiple fragments, that is possible as well.
OK, should we move on?
NICK BUTCHER: Yeah, I think we just got a good example here.
Just reinforcing the point that every section which
appears in a Drawer, you'd expect to have the Drawer as
coordinates showing on the screen, and for other sections,
it should show you the Up caret.
ROMAN NURIK: So related to that is never showing the Up caret.
And this is really view the converse
of that-- or the inverse of that-- whatever it is.
So like we said, anything that is represented in the Drawer
should show the Drawer indicator.
But things that aren't represented in the Drawer,
for example, here we're looking at a specific piece of content.
We've now dived into-- or dove into-- a specific news story,
for example.
At this point the, Drawer indicator shouldn't be there.
You should instead show the Up caret,
because you're now in a deeper section or a deeper
part of the app within one of the sections in the Drawer.
And so instead of doing something like this,
you should obviously show the Up caret.
But what you can do to still expose the Drawer
is allow an edge swipe.
And again, this is something that's in our documentation,
in our design guidelines.
You don't necessarily have to show the three little line
indicator, the Navigation Drawer indicator, to have a drawer.
In this case, having the Drawer there
is more like a power user feature.
For folks that discover that gesture, great.
For those that don't, that's not so great.
But they always have that ability
to navigate to those other sections by pressing Up.
So you're not really keeping functionality
from a certain class of users.
You're really just adding additional functionality
for power users.
NICK BUTCHER: I guess it's kind of two competing
things, like competing for the same space.
You want the user to have that hierarchical navigation,
to have strong sense that it's going to keep you in the app
and go to a parent type screen.
So you want the Up caret.
And one of the greatest abilities of the Drawer
is that you can have it available to you elsewhere
to do these cross-cutting navigation gestures.
So I advise to resolve those two competing
things is to show the Up caret, but allow the edge gesture.
And an interesting implementation detail
is what do you do when you [INAUDIBLE]
edge swipe the Drawer open?
I think a really nice way to do this
is if you take a look at the way Google Newsstand does
this is they'll show the Up caret.
And as you that edge swipe out to open the Drawer,
they'll cross-fade the caret into the open Drawer
affordance.
So it makes sense that when you look at the screen,
oh yeah, that's the Drawer open I
know that touching that's going to close it.
But when you look at the content screen, you have that Up.
And it's giving you that stability,
that expectation of navigation.
ROMAN NURIK: Mhmm.
Exactly.
Should we move on to our last anti-pattern?
NICK BUTCHER: Yeah.
Unit 10.
ROMAN NURIK: Do you want to talk about this one, Nick?
NICK BUTCHER: Yeah, for sure.
So the last one we're going to pick out
is using right side navigation.
And we touched on this slightly at the top of the show.
There's a strong, strong organizational theme in Android
to have navigation activities on the left
and actions on the right.
With most left-to-right languages,
you scan the page in one way, and it reinforces
the hierarchy, that this is your navigation,
you're hierarchy, your top level things.
And the content is going to be on the right hand side.
So I think on this example here, we're
showing a tablet, which has a larger screen available to it,
so [INAUDIBLE] persistently.
So you wouldn't want to put that on the right hand side.
You'd want to keep that left-aligned
to go with that general organization of nav
on the left.
ROMAN NURIK: So basically, here's the bad screenshot.
Here's the good screenshot.
This really works with both navigation--
you shouldn't have Navigation Drawers on the right--
as well as Master detail scenarios.
You shouldn't have the Master on the right.
You should really have the Master on the left.
It should really read left to right.
And obviously RTL locales, like if your language
is in Hebrew or Arabic, this would be flipped.
NICK BUTCHER: Yeah, So you've got the gravity start
on Android on the left and right.
ROMAN NURIK: Exactly.
So those are the 10 more anti-patterns for navigation
that we wanted to talk about today.
I guess it's both navigation and app structure, if you will.
If you have any more anti-patterns-- well
this obviously wasn't a comprehensive, exhaustive list.
But if you have any more anti-patterns
that you want to share, feel free to let
us know in the comments.
Or just post something to Google+ with the hashtag
#AndroidDev, and we'll take a look and possibly comment.
So with that, thanks again for joining
Android Design in Action.
As always, I'm your host, Roman Nurik.
NICK BUTCHER: And thanks from me, Nick Butcher.
ROMAN NURIK: See you guys next time.