Close vs. Exit? [Was: Re: [Usability] GNOME UI principle: All applications should saveinternal state? ]

[Ryan McDougall <ryan mcdougall telusplanet net>]

On Mon, 2004-04-05 at 19:15 +0400, Andrei Yurkevich wrote:
> 
> I think that saving application state only makes sense if the application
> has been terminated (but not closed by user). For example, when the browser has
> been showing some page and you logoff without shutting down the browser.
> Otherwise, if you close the application manually there is no point to
> restore application state unless you ask the application to (selecting some
> menu item?)
>
> cheers,
> Andrei
> 

Ah, the old Close vs. Quit dichotomy! Maybe we can finally differentiate
between the two with regards to application state: Close means "I don't
want to see this document any more." Quit means "I'm leaving the this
"workspace" temporarily to go do other things, but when I come back I
expect everything as I left it." The technical details about what gets
loaded or removed from memory, or whether a process starts or get
terminated, it totally irrelevant from Close/Quit and is left up to the
app developer.

Thoughts on how this relates to apps always saving state? As Sean said,
whether the user doesn't want to see a certain document, that is part of
its state, and the app remembers that when the user chooses Close by
removing the document from the state information. Otherwise, when he
user chooses Quit, the app always saves the state, including what
documents were open at the time.

The only problem I see right away is that currently many people use
"Exit" as a synonym for "Close All", and they would require some re-
training to figure out the semantic difference between the two modes.
Of course there are probably some apps that don't quite fit into this
Close/Quit model, but I can't think of any right this moment. ;)

As for concerns about "secure" remote resources, such as a banking
website, an app would never save that state due to security reasons;
which should be pretty obvious.

Cheers,
Ryan