Navigation with Up and Back buttons is quite complicated (at least for me)
As the android documentation states,
You have the ability to make the Up behavior even smarter based on your knowledge of detail view. Extending the Play Store example from above, imagine the user has navigated from the last Book viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies) which the user hasn't previously navigated through.
http://developer.android.com/design/media/navigation_between_siblings_market2.png
I am exploring Google IO 2013 application for best practices and as far as I can see the mentioned above navigation rules are not taken into consideration.
Here is the picture:
https://dl.dropboxusercontent.com/u/6129677/do_not_delete/iosched2013.png
I launch the app and the main screen opens (#1). I tap on 'Browse sessions' -> second screen opens. Then I tap on a session - its detailed view is opened (#3). UP button says that this is 'Google+' category, and I expect to navigate to list of 'Google+' sessions after clicking on this button. Instead, the first screen is opened again (see picture).
Is this a correct behaviour and I am missing something?
Android design says that the up button goes up to the container regardless of what the icon is. It also says that the icon in the top left should be of the app. So in this case you could say that it violates the design by having a g+ icon.
That being said it is okay to violate android design if you have a specific reason to, in this case Google decided that it would like to show the icon of the category to give the user an indication of what category is without having to show 2 icons. In this case, they didn't want to alter the design all the way so as to go back to g+, but to assume the user understands that they are replacing the app icon with the category icon. So while they could show your 4th screen, they aren't necessarily required to and it depends on what you think will be best for user flows. Android design is meant to guide your individual design and doesn't need to be followed strictly (though it should be most of the time).
Hope that helps, I'm happy to answer any follow up questions.
Related
I'm coming from the iOS world and need to port an app with the typical tabbar/navigation pattern to Android. The UI design is the client's decision, so I can't change it (I'd still like to hear from you if you think it's appropriate or not for Android).
So the idea of the app is the following:
3 Tabs are always shown on the bottom of the screen. Inside each tab there can be a hierarchy of screens, with the title and up-button showing in the action bar on the top.
How do I implement this in Android? Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity? How should the hardware back button behave? Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
As you can see I'm struggling with all these basic concepts and I'm very thankful for any tip that can help me to implement this navigation structure.
Edit:
Thanks to the competent answer of CommonsWare and looking deeper into it, I realise that I really should push the client to use an UI that's more suitable for the platform. (Also, I know I should use an Android device for some time to get used to the concepts, but I can't change that for now. So I'm sorry for these newbie questions).
The thing is, the app existed before as a web container app with an ugly jquery mobile UI with the above described UI elements. The idea is now to make the app navigation native with native animations, while keeping the content views in html/css/js inside webviews. So while it's possible to adapt each platform's UI principles, I cannot change the general structure of the app, which is: 3 different main entry points, and in each of them the content is navigated hierarchically. I've implemented that in iOS with a tabbar and navigation controllers which works great. The challenge is now to implement it in Android. To reassure that I'm on the right path and understood the points of CommonsWare correctly as well as to maybe receive more tips, I'm writing down what my thoughts on the steps involved:
As CommonsWare suggested, I could replace the tab idea with action buttons in the action bar, which will work well as there are only 3 of it. So it's appropriate to use action buttons for navigation? There will be an additional button for switching the language (Yes I know, usually I should pick the current language of the system, but in this particular app language switching is important and the user will switch it several times while using the app). To separate the navigation action buttons from the language switcher, which works on the current content and is a bit less important, I put the language switcher under the so-called "action overflow" (the 3 dots on the upper right corner).
Now there is an action bar button for each "tab", so far so good. But is there a way the user can tell on which "tab" he is? Or should I only show two action bar buttons at any given time, hiding the one he's currently "in"?
Each of these action bar buttons starts a new activity (with it's own action bar, right?). Inside such activity, the user can navigate hierarchically and back using the up button or back button. He can also use the hardware back button to go back to the last "tab"; would this be appropriate?
Every screen in the navigation hierarchy is a separate activity with a title and a webview.
In the end, to make the whole app compatible back with gingerbread, I would use the actionbarsherlock library, right?
3 Tabs are always shown on the bottom of the screen
That violates the Android design guidelines. On Android, tabs go at the top.
Inside each tab there can be a hierarchy of screens
Outside of a Web browser, I truly detest this navigation concept.
Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity?
You do not appear to have more than one activity in your proposed design.
Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
And this is one of the reasons why I truly detest in-tab navigation. Tabs are for presentation of content, not as a navigable container in their own right.
should it mirror the up-button's functionality?
Since you do not appear to have more than one activity, it is unclear to me that you even have an up button.
How do I implement this in Android?
Ideally, you dump the tabs and use action bar items to switch between the different navigable areas, each of which would be its own activity. In that case, back (and to a lesser extent up) will flow more naturally.
If you had more than three tabs, you might go with the navigation drawer pattern, with the navigable areas each having an entry in the drawer. Three, though, would make the drawer look rather empty.
There is plenty more on app structure in the Android design guidelines that can help.
The UI design is the client's decision, so I can't change it
The objective of an app is to allow the users to accomplish their objective. Using design patterns native to a platform help in this regard, by allowing the users' existing experience to guide them in the use of the new app. This is not to say that true innovation beyond the guidelines is inappropriate, but it requires experience and deft hand.
Your client appears to be saying, "hey, this one firm came up with a design pattern for their platform, so therefore let's use it everywhere, as we want a consistent UI design". The problem is that nobody cares about consistency between platforms except them. Few people own mobile devices from multiple platforms, let alone use the same app on both, let alone expect the same UI design on both. Certainly, design touches (e.g., color scheme) could be similar, and the objectives of the app will be similar if not identical. But the delivery of that functionality should use design metaphors and patterns that are native to each platform, as the user is far more important than is your client.
(and if your client says "well, we are the users", because this is an internal-use-only enterprise app, kindly explain to them the concept of the passage of time, introduce them to the notion of employee turnover, and point out that they won't be the users all that long compared to the possible lifetime of the app)
Your client, if they ran a US-based car rental agency, would argue that their firm should rent left-hand-drive cars in the UK, for a consistent UI experience, despite all the accidents that will cause in a left-hand-traffic country.
Now, let's pretend for a moment that you need to write this app following their UI design anyway. Hostages are being held at gunpoint, somebody has a nuke on a hair trigger, the bad guy is demanding the app, the clock is ticking, you're Kiefer Sutherland, and so on.
(and if you really are Kiefer Sutherland, ummm... hi!)
You will wind up with a single activity for this core UI. Ancillary stuff (e.g., preferences, help) would be separate activities, but the three-tabs-to-rule-them-all UI would be in one activity.
The tabs themselves probably would use a FragmentTabHost, perhaps with modifications to better support tabs on the bottom. This is not a common choice, but it's the best fit. ViewPager and a tabbed indicator would be another possibility, if the client does not consider a horizontal swipe to change tabs to be "the devil's gesture" or something. Action bar tabs are at the top and are not always tabs, as they sometimes convert to drop-down navigation in certain screen size and orientation combinations.
Each tab would be a fragment and most likely would use nested fragments for the in-tab navigation between panes of content. Again, there are other possibilities (e.g., lots of hiding and showing of widgets within a single fragment to handle the navigation), but I think you'll go crazy trying to manage all of that.
With respect to the BACK button, without knowing the context of the tabs, my gut instinct would be to follow the tabbed browser metaphor of "BACK is local to a tab". I think that you'll need to manage this manually, unless it magically works because you are using nested fragments, and I don't think that's the case. When you are at the beginning (nested) fragment for a tab, and the user presses BACK, exit the activity.
what is the best practice regarding the back button currently?
A lot of apps save and restore an entire activity stack when you open them (after they've been onStop and onDestroyed), take Facebook for example, when you open it and your last place was in a photo, then pressing back doesn't close the Facebook app, it takes you back infinitely till the very first thing you did when you opened the app days ago.
This design convention is a little different than what the back button would be expected to do, I think. Where it typically is used to kill the app or stop the main view taking you back to your device's launcher screen.
Facebook was just one example of an app doing this.
Are there developer articles or an authoritative source like Google I/O discussing the utility of this feature (restoring activity stack and having back button traverse through them) vs other functionality (killing the view taking user back out of the app)? If so, please discuss and link them here. I hope this isn't considered too subjective because there is a proper use of the back button as well as an incorrect use
What the Facebook app does actually is the basic default behavior of Android. Those apps don't do anything special regarding that behavior. The Activity stack is saved by default.
One of the more cited blogs regarding it is CommonsWare's BACK means Back. Basically, the functionality of the "BACK" button means it should to take you to the previous page that you just were at. In Android, this is very often the last Activity you just pushed. If the user wants to leave the app, then he or she can press the "HOME" button and that will always push the Activity stack and take the user to the homescreen.
What this means is, the functionality of the BACK button is entirely dependent on the app in question, but the concept is to reverse the action that the user just did. If you are in a game, you go to a sub menu, the BACK button should take you to the top menu. If you are in a browser, the BACK button may take you to the last webpage you were viewing. If you are in a browser and you are in the top page, the user may expect the BACK button to close the app since the last action the user did prior to opening the browser is open the app. If the user starts a download, the BACK button may be to cancel it.
One functionality improvement that Facebook and others like is may consider is to wipe the stack after x number of days since the user may not remember exactly what they did since being interrupted from the last use. The use case for this is very small though.
Overall, this is why people always stress usability testing. You have to figure out what 99% of the people of the app expected when they press the back button.
You can find on the Android Developer site that you should not change the expected behavior of the back button. Let the OS handle the back button.
App does not redefine the expected function of a system icon (such as
the Back button).
That quote is pulled from their Core App Quality page.
You should consider using Up Navigation. You can read more about designing for it here:
Lastly, here is a tutorial on how to implement various types of navigation (lateral, ancestral [up], temporal, descendant).
check here
From my personal experience you can close most, which are using back pressing to go to a previous screen, with a long click on the back button. The best example is the browser app, whether its the native one or a third-party browser
I think that behavior depends on application logic.
By default it is desired to move on previous screen (activity in back stack, or fragment if it was saved to the fragment's back stack).
Actually there is no any silver bullet for this case. Just use "back-pressed implementation" what ever you want. My point is that on back pressed, application must be shown in previous logical state.
I have seen couple of Android applications when I came across one common practice. Navigation header does not have a Back button. Since then I was quite confused so as to place the same in the Navigation header of my application.
Should back button be placed in Navigation (Header) or we should leave keys to handle it? What is the best practice we should follow?
Thanks
My personal view is that each platform has its own way of handling certain functions. An apple device will have a back button on its navigation bar because that is the place where an iphone user will look for it.
As far as Android is concerned, because we are supplied with a physical back button, we must leave it at that because that is the first place an android user will look to if he wants to go back.
Therefore since user satisfaction and ease of use is the main concern, i would not play with the back button (unless i have to).
Similar to the responses above, however for the sake of simplicity I have taken a central approach in which I actually keep a back button in the navigation header however user can still press the hard key back button and the code actually performs the same functionality.
Essentially what it does is to cover both set of users, some really new ones who do not understand Android hard-keys yet, like people used to iOS (pun intended) and the other more suave Android users.
oI believe there could not be best approach. It depends on your custom UI and how much screen estate your navigation consume. The best approach is to buil two variants ant alllow to beta-testers decide.
Allthow back button on the screen could be as much handy, so much annoying.
What the "Back" button actually does, is to close your current activity and bring the previous one to the front.
You can do the same by calling finish() in your current activity. It will remove the current activity from activity Stack and take you to the previous one.
Asaf Pinhassi
I would like to put fairly extensive help information within my app - both "how to use" and explanation of what one is seeing.
The app (map oriented) has a row of buttons at the bottom, and I was considering adding a help button.
Context sensitive help is mostly not appropriate, btw.
What are common and best practices for this?
Thanks
I wouldn't suggest using a help button, once the user knows how to use your app it will be useless, and will only takes some space.
What I do (but it's maybe not the best practice) is to show a popup on the first use. Within the popup I put some basic help and a link to my website which fully explains how my app works (with some screenshots to make it user-friendly). I also put a "Help" button in the activity menu which redirects to my website again.
What I can suggest is to explore by yourself how other android apps shows the help information, and reuse or adapt the one you prefer (this is what I've done).
I have put help into a menu item as I expect new users to click the menu button anyway (my app, Zwitscher also has a button bar at the bottom).
Clicking the menu item then starts an Activity that simply shows a table view that explains the various buttons in the system and contains a link to more information online.
See https://github.com/pilhuhn/ZwitscherA/blob/master/src/de/bsd/zwitscher/HelpActivity.java and
https://github.com/pilhuhn/ZwitscherA/blob/master/res/layout/help.xml
Another option I've seen sometimes is including a help option in the preferences/configuration screen.
Usually it starts a new activity with a sequence of steps to make the user understand everything.
Desktop apps have top level menus (File, Edit, Search, ..., Help).
Web apps have very similar thing, menu tabs (Logo, Questions, Tags, Users, Badges, ...).
However I cannot find equivalent of top level menu in Android framework. Assume that my app has 5 main activities. According to menu design guidelines options menu should contain actions related to current activity. So how an app should allow users to easily switch to one of five main activities.
It seems that different apps solve the problem in different ways. Some have a tab list at the top of the screen, some at the bottom. Even Google applications aren't consisted in that field. Google Listen has an options menu item called 'Listen Home', however Listen main activity has no that options menu item. Others have two icons in app luncher which start two different activities from one app.
I realize that due to small phone screens Android apps have to be designed in a slightly different way than web or desktop apps. But I have a feeling that the app top level menu topic was omitted in Android framework. And developers are on their own here. Or am I missing something?
Update: this is Google blueprint for a great app
Update2: this an example app of these patterns
Update3: GreenDroid library helps a lot implementing these patters in your apps. It seems that dashboard and action bar patterns are becoming quite popular.
You should take a look at this Google I/O session: http://www.google.com/events/io/2010/sessions/android-ui-design-patterns.html
They talk about the design patterns they used for the Twitter application and basically the type of concept you are asking about. Basically, your activity should have a top bar that gives the user specific tasks to do in the view or allows them to switch into another activity.
Google has not implemented anything like this into the actual SDK yet so you're sort of on your own in terms of implementing it but the main concept is given in the presentation. This is the direction that Google would like to see Android shift into though.
Hopefully this helps you out somewhat.
The file/edit menus of desktop apps have a very different purpose than the questions/tags etc. tabs at the top of this webpage.
The contents of the file/edit menu should be implemented as in the options menu that appears when you press the menu button. This is, as you noted, to save space on the smaller screens.
App navigation like the questions/tags etc could be implemented using a Tab Layout. You are right that apps vary in whether or not the tabs are on the top or bottom, but I don't think thats a huge deal. In my unscientific look through apps on my phone, the bottom seems to be more common. However, I think it might depend on your specific implementation which you decide.
A lot of apps don't require any sort of navigation like that, and can get away with just having a path forward or back via the back button. I think this is preferable for a lot of applications, but won't work in all cases.
I'm not sure what more you would want built into the framework.. It seems like you can accomplish any kind of navigation desired with the above options.
You can look at the source of the Google IO app
ioshed