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.
Love it! Looks much cleaner and less cluttered. I'm curious how using those principles would play out with other screens, especailly ones that have tabs within tabs… can't think of any off the top of my head though. However, for config dialogs like Appearance Preferences, it looks really good!
Great improvement!
My personal opinion on multiple layered tabs is that the design needs to be changed if they are considered for use in an interface (or at least change the tab orientation).
I like it.
+1, Huge improvement!
It looks deformed and out of place in your mockup, sorry, I don't like it.
I like that you are using only one line to separate each widget, but your design introduces a new problem: Does the tab bar affect the icon view , the icon view + controls, or the icon view + controls + dialog buttons?
@JayBee: I can't decide if I like the second one much either :)
I'm curious what you found ugly, though!
@Hylke: Yeah, the second one especially has that issue. I was hoping the shading would communicate enough, but the tabs at the top don't set the stage for it. Logically, I should have coloured their background the same as the dialog buttons and offset them a little; made them more visually like top-level things that control the entire focus.
Sticking with the current widget designs turned out to be a problem there.
Of course, indentation is the most readily available tool for saying “this goes under this”, but I don't think the main focus of a window should have three layers of indentation. There must be another way.
Websites, for example, use separate headers with top-level navigation.
I think it would help this cause if GTK provided some more presentation controls to developers. For example, with simple function calls, adjusting the background colour according to a few presets (maybe just "dark", "darker" and "light"?) and each of the four borders.
Padding can already be controlled on each side with an alignment, but with themes still drawing left and right borders anyway, the two mockups wouldn't look right if the padding was anything but symmetrical.
For example, here's the first mockup quickly implemented by editing Appearance Preferences's UI file:
http://people.ubuntu.com/~dylanmccall/mockups/appearance-preferences-tidy/AppearancePrefs-Real-implementation.png
Pretty close, but I need a bottom border on that scrolled window — and ONLY a bottom border.
Would you be interested in presenting this at an upcoming Ubuntu Vancouver event? Seems like it would be interesting to a lot of our members :)
"Pretty close, but I need a bottom border on that scrolled window — and ONLY a bottom border." – Why? It looks much better without. And the scroll-bar already communicates what part of that area is scrollable.
Nice work. I initially thought this was going to be another one of those concepts that is nice for one thing, but makes everything else crappy, and I was pleasantly surprised.
One thing which seems to be a step in the wrong direction is how impossibly small the window border on the right is (making it difficult to resize the window). However, I suspect this is more of an issue with the window border style than the style of the stuff inside it. But the advantage of a bit of padding here is that you have two very different actions (clicking in the scroll bar and initiating a horizontal resize) separated by a single pixel.
So from this perspective, I'm 100% sold on the first mockup, and with a bit of convincing, I might come around to the second (would it look crap with uniform padding down the sides?)
I will try to elaborate my comment.
Horizontal padding is important, I hope that you will understand that after reading my comment and looking at this picture:
http://img3.imageshack.us/img3/9109/appearanceprefsproblems.png
Here are some problems with your mockup:
1. These controls on the bottom are not connected to anything. What are they about? Are they part of the same window? They look strange and disconnected from the rest of the interface.
2. Empty space, a lot of empty space. Much more empty space than padding takes. Messy and disorganized. (Not that it was good before)
3. Without padding I can't tell what these controls "Style" and "Colour" do. Are they part of the background or what? I think that Colour chooser should not be shown at all unless a wallpaper uses colour but hey, let's not make it more confusing than necessary.
4. That scrollbar looks out of place.
5. That tab looks like it only contains those pretty little pictures below it.
6. Ugly corner ;-)
@the-new-andy: Thanks :)
Remember that I'm staying as close to the original stuff as possible. That means window borders, too!
Besides, nobody should need to think about resizing that dialog.
@JayBee: Thanks for the analysis!
I agree the second mockup is a bit of an extreme, and tougher to get right than the first.
#1: That's mostly the idea. The Close and Help buttons _are_ detached. We can connect them to the window itself by convention, with the background colour. I should have used that colour at the top as well (behind the tabs). Oops! :)
#2: Oh, yes! It was exactly like that before, though, remember. I didn't touch that bit. (Okay, I may have shifted something horizontally a tad to get the alignment right). It may be nice to stack Colours and Style vertically, raise the Remove and Add buttons, and move "Get more backgrounds online" closer to them.
#4: There's definitely _something_ off there. I guess the icon view added a hard border on the right side and I never removed it, so that does detach it a little from the scroll bar.
#3 / #5 / #6: Yeah, this is _begging_ for a top-level notebook / tab bar widget. The tabs shouldn't be pushing up against the icons, but the present design of GtkNotebook encourages it. (The contents are directly within the notebook container and you can have either no padding or padding on all sides).
I think if I had shaded the top (consistent with the "window background is darker grey" idea) it would work better, too.
One experiment to do: how do you know what is connected in the current padding / lines crazy dialogs? For me, the most certain approach is to follow the line from the tabs to the bottom of the window. However, in doing so I pass a whole lot of other lines and things get quite confusing.
It's like reading a really badly formatted spreadsheet.
Instead, we should be conveying that same information with the background colour instead of with lines, like how lots of the more readable spreadsheets use zebra striping. We should be varying the weight and appearance of any lines that are left so they convey the right meaning naturally.
I can tell that things are connected because they are closed and grouped together and I can easily observe closed shapes (squares). Everything inside a square is connected to it.
You shouldn't visually disconnect two things that are connected because that leads to the problems mentioned, and I don't think the same colour of the top and bottom part would help much.
If you want to hold on to the current design with tabs, then there is no way around 'triple frames' without introducing other issues and inconsistencies.
Window needs to have a border so we can't get rid of that. Tabs need to have a border too, so that we can tell what are they containing and what they are not containing. Icon view is scrollable and requires a border too.
I am more bothered by the empty space and messy buttons. I think most of their functions could be placed inside the icon view (I don't know if it's possible with gtk).
>You shouldn't visually disconnect two things
> that are connected because that leads to the
> problems mentioned, and I don't think the
> same colour of the top and bottom part would
> help much.
For sure! The vertical spacing isn't perfect. Needs more love, care and precision :)
I agree with you about sticking those functions "inside" the icon view. Unfortunately not readily possible, but one could give a container the same background colour as the icon view, so they would blend seamlessly. Would be neat if that was a more conventional operation.
> Window needs to have a border so we can't get
> rid of that. Tabs need to have a border too,
> so that we can tell what are they containing
> and what they are not containing. Icon view
> is scrollable and requires a border too.
The window needs a border, but we can USE that border. Right now, each container blindly adds 12px of padding because it's a container, irrespective of its parent and its siblings.
The area inside a notebook currently needs borders on the left and right sides, yes. But it _should't_ need borders on those sides in the general case. This interface is not that complicated.
We might use padding to separate an element from another element; to pull it away from the noise generated by something else. However, there is no noise to be pulled away from on the left and right sides! In fact, we're CREATING it with all those unnecessary borders. It's overpowering and wastes an incredible amount of space that could be spent presenting actual information.
> If you want to hold on to the current design
> with tabs, then there is no way around 'triple
> frames' without introducing other issues and
> inconsistencies.
There is! Triple frames are, themselves, an issue and an inconsistency.
The issue: They Look Horrible
The inconsistency: Different interfaces look differently horrible, which acts to make them all even more horrible than they were. Sometimes the main control you're going to be using is within 12px of the window edge, sometimes it's within 36px and two black borders.
Every interface has issues. The question is whether it's worth trading those issues with different ones. I, for one, think it's quite possible to change the issues I mentioned for a set that is more in our favour. Of course, (and I should have put this in bold somewhere), it's important to use your imagination a little. My mockup is a skeleton. A rather hastily assembled one at that ;)
Do windows need borders or is it just "that's the way it has always been done" lazy design thinking? Is a frame the only way to illustrate connectivity?
This is 2010.
Think about progressive disclosure as a design concept on this one. Have a peek at Google Chrome/ium's default frequently visited sites page, for example. That sort of outside-the-box thinking has deep ramifications for all interface elements. Think about touch / clickable targets and how animated states might improve accuracy?
And for anyone that believes that you need a wrapper to associate elements together, perhaps start by reading one respected theory of perception – Gestalt (http://graphicdesign.spokanefalls.edu/tutorials/process/gestaltprinciples/gestaltprinc.htm). While not perfect, it certainly is a valuable entry point that elucidates visual literacy concepts.
After doing so, perhaps there might be a less absolutist stance on the accepted methods that GNOME has chosen?