I keep babbling about how ugly I think Appearance Preferences is, so I played with GIMP just now and made a couple of mockups.
I’m hoping to stay grounded in reality here.
First: the problem!
This here is the status quo in Gnome. The problem is not limited to Appearance Preferences, but it’s easy to demonstrate with it. I’m just going to focus on the Background section, too, but what I’m doing can be applied to the others. Let’s say I right clicked on my desktop and innocently selected “Change Desktop Background.”
The thing that immediately deserves a significant chunk of ire is that empty white patch to the right of the icon view. Were the window a few pixels wider, it wouldn’t be there. As it is, this gives us a 3×3 grid of tiny icons, with more space between the icons than the icons themselves, from which we need to choose a background picture. And that breaks one of my rules: Never, ever expect your user to resize a window.
We aren’t going to make the window wider, but we are going to fix that problem.
The next issue is visible by scanning across the window. I go through three heavy lines: the window border, the tab bar, and the frame around the icon view, before I get to the meat of this thing. That is three layers; three sections of the interface.
If this was a printed document, the icon view would be a subsection.
But what is this interface’s main objective? Choosing your background picture! Doesn’t that seem a little bit crazy?
My first mockup is getting rid of that excess border between the tab bar and the icon view…
This highlights a particular habit Gnome apps have, especially when they follow today’s HIG. (And, as you might have guessed, I disagree with this habit). They add padding, padding, padding. They are obsessed with padding. Every container has 12 pixels of padding on every side.
Of course, I like padding, too. I want things to use padding. If everyone used padding and margins, maybe themes wouldn’t be using so many lines! (The other thing that makes me crazy, but it turns out these go together in our case. Note that one strangely thick border is now gone. I did cheat a bit by making it a 1px border instead of a 3px border, but as far as I can tell that’s a theme thing).
Unfortunately, padding is being used robotically to fill an arbitrary requirement. Everything uses the exact same amount of padding around every element regardless of what that element means. The result is a tangle. (See above).
I propose a slightly more organic approach: “Padding should be in multiples of x, never less than y pixels and never more than z pixels. In general, no control should reach within w pixels of a window’s edge or a heavy border.”
There is another problem here: if a container creates a heavy border, it is redundant to give the next container inside it a heavy border as well. Besides, having a sudden contrast between two halves of a double border defeats the purpose; it adds noise right in the middle of the attempt to create a clean surface. That can happen if one follows a mathematical guide to padding.
At this point the mockup is attainable with GTK as it is right now. However, I think I only applied my solution half-way. The icon view still has its own spacing around each icon. (Conveniently enough, it is precisely the same as the padding within a toplevel container: 12px). Here’s my attempt with that:
This one would need a few small changes in GTK, in themes and in philosophy.
The first thing is this interface stacks vertically, and only vertically. Trying to differentiate empty space from another element’s empty space going horizontally was a fruitless exercise, so this stops trying to do that.
If you draw a line down the left side, you will notice that the edge of the left-most icon in the icon view, the Style label and the Help button are all aligned. However, instead of a single Alignment, I’m adjusting each element on an individual basis to align based on its content.
As well, the buttons part of the Notebook widget would need a settable left margin. Quite attainable, really! There’s precedent in any web browser where the content spans to the edge of the screen. (MacOS’s design is interesting, too. Over there, a tab bar at the top of a window is styled a bit differently than one somewhere else).
I’m cheating a little by assuming that the theme will use a different background colour inside a frame or a notebook container. That is the case with Clearlooks or Elementary, for example. By varying the background colour, we can strongly communicate that the tabs at the top affect a particular thing without wasting 45,156px² of screen space on layers of margins and borders.