Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have developed an app that works on Android devices and iPhones. I went to great lengths to ensure that the interface is exactly the same on both systems.

However, one significant difference that I can not change is that most, maybe all, Android devices have, on the front of the device below the screen, two extra physical buttons along with a main button, whereas the iPhone only has one main button. One is a menu button, the other is a back button.

When using my app, whether on the iPhone or Android, pressing the main central button will exit to the desktop screen. This seems to be the default behaviour as I made no attempt to configure it, and that behaviour is fine with me.

Since I have taken care of all other interface needs in order to accomodate the iPhone's lack of any other buttons, the two extra buttons on the Android are not needed for me. However, I've discovered with testing that users expect at least something to happen. If nothing else, to at least in some way let them know that it's the case that the button was pressed but has no function, as opposed to not responding because of some kind of system error.

I have a settings and configuration screen, so the menu button could conceivably take a user to that.

However in my application, there is nowhere to conceptually go "back" to, rendering the back button completely superfluous. In some ways it might make sense to have it exit the user out of the application, but the main button already does that, so it seems a little odd to have that function duplicated.

In any case, what would be the best action to apply to these buttons as a way of letting a user know that those buttons don't serve a purpose? Or, what would be a logical default action for those buttons that would least not confuse a user?

I'm open to other suggestions as well if there are other possibilities I haven't touched on.

share|improve this question
1  
That 'double box' button at the bottom is not a menu button it's the 'recents' button. Older devices may have a fixed 4th menu button. On newer devices without a fixed menu button and depending on how the application has been developed, you may sometimes see a soft three dot menu button created alongside the other three or in the action bar at the top. The 'Back' button should ALWAYS behave as per the UI guidelines, that's what Android users expect, they don't care how your IOS version works. –  paulkayuk Aug 2 '13 at 15:43
    
I must say this sounds like an absolutely horrendous user experience. Definitely let it go back to the home screen. FYI this is actually doing something different from just hitting the home button - it is actually finishing the Activity instead of just putting it in the background when the user hits back. –  powerj1984 Aug 3 '13 at 0:48
add comment

3 Answers

Having exactly the same interface on Android and iOS sounds somewhat dubious to me, considering that the those operating systems have different guidelines for navigation and GUI design. We would need some more datails about the interface of the app.

The menu button does not have to have an obligatory function and is more and more deprecated in modern devices. It can be left withou a function when there is no function for it. If you have a configuration screen, then don't point the button to it directly. Instead, let the menu button open a popup list, with a "Settings" entry. Like this:

enter image description here

The behavior of the back button on the other hand is clearly defined in guidelines. It shouldn't do nothing and is an essential way of navigation within and between apps in the navigational structure of Android. Depending on the app's structure, it can take you a layer up in the app hierarchy, back to the last screen or back to to home screen. Aside from navigation, it can has other behavior as well:

  • Dismisses floating windows (dialogs, popups)
  • Dismisses contextual action bars, and removes the highlight from the selected items
  • Hides the onscreen keyboard

For a better understand of navgiation in Android I recommend you the offical guidelines: http://developer.android.com/design/patterns/navigation.html

share|improve this answer
add comment

On Android devices Back button is very important and used very often by users.
Difference between Home vs Back buttons in your case will be that

  • Home button always exit your app to system screen

  • Back button exit your app to system screen or to another app (if
    previously user jumps to your app from another)

enter image description here

In some ways it might make sense to have it exit the user out of the application, but the main button already does that, so it seems a little odd to have that function duplicated.

So, as you see this behavior is not just dublicated, and if you just disable Back button that will more confuse your users than simply exit from the app.

Please notice that navigation UP button often takes similar result as BACK button, but theirs behavior is not dulicated too.

share|improve this answer
add comment

Most Android users are now used to the Back button. You could ask a confirmation "Do you want to exit?" if the back button is pressed. Then exit the app if the users accepts.

The menu button can be used to show an in app menu that you already have or to switch between screens. Many apps that I have used on an Android dont do anything when I press the menu button.

share|improve this answer
    
A modal confirmation dialog could break the navigational flow, considering also that closing an app in Android can just hibernate it (depending on the implementation). I would only use a confirmation dialog if closing the app is somewhat critical, for example if you could lose unsaved data or re-starting the app would take some loading time. –  J_rgen Aug 2 '13 at 13:40
1  
Don't do this either. The back confirmation is maybe the single worst user experience found in Android applications. It shows a complete lack of understanding of the platform. @J_rgen brought up some points about when one might consider doing so, but think long and hard about a better way. –  powerj1984 Aug 3 '13 at 0:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.