My application has a interests page where the user can select which interests they wanted selected. It looks like an expandable listview with checkboxes.

When the user first enters the page, the application downloads the latest interest from the webserver. And when they are done, if there are changes, the changes are uploaded to the webserver.

The interests are important because they are used somewhere else. I am wondering if I should just save in the background when they leave the page and notify them if it fails, or should I explicitly ask them if they want to save when they try to leave the page?

  • Sounds like something that should auto-save, it's very easy to add/remove these items correct?
    – Ben Brocka
    Feb 21, 2012 at 21:05
  • It's kind of like stumbleupon where you can edit interests, so very easy to change. But I think I might split it to show selected items and have a another screen that allows you to edit it.
    – Hank
    Feb 21, 2012 at 21:33
  • People like confirmation. A 'save complete' is key...be it with a formal SAVE button or something more like how Twitter uses the 'add to list' functionality with an ajax call with every check action.
    – DA01
    Feb 28, 2012 at 3:52

4 Answers 4

  • A user who is altering the page will want confirmation that that change has been carried out successfully.
  • It's important to ensure that a user who is visiting the page to view information, doesn't unintentionally alter information.

It's possible to fulfil both these cases without making use of an explicit save button, and depending on your interface it might be less obtrusive and more intuitive to do so - but ensure you keep your user informed.

Let them know when their information has been successfully saved - and provide a clear indication when settings have been altered but haven't been saved yet.

Also, think about where your user has come from and where your user is about to go. If they have visited the page to specifically to change settings, they might be expecting to be able to define their choice using a save-like action.

  • 2
    Android applications don't have "save settings" buttons for the most part.
    – dnbrv
    Feb 21, 2012 at 21:19
  • That might be true, however I think it's more useful to deal with concepts rather than implementation here. Feb 21, 2012 at 21:27
  • 1
    Asking for confirmation on reversible actions is useless.
    – dnbrv
    Feb 21, 2012 at 23:07
  • 2
    @dnbrv, I agree - I haven't suggested asking for confirmation, I'd suggested the user should receive confirmation. There's a difference. Feb 21, 2012 at 23:52

A prompt to confirm settings is a logical conclusion to the process. However, unlike most other systems, the default behavior on Android is to automatically save changes in settings (and it doesn't feel strange, at least once you're used to it). Thus, you shouldn't prompt for saving unless there's no way to change the selection. (I hope the app allows users to change their mind later.) Yet, if the changes aren't visible right away, it makes sense to show a toast message to notify the user of success upon selection or returning to the previous screen.

What you also need to check is how easy it is to see the selection. If your list is too long (3+ screens) you should consider adding a tab to show what user already has with a button Add more that links to the main list.


In general, it's good to automatically and silently save settings as-you-go. It's also a good idea to store settings locally until a 'sync' occurs with the server. How and when this 'sync' occurs is up to you; for settings, it's probably best to sync when leaving a dirty (modified) settings screen. In cases where a sync (or otherwise save-over-the-network) operation may fail, it may be useful to show a Toast (see the bottom of Android Design: Notifications for info on this) to the user indicating success. But, as you'll notice in most system apps, this is uncommon, as saving should generally be automatic and silent.


Since you have decided on the listbox type of display, this affords you some luxury in interfacing. My solution would be that when a user touches the box, grey out the background and have two buttons appear: "Save" and "Cancel". If a user touches "Cancel", the buttons and box fade out in a manner appropriate with the UX guidelines of Android. If the user touches "Save", the buttons and box fade out and the word "Saved" should apear on the listbox somewhere.

As for when you actually save, I would do it immediately when the choice is made. When the user leaves the screen, I would show either a notification in the UI somewhere which subtly but effectively communicates the saving of their choices.

You really never know when a phone will no longer have power and users expect their choices to be saved immediately in a mobile environment. Telling the user their information is saved in an appropriate way will make your application that much better than the one which does not; thus engendering trust between the user in the future and you.

For your reference: Android UX Guidelines

  • You're suggesting to introduce an unnecessary step into the workflow: confirming every single selection. That's bad UX.
    – dnbrv
    Feb 28, 2012 at 3:46
  • As your own answer below started out with "A prompt to confirm settings is a logical conclusion to the process.". I would venture it is not bad UX. Your comment gave me pause however. The better solution would be to simply save the selection on touch. The user could touch again to unsave. Simplicity.
    – Jkales
    Feb 28, 2012 at 6:39
  • There's a difference between confirming all settings and each selection. I was talking about all of them and you're suggesting to confirm every single one of them. It might sound fine in theory but in practice you'll get annoyed by the third confirmation modal.
    – dnbrv
    Feb 28, 2012 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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