17

We're designing an application for creating personalized photo books through a Flash-based interface. When the application first opens, we display a dialog encouraging the user to give their project a name (if they don't, it just gets a default name). This dialog also indicates that we auto-save their work each time they change pages or if they start a new book.

In our current book application, we've also had the autosave feature but users were often unaware that the application was saved. So, in addition to the message in the dialog, in the new app we're also using a dynamic Save button state - when it's saving, the label changes to "Saving..." and for a few seconds after a successful save, it displays "Your work has been saved...".

We've done some usability testing and have started a small beta test and have found that users are confused by the difference between the Save button that's part of the main application toolbar and the "Save and Exit" link that's part of the utility nav (incl Help | Feedback | Start New Book). Surprisingly, they are often noticing the link before the button and then wondering how they can save without exiting.

I've thought that maybe removing the word Save from the "Save and Exit" label could be better. I think we added it originally because we were concerned that users would worry that their work would not be saved. However, we could present a saving indicator after they click the Exit link.

So, my question to all of you is what your thoughts on how to properly distinguish between the action of Saving and staying in place versus Saving and Exiting? Of course, the classic template for this is the difference between Apply and Save, but in my experience, very few users understand the difference.

0

4 Answers 4

4

I would follow the standards of a "normal" application. For example, look at the file menu in Microsoft Word. You have "Save" and you have "Close" or "Exit". If you close a document or exit the program before saving it, you are prompted to save your work. That's a very standard workflow for applications, and I'm pretty sure people understand it pretty well. So I think just using the phrase Exit probably would work.

5
  • I agree. Save is one link. Close is another. This is harder to do in certain cases with html where blur means something, but Flash should be fine.
    – Glen Lipka
    Jan 12, 2010 at 2:05
  • I'm wondering if, instead of a dialog interrupting the user, we could have an "Exit" option and that when the user clicks this we simply display a progress indicator that their work is being saved. Essentially the same as save and exit - the downside is that the user doesn't have the comfort of knowing that when they click on that control that their work will be saved.
    – Chris Braunsdorf
    Jan 12, 2010 at 15:19
  • I'm all for avoiding modal dialogues and instead going with auto save option.
    – Janel
    Jan 12, 2010 at 16:02
  • Thanks for all the feedback and suggestions. At this point, I think we're going to try changing the link to just "Exit" and display a progress indicator upon exiting that reinforces the fact that we're saving their work. Users who are concerned that clicking Exit will not save their work will, hopefully, see the Save button, click Save first and then Exit. When they see the save progress indicator on exiting, this will hopefully condition their behavior for the next time.
    – Chris Braunsdorf
    Jan 13, 2010 at 22:34
  • 1
    @Chris - then how do I close a document without saving the changes that I've made? There are many time where I start changing a document and then change my mind and just want to leave it as is. How do I go about doing that? May 3, 2011 at 16:08
2

I would argue for "Save and exit." It reassures the user that they are not going lose any of their work.

Google Docs is a good example of this. Even though I know that Google Docs is saving my work on the fly, I use "Save and close" when I want to close a document. Simply closing the browser (or the tab) or clicking "Exit" leaves me wondering whether I've actually lost my last few minutes of work. I've re-opened several documents to make sure this wasn't the case.

It also provides a way of allowing the user to tell you exactly what they want to do and avoids the need for a pesky dialog box.

2
  • I agree that I'd like to avoid an extra dialog box if possible. The problem we seem to be running into is that users are finding "Save and Exit" before "Save" and then thinking that this is their only option. We considered removing Save altogether since we autosave, but we still wanted to give users the ability to manually save between autosaves and because users have been conditioned to look for a way to save their work even if the app is saving automatically.
    – Chris Braunsdorf
    Jan 12, 2010 at 15:17
  • Chris, your last statement is exactly why I made the recommendation that I made. Users have been conditioned to look for a way to save. In the same way, users have been conditioned on how "Close" will ask them to save if their work hasn't been saved since it last changed.
    – Charles Boyung
    Jan 12, 2010 at 15:37
2

Perhaps part of the confusion is that one is a link whereas the other is a button. I know I would question the difference between the two.

I think what you're describing is similar to Save or Apply, where both are buttons located next to one another. That way it's clear to the user they can select one or the other, depending on what he wants to do.

FWIW I'm not a fan of the modal prompt after performing any action. For instance, I just deleted three files on my PC. Windows helpfully prompts to confirm I wanted to do this action. Seems a bit unnecessary to me.

2
  • We don't really want to put them right next to each other because saving is something we expect that they may want to do frequently while - we hope - Save and Exit would be a less frequent action. That's also part of the logic behind why we made Save and Exit - to give it a bit less prominence (similar to the way many sites have started to make Cancel a link rather than a button). But I think wha't happening is that users are starting at the top of the page looking for anything that says "save" and this is the first control they find.
    – Chris Braunsdorf
    Jan 12, 2010 at 15:14
  • I agree that this is a problem. If "Save" and "Save & Exit" aren't close to one another, people aren't going to understand that they are two different actions. Is there any way you could repeat "Save" in the utility nav as "Save & Edit"? If you place "Save" before "Save & Edit" that would prevent users finding "Save & Edit" first. It would also highlight the fact that there is a difference between the two. If not, is there anyway you could place the two actions side by side?
    – Jeff Van Campen
    Jan 12, 2010 at 15:58
0

Responsive textual feedback would indicate using context comparative language. e.g. if you state "Save and exit", then comparative language would be "save and continue" as you are giving a literal directive with "Save and exit", so continue that literal directive with other textual indicators.

Frames are important and dictate context, they must be in the same frame, or they may not be analogous in context (keep your actions grouped by context, it's really one interactive layer with variable states. e.g. close, save, review are all actions attached to one frame).

"Save" does not mean the same thing as "Save and continue" when compared with "Save and exit". Though "Save" can be necessary, against "Save and exit" it might imply "Save and stay". So, do I have another step?

https://en.wikipedia.org/wiki/Context_(language_use)

As for reminding users to save a form with unsaved data as they attempt to close it, well, that is just what we do as good programmers and UX developers to help people understand when they're about to do something that might cost them. Error control is not the same realm as textual directives and indicators.

Your Answer

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