Should closing a window save changes?

14 Mar 2007 - 4:35pm
7 years ago
26 replies
955 reads
Al Selvin
2006

We have an application with a dialogue box that allows users to enter
text. Normally there is an OK and Cancel button, users click OK to
save and close the window, Cancel to close without saving. In Windows
(there are also Mac and Linux versions), currently closing the window
by clicking the X in upper right has the same behaviour as clicking
Cancel (closes without saving).

Is this proper? We've had a change request that clicking the X should
save the changes.

I also now wonder if we should prompt the user (e.g. "Close without
saving your changes?").

Many thanks,

Al

Comments

14 Mar 2007 - 4:58pm
stauciuc
2006

Hi,

I am going to skip the 'it depends on your users' part (because I have a
strong feeling about this) and tell you my opinion:
X should not save. Because it is x (it has a 'Delete' or 'Cancel' sound to
it) and because it (probably) has a red background. No matter how modern and
Google-Docs-Save-and-Close oriented your users are, I doubt they would be
very confident that X actually saves the data.
I had a similar dilemma once and I chose to change the x alltogether, to a
more suggestive icon. But that one really depends :)
I would also consider disabling the x to avoid any confusion.

But I wouldn't make it save...

Sebi

On 3/14/07, Al Selvin <alselvin at gmail.com> wrote:
>
> We have an application with a dialogue box that allows users to enter
> text. Normally there is an OK and Cancel button, users click OK to
> save and close the window, Cancel to close without saving. In Windows
> (there are also Mac and Linux versions), currently closing the window
> by clicking the X in upper right has the same behaviour as clicking
> Cancel (closes without saving).
>
> Is this proper? We've had a change request that clicking the X should
> save the changes.
>
> I also now wonder if we should prompt the user (e.g. "Close without
> saving your changes?").
>
> Many thanks,
>
> Al
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/

14 Mar 2007 - 5:10pm
Jason Cyr
2007

Functionality such as Save or Delete should be specifically performed
user actions, they should never be inferred.

When a user is editing an "object" in a window and closes that window we
(as the interface) cannot guess at what they perceived would happen. Why
would it be more correct to save the object than delete it?

A similar situation would be in the case of an online form... The user
fills out the form then clicks a link to elsewhere in the site. The form
obviously wouldn't be submitted.

Jason

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Sebi Tauciuc
Sent: Wednesday, March 14, 2007 2:58 PM
To: Al Selvin
Cc: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Should closing a window save changes?

Hi,

I am going to skip the 'it depends on your users' part (because I have a
strong feeling about this) and tell you my opinion:
X should not save. Because it is x (it has a 'Delete' or 'Cancel' sound
to
it) and because it (probably) has a red background. No matter how modern
and
Google-Docs-Save-and-Close oriented your users are, I doubt they would
be
very confident that X actually saves the data.
I had a similar dilemma once and I chose to change the x alltogether, to
a
more suggestive icon. But that one really depends :)
I would also consider disabling the x to avoid any confusion.

But I wouldn't make it save...

Sebi

On 3/14/07, Al Selvin <alselvin at gmail.com> wrote:
>
> We have an application with a dialogue box that allows users to enter
> text. Normally there is an OK and Cancel button, users click OK to
> save and close the window, Cancel to close without saving. In Windows
> (there are also Mac and Linux versions), currently closing the window
> by clicking the X in upper right has the same behaviour as clicking
> Cancel (closes without saving).
>
> Is this proper? We've had a change request that clicking the X should
> save the changes.
>
> I also now wonder if we should prompt the user (e.g. "Close without
> saving your changes?").
>
> Many thanks,
>
> Al
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

14 Mar 2007 - 5:59pm
dmitryn
2004

Jason,

Although I agree with you in the case of Delete, I emphatically
disagree in the case of Save.

There is no reason why Save should _ever_ be a specifically performed
user action. Users should always be given a choice to undo a save, but
insisting that they always remember to save can only lead to lost time
and annoyed users.

Unfortunately, I can't find research to back this assertion up at the
moment, but here is a nice quote from Jef Raskin's The Humane
Interface to illustrate my point:

"Interfaces must be designed to accommodate our ability to pay
conscious attention to only one object or situation, called our locus
of attention, at a time... A user should never have to explicitly save
or store work. The system should treat all produced or acquired data
as sacred and make sure that it does not get lost, without user
intervention. The user may, of course, deliberately delete anything."

http://jef.raskincenter.org/humane_interface/summary_of_thi.html

Dmitry

On 3/14/07, Jason Cyr <jcyr at riptown.com> wrote:
> Functionality such as Save or Delete should be specifically performed
> user actions, they should never be inferred.
>
> When a user is editing an "object" in a window and closes that window we
> (as the interface) cannot guess at what they perceived would happen. Why
> would it be more correct to save the object than delete it?
>
> A similar situation would be in the case of an online form... The user
> fills out the form then clicks a link to elsewhere in the site. The form
> obviously wouldn't be submitted.
>
> Jason
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> Sebi Tauciuc
> Sent: Wednesday, March 14, 2007 2:58 PM
> To: Al Selvin
> Cc: discuss at lists.interactiondesigners.com
> Subject: Re: [IxDA Discuss] Should closing a window save changes?
>
> Hi,
>
> I am going to skip the 'it depends on your users' part (because I have a
> strong feeling about this) and tell you my opinion:
> X should not save. Because it is x (it has a 'Delete' or 'Cancel' sound
> to
> it) and because it (probably) has a red background. No matter how modern
> and
> Google-Docs-Save-and-Close oriented your users are, I doubt they would
> be
> very confident that X actually saves the data.
> I had a similar dilemma once and I chose to change the x alltogether, to
> a
> more suggestive icon. But that one really depends :)
> I would also consider disabling the x to avoid any confusion.
>
> But I wouldn't make it save...
>
> Sebi
>
> On 3/14/07, Al Selvin <alselvin at gmail.com> wrote:
> >
> > We have an application with a dialogue box that allows users to enter
> > text. Normally there is an OK and Cancel button, users click OK to
> > save and close the window, Cancel to close without saving. In Windows
> > (there are also Mac and Linux versions), currently closing the window
> > by clicking the X in upper right has the same behaviour as clicking
> > Cancel (closes without saving).
> >
> > Is this proper? We've had a change request that clicking the X should
> > save the changes.
> >
> > I also now wonder if we should prompt the user (e.g. "Close without
> > saving your changes?").
> >
> > Many thanks,
> >
> > Al
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
>
>
>
> --
> Sergiu Sebastian Tauciuc
> http://www.sergiutauciuc.ro/en/
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

14 Mar 2007 - 6:08pm
Donna Maurer
2003

Here's where there is quite a big difference between 'save' and 'submit'.

I love applications that save my work as I go and don't need me to do
anything. But I wouldn't expect a simple online form to be
saving/submitting away until I tell it to.

I think Cooper/Reimann About Face II has a long discussion about whether
to save or not to save.

But really, the main issue is that users know what is happening ;)

