Thoughts on the GUI

Before I start, let me get one thing off my chest. The progressbar animation in Ubuntu 8.10… It moves the wrong direction! Sadly the original default in Clearlooks was chosen from a poll, which had a subtle flaw: The progressbar wasn’t actually progressing, and that makes all the difference (as more people will hopefully realize now 😉 ).

Thank you, this was important.

Some observations about current trends in GNOME themes:

  • Desaturation. I see many many themes and mockups tone down the amount of colour in the general chrome, which also happens to be what Apple and Microsoft are doing. The popular Ubuntu Dust is a good example of this. Personally I find this style very attractive, so I welcome this development.
  • Another popular thing seems to be the reduction of borders and bevels. Many themes for a long time have tried to reduce the window border to a thin line, to create a cleaner look (as OS X does), which obviously fails to the lack of a consistent resize handle for GNOME applications. A workaround is to only make the bottom border thick, but this can look rather crude, especially when the application also has a status bar with a resize handle. Dust uses a fairly small bottom border which looks nice, but I find the usability of it to be fairly poor.
  • Along the same lines, people are trying to create a more unified look and remove the separation between titlebars and the application (again, Dust is a decent example for this). This makes a lot of sense, it doesn’t just look good, it also makes windows appear more like objects and it should increase the area of the chrome which can be grabbed. Of course the latter isn’t the case with Gtk. Another problem is that the menubar gets in the way. Creating a unified look that works well with and without the existence of the menubar is near impossible. Dust does a better job than most, but the lack of a separator on no-menubar windows still feels like a bad compromise.

So what could we do to support these trends? It is unreasonable to think that themers will come up with something truly remarkable, if we don’t provide them the means to implement popular concepts. I see this as a general problem in the GNOME art community, design generally seems to be seen as this thing that has nothing to do with programming. But providing a set of API functions and replaceable images just isn’t enough. Great design has to be a top to bottom effort. I’m not optimistic that we can ever rival OS X (or Windows even), if we don’t start talking to each other and take design seriously on all layers.

That said, here would be some thoughts:

  • Reconsider the menubar. Soon we are the only ones left who still stick to the traditional method of putting the menubar at the top of every window, right below the titlebar. It’s not just bad for design, there are other problems too. E.g. it really isn’t well suited for applications that have a very small profile, like a buddy list. And a small menu looks silly on a large window, which invites application developers of simple applications to add countless trivial menu items, instead of keeping the application menu nice and tidy. Let’s brainstorm some alternatives and let’s not be afraid of breaking consistency. We will have to do it sooner or later, if we don’t want to be trailing behind for all eternity.
  • Make the resize handle ubiquitous. Resizable windows should have a resize handle, not just to make “borderless” designs a real possibility. I regularly find myself unmotivated to resize a window if it got no resize handle. Marrying the resize handle with the statusbar seems fairly pointless to me. Let’s make it possible to integrate the handle in every possible window design (even if it has to transparently overlap the content area).
  • Pull the window frame drawing into the toolkit. The strict separation between frame and application causes many problems. The application should have complete control over the appearance of the window object, and there should be no difference in behaviour between different (often equal looking) parts of the chrome. This could also allow applications to tweak the entire window object, if the conventions are not ideally suited for a specific task. Consistency can be ensured by using common themes/layouts (more thoughts on this coming). This would also open up the possibility for many alternative menu designs (and of course “legacy” applications would still be supported with a separate frame).

I planned to write more, but this is already getting quite long (and I tired), so I will break it up into two posts. I will go more into my reasons for some of the more controversial thoughts and add some more thoughts about theming in general.

I am aware that this must look like armchair-criticism, but I am mostly just trying to express the various thoughts I’ve had in my head for a while now. I fully intend to make up for it in the near future with some actual work.


