Via : OpenAndroid.in
Tags : #Andoird, #LIABRARY, #Source_Code, #Tips__Tricks, #UI_Design
Orginal Post: Emerging UI Pattern - Side Navigation
Android UI has been improving with a phenomenal speed in the last year (I composed a small gallery of some apps I really like in Google+). Many of the changes has been only cosmetic (holo theme, Roboto font, etc). We haven't seen large changes in the way user interfaces are designed beyond that. We might have one such change happening now though.
The facebook's side navigation was recently picked up by few apps nearly simultaneously. First we saw the Spotify redesign using it and shortly after the Evernote redesign. Not long after that the Google+ redesign also embraced the side navigation design pattern.The implementation in each of the apps is very different. The navigation look and feel different but the underlying approach is the same. The idea is to provide users quick shortcuts to the most important part of the application without having to leave the screen they are on.
The visual differences of the implementations are very apparent. The Google+ app slides the navigation on top of the UI while the others move the UI to the side. Google+ also has the up caret icon and the action bar present when the menu is opened while other apps don't.
There was a interesting discussion about this pattern in the blog's Google+ page some time ago. You can find the post & discussion here: Google+.
The side navigation replaces the much criticized dashboard pattern in the apps. The major criticism towards use of dashboards has been that it slows users down on their way to the app's content. Every time you launch the app you must first tap an icon to get where you want.
The Dashboard also requires users to come back to the app's home screen to navigate to other parts of the app. Here's a abstract wireframe of a generic Android app with a dahboard and one section of the app is a list of items and tapping any of the items takes the user to an item details screen (a very common mobile app structure). in this example the user first selects an item from the dasboard, then selects one of the list items and moves to another item from the first item.
This example demonstrates the difficulty of navigating between app sections in a dashboard app.
.png)
The new side navigation removes both of the problems. Users can directly access any major part of the app without having to move back up in the activity stack first. Therefore the app can launch directly yo one of the primary screens instead of to the dashboard providing users content directly.
The following example wireframe is the same app transformed to use the side navigation. Firstly, the app's landing screen has content visible and the user can access the other parts of the app directly from any screen.
I believe that the side navigation is superior to the old dashboard concept. There might still be use for the dashboard but use for it will be much more limited. In rare cases it might be impossible to select any of the app's screen as the landing screen. In those cases a dashboard might still be a good option. Aos, massively complex apps might make it easier for first time users to get hang of the app by presenting a non-intimidating dashboard instead of an overwhelming screen when they first start the app.
It might be time to say good bye to the pattern that was one of the identifying symbols of Android UI not so long ago.
more after the break..
Unfortunately, getting the side navigation right is much more difficult than getting a dashboard right due to the increased complexity.
I've never been fan of the up concept in Android. I think it is impossible for users to differentiate between up and back. Google deciding to use an arrow pointing left to indicate up isn't helping that. Every user I've talked to refer to the top left button as the back button.
In my opinion using the side navigation makes up obsolete and unnecessary. If your app is well structured and you provide an easy access to any of your app's main screen through the side navigation from any screen users are never more than few clicks away from any screen. The phone's back button still takes care of most of the navigation needs anyways.
If you look at the Google+ app and how the side navigation works you'll find out that you must first "up" your way back to one of the category home screens to be able to access the side navigation. I think that this defeats the purpose of it. If I'm, for example, reading one of my feed items and suddenly want to start a hangout why do I have to go back to the streams screen to be able to navigate to the hangouts?
Instead of an up button I would much rather see the top left home icon on the action bar opening the side navigation always no matter on which screen you're on.
If you decide to use the up anyways you should make sure not to use the up caret when the side navigation will be opened by the home icon. Using the same left arrow than up functionality uses breaks one very fundamental user interface design guideline: it should always be obvious what a button does on a UI. The up button (which is already not that clear) can suddenly have two very different functions and user cannot tell which one it is without trying the button.
I think we need another icon for the side navigation as part of the operating system that will bring consistency to this concept. Here's a very crude draft of what I mean. The first picture shows how the home button looks like when it is an up button (this is the current look). The second picture is a draft how it could look when the home button is used to open the side navigation. This would save users from confusion in apps that choose to use both up and side navigation.
Managing back stack correctly is very important. The side navigation concept can make the back stack even more complex. Alexander Blom has written few good blog posts about this subject. I recommend you to check them out:
Android navigation and Spotify (with friends)
Slide-out navigation done better
How should users be able to open the side navigation? What gestures and buttons should be used?
The side navigation is probably the most important component in any app that chooses to use it. Users won't be able to navigate in the app without knowing how to open it.
After experimenting with all the apps I found using this pattern I feel that none of them have got it quite perfect. The closest one I feel is the Prixing app. This app has abandoned the concept of up and made the app's home button a dedicated button opening the side navigation.
This app also has added a gesture shortcut for accessing the menu. Users can perform a bezel swipe to open it. While bezel swipe can be a difficult gesture to find it isn't a problem in this case as any user can reach the same results by tapping the home button. (I wrote about bezel swipe some time ago. Here's the article.)
The only improvement I'd like to see in this app would be to still use the app icon as the home button maybe adding some additional icon showing that the button has this functionality.
Other apps are using different methods to open the side navigation. Evernote for example uses a swipe on the user interface. This causes some consistency problems as swipe is already reserved gesture for moving between tabs. As evernote is using tabs in some parts of its UI the side menu is not accessible via this gesture unless the user is on the leftmost tab.
My recommendation for opening the side navigation is to always open it from the home button (ditch up) and support bezel swipe as a shortcut for the same function. If you must use up in your app make sure that the icon is different when the up button turns into the side navigation button.
.png)
We might have to wait for Google to name this pattern before one of the names gets established. A democratic process is probably going to fail here. For now, I'll be calling it side navigation but I'm open to changing it once one name gets established.
The side navigation isn't (yet) included in the Android SDK. A quick search in github does reveal one project that has implemented the UI pattern.
android-fb-like-slideout-navigation at github
There's also a video demonstrating the library at work.
EDIT: Here's another library project:
https://github.com/darvds/RibbonMenu
Thanks Mr BuBBLs in comments!
Two more library project:
https://bitbucket.org/jfeinstein10/slidingmenu/overview
https://github.com/Gregadeaux/android-fly-in-app-navigation
If you know any other library projects doing this please leave a comment bellow or at the Google+ page!
Cyril Mottier has also written about implementing this pattern in his blog. These posts are very much worth reading:
The making of Prixing #1: Fly-in app menu
The making of Prixing #2: Swiping the fly-in app menu
The making of Prixing #3: Polishing the sliding app menu
See also the Prixing app on the Google Play to try out the side navigation implemented by Cyril.
I think this is a good step forwards in the Android UI design. We must be extremely careful not to create an unmanageable mess of different implementations that will look the same but function differently confusing the users.
The Google I|O is also just around the corner. We will likely see the next Android version getting announced in the event. I'm hoping that Google continues their push of getting these more complex components into the operating system (like they did with Action Bar in ICS / Honeycomb). I'm hoping that we'll see a side navigation component as part of the new release bringing consistency to the implementations.
The visual differences of the implementations are very apparent. The Google+ app slides the navigation on top of the UI while the others move the UI to the side. Google+ also has the up caret icon and the action bar present when the menu is opened while other apps don't.
There was a interesting discussion about this pattern in the blog's Google+ page some time ago. You can find the post & discussion here: Google+.
DASHBOARD IS DEAD(ISH)
The side navigation replaces the much criticized dashboard pattern in the apps. The major criticism towards use of dashboards has been that it slows users down on their way to the app's content. Every time you launch the app you must first tap an icon to get where you want.
The Dashboard also requires users to come back to the app's home screen to navigate to other parts of the app. Here's a abstract wireframe of a generic Android app with a dahboard and one section of the app is a list of items and tapping any of the items takes the user to an item details screen (a very common mobile app structure). in this example the user first selects an item from the dasboard, then selects one of the list items and moves to another item from the first item.
This example demonstrates the difficulty of navigating between app sections in a dashboard app.
.png)
The new side navigation removes both of the problems. Users can directly access any major part of the app without having to move back up in the activity stack first. Therefore the app can launch directly yo one of the primary screens instead of to the dashboard providing users content directly.
The following example wireframe is the same app transformed to use the side navigation. Firstly, the app's landing screen has content visible and the user can access the other parts of the app directly from any screen.
I believe that the side navigation is superior to the old dashboard concept. There might still be use for the dashboard but use for it will be much more limited. In rare cases it might be impossible to select any of the app's screen as the landing screen. In those cases a dashboard might still be a good option. Aos, massively complex apps might make it easier for first time users to get hang of the app by presenting a non-intimidating dashboard instead of an overwhelming screen when they first start the app.
It might be time to say good bye to the pattern that was one of the identifying symbols of Android UI not so long ago.
more after the break..
SIDE NAVIGATION PROBLEMS
Unfortunately, getting the side navigation right is much more difficult than getting a dashboard right due to the increased complexity.
Up?
I've never been fan of the up concept in Android. I think it is impossible for users to differentiate between up and back. Google deciding to use an arrow pointing left to indicate up isn't helping that. Every user I've talked to refer to the top left button as the back button.
In my opinion using the side navigation makes up obsolete and unnecessary. If your app is well structured and you provide an easy access to any of your app's main screen through the side navigation from any screen users are never more than few clicks away from any screen. The phone's back button still takes care of most of the navigation needs anyways.
If you look at the Google+ app and how the side navigation works you'll find out that you must first "up" your way back to one of the category home screens to be able to access the side navigation. I think that this defeats the purpose of it. If I'm, for example, reading one of my feed items and suddenly want to start a hangout why do I have to go back to the streams screen to be able to navigate to the hangouts?
Instead of an up button I would much rather see the top left home icon on the action bar opening the side navigation always no matter on which screen you're on.
If you decide to use the up anyways you should make sure not to use the up caret when the side navigation will be opened by the home icon. Using the same left arrow than up functionality uses breaks one very fundamental user interface design guideline: it should always be obvious what a button does on a UI. The up button (which is already not that clear) can suddenly have two very different functions and user cannot tell which one it is without trying the button.
I think we need another icon for the side navigation as part of the operating system that will bring consistency to this concept. Here's a very crude draft of what I mean. The first picture shows how the home button looks like when it is an up button (this is the current look). The second picture is a draft how it could look when the home button is used to open the side navigation. This would save users from confusion in apps that choose to use both up and side navigation.
Back stack problems
Managing back stack correctly is very important. The side navigation concept can make the back stack even more complex. Alexander Blom has written few good blog posts about this subject. I recommend you to check them out:
Android navigation and Spotify (with friends)
Slide-out navigation done better
WHAT OPENS THE SIDE NAVIGATION?
How should users be able to open the side navigation? What gestures and buttons should be used?
The side navigation is probably the most important component in any app that chooses to use it. Users won't be able to navigate in the app without knowing how to open it.
After experimenting with all the apps I found using this pattern I feel that none of them have got it quite perfect. The closest one I feel is the Prixing app. This app has abandoned the concept of up and made the app's home button a dedicated button opening the side navigation.This app also has added a gesture shortcut for accessing the menu. Users can perform a bezel swipe to open it. While bezel swipe can be a difficult gesture to find it isn't a problem in this case as any user can reach the same results by tapping the home button. (I wrote about bezel swipe some time ago. Here's the article.)
The only improvement I'd like to see in this app would be to still use the app icon as the home button maybe adding some additional icon showing that the button has this functionality.
Other apps are using different methods to open the side navigation. Evernote for example uses a swipe on the user interface. This causes some consistency problems as swipe is already reserved gesture for moving between tabs. As evernote is using tabs in some parts of its UI the side menu is not accessible via this gesture unless the user is on the leftmost tab.
My recommendation for opening the side navigation is to always open it from the home button (ditch up) and support bezel swipe as a shortcut for the same function. If you must use up in your app make sure that the icon is different when the up button turns into the side navigation button.
ACTIONS IN SIDE NAVIGATION
I've been talking about navigation but many of the implementations go beyond navigation. To me it makes sense. The action bar is the place for contextual actions for the screen the action bar is on. What if your app has some actions that are so important that they should be reachable from any screen?
Evernote has solved the problem by introducing actions in the side navigation. I think their implementation is great. It can be slightly overwhelming at the first use but the clear sectioning of actions and navigation is making it easy for the users to quickly to form a good mental model of the navigation and actions.
.png)
WHAT TO CALL IT?
Naming patterns in a descriptive and consistent way is important. One of the benefits of patterns is that they can easily be used in discussions by simply referring them by their name. For established patterns no further descriptions are needed. "Maybe we should use action bar in the UI" or "How about quick actions in this list" are self explanatory sentences.
So what should this pattern be called? I've been referring to it as "side navigation" in this post but there are many, many more names for it.
- Side navigation
- Fly-in app menu
- Slide out navigation
- Sliding navigation bar
- Slide menu
- ...
We might have to wait for Google to name this pattern before one of the names gets established. A democratic process is probably going to fail here. For now, I'll be calling it side navigation but I'm open to changing it once one name gets established.
TECHNICAL IMPLEMENTATION
The side navigation isn't (yet) included in the Android SDK. A quick search in github does reveal one project that has implemented the UI pattern.
android-fb-like-slideout-navigation at github
There's also a video demonstrating the library at work.
EDIT: Here's another library project:
https://github.com/darvds/RibbonMenu
Thanks Mr BuBBLs in comments!
Two more library project:
https://bitbucket.org/jfeinstein10/slidingmenu/overview
https://github.com/Gregadeaux/android-fly-in-app-navigation
If you know any other library projects doing this please leave a comment bellow or at the Google+ page!
Cyril Mottier has also written about implementing this pattern in his blog. These posts are very much worth reading:
The making of Prixing #1: Fly-in app menu
The making of Prixing #2: Swiping the fly-in app menu
The making of Prixing #3: Polishing the sliding app menu
See also the Prixing app on the Google Play to try out the side navigation implemented by Cyril.
FUTURE
I think this is a good step forwards in the Android UI design. We must be extremely careful not to create an unmanageable mess of different implementations that will look the same but function differently confusing the users.
The Google I|O is also just around the corner. We will likely see the next Android version getting announced in the event. I'm hoping that Google continues their push of getting these more complex components into the operating system (like they did with Action Bar in ICS / Honeycomb). I'm hoping that we'll see a side navigation component as part of the new release bringing consistency to the implementations.
SUMMARY
I'm a fan of the side navigation concept. It is, however, very easy to get it wrong. If you decide to include it in your app be aware of the potential problems. Design the back stack, gestures, relationship with up and visuals very carefully.
Via : OpenAndroid.in
Tags : #Andoird, #LIABRARY, #Source_Code, #Tips__Tricks, #UI_Design
Orginal Post: Emerging UI Pattern - Side Navigation
0 comments:
Post a Comment