Donna

Dmitry Nekrasovski wrote:
> Jason,
>
> Although I agree with you in the case of Delete, I emphatically
> disagree in the case of Save.
>
> There is no reason why Save should _ever_ be a specifically performed
> user action. Users should always be given a choice to undo a save, but
> insisting that they always remember to save can only lead to lost time
> and annoyed users.
>
> Unfortunately, I can't find research to back this assertion up at the
> moment, but here is a nice quote from Jef Raskin's The Humane
> Interface to illustrate my point:
>
> "Interfaces must be designed to accommodate our ability to pay
> conscious attention to only one object or situation, called our locus
> of attention, at a time... A user should never have to explicitly save
> or store work. The system should treat all produced or acquired data
> as sacred and make sure that it does not get lost, without user
> intervention. The user may, of course, deliberately delete anything."
>
> http://jef.raskincenter.org/humane_interface/summary_of_thi.html
>
> Dmitry
>

--
Donna Maurer
Maadmob Interaction Design
e: donna at maadmob.net
web: http://maadmob.net/maadmob_id/
book: http://rosenfeldmedia.com/books/cardsorting/

14 Mar 2007 - 7:17pm
cfmdesigns
2004

>From: Al Selvin <alselvin at gmail.com>
>
>We have an application with a dialogue box that allows users to enter
>text. Normally there is an OK and Cancel button, users click OK to
>save and close the window, Cancel to close without saving. In Windows
>(there are also Mac and Linux versions), currently closing the window
>by clicking the X in upper right has the same behaviour as clicking
>Cancel (closes without saving).
>
>Is this proper? We've had a change request that clicking the X should
>save the changes.
>
>I also now wonder if we should prompt the user (e.g. "Close without
>saving your changes?").

In the product I currently work on, there are one or two dialogs where the X box means "proceed forward", while in all the others, it means "Cancel". I think it is in dialogs without a Cancel button that it doesn't mean Cancel.

If users have any expectation about the X, it is that it means Cancel. (Many users are just mystified by it.) Rather than prompting the user, I would say that if there is going to be any divergence from the expectation -- different behavior or no Cancel option -- then don't show it. Removes the problem completely.

In fact, I would say that it should (generally) not be present in modal dialogs at all. Why deal with the added questions?

-- Jim

14 Mar 2007 - 9:05pm
Will Parker
2007

From: Al Selvin <alselvin at gmail.com>
>
> We have an application with a dialogue box that allows users to enter
> text. Normally there is an OK and Cancel button, users click OK to
> save and close the window, Cancel to close without saving. In Windows
> (there are also Mac and Linux versions), currently closing the window
> by clicking the X in upper right has the same behaviour as clicking
> Cancel (closes without saving). Is this proper?

This has been the accepted behavior of closing an application window
in windowing operating systems, as far as I can remember, in every OS
I've encountered back to GEOS on the Commodore 64. Whatever you do,
you shouldn't change that long-held design idea without making the
difference quite clear to the user.

> We've had a change request that clicking the X should
> save the changes.

Doing so without user feedback could _easily_ lead to a different
kind of data loss -- overwriting known good data with data that the
user intended to abandon. Is the amount of work the user might have
to re-do _really_ worth the hassle that could happen if they
overwrite good data with bad by saving when they intended to abandon
the session?

> I also now wonder if we should prompt the user (e.g. "Close without
> saving your changes?").

The usual method for resolving this kind of issue is to capture the
close-window event, check to see if there is saved data from a
previous session, and prompt the user with something like 'You have
unsaved changes. Do you want to save your work or exit?'. Then
proceed to do a normal save, followed by a normal exit.

However, having encountered that kind of creeping nannyism, I'd say
that this would perceived as a serious annoyance by most users, and a
leading candidate for The First Option To Turn Off on any new
install, if you bother to give them the choice.

A _superficially_ less-intrusive method might be to cache the current
session data on a window-close event, and prompt the user at the
start of the next session with something like 'On you last visit, you
exited without saving your work. Would you like to review your
previous work, open a new document, or open a saved document?'

However, this design leaves a large number of questions unanswered.
Will the user remember what they were doing last time? How long will
they remember it? How are you going to remind them what they changed
from the time before that? Are you asking the user to think about
previous work when THEY want to think about new work?

Bottom line -- the change request is a bad one, and should be
resisted for the sake of your customers.

- Will

Will Parker
wparker at ChannelingDesign.com

"The only people who value your specialist knowledge are the ones who
already have it." - William Tozier

On Mar 14, 2007, at 5:17 PM, Jim Drew wrote:

14 Mar 2007 - 11:00pm
Laurie Knaack
2007

I would guess that your problem is more one of expert users accidentally
discarding changes they want, than a problem that currently afflicts novice
users. Be careful when considering design decisions that you don't throw up
obstacles for less-experienced users or "nanny features" that annoy experts.

For things like Windows and Mac system properties dialog boxes, there is
often an X (close) and it performs the same function as "Cancel." Usually
this means "exit without saving changes." This is often part of users'
mental model - that X means "get me out of here," even before the Cancel
button can be found. The disastrous consequence of making X "Save" could
mean that users who expect it to "get rid of this dialog" have inadvertently
entered some text or changed some option, and certainly don't want to
overwrite anything with it - if I didn't mean to bring up the dialog, I
probably don't remember the default options in it. If my changes or
inadvertent text entry are saved (without my knowledge) I may never be able
to figure out my mistake!

My opinion would be to beg you not to deviate from the "standard" behavior
unless you find out that your users really EXPECT the X to save, or unless
consistency requires it (closing a window with the X saves changes for the
rest of the environment/software this is a part of).

If you do make a change, make sure what's going on is clear to your users. A
more subtle indication of unsaved changes might be possible to implement and
might solve the problem: what about changing the text color/highlighting (to
red or something) if the user mouses over the "X" or "Cancel" button? A long
hover might cue a tooltip that indicates "Cancel without saving changes?"
Will Parker's suggestion to cache the current session data on a window-close
event, for later review, might be useful if users frequently want to get
back something they didn't save - but if the X is that big a problem, you
might consider taking it out altogether, and making the actual "Cancel"
button the only way to get out without saving.

Laurie

On 3/14/07, Will Parker <wparker at channelingdesign.com> wrote:
>
> From: Al Selvin <alselvin at gmail.com>
> >
> > We have an application with a dialogue box that allows users to enter
> > text. Normally there is an OK and Cancel button, users click OK to
> > save and close the window, Cancel to close without saving. In Windows
> > (there are also Mac and Linux versions), currently closing the window
> > by clicking the X in upper right has the same behaviour as clicking
> > Cancel (closes without saving). Is this proper?
>
> This has been the accepted behavior of closing an application window
> in windowing operating systems, as far as I can remember, in every OS
> I've encountered back to GEOS on the Commodore 64. Whatever you do,
> you shouldn't change that long-held design idea without making the
> difference quite clear to the user.
>
> > We've had a change request that clicking the X should
> > save the changes.
>
> Doing so without user feedback could _easily_ lead to a different
> kind of data loss -- overwriting known good data with data that the
> user intended to abandon. Is the amount of work the user might have
> to re-do _really_ worth the hassle that could happen if they
> overwrite good data with bad by saving when they intended to abandon
> the session?
>
> > I also now wonder if we should prompt the user (e.g. "Close without
> > saving your changes?").
>
> The usual method for resolving this kind of issue is to capture the
> close-window event, check to see if there is saved data from a
> previous session, and prompt the user with something like 'You have
> unsaved changes. Do you want to save your work or exit?'. Then
> proceed to do a normal save, followed by a normal exit.
>
> However, having encountered that kind of creeping nannyism, I'd say
> that this would perceived as a serious annoyance by most users, and a
> leading candidate for The First Option To Turn Off on any new
> install, if you bother to give them the choice.
>
> A _superficially_ less-intrusive method might be to cache the current
> session data on a window-close event, and prompt the user at the
> start of the next session with something like 'On you last visit, you
> exited without saving your work. Would you like to review your
> previous work, open a new document, or open a saved document?'
>
> However, this design leaves a large number of questions unanswered.
> Will the user remember what they were doing last time? How long will
> they remember it? How are you going to remind them what they changed
> from the time before that? Are you asking the user to think about
> previous work when THEY want to think about new work?
>
> Bottom line -- the change request is a bad one, and should be
> resisted for the sake of your customers.
>
> - Will
>
> Will Parker
> wparker at ChannelingDesign.com
>
> "The only people who value your specialist knowledge are the ones who
> already have it." - William Tozier
>
>
>
>
>
> On Mar 14, 2007, at 5:17 PM, Jim Drew wrote:
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
Laurie S. Knaack
Rensselaer Polytechnic Institute '06 Computer Science

15 Mar 2007 - 8:52am
DrWex
2006

If people don't mind, I'd like to try to pick this apart a bit.

I believe there's an underlying confusion in this discussion between
"Close" and "Cancel." The latter is an unambiguous directive from the
person to discard something. In dialogs where the options are
OK/Cancel, the "X" maps cleanly to Cancel. Clicking the X should
unambiguously close the window and discard contents.

However, when the options are Save/Close there's no clean way to map
the "X". Clearly it's a request by the person to close the window,
but it's not clear what to do with the contents. In our application
we put up a dialog asking if the person wishes to save changes prior
to close. I realize that repeated use of confirmation dialogs can
just lead to mindless confirmation by a bored or distracted person,
but I don't think it's good usability to decide whether or not to save
without a person making a decision in context.

I have great respect for Raskin's work and writing, but in this case
he's just flat wrong. By automating Save, we take away the security
of a 'sandbox' in which a person can doodle, write drafts, project
possible futures, or whatever sort of data processing the application
permits. It's like going around and taking the erasers off of
everyone's pencils.

Sure, you might make some kind of "undo save" functionality but then
you're adding more work that the person has to do (remember the past
state and figure out how much to undo) when if you'd just left his
stuff alone you wouldn't have to do this extra work in the first
place.

This also ignores the fact that many applications or windows don't
exist in isolation and saving from one data set can have side effects
or consequences that the person might want to consider before
committing to them.

(Note that I am not arguing here against auto-save or checkpoint
functionality - I believe that is useful to help people avoid
accidental work loss. But one should not confuse the helpfulness of
auto-save with the mess that invisible Save can produce.)

Best,
--Alan

15 Mar 2007 - 9:40am
stauciuc
2006

On 3/15/07, Alan Wexelblat <awexelblat at gmail.com> wrote:

>
> In dialogs where the options are
> OK/Cancel, the "X" maps cleanly to Cancel. Clicking the X should
> unambiguously close the window and discard contents.
>

I guess we all agree on this one.

However, when the options are Save/Close there's no clean way to map
> the "X".

If we are talking Save/Close, we must be talking documents. In short, I see
the situation like this: In the very beginnings of designing interaction, a
mistake was made: documents were not auto-saved. Thus the omnipresent
"Yes/No" dialog when closing a document appeared.
Now, this de-facto standard is so..de-facto, that we cannot imagine things
could possibly have been different. I, myself, use this flaw in interaction
all the time, to play around in documents as described below, and then throw
the changes away.

Ofcourse, we couldn't possible change this model all at once in all
applications, because that would cause a lot of confusion and problems (like
the ones described by Alan) to a lot of users (like me).

But we can start changing it step-by-step (we can 'design for change')
Google Documents has a very good example, I think. The default is not to
auto-save, but the user can (and is encouraged to :) ) turn Auto-save on.
This way, the user knows about the auto-saving and doesn't rely anymore on
"I can mess around, it's not saved yet"

Ofcourse, we can't afford to do that for all apps. Because it always depends
on users expectations. And the expectation for the "x" button in a document
is in most cases to be given the <Save/Don't Save> dialog.

I have great respect for Raskin's work and writing, but in this case
> he's just flat wrong. By automating Save, we take away the security
> of a 'sandbox' in which a person can doodle, write drafts, project
> possible futures, or whatever sort of data processing the application
> permits. It's like going around and taking the erasers off of
> everyone's pencils.
>

I disagree. The erasers on everyone's pencils should be the Undo mechanism.
Writing on a paper should mean(or should have meant) that the pencil
actually leaves a mark on the surface, not that the mark is recorded
somewhere in mid-air and will only get written on paper when we say "Save".
Again, I understand that automating('invisible') Save today would cause a
lot of confusion and errors. But I still think that the initial model was
wrong.

Sure, you might make some kind of "undo save" functionality but then
> you're adding more work that the person has to do (remember the past
> state and figure out how much to undo) when if you'd just left his
> stuff alone you wouldn't have to do this extra work in the first
> place.
>
> This also ignores the fact that many applications or windows don't
> exist in isolation and saving from one data set can have side effects
> or consequences that the person might want to consider before
> committing to them.
>
> (Note that I am not arguing here against auto-save or checkpoint
> functionality - I believe that is useful to help people avoid
> accidental work loss. But one should not confuse the helpfulness of
> auto-save with the mess that invisible Save can produce.)
>
> Best,
> --Alan
> ____________________________________________________________

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/

