Re: Nested sheets
Re: Nested sheets
- Subject: Re: Nested sheets
- From: daniel <email@hidden>
- Date: Wed, 30 Mar 2005 17:38:11 -0800
Nested sheets strike me as hint that something "unsavory" is going on.
I think it's an opportunity to rethink the design carefully.
You've got a user action in your program: "import stuff from file." A
side effect of the this action is that items might get replaced. One
common method of performing this user action is through a file picker.
Another method you've mentioned is via an AppleScript command. The
approaches you're providing to the user are already divided in each
case. The user has to use a different mentality for each case. That may
be acceptable, but it has consequences both to your code's complexity
and to the user's grasp of the program.
In the file picker case you take the approach "I'll ask you if the
issue comes up."
In the AppleScript case you take the approach "You must tell me
beforehand what to do if the issue comes up."
If you add support for this function via a drag or paste operation,
will it be "I'll ask you if the issue comes up," or "hold a special key
while dragging to replace"? If you ask when it comes up, you've got a
duplicate functionality to the file picker case, but in a different
context. The differences between these contexts will likely require
different code paths. By responding differently to the basic "import
stuff" action depending on the route the user took, you limit your
ability to easily expand your program with new routes in the future.
Consider designing around your AppleScript method. Since it's
programmatic, it necessarily encapsulates everything needed for the
action to be performed. You said that you didn't want to waste the
accessory view on something that would be used only rarely by the user.
Why didn't that same argument prevent you from "cluttering" the
AppleScript command? Your AppleScript command is telling you the right
thing to do. The action your user is trying to perform accepts an
option. It's stingy of you to withhold that option from the user!
Consider this benefit of including all information in the file picker:
by publicizing the option to the user in the accessory view, you give
the user confidence that they will not suffer data loss by performing
the action. If you don't publish it, then the the user doesn't know
until they read the manual or until after the first time they encounter
the "conflict" case, that they will in fact be saved from data loss.
If your user doesn't know that you are looking out for them "only when
the issue comes up" then they may be living in fear each time they
import, carefully avoiding the possibility of encountering that
condition.
Finally, by including the option in the accessory view and retaining
that preference across invocations, you give the user the ability to
easily choose and apply without interruption their preferred
methodology. A user whose work habits led them to frequently "import
to replace" might get quickly annoyed by the need to constantly pass
through your confirmation dialog.
Daniel
On Mar 30, 2005, at 3:24 PM, Bill Cheeseman wrote:
In my scenario, if the secondary sheet is dismissed with a "don't
replace"
answer, the primary sheet remains in place ready for the user to select
another file without having to reopen the sheet again. The user is kept
on-task.
_______________________________________________
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