GNOME.org
 

Re: Appearance Capplet Ideas

I have made some small updates to my mockups, but I haven't changed anything major yet. Hopefully answering Jens' very useful questions will explain why. 

On 04/04/07 17:06, Jens Granseuer wrote:

On 04.04.2007 00:44, Thomas Wood wrote:
Various people have suggested an all-in-one appearance capplet might be a good idea to try and reduce our proliferation of these settings over many different windows. Unfortunately, no one has so far come up with any good mockups (other than "let's cram all the current capplets into tabs"). So, I put together a glade file organising our existing options into the following categories: 

I like that. Still got a couple of points in addition to what Rodrigo
and Denis already mentioned, though:

* "Themes": when I looked at this tab for the first time I desperately
  went looking for the button that let me customize stuff. That it's over
  in the "Appearance" tab is rather non-obvious. At the very least
  "appearence" should be capitalized in the hint (but "Appearance isn't
  a good name anyway, as the others have pointed out).
I think this is actually a symptom of knowing the old theme capplet too well. Once you realise what was going on, was it still so confusing?
I would like people to start thinking of themes as "profiles" of all the appearance, desktop and font settings, rather than just the "GTK+, Metacity, Icon" triplet. 



* "Appearance": what would this look like for themes which don't support
  custom colours? Might get a bit crowded, especially if cursors move
  there as well.
I've put the cursors combo box into the mockups, and shown the "colours not supported" message. I don't think it's too cramped yet. 



* "Desktop": should not have "Desktop" in the category titles; should
  probably also change "Desktop Colors" to "Background" or so


Agreed, and updated in the new mockups.



* we seem to be a little inconsistent regarding images in buttons
Interesting one, especially as this is also a GTK+ style option. Stock buttons always use icons, but other buttons don't have to. I can see two possible policies here. We either insist on icons in all buttons, or we decide only stock buttons should have icons. Either way, the user should be able to disable all icons in buttons by using the GTK+ option. 



* somebody couldn't decide between BE and AE spelling... ;-)


Sorry, my fault. It will of corse all be en_US in the final glade file.



* your mockups drop the "Close" button, which means windows will have
  to be closed using the window decoration; iirc there was an
  argument some time ago that this isn't ideal for
  usability/discoverability reasons (Calum?). It does save us some
  space, though...
I'm glad someone noticed this, as it was deliberate. There was a long discussion about this some time ago[1]. With our current debate between "Finish" and "Close" buttons, I thought it might be good to look back at why there is a Close button in the first place.
Personally, I believe the problem of the Close button is more to do with users' previous experience in which they will often equate "Close" with "Cancel". Therefore, the presence of a Close button will cause people to start thinking that the dialog uses the explicit apply model in some way. Removing all the buttons all together enforces the perception that the dialog is instant apply, in much the same way as "utility windows" do.
However, there is a problem here in that we currently do not require the window manager to provide a Close button in the title bar. We could change this policy, and require "GNOME compliant" window managers.
I also realise that the space made available by the current requirement to include the Close button also makes room for a Help button. I am not advocating the removal of the Help button, but I would like to see if we can't find another more adequate solution first. I am fully aware the Close/Finish/Done button will probably have to return, but let's experiment for a little while.
A few of the screens could do with cleaning up and simplifying (Fonts for example). What are people's opinions on "Advanced" buttons so that we can keep the main tabs clean and simple? 

I seriously detest "Advanced..." buttons. You can never tell what
lies beyond (and in most cases it doesn't have much to do with advanced)
so you'll have to take a look anyway. If we managed to come up with
reasonably telling labels, though, that wouldn't be much
of a problem (to me).
I mostly agree here. The use of "Advanced..." buttons leads to excessive windows (such as those present in the Windows appearance settings). Let's make sure the settings are really important to include at all before just relegating them to an extra window.
The other things that are missing from the current layout are cursor settings (themes), and also any link to sound themes for the Themes tab. Perhaps cursor themes should be added to the Appearance category, underneath icons. 

One problem I can see with that is that we'll lose the preview.
It could maybe be put behind a "Preview" button in a separate window,
but in that case I'm not sure a combobox would work well here.
I'm going to suggest icon sized previews in the combobox. As you can see I've filled it with a stock icon at the moment, but at least it gives some idea overall impression.
I'm not sure how any link to sounds for the Themes page should work. 

IMO sound doesn't belong in the appearance capplet.
Absolutely, and here in lies the problem of equating Themes with appearance settings. Themes are just a collection of settings and files that relate to a particular way the user interface presents itself to the senses. This includes audio, visual, and who knows what in the future. Mobile phones already have tactile options (e.g. vibrate) as part of their themes. 

Regards,

Thomas

[1] http://mail.gnome.org/archives/usability/2002-January/msg00075.html
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]