General Discussion  - 
 
Hi everyone,

I wrote a blog post about how we, developers and designers, should start working towards a more consistent sliding drawer design. I wrote a few guidelines I think should be followed, although feel free to disagree :) I've also shown what I've done, and make some assets to help people get started.

I'd be interested to get any feedback/comments about the design - the Android Design Guide isn't very detailed on the design of sliding layout so I thought I'd have a go at doing the guidelines myself!
14
1
Jeremy Feinstein's profile photoAlex Curran's profile photoAkash Ramani's profile photoJoshwin Greene's profile photo
28 comments
 
Copied from your public post:

I don't think the left padding on the icons is necessary, but if its used, the header text should align with it. If you check out the standard header view, you will notice padding on the text, and not the underline.

Also, list items are typically 48dp or 56dp, what caused you to suggest 64dp? May throw off the rhythm in certain places.

I have to be honest, I really appreciate the effort here, but would be dismayed if all apps had the exact same look and feel. This is a good baseline, but I'm not sure that I agree that things like the scroll scale and offset should be standardized.

I believe that the only thing that should really be standardized is the open/close mechanism, and handling of the Action Bar. Consistency is good, but more important at the interaction level, than the visual.

Btw, "Sliding menus (SMs for short) should have paddings of 6dp on their left, top, bottom and optionally right edges." -- don't you mean 16dp?
 
Might as well discuss on this post - more people can join in!

The left padding is between the text and the icon itself, not the icon and the left side of its container. This gives the text a bit of breathing room with respect to the icon and makes it a little less bunched up. 

I don't think that 64dp is any less out-of-rhythm than 56dp (which, I've never used). I'd say it's better than 56dp because it's 1.25x the standard 48dp, rather than 1.125x, i.e. a less-divided fraction of the standard. I didn't use 48dp because sliding menus are generally not very informationally dense (exception being the G+ one), and so you might as well fill up the space. As an example, The Verge has a huge gap at the bottom because it has small items and there's no danger in simply making them bigger. 72dp would be better in terms of rhythm (1.5x48dp) but that's enormous. 

This isn't about making all apps looking the same, rather getting consistency in action. I really think that some consistency could - and should - be gained by having them the same size, with similar mechanisms etc. I did consider saying scroll offset and other similar items were non-optional but decided against it to get some variety. To argue the converse,- the ActionBar has a rigid set of guidelines on how it looks and acts, and whilst, yes, people's apps do look more similar following these, it makes it so much easier for users. Take a look at Pocket for example - it doesn't use a standard ActionBar, but because it follows the guidelines people know how to use it. iPlayer used to have a non-standard one and it was confusing for users.  

It's worth me reiterating, these aren't to be taken as gospel and a lot of the things (e.g. my quite-random 6dp padding rhythm) are arbitrary and more than open to improvement. This is meant to be a discussion of a) if we need such guidelines and b) how can we improve them. I remember how, before the official ActionBar arose, there were loads of different implementations, which all worked in different ways, and it was just confusing. This is simply trying to get past this stage in the sliding menu's development so users aren't trying to learn how to use what is essentially a moving target.
 
There is definitely padding to the left of the icon (relative to the list item). Perhaps this is unintentional, but its there (http://imgur.com/kitat). My point here is that the left side of the icons should be aligned with the left of the list header (in this case, "Sections"), whether or not there is padding used in the list item. (e.g. http://imgur.com/e7Tn5)

On "consistency in action": I completely agree, but this is not really what your article is talking about. You are proposing many ideas for visual/graphical consistency (use of shadows, what colors to use, perceived scroll offset, etc).

The Action Bar pattern was defined as navigation on the left, actions on the right, main icon can mean up, overflow means more actions. Those are interaction concepts, not graphical guidelines. Notice how the Action Bar guidelines do not mention color, shadows, etc. For example, nowhere in the doc is guidelines on what color the action glyphs should be.

If you read the guidelines for the Drawer pattern, whilst concise, it clearly explains the most important patterns for consistency (though it strangely lacks Action Bar guidance).

Also, I measured the padding and I'm pretty sure you mean 16dp on the top and left of the Drawer.
 
You're right, there is padding. That was indeed unintentional, but unfortunately can't be changed whilst using compoundDrawables. You could however, change the TextView for a TextView + ImageView, but you'll get Lint shouting at you. And yes, I do mean 16dp, I'll correct that in a sec.

The guidelines do in fact dictate what colours you should be using (http://developer.android.com/design/style/iconography.html#action-bar) hence why I chose colours which match these, to make it easier for designers and maintain consistency between ActionBar icons and sliding drawer icons. Likewise with colours, they're simply recommendations in line with the Design Guidelines ("Use color primarily for emphasis. Choose colors that fit with your brand and provide good contrast between visual components."). People are free to interpret these guidelines as they see fit, as I interpreted the ADG to suggest titles should be coloured. 

Whilst a lot of the things I recommend may seem purely visual, they aren't, or serve a more actionable purpose. For an example, use of a shadow subtly implies to the user which content is more important (not the sliding menu), and can also indicate how to return to the content if they missed the animation - "if the content is above the sliding menu, why don't I try sliding it back over"? I'll admit, the scroll scale is totally arbitrary and doesn't really matter, but a developer using the same values in their own apps will come across (to the few that notice) and having a good attention to detail and consistency. As for width - it's assumed that ActionBar's have consistent sizes (48dp on phones, 56dp on tablets) so why not maintain a consistent size here? I'm not sure developer are going to be able to differentiate against competing apps by making the SM 50dp larger.

Having no guidelines runs the risk of really confusing users. Not all users are tech-literate/super brainy. To take an example, if one app uses a SM with large titles and small items, and another has small titles and large items, there'll be some users which get confused. There will also be some others which say "hey, these things act the same, so why do they look so different?".

There's a reason everyone loves 4.0+ - it's much more consistent than previous releases. You'll see app reviews which praise apps for conforming to the guidelines, and chiding ones which don't. I don't really see any difference here. I may well be being restrictive with my guidelines (which, lets be honest, few people will actually follow), but I believe its better to be restrictive, and let developers explore outwards than have no starting point, which is where we are now!
 
The shadow is definitely a good point, that I hadn't considered.

The colors they suggest are "... for use with the Holo Light and Holo Dark themes." It goes on to say, "... the package also includes unstyled icons that you can modify to match your theme".

I'm also not so sure that I agree that users will be as easily confused as you suggest, but its important to note that there are already guidelines for lists and list headers (which you have mostly followed/emulated).

And in all fairness, there are already guidelines for the Drawer pattern. Perhaps not as robust as they should be, but IMO, the only real interaction guidelines that you have suggested (that should be added) are edge shadow, and static Action Bar. These are definitely important, and should be highlighted/separated in your article. The others are mostly style choices, or mimicking guidelines that have already been established (16dp padding, stand-out colors, list item heights, and list header styles are all already in the docs).

I think its a great initiative you have started, but fear that novice designers/developer will take your suggestions as rules, considering the lack of opposing views in the wild. This is why I think it would be best to separate your suggestions into interaction and style categories.
 
Also, one thing that we definitely need consistency on is the name. The name of this pattern is officially Drawer.

Considering that it falls under the Action Bar guidelines, perhaps a less ambiguous name would be "Action Drawer", or "Action Bar Drawer".
 
I agree with +Paul Burke that most of the guidelines for the metrics of these sliding drawers are found in http://developer.android.com/design/style/metrics-grids.html#48dp-rhythm. It's the interaction portion that really needs standardization.

Edge shadow and static ActionBar are a good start. I'm tempted to say that bezel swipe to expose should be considered standard as well. I like +Cyril Mottier's suggestion that there should be an alternate 'up' affordance used to indicate a sliding drawer is available. There's also the question of whether the drawer should be exposed on initial startup and/or show a quick bounce animation to let the user know it's there.

The biggest thing to standardize these aspects would be a common library that everyone pulls from. I don't think this should be a part of the SDK, but possibly the support library (look what that's done to standardize the ViewPager). +Jeremy Feinstein has a great library that seems to be becoming the de-facto standard implementation in much the same way ActionBarSherlock became the standard way to do an ActionBar on 2.x. What propelled ABS to its status, though, is that it wraps the native APIs when possible (for the drawer no such APIs exist), and that an ActionBar pattern is almost required for good Android design and is certainly a best practice. The Sliding Drawer is merely a navigation design decision.

As far as the naming of such a pattern goes, I would be against using the word "action" since it deals entirely with navigation and NOT action. The ActionBar is so called because its primary purpose is to contain ActionItems (and is thus the replacement for the old OptionsMenu). The navigation and branding aspects are secondary, though still important. Side Navigation seems to be a popular choice, and I would be on-board with that. Sliding Menu or Sliding Drawer also works, but is a bit more ambiguous. Neither specifies the type of items contained in it, and Sliding Drawer directly conflicts with android.widget.SlidingDrawer.
 
+Josh Brown One thing: The Action Bar houses navigation and actions. Also, the Drawer pattern is found in the Action Bar section of the docs.

If we think of the Drawer as part of the Action Bar, I guess it makes some sense why the "static" guideline is omitted.

The more I think about the shadow, the more I believe it is a stylistic choice (that helps to reinforce the metaphor). I think cut-off content is inherently enough of a visual queue to suggest a swipe, or at the very least, a touch. The Google+ app has the slightest of shadows, and it is the mechanism is perfectly clear. YouTube (the supposed model example) has none.

I think there's actually a contradiction to the Drawer pattern as a means of housing the top-level navigation. I plan to write a separate post on this tomorrow -- think it will be a good discussion.
 
The ActionBar is so called because its primary purpose is to contain ActionItems (and is thus the replacement for the old OptionsMenu). The navigation and branding aspects are secondary...

I have to disagree here. The Action Bar unified navigation and actions, while providing an overflow as the replacement for the old OptionsMenu. It also introduced an alternative navigation metaphor (to tabs).

If you were previously putting your most important actions in the OptionsMenu, you were doing something very wrong. To say that the navigation aspect of the Action Bar is secondary seems pretty inaccurate to me.
 
The ActionBar as it evolved in 2010 (i.e. pre 3.0) was primarily a way to get your more commonly used menu items to have some screen real estate. There was no overflow menu yet since there was no easy way to tie your ActionBar and your OptionsMenu together. None of the navigation modes had even really been considered at the time, and the only navigational function it served was as an app-centric home button for the top left (in the same way that clicking the top left of a website often takes you back to the main page of that site). The navigation features the ActionBar now has evolved from that including the idea of 'up' navigation.

Also the Overflow Menu is not a replacement for the OptionsMenu. ActionItems are its replacement, and the Overflow Menu is simply a place for ActionItems that don't fit on the screen (or in some cases should be less discoverable/intrusive). This is evident both in the API for ActionItems (which is exactly the same as the old OptionsMenu) and the naming of the Overflow Menu (for items that overflow the visible space in the ActionBar).
 
I disagree that only interaction needs to be "standardised" here, not UI. You've both commented that most of my guidelines are derived from the standard UI guidelines which is true - that's the point. But then, why are the implementations so radically different? Apps using the same implementation (e.g. Falcon Pro & The Verge) have very different UIs and you wouldn't guess that they used the same library, so simply using the same library (which has such a large scope) isn't enough, as Josh suggested.

The point of these guidelines is to give people a platform to start off, and move from there. Paul, you say that novice users may take these as gospel. But that's the point - novice users take the official guidelines as gospel too. They don't deviate from that at all. Once you get better as a developer/designer, you find new things that work, but until then there has to be something you're aiming at else you're completely on your own. The amount of different implementations is dizzying at the moment and even if it has the potential to confuse users, then its an issue. 

I'm not sure where this discussion about naming came from, but I think Sliding Drawer is fine. Personally, I believe this should only be used for menu-like implementations (and so could be Sliding Menu), but I suspect a lot of people will disagree with me. There is a previous SlidingDrawer widget but I haven't seen it used since the 1.x era, and so I don't think any confusion will occur. I also think that this new pattern has absolutely nothing to do with the ActionBar, and so shouldn't really be in the ActionBar guidelines (I suspect it is just there for convenience).

In regards to the comment "If you were previously putting your most important actions in the OptionsMenu, you were doing something very wrong", there wasn't really any choice before the ActionBar (and the previous similar implementations) came about. The issue came, when before 3.0, there was no single consistent implementation, which is where we are now with the SlidingWhatever. I remember the first two apps to implement some sort of Action Bar were Twitter and Facebook, and neither was very similar to the other. Then more implementations came along and it suddenly got very confusing as you had to learn what each one did when it came to each app, where the buttons were etc. Then the new API came about with it's fixed size ActionItems, and titles, and standard placement of the home and overflow buttons and it sorted itself out. My guidelines are about this, about making it easier to work out how one SlidingWhatever works from using another, and familiarity of UI is a big part of that.

You currently can't tell how the sliding menu from Facebook works by using the one in Google+ or YouTube, and that's not a good place to be. I'll admit here that some of the interaction parts I've missed out (e.g. how it should open & close), and I'll add that tomorrow.
 
API implementation and design interaction concepts are very, very different things. It is true that you add all actions to the Action Bar through the same API as the OptionsMenu, but that really does not reflect the way that the Action Bar is described in the docs, and what it has evolved to be. That has to more do with graceful backwards compatibility, than is does defining the concepts.

That's why we now have the design guidelines. And if you really want to get SDK specific, MenuItems have a parameter that allows you to tell whether an ActionItem should always be on screen. The fact that phones with hardware menu buttons show only the items that get pushed to the Action Overflow (not Overflow Menu) should be enough indication that it is what replaced the Options Menu. The overflow is also commonly used, not only, for less-important actions, but also for navigation items (e.g. Settings). 

Before the official Action Bar implementation, the most important actions where exposed in content, not in the Options Menu. The history of the Action Bar is surely less important than the official guidelines and system implementation.
 
And apologies to Jeremy, who for some reason I've called Jeff all the way throughout this thread and in the post...
 
The point about apps having a different look for their drawers, while valid, is in my opinion a little off the mark. I think this is something to be celebrated rather than discouraged. When the Dashboard pattern was in vogue each one looked radically different from the next, and that was a good thing. There's actually a lot in common between the Dashboard pattern and this one. If you get rid of the pretty animation and interaction ideas what you end up with is pretty much a dashboard. In many ways this pattern has been done to serve as a replacement for the aging dashboard pattern.

A lot of the implementations use a list and makes sense in certain contexts, but look at Evernote. Theirs is very clearly a dashboard and I think it works well for them. They've got some other navigation issues and inconsistencies, but their overall approach and styling is spot on. A standardized list would get old very quickly, and you may as well use ListNavigation in the ActionBar if that's all you'll ever do. The thing I like most about Google+'s implementation is that they've used their drawer for more than that.

The important thing here is that the drawers BEHAVE the same. That the user knows that if he bezel swipes the drawer will appear. The reasoning for a static ActionBar has more to do with the behavior of the bar rather than the nature of the drawer. The ActionBar almost lives in a realm outside the app propper and becomes more of a semantic manifestation of the system's UI rather than the app (in much the same way the old OptionsMenu's UI was really provided by the system rather than the app. That's a key portion of the concept rather than just an implementation detail). The edge shadow is there to illustrate some of the metaphor (which should be consistent) of this drawer rather than some stylistic concept.
 
But there's the crux - none of them do act the same. G+, YouTube, Falcon Pro, Attitude, Facebook and The Verge all have sliding panels and all act, and look different, and you can't tell how to use one from using another. Sure, I've gone for quite a lot of UI guidelining, but interaction mechanism isn't the be-all and end-all of consistency, and the official guidelines aren't robust enough to be able to unify implementations.

I'm glad you mentioned Evernote because in my opinion its the worst implementation stylistically. I've only used in on the N7 where the panel doesn't slide so I can't comment on its interaction, but why have four, big buttons instead of two similar looking lists? Here there's no consistency inside their drawer, let alone with other drawers. I just think the buttons look really out of place on that menu, but, as I said above I don't believe the panel should be anything (much) more than a menu.

In regards to a standardised list getting old, no one complains about most Action Bars looking the same, and I can't see why this would be any different. I'm not saying "your sliding drawer must look like this", as I've reiterated multiple times, but "think about trying to align your style with this". Because currently its a total mess.
 
There is no problem with suggesting style, all I was saying is that many of your style suggestions actually just mimmic the official, respective, ones. Some others are, in my opinion, overbearing (colors, scrolling, icons, fonts), but some are great (list selectors, contrast to Action Bar).

The style implementations out there are different because if they were all the same things would be really boring. The interaction implementations out there are different because most of them were created before there were guidelines. However, The new guidelines are pretty clear, while lacking, so the (developer/designer) confusion is no longer justified.

We all agree that the interaction patterns should be more detailed. My main point is that it would have been beneficial to discuss the interaction suggestions as separate from the style suggestions, so its more clear what is flexible. I also just happen to disagree that the shadow is an interaction suggestion. :-)
 
