Richard wrote what's in CVS from scratch and failed to use the newest
version of the interface or to capture a number of
"un-screenshot-able" interactions.

For reference, this is what the capplet should look like:

http://beauty.stanford.edu/bgcapplet.png

I've already fixed a few things in the new capplet, but I haven't
found the time to fix everything.

- should the "Picture" label have a mnemonic for the main
picture-chooser button?

Yes, though the revised interface uses a button there. If we don't use
a button, the "Picture" label should have a keyboard shortcut.

- should the "border the picture with" label have a mnemonic for the 
  option menu?

Yes. Another thing that didn't get carried into the new capplet.

There should be no padding between the labels and the content they
refer to. Putting more space between reduces the strength of the
grouping (gestalt design principles). If you're still seeing frames,
you need to update again, there should be no visible frame borders.

   - why would you drag an image file here instead of just onto 
     the desktop itself for Nautilus to set as the image

I prefer the interaction of dragging into Nautilus desktop too. I just
haven't thought up a great way to do this (either technically or
interface-wise). The problem is that Nautilus already has a meaning
for "drag image file" in normal folders. We could potentially pop up a
dialogue if its an image file, but I think that's intrusive. Another
option might be to merge in a "Set as desktop background" entry to the
right drag menu when the file being dragged is an image.

   - sort of a classic "feature is unusable so put docs in the 
     dialog" cop-out

No, subtle but important difference. Feature is *invisible*
(contrasted with unusable, since the interface provides an alternate
mechanism for accessing this functionality) because GNOME fails to
provide this interaction such a high percentage of the time (i.e. DND
does not work in most places). There's really no good way to express
"hey kids, you can DND here" except to outright say it. In the future
when GNOME supports this interaction more pervasively, I would
definitely agree with dropping this label.

Think of this as "the label for a control that is inherently invisible".

   - I did a cheesy user test and the user couldn't figure out 
     what "image files" was supposed to referred to. Tried dragging
     the Home icon on the desktop.

This is a hard problem. If you can suggest a better word than "image
files" I'm open to it. Ideally, if the user dragged a .desktop file
into the capplet, we would extract the picture used there and set that
as the background picture.

   - the dialog would probably look better if the Picture icon 
     were centered and these odd docs weren't there

Actually, I don't think we should center it even if the DND label
weren't there. The rest of the dialogue is left aligned and moving it
that far right makes the dialogue look more cluttered and less easy to
scan. I might try moving the "border picture" controls into that spot
though.

- instead of "border the picture" wouldn't "behind the picture"
  be more accurate?

It would be more accurate. My capplet changed this label when you
selected different picture options. I hadn't added one for cases where
the picture filled the whole screen (wallpaper, stretched), but it did
use different wording for "No Picture" and could have changed for
wallpaper and stretched too. Of course, this is yet another
interaction that didn't make it into the rewrite (which was basically
a "lets use peditors everywhere we can at the expense of the
interface" job).

- the "T" mnemonic is used twice

Where?

Updating all cc bugs that have the GNOME2 keyword set to the GNOME2.0 milestone,
to help jrb triage/prioritize cc bugs. Filter on 'luis doing GNOME2 work' to
ignore this spam.

I have to agree with Havoc here, and would like to expand the list of
UI troubles he found. 

First to address something you wrote in your reply to Havoc: 

"There should be no padding between the labels and the content they
refer to. Putting more space between reduces the strength of the
grouping (gestalt design principles)" 

This is just not true. Too much padding between labels and their
controls might limit the association betweem them-- but no space
detracts from their readbility. Our HIG has something to say
about this, recommending, I believe, 3 pixels between labels and
controls. 

To help explain this point, it may be useful for you to imagine the
widgets in your design as being words in a sentence. It is hard to
read the words whenthereisnospacebetweenthem. Keeping a small,
standardized space between labels and controls improves their readiblity.

See the links below from the MacOS8 HIG and the Aqua HIG for some
information about how Apple approaches this problem.

