Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

how to handle "save" and "cancel" buttons and the back key

Tags:

android

I am wondering how to handle user input forms in my app. (real budget lite). Right now this is what I am doing, but I am not sure if this is the best practice:

I have two soft buttons on most of my activities that take user input: "save" and "cancel".

"save" captures the user input and then finishes the current activity "cancel" abandons any user input and finishes the current activity Hitting the back button on the device does the same thing as "save"

It still bothers me a little that the back button performs the function "save and go back". Users who are new to android phones are probably used to web browsers, where the back button means "forget about this page and go back to the previous page". If you were buying something online and you got to the final "purchase" page, you would not expect the back button to complete the purchase, would you? But it seems like that behavior is the way that the built-in applications work, so I am not inclined to do it differently.

Anyway, I have looked through the official documentation and I cannot find this behavior explicitly spelled out. Can someone point me to the right place, or at least provide some guidance as to best practice?

The choices as I see them are:

  1. Do it the way I am doing it now.
  2. Get rid of the "save" button and count on the users knowing that back equals save.
  3. Get rid of both buttons and provide a cancel feature from the menu key.

The google contacts app provides the buttons "done" and "revert", by the way. I guess "revert" means cancel; is there a difference? Maybe I should have my buttons labeled "done" and "revert" instead of "save" and "cancel"? In gmail, the menu button provides the choices "save draft" and "discard". It seems to me that we would be doing the users a favor if we had some consistency here.

Thanks in advance.

like image 737
Burke Avatar asked Feb 14 '11 01:02

Burke


1 Answers

But it seems like that behavior is the way that the built-in applications work, so I am not inclined to do it differently.

The only built-in application that does this, that I can think of, is the contacts app, and I find that UX to be lousy. I was just cursing at it yesterday, as it happens.

Perhaps other built-in apps do it too, but I haven't encountered it yet, at least not that I recall.

Anyway, I have looked through the official documentation and I cannot find this behavior explicitly spelled out.

There are no UX guidelines of this nature in the documentation. Unfortunately.

It seems to me that we would be doing the users a favor if we had some consistency here.

You would get no argument from me.

Personally, I think of the BACK button as behaving as a "cancel", or whatever the negative choice would be. Dialogs typically behave this way on Android, for example.

If you have existing users, and you have established communications with them (newsletter, support Google Group, etc.), I'd poll them and see what they think. In the end, it is what your users want that matters most.

In a pinch, make it configurable. Ideally, for something like this, there is One True Right Answer, and therefore configurability would be pointless. However, if your poll indicates a split vote, and in the absence of Android platform UX guidelines, a setting might be the right solution for you.


UPDATE: I wrote a blog post about this issue, as I think it is reasonably important and worth a bit more prose.

like image 73
CommonsWare Avatar answered Sep 25 '22 21:09

CommonsWare