The ActionBar is supposed to fade out of the user's consciousness until they need to use it whereas the drawer is a primary interaction point. Nobody complains about it looking the same for the same reason nobody complains about the NavigationBar always looking the same: it's not part of the "main window" to the user (to developers this is the contentView of the Activity). The drawer definitely is and is a chance to be a hero moment for the app.

Evernote on the phone has some issues, but the thing that made them stand out to me as something that really WORKS is that they fully embraced a dashboard for their panel. Lists were the things that dashboards replaced long ago. It pains me that we're going back to them. YouTube actually became less navigable to me when they made the change.
 
There's no question that there's a lot of inconsistency with the panels, but the contents of the drawer should not be a point to standardize on anymore than the contents of the main views is. The physics and interaction model of how the drawer works should be the same, but what is in the drawer should vary from app to app. Lists definitely don't work for everyone, and even when they're used they should be styled and branded to be consistent with the rest of the app. And to that degree the design guidelines already go over how to style a list extensively.
 
Ah, we've found our proper disagreement :) see, I believe that the sliding panel isn't part of the main UI. I essentially think it is somewhere to hide things you need access to quickly, but that are too busy/numerous to be placed front and centre. For example, Google+ would look a nightmare if all those options were as a drop down in the Action Bar! This is the sticking point - I see the drawer as simply another piece of UI chrome, whereas you don't. E.g. in my apps, its generally replaced the drop down navigation on the Action Bar, rather than some sort of snazzy dashboard.

