User interface considerations for saving changes in document-based app

I'm making an image editor (e.g. for drawing pictures and diagrams) for iPhone and Android mobile devices. This question would also apply to anything that involves editing documents e.g. spreadsheets, videos, text files.

When the app starts, the user sees all the documents they've created so far in a gallery and clicking a document opens up the editor. My saving options so far, which work as they do on desktop applications, are: "save" (which is good for saving incremental progress) and "save a copy" (which is good for saving a milestone in the editing phase). When the user exits the app, they see the usual "Save changes? Yes/no/cancel" dialog.

However, this approach doesn't seem great:

1. I've found it common in tests that users accidentally pick the wrong option when shown the "Save changes? Yes/no/cancel" dialog.
2. Explaining the difference between "save", and "save a copy" to causal users in particular is tricky and is something where misunderstandings will lead to data loss. I want an option like "save as" as well but this is probably the most confusing s开发者_如何转开发ave option especially since you don't really want the user to specify a filename on a mobile device.

Are there any better interface models I could consider for handling the saving of complex documents on a mobile device?

Some ideas I've considered are:

• When quitting the app, changes are always saved to a new file on exit without prompting. The user can then manually discard the original or the edited copy if they wish

and/or

• When "save" is selected from a menu in the editor, the updated document is saved to a new file F and all future "save" actions will overwrite F. This lets the user save their progress as they go without having the option of destroying the original file by accident. The only issue with this is what to do if the user saves, makes some changes and then wants to leave the editor while discarding the changes since the previous save. The only ideas I can think of are to add a prompt when exiting or to add a "discard" changes menu option.

I'm looking for something that is flexible, easy to explain and prevents mistakes.

Edit: Due to the nature of my app (large images, destructive and slow operations), it is impractical for me to offer persistent undo (I know there is some discussion to be had here but it isn't practical here even if we just consider development time). This makes autosaving documents more troublesome. I'm aware this limits my options but I'm not expecting perfection.

When I'm in doubt how to handle such things I start some of the flagship apps and look how they do it.

Let's take Numbers for iPad as example.
If I edit a spreadsheet Numbers never asks me if I want to save, it just saves.
If I make changes I can undo them later because there is a Undo function. And even if I force quit the app the undo option will be there the next time I launch it.

If I want I can duplicate my spreadsheet, but this option is hidden in the "My Spreadsheets" submenu. It's not visible when you create a spreadsheet.

So I would suggest to implement some undo functionality so you can save without user interaction.

I wonder how you ask the user to save when the application exits anyway. On iOS this should not be possible.

Btw, this is what the iOS Human Interface Guidelines say:

Ask People to Save Only When Necessary

People should have confidence that their work is always preserved unless they explicitly cancel or delete it. If your application helps people create and edit documents, make sure that they do not have to take an explicit save action. iOS apps should take responsibility for saving people’s input, both periodically and when they open a different document or quit the application.

If the main function of your application is not content creation, but you allow people to switch between viewing information and editing it, it can make sense to ask them to save their changes. In this scenario, it often works well to provide an Edit button in the view that displays the information. When people tap the Edit button, you can replace it with a Save button and add a Cancel button. The transformation of the Edit button helps remind people that they’re in an editing mode and might need to save changes, and the Cancel button gives them the opportunity to exit without saving their changes.

For iPad, save information that people enter in a popover (unless they cancel their work), because they might dismiss the popover without meaning to. For more guidelines specific to using popovers, see “Popover (iPad Only).”

Your app should automatically save without requiring an explicit action by the user. 99% of tne time this is what the user wants, so why put up an obstacle (a prompt) that inconveniences the user 99% of the time to protect tbem 1% of the time?

If you are really concerned about tnat ladt 1%, save N versions and provide a revert feature. If you had an interface for that which would show what was added or deleted in each version, even better. I bet if you do that and monitor how often it is used you'll be surprised at how rarely people actually use it.