15 Mar 2007 - 10:15am
Jacco Nieuwland
2006

Last night I spent quite a bit of time upgrading my Wordpress
installation. And it has introduced some pretty nifty web 2.0 settings
dialogs. But these dialogs (in the sidebar widgets, if you know
Wordpress) do not have any positive close option. The only close is an
'X' in the top right corner. It took me a couple of seconds before I
actually dared to use it after I made some changes. It saves the
changes, but to me this was so counter-intuitive, I literally hovered
over the icon with my mousepointer, afraid to click it.

I would suggest never use the 'X' (which to me has a very negative feel
to it) to do something positive (save your changes and continue.

Jacco

15 Mar 2007 - 11:17am
dmitryn
2004

To add to Sebi's excellent points, I would suggest that this
disagreement is partially an issue of terminology.

I think that Alan is using "save" to mean "save and commit changes"
(an action that should be user initiated), as opposed to "save current
user work/application state in some form" (which should be automated
where possible, and is probably best implemented using some sort of
draft/sandbox functionality, to differentiate it from user-initiated
save points).

This is also similar to the distinction Donna made between "submit"
and "save" in a web form - "submit" reflects a commitment to the
current application state that can only be made explicitly by the
user, while "save" does not.

Dmitry

> I have great respect for Raskin's work and writing, but in this case
> > he's just flat wrong. By automating Save, we take away the security
> > of a 'sandbox' in which a person can doodle, write drafts, project
> > possible futures, or whatever sort of data processing the application
> > permits. It's like going around and taking the erasers off of
> > everyone's pencils.
> >
> I disagree. The erasers on everyone's pencils should be the Undo mechanism.
> Writing on a paper should mean(or should have meant) that the pencil
> actually leaves a mark on the surface, not that the mark is recorded
> somewhere in mid-air and will only get written on paper when we say "Save".
> Again, I understand that automating('invisible') Save today would cause a
> lot of confusion and errors. But I still think that the initial model was
> wrong.