35 responses to “Thoughts on the GUI

  1. There’s my desktop as of a few weeks ago.
    Apple knows that we pack too much into windows right now.
    They kicked the menu bar off.
    They /should/ have kicked the window title off.

    The menu bar and window controls should all be in the same bar, and the entire bar should be grab-able. Only after clicking and releasing should clicks be passed from the grab bar to the menu or window controls.

  2. I’d also like to note that while we should consider a lot more overlap with the window frame drawing and the app, giving the /app/ more control is a Bad Idea. I think the entire GUI of any app should be written in a markup language and some webkit derivative should do all the rendering while the app itself only handles small frames and sockets with the widgets…

    By golly when I click the close button, I don’t care WHAT the app thinks about it, I want it to close, even if that means SIGTERM or SIGKILL.

  3. Re menu bars, please don’t take the traditional Apple approach of having the menu bar detached at the top of the screen. It’s a pain on large screens, where all the benefits of Fitt’s Law are canceled out by having to move the mouse all the way to the top of the screen, then back again.

  4. Simon: You’d think a global menu bar would be too slow on larger screens, but preliminary calculations indicate otherwise. See (middle section of that post). People should stop perpetuating this myth. Fitts’ Law isn’t pseudo-science, but a real verified mathematical equation. If you’d going to make a claim about Fitts’ Law, be prepared to crunch the numbers.

    In any case, getting rid of the antiquated menu bar would be a step in the right direction. It was fine when there were just a few menu entries, but it’s become unusable for most applications. It’s also a Hick’s Law violation to have the same function both as a menu entry and as a toolbar button. Deprecating the menu bar would force proper design, as the designer would be forced to avoid having a million toolbars and toolbar buttons. A similar argument could be made for a ubiquitous resize handle: it would allow the deprecation of the status bar in many applications that don’t need it without losing the resizer.

  5. Removing the menu bar would be foolish at this point. I like the trend of visually combining the menu bar and the window title in one area, as seen in Vista and the Dust theme you mentioned. I agree that some small utility windows like a buddy list don’t need a menu bar, but those kinds of applications can easily use a set of icons instead of a full-fledged menu.

    In general, to achieve an uncluttered look I think using expanding hover widgets would be cleaner and more intuitive. Resize handles should appear when hovering near the corners, and the minimize, maximize and close buttons should be very subdued until hovered-over, at which point they can become larger and brighter.

  6. Hey,

    The creator of the Dust theme here. Let me just add some of my observations while doing the theme of what I hope to see in the future of GNOME:

    – Standardization across applications.
    This is very poor at the moment. Some apps want to put borders on their own, some insist on their own button padding values, et cetera.

    – Different window types.
    I’ve long wanted to skin dialog boxes differently from the rest: …but GNOME currently doesn’t support this.

    – A better theming system.
    A CSS-based system is in the works. I can’t wait to see that in practical use! Right now, GTK theming is very hard and involves a lot of guesswork. This has to change to pave way to a new generation of themes.

    – More classes on apps (for more visual variation)
    By “classes” I mean giving names to the widgets of apps so that they can be styled differently in themes.
    With reference to the mockup above, I’d love to see certain widgets on certain apps styled differently. For instance, the location bar in Nautilus looks ugly being homogenous with the other toolbars — it’d be nice to be able to style it differently!

  7. Windows can already be drawn without frames — this is used by special applications like the panel, or desktop widgets.

    However, the idea moving frame rendering into the application is *terrible*. With the current design, the user has control over an app’s window no matter what that app’s state. If it’s frozen, or buggy, or waiting on input the window can still be moved, resized, and closed. If the frame was drawn by the app, it would be unavailable to the user.


    There are a couple changes I’d like to see to menu bars, though. I think the Apple design of putting the Quit, About, etc menu items within a menu named after the application is a brilliant idea.


    Lastly, there’s no reason why menubars can’t be made grabbable in current applications. It’s easy enough for windows to implement self-dragging — all that needs be done is convince the GTK+ maintainers that it’s a beneficial feature. If you can do this, more power to you — I’ve tried with no success.

  8. @aescnt: Love the Dust theme. Very impressive!

    Another thought on less clutter: subtle hints that briefly appear when a window is rendered, and then fade away. I like the idea of not having resize handles visible at all times, or minimize/maximize buttons on windows that don’t have focus, and by providing some kind of visual cue upon hover or initial placement events, the process of figuring out which parts of a window can be interacted with becomes intuitive.

  9. @David

    I’m entirely aware that Fitt’s Law isn’t pseudo-science, which is why I mentioned it in the first place. But remember that it’s not just a factor of how large a target is, but equally about how far away it is. Distance isn’t a big factor in getting to those infinitely large screen edges, true enough – even on the biggest screens, pointer acceleration will get there with no problem of overrunning the target.

    However, that doesn’t apply to the return trip back to wherever your attention is, usually somewhere in the middle of the screen. That *is* heavily affected by having to move greater distances – from personal experience on a 24″ screen, it’s relatively easy to find a small target from a few hundred pixels away, but much harder to do from twice that. Right now, the Firefox menubar is roughly 200 pixels from the text field I’m typing in. The top of the screen, where that menu would be on a Mac, is close on 600. Makes a big difference…

  10. Oh, and the idea of merging any menus with the titlebar is interesting, but the screenshots people have provided don’t seem to include the actual window title anywhere. Given the title is usually the name of the document I’m working on, how do you keep track of which file you’re editing when you’ve got a few open?

  11. > obviously fails to the lack of a consistent resize handle for GNOME applications.

    What causes this inconsistency? I really miss those bottom-right resizing triangles. I rarely see them in Ubuntu.

  12. Simon: The thread I linked to earlier contains answers to your objections, and more. The return trip is slow either way. The difference between returning from a local menu bar and global menu bar is negligible, compared to the advantage. It’s basic algebra to do the calculations. In the end, the results indicate that screens would have to be much larger than they currently are (and pointers much slower) for global menu bars not to be more productive. So, again, please perform the calculations yourself (and show the results), if you’re going to make a claim based on Fitts’ Law.

  13. Pulling window frame drawing into the toolkit doesnt solve any of the problems listed and creates many more.

  14. How about BeOS-like window titlebars? If there were a way to organize windows so that titlebars are moved and rearranged as if they were tab a lot of space on the screen could be saved.

    Menus should change in some way, I agree that they’re a difficult target (Fitt’s law) but I’m as well a little skeptical wrt ribbons.

  15. Murray: The problem is that the resize handle only exists as a part of the statusbar, so unless an application uses a (standard) statusbar, it can’t have a resize handle.

    As far as I can tell, OS X has at least three types of resize handles: Integrated in the status bar, integrated in the scrollbar, and a standalone one which is used on dialogs or even on top of the content, if the window has no other chrome to integrate the handle with.

  16. Having unified drawing should allow some of the nicer ideas for gnome 3.0 – like having a large icon that covers the titlebar, and part of the menubar below, which can be used for drag-and-save.

  17. Pingback: » stop saying fitts’ law

  18. Almost all of the windows I ever use are permanently maximised; I might as well have a global toolbar and menubar. Seriously, does anyone ever use the multiple-windows-as-once display for any real purpose? Maybe I will when I use larger resolution monitors one day.

    Can’t resize work on window edges no matter how small the border?

  19. “Seriously, does anyone ever use the multiple-windows-as-once display for any real purpose?”

    Not sure what you mean, but the main advantage of using overlapping windows (instead of maximized), is that it is easier to quickly select a window. I almost never use the taskbar or dock for window switching.

    Another advantage is, that window objects can have a size that is most natural to view them, e.g. for flowing text.

    I also often keep several windows side by side, most usually involving terminal windows. But this is a rather advanced use case. Most of the time, my focus is on only one window object.

    > Can’t resize work on window edges no matter how small the border?

    The thought crossed my mind, and I see no reason why it shouldn’t be possible. It does have the (minor) downside however, that it will unintuitively block a part of the click-through area. In any case, a resize handle would still add a lot of value.

  20. @Daniel: Sorry, it should have been “multiple-windows-at-once” but I think you understood me correctly anyway. I, too, never use a taskbar or dock for switching: I use ALT-TAB which I find much faster. I also have several terminal windows open, all maximised.

    I guess my point is that, even taking your counterpoints as the final word, it’s still perfectly possible to get by with just a single menubar displayed at all times. I love the Mac UI for that.

  21. Good write-up.

    And yes, there should be difference between normal Window and dialogs.

    And being able to detach the menu-bar from the window to the panel: awesome 🙂

  22. Here’s an idea: Instead of pulling the window frame drawing in the toolkit, why not create a simple communication protocol for exchange of data/events between the two?

    A hinting/advertising mechanism that can export things like color, texture, transparency to the window manager, so the frame can be drawn to match any changes in the application area. The same method (dbus?) can also be used to export the contents of the menu bar to the window manager: if the WM is capable of honoring the request, it returns a signal, upon which the tookit forgoes drawing the menu bar.

    The same method would also enable arbitrary placement of the menu bar, such as in the top panel.

  23. In most (especially maximised) windows the title bar and menu bar both have lots of whitespace, why can’t we just combine the two like itunes on windows.

    What I’d really like to see is the ribbon interface on Linux – just because microsoft invented doesn’t mean it isn’t very useful for apps with lots of commands.

  24. +1 for border-less design

    Example of how much nicer certain apps could look:

    * Bordered

    * Border-less

  25. @David

    You’ve twice referred me to a link you’ve posted, but I can’t find it. The only links I can see in your post are to an XKCD comic, and to the Ubuntu Dust theme page, neither of which seem to be relate…

    Somewhat tangential, might I observe that links don’t stand out very well with your CSS? On my screen at least, dark green text doesn’t stand out very well from the black text – I didn’t see the Poll or Dust links until I tried tabbing through to find the one you were referring to…

  26. Simon: I am not Daniel. The links you refer to are in Daniel’s post. Looking back at my first comment, I now see now that the link I posted was actually stripped out! I apologize for all the confusion. Here is the link: .

  27. @David

    Oops, you’re right, I was confusing your name with Daniel’s. Silly mistake. I’ll have a look at the article then…

  28. +1 on border removal and de-cluttering, I made my own fumbled efforts to Pidgin, earlier in the year:

    There’s too much space wasted on padding in Gnome, and are too many vertical and horizontal lines in a typical GTK app.

    @aescnt: Great to here that CSS is coming to GTK

    @stu: I would love to see a big-icon/spawn-of-file-menu consume the top left corner. I so rearely see the window menu used, that it’s a waste of the window corner.


  29. @David

    The thread you link to, and the article it in turn references, seem inconclusive on the subject. As an actual equation, Fitt’s Law predicts top-menus should still be better than window-menus, based on numbers. But that’s still only a prediction, and neither page seems to offer any actual experimental evidence – just that theoretical prediction, and a bunch of subjective opinions. Do you know of any actual studies on the subject of menu location and large screens?

  30. Simon: Alas, I know only of no studies on the subject, at least none that are available online. The calculations in that thread are all based on Jef Raskin’s summary and his figures.

  31. Pingback: Peng’s links for 5 November « I’m Just an Avatar

  32. What do you think of showing the window title only on inactive windows? When an inactive windows gets the focus, the title gets replaced by the applications menu.

  33. If you take away my file menu, like Office 2007, I will break your fucking face! I will shit on your cat! You will rue the motherfucking day!

    Fuck niggers who take away my menus!

  34. Pingback: Michael Alan Miller » This rant goes to 11

  35. Pingback: Creating Themes « dborg’s Journal

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s