Shared publicly  - 

Done + Discard

A few minutes ago +Reto Meier and +Ian Ni-Lewis talked about a detail-edit screen in a finance app during The Friday App Clinic [see third photo]. The screen was a bit complex, offering something like four different ways to leave the screen with either positive (save) or negative (discard) results. One of the methods even used a floppy disk icon, but let's just gloss over that for now.

There's a visual pattern in some system apps where the Up button is replaced by a Done button, optionally with an adjacent or overflow'd Discard negative action. I personally think this pattern works really well within the framework of—and in the spirit of—the guidelines, so I decided to open source some code showing how to do it.

You can find that code here:

There are two example layouts in the sample project. The first simply shows the Done button in place of the Up button at the top left, with a Discard action in the overflow. This treatment seems best suited for tasks where you may have more than just the positive/negative actions (e.g. Join contact), requiring more space in the action bar or overflow. It also seems most appropriate for cases where the user is unlikely to want to discard changes, and where the default behavior upon pressing BACK is to save. A real-world example of this is the People app's contact-editing screen or the Clock's alarm-editing screen.

The second shows both Done and Discard enveloping the entire action bar. Done is to the right of Discard to oblige the negative-left-of-positive button layout rule (as of ICS). This layout seems best suited to very simple screens with no alternate actions, or screens where Discard may be a more common action.

One last thing… please remember that since this isn't documented on, this isn't formal design guidance. These are merely observations, hence my usage of words like 'seems' throughout this post :)

Sahil Chaturvedi's profile photoIvo Encarnação's profile photoGovorovsky Alexey's profile photoJuan Ramirez Cervantes's profile photo
This is a tricky one. It is even more complex on tablet displays when you often have the navigation visible as well. I remember having problems with exactly this issue in some of my university usability courses years ago with desktop apps as well.

Even if you replace the up button you still have the back button. In my opinion apps should always save everything users do unless they tell the app to get rid of it. I do't think that apps need the "done" button at all. Back / up should be enough. I do like the confidence this done discards brings to the UI.
If the app saves all changes automatically, it needs a way to show the users, that the change is saved. Otherwise they will search for a save button, because thats what you have to do nearly everywhere.
+Juhani Lehtimäki that's exactly it — Done behaves mostly (exactly?) like Up, but provides that tiny extra bit of confidence.
Great topic ! I faced this situation too, on Activities where saving meant a lot : a WS call that spreads the modifications for all the users to see (as it could be for G+ or FB profile update). I searched for the correct pattern in the platform but didn't find a lot.

For now, I discard changes when using Up & back, and I have a normal action item "Save". I don't really like this approach though, with this main save action being just a text action item at the top right of the screen.
I prefer your idea with the Discard / Save, but it means losing the activity title.
I thought about the CAB approach, with the Done / Discard coming as soon as the users modifies something, but in this situation users won't be able to return to the first state of the AB, like they can with a classic CAB on a ListActivity for example. That might be confusing...
+Nicolas Mottin in some cases where you're operating on the data directly, you don't need a title. For example, the top field in People's contact-edit screen is the contact name, which establishes sufficient context. As for throwing the user into a CAB as soon as editing a field, that seems like a strange/jarring interaction :-/
How about leaving the Up button, but hooking the Up and Back buttons so that they cause an animation or something on the Save and Discard buttons if there are any unsaved changes?

You could even do a full-screen transparent box that zooms over to Save / Discard, or some other really eye-catching animation that hopefully makes it clear that the user.

Also, should we hide the Save button if there are no changes? Or just grey it out (more discoverable)? Again, as soon as there are unsaved changes, the Save button could be displayed / changed with an animation to let the user know what to do next.
I think the solution that has both Done and Discard on the action bar is already pretty good. Gave the confidence to the user and give the user full control of the saving state. If the user use Back button while editing, I think we can just ask the user whether to save it or discard the changes (oh yes, pop up), more inline with form editing mental model, and also because we can't predict what's the user expectation. Not elegant but less user frustration.

One reason that I don't like the app to save whatever changes made when we click Up or Back - There is always chance that user creates empty entry (for example, to do list), and there the user wasted more clicks just to delete it (user don't like to see empty entry in the list isn't?).
Agree with +Taylor Ling that both should be there.

Why not just employ the same principles that the Google Calendar app does when creating an event? There's a Cancel | Done in the action bar, and then a toast if you tap Back that nothing was created.
This is an interesting problem, so if you'll excuse me I'll complicate it a bit further.

I have an app with a list of editable items. I know for certain that the user will often, but not always, want to edit more than one of them, and quite probably in sequence. So I wanted to save the user from a lot of extra clicks and back and forth jumping between the list and the edit screen. I did this by having Next and Previous buttons in the edit screen and have them traverse to the corresponding item without going back to the list. I also have a Done button in the mix, but no Discard as I already seemed to have enough buttons to fit in.

