Scott Raney <raney_at_metacard.com> writes:
> All I can find in the 2.0.43 source regarding this is the
> "MODALITY_IS_EVIL" #define which just changes the properties a Motif
> window (I'm not sure why, perhaps it is just to tell the Motif window
> that modal enforcement is not supported).
Yepp, this was the option that I had been thinking of. I cannot tell,
what difference it makes, because I enabled it ever since I compiled
my first copy of fvwm.
> While I'd agree with you that they should be used sparingly, you'll
> have even less luck convincing UI designers that they're obsolete than
> I've had convincing pointer-focus afficianados that *that's* obsolete
> ;-) The fact that nearly all apps on MS-Windows and the Mac use modal
> dialogs is pretty clear evidence that you're way out on the fringe on
> this one.
<FLAME MODE>
You see, that is one of the many reasons why I do not use these
environments ;-) I might be able to accept that some people actually
like modal dialogs, but I can see no reason whatsoever why this could
not be made an option. The only exception is, that you accept the
lazyness of the programmer being a valid excuse.
</FLAME MODE>
Although I feel very strong about this topic, it is not intended as
flame-bait. You said, that MetaCard is a developer's tool, thus you
might have some influence on setting policies. I would like to suggest
that your policies consider the needs of all potential
customers/users. Therefore, the ability to configure all "religously"
discussed features of the GUI should be the first and foremost design
criterion! (these topics include: pointer mode, modality, keyboard-
vs. mouse-driven, amount of colors, keyboard layout, ...) Leave the
final decision to the end-user, but provide default settings that you
consider sensible and that are commonly accepted in your target
market.
So far, the only seemingly good argument for modal dialogs appears to
be that they require your immediate attention if there has been a
serious error. The reasoning is, that you could not do anything else
anyways, before answering this dialog, so you might just as well be
forced to answer it. I do not believe this to be true:
Imagine a texteditor; when closing the window the text is supposed to
be autosaved, but a hard-error occurs and the system is unable to
write the file. Writing to a backup file fails just as well, so the
application needs your help and pops up a modal dialog asking you what
to do now. The options are 1) save under another name, 2) forget about
the whole thing and discard the data, 3) mail the file to you so that
you can recover it from your mailbox, 4) return to the main
application; unfortunately, many application programmers forget the
latter, because it complicates the program design.
As a user, I might be able to think of a couple of other options: 1) I
might want to select the entire text and after copying to the
clipboard, paste the contents to a different application, 2) I might
want to use "xv" to get a snapshot of the current window, if only it
was not obstructed by the modal dialog, 3) I want to select print-file
instead, so that I get a hardcopy of my work, 4) I know why this error
occured and I want to select another entry from the main window in
order to fix it, 5) I have to double check a couple of other options
in the main application before I can really decide on which button to
press.
Pro-modality people usually suggest that you could just as well close
the warning dialog and then (hopefully) return to where you left
off. Only 1) this does not work in all situations, 2) it is
counter-intuitive to the way that I work, 3) it might have taken
considerable effort to finally get to this stage where the box popped
up; closing it now would require me to re-do all this work after I
fixed the original error.
Markus
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sat Oct 26 1996 - 21:51:32 BST