Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm making a photoshop-like image editor (e.g. for drawing pictures and diagrams) for iPhone and Android mobile devices. I'm designing the interface for saving documents with regards to how data loss is handled and what confirmations are asked. I expect users will want similar flexibility to what is offered by typical "save", "save as" and "save as a copy" actions found on desktop software.

Note that because of the nature of my app (large images, destructive edits, real-time interaction, slow operations), it is impractical for me to offer persistent undo for documents. I know there is some discussion to be had here but it isn't practical even if I just consider the available development time. I'm aware this limits my options but I'm not expecting perfection.

At the moment my interface works like this:

  • The user is presented with a gallery of documents.
  • If the user taps document E, the editor opens with document E loaded.
  • During editing, the user may explicitly save their progress to a new document B if they like. Future saves overwrite B.
  • During editing, the user can save a copy of the editor state to a new document (i.e. save a copy).
  • If the user tries to return to the gallery, the are asked if they would like to save the current state to B or if the current state should be discarded.
  • Periodically, the editor state is saved to an autosave file A. This never overwrites B (as the user might want to discard recent changes) and is only used in the event of a crash.

Some things I don't like about this design:

  • One problem I've tried to avoid is the user accidentally overwriting the document that was opened initially. Documents are always saved as new files so this isn't a problem but this does mean the user will probably have to go about explicitly deleting old files if they make a lot of edits.
  • The user can accidentally hit "discard" on exit. I thought about removing this option entirely from the dialog (so the dialog options would be "Save and return to the gallery" and "Cancel") and only having this option available from a menu to make it very hard to hit accidentally. People that discard things a lot will find this annoying though. I could even add an "undo the previous discard action" button to the gallery I suppose.
  • Explaining to the user that the explicit save action writes to a new file, "save and exit to the gallery" writes to this same file and save as a copy always creates a new file is tricky.

Can anyone see how I can improve my UI here?

share|improve this question

1 Answer 1

To me it seems that the difference between a Save and Save as a copy would be quite clear.

I was thinking maybe you could make the normal Save always make a backup-version of the previous version first. You keep a limited amount of back-up copies (configurable somewhere, as disk space is scarcer), and this would allow a user to rollback or go back if suddenly something does seem wrong.

I am not entirely sure if in that case you would still need the explicit Save as a copy. Maybe yes, but at least it would not need to be that easy to reach anymore?

What do you think?

share|improve this answer
    
I thought about this: when replacing a file, you move the old file to a recycle bin or having some kind of history function. I'd rather avoid this complication if possible though. "Save as a copy" would still be important though as the copies are usually significant to the user and you never want to recycle these when running low on space. –  user4342 Mar 29 '11 at 14:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.