Re: [PATCH] GtkMessageBox should set empty window title by default

["Kalle Vahlman" <kalle vahlman gmail com>]

On 2/21/06, Tim Janik <timj imendio com> wrote:
> On Tue, 21 Feb 2006, Kalle Vahlman wrote:
>
> > On 2/21/06, Martyn Russell <martyn imendio com> wrote:
>
> >> I completely agree with Tim here. What if you have 10 dialogs all pop up
> >> with no title and one of them happens to be an important one from
> >> another application?
> >
> > If you have 10 dialogs popping all over the place, there's more wrong
> > in the world than just suggesting empty titles ;)
>
> depends on your application. e.g. mozilla implements modality per browser
> window and each such browser window can have multiple tabs. an alert could
> be popped up e.g. per tab (say for security relevant information) so you
> quite possibly get a bunch of similar alert windows.

So far I've seen this particular case work in a way that one modal
dialog blocks the entire web browser (even different windows) from
functioning, so can't really assess how often that would be the case
(though it's not mozilla I use so a moot point I guess)... ;)

So either you are saying that (in this particular case) security
messages are not critical enough to block the application window (at
which point they become dialogs or other notifications) or they should
and thus I see no point in cycling them (as they will be transient and
kept above their parent and not in window list).

Furthermore, security alert probably won't have the title as
"Question" but as something more descriptive and unique, right?

Besides the point but mozilla is not really a HIG-abiding sw anyway,
so perhaps another example would be better?

> >> It makes it harder to know when cycling through
> >> them as Tim says.
> >
> > You shouldn't have to cycle through them, that's my point. Either you
> > cycle the parent windows (where the popup will be on top) or it will
> > be the only window and then IMO it could have an title (as I stated).
>
> whether cycling goes through window groups or individual windows and
> whether windows are placable always-on-top and cenetered-on-parent or
> not is completely up to the window manager and the specific behaviour
> it implements. you can't assume either.
>
> i outlined that earlier, in particular you can't assume that having no
> title does make sense at all with your eindow manager theme, or your
> accessibility toolkit.
>
> you can of course implement title-less alerts in a window manager (-theme),
> but then you don't need toolkit support for the title-removal, you simply
> don't show the title bar for windows flagged as alerts.

Is that the same thing as not having a title?
(I never said anything about themes or whatnot, just the (default) title string)

> but accesibility kits or other window managers (-themes) may need a normal
> or emphasized title bar, so unsetting it in the toolkit would actively
> interfere with proper window manager operation.

Perhaps someone with more a11y experience can comment on whether the
title text is important, I don't know.

> >>> They should be application modal, and kept above their parent so as
> >>> not to be lost. They should _not_ be visible in window lists and I
> >>> don't really see why should they ever be shaded either...
> >>
> >> I disagree, I think modal dialogs have very limited use. Modal dialogs
> >> should ONLY be used when the whole app is waiting for input IMO. That is
> >> rarely the case.
> >
> > That should be _always_ the case with alerts. If it's not that urgent
> > and devastating, don't use an alert, notify the user somewhere else.
>
> i really wonder what kind of use case you have in mind for your alerts
> then. i'm using graphical user interfaces for some 20 years now, and
> i have not come across a dialog yet that seems to meet all of your
> requirements. maybe with the exception of a "Core melt down, leave
> the building!" alert in a power plant movie.
> but then i think that specific case doesn't need generic toolkit support.



> >> You only have to use Microsoft Outlook to understand
> >> why modal dialogs are a bad idea. It means you can't visit information
> >> from other windows/dialogs in the application that might be important in
> >> responding to the modal dialog.
> >
> > That's bad application design, not fault in modal dialogs.
> >
> >> If you want them to remain on top of their parents, you should make the
> >> window a transient.
> >
> > Yes, alerts should be transient to their parent _and_ modal.
> >
> >> I think the HIG should be amended here, I think having no title is just
> >> uninformative and just not aesthetic IMO.
> >
> > The point is not to repeat the message of the dialog, which will
> > contain more details than the title.
>
> if that was a valid point, it'd apply to general notification or
> application toolbox windows as well, i.e. any window that has a title.

Yes for toolboxes:

"Utility windows, such as palettes and toolboxes, normally have
borders. They do not contain a menu bar, a toolbar, or a statusbar."

Normal dialogs have the command name as title (open, save, frobnicate,
etc) which can't really be described as repeating the message.

> in your other email/HIG, you call the alert window title "noise". i don't
> think that is proper attribution though. it simply is a biased unbacked
> claim, maybe your perception, but nevertheless not a valid technical
> or usability argument.

So this would be not be unnecessary in your opinion:
(ASCII art pretending to be a top-left corner of a dialog)

---
I Some information
I--
I Some information that
I  the user can't live without
...

Now let me counter-extrapolate your argument: If the above is cool,
then this should be too:
(ASCII art pretending to be the button for above dialog)

The OK button:
     [ OK ]

So even if the content is twice there, it's not noise if it has some
function, let's say for a11y reasons for example.

> (if it was, we could simply end this argument by
> me claiming the relevant HIG section to be "noise" ;)

I'm happy with that if you are ;)

--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi