Re: [platform-swt-dev] SWT & Native widgets

[Seth Nickell <snickell@xxxxxxxxxxxx>]

On Fri, 2002-08-09 at 02:28, Martin Möbius wrote:
> > By way of graphic example, compare just one tiny dialogue as generated
> > by Eclipse of today with a properly styled and worded version for
> > GTK/GNOME:
> > 
> > http://www.stanford.edu/~snickell/eclipse-dialogue.png
> > http://www.stanford.edu/~snickell/native-dialogue.png
> 
> Just want to add that this example is very special. During development of

This could have been done with a more standard confirmation alert, or
pretty much any dialogue in Eclipse with similar results. The things to
note are not just the lack of radio buttons (which are explicitly
decried in the HIG, btw), but the button order, the lack of "Yes/No/OK"
buttons, the dialogue alignment and spacing, the lack of a title in the
dialogue window, and the use of a short 4-8 word primary title text
followed by a longer explanation. These are all important aspects of the
GTK/GNOME style which Eclipse is not replicating. There are literally
hundreds and hundreds of examples like this, not just alerts.

> release 2.0 there were a problem with exactly this dialog (usecase). If you
> perform an action 'delete' we all know that there will pop up a dialog asking
> 'Are your sure?'. But the dialog presents another topic, 'Do you want to
> delete, the resources as well? To get the attention of the user it was decided to
> use the checkboxes, as it look unexpected.

Confirmation alerts are generally useful for only two things:

1) Preventing users from executing hazardous items accidentally (mouse
slipped and mis-clicked, hit a shortcut for the item accidentally, etc)
2) Informing unfamiliar users that an item may not do what they expect
(of course, its better to renname or re-present the item so this is not
necessary, but occasionally this is the best choice).

Unfortunately none of these uses apply to making this alert
non-standard.

1) Making it non-standard is effectively saying "We are intentionally
making this bothersome for the user to make them think", which can be ok
in some cases, but...
2) Responses to alerts become so automated with time that it doesn't
matter how much you bother the user, if they intentionally start an
operation they will probably complete it.[1]
3) First time and unfamiliar users almost always read alerts before
responding to them.

Effectively this seems like a technique to prevent automated response,
but unfortunately automated response is too strong. People even automate
incredibly complex operations like "driving to work" to the extent that
if some people (myself included) don't pay attention to what they're
doing, they'll end up at work rather than the shopping mall. The net
effect of this interface is likely to be merely inconveniencing the
user, with little or no prevention of accidental data loss.

-Seth

[1] - the solution to this, btw, is not to make confirmation alerts
require more work to respond to, but to make operations more "undoable".
So e.g. Eclipse could place deleted projects in the Trash rather than
actaully deleting them from the filesystem. This would be the
appropriate behavior on both GNOME and MacOS, and perhaps Windows too
(though I don't know how much they push their trash feature).