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
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.
Does anyone know how to implement a sliding menu like some of the top apps of today?
Other Stack Overflow questions haven't had any answers on how to do this, so I'm trying to gather as much info to help out others. All the applications I mention below do a great job of implementing the slide menu.
1. Google Plus (as of 7/7/12)
You can only go from the first screen to the second screen by clicking the G+ logo in the upper left hand corner. Notice that the entire screen moves from it's position and get's nudged to the right side of the screen (including the action bar). To get back to the first screen you can either slide the right side back into focus or you can click the G+ icon again.
2. YouTube (as of 7/7/12)
You can go from the first screen to second screen using two methods. Either click the YouTube logo in the upper left, or you can use a swipe gesture to move it to the right. This is already different from the G+ app. Secondly, you can see that the action bar stays put (Unlike G+). Lastly, to get the original screen back it works just like G+.
Edit #3:
The Navigation Drawer pattern is officially described in the Android documentation!
Check out the following links:
Design docs can be found here.
Developer docs can be found here.
Edit #2:
Roman Nurik (an Android design engineer at Google) has confirmed that the recommended behavior is to not move the Action Bar when opening the drawer (like the YouTube app). See this Google+ post.
Edit #1:
I answered this question a while ago, but I'm back to re-emphasize that Prixing has the best fly-out menu out there... by far. It's absolutely beautiful, perfectly smooth, and it puts Facebook, Google+, and YouTube to shame. EverNote is pretty good too... but still not as perfect as Prixing. Check out this series of posts on how the flyout menu was implemented (from none other than the head developer at Prixing himself!).
Original Answer:
Adam Powell and Richard Fulcher talk about this at 49:47 - 52:50 in the Google I/O talk titled "Navigation in Android".
To summarize their answer, as of the date of this posting the slide out navigation menu is not officially part of the Android application design standard. As you have probably discovered, there's currently no native support for this feature, but there was talk about making this an addition to an upcoming revision of the support package.
With regards to the YouTube and G+ apps, it does seem odd that they behave differently. My best guess is that the reason the YouTube app fixes the position of the action bar is,
One of the most important navigational options for users using the YouTube app is search, which is performed in the SearchView in the action bar. It would make sense to make the action bar static in this regard, since it would allow the user to always have the option to search for new videos.
The G+ app uses a ViewPager to display its content, so making the pull out menu specific to the layout content (i.e. everything under the action bar) wouldn't make much sense. Swiping is supposed to provide a means of navigating between pages, not a means of global navigation. This might be why they decided to do it differently in the G+ app than they did in the YouTube app.
On another note, check out the Google Play app for another version of the "pull out menu" (when you are at the left most page, swipe left and a pull out, "half-page" menu will appear).
You're right in that this isn't very consistent behavior, but it doesn't seem like there is a 100% consensus within the Android team on how this behavior should be implemented yet. I wouldn't be surprised if in the future the apps are updated so that the navigation in both apps are identical (they seemed very keen on making navigation consistent across all Google-made apps in the talk).
Just recently I forked a current Github project called "RibbonMenu" and edited it to fit my needs:
https://github.com/jaredsburrows/RibbonMenu
What's the Purpose
Ease of Access: Allow easy access to a menu that slides in and out
Ease of Implementation: Update the same screen using minimal amount of code
Independency: Does not require support libraries such as ActionBarSherlock
Customization: Easy to change colors and menus
What's New
Changed the sliding animation to match Facebook and Google+ apps
Added standard ActionBar (you can chose to use ActionBarSherlock)
Used menuitem to open the Menu
Added ability to update ListView on main Activity
Added 2 ListViews to the Menu, similiar to Facebook and Google+ apps
Added a AutoCompleteTextView and a Button as well to show examples of implemenation
Added method to allow users to hit the 'back button' to hide the menu when it is open
Allows users to interact with background(main ListView) and the menu at the same time unlike the Facebook and Google+ apps!
ActionBar with Menu out
ActionBar with Menu out and search selected
There is a great implementation of NavigationDrawer that follows the Google Material Design Guidelines (and compatible down to API 10) - The MaterialDrawer library (link to GitHub). As of time of writing, May 2017, it's actively supported.
It's available in Maven Central repo.
Gradle dependency setup:
compile 'com.mikepenz:materialdrawer:5.9.1'
Maven dependency setup:
<dependency>
<groupId>com.mikepenz</groupId>
<artifactId>materialdrawer</artifactId>
<version>5.9.1</version>
</dependency>
I know this is an old question but the most up to date answer is to use the Android Support Design library that will make your life easy.
Personally I like the navigationDrawer in Google Drive official app. It just works and works great. I agree that the navigation drawer shouldn't move the action bar because is the key point to open and close the navigation drawer.
If you are still trying to get that behavior I recently create a project Called SherlockNavigationDrawer and as you may expect is the implementation of the Navigation Drawer with ActionBarSherlock and works for pre Honeycomb devices. Check it:
SherlockNavigationDrawer github
clients want exact replica app on iphone and android. the iphone design is the only one thought about, and it frequently has tabs on the lower part of the screen
in android, this can be replicated but the primary way of doing this was deprecated, for various reasons. (tabhost, tab groups, activity) android's replacement methods include action bars and viewpagers and fragments with a varying degree of backwards compatibility but they don't really put the resulting tabs at the bottom of the screen.
similarly, multiplatform web app tools like Sencha Touch can generate intuitive "bottom tabs" on both platforms. So for Android there are still a variety of ways to do bottom tabs, so it would be fiction to tell a client that they need to change their iphone design for android
how do developers and consultants approach this. any best practices?
I don't quite know what you're asking for. If it's a programming solution, then someone who's made bottom tabs before could answer. I've never done it, so I don't know if there's an easier way than the brute force do-it-yourself approach.
If it's a consultation answer, then the best approach that's worked for me is to convince the client that the "Android way" is to put tabs on the top. As such, people who use Android phones regularly come to expect a certain way things are done. Especially since ICS came out, soft buttons have been moved to the bottom of the screen. These can't be shifted, moved, or removed and having tabs on the bottom could result in the user accidentally pressing either back, home, or process-list.
I'm currently working on a port of an iPhone app into an Android. The iPhone app has a custom global navigation menu at the bottom of the screen, and when bringing this over to Android, it was suggested to replace this custom menu with the generic Option Menu (invoked via the option key on the device) to give it a more native Android look and feel.
The issue is that the menu itself has several layers (e.g. Three main option like A, B, C, and sub-options like A1, A2, A3). I've looked around but have not seen this sort of multi-level option menu on Android apps, so am looking for some guidelines on how this may be best achieved.
I've seen some questions on customizing the Option Menu such as this one; Android: customize application's menu (e.g background color); and they seem to suggest that the native framework doesn't support many options.
Should I be looking at a bit of hacking into the option menu (is this a good idea?), or looking at some other approach to modifying the app flow? Trying to understand what would be the best way to maintain a consistent user experience on Android, while reducing the level of variation from the iPhone app.
Thanks!
I've looked around but have not seen this sort of multi-level option menu on Android apps, so am looking for some guidelines on how this may be best achieved.
Options menus support sub-menus, but only one level deep (i.e., the menu can have a sub-menu, but a sub-menu cannot have a sub-sub-menu).
If you really need that (and want to violate the Android platform standards regarding menu depth), then you can easily implement this by using an AlertDialog with lists for every nested level of your menu. Visually those appear exactly the same like an options menu.
I've done something similar to what banana suggested. I would just add the reasoning behind the limitation is the myriad number or devices and screen resolutions that need to be supported. Multiple nested menus might look good on a tablet but not on a 5 inch screen so we need to keep that in mind.
For me, adding
android:onClick="onOptionsItemSelected"
to nested menu items worked.
I'm working on an android app that has a section that feels like an iPhone home screen. There's a bunch of pages that are essentially displaying the same data in different configurations and users should be able to quickly move between them. Generally there won't be more than 4 or 5 pages.
I could just replicate the experience with the iPhone home screen with multiple dots on the bottom of the page, but that doesn't feel very android-friendly. What's the design pattern in android for viewing and interacting with this type of view? I know the android home screen has a variant with dots, but I've never seen it used within an app.
Screenshots or links to existing apps would be great.
The stock Android launcher has left/right paging behavior on the home screen, and it's open source.
This is the Workspace class. Pay special attention to the onTouchEvent and onInterceptTouchEvent methods. The utility classes Scroller and VelocityTracker are used together to define the behavior for snapping to a page when the user lets go from a drag.
https://android.googlesource.com/platform/packages/apps/Launcher2/+/master/src/com/android/launcher2/Workspace.java
Hootsuite uses this design pattern and it works well in my opinion. I don't think it affects the user experience on Android in a negative way. I find that the biggest problem with people porting iPhone applications to Android is the fact that they try to port every single design pattern over. I don't think what you're trying to implement will be an issue.