It’s already a few months since my two posts on gnome-shell, so here is another one. I hadn’t looked at it for some time, but now I’ve checked it out again and although the visible changes aren’t all too big you can see it has a bit more form now (FUSA works now on it, you can move windows from one workspace to another, the transition from the desktop to the overlay window has got a better looking animation, etc). For those who want to try it out, I’ve updated my post with the installation instructions, but following those from the official wiki should achieve the same now.
In case you are running Ubuntu Jaunty, at the moment you’ll get a build failure trying to compile gir-repository, but you can easily workaround it by opening file «~/gnome-shell/install/bin/g-ir-scanner» in your favourite text editor and changing «site-packages» in line 41 to «dist-packages»; if you’re using Ubuntu 64 bits you’ll also need to change the value of «libdir» at line 37 from «lib64» to just «lib» .
Anyway, so let’s go to the actual reason for writing this post. David Jordan has been asking about the windows list in #gnome-shell (server irc.gnome.org) and I offered to ask the question here so that it arrives to more people. So here it is:
What do people like or dislike about the current GNOME window-list?
Tell us your opinion in a comment, or jump into #gnome-shell and speak with David himelf (alias dmj726).
Related posts:
- Installing GNOME Shell in Ubuntu Intrepid
I’ve read in Jono‘s blog that the development of GNOME Shell (which in turn may... - Call for feedback: Removing the Run dialog with GNOME Shell
I was about to do some work for GNOME Shell’s “Run Dialog” when Colin Walters... - GNOME Activity Journal, and installing it on Ubuntu
As already announced by Seif, the first development release of the GNOME Activity Journal (what... - I want a mailing list & forum hybrid
There are some thoughts which are repeating in my head for years, and I’ve just...
I’m against revolution in GNOME. Whole new thing called GNOME Shell creates too many new boundaries.
Would be cool if there was a PPA to try it out.
The window list is built on a rather broken idea that individual windows (in particular their names and icons) on their own always represent something of importance to the user. The concept is definitely not GNOME’s fault, but there are trends moving away from it, and for good reason.
Windows are windows; containers for drawing stuff, generally GUI widgets. Nothing more, nothing less.
Take a look at the different ways applications function with regards to windows. Some have no main windows, and so with today’s environment have no way of “existing” to the user unless they ‘abuse’ the notification area or make use of deprecated component frameworks. (And don’t get me started on panel applets. That is a prime example of consistent user interface being pushed over by implementation details. Why should the user have to care whether a timer application appears in the panel or a window? With panel applets, we end up with two methods of launching applications with the only functional difference being that panel applet applications never present themselves beyond their launchers). If we are going to have “open window = application,” why don’t we come up with a framework to represent /applications/ instead of all the guessing?
An application window can become urgent, triggering a fancy glow effect in the window list applet. The notification daemon (libnotify) stuff has made that look redundant. Canonical’s “Messages” panel applet coming in Jaunty has the same problem.
The window list provides us with notifications in the same style as libnotify. (I hate to call them notifications, but it’s become the trend. It’s really more like a shelf). In this case, the window list gives us rather passive notifications that things are happening in the background. Each notification has a variety of actions through the right click menu (all provided by libwnck) and a primary one through a single left click. They can also be dragged and dropped since they’re all linked to relevant content types.
The user is driven to look to the window list when windows appear and start yelling for attention, so why not when other objects like emails and people and downloads start appearing? What, other than feeble implementation details (no windows exist for the objects) say that these things should be panel applets or should operate through actioney notification bubbles?
If notifications are meant to be quick and easy and helpful, they should not be happening in six places at once. It’s like having six over-zealous assistants all competing for attention as you try to get work done. (The notification bubbles are winning, by the way). One becomes more interested in strangling them than in actually listening to what they have to say.
The Window list’s items change size! That’s a big thing for me.. Especially disturbing if one window constantly changes title, the window list button is going to grow and shrink all the time. The major bad thing about this is that the button’s position and buttons after it _move_ so I actually miss the right button to get the window I want.. which sucks. The only way to fix it with the current window list is to set minimum size = maximum size = something big, so that the window buttons can’t do that.
PPA to try it out would be cool indeed.
Well, one thing I do like about the current GNOME window-list is the ability to rearrange items in the window list with a simple drag-and-drop. It is just a small little thing, but I like it!
I know some people say the window-list is broken. I’m rather used to it, but I don’t mind innovation – if it works. I do, however, find the window-selector panel plugin a useful addition to the window list (I do wish there was some hotkey to bring it up).
1. The buttons are modal. Usually, clicking a window’s button focuses the window, but if the window is already focused it minimises it.
An old version of the Ubuntu Netbook Remix window picker got this right (although the latest version gets it wrong again).
2. New items appear at the end, instead of alongside similar items. (For example, new Firefox windows don’t appear next to other Firefox windows.) Windows XP got this right.
3. The window list doesn’t use all the available space—this makes Fitts’s Law cry. In the simple case, when there are n buttons, each should occupy 1/n of the available space.
Safari 4 beta’s tab/title bar gets this right. (And there’s a Windows XP registry tweak to accomplish the same.)
(3a. Cleverer would be to make more-relevant buttons wider, whilst still occupying all of the available space overall.)
I really like all the improvements that are invented because of this program are getting better and we see new opportunities.
Greg’s point #1. If you use focus-follows-mouse, and you have an almost-maximized terminal window on top with a couple of pixels at the bottom of the screen showing another window, that other window gets focus when you’re trying to move your mouse over a window list button, triggering the minimization on click when you’d expect focusing.
Mr. Odd: that’s a feature I hadn’t known about. Cool!
To see what people want in a task bar, maybe take a look at all the tab-related Firefox Extensions. Or look at Google Chrome to see a tab bar done dictatorially, and done right.
I can think of a few reasons I prefer tab bars to most window lists. Tab bars have close buttons, and they can do so safely because any accident is easy enough to undo, websites being good about autosaving their state. They display emoticons, which KDE’s window list, when combined with Konqueror, does too. They dispense with the modality mentioned by Greg Nicholson, and with window management futzing generally, by always maximizing their contents, which on any monitor I’ve ever used is very rarely a problem. (On a larger monitor, it might be cool to have predefined spaces, i.e. adjacent virtual desktops, always fully filled by their contents.) Chrome’s tab bar has nice animations too, and smart rules for grouping related tabs, and a cute little new tab button that when combined with their blank tab page and the flashing cursor in the “omnibox” is effectively a task launcher.
For what it’s worth, in the larger debate over the future of the graphical shell, I think tab bars and window lists are both great, and both are unfairly maligned (though I do agree that internal tab bars represent a failure of window managment, which should be done right at the right level). To an eye accustomed to reading they’re much easier to scan than an arrangement of miniaturized pages.
“Internal tab bars represent a failure of window management, which should be done right at the right level”
Whoah, you said it so much better than I ever could. I don’t think that the user wants a list of windows. The user wants to switch between tasks, not between windows (or tabs). This is a really hard problem to solve, but if it is done right, there’s a lot of potential to make Gnome better (than any current desktop environment).
http://bloc.eurion.net/archives/2009/gnome-shell-window-list/comment-page-1/#comment-5272
I’d like to echo this comment.
There’s an add-on for removing tabs from Firefox (Tab Killer), at which several people have commented, “Why would you want to do that?!”. There’s an assumption—largely valid—that window managers are all broken.
But with a decent (or even *good*) window manager, in-application tabs would become a hindrance.
I see nothing wrong with the window list. The Gnome Shell I think just does things simpler. And isn’t that the Gnome ideal? Since the purported goal of a GUI is to make things easier for the casual user to do, GUI OS’es should do their best to get out of the way. I propose two tasks buttons and their corresponding work spaces, a House icon for “Home” or “My Computer” and a Globe icon for the Web or network (which grays out when the user chooses to unplug from the network). That way, the user knows that what she or he is doing is still local or already on the Net. I certainly don’t want to be writing an intimate love letter only to find out I’ve already posted it to MySpace.
As a follow up, this is now being actively discussed on gnome-shell’s mailing list.
Here’s a sample of what it might be like:
http://farm4.static.flickr.com/3550/3495515137_47b1d16603_o.png
(But please don’t start complaining about it, this is just one suggestion out of many :). Check the mailing list’s archives if you want more information about them all.).
There is one thing I really do not understand about usability and this is why the typical target is the’new user’.
It feels like the new user is someone who has never used a computer before. The new user has not seen Windows, the new user has not seen MacOS, nothing. The fact is that most people who will use Gnome 3 are people who have used Gnome 2 before, or at least some other PC user interface be it Windows 7 or Mac OS. I don’t understand the need to constantly invent new UI paradigms. The ones that have stuck with us have done so probably because they work.
The first hypothesis about the UI that is supposed to be verified in GnomeShell usability tests (http://live.gnome.org/GnomeShell/Design/UsabilityTesting/PhaseI) is the following:
1. A persistent window list is distracting to the user. A user will be less distracted if the window list is not always visible on the screen.
How about another hypothesis:
1a. A user would prefer to be able to switch between running applications with just one click instead of two
IMHO the taskbar is one of the best achievements for desktop UI design, I remember how much of a difference it made when moving from Windows 3.11 to 95.
The decision to get rid of the taskbar is similar only to Microsoft’s decision to get rid of the application menus and replace them with a loosely structured collection of icons (the ribbon UI)