Re: Nested sheets
Re: Nested sheets
- Subject: Re: Nested sheets
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 30 Mar 2005 18:24:01 -0500
I wanted somebody to lay out the no-nested-sheets argument, and you've done
that very nicely. I'll respond to specific points in context below, and also
comment on some similar points raised by others.
on 2005-03-30 7:44 AM, M. Uli Kusterer at email@hidden
wrote:
> Your use of a sheet here is wrong. Use drag & drop to let the users
> add files to your list and there's no problem with showing the second
> sheet, because there's no first sheet to begin with.
I feel that drag-and-drop should be an optional means of opening files,
never a required means. Hunting through windows to find the source file for
drag-and-drop is very inconvenient in most cases, while the standard open
file panel is a familiar, consistent and simple navigation mechanism.
Sacrificing the ease of use of the standard open panel in order to avoid the
secondary sheet question seems backwards to me. I want the best primary user
interface first, then I want to solve the secondary sheet question in that
context.
I already have an optional file drag-and-drop interface for more basic and
frequent operations in my utility, in any event, so I fear that implementing
drag-and-drop for import, too, would be confusing to the user.
Also, a standard file open panel allows me to set a default location to
which it always opens, which in my utility is a preferred location for
storing these import files. (I have gone the extra mile and made the use of
the default location a user-settable preference.)
The HIG has a pretty good section on when to use sheets, with three common
cases bulleted. The single-window, non-document-based app is one of the
three primary cases where sheets are said to be appropriate.
> Stacking sheets (or modal dialogs) is bad because it forces the
> programmer's order on the user. While you are showing the sheet, the
> user can not do anything else. People just keep doing it because it
> is easier to program. You can have the sheet to make it easier for
> people who won't or can't use drag & drop, but I'd just say in the
> case of an error you close the open sheet and bring up the error
> sheet afterwards.
In my case, the order is inherent in the problem. Making this a modal panel
is important because it prevents loss of information. The user picks a file
to import and clicks the import button. My program says, Wait, that file
contains an item that conflicts with an item you've already imported; pick
which one you want. Either answer is a reasonable choice, neither is an
error. It's a small, simple question; it's closely related to what the user
is thinking about, anyway; and the user's workflow is much simpler if he
answers it right now. There is no need to let this question stop the
workflow cold and force the user to go back to ground zero and start over
again.
In other circumstances, I would present this question in an accessory view
on the standard file open sheet. But in this case the conflict arises
infrequently, so bringing it up in an accessory view in every file open
panel makes it an issue every time, when it's really an issue only
occasionally.
Since this isn't an error situation but only a choice, making the user
choose import from the menu to start all over again is a much worse user
experience. Better to leave the file open panel sitting there when he
dismisses the secondary sheet, to let him know he's still on-task.
> We programmers are much more used to nested designs as the average
> user, because it's a skill we need to have to get our work done. Most
> other people are much more comfortable with sequential processes, and
> ideally want them in the sequence they're thinking of right now. So,
> the less your GUI requires a particular order, the more it gets out
> of the way. And getting out of the way is what every user interface
> should do, so the user can focus on the job they actually want to do.
Normally, that's good advice. But the design issue I meant to pose assumes
that the question is small, it is not an error but a choice, it needs to be
answered in a small number of cases, and it is an inherent part of the
workflow.
For what it's worth, this utility is a programmer's tool. So if you're right
about how programmers think, then my targeted users will be very comfortable
with it.
> And even if your app is an image conversion tool, what your app does
> isn't what the user wants to do. The user doesn't want to convert
> images, she wants to get their web site published, and conversion is
> just a little sub-task she does while already thinking about the
> spelling mistakes in need of fixing on the next page.
Again, this is normally good advice. But the design issue I meant to pose
assumes that a choice must be made. I have thought about applying a default
presumption and documenting it, but I can't think why any user would more
often want to choose replacement or nonreplacement. If the user isn't
allowed to choose, the user will likely be surprised and disappointed by the
result in about half the cases.
For this same reason, I have decided that the AppleScript version of this
command will include a Boolean parameter, something like the familiar
'replacing conflicts: yes/no'.
>> The Cocoa documentation on sheets says that Cocoa is not designed to support
>> nested sheets. This is a poor reason to adopt the HIG's absolute rule
>> prohibiting nested sheets -- especially since it isn't true.
>
> It is true. Since Apple's HIG says nested sheets are bad, Apple
> haven't designed Cocoa to handle them, and moreover, they haven't
> tested it to make sure that even works. And judging from the problems
> some people had with sheets on windows that have a drawer, I wouldn't
> be at all surprised if you would end up with odd behavior in the case
> of two sheets as well. "You're on your own, Jim."
I don't think this is one of those situations where the capability hasn't
been implemented or tested. Sheets and modal dialogs are just NSWindows in
this context, and in my experience you implement nested sheets using exactly
the same calls on the primary sheet (a window) as you normally do on the
main window. I have already implemented this in my app and tested it
extensively, and it's working like a charm. Also, Apple's Cocoa
documentation explains how to make two sheets close at once, so I don't
think this is an unanticipated situation.
I'm not familiar with the drawers-and-sheets problem you mention, but I
would guess it might have something to do with too many parent window/child
window connections. My utility doesn't do drawers.
> Don't do nested sheets. They may even be technically possible, and
> it may seem like you're actually improving the UI, but you're
> thinking like a programmer, not like a user. Fix the problem at its
> core (which is the use of one main window and oodles of sheets
> popping out of it -- why not use a few floating panels or auxiliary
> windows?). Nesting sheets is simply fixing one symptom.
I haven't explained my utility in detail, so it's reasonable for you to
caution against excessive use of sheets when extra windows might be cleaner.
But in this case it really is a one-window utility. I present very few
sheets and then only for very narrow tasks in response to button clicks.
Adding extra free-floating panels and windows would be a step toward
confusion. Having it open as a small window in the middle of the screen when
the user has moved the utility's main window into a corner risks user
confusion. In fact, I suspect a user with a crowded desktop might not even
notice it. Popping it up on the primary sheet seems much more intuitive,
focused, and on-task.
I am mindful of the programmer vs. user mindset issue. I'm a trial lawyer by
day, and thinking like the postman or housewife on the jury instead of like
a lawyer is part of my stock in trade. My instincts have proved to be pretty
good in the field.
> Years of Human Interface research have shown that nested dialogs
> (and, by extension, sheets) make it harder for your users. Don't go
> against that unless you've got at least as much research to back you
> up.
I'd like to read the research you cite, but I don't have time. I suspect it
isn't as open-and-shut as you suggest, when considering circumstances like
those I've posed here.
Thanks for the feedback, and I'm looking forward to any further debate that
may arise.
--
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