15 Mar 2007 - 11:15am
Christopher Fahey
2005

This question seems like a no-brainer to me, especially after having
drank deep from Jef Raskin's "The Humane Interface" Kool Aid.

Unless the data in question is horrendously massive (large images,
video/audio), all applications should:
1) Auto-save after every single user interaction.
2) Have unlimited Undos -- and save those undos so they can be
accessed in later sessions.
3) Have the ability to separately save (or at least flag) key versions
for archival purposes.

Saving when closing the window is a moot point -- you should *always*
save changes.

Admittedly this is a huge change from how apps and files currently work
today, and people will need to be explicitly re-trained for this
paradigm... but the world has changed a whole lot since the "Save"
feature was first introduced to the world. Significantly, speed and
storage capacity are a thousand times what they were years ago -- and
these quantitative technological constraints were, I think, the only
reasons why the Save feature was not made continuous in the first place.

Basically, I'm advocating for a sea-change in the "Save" paradigm.

I'm being super-idealistic here, I know. But IMHO the more we as
interaction designers start designing systems that conform to this
inevitable paradigm, the better. It's a little early to make it a
baseline usability requirement for ALL applications, but it's a mature
enough concept, I think, that it's worth seriously considering for any
new document-manipulation projects we begin from now on.

-Cf

Christopher Fahey
____________________________
Behavior
http://www.behaviordesign.com
me: http://www.graphpaper.com

15 Mar 2007 - 12:22pm
Martin Kas
2007

On the Mac at least, save on close if often implied, at least for
preferences windows. There is no OK/Cancel button, and closing the window
via the red X button will save the changes and close the window. So you
could argue that for Mac users the expectation would be that changes are
saved automatically, at least if the changes are related to setting
preferences. Windows users might expect the opposite though.

How about asking for a confirmation on close? If there are unsaved changes,
intercept the close and ask if the changes should be saved or discarded.

Martin

15 Mar 2007 - 1:40pm
Will Parker
2007

On Mar 15, 2007, at 7:40 AM, Sebi Tauciuc wrote:

> If we are talking Save/Close, we must be talking documents.

Not necessarily. A window might be the container for a particular
workspace configuration or a set of views on separate documents.

Although we've been talking about document-centered scenarios,
another common question is whether closing a tabbed browser should
retain and re-display the current set of URLs when next launched. One
of the annoyances in Apple's Safari browser is that closing the
browser window loses the set of open tabs in that window. Allegedly,
that will be fixed in the next version by offering two types of saves
for tab sets. One is the ability to manually save a bookmark that
opens multiple urls as tabs, and the other is supposedly an_option_
to silently save and redisplay the current tab set on next launch.

The 'Silent Save' model works in the latter case because the action
_doesn't silently overwrite any vital data_ and _doesn't require the
user to remember what might be overwritten_.

In the case of silent save of a window configuration, you're
overwriting the old workspace layout, which may not always be
appropriate. Therefore, some method of saving and restoring favored
workspace layouts should be offered. Nonetheless, it's likely that
putting the user's tool layout back to the last-used state will not
substantially harm -- and in certain cases, may _help_ -- their
ability to use the application.

> In short, I see
> the situation like this: In the very beginnings of designing
> interaction, a
> mistake was made: documents were not auto-saved. Thus the omnipresent
> "Yes/No" dialog when closing a document appeared.
> Now, this de-facto standard is so..de-facto, that we cannot imagine
> things
> could possibly have been different. I, myself, use this flaw in
> interaction
> all the time, to play around in documents as described below, and
> then throw
> the changes away.

Silent save is fine for new documents, but I can see huge scope for
user error based on inattention or imperfect memory of what they are
saving over in the case of replacing a current document. Therefore, I
can't agree with the idea that 'Close == Cancel' constitutes a flawed
interaction model, when the proposed alternative pattern has not been
described in a manner that:

1) provides equal or better protection of user data,
2) is as readily transferrable to multiple application platforms (as
in 'web, desktop OS, and mobile'), and
3) does not impose a different and equally error-prone set of UI
management tasks on the user.

On the other hand, there is some scope for silent save of all work if
the OS or application offer a _simple, clearly understandable_
revision control system. (Have fun designing that in a manner that
doesn't steal from Apple, BTW.)

Donna Maurer's distinction of Save vs. Submit certainly applies here.
Where a Save action implicitly or explicitly transmits an _action
order_ (other than save my document) outside the user's direct
control, you can't safely do Silent Save.

> Of course, we couldn't possible change this model all at once in all
> applications, because that would cause a lot of confusion and
> problems (like
> the ones described by Alan) to a lot of users (like me).

... And because this is the case, the user is going to be subject to
an enhanced risk of data loss when exposed to a mix of the two methods.

> But we can start changing it step-by-step (we can 'design for change')
> Google Documents has a very good example, I think. The default is
> not to
> auto-save, but the user can (and is encouraged to :) ) turn Auto-
> save on.
> This way, the user knows about the auto-saving and doesn't rely
> anymore on
> "I can mess around, it's not saved yet"

All this, so the user doesn't have to issue a Save command. The
freedom to 'mess around' without potential data loss or the necessity
of naming the current document up-front is a vital part of a
comfortable user experience, in my opinion.

> Ofcourse, we can't afford to do that for all apps. Because it
> always depends
> on users expectations. And the expectation for the "x" button in a
> document
> is in most cases to be given the <Save/Don't Save> dialog.

Actually, _my_ expectation is that when I click the Close Window
button, I can either walk away without further attention OR choose
'Undo'. I don't usually get that level of freedom.

>> By automating Save, we take away the security
>> of a 'sandbox' in which a person can doodle, write drafts, project
>> possible futures, or whatever sort of data processing the application
>> permits. It's like going around and taking the erasers off of
>> everyone's pencils.
>
> I disagree. The erasers on everyone's pencils should be the Undo
> mechanism.
> Writing on a paper should mean(or should have meant) that the pencil
> actually leaves a mark on the surface, not that the mark is recorded
> somewhere in mid-air and will only get written on paper when we say
> "Save".