Paul, you say that the UI guidelines are clear and so confusion is no longer justified. But there still exists implementations which don't follow these guidelines (G+ in fact being one of them). Another of the aims of my guidelines was to cement the few official guidelines we're given and, essentially, try to make people follow them. It probably won't work, but we can hope! I'll separate out the interaction and stylistic guidelines tomorrow, and we can try to refine them further.
 
As an added point - I don't see this as suitable replacement for a dashboard because with a dashboard, there is a single tap to get anywhere. With a sliding drawer, there is a slide and a tap, so it takes longer to get to your destination. Also, if you have a nice looking dashboard, why are you hiding it away?!
 
+Alex Curran If you follow the normal guidance with dashboards to start at the main point of interaction (i.e. one level below the top), it pretty much behaves exactly the same (ignoring the swipe to expose gesture which isn't even used universally). In both places tapping "up" takes you to the navigation page (either the dashboard or the drawer) and then one tap from there takes you to the new section. There is some slight differences in back button behavior, but right now that's still a point of confusion. Some implementations of the drawer believe that back should open the drawer if it's not already open (these more closely mirror a dashboard); others believe it should close the drawer if it is (this seems to be where the pattern is heading). 
 
The reason a lot of designers hide their dashboard in the drawer (and often convert it into a list) is that dashboards are seen as the "old way". While I agree a normal dashboard pattern on its own is dull and boring, if done intelligently I still think there's a place for the pattern. The best example I've found is SoundHound.  It presents its content in a way that's new and exciting while maintaining the "home" feeling that a dashboard gives the user.

The old G+ dashboard, the FriendCaster dashboard, and many others come off as boring because they just use a standard grid of icons. There's nothing about them that screams "click right here" the way SoundHound's listen button does. They bring only a little bit of content forward rather than the hero carousel that SoundHound has. Basically their dashboards have all the same problems that a sliding drawer has, but because the sliding drawer has some pretty animations people are willing to overlook that for now. The only exception is that most implementations start one level down... exactly the way dashboards should be done.
 
See I wouldn't class SoundHounds main page as a dashboard, just a main page. A dashboard to me is a consistently styled grid of icons with similar hierarchical standing (I.e. one is no more important than the others). In SoundHounds case, the Listen button is obviously much more important than the history/settings buttons and other items, so its not a dashboard. But hey, this is a totally different discussion and not helping to thrash out some guidelines for sliding drawers :-)

So, in terms of how the SM should act, what do you think? The issues of confusion are margin vs full-screen opening, whether Up accordance is required, and what the icon should be, what the back button does. There's likely some other things to discuss but I can't remember them at the moment. My recommendations are:

- No preference for margin vs full-screen slide, I like margin but its less discoverable
- Require an Up indicator, I am going to create a library today which, I think, will improve the ambiguity of the standard up icon
- I think the back button should close the drawer if its open, and perform the standard action otherwise.

Thoughts?
 
Just took a look at the article. It seems full of lots of good feedback and recommendations. Two things : my name is Jeremy (not Jeff :P) and would you mind including a link to the GitHub repo for SlidingMenu?
 
Yeah, sorry about that, I did apologise in a comment above! Have added the link too. 
 
Wow! +Alex Curran +Josh Brown +Paul Burke You guys really do make good points of discussion, i just read the entire conversation :)

