Re: [Usability] Re: RFE - API change from GtkMessageDialog to GtkAlert

[Maciej Stachowiak <mjs noisehavoc org>]

On 23Nov2001 07:36PM (-0500), Owen Taylor wrote:
> 
> Thanks for the suggestion. Unfortunately, it's way too late
> to do it for 2.0. (We've now cut off even tiny API changes.)
> 
> We could _add_ this for 2.2, however. Feel free to file a bug to that
> effect. (Personally I think it would be confusing to programmers and
> probably lead to inconsistency on the desktop.)
> 
> The change to make the icon extend all the way down the side would be
> easy enough to do compatibly with a little hackish repacking of the
> GtkDialog in the init function; anybody who actually _did_ put help
> buttons in their GtkMessageDialog would perhaps get a non-optimal
> result, but otherwise it would be fine.
> 
> (Of course, this arrangement does exacerbate the problem that
> message dialogs tend to be too wide in aspect ratio.)
> 
> Where do nautilus-style "Details" buttons go?
> 

My 2 cents:

The only critical flaw with the current GtkMessageDialog API is that
it only allows button labels that come from a fairly small fixed set
(OK, Yes, No, Cancel, Close), and only in a restricted set of
combinations (for example three buttons are not possible).

However, we are encouraging developers to use button names meaningful
to the specific situation ("Save" in a save dialog, not "OK"), and we
need to solve classic 3-button problems like the "save before
quitting" dialog.

It seems to me this problem can be solved compatibly in 2.2 with an
addition to the existing MessageDialog API, but in the meantime we
would have to encourage GNOME developers to avoid using
GtkMessageDialog.

That's one of the dangers of bottom-up design - if you don't consider
the interface up front, you may end up with an unsuable API.


Authentication alerts or other alerts with special controls can be
implemented using ordinary dialogs, so lack of explicit support for
them is not a fatal flaw.

Regards,

Maciej


> 
> Gregory Merchan <merchan baton phys lsu edu> writes:
> 
> > I realize that this is too late for the freeze.
> > 
> > I'd like to see a change from the GtkMessageDialog api to a GtkAlert api.
> > There are three parts I see changing for this.
> > 
> > The name:
> >  * GtkAlert is fewer letters and words so it requires less typing and the egtk
> >     minor mode for emacs will work correctly without modification.
> >  * The name is more suggestive of proper use. The essential difference between
> >    a dialog and an alert is that the user never requests an alert; an alert
> >    is an intrusion into the user's workflow.
> > 
> > The construction:
> >  * Alerts may have a Cancel button, an equivalent of OK, and possibly an
> >    alternative action button.
> >    - Error notices and informative alerts would have just an OK button.

If there's only one button, better to call it "Close", since the user
is not agreeing to anything (and does not have the option to
disagree). There may be other, better names in some situations.

> >    - Authenication alerts would have GtkEntry's to meet authentication
> >       requirements and Cancel and OK buttons.

Best to avoid "OK". "Log In" or something may be a better choice,
depending on the situation.

> >    - Confirmation alerts would have Cancel (as such) and an OK-equivalent
> >       button labeled to indicate what is okayed. When appropriate they would
> >       also have an alternative action button.

"Cancel" is often ambiguous; we should not enforce it.

> >  * The arrangement of widgets would be slightly different from that of
> >    GtkDialog. This is shown here indicating boxes (which would not be visible,
> >    of course) and placement of all elements even though entries and an
> >    alternative button would not appear together.
> > 
> >    +--------+------------------------------------------+
> >    | <icon> | <alert text>                             |
> >    |        |                                          |
> >    |        |          <auth1> [____________]          | 
> >    |        |          <auth2> [____________]          |
> >    |        |                                          |
> >    |        +------------------------------------------+
> >    |        | <alternative button>     <cancel> <<ok>> |
> >    +--------+------------------------------------------+
> >  
> >    The alternative button would be placed in the secondary area of the
> >     GtkButtonBox; an alert would not have a Help button and the alternative
> >     would be useful for alerts like the "Save before closing"-alert.
> > 
> >     |  A "Save before closing" alert would have:
> >     |
> >     |    <icon>               = the warning icon
> >     |    <alternative button> = _Don't Save
> >     |    <cancel>             = Cancel
> >     |    <<ok>>               = Save

Here I would name the cancel button "Don't Quit" for
clarity. Otherwise I wouldn't be sure how "Cancel" is different from
"Don't Save".

> > 
> >    Running the space of the icon to the bottom of the window makes the alert
> >     more clear and more distinct from dialogs. Without this change, the
> >     alternative button would appear in the same place as Help does in dialogs
> >     unless it were kept in the primary area of the GtkButtonBox - doing that
> >     would place a potentially destructive action too near the safe actions in
> >     an alert like "Save before closing".
> > 
> > The third change would be to the api as necessary to afford this. I've not
> >  yet drafted any code for it, but Seth Nickell claims to have done so.
> > 
> > Breakage:
> >  * The GtkMessageDialog first appeared in gtk+ 1.3 so no part of the 1.2 api
> >     will be broken by this change that isn't already broken.
> >  * If the change does not appear before 2.0 it will lead to soon deprecating
> >     the new GtkMessageDialog api and having two active and overlapping api's.
> >     This could result in inconsistency of the user interface.
>  
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability