RE: modal dialogs

> -----Original Message-----
> From: Scott Meyers [mailto:smeyers-Q9ZaqOuDrMJWk0Htik3J/[email protected]] 
> Sent: August 05, 2003 7:44 PM
> To: Software Keyholes; Software Keyholes
> Subject: RE: [SK] modal dialogs
> 
> 
> At 09:35 AM 8/4/2003, Frank Paris wrote:
> >Modal dialogs should only be used when they ARE necessary, when the 
> >program needs user input before it can procede to do anything else 
> >without getting into incoherent or undefinable behavior. Otherwise 
> >modeless dialogs should be used. Modal dialogs under Windows 
> MFC aren't 
> >that much simpler than modeless dialogs. What isn't simpler is the 
> >developer's task of thinking before acting rather than 
> mindlessly using 
> >modal dialogs all the time. I have found however that most 
> of the time 
> >modal rather than modeless dialogs are appropriate.
> 
> Hmmm, I have found quite the opposite.  Other than "This 
> program has performed an illegal operation and is about to 
> crash," can you give me examples of where you believe modal 
> dialogs are appropriate?

Most of the time they are necessary to avoid confusing the user. I
started looking at various applications and noticed that theoretically
the various dialogs could come up modeless but if they did you could
wind up with dialogs all over the place and lose track of their
relationships, i.e. where they came from and what problem they were
supposed to solve. What I was talking about above however was the
program itself getting confused. Modal dialogs are used to keep things
simple for both the user and the programmer. I suppose you could argue
that keeping things simple for the programmer is not of concern to the
user experience, but it becomes so when there is so much for the
application to keep track of that bugs are introduced and maintenance
problems proliferate exponentially. It then becomes an economic issue.
It is better for a user to have a program that keeps things simple than
one that allows for undisciplined freedom that crashes all the time.

One thing that a program might have to do is control the number of
modeless dialogs that can be active at the same time. Autodesk's
Inventor program for example embodies "commands" in modeless dialogs,
but it makes sense for only one command to be active at once. So if one
command is up, you can move back and forth between the main window
client area and the command dialog, but if you start another command
dialog, the first command dialog automatically disappears, as if it has
been cancelled. One of the things we strive for in the Inventor program
is to minimize the amount of mousework (clicking on buttons, etc.) the
user has to do. Making a command dialog go away automatically when
another command is started is a violation of one user interface
principle, where nothing is supposed to happen unless the user takes
explicit action, but not to do so violates our above mentioned principle
of minimizing user mouse activity, e.g. answering to a dialog that says,
"Do you really want to start another command and cancel the current
one?" We also have "expert" modes where we might have something like
that that the experienced user can turn off.