Re: Nested sheets
Re: Nested sheets
- Subject: Re: Nested sheets
- From: Hamish Allan <email@hidden>
- Date: Wed, 30 Mar 2005 15:48:27 +0100
On Wed, 30 Mar 2005 14:44:29 +0200, "M. Uli Kusterer"
<email@hidden> wrote:
At 5:47 Uhr -0500 30.03.2005, Bill Cheeseman wrote:
An example: My app is a single-window, non-document-based utility, so
most
dialogs are appropriately implemented as sheets on the single window.
The
primary sheet is a standard open file sheet used to select a file for
import. The user chooses a file to import and clicks the primary
sheet's
default button. Sometimes (but not always), the chosen file contains
an item
that conflicts with an item already imported into the utility, and I
need to
present a small secondary dialog or sheet to ask the user whether to
replace
the existing item. If the user chooses not to replace the existing
item, the
secondary dialog or sheet is dismissed and the import is canceled,
but the
primary sheet remains open so the user can choose another file to
import (or
cancel the primary sheet). If the user chooses to prefer the new
item, the
import is carried out and both the secondary sheet or dialog and the
primary
sheet are dismissed.
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.
Are you not doing exactly what you later caution against: thinking like
a programmer, not like a user? The logic behind crippling the user's
options for importing files in order not to have to face the question
doesn't seem to me to be usability-focussed.
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.
I don't understand where you're coming from here. The second sheet will
do this anyway, by design.
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.
You seem to be trying to imply that people only ever use modal dialogs
because they can't be bothered to write properly multi-threaded
applications. Yet you also seem to understand that in this case there
is a need for a modal dialog. So the whole drag and drop thing seems to
be a red herring.
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.
That is the beauty of sheets: they explain to the user visually that
this is the order in which things need to be done. You think it would
be easier for users if the main window disappeared whilst they were
being asked to choose the files for import?
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.
I understand your assumptions, but not your point. Again, what are you
suggesting as an alternative?
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."
FWIW, this would be enough to make me hide the file dialog sheet before
presenting the secondary sheet, but I still don't think that makes it
any clearer for the user.
This is not a linear workflow. The user does not have to think about
how to deal with conflicts unless conflicts arise, so nesting is a much
more natural way of expressing it. Users *do* have these concepts, even
if they don't understand the term "nesting": e.g., "We'll cross that
bridge when we come to it", "Give me a breakdown of those prices", etc.
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.
Can you explain how floating panels would be used to address this
problem, or how you think auxiliary windows would make the modal
workflow easier to understand for the user?
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.
Maybe this is the problem: years of HCI research have shown that people
get confused by nested dialogs, so people automatically assume that the
same applies to sheets. Can you explain why this is necessarily the
case?
Best wishes,
Hamish
_______________________________________________
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