Re: [Usability] Control Center Appearance Capplet
- From: Thomas Wood <thos gnome org>
- To: Calum Benson <Calum Benson Sun COM>
- Cc: GNOME Usability List <usability gnome org>
- Subject: Re: [Usability] Control Center Appearance Capplet
- Date: Tue, 17 Apr 2007 16:23:49 +0100
On 04/16/2007 04:31 PM, Calum Benson wrote:
On Mon, 2007-04-16 at 14:57 +0100, Thomas Wood wrote:
I am not sure
if the advice in the HIG applies to this, as it is (or should be) fairly
obvious that changing to a different theme will affect options not shown
on the current tab.
I wouldn't say that's necessarily true, especially as not all the other
tabs (e.g. Options) do comprise the Theme, just some of them. In fact,
at least one of the tabs (Fonts) mixes some things that are part of the
theme (the fonts themselves), and some that aren't (the anti-aliasing
options). I can't help feeling some cleaner separation would be
Either that, or including the remaining options in the theme. For those
on the "Options" tab it might make sense as some themes might want to
specify if icons are shown in buttons for example. However, it obviously
doesn't make much sense to add font hinting settings to the theme. How
could we separate these in an obvious way though?
Related to the above, I have also not set this window to be a dialog
window. The window is not asking for any confirmation or action from the
user, so I think it ought to be a "normal" window. We also had several
bug reports requesting that the previous theme capplet have maximise
buttons because in contained a scrollable window. Metacity (quite
reasonably) does not allow maximise buttons on dialogs, so it had to be
changed to a normal window.
I don't think it's too hard to argue that metacity's "no maximise on
dialogs" theory is somewhat flawed. Any window that benefits from
resizing should be maximisable IMHO, although some windows may require
constraints other than "the full size of the screen". E.g. in this
particular case, you probably just want to maximise the window
vertically (something for which we even have a keyboard shortcut,
ironically), but not change the width at all. OSX has the upper hand on
us here with its zoom button, I guess.
I'm not sure. After all, what's the difference between a Dialog window
and a Normal window? Presumably Dialog windows are asking for some kind
of user input or action, hence their name. Any other window should be a
Normal window. I don't see that Preference windows are really creating
any sort of dialogue with the user.
Undo and Redo
There has been some suggestion on the control center list that we might
like to include Undo/Redo or Revert buttons in the capplets, It would
be useful to get some input into the usability/accessibility
implications of such a feature.
Well, I'll kick off that debate by restating why I tend to prefer
Revert :) Partly because it's essentially the equivalent of Cancel for
instant-apply windows, so its behaviour is simple and somewhat
consistent with explicit-apply windows. IMHO the classic, linear Undo
concept doesn't seem particularly-well suited to such windows, where a
change in one setting isn't necessarily related to the setting you
changed prior to that, so having to undo the most recent change first
can often be counter-productive.
Personally, I agree with you here. I don't think the use case is big
enough to justify a full Undo/Redo system, but a "Revert to settings
when I opened this window" and/or perhaps a "Revert to system defaults"
may be useful.
It would be useful to clarify the above points with regards to
"Preference Windows" in the HIG. The HIG specifies that preference
windows should be instant apply, but does not specify a particular
layout to deal with this idiom. Looking at any other operating systems
where instant apply is often used (primarily Mac OS X), it seems that
most preference windows do not have any Close button other than that
provided by the title bar.
Well, the main reason the HIG specifies an explicit Close button is
accessibility-- at the time, the a11y team asked a number of blind users
whether or not they felt it was necessary, and they felt that it was.
(I don't have any more details than that to hand, I'm afraid.)
As you say, that doesn't jive with the OSX model... although I think our
a11y folks still consider OSX to be playing catch-up with both Windows
and GNOME in terms of accessibility, and I don't know if this is one of
the issues they have with it.
I'm not quite sure about this, as Metacity allows you to use key
combinations to close the current window anyway. Perhaps someone can
comment on whether this is still relevant.
] [Thread Prev