[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Dialogs don't have menus
From:       Derek <fountai () hursley ! ibm ! com>
Date:       1999-09-10 8:06:28
[Download RAW message or body]

> > This reads like the opinion of someone, who is prepared to stick to it
> > regardless of common sense. The Find dialog example is sound - a classic
> > UI mistake - but only because it changes shape when it has done it's
> > stuff. To say that that application shouldn't have a menu is silly.
> 
> Sorry, the writer knows what he is talking about. There are differences
> in types of applications only because they are graphically different.
> This is a typical example of an application that uses a mixture, even in
> windows the user will search for buttons, try to find the functions in
> the menu etc.
> 
> The example is sound.

The example is sound. The rule isn't...

...unless someone defines *exactly* what is and isn't a dialog box.

> A dialog just asks for info (unually text/numbers) and gives you buttons
> to act on them (common: ok, cancel etc.)
> 
> Traditionally the dialog just asks the user for info.
> Traditionally the dialog box has no menu's, it is silly to create an application
> out of a dialog box.
> Traditionally the dialog box gives the user a single buttons to exit (cancel,
> or indeed exit)
> Pop-up menu's, same thing as normal menu's, no don't use them.

If a window pops up from within an application, prints a message and
asks for acknowledgement, that's a dialog box. It shouldn't have a menu,
agreed.

If a window pops up from within an application, asks for a line, or
several lines of text, and gives an OK button to confirm, that's a
dialog. Maybe. But with no menu how can the user paste into the text
area? (Yes, they'll be hotkeys, etc, but a user who is used to clicking
on Edit->Paste may not know them.) I would suggest a menu with Edit and
Help pulldowns are valid here.

If a window pops up as the main window of an application, only asks for
text or other information, and gives buttons to confirm, that's not a
dialog, although it might look like one. It's an application. The MS
Find utility is an application, not a dialog. It might be a stupid
application which rearranges itself instead of popping up an Explorer
window, but's still an application. Applications should have menus.

Consider a window which appears printing a filename, and showing it's
file read, write and execute permissions as choice options which the
user can change. If it's popped up from KFM, it's a dialog. If the user
has started such a dedicated task manually, it's an application. The job
is the same, the appearance is the same, but one should have a menu (to
exit, etc) while the other shouldn't.

The rule that "Dialogs don't have menus" is too sweeping. Menus should
be allowed where menus are appropriate.

[prev in list] [next in list] [prev in thread] [next in thread]