Don't get too caught up in the metaphor. There are a few subtle but
important differences between pencil+paper and using a computer. In
your example, you are writing on a single piece of paper, which is
directly in front of you. If there was writing on the paper, you have
to review it, decide what to remove, remove it, and then replace it
with new content. You, the user, have complete and immediate access
and understanding of the old data. You also have full responsibility
for all the tasks involved in the change. When this document is
returned to storage, no other document is changed. When you leave the
document on your desk without completing the edits and exit the room,
the document will still be on your desk when you return.

On the computer, Silent Save does NOT give you the leisure of leaving
a document half-edited, because you can't close it without COMMITTING
the half-edited document. If you're in a rush, that could be a disaster.

- Will

Will Parker
wparker at ChannelingDesign.com

"The only people who value your specialist knowledge are the ones who
already have it." - William Tozier

15 Mar 2007 - 1:39pm
Kelly Muñiz
2007

On the Mac system preferences, the changes are saved immediately as
you change a preference (in a dialog box). The X just closes the
window.

On Mar 15, 2007, at 10:22 AM, Martin Kas wrote:

> On the Mac at least, save on close if often implied, at least for
> preferences windows. There is no OK/Cancel button, and closing the
> window
> via the red X button will save the changes and close the window. So
> you

15 Mar 2007 - 3:44pm
cfmdesigns
2004

>From: Sebi Tauciuc <stauciuc at gmail.com>
>
>> I have great respect for Raskin's work and writing, but in this case
>> he's just flat wrong. By automating Save, we take away the security
>> of a 'sandbox' in which a person can doodle, write drafts, project
>> possible futures, or whatever sort of data processing the application
>> permits. It's like going around and taking the erasers off of
>> everyone's pencils.
>
>I disagree. The erasers on everyone's pencils should be the Undo mechanism.
>Writing on a paper should mean(or should have meant) that the pencil
>actually leaves a mark on the surface, not that the mark is recorded
>somewhere in mid-air and will only get written on paper when we say "Save".

Sure it should. Think of the added power and flexibility that would from such an intermediary, not-yet-committed state. Just think of the savings on paper and ink.

Don't confuse the fact that "pen on paper leaves mark" is so ingrained into us that it's hard to conceive of some other mechanism with the current situation actually being *better*.

There are definite benefits to not having to do an explicit save. There are also problem scenarios that it raises. The question isn't whether those scenarios are detriments which are fatal to automatic save, but whether we can design suitable ways to mitigate things such that the scenarios are not (as) problematic.

The value of a "sandbox" is one such scenario; how can we provide a sandbox that ties easily and seamlessly to the automatic save? Can we, for example, have an "Open as Sandbox" command which creates an automatically-saving duplicate of the original which can be committed at some point to merge its stream back onto the original, or be dismissed without harming the original? Can we (singly or as multiple users) open multiple such sandbox variants, including sandboxes of sandboxes, and be easily able to prune, merge, and even graft the tree of sandboxes?

-- Jim

15 Mar 2007 - 3:55pm
Paul Trumble
2004

Aren't there other issues here beyond the users ability to undo an entire
session with a document or whatever. It seems to me that the system should
endeavor to protect work from being lost. I say this as someone who just
watched his computer do a memory dump an hour ago. I lost a lot of work
that I had not saved yet.

Paul

15 Mar 2007 - 3:59pm
.pauric
2006

I would guess that you've "had a change request that clicking the X should
save the changes" because there is no [save] button in the window. Change
[OK] to [Save] and low end users might get it. I expect its the same users
that think by typing text on to the screen 'its in the system'

Call it save or submit or anything that says 'you need to do one more thing
before you move away form this page/window' [OK] doesnt say this

15 Mar 2007 - 4:06pm
stauciuc
2006

On 3/15/07, Will Parker <wparker at channelingdesign.com> wrote:
>
>
>
> All this, so the user doesn't have to issue a Save command. The
> freedom to 'mess around' without potential data loss or the necessity
> of naming the current document up-front is a vital part of a
> comfortable user experience, in my opinion.
>

The freedom to 'mess around' would still be there with a good Undo system,
wouldn't it? It's true that we don't have many good Undo systems, but the
reason for that is exactly that we haven't been building too many. If
autosave had been the standard, I'm sure we would have gotten pretty good at
building solid Undo mechanims by now.

There would have been no necessity of naming the document up-front,
ofcourse. It would have been assigned an initial name, which could have been
changed by the user afterwards (Rename - a whole different issue, isn't it?)

Don't get too caught up in the metaphor. There are a few subtle but
> important differences between pencil+paper and using a computer. In
> your example, you are writing on a single piece of paper, which is
> directly in front of you. If there was writing on the paper, you have
> to review it, decide what to remove, remove it, and then replace it
> with new content. You, the user, have complete and immediate access
> and understanding of the old data. You also have full responsibility
> for all the tasks involved in the change. When this document is
> returned to storage, no other document is changed. When you leave the
> document on your desk without completing the edits and exit the room,
> the document will still be on your desk when you return.
>
> On the computer, Silent Save does NOT give you the leisure of leaving
> a document half-edited, because you can't close it without COMMITTING
> the half-edited document. If you're in a rush, that could be a disaster.

I don't understand exactly what the computer version would be taking from
the real-world/initial situation. Ofcourse, the question is what it could
add, not only making sure it doesn't take anything away. But having to save
everything every 2 minutes just to make sure it's not lost (that's how it
started, isn't it? and that's why everybody still uses the Save button,
despite any Autosave->Recovery mechanisms that some Products have
implemented) doesn't sound to me like added value.

- Will
>
> Will Parker
> wparker at ChannelingDesign.com
>
>
> "The only people who value your specialist knowledge are the ones who
> already have it." - William Tozier
>
>
>
>
>
>
>
Sebi

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/

15 Mar 2007 - 4:10pm
Will Parker
2007

