Re: Sheet interferes with close widget and app quit
Re: Sheet interferes with close widget and app quit
- Subject: Re: Sheet interferes with close widget and app quit
- From: "R. Tony Goold" <email@hidden>
- Date: Tue, 21 Aug 2001 11:09:22 -0400
>
Not in the classic Mac OS. But back then you couldn't create a new
>
document, or even work on another document in your application either.
>
Now, with the advent of sheets, the user can continue to work with other
>
documents when the modal sheet is up. Why shouldn't they be able to quit
>
the application as well (assuming that dismissing the sheet would not
>
cause data loss, of course)?
The intent of an alert, whether a modal dialog or a sheet, is to force the
user to respond to a situation before proceeding. You'll notice there's no
close button in modal dialogs, nor any standard Dismiss button for sheets.
Having the OS guess the correct behaviour for dealing with a situation
where user input is expected is not a good thing, especially when there is
no way of knowing which button is the non-destructive Dismiss. It defeats
the whole point of trying to get the user's attention. This sort of UI
assumption is the kind of thing hashed to death on comp.risks.
>
For instance, I'm using OmniWeb and I visit a secure website. Out slides
>
a sheet asking me for a username and password. "Uhoh, look at the time,
>
IronChef is coming on. I've gotta run". IMO At this point I should be
>
able to quit omniWeb and have the sheet automatically dismissed for me.
>
Why should I need to click 'cancel'? If I'm quitting, it is obvious that
>
I no longer care about visiting that secure site and all I want to do is
>
close the window.
I disagree that cancelling is the correct behaviour. If forced, I would
expect the OS to choose whatever is the default button. But again, the
purpose of sheets is to draw the user's attention and make them choose.
What if it's a window you minimised long ago, possibly an https
transaction that was in progress and you'd expected would complete in the
background? Now the application has completely lost its way of notifying
you of a serious error condition. You run out the door, write a few
cheques, and get nailed for writing bad cheques because that inter-account
transfer you thought you did was cancelled without your awareness.
Yes, the user should be aware of what they're closing when they quit, but
applications should still have a way of forcing the user to respond to
that particular document before dismissing it.
>
So in my situation, when I become disconnected from the server, I need a
>
way to lock the user from touching my main window, and my main window
>
alone. The list of options I came up with
>
>
1) Hide the main window when I get disconnected and display a non-modal
>
connect window instead.
>
This situation is very disorientating... "hey, where'd my window go!?"
Agreed.
>
2) Dim everything in the main window and display a separate non-modal
>
connect window
>
This is good, except the connection that my main window is dimmed
>
because the user is disconnected is weak, especially in OSX where windows
>
are intermingled between apps.
Which would easily be remedied by a feedback mechanism to the user, such
as a status bar or a 'disconnected' icon that draws attention. If
connection to the server is so critical, there should probably be a
Connect button in your main window. Clicking that should pop down a sheet
(not a separate non-modal window where the relation is unclear!) prompting
the user for connect info and then proceed with reconnecting and
resensitising the window's components.
>
3) Show a connect sheet on my main window
>
This option is IMO perfect, since it shows a great connection that my
>
main window will no longer function (and is locked) because the user
>
needs to connect first.
Provided it's clear to the user why this sheet is appearing. It might be
even better to pop up a sheet saying "You have been disconnected, would
you like to reconnect? (Yes) (No)", then dismiss the first sheet and pop
out a second one for connection if they choose Yes. The result of choosing
No depends on your intents, but its actions should apply only to the
window it affects, not to your app as a whole (i.e., it shouldn't quit).
>
However, I do not want the sheet crippling the user from closing my
>
window, or quitting my app.
Then add a Cancel/No button to your connect sheet :-)
>
If they are pressing Apple-Q, they want out and they want out now.
>
Ignoring the connect sheet I had open and closing the window will cause
>
_no_ data loss, so why is it wrong?
Hopefully I've already addressed this above. Allowing a component
requiring user intervention to be circumvented automatically renders it
useless and, worse (from a human interface perspective), meaningless. I
certainly don't want my users getting accustomed to dismissing
document-specific alerts just by quitting the app, because they'll
complain when mine don't behave that way! The user interface metaphors are
there to keep consistency across all applications, not just within one,
and it's critical that I be able to force a user to respond.
>
And if it is wrong, what would be the better way to handle my app getting
>
disconnected? A non modal dialog just feels very clunky in this
>
situation.
You should track the connection state in your app and allow for
user-initiated connects and disconnects, rather than forcing that action
upon the user. If an unexpected disconnect happens, prompt the user if
they want to reconnect, but make your app capable of handling the
situation where it is both disconnected and idle (no sheets requiring
attention) at the same time by desensitising your window's components
(except that precious Connect button!).
>
Would adding a 'Quit' button to my sheet be less pollutant to the
>
interface metaphor?
Worse, in my opinion. Sheets are window-/document-specific so they should
not cause actions that affect other windows/documents.
>
How about removing all the controls in my window from the superview and
>
replacing then with the contents of my connect dialog? I am truly at a
>
loss of a more elegant way than a sheet to accomplish this.
If you go this route, it could be simplified by keeping two views in the
window with only enough room for one. Switch which one is the visible view,
depending on the connection status. Think of the Project Builder sliding
tabs, but simplified. That would allow you to automatically close the
window on quit, since it wouldn't be using sheets.
Cheers,
Tony