Question

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 save 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.

Answer 1

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).”