Re: Nested sheets
Re: Nested sheets
- Subject: Re: Nested sheets
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 30 Mar 2005 18:29:47 -0500
on 2005-03-30 11:54 AM, Marco Scheurer at email@hidden wrote:
> Nested sheets also seem bad to me, but not just because they are
> sheets: nested modal dialogs are just as bad. I really can't suffer
> Windows endless nested dialogs...
Sure. But I've got to let the user know somehow that there's a conflict and
give him a means to resolve it. My utility really doesn't involve a lot of
windows popping up unexpectedly all the time. This is the only instance
where such an issue arises. I just want to find the simplest way to let the
user deal with it, and it seems cleaner to bring it to the user's attention
and then immediately send him right back where he was with a minimum of
fuss.
The weight of opinion seems to be running against me. However, what has
begun to strike me about the replies is that everybody seems to be willing
to go to very complex lengths just to avoid a simple nested sheet. The
counter-examples are beginning to prove my case, I think, because they all
involve more busywork on screen and with the mouse than the simple nested
sheet. Why does everybody have such a negative reaction to a nested sheet in
a narrow situation? I've been using it for a while now in my utility, and
it's very simple and clean in practice.
> Even worse, there's a big problem with your plan: one of the buttons of
> the 2nd sheet will close both of them. This is, in my opinion, not user
> friendly and not obvious.
The Cocoa documentation, if not the HIG itself, has long included
instructions about how to do exactly this. I can't put my finger on it at
the moment, but I read it again just this morning. Something about calling
-orderOut.
It seems clear enough to me: The user chooses a file and clicks Import in
the primary sheet. A small second sheet pops up and says, Are you sure? (or
words to that effect). The user says Yes, damn it!, and the operation is
immediately completed in accordance with his original instructions (i.e.,
the primary sheet disappears along with the secondary sheet). (Of course,
like all user interface designs, it requires attention to the wording and
appearance to make sure it is as obvious as possible.)
> The alternative: the open sheet is closed, if there is a problem
> another sheet pops up is much better. There's not even a need to reopen
> the open sheet after a cancel, I think. If the first chosen item is
> problematic and canceled, there's no reason that another one would be
> good or that the user want's to choose another.
In the normal use of my utility, the user is more likely to want to import
another file than to give up. So making him go to special effort to reopen
the primary sheet seems like putting unnecessary obstacles in his way.
Leaving the primary sheet open keeps the user right on-task.
> If the import was lengthy, you wouldn't do this with a progress /
> cancel alert panel would you?
I'm not sure what you're suggesting. But in general, of course the nature of
the task is always relevant to the interface design. In fact, that was my
original point. I have a very simple question that has to be answered rarely
while choosing a file to import. What's the least intrusive and disruptive
way to get the user's answer? (The time it takes my utility to recognize
that there is a conflict is negligible, so there is no delay or wait-time
involved.)
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden