The same can be said about Ubuntu as a whole. If you browse through the archives of the Ubuntu development list, you can hardly miss how the introduction of the Design Team upset the decision-making in the Ubuntu community. Suddenly, all those who had discussed design direction were expected to defer to a set of newcomers unfamiliar with the community's norms.
The situation has since improved, although other design fiats, such as the movement of the title bar button, or the decision to make Unity the default desktop have been caused some upsets as well. At Ubuntu, those making design decisions seem to have veto power over almost everything. To the skeptical eye, this veto can look surprisingly like a claim of objectivity based on a familiarity with usability theory.
The same is even truer of GNOME 3. When you read the design history of GNOME 3, what is striking is the degree to which "from the start, GNOME Shell was a design-led project."
As with Unity, at times this design-centered approach has its points. As the GNOME 3 design history suggests, keeping track of open windows is a problem on all modern desktops, and virtual workspaces, while useful, need to be implemented so that they are easy to use.
However, the same illusion of objectivity that seems to have influenced Ubuntu also seems to have influenced GNOME 3. Design lead William Jon McCann is quoted as saying, "The first thing I did when I started working on the GNOME Shell project was read. I spent a month doing nothing but reviewing usability research into desktop computing. This research reinforced a pre-existing concern: that computers users are increasingly suffering from distraction."
What is interesting here is that McCann reveals the subjectivity of what was to become one of GNOME 3's main design principles. Already convinced that distraction was an issue, McCann found -- unsurprisingly -- the external evidence to support exactly what he was inclined to believe.
Later, when GNOME 3 was released, "distraction-free computing" became one of the benefits emphasized by the marketing team. At the same time, an FAQ answered the question "how do you know it's better?" by emphasizing -- among other things -- "empirical usability research" and "stock usability principles and knowledge." In this way, a subjective impression appears to have been elevated to unquestionable fact.
In neither Ubuntu's nor GNOME 3's case is this transformation of subjectivity into objectivity likely to have been conscious or malicious. But it occurs frequently enough, as people attempt to master the tremendous body of usability theory and are influenced by the apparent objectivity of the scientific and pseudo-scientific voice.
But the danger of studying too much usability theory is not just the temptation to assume infallibility. What is equally important is that it often discourages a close examination of basic assumptions and whether they are complete or can be mapped on to the real-world situation.
My worry is that this outlook has infected both Unity and GNOME. Having identified actual problems, both Unity and GNOME 3 sometimes appear to have moved to solve them without considering whether other problems were equally important, or what new problems might arise from the solutions.
For example, in trying to make the launching of applications easier and freer of error, both eliminated the classic main menu in favor of displays that occupy the entire desktop. This arrangement does improve the launching of applications -- but it does so at the cost of obscuring the windows that are already open and requiring far more clicks and movements away from the active window than the main menu ever did.
The same is true of the decision to design desktops that can be used for mobile devices and touch screens as well as workstations. From the perspective of software engineering, this design principle is sensible because it saves the effort of maintaining at least partially separate code bases.
Yet, from the perspective of a user on a workstation or a laptop, the principle becomes a frustration. Admittedly, a desktop for a smaller screen works better on a larger screen than one intended for a larger screen works on a smaller. Yet it is also true that, at the same time, what works on a small screen can seem cramped and clumsy on a large screen. Nor is a small screen design likely to be equipped to make use of the extra space on a larger screen.
Yet another way that focusing on one design principle can cause new problems is designing with the mythical new user in mind. By "mythical," I do not mean that such a person does not exist, but that they are more of an abstraction than an actual demographic. For one thing, right now, few newcomers to Linux are likely to be completely ignorant of the desktop metaphor. Conversely, if the mythical newcomer does exist, elements such as GNOME's overview screen or Unity's launcher, with its mixture of favorite and running apps, are even more likely to confuse them than anything in GNOME 2.32.
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.