Re: [Usability]Keeping the Quit menu item

[Wesley Leggette <wleggette gate net>]

On Wed, 2003-03-19 at 15:41, Havoc Pennington wrote:
> On Wed, Mar 19, 2003 at 02:24:34PM -0700, Joshua Adam Ginsberg wrote:
> > Wait, wait, wait... have I been living in a cave? We're *abandoning* the
> > idea of having Quit in the menu?!
> > 
> 
> The user model for "Quit" involves the idea of a process. If you don't
> know what a process is, you can't understand what that menu item does.
> 
> Do we expose "process" anywhere else in the UI? Not really.
> 
> gnome-terminal for example can use a separate process for each window,
> or not, depending on --disable-factory command line option, and it
> looks the same to users either way. Nobody ever complains about that
> or wants to quit all terminals at once. In fact the only complaint I
> get is confusion where people expect a process per-terminal, because
> they're used to xterm. I use --disable-factory most of the time myself
> for robustness.
> 
> A web browser could easily work either way as well, right now they all
> work like "factory mode" but there's not any special reason why, other
> than efficiency. If an app was fast and small enough it could easily
> just start a new instance for each window for robustness reasons.
> 
> There's no reason we can't have one process that implements several
> windows that look like different apps to users, even. 
> 
> The user visible concepts are "application" and "window" - where most
> likely each toplevel main window plus its dialogs should be an
> "application" (in implementation terms, share a group leader window).
> There's no user-visible concept of a process.

I think this is where Mac OS X has gnome and windows beat. In that
windowing system, there is a distinct different between windows and
applications, and therefore quit is still present. And I think the
concept of "processes" or "applications" vs. "windows" is important, so
it's good to have a clear way of showing the different to everyday
users. This memory issue is one clear case that shows users should be
aware of what processes are running on their computer.

Also, another justification comes up in big applications like Adobe
Photoshop, where quiting the application is usually bad from a workflow
standpoint (long startup times), but closing all windows is usually good
(close the pictures you're not working on).

> 
> It only makes sense that if you close a main window, its dialogs and
> toolboxes will close also, so you don't need Quit for that.
> 
> I don't really buy the memory argument; Linux (or any sane unix) is
> fully capable of swapping out apps you aren't using, at least if you
> put them on another workspace or minimize them so they never get
> redrawn. If an app is swapped out it's not going to be slowing down
> whatever you're currently doing.
> 
> Basically, if you can't explain the Quit menu item without invoking
> the idea of a process, then you can't explain the Quit menu item at
> all, because processes are not in the user model.
> 
> Havoc
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
-- 
Wesley Leggette <wleggette gate net>