This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: Modal dialogs again
- To: Keith Seitz <keiths at cygnus dot com>
- Subject: Re: Modal dialogs again
- From: Jim Ingham <jingham at apple dot com>
- Date: Mon, 21 May 2001 10:48:17 -0700
- Cc: Tom Tromey <tromey at redhat dot com>, Insight Maling List <insight at sources dot redhat dot com>
Keith,
I don't think that I ever said I wanted all windows modal. I do favor
modal dialogs for alerts and for configuration panels, unless there is a
good reason not to make them modal.
1) Alerts:
Error messages like "Couldn't connect to target board" or "Your program
just crashed" certainly should be modal, and SHOULD be dialogs. They
only exist to warn the user of an unusual condition, and usually mean
that the thing the user is trying to do isn't going to work - so routing
them to the console is a sure recipe for confusion - You don't notice
that one line in the console buried somewhere, but step JUST doesn't
work!!!!
AND they have no long-term value, so being able to accumulate them
behind the running windows of the application serves NO useful purpose.
They should be properly created, so they float on top of the
application, are dismissed both with a <Return> and with a mouse click,
so it is convenient to get rid of them. But they should be modal.
I don't think that Tom's Netscape example is particularly good - it has
less to do with whether modal dialogs are good, and more just reveals
bad programming on Netscape's part. If he was trying to do something
that was going to fail in such a way that his work would be lost, he
should get 1 (and only one!!) dialog immediately saying that. Not
telling the user that right away, or just spitting a line to stderr, is
doing the user a disservice - it is letting him waste his time, so that
the program can laugh at him later. If the error was one that he could
recover from when he commits his work, then you should delay the dialog
till the commit, and then offer options for recovery, since the
situation might get better between the time he started composing and
when he sends.
2) Configuration panels:
I also do think that you need to consider stuff like making a non-modal
Target dialog carefully. The dialog exists to change the state of the
application in a way that affects future use, so you need to have a
clear & obvious representation of the state HAVING changed. Does is
happen right when you change one of the combo boxes? This may or may
not be a good idea depending on whether it can interrupt extant
services - you don't want to penalize the user for just playing and the
rule that everything that can be reversable should be is a good one...
If you don't commit changes immediately, you have to have an "apply"
action. But you need to then make sure it is clear when there are or
are not "unapplied" changes, or the state of the application can get
confusing. The user could get interrupted by a co-worker, mail message
or whatever, think they had applied the changes, go on... It's ok to do
this, but you introduce another layer of signification to the UI, which
you had better keep up faithfully, and which adds more noise to the
dialogs.
That is why modal dialogs are good for this sort of interaction. When
the dialog is up, it is clear that you are fiddling with the state of
this part of the application, but just playing, and you can always
Cancel. When you are done, you dismiss the dialog with a clear OK, and
now you are back using the App. This model is easy to implement,
maintain, and understand. I would only move away from it if there is
some real benefit to having the configuration panel open while you are
not actually changing the configuration, or if it is the sort of thing
you are going to want to fiddle with a lot, so that the time to post the
dialog is disruptive.
Jim
On Monday, May 21, 2001, at 07:03 AM, Keith Seitz wrote:
> I think it was Jim who wanted all windows modal. Right now, I am just
> going to fix the dialogs to behave the way they are currently
> implemented.
> The decision about which should be modal and which should not could be
> quite lengthy. :-)
>
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer