The "Discard/Done" pattern refers to an action bar with two buttons ("Discard" and "Done") set as a custom view, with the intention of giving the user more confidence when making changes to some content. The confidence gained is with regards to the effect their actions had on the content versus their expectations.

Roman Nurik described it in some detail here (Juhani Lehtimäki wrote an excellent summary of the discussion here) but it wasn't decided how best to handle the back button which potentially short-circuits the action buttons presented.

Should it save by default, discard by default, or ask the user via a popup (dialog)?

For the refresh of stacks (still working on it), I've initially decided to allow the user to back out of the screen (discarding the changes) after warning them first using a Crouton.

The Crouton library is written and maintained by Benjamin Weiss, and it's an implemention of Cyril Mottier's Croutons and can be thought of as a "context-sensitive Toast". For the purposes of this usecase, I set the Crouton to a short (3s) duration, but allow the user to dismiss the message immediately by tapping on it; though the images don't show it, I've since reverted the height back to the same height as the action bar to make it easier to interact with.

The chart below shows the possible actions at each state:

• User taps the "Edit" action item; the EditFragment is displayed, in an unmodified state.
• The user can tap "Done" at any state. This saves changes, and returns to the ViewFragment.
• The user can tap "Discard" at any state. This discards all changes immediately, returning the user to the ViewFragment
• If the user makes a change (e.g. edits a field), the state is set to modified.
• If the user presses back while the state is modified, the app will display a warning, and the state is set to user warned.
• If the user makes a change while the state is user warned, the state will be reset to modified.
• If the user presses back while the state is user warned, it will discards all changes immediately, returning the user to the ViewFragment, and display a message stating that changes weren't saved.

If the user pressed back by accident, having the warning stage saves her from losing all the changes made (whether the default action is save or discard). Taylor Ling notes:

"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"

For now, I've settled on this but if you've any comments or criticisms against this approach, leave a message on the G+ post below!

Tags:  android  ux  interaction  crouton  behaviour  stacks