RE: A New Keyhole Type!

software-keyholes-bounces-xIg/pKzrS18HpDbxM/[email protected] wrote:
> What I mean is that it is not impossible (for most of those
> modal dialog boxes) to make code, which does not force them
> to be modal and still works just fine.  But that work should
> start at the design stage. :-(  And since it wasn't for most
> programs, we end up with that huge usability problem in most
> programs. :-( 
> 
> How much experience do you have trying to do this?

Enough to know that it can be done.

> Are you personally guilt-free of using modal dialogs?

I am sorry, but I do not understand the question.  I was talking
technical issues.  The word guilt has no meaning in that area.

> What OS do you program under?

What does it have to do with anything, what OS do *I* program under?

> Modal dialogs are pervasive under Windows.

If you mean that under Windows, most programs use modal dialogs by
default, I agree.  If you say they must, I don't.

> The
> only program I use regularly that uses mostly modeless
> dialogs is Nikon Capture for processing raw images from Nikon
> digital cameras.

That shows how bad the problem is.

> Our own application here at Autodesk
> (Inventor) also uses a lot of modeless dialogs, but they
> aren't the usual case where you need an answer before it
> makes sense to do anything else.

I think if you have read my previous mails you can clearly see, that I
was not referring to those (minority) cases, when a dialog must be
finished in order to do anything else.

> In the Inventor case, you
> HAVE to interact with the active document while the dialog is
> up.

I don't have to.  I don't even have the software. :-)

This is the case, when the programmers have no choice, so they do the
right thing.  Usability means ease of use, *not* that it *can* be used.
If your dialogs would be modal, the software would not work at all.
Usability comes way after that.

> It just seems like a completely different situation.

>From what?  From forcing the user to close 2-3 dialogs until he can look
at a document number (for example)?

> Our Open and Save dialogs are still modal.

I can see no technical reason why they should be, although there may be
no hassle there as you rarely open a second dialog from that one, so you
can still "uncover" any area of the main window(s) if you need to see
them.

> Unconditionally saying modal dialogs are "bad" and putting
> the epithet, "keyhole," on them seems pedantically
> disconnected from reality to me.

I am still waiting for convincing arguments.  Preferrably facts and
figures, because I do not think that I am such an important or
influential person that my work experiences or ethical standards would
change facts.

As for an example of a happy little modal dialog: ClearCase automounter.
At every boot, it happily (in the middle of the boot process) reports to
me in a modal dialog, that it could mount my views.  So I have to sit
there during the 6 minutes bootup process, just to press an OK button
after 3 minutes, so that my computer will continue booting.  I could not
care less that it could remount the views.  That is its job.  If it
worked, I don't wanna know about it.

But wait!  There is more!  If ClearCase *cannot* mount the views, it
reports them one-by-one, EACH in its own modal dialog.  With about 10
seconds between them, so that you will pull your hair out until its done
(6 views: 1 minute).  But wait!  There is more!  Altough they do modal
dialogs, there is *nothing* else but an OK button on them.  I cannot
tell: hey, don't try the others, I am sitting on an airplane, no
intranet...

That was only one example.  Another one is Kate, the wonderful editor,
which report in a MODAL dialog after each find/replace how many it has
done.  Today I had to do find/replace in about a 100 files.  Now I am
typing with my tounge.

Attila