On Mar 15, 2007, at 1:55 PM, Paul Trumble wrote:
> Aren't there other issues here beyond the users ability to undo an
> entire
> session with a document or whatever. It seems to me that the
> system should
> endeavor to protect work from being lost. I say this as someone
> who just
> watched his computer do a memory dump an hour ago. I lost a lot of
> work
> that I had not saved yet.

Most apps that offer the possibility of working on the same document
hour-upon-hour also offer some version of periodic auto-save. Mac
Word, for example, offers autosave as an option -- which I don't
happen to use, because it also silently saves to a temp file.

The thing is, that temp file is not the same as some previously saved
version. On launch, Word checks the state of the temp file; if the
temp file is 'dirty' (changed & doc not saved & NOT DUE TO USER
CANCEL), the assumption is made that it's in this state because of a
previous abnormal exit, and an attempt is made to recover the file as
the current open Word doc. It does NOT automatically write the
abandoned version to the file system, but leaves the choice to save
or abandon the file to the user.

I'll repeat this one last time - the only way Silent Save on Close
would win my trust as a user would be if it positively COULD NOT
overwrite some previously-saved version of the document. I don't mind
an auto-save, if it's not a de facto commit.

- Will

Will Parker
wparker at ChannelingDesign.com
206-228-3187 (cell-preferred)
206-783-1943 (home office)

"The only people who value your specialist knowledge are the ones who
already have it." - William Tozier

15 Mar 2007 - 4:11pm
.pauric
2006

Chris said"This question seems like a no-brainer to me, especially after
having
drank deep from Jef Raskin's "The Humane Interface" Kool Aid.

Unless the data in question is horrendously massive (large images,
video/audio), all applications should:
1) Auto-save after every single user interaction."

Where this breaks, big time, is in remote systems or devices that have
interdependent data points. I've designed an interface to a piece of
equipment that is installed on top of masts and buildings. Its not possible
to apply an IP address on one page, save, and move on to configure routing.
You lose connectivity.

This is a fairly edge scenario but I dont think you can generalize Raskin's
theory across the board.

16 Mar 2007 - 10:53am
Pawson, Mark
2007

I have to say I have been enjoying this thread because it is very
pertinent to a design issue that a developer and I took opposite sides
on for many of the same reasons everyone has listed here. In our case it
was specifically to autosave or not autosave upon selecting the OK
button. However, much to my surprise today I realized that we do have an
application window that does in fact Save when clicking the X button. In
fact, this just shows you how we can get too close to our products; it
only has an X button! There is no OK, Close or Save buttons. I've only
being working here 13 years and forgot about this, of course most of
that was in QA ;)

The application allows a geologist to create their own user tops
(geological formations) database for the wells they have drilled. Its
Gui looks very much like an Excel spreadsheet. A user can change
formation depths, various rock properties, enter comments etc. Its all
immediately saved while working so, technically X is not saving the
changes, its just closing the window. We have multiple level UNDO but if
the users closes the app the stack is cleared. Opening the app again
will display the last changes made with no ability to return to the
previous state. I remember a user complaining about X saving changes
years ago. They thought they could play in the system and then exit
without saving. I believe we explained that our approach was since it's
a database, any changes you make while working in the system are
immediately saved.

So today I decided to do a wee usability review and asked our support
application specialist who has spent several years teaching, supporting
and demoing this app what is the response she gets from users. This is
her reply:

"Yup! I get asked all the time: How do I know my tops are saved? What
saves my tops back to my user database? Why don't we have a SAVE or OK
button? Why isn't there a message popping up asking if I want to save
changes?

It's not obvious what's happening and users do get confused (as did I)
as to what's happening with saving tops."

Great thread everyone. Thanks.

Mark Pawson
User Centered Design Team
IHS

16 Mar 2007 - 1:02pm
leo.frishberg a...
2005

I've been out of touch for two days and 23 posts on this one thread came
through....

We've looked into this particular interaction with great interest and
trepidation.

My two cents:

1) Raskin's notions are absolutely spot-on qualified as "pauric's" most
recent post suggests - when is an interaction ever applied globally
without proper qualification?
2) the problem as stated is the problem - whether to save or not save on
close/cancel isn't the issue and will never be resolved when looked at
that way.

The problem is "What is the user's intention when they've invested time
in changing the state of something?"

If you can't answer that question then you can't resolve the issue.

3) The issue doesn't revolve around "document" or content changes as a
later post suggested as well.

The issue does revolve around how well we inform the user of the
implications of their actions so that they can effectively proceed
without question.

In our enormously complex application - an industrial tool based on
Windows - the user is faced with several dozens of possible tasks many
of which are intertwined and non-linear.

What does it mean when they enter an "area" and make some changes to the
system state? Are they just "trying some scenarios out" or are they
"wanting to commit?"

In our analysis we concluded several things:

A) a "modal" dialog box was the root of the problem - modal boxes
require users to close the box to return control to the main screen -
and we would have to make some kind of distinction among "OK," "Close,"
and "Cancel." This posed an impossible set of scenarios to resolve. We
changed such interactions to modeless dialogs, converting the commitment
issue from a batch process to an individual / incremental change.
Effectively, this changes the interaction from "Have to do a lot of
things at once and commit," to "Properties Sheet."
B) Auto-save on each change, a la Raskin - there is no such thing as
save, just do your work and observe the changes you've made
C) Implementation of "Local Undo" and "Global Undo." With an undo
button (and associated list of actions to undo) local to the modeless
screen, users are able to roll-back their changes to whatever point was
desirable. This is not unlike Photoshop notions.
D) Additional modeless status indicators and messages ::in the main
screen:: users can observe to assist in understanding the effects of
their incremental changes from the local dialog.
E) With all of the above, we were able to remove all "OK," "Apply,"
"Cancel," and "Close" ambiguities (including the red X), and we didn't
have to further interrupt user flow with horrific "Are you sure?"
uncertainties and chatter. We have a single "Close" button that means
the same thing as the red X. Users are absolutely certain at all times
what they have done, what the system has done and what state they are in
both before and after closing the dialog.