http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-52.html
http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGControls/Radio_Butto__Checkboxes.html

(OT: I was playing with OSX's Interface Builder this weekend, and
found that they enforce standardized spacing/padding by creating
guides around a widget as you drag it into your project; these guides
represent the aqua spacing and padding standards, and you can't add
widgets without complying to them. In fact, when you add a widget to a
project in the interface builder, it just snaps into place according
to the aqua specs. Drool.We need this.)


Okay, now for my own comments on this dialog. 

The number one thing that bothers me about this design is that you use
seeminly identical widgets in different and inconsistent ways. 

Upon starting the capplet, you are presented with a dialog filled with
what appear to be buttons. These buttons server a myriad of purposes:
some function as file selectors, some as radiobuttons and as preview
panes-- only one actually works like a button (Close). 

We already have perfectly functional, standard widgets to accomplish
these tasks, and roughly all other gnome apps use them. This allows
gnome users to transfer their knowledge of how widgets work from one
app to another, effectively lowering the gnome-fluency barrier.

What, then, does the heavy, non-standard use of buttons in this
dialog accomplish, besides making it inconsistent with other apps,
and even inconsistent within itself? 

My recommendation to you is to remove your togglebuttons, and replace
them with an option menu (whose menuitems have both labels and icons),
and to replace your "Select Picture" button with a combo box. Also, I
think that the "No Picture" toggle would be happier as a "Use a
background picture" checkbox, whose value toggles the sensitivity of
the picture related options.

Next:
This dialog has no concept of history, and is hence not very
forgiving. Using the "Picture" button instead of a standard file
selector means that there is no easy way to change to a previous
background picture. 
    
So, if you select a picture that you decide you don't like, the only
way to revert your change is to remember where your original picture
lives. This discourages people from playing around with what should
be one of the most fun and rewarding capplets. Hmm.

As mentioned above, replacing this button with a combobox will fix
this problem.

Next: 
This dialog uses inconsistent labelling conventions, and makes some
potentially confusing assumptions.
        
The dialog seems to assume that the user wants to use a background
picture, because it uses phrases like "Picture Options:" and "Border
the picture with a:" . The dialog has no reason to assume this-- and
when taken out of context, these labels are confusing. If you are
using a screenreader or similar assistive technologies, this is a
real problem. 
    
Also, some labels have colons after them, some don't. Some adhere to
HIG capitalization guidelines, and some don't. Inconsistencies like
this are so painfully easy to fix that allowing them to be made is
just embarassing.

So I think you should: put colons after the "left color", etc, labels;
find a better label than "Border the picture with a" and capitalize it
properly..perhaps "Pattern:"? 

Next: 

Look at this: http://primates.ximian.com/~anna/background-capplet.png
It isn't clear at all from the little wallpaper/centered/scaled
previews what the difference between them will be. These previews are
more confusing than useful, at least with my background picture. 

If you want really want to use a picture to show what each of  the
Picture Options means, how about using a little preview icon 
(where the options actually look different) for each option?

So that is about all. I have made a glade2 file for you which includes
all the changes I have proposed. You may download the tarball from
here: http://primates.ximian.com/~anna/background.tar.Z 

NOTE: There is a gtk+ bug preventing these option menu from displaying
 correctly. If you play with the glade file, you will see that each
option menuitem has an icon and a label associated with it; the point
of the icons is to give a clear preview of what each of the options
would look like.

I am also putting a screenshot (which suffers from the same bug of
course) here: http://primates.ximian.com/~anna/background_proposal.png 

So. What do you think?

Aside: I think the GTK bug with the option menus is really hard to fix
(enough so that I think we've WONTFIX'd it in the past), so we may 
not want to rely on that getting fixed.

SPAM as discussed last night. Search for 'SPAM as discussed last night' to catch
these all and delete them. :) 

Sorry for the spam, folks

Removing keynav keyword as there are no outstanding keynav issues with
the dialog, as far as I can see.

None of these apply to the new capplet. Marking as fixed.