Thank you for approaching a problem that I've had with GNOME. I think Benson makes some good points. Making sure the mental models that a user will create as a result of modifying appearance will be clear rather than overlapping is very important. This is actually one problem that I've seen using KDE in a number of areas. A user is better off if there's a clear foundation of functionality.
On Monday 16 April 2007 09:57:31 am Thomas Wood wrote: > I'm currently looking at integrating the various appearance settings > throughout GNOME into a single "Appearance Settings" application for the > control center. > > I have made some mockups, which can be seen here: > http://live.gnome.org/ControlCenter/AppearanceSettings > > We've discussed these on the control center mailing list[1] and I would > like to discuss some of the issues raised here as well. > > > Themes Tab > > The themes tab provides a way of saving and apply a particular group of > appearance settings. This means it will change the settings on other > tabs, and this is contrary to advice in the HIG. However, 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. > > > Close Button > > As you can see, there is no separate close button on this window other > than in the title bar. I know this has been discussed before, but would > it be impossible to require "GNOME Compliant" window managers to include > a close button. My main reason for removing it is because of the Novel > usability studies that showed[2] several people did not understand that > the window was instant apply. I think the presence of a dialog-style > button bar suggests that the window is asking the user for some action, > when in fact this is not the case. > > > Dialog Window > > 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[3] 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. > > > 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[4], It would > be useful to get some input into the usability/accessibility > implications of such a feature. > > > Preference Windows > > 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. > > > Of course, any other comments and suggestions are welcome as well. > > Regards, > > Thomas > > > [1] http://mail.gnome.org/archives/gnomecc-list/2007-April/msg00000.html > [2] http://www.betterdesktop.org/wiki/index.php?title=Data > [3] http://bugzilla.gnome.org/show_bug.cgi?id=331835 > [4] http://mail.gnome.org/archives/gnomecc-list/2007-April/msg00011.html > _______________________________________________ > Usability mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/usability _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