Conclusion:

i) This is a specific path we've chosen based on our users, our
application, our platform, etc. - it absolutely isn't a prescription
across the board
ii) It's really really hard to implement - but that doesn't matter to
our users, so it isn't germane to the conversation. To implement a
desirable user experience, we have to build what users want, expect and
desire, not what is easy.
iii) It has required a significant change to our s/w architecture - in
this case, the question is: why did we have such an architecture to
begin with, not how difficult it is to realign the architecture with
users' needs.

Leo

3 Apr 2007 - 2:12am
Anonymous

Martin wrote:

> On the Mac at least, save on close if often implied, at least for
> preferences windows. There is no OK/Cancel button, and closing the
> window
> via the red X button will save the changes and close the window. So
> you
> could argue that for Mac users the expectation would be that
> changes are
> saved automatically, at least if the changes are related to setting
> preferences. Windows users might expect the opposite though.
>
> How about asking for a confirmation on close? If there are unsaved
> changes,
> intercept the close and ask if the changes should be saved or
> discarded.

This is incorrect.

In most Mac OS X applications (Finder, Safari, etc.), preference
changes happen immediately, as soon as the checkbox/radio button/
button is clicked. You don't need to close the window.

There are a couple of exceptions/variations:
- In Mail > Preferences > Accounts, changes must be confirmed with a
Save/Don't Save/Cancel sheet
- In DVD Player and iTunes, the preferences dialogs are modal, and
you must click OK

Paul

shad 96c / uw cs 2001
/ mac activist / fumbler / eda / headliner / navy-souper
fan of / sophie b. / steve poltz / habs / bills / 49ers /

"One hundred percent of the shots you don't take don't go in."
--Wayne Gretzky

3 Apr 2007 - 6:45am
Darryll DeCoster
2007

It should depend on the delivery platform. If the forms are to be hosted
within a website or web app, then they should follow the standard function
of the web. Which would discard the unsaved data, possibly with a
confirmation box, although I would build in a warning or confirmation that
they have unsaved data which will be lost if the window is closed.

I recently added a Mac to my mass of computers, and honestly it is very
counter intuitive to not have to click a save or apply button on changes.
That's not say I think it's wrong - but having been a Windows user since the
days of Windows 3.1, I am a little accustomed to some things. If the user
base is primarily a Windows user base, then the function should conform to
what they expect there as well - unless there are very compelling reasons to
make the change.

Darryll

--
www.floggingenglish.com
www.delivermyliver.com

On 4/3/07, Paul Schreiber <shrub at mac.com> wrote:
>
> Martin wrote:
>
> > On the Mac at least, save on close if often implied, at least for
> > preferences windows. There is no OK/Cancel button, and closing the
> > window
> > via the red X button will save the changes and close the window. So
> > you
> > could argue that for Mac users the expectation would be that
> > changes are
> > saved automatically, at least if the changes are related to setting
> > preferences. Windows users might expect the opposite though.
> >
> > How about asking for a confirmation on close? If there are unsaved
> > changes,
> > intercept the close and ask if the changes should be saved or
> > discarded.
>
> This is incorrect.
>
> In most Mac OS X applications (Finder, Safari, etc.), preference
> changes happen immediately, as soon as the checkbox/radio button/
> button is clicked. You don't need to close the window.
>
> There are a couple of exceptions/variations:
> - In Mail > Preferences > Accounts, changes must be confirmed with a
> Save/Don't Save/Cancel sheet
> - In DVD Player and iTunes, the preferences dialogs are modal, and
> you must click OK
>
>
> Paul
>
> shad 96c / uw cs 2001
> / mac activist / fumbler / eda / headliner / navy-souper
> fan of / sophie b. / steve poltz / habs / bills / 49ers /
>
> "One hundred percent of the shots you don't take don't go in."
> --Wayne Gretzky
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

9 Apr 2007 - 11:15pm
Anonymous

On Apr 3, 2007, at 4:45 am, Darryll DeCoster wrote:

> I recently added a Mac to my mass of computers, and honestly it is
> very
> counter intuitive to not have to click a save or apply button on
> changes.
> That's not say I think it's wrong - but having been a Windows user
> since the
> days of Windows 3.1, I am a little accustomed to some things. If
> the user
> base is primarily a Windows user base, then the function should
> conform to
> what they expect there as well - unless there are very compelling
> reasons to
> make the change.

I don't think this has anything to do with being *intuitive* -- it's
just what you're used to. Windows is full of extraneous steps, while
the Mac OS follows the direct manipulation principle more closely.
(An example is the Mac OS X Finder's lack of a rename command. You
just click on the the file name and wait.)

Another reason instant-apply preferences make sense is Mac OS X's
window layering model.

With a modal dialog, the sequence of events is clear:
- make the preference change
- click OK
- see windows update

In this case, you're blocked from interacting with other windows
(documents) until the change is complete.

If you open a modeless preferences dialog and make a change, I feel
it would be confusing if the change *didn't* affect existing windows
until you clicked OK ... or Apply ... or Save ... or whatever the
button may be. Having the changes occur immediately is consistent
with other interactions, like changing the text to bold.

Paul

shad 96c / uw cs 2001
/ mac activist / fumbler / eda / headliner / navy-souper
fan of / sophie b. / steve poltz / habs / bills / 49ers /

"Never retreat, never explain, never apologize -- get the thing done
and let them howl."
--Nellie McClung

Syndicate content Get the feed