Re: Display dialog frontmost?
Re: Display dialog frontmost?
- Subject: Re: Display dialog frontmost?
- From: email@hidden (Michael Sullivan)
- Date: Fri, 13 Sep 2002 15:08:14 -0400
- Organization: Society for the Incurably Pompous
Christopher Nebel writes:
>
On Wednesday, September 11, 2002, at 01:26 PM, Paul Berkowitz wrote:
>
> If you activate a different app and then want the dd to display in
>
> front
>
> while there, then put it in the tell block to that app:
>
>
>
> tell application "Finder"
>
> activate
>
> display dialog "Boo"
>
> end tell
>
This will certainly work, but I want to point out that this sort of
>
thing is considered to be in bad taste, interface-wise. The user is
>
doing what they're doing, and it's presumptuous and rude to suddenly
>
jump in their face yammering on about how they need to choose a file
>
*right now*.
Hmm. The real interface issue is that you activated another application
on them. If there's enough justification to do *that*, then there's
plenty of justification to throw up a dialog. If the script doesn't
expect the script to bother them, then I wouldn't do this, but I
wouldn't issue an activate command to anything in the middle of the
script either.
A large number of scripts are either run as direct user interaction,
where the user calls for the script to be run, and expects it to finish
fairly quickly, and maybe as part of it's action, *expects* it to change
what's active on the screen, or *expects* to be asked for input. Just
like when one launches an app, one *expects* it to end up in the
foreground. In this case, I'd much rather have a script issue the
dialog in the frontmost, rather than sit there until I happen to notice
a bouncing/flashing icon in the periphery, and make me do a menu call to
get to it.
Another large number of scripts are run as pure automation on headless
workstations. There, you don't expect a user to be there at all, and so
putting up a dialog isn't going to bother anyone. In fact, it's
helpful, since it's much more likely to be noticed from another
workstation, or by someone walking by than a blinking icon, especially
if spoken alerts are enabled.
Of course, if a script is designed as a background daemon that runs on a
user machine and normally never interrupts the user at all, but just
handles some task and maybe takes it's time about it, then I would
absolutely agree with your guideline. IME, that's a minority of
scripts.
I have a huge rant ready on "human interface guidelines" that don't take
into account the fact that different programs tend to generate different
user expectations, and (SHOCK!), different *users* often have different
expectations in the same situation. Frankly, some people at Apple
really could use a jolt in the posterior on this issue, as I keep seeing
decisions that reduce user choice. Think Keyboard cdev in 9.0 All of
my workstations are backgraded to eliminate this. Think Command-Tab.
It would be really nice if apple would stop stepping on keys that people
have been using for other purposes for *years* in the name of a better
human interface.
>
Of course, this only applies if you plan to give your script to someone
>
else. If it's purely for your own use, you can do whatever you darn
>
well please.
When I *sell* my scripts to other people, I expect to allow them to
customize the script's behavior as much as possible. So, I might have a
property that indicates whether it should stay in the background or not,
and some functions that let the user set this property to their liking.
If I'm giving a script away as editable freeware then they can make
whatever changes they desire on their own time, so I don't worry too
much about providing a customizable interface. I just please myself or
my users.
But when feasible, I never want to depend on some monolithic human
interface guideline to determine a script's behavior, and IMO, a very
cold and nasty place in hell is reserved for programmers who believe
that forcing the user to deal with their concept of a "good human
interface" is the way to work.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.