Re: Modal dialogs again

[Jim Ingham <jingham at apple 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