Where to put OK/Cancel on an Android activity form?

Question

Imagine an app screen used to fill out a form and then either Ok, or Cancel - an activity that on a desktop application might be a dialog box. The keyboard will be displayed, so we have limited screen space on a phone, and to ensure everything fits on all devices the screen content will be wrapped in a ScrollView, so it'll scroll if the screen is small.

In this app I use an ActionBar on all activities, to provide an easy and consistent way to move around the app.

Options:

1. Put Ok/Cancel at the top of the activity, under the ActionBar. If the user scrolls down, the buttons scroll off the top. I don't like this much as it means if the user goes down to enter the form data, they have to scroll BACK UP to get to the buttons. But what's good is the buttons are clearly visible right from the start - the user knows their options, though things appear in the wrong order (you need to fill the form out before sending it)

2. Have the Ok/Cancel buttons at the bottom of the form. The problem with this is they are not visible when the screen opens. New users may get confused and wonder what to do. I'm requiring they do some scrolling to even find the most important buttons on the screen. But the advantage is that the form to be filled is shows first, which is the first step they need to take, so in that respect it's logical.

3. Move the Ok/Cancel buttons into the ActionBar, so they are always visible. If I do this they will be much smaller. The approach would be much like the iPhone. So I'd be using the ActionBar to provide context-sensitive options for users to work with.

4. Remove the ActionBar from activities like this, and simply have Ok/Cancel buttons to select how to exit, and retain the ActionBar for the main screens. Though doing this may work on phones, it won't work so well on tablets.

Answer 1

Most input forms on Android have the cancel and confirmation buttons at the bottom of the dialog. This is natural based on the flow of information: The user will work their way down the various input fields and at the end of the fields will either commit or cancel their work. The action bar is the new shiny control of Android but you need to be judicious with its use. There are no instances of Google using the action bar in either their OS or applications for confirm/cancel. Note that confirm/cancel is different from other types of actions like sending an email versus trashing a draft.

You are worried about hiding the buttons in option #2: "Have the Ok/Cancel buttons at the bottom of the form." Instead of having the buttons as part of the scroll view, you could pin the buttons to the bottom of the screen. This informs the user of all the major UI elements and if there are optional form elements, allows the user to submit the form without having to scroll through all options.

Additionally, most fully-designed Android applications will have seperate UI for phones versus tablets. You should take advantage of the larger screen real estate offered on tablets and layout the forms differently. You'll still wants confirm/cancel buttons near the bottom of the form but you can likely layout the form without the need for the user to scroll to see all fields.

Answer 2

Every Android design guideline and design principle is described at developer.android.com.

If you can't find the answer to your question here - then you're doing it wrong...

---

Actions bars should not be used in dialogs. If you take a look at the common app structure, then you'll find some tips on how the screens of your app should be designed.

I would also point out that Android devices has a hardware "back" button that is commonly used to "cancel" actions or "exit" dialogs. There is also a consideration to be made whether the confirmation is really needed or if a simple acknowledgment is enough. If you design a flat structure, then immediate saving won't require a confirmation, but an acknowledgment could be useful...

For dialogs, the buttons are at the bottom:

When it comes to targeting various screen sizes, then you should consider different layouts for these. You could for instance use fragments to split your activity into smaller steps.

Answer 3

From my reading of the question, this is not a dialog box at all, but a fully fledged form Activity. If you are seeking an answer for a dialog anyway, as other answerers have said, buttons on the bottom, as prescribed by the guidelines.

Overall I agree with Mike Bibik's answer, but I would like to expand slightly with four considerations:

• Would it make sense for the form to be submitted at any time, at any point of completion? If not, and the user is expected to complete the form, then why worry about displaying the buttons at all times? If the buttons only have use once the form is complete, don't display them when activating them would be erroneous.
• Often when opening up a form activity, the focus is not placed on the first form field immediately, meaning the keyboard does not display as the Activity is loaded. This means that the entire screen is available when the Activity is displayed. This can be used to mitigate the chance of the buttons being placed off screen, but needs to be weighed against the hassle of not auto-focusing on the first field.
• Consider carefully the "Cancel" button, forms often do not need them. Android already has a Back button and, as Action Bars are being used, an Up button, both of these will cancel the form. Also, consider the frustration in completing the form, accidentally hitting "Cancel" sitting right next to the "Submit" button, and losing progress. Dialogs make them work as they typically have few options and can be rapidly altered again.
• Forms are reasonably common. Consider your audience, will they be likely to not understand a form if a Submit button is not displayed, or is this overthinking?

Answer 4

In response to your followup, simply hide the bar on smaller screens until it's scrolled to the bottom. On larger devices show it as a bottom sticky bar.

if (screenHeight <= minScreen) {stickyBar} else { show at bottom}

Answer 5

Mike Bibik's assertion that "There are no instances of Google using the action bar in either their OS or applications for confirm/cancel" might have been true back in 2011, but not today.

One obvious counterexample is the "New event" form in the built-in Calendar app, which has "cancel" and "done" action items on a non-dialog Activity. Another example is the photo editor in Jelly Bean, which has "save" in the title position of the ActionBar.

In both cases, back seems to be equivalent to the "done" action. Notice that in both cases it's possible to complete the form (i.e. save the event or the modified picture) even if fields haven't been filled in, so if you have mandatory fields with no sensible default, this behaviour might not be appropriate.