I have an app that's built for Android 2.2, so I'm not using the 3.0+ built-in ActionBar class but rather building my own custom ActionBar implementation using Google's older UI recommendation that was introduced a couple of years ago.
All of my screens have between 1 and 3 actions that can be performed, so they all fit very nicely into the ActionBar UI (which Google recommends has a maximum of three buttons). The problem now is that none of my screens have a regular options menu and so they do nothing when the user presses the hardware Menu button.
According to Google's interface guidelines, this is correct behavior. If your activity doesn't have an options menu then it should do nothing when the Menu button is pressed. I've found during user testing, however, that users are quite perplexed when they press Menu and nothing happens (and every single user has tried, usually multiple times). They say that they appreciate the actions being exposed on the screen through the ActionBar, but at the same time they want the Menu button to do something.
I've been looking at Google's first party apps and it looks like they just always have enough options available to be able to load up the options menu with stuff after the ActionBar is full. Google+ seems to use the Menu button in the traditional way for overflow options on phones that have one, and they show a dropdown menu in the ActionBar for phones that don't. That would work if I had more than three actions but I currently don't.
It seems that the only way to meet my user's expectations is to put some junk options that have no value into the Options Menu just so that something happens when they push the button. I really don't want to do that. Does anybody know of a good way to deal with this problem? Should I just leave the menu button alone and expect people to figure out that it doesn't do anything?
I think it's safe to assume that most users don't know the menu button exists and having all of the actionable items displayed on screen is best. User testing by Google has revealed this and it is why they have chosen to eliminate the menu and go with the built-in action bar starting with Android 3.0 and culminating in the recent 4.0 release.
Something to think about would be added a single "About" item to the pre-3.0 options menu/post-3.0 overflow menu. This could just popup a dialog with simple info about the application (e.g., version, licensing, link to website, author, etc.). This way there is something there should they happen to press the menu button but it is not required in order to properly use each activity to its fullest potential.
I have an app that's built for Android 2.2, so I'm not using the 3.0+ built-in ActionBar class but rather building my own custom ActionBar implementation using Google's older UI recommendation that was introduced a couple of years ago.
As an author of an action bar library this sentence disturbs me. It's fairly trivial to use a custom action bar implementation on pre-3.0 and the native one post-3.0. Take a look at Google's Action Bar Compat sample.
...or, you know, you could also go with a library like ActionBarSherlock that does this for you! </shamelessPlug>
Related
I've been developing an app (min sdk 8) that uses the physical menu buton for almost everything into the app. Recently I've bought a new cellphone and I realize that it doesn't have a physical menu button, compromising the usage of my app. I don't want to change the min sdk version, what is the best way to migrate to newer versions? I've taken a look into Action Bar but I don't know if I need to reimplement everything I've made so far (removing the logic that uses physical menu button) or if I let how it is and just implement new logic that uses action bar.
Thanks in advance.
You might want to take a look at ActionBarActivity from the support library. They have similar callback like onCreateOptionMenu, onOptionMenuSelected etc. So it is not that hard to make the transition in terms of the menu button you talked about.
Don't worry about action bar, you can use v4 or v7 support jars which will work on lower versions as well.
Hard menu button is just to give options menu. If you use action bar you will see three dots on the right side which indicates options menu.
I am relatively new to android development and I'm having a good time so far. My application is functional and I'm ready to add a few options for the user. There seems to be a wealth of information on the ways to do this and I'm having trouble sorting through it and determining which way is the current "accepted" method of providing options to the user.
Does anyone have a great resource to share?
It really depends on the particular app, existing UX, branding and a ton of other design considerations.
In general, starting from scratch, a good starting point (though not universally!) would be the action bar. It gives the user access to ways of manipulating the data on screen, as well as a way of consistently presenting secondary functionality (the overflow menu). Design docs, implementation docs.
I would heartily recommend going through the Patterns section of the design documentation, as it explains the rationale behind many of the core design decisions.
P.S. The reason I'm eager to underline that it's not universal is apps with established UX and user expectations. Examples include Facebook, Path, Google Maps. They all have their reasons for not sticking strictly to the action bar paradigms but they work with it as much as they can.
This Menu Doc page is particularly helpful. But basically if it is API < 11 then you use the hard menu button for an options menu. After 10 the menu items will show in either the ActionBar as action items or in the overflow button. But can still be located in a hard menu button if one exists.
You also always have the option of a contextual menu, primarily with a long click, for things like certain menus depending on the View that is triggered. So maybe show an edit, delete, save menu for a list item.
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
I am trying to create an android app that has the following:
Theme set to #android:style/Theme.Black
Bottom options menu button on all activities except for one.
I am trying to remove the bottom menu button from the activity that I do not want it to appear on by returning false in the OnCreateOptionsMenu method. This doesn't work...
So if I compile my app to target sdk version 14 the menu is gone from every activity...
How can I achieve this?
Assuming you are thinking of the standard Android MENU button, this cannot be removed. Keep in mind that on many older phones, this is a hardware (physical) button.
I recommend reading the advice I received in the following link, regarding the MENU button and the various issues pertaining to the changes from earlier version of Android to ICS.
Handling the missing MENU button in new versions of Android (3.x and up)
Also, I would pay attention to the following official info from Google, and strongly considering rebuilding the app to not be dependent on the MENU button.
http://android-developers.blogspot.no/2012/01/say-goodbye-to-menu-button.html
Not only should your apps stop relying on the hardware Menu button, but you should stop thinking about your activities using a “menu button” at all.
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