So what I finally ended up with is: Done saves the current item and returns to the list. Next and Previous also save the current item and move to another item. The back button exits back to the list, but does not save the current item.

Now the interesting question is that if the user edits item A, taps next to advance to B, but then presses back, what does he expect to happen? The app just saved A some moments ago, there's no way to discard that anymore. So far I haven't had any complaints, so I guess nobody's thought of it as much of a problem.  

I'm interested in trying out Roman's Done/Discard scheme, but with having the Next/Previous buttons in the screen bottom. What do you think, would I just end up with a confusing train wreck of a UI?
+Harri Ohra-aho I didn't have a deep thought on your mentioned scenario but for Next and Previous, perhaps you can consider swiping instead? Much like when you are swiping emails in Gmail app. That could potentially solve your concern about what's the Back button should do.
+Taylor Ling  Yes, swiping might be an alternative. It would definitely tone down on the button clutter. It would actually present another interesting phenomenon, since in my particular case swiping into the next item would actually commit the changes done to the current item... unless I implement some model buffering and only save all the changes when the user finally taps Done. 

So the options would actually be:
1) Save the changes every time the edit screen for a particular item is exited, unless Discard is selected.
2) Buffer the changes for each item and only save everything when the user finally selects Done in any item's edit screen.

Both have their equal confusion factors. :)
Another point for those who are concerned with users saving changes unintentionally: potentially destructive or heavyweight actions (e.g. edit an event and send new invites) should be reversible (undo), even if within a short time period. If not with an interactive Undo toast ala Gmail, perhaps somewhere contextual within the parent screen. Reversibility is key to avoiding extraneous popups, etc.
I tend to also like just saving on back and providing an easy editing method where the data doesn't need to be reverted with a time limit.
First of all, thank you +Reto Meier and +Ian Ni-Lewis for the great review of my app +Timesheet . Thank you +Roman Nurik to bring up  this topic and samples! A lot of constructive input!

I have to say that before I used the ActionBar I had a static Title Bar with only main navigation items. Also two buttons (Discard, Save) at the bottom of the screen. Now with the ActionBar I have the ability to save space and moved the two buttons as actions to the top (not all users liked that). I understand that there are too many ways to return (save/discard/up/back) but I think some users want a clear button to take control. If there is an arrow back and up which saves the input a user may be confused at the first time - where's the save button? If I changed some fields but I don't want to save them a back button would be great without save action. Maybe an undo button would help but then there is one more action on the tiny screens.

Seems to be a difficult topic!

To clear up the mess of actions maybe I would hide the "up" button and move the discard action to the overflow menu. And yes I would change the floppy disc icon to the standard android save icon ;-)
(But then there's a third arrow?) 
+Florian Rauscha FWIW, I think the app is miles ahead of other work trackers in the Play Store! Definitely not an easy problem. May want to prototype several options and try each on 5 people. That may help decide on any changes :)
It is a shame that Google didn't make a soft Back button (like on the Galaxy Nexus) mandatory with 4.0. There would be an opportunity there to visually ornament the Back icon in a way that guides user expectations.
Ben L
I personally feel that main action button (aka save) should be at the bottom of the screen not in the action bar. It's hard to reach action bar on some devices - especially if you are holding device with one hand. Plus it's closer to the keyboard, so if you were typing it's faster and easier to hit send / save.
I have related topic going here in the comments and would love others to give opinions on that:
+Benas Benediktas I think it depends. Putting those actions in action bar have two advantages: Consistency in user interaction for action bar and less user-error. If it's near the keyboard area, I personally think that it's prone to mistake. Putting it on top (somewhere further) would also give some time to the user before they hit the save/done/discard. But as I mentioned, it really depends on the context/situation, but generally placing them on action bar is a better decision IMO.
+Antonio Leiva Gordillo The CAB is really only meant to present very temporary contexts/modes. Showing it for more than a few steps, or for complex flows, may be confusing. Use with caution :)
+Roman Nurik I considered using the Done/Discard scheme in an app, but in my case the edit page is actually a fragment, not an activity. Although it is intended for phones, it may not be a good idea to completely replace the actionbar. What would you do?
Yeah I'd use an inline done button in that case perhaps. Or just do what the People app does on a tablet. 
for the record, the People app uses an ActionMode, saves the contact if you dismiss either via the tick or back, and has discard in overflow menu.
+Roman Nurik  I hate the fact ActionMode steals the back button event, as its really the most obvious 'dismiss' mechanism (one would expect it to dismiss without saving). ActionMode steals that back event so much that going 'back' to an ActionMode is kind of a weird thing to implement! Part of that problem is that ActionMode doesn't get re-established as state from fragment backstack. I had to resort to a 200ms delayed post to thread + some other logic to get that working.
Great! Thanks for you help. I add Build.VERSION.SDK_INT for to use that app in android 2.x
Does anyone has an example of this for the Actionbar Compat? so that is works on 2.x ?
Add a comment...