One of the pieces of feedback I often get about GNOME 3 concerns the use of space. People repeatedly say to me that GNOME 3 apps use too much space, particularly in terms of header bars and their buttons.
I find these comments about wasted spacing to be perplexing, because they seem contrary to one of the major themes of GNOME design over the past five years or so. It’s incisive to look at GNOME’s history in this area, and to count some pixels along the way.
Back during the tail-end of the GNOME 2.x days, those of us who were involved in GNOME design were strongly advocating for applications that had less chrome, and gave more space to content. We were particularly concerned about apps like Nautilus, and this kind of screenshot was the kind of thing we wanted to eradicate:
David Siegal wrote a great blog post about it at the time. The proportion of the window that was devoted to content rather than chrome was laugably small, as Andreas Nilsson artfully demonstrated:
Starting with this as a baseline, we can measure how space usage has changed in GNOME in the past four or five years. Back then, a Nautilus window used 171 vertical pixels for chrome (24 pixels each for the title bar, menu bar, and status bar, 55 for the tool bar, and 44 for the path bar).
By the time 3.0 came around, we had managed to reduce the amount of wasted space considerably. The stacked toolbar and path bar were gone, and the permanent status bar was replaced by a floating element. I count 63 pixels for the title bar and menu bar, and 53 pixels for the toolbar – that’s a space saving of 55 pixels.
Three releases later, and more space saving improvements had landed. The menu bar was gone, which had been replaced by a single toolbar. Chrome stood at a height of 70 pixels – a saving of 46 pixels since 3.0, and a whopping 101 pixels since GNOME 2.
Finally, to bring the story up to date, in GNOME 3.12 we introduced header bars, which again resulted in a space saving. Nautilus today has 48 pixels of vertical chrome, less than a third of what it had in 2.22.
This history makes quite a nifty table…
| Nautilus Version | Vertical Chrome |
| 2.22 | 171 |
| 3.0 | 116 |
| 3.6 | 70 |
| 3.12 | 48 |
You get a similar result for other GNOME applications. At the end of GNOME 2, gedit had 127 vertical pixels of chrome. Nowadays it is down to 72 pixels.
What’s more, today’s Nautilus compares favourably with file managers from other operating systems/desktop environments. KDE’s Dolphin uses 109 vertical pixels of chrome compared with Nautilus’s 48. Finder in the upcoming OS X version seems to have around 75 pixels.
So I am puzzled. In GNOME we have greatly reduced our use of chrome, to the point where we seem to use less than obvious alternatives. And yet, we still get repeated comments that we use too much chrome.
You could argue that there is still extraneous chrome that can be shaved off, of course. I’ve looked into the possibility myself, and what I found is that the potential savings really are negligible – in the region of four or six pixels or so. Compared with the dramatic savings we’ve seen in the past years, this is trivial stuff.
Besides, I don’t think that shaving four or six pixels is really the answer to why we get comments about space usage. It’s hard to know exactly what is going on, but I suspect that it is more down to the visual presentation of header bars [1], and something about how some people expect buttons to look. For some reason, buttons like this seem to hit a nerve:
It might well be something to do with shape, rather than size.
GNOME is actually using space better than it ever has done before, and is more efficient in this respect than at least some major rivals. This isn’t to say that there aren’t real issues behind the feedback we’ve got about space usage – obviously something is going on. It’s more of a subtle issue than many give credit for, though, and it’s certainly not because we are worse at using space than in the past.
[1] Perhaps in combination with their position. On a small laptop screen that is below eye level, something at the top is more noticeable, closer, and appears bigger.
I think part of the “wasted space” impression that people get when looking at Nautilus 3.10, specifically in the last screenshot is that there is such a huge gap between the icons horizontally. The vertical gap seems fine, but the rows can each easily hold 6 icons across as opposed to the 4 shown. Of course the labels are relatively short in that example.
Merely counting pixels without also counting the accessible features is completely misleading: how do you account for the missing zoom or “new file” functions in your comparsion?
Rather than counting vertical space, how about counting _useless_ chrome, i.e. the percentage of chrome where clicking does nothing? AFAICT without measuring, that measure is going consistently down, from ~80% useful chrome to ~30%. This is obviously a kind of stupid measure (making buttons uselessly bigger would make the waste smaller) but it does account for both used space and offerend functionality at least a little.
As for the hamburger button hitting a nerve, that’s precisely that: optimizing for adding ~extra empty space on the toolbar at the cost of one extra click, and a pause to search for an item in the pop-up menu.
Of course, counting pixels alone is simplistic. But then, this post was a reaction to claims that GNOME wastes space – showing that we have reduced space usage is a legitimate point to make in that discussion.
I don’t follow your point about useless chrome. The entirety of a header bar provides a useful surface, since it is the means for dragging the window, or for accessing the window menu.
Hey, nice comparison.
Whenever I hear people complain about gnome’s usage of space, they are more complaining about the non-headerbar applications, i.e. the mutter theme with the big title bars (or GtkHeaderBar under wayland). Most reasonable people seem to understand that *using* a custom titlebar (putting buttons inside of it instead of using an extra toolbar, etc) saves space, but when the app isn’t doing that, it looks out of place for them. osx doesn’t seem to care about a uniform size for all the titlebars, is this really important in gnome?
It’s clearly an issue of apparent size. The button/etc have a lot of empty space around the text and icons that seems “wasted”. Especially if you compare with the 2.x era Nautilus, all that space was used for important buttons and labels, so it didn’t feel wasted. So it’s probably an issue of using the right visual trick to make the space feel more useful, for example, by making the icons larger, or by eliminating the outsize box of buttons or something (I’m not a designer!), or we could probably cut the height of the header bar by at least a third if not help just by reducing whitespace… But any of these would end up being big changes in the visual identity of GNOME 3.
And I must say I love GNOME 3, but the feeling of wasted space does annoy me too.
I’ve always thought that the criticism is related to the excessive padding that Gnome uses for widgets. This is probably why OSX achieves a smaller chrome even using a window decoration for close/minimize/title.
OS X actually uses more padding than GNOME in a lot of cases. Buttons certainly have more space around them. Likewise, icon buttons on OS X are a bit shorter, but they are wider to compensate. (This is partly what I meant by this being a shape rather than a size issue.)
I’ve been with GNOME since Ubuntu 6.04, and the header bars are a *great* idea, especially on 768px tall laptop screens. I used to hate Nautilus; now I use it daily.
On the other hand, I was somewhat disappointed by the decision to increase the padding of *all* buttons to make them “more like the ones in headerbars”. I don’t understand that – I’ve always thought of the header bar buttons (like gedit has) of a different category than the regular ones (global actions); they *should* be different.
But overall, GNOME 3 is a huge improvement over the cluttered earlier versions. (If only more lprograms followrd it. I still have to battle with decade-old stuff like Wireshark’s capture options, which doesn’t even *fit* on my screen…)
Hi,
I guess people complain about vertical size that gnome takes not on gnome’s default apps (with those nice header bars), but on the other apps like firefox.
The titlebar for the ‘other apps’ is *huge* compared to MacOS X for example. I always have to modify my theme to reduce the titlebar height. And as you point out, look at the ‘X’ icon displayed for the ‘other apps’. It’s a huge, gigantic ‘X’, which accentuates the feeling that the titlebar is huge.
I guess one thing to bear in mind is with GNOME 3+, people have one de-facto theme they can use, Adwaita, which is larger than some of the shipped themes in GNOME 2. I always switched to Metabox or something similar and shrunk font sizes down to make the menu bars as small as possible etc. – by comparison to *that*, Adwaita still seems bulky. I’ve quite liked the nautilus space-saving improvements in recent releases, for what it’s worth. (Sadly other changes I am less enthusiastic about!)
I suspect that the complaints are more to do with scaling. On a 1336×768 monitor, GNOME apps, panel and icons (by default) take up an unusually large amount of screen space.
Addressing your final point, that may well be the case. The top panel in GNOME Shell combined with the headerbar/top bar of an app gives the impression of top heaviness. Compare GNOME to Windows and you see a stark contrast – GNOME seems top heavy, while Windows (which typically uses considerably more chrome) appears balanced – because the taskbar is bottom weighted and the window decoration is top weighted.
I’m a huge fan of how the Gnome apps are evolving. I’m unwilling to move from Gedit to a more full featured editor purely because I find it so asthetically appealling.
Maybe *because* the visual design is nice/open looking due to intelligent use of whitespace – it feels to some users that there is wasted space? Even though the alternative would look cramped and be less readable just to shave off 4 pixels or so.
Another maybe could be that ppl are responding to none-gnome apps in Gnome. here the only factor from Gnome is the width of the title bar, so ‘wasted space’ just means ‘my titlebar is too tall’
granted this again only saves a few pixels.
Full disclosure: I hack my own adawaita theme to have only a two pixel black titlebar for maximized apps – not ideal *at all* for most folks, but it gets me back some precious vertical space (I can still use the OSkey, or unused chrome, or better aim to drag out of maximize, so for me it is a win)
Obviously not everyone will be happy with the choices Gnome makes, so this debate isn’t going to go away. For myself, I think it’s a mix between less chrome and just the right amount of easy-to-reach features. People want space efficiency but not at the cost of ALL functionality being hidden away in one button or just in a right-click menu.
Gnome seems to be balancing this pretty well now.
Hi, yes, you obviously reduced chrome, but I’d be more reserved about effective space usage claims. You have less space, because you have less readily available functionality:
Nautilus from GNOME2 in addition to current nautilus.
Full-blown menu bar, with categories being top-level. This is arguable whether it’s a good thing to have or not, while I don’t like it in a web browser, I kinda want it everywhere else (one of the reasons I don’t use GNOME3).
The titlebar itself was smaller and had colour, thus was really easy to locate and identify and didn’t take up much space. Because it didn’t have anything from the app, it showed what app are you actually running. No maximize/minimize here, no window-manager menu now as well. The close button is reduced to plain x, again making it harder to notice.
Up and reload buttons disappeared. Does nautilus support remote locations (e.g. via ftp, ssh, etc?). If so, why isn’t there reload button? The same with stop (can be integrated into one button like in many web browsers).
There are some more hidden icons in the toolbar (see the arrow). Home, This Computer, search. The first two are duplicate with places, unless you use tree in sidebar… Search is still present.
The toolbar was unnecessarily huge because it had text beside icons which you dropped completely, because the icons were big and because there were two toolbars. Thunar (from XFCE) uses just one toolbar with 22×22 icon size, although it’s missing zoom (not that often used, hence in a menu), view type (same as with zoom) and search (do you really need an icon for that? Every modern web browser expects you to know the Ctrl+F magic combo).
The old nautilus had button for switching to editable location.
So, obviously, you saved space not by having things more effectively positioned, etc., but by removing directly accessible functionality. With the visually strange phenomenon of having huge empty space in title bar. That is not what I’d call effective. Also the horizontal space in Home button (part of location) is obviously too huge. Certainly not effective. Does it get better with longer paths, at least?
The problem with the three-lines icon is probably that google chrome uses it for menu access, and that’s also what I’d expect it to be.
I personally have problem with all the icons in gnome 3, all are less appealing than the old tango-styled ones (they kinda lack the details provided by having larger than two colour palette), and also harder to identify. Though the visual look is evidently subjective, there are many people who like such icons, even though they look like coming from b/w displays era…
When I first installed the version that doesn’t have a separate toolbar, but everything is in the header bar, I thought, “wow, this is so ample!”. It works extremely well.
I think the perception of wasted space isn’t about the total chrome vs content – it’s about the size of individual chrome. Gnome 3 saves space through the use of more efficient layout, but the individual chrome elements *are* relatively large compared to previous versions – larger title bars, more padding, etc.
whoever argues about too much chrome used in gnome should wear glasses. if anything i would prefer few pixels more only on top of headerbar when window is not maximized (kind of like chrome does it). narrow space is a bit harder to hit when window uses whole headerbar area for widgets like nautilus can.
i would think those comments are aimed at white space between items or widgets, which is a bit larger than elsewhere and also larger than it was in gnome 2. less like traditional linux, more like osx
huge majority of gnome design is 1st class. some parts on the other hand are huge hickups, like notifications, mind that new design https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/notifications/top-right/message-tray.png is a dream come true. visible at all times, doesn’t cover often used screen part…
Wow thats awesome! great to see some hard evidence :)
Hi,
that really neatly explains why I stopped worrying about wasted screen real estate during the last ~3 years. Back in the gnome 2 days I did quite a lot to get rid of title bars and menus and stuff, in order to actually be able to read webpages in iceweasel or read emails in claws. And I was constantly annoyed about changes in gnome which would break my theme or whatnot and I had to get rid of title bars /again/. Nowadays, I only edit the default theme to hide title bars of maximized windows anymore (and I still get annoyed when I have to re-edit the default theme because things changed), but with header bars I find less and less need for that. I never really reflected why I wouldn’t spend hours anymore “customizing” the look of gnome anymore, I just suspected I was getting old and lazy or something. Turns out it is because gnome now just does the right thing out of the box!
Amazing work + keep it up!
Mika
I am confused, surely you are not puzzled that people complained at the time of the 2.32 -> 3.0 upgrade?
Using nautilus 2.32 it was easy to disable all bars except for the location bar and menu bar (that is, exactly what nautilus 3.0 had); this amounted to ~85 pixels of vertical chrome. (Just checked this with MATE’s caja 1.8.1: 82 pixels to be precise.)
I can understand that the increase ~85 -> 116 might make people unhappy (Especially if you’re working on a screen with height of 600 or 768 pixels.)
Of course, as you’ve shown, now this is no longer an issue.
PS. Thanks for your work on GNOME 3, I am using it daily with satisfaction.
Hi Alan,
If you compare with the biggest possible combination (although the default), I would agree with you.
However, it might worth to take a look how different would it be with 3 cases not mentioned here:
(1) Use only icons
(2) Use small icons in the toolbar
(3) In addition, a relatively small font size for window decorations (say 9).
When having (3), Adwaita’s window border looked wider, and thereafter the the headerbar. Similarly if you compare everything altogether (only icons and small icons in the toolbar).
If you are comparing old and new versions, it might be fair to compare the other alternatives already offered within GNOME. I think the benefit would be two fold: it will show that newer versions of GNOME makes thin it better regardless of the setting, and it would provide a fair/complete comparison.
FWIW, I don’t think I am the list of complainers (I avoid to raise this kind of issues when there is a risk of being mixed with an overall noise).
Two comments:
* Nautilus 3.12 is almost indistinguishable from Nautilus 3.10. 3.10 is where we introduced the header bar. (It didn’t use GtkHeaderBar, but it was mostly indistinguishable from one.)
* I think you’re puzzled by the complaints that GNOME is big because you’re misinterpreting them. It’s not that GNOME programs waste space on chrome — I think GNOME has been very successful in cleaning up programs to avoid wasted space, and header bars have been a huge win here — it’s that everything is bigger in Adwaita than it is in other environments, like KDE, OS X, and Windows. Take that Nautilus 3.10/3.12 screenshot, then shrink the whole thing by, say (random guess) 20%. Now you have saved some space, at the cost of making everything teensier and somewhat harder to read. This is what people are talking about when they say “GNOME is big” — EVERYTHING is somewhat teensier in other desktops than in GNOME, so you can fit more on your screen. Compare KDevelop in KDE to Anjuta in GNOME, and you’ll see a tremendous difference in how much functionality you can fit on the screen that has as much to do with the different themes as it does with the apps’ different UIs. This is mostly only an issue on small monitors: at my desktop computer, I don’t care, but on my 1366×768 laptop I find KDE is a better environment for development because everything is smaller and I can fit more on my screen. Does that make sense?
Although I bet much of that might also just be differences in font sizes.
it’s probably a difference in relative font size, as you say.
Windows has a default font size of 9pt out of the box, whereas we go for 10pt.
MacOS has a default font size of 13 (points? pixels? we’ll never know), but they have been changing that with the latest OS release.
to be fair, tho, packing a ton of stuff inside the UI and on top of that making text smaller is not going to look really good after a while.
yes, it’s going to have more controls on the screen, but I stare at text all day, and I have glasses already; if the text becomes too small, or if the chrome gets more stuff, I tend to feel slightly more anxious, and claustrophobic.
I personally agree with your point. The problem arises for displays with height less than 800px and it’s related to “how much content” I can display comparing different desktop. It’s not only a matter of available space in height (width should not be an issue) but a font size issue.
Comparing GNOME, OS X and Windows XP, each of them with its own browser, the picture gets a bit more clear: http://dummyuser.com/temp/GNOME-OSX-WINXP.jpg (the screenshots are from a 1440×900 display so the problem really is non existent, yet you can see the issue on the content and how OS X shows more content with actually less vertical space of all three!
I got the browser example instead of the filesystem cause it better shows the issue. I guess the same could be done with some code in an IDE or a file manager in list view.
The thing is, when compared to a tiling window manager, your waste a nearly infinite amount of space. I’d love to use the gnome back end with bspwm or a similar minimalist window manager. It used to be possible to do that, but that ability seems to be taken away from us.
My main gripe with how GNOME 3 uses space is the top header bar (applications menu, clock, icons).
Firstly, it takes up far too many vertical pixels, which are a scarce resource on a small or medium size widescreen display. Since it takes the whole top edge of the screen, it doesn’t need to be such a large target for clicking, because it’s so easy to move the cursor to the top of the screen. Next, most of the header is just empty space with no functionality. Between the applications menu and the clock – nothing. Between the clock and the right side icons – nothing.
To make matters worse, many actions are now several more clicks away than they used to be. For example, clicking the network icon used to show devices and it used to be easy to change WiFi network, for example. Now you have to click on the network icon, then click on the WiFi device to expand the menu, then click on “Select Network”, then click on the network you want, then click close. There is plenty more vertical space in the menu to display available saved WiFi networks without needing any extra clicks.
I think we should target some attention there, since it is what users see 100% of the time, no matter if they are browsing the net or using nautilus or writing a document.
For example, for maximised apps, there used to be an extension that removed the app’s window decoration and put them into some of the unused header space – if done properly this would be excellent. Also, we should make good use of the fact that it’s easy to move the cursor to the top edge (or to drag down from the top edge on touch screens) – make the header thinner but with wider targets for icons on the right to compensate.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
People complains about Gnome having too much chrome, because:
* They are still largely using and were using Gnome < 3.10 (Ubuntu was in 3.8 before may, Debian is in 3.4…)
* When the header bar is not used by the application (thunderbird, firefox, libreoffice…), it is just a lot of vertical empty space with a line of text and a ridiculously big close button.
Keep up the good work, but you might have to step back and see a typical user desktop not just some ideal where everything is the latest Gnome app. You can't do much about the user updating to latest Gnome, but you could pay attention to the shape of the bar on a non Gnome app.
I don’t mind space taken up be chrome if it is providing something useful. Chrome can be reduced to almost zero if thats what you want https://en.wikipedia.org/wiki/File:ION3_Screenshot.jpg, but I guess most people want a balance between ‘enough remaining space to do useful work’ and ‘enough buttons, indicators, labels etc to do useful work’. The other factor is that some people like whitespace and simplicity for aesthetic reasons.
(Personally I use MATE with a 2 panel setup. Both my panels are packed with useful things. Reducing the panel height and font sizes makes things useable on a 12 inch screen. I often use F11 to jump to full screen if I cam concentrating on just 1 application.)
> So I am puzzled. In GNOME we have greatly reduced our use
> of chrome, to the point where we seem to use less than obvious
> alternatives. And yet, we still get repeated comments that we
> use too much chrome.
I believe some of it comes from people who don’t run all of GNOME and therefore don’t benefit from gnome-shell. Without that apps like nautilus and gedit get title bars from the WM and a strip designed to act like a title bar.
Hi Allan,
First of all, I would like to thank you all who have put so much effort and time to make GNOME Shell such a great desktop environment to use. I’m one of the early users who have been using GNOME Shell on a daily basis since the first release therefore I can say I witnessed how it has been growing and becoming mature with regard to both UI and UX over the time. I have to say, I love GNOME Shell just because of its minimalist yet elegant design. In my personal opinion, GNOME Shell is heading in the right direction so keep up the great work!
Now on to the topic.
One of the possibilities (though I’m not 100% sure) which might have puzzled you is that people who are complaining about “space being wasted in GNOME Shell” might be comparing apples to oranges. Let me explain this in details.
When these people are looking at the header bar (apples), they are actually seeing a “title bar” (oranges) with a few more buttons next to the “traditional” Close button. This is certainly because of the traditional way of thinking that the part at the top of a window is always the title bar. Based on this mind set, the header bar (i.e the “title bar” in their mind) is definitely taller that any title bar we all have ever seen in any desktop environment on any OS so far.
Those who complain should (or the GNOME folks should help them) wrap their heads around the fact that the thing at the top of a window which uses a header bar in GNOME Shell is NOT a title bar. Instead, it’s a merger of a title bar (even though Nautilus 3.10 does not even have it’s title on it) and a tool bar therefore it’s taller than a traditional title bar to make room for regular tool bar buttons because these buttons are, traditionally, taller than a title bar (everybody buys this one, I guess).
Another possibility that gives these people the false impression that the buttons in the header bar are using extra padding and thus wasting space is that those buttons use smaller icons compared to the ones used by regular tool bar buttons.
The third possibility is that there’s not a clear separation between the title bar and a menu bar in a window which does not use a header bar. This definitely gives the impression that the window is “heavy-headed”.
At the end, these are all a matter of personal taste. There are the people like me who love apples and there are also the people who love oranges. The people who are happily loving apples do not make too much noise (I, personally, rarely leave comments if I’m happy with something.) And the people who love oranges might have got frustrated because they keep getting apples instead of oranges thus they might have become so called “vocal minority”.
Based on these thoughts, the GNOME folks should not be bothered by this space issue. In my opinion, GNOME Shell, by design, is not traditional. They should send out this message more clearly. GNOME Flashback, one the other hand, is traditional. The people who are stuck with the traditional desktop UI/UX and thus not happy with GNOME Shell’s design principles should feel free to use GNOME Flashback which offers most of the traditional stuff they are used to until they finally accept the modern design choices employed by GNOME Shell (or any other modern DEs).
Vertical space is the problem on most laptops.
The Hide Top Bar extension is a must for screens <= 900px.
The Maximus extension is good, but unfortunately does not work with 3.12. Also, the user experience is not that good since it changes the placement of the close button.
Hi Allan,
Gnome is designed from the ground up to be equally friendly to fingers as it is to mouse/keyboard, so some extra padding on list items is understandable. However, I think the effect you describe is psychological, because many modern interfaces ignore hard-line borders around button click areas, and instead show just the icon sans-borders.
I made this mockup in about 2 seconds, so it’s sloppy, but it gives a good contrast of what fewer borders could look like:
https://www.flickr.com/photos/26671354@N05/14887117120/in/photostream/
I love gnome. thanks for all this evolution. really. thanks! I won’t change it never!!!
The thing with those buttons is they are so ‘in your face’.
If you want to see why ‘Gnome wastes space’, it’s probably instructive to look at the ‘Home’ path/button thing in Nautilus as compared to, say, Windows Explorer or Dolphin. Two out of those present a single, smooth uninterrupted line of content, using relatively unobtrusive delimiters (>). The other decides to add what appears to be visual noise, and to add insult to injury decides to dispense with gradients so there is no visual relief. It’s the opposite of unobtrusive, really, and that’s what makes you notice the UI so much, which is why it appears to take up space excessively.
By contrast the design choices of Dolphin (using the Oxygen theme, anyway) mean that you barely notice a few pixels here or there because the whole UI appears to treat your eyes rather more gently.
Hi,
I think the problem of “perceptual bulkiness” in Gnome is more complex than just icon design. I belive there are at least four factors at work: the ubiquitousness of icon widget borders; the design of buttons; how Gnome uses fonts and typography; and theme properties.
1) Icon Borders
Currently, every button has it’s own always-visible border, which to me seems reminiscent of the Gnome 2.22 days when Gnome used lines around every section, sub-section, tab, and sub-tab, such that you would frequently see UI’s that looked like relief maps. In more modern UIs, some click button borders could be invisible except on mouseover — the chrome web-browser does that. I made this in GIMP to show what I mean: https://www.flickr.com/photos/26671354@N05/14887117120/
Buttons that are clearly grouped together, like those that alternate between different views in a window, can have some kind of animated toggle effect that clearly connects them.
2) Button Design
I also really like the clean way buttons are drawn in modal dialogs after 3.12, and think that clean language could be transferred to elsewhere:
http://worldofgnome.org/uploads/2014/03/modall-dialogs312-apps.png
In many places, Gnome still uses slightly rounded and shaded rectangular buttons within a larger plane. But virtually every other major GUI has been following a trend toward completely flat design, where perfectly square rectangles or perfect circles reign supreme. In some UIs, button borders are eschewed entirely in favor of clickable text with nothing around it.
3) Fonts and Typography
I think another area where Gnome could make inroads in perceptual use of space is in diversifying fonts more. Using greater varieties of fonts across titles, headers, and body can make a huge impact in the “feel” of UI lightness. For instance, the Elementary OS does this:
http://elementaryos.org/journal/typography-gtk3
4) Theme Design
Gnome has been headed in the direction of a completely flat design for a couple generations now, but I would encourage it to embrace the philosophy more completely — including folder design :)
Specifically, I hope Gnome takes inspiration from three trend-setters: iOS 7; Google’s “Material”; and the web-OS “Mochi” design language (http://www.slashgear.com/webos-mochi-design-language-released-as-open-source-03323722/)
Ps I posted a similar comment on 29/08, but it never passed through moderation. I hope nobody minds if this is a re-post, but I am not sure if it was a technical glitch with the local DNS router, which has been known to happen.