My contribution:

1. In the case of a static action bar and the sliding menu / sliding drawer / action drawer sliding right below the action bar, is there a way to temporarily disappear overflow menu items which are on the right hand side of the actionbar? Basically having a static action bar IMPLIES that any "actions" are higher priority than the sliding drawer right?

2. Here is a question which puzzles me, is the sliding drawer something to be used in apps which dont have large back stacks, only probably 2 or 3 levels down or is it independent of the "depth" of the app?

3. I really like the drop shadow suggestion though it need not become a standard. What should become a standard is there should be a very clear differentiation between the sliding drawer and the content. IMHO, the sliding drawer should always seem to appear UNDER (think layers) the main content view.

4. No preference for margin vs full-screen slide, I like margin but its less discoverable - Why is this approach less discoverable?

5. They should be able to be open and closed by the Home icon, in the highest level of the app only. (from the website) - I really think this guideline will help ONLY if you want to achieve high level navigation. Being able to access it from ANY screen is a way to achieve GLOBAL navigation. Rather than calling it guidelines, i think you could highlight that these are the two use cases :)

6. The back button should close the SM if it is open, but perform the standard back action if it is closed (from the website) I for one don't agree with this AT ALL! I think the HIGHEST level and ENTRY and EXIT points for an application should with the sliding menu being in an opened state. I know this might be an unusual activity but i truly believe this is the way to go (this concept is only for apps which use the sliding drawer as main navigation menu and not contextual menu [for which the action bar menu can be used]). I am going to try this out in my own app :)

7. I have a question about confusing usage of tabs with swipe support and the sliding drawer which can be opened by swiping. For example in the case of the verge app. I have to swipe all the way to the left tab and then swipe again to open the sliding drawer. How do you suppose one can handle this situation? ( i know the home button could be used to open the sliding drawer, but i'm talking purely about gestures)
Add a comment...