3

Does anybody have any suggestions/recommendations for cancelling and saving within android? The issue that I'm having is I have to open a screen in a full screen dialog with save-able options on it, but there is also an option to move to another screen within the dialog with yet more save-able option. I don't know what to do when the user goes to the second screen. Should there be more save and cancel options on that, should changes just be saved automatically? I've looked through other android apps but I haven't found anything similar.

I'd love to be able to keep all data on a single screen but I haven't found a solution for it. It's for a checkout flow, when a user wants to change their address.

First full screen modal

second screen with editable details

  • If the User has filled up all the details on the current screen and clicks to Continue to the Next Screen, Save the data of that screen. – Swapnil Borkar Oct 10 '15 at 13:19
  • Thanks for the answer but the thing is that this is a mini flow within a checkout flow. I agree that continue automatically saves. I decided in the end to just use an annotated save icon, the user can cancel using the back button. – Donal Hanafin Oct 20 '15 at 11:53
  • Okay got it. Your approach works too. The only problem I see with a Save button is, what if like in MS Word, the User fails to click on it and has to exit the app or force closes all apps, etc. There needs to something that saves the previous record for the User as per the Activity Lifecycles for an app, rather than keeping a single manual button. Of course, this is an extreme test case, but one worth thinking. – Swapnil Borkar Oct 20 '15 at 13:48
  • 1
    Indeed it is but it's an mvp that I'm working on so it's the bare minimum that we're going for. You should see what else we're having to cut out for the moment!! Definitely something to consider in the future. Thanks for the help – Donal Hanafin Oct 21 '15 at 14:42
2

Google Calendar actually has an excellent example of this workflow.

enter image description here

In the image above, edit and delete actions are called out distinctly. Delete is far from edit - as far as calendar events go, you don't want to accidentally delete the item when adding more details.

Once you start editing, you have "discard changes" (#2) and "save changes" (#3). The actions are very clearly identified and give you the option to "back out" of the workflow if you end up not wanting to make changes.

Lastly, if you're ever doing something that could result in you losing work (like filling out a long address or editing an event), confirm the action. The Android design guidelines have an awesome flowchart that captures some rationale of "when to confirm".

In your case, I would recommend copying the pattern almost exactly.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  • Thanks for that really detailed answer. It was really helpful to give an understanding of the problem that I'm trying to solve. The way I implemented was almost the same as what you have except I used a back button on the final screen that autosaves when a user goes back and does a form validation to make sure that all the changes that have been made are legitimate. I think your way is probably a bit better as it gives the user an extra option and keeps tasks a bit more separated. – Donal Hanafin Feb 22 '16 at 17:38
  • @DonalHanafin Thanks for following up. It might help the "educational" aspect of StackOverflow to post some screenshots of the flow from your application as well. – nolcotin Feb 22 '16 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.