GNOME Bugzilla – Bug 302076
3.0 would be a good time to get rid of "Close" buttons
Last modified: 2020-12-04 18:20:51 UTC
Distribution/Version: Ubuntu 5.04 When the HIG 1.0 was being written, it was quite common to use a window manager other than Sawfish, and some of those window managers were pretty wild. A few didn't even have close buttons in their title bars ... The world is a calmer place now. Gnome doesn't have a GUI for choosing a window manager other than Metacity, for the good reason that such a choice is irrelevant to most humans. People can still use other window managers if they like, but if they do, they're on their own. And the sort of people who go to the trouble of using window managers like Ion without close buttons are the sort of people who can learn how to use Ctrl+W, Alt+F4, or their WM's equivalent shortcut. They can. Really. Which brings us to our problem: Instant-apply windows in Gnome have two close buttons. One is labelled "X", the other labelled "Close". This has several disadvantages. * Multiple similarly accessible methods of doing the same thing slow people down, because they wonder which one to use, or whether there's a functional difference between them. * The "Close" button wastes a lot of space -- it's often on a row all to itself, and when it's not, its usual neighbor is an overwrought Help button that could go elsewhere (e.g. at the top right). * Because an instant-apply window isn't a dialog, it's inappropriate for it to disppear with Enter or Escape (see also bug 302057), so it consumes an access key that then can't be used by any other control in any tab in any pane of the window. * The presence of a "Close" button along the bottom of non-modal instant-apply windows robs Gnome of what would otherwise be a helpful visual cue, that being, "a row of labelled pushbuttons along the bottom of a window means that the window is modal". For Gnome 3.0, I suggest getting rid of the "Close" buttons -- making the interface simpler, removing ambiguity, saving space, allowing for better accessibility, and making window modality more obvious.
FWIW, it was primarily our blind users who demanded a close button in dialogs in the first place. If anything's changed from their perspective (our screenreader is certainly better now than it was then), I'd be happy to support your proposal.
There's also the issue of the size of the close target: in most themes the close button is too small for people with even minor physical disabilities, or visual difficulties. The 'close' button helps by providing a larger, more obvious target as well as by assisting blind users. However blind users can easily learn the window manager keyboard shortcut (Alt F4) for this, so in some ways the physical disability and low-vision arguments are the stronger ones.
I see that's one of the features of the gnome-accessibility-themes -- enlarging the title-bar close buttons. That seems like the right way to do it: let themes enlarge the title-bar buttons for people who need that, instead of slowing everyone else down by having multiple close buttons. (As a comparison, Mac OS X makes much of its accessibility features, without having multiple close buttons *or* letting you enlarge the title-bar buttons.)
Also doesn't ESC function in most dialogs to close them as well as Alt-F4? I don't think a close button is needed for accessibility. I think users with disabilities will have the same transition/expectation issues as users w/out disabilities - they will wonder where it went and why, and will have that learning curve to get over. It perhaps hits blind users harder because it adds to an already otherwise steep learning curve. But this doesn't seem like a sufficient reason to block this change if the UI gods have come to the conclusion that it is an improvement.
'ESC' is bound to Cancel, where available. It does NOT close dialogs without a Cancel button. It has been argued that it must NOT be bound to the 'CLOSE' button (if present at all), because that inconsistency would create problems since the user would not know reliably what the action of 'Esc' would be (does it revert and close, i.e. 'cancel', or just close i.e. 'ok' ?)
I wonder whether this really offers many advantages. You won't save space, since the "Help" button remains in the dialog.
As I said, the "Help" button in Gnome dialogs is overwrought, so its presence isn't really a good excuse for the space taken up by "Close". By comparison, in both Windows and Mac OS, Help buttons in dialogs are often much smaller. (And anyway, the most effective help for dialogs is short explanations under individual controls, not slow separate help windows.)
Don't entirely disagree... would also say, though, that short explanations under controls are great if you have one or two people writing all of them, but as soon as you let developers write their own (as you inevitably have to in this sort of environment), you end up with smatterings of bad English, differing ideas between apps about when text should be given and when it shouldn't, and inconsistencies in the style and terminology of the text itself, which makes lots of extra work for translators (particularly the ones using semi-automatic translation). At least if it's all in Help files, there's not so much in-yer-face yuckiness, and it's all somewhat under the control of the GDP... I doubt they'd enjoy having to review the content of dozens of dialogs on top of their own documentation :/
I really think this would be a step in the right direction. It would make preference dialogs appear less cluttered, cleaner, and more to the point. I've always thought the double close aspect of the preference dialog to be redundant. I'm glad to see others agree.
FWIW, I just started a thread about the Close button issue on gnome-accessibility-list, to try and shed some light on the consensus of assistive technology users these days. http://mail.gnome.org/archives/gnome-accessibility-list/2009-July/msg00014.html
Totally agree with the bug report. The new HIG recommends a single close button for instant apply dialogs.
*** Bug 479541 has been marked as a duplicate of this bug. ***