Save vs Save and Exit

11 Jan 2010 - 7:06pm
4 years ago
7 replies
977 reads
Chris Braunsdorf
2008

We're desigining 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 applciation, we've also had the auto save
feature but users were often unaware that the application was saving.
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.

Comments

12 Jan 2010 - 3:33pm
Brian Mila
2009

We recently made a similar change in our apps. We had "Save &
Close" and "Cancel" as standard buttons in our web app. We've
been reworking our UI, and one of the changes to our standard is that
all buttons should only perform a single function. Thus we've moved
to a "Save" and a "Close" button. Now the users can save w/o
exiting (which they couldn't do before). The downside side is that
to Save and Exit requires two button clicks, and we also need to trap
the Close event to warn the user if they haven't saved. Its more
work on the backend but should be more usable for the user. We
won't know for sure until we test it, which is a couple months away
at this point. I'd love to know if anyone has previously tested
this already.

Brian

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=48302

13 Jan 2010 - 5:19am
Dimiter Simov
2006

Chris,
I'd say remove the "Save" part from "Save and Exit". When people exit, save
their changes. You can show a saving in progress indicator while exiting.

"Normal" people would expect that all their changes are saved when they
exit. People who have had some experience with software and computers have
learned the hard way that they need to explicitly tell the program to save,
so such people may not be sure whether Exit will also save their changes.
Check it with users.

You can also consider moving the Save button to a more prominent position.

Here's a more radical idea. Have you thought of removing the Save button?
You just save everything users do. Of course, in this case, you may need to
provide an undo mechanism.

Dimiter Simov
Lucrat Ltd. www.lucrat.net
Netage Solutions Inc. www.netagesolutions.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Chris
Braunsdorf
Sent: Mon, Jan 11, 2010 16:07
To: discuss at ixda.org
Subject: [IxDA Discuss] Save vs Save and Exit

We're desigining 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 applciation, we've also had the auto save
feature but users were often unaware that the application was saving.
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.
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.725 / Virus Database: 270.14.127/2603 - Release Date: 01/11/10
21:35:00

13 Jan 2010 - 5:31pm
Chris Braunsdorf
2008

Thanks for the input. I'm leaning in the direction of what you're
suggesting, Dimiter. Have an Exit control and then display a saving
indicator.

Not quite ready to remove the Save button altogether - our experience
in testing is that users definitely look for it (even though we tell
them that we auto-save) and the fact that we're not saving every
time they make a change - just when they switch pages, click the save
button, exit the application, or select to upload additional photos.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=48302

14 Jan 2010 - 10:55am
Diego Moya
2005

I like how the GMail interface handles the case for saving a new message as a
draft: a "Save now" button that gets disabled after the content has
been saved (either by the user or autosave). The button is reactivated
when the user makes a change to the content.

This provides a persistent indicator of the current state of data
(saved or unsaved). In case of a recent auto-save, the user can close
the window and understand that the data is saved even if there is no
"Do you want to save?" question.

14 Jan 2010 - 11:02am
Oleh Kovalchuke
2006

Do not remove Save button, if you save on those system-significant events
only.

If you can implement autosave periodically on change (a better approach),
add time stamp in the "Document has been autosaved" message. Seeing the
stamp is quite reassuring. In this case you can safely remove Save button.
Look at autosave in Google spreadsheet for example.

--
Oleh Kovalchuke
(816) 808-6177
Skype: tangospring

On Wed, Jan 13, 2010 at 8:31 AM, Chris Braunsdorf <chris at braunsdorf.com>wrote:

> Thanks for the input. I'm leaning in the direction of what you're
> suggesting, Dimiter. Have an Exit control and then display a saving
> indicator.
>
> Not quite ready to remove the Save button altogether - our experience
> in testing is that users definitely look for it (even though we tell
> them that we auto-save) and the fact that we're not saving every
> time they make a change - just when they switch pages, click the save
> button, exit the application, or select to upload additional photos.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=48302
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

14 Jan 2010 - 5:17pm
James Yuan
2010

I think the design in Google Doc is a good reference. It provides both
Save & Save and close command, and put them next to each other in File
menu. In addition they are provided as button in upper right corner,
and Save button in toolbar. The reasons are:
1. Many users has formed a very strong habit to do save now and then,
by pressing the Save button or Ctrl-S without even thinking about what
they are doing. Removing Save button, or even dimming it, work against
users' habit, and thus increase their metal workload: i.e. they need
to understand how your application is handling the save. It might
take longer time for users to figure out why the Save button is
dimmed then just allow them to press it even all the changes has been
saved. In addition, even when they understand it, they has to switch
mental models between applications handling save in different
manners. So it might be good to just stick to the old "standard"
always available Save button.

2. Save and close should be put together and clearly labeled. Most of
the time, or almost all the time, users want to save the changes and
close. It's very logical and easy for users to combine them
together. Mentioning both save and close in the command reassures
users that their work will be saved before close. If there is only
"close" in this command, users may have to guess whether save will
be done before they press the button. Or the application has to popup
a dialog to ask "do you want to save?". Either is ideal. It's more
intuitive to just say clearly "Save and close". But this kind of
save may cause problem in case a user does want to discard the
changes. At least in Google Doc there isn't a clear way to do it.
Using revision history can solve this problem in a not very
straightforward way. Since discarding changes is a very rare case, it
should be OK to do it in a more difficult way so that the most often
use case is better supported.

3. Autosave is also valuable but the use case is different from the
Save button. So both can be provided.

4. Putting these two command together makes them easy to find and
compare.

James

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=48302

17 Jan 2010 - 8:39pm
Formulate
2007

Hi Chris

Interesting problem.

If you do go the route of taking the word "Save" out of "Save and
Exit", perhaps you could:

- add some text under the Exit link/button that says "Your changes
will be saved" and/or
- have use of the Exit link bring up a dialog asking whether to save
changes or not.

The former will at least give confidence to those users who are
unsure about whether they will lose changes on exit.

Cheers
Jessica

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=48302

Syndicate content Get the feed