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

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 开发者_如何学Pythonas 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.

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.

I highly recommend you following the model used by the standard Android and apps, where editing always happens in place. That is, there is no "save" button -- the changes you are making are effectively being saved as they are being done. (The implementation may of course be slightly different, but to the user this should not be visible.) Following that model, your buttons should be something along the lines of "done" and "revert". This helps with the user's mental model of what is going on, that leaving the activity would not be likely to turn into a "revert" operation.

One reason for using this data editing model is that you will run into many fewer bad edge cases. If you try to present a more traditional model where the user explicitly saves, then any path the user may take out of your activity is a potential cause of data loss, which then leads you to want to protect them from that, and thus trying to show dialogs to confirm that they really want to lose their data. This is a losing battle, and you will never be able to catch all of the holes out, and your UX will suffer for it. (Consider for example if they receive an incoming phone call, this is just not the time to put up a dialog to first ask them if they want to save their data, nor would you be able to anyway.)

So start with your basic model being edit in place. This is consistent with the convention the standard platform uses, and this was deliberately chosen in the platform design because overall it results in a much simpler and more consistent and comprehensible UX. Design your UI flow to emphasize this model, by avoiding explicit "save" actions.

For me, I always feel 'unsafe' without a save option. For example, in GTask, when you create a new task, hitting 'back' (hard button) will save the stuff and back to prev screen. There's no soft button BTW. But I always frustrated about this.

For your app, I think you need to consider two things before deciding which way did the back button perform:

1. How critical is your 'save' operation (like it will place orders!)
2. Did your user expected to cancel stuff?

Obviously, if the save is long-processed and critical, an explicit control must be taken. (and back would not save); and for the second point, I guess GTask considered jotting notes should be quick and simple, and it should feel like jotting on paper --- it's saved, once you wrote.

Referring to what you said, back in web browser is go back and forget everything. But at the same time, Google (e.g. Google Docs) is also doing auto, background save, that it's not 'forgotten' when you back.

Trying to decide a universal action for when the user presses back makes this question a lot more difficult (if not impossible).

A much simpler approach is thinking about the context, and I see two main situations: the user is interacting with a dialog and the user is interacting with a regular activity.

Interacting with a dialog

If an user presses back in a dialog (for instance date time picker dialog) it's because he doesn't want to see that dialog or change that information.

While in a dialog, the user doesn't expect changes to apply until he says so (by pressing "Ok").

Interacting with an activity

For example, the user is seeing the details of some item that your application provides (contact information). Pressing back after some changes could mean "now take me back to the list of contacts". Anyway, this is not 100% clear. So including options to save and discard changes (call it whatever you like) could be a good option.

My thoughts as an android user

The behavior in a dialog is simple and clear. I think we have no doubts about it.

In activities, I'm used to have the back key to save data and send me to the last activity. Whenever I want to discard my changes, I find myself pressing the menu button and looking for a button to cancel.

If you want to something better, include the default behaviour as a preference and/or display a toast when you cancel or save the information.

Cancel vs revert

In practice, they do the same thing. Cancel should, herr, cancel what you are doing right now (editing something). This should/could take you to what you were doing before (list activity).

Revert will change the state of what you are seeing to the way it was before you started doing changes. This may not take you to the previous activity. It could simply update the UI to the original values.

Experiments with contacts application

1. Pressing back while editing a contact will save the changes.
2. Pressing home while editing a contact will discard changes