|An Early Look at GNOME 3.0|
For example, consider that the Activities Overview and the Alt-Tab switcher are the only ways to switch between running applications. I run a dual-monitor setup, and prefer to use GNOME 2's window list to switch between apps. That's not because I'm old-fashioned, it's because I can switch to any running app in less than a second by clicking on its window list icon. In contrast, it takes 4 to 5 seconds to switch apps via the Activities Overview, and potentially longer with Alt-Tab, depending on how many are open. On top of that, if I've been away from the keyboard, I can instantaneously tell that there are highlighted IRC messages or new IMs in the panel, because the window list icon slowly pulsates. In GNOME Shell, if I missed the transient notification pop-up, it's just gone.
So why is there no window list option in GNOME Shell? Officially, the Design FAQ tell us: "in order to minimise distraction and interruption and to enable users to focus on the task at hand. A persistent window list or dock would interfere with this goal, serving as a constant temptation to switch focus." Well, my oh my — thank goodness I'm protected from temptation. Although are we supposed to believe that the 22-pixel high list of windows amounts to a greater temptation to distraction than the actual application windows themselves? I know there are users who prefer the hide-all-inactive-windows behavior of tools like Isolator, but last I heard that wasn't slated to be mandatory in GNOME. Besides, the GNOME 3 home page says the goal is "to put you in control." When I can't quickly switch between running apps when I need to, all to save me from the temptation of switching apps when I don't need to, I don't feel in control.
To the Bugzillamobile!
The app-switching difficulty is just the kind of problem that makes me feel like GNOME Shell hasn't had nearly enough real-world testing. It was obviously designed by a small team based on an in-house specification, but one that considers only one way to work. That simply isn't good enough for mass-production environments. There are too many assumptions about distraction, preferences, and daily routines that don't hold up in the wild.
Consider another problem: the menu bar has and will have no "applets." A user filed a bug report about this, specifically citing the need for a system monitor applet. Red Hat's Jon McCann, the GNOME Shell design lead, dismisses it as unnecessary, because "it would be better for the system to be robust against this type of failure." The design FAQ claims a review was done of the GNOME 2 applets, and "it was concluded that no essential functionality has been omitted from the GNOME Shell design." In reality, though, you can dig into the mailing list archives and find that McCann opposed applets for an entirely different reason: because they are "detrimental to the Identity of the product or platform" in that they they allow "ad-hoc/individually-customized design identity." So at least when your CPU overheats, it won't disturb the identity of the desktop in the process?
Fortunately, as the actual release date draws near, the voices of real users are slowing pushing back against some of the bad ideas that came out of the initial design process. An "extension" mechanism is in the works for the GNOME Shell panel, which will allow developers to code missing pieces such as system monitor applets. The API is not defined yet, but there is a git repository where you can follow some of the work.
In an even better example, McCann's preliminary design removed all categories from the App Well, dumping all application icons into a single slow-to-search alphabetized grid. He defends this choice in a bug report, citing a research paper. Fortunately developer Giovanni Campagna held fast, observing that the paper was about a different topic, while pointing out that a 2-D grid is slower to search than a 1-D application list, and that categories substantially speed up users' ability to find the app they are looking for. App Well categories returned in the ISO builds provided by Crozat, but are not in the Ubuntu repository's version of GNOME Shell. Having used both over the past week, the speed difference is tremendous.
Let me be clear: I don't mention McCann in order to single him out personally for some reason; I've never met him and don't even know him online. But his response to this series of bug reports is illustrative: the design decisions were fixed in stone — by a small team — before the code was written, and were based on a literature survey, not real users' actual experiences. For all the flak that Ubuntu-critics like to give Canonical for developing Unity "privately," the upstream GNOME project can be just as unresponsive to input and difficult to interact with, and users get weaker software as a result.
Thus, while I don't think GNOME Shell currently provides enough functionality to use in place of GNOME 2's panel on a daily basis, I highly encourage everyone interested in the platform to test it out and send your feedback to the project. Create a GNOME Bugzilla account, and file a bug reporting the problem.
There are still plenty to squish. You cannot change the placement or orientation of the menubar or notification area (so if you read left-to-right, top-to-bottom, pop-ups pop up in the least-used part of the screen; if your language is different, they're right in your way). The menubar only spans one monitor, which mis-aligns application windows on multi-montior systems and makes them hard to drag from one display to another. The "Activities" label is entirely superfluous. The Alt-F2 command-launcher is impossible to discover. System Preferences are buried halfway down the combined IM-and-shutdown menu, which makes them look like IM Preferences. For that matter, why are IM, preferences, and shutdown combined in one menu anyway (and why is it labeled with my name — in case I forget it?)?
My biggest personal aggravation at the moment is those blurry and cropped-off "current app" icons. A good 40% of the icon is gone, making many of them indistinguishable from one another, and others unidentifiable. I even asked about the rationale on "GNOME 3 User Day" in IRC, and no one could explain when or why it was done. Luckily there is still time between now and April to get it fixed.
On the whole, GNOME 3 is going to bring loads of positive changes for users and for application developers. GTK+ 3, Mutter, the polished notification system — all are clear wins. Shell probably needs more time. I try to take the optimistic viewpoint that Unity, which shares a lot of Shell's underpinnings, will serve as healthy competition, as will continued developments from outside developers working on the extension framework, and eventually we users will get a solution that supports multiple hardware configurations and individual workflows. Sure, it might be rocky for a while in the meantime, but ultimately, isn't that freedom what open source software is all about?