Revolutionizing desktops without causing user revolts
Off the Beat: Bruce Byfield's Blog
The last few years of development on the free desktop have been instructive. First, KDE stumbled and recovered with the KDE 4 series. Then, this year, GNOME and Ubuntu introduced radically new desktops. In each case, user complaints immediately poured in. Although both GNOME and Ubuntu seem determined to ignore these complaints and continue on their course, I keep wondering: could the disastrous receptions have been avoided?
The question is worth asking. On the one hand, free desktops need to innovate steadily, both to attract developers and to stay competitive with proprietary rivals. On the other hand, although many developers disregard users, unsatisfied users may move on and risk reducing a desktop project's influence.
So what can be done to avoid future train-wrecks? As a sometime interface designer and a long-time observer of the free desktop, I make the following modest proposals, in the hopes of being constructive rather than simply critical:
Don't change too much too quickly
A significant number of users are conservative in their habits. Even changes that give new flexibility to their habits, such as KDE's Folder View, may be rejected simply because they are new. Whenever possible, pace the changes, and spread them out over several releases rather than introducing them all at once.
Build user testing into each stage of the development
User testing tends to be sparse on the free desktop at the best of times. But doing it only near the end of the development cycle doesn't provide the necessary feedback. Nor, for that matter, does testing only the interface you want. In either case, developers are likely to be too committed to their plans to alter them greatly.
Whenever possible, leave legacy features in place
No matter how inspired a new design is, some users will always prefer the familiar. If you give them both the new and the familiar, they'll be far more likely to explore the new than if they're complaining about how the project took away features they consider essential. One reason why KDE recovered from its initial stumble is that, while the default menu changed, you could revert to the classical menu. Similarly, if you didn't like the new icon-based System Settings, you could revert to the old tree structure.
Don't impose work-flows from above
The GNOME 2 and KDE 3 series differed greatly from each other. However, one characteristic that both series had in common was that users were not constrained by design in how they could work. If they wanted desktop icons, they could use them; if they preferred using the menus, they could do that, too. If they wanted to load the panel with applets, they could; conversely, they could leave panels applets.
By contrast, GNOME 3 and Unity pressure and frequently force users to work in the way that developers think they should. Under the circumstances, it shouldn't be surprising that some users will find the interfaces restrictive.
Beware of designer fads
Usability and interface design are usually discussed in articles with an academic tone and format. When you first discover them, you can easily over-rate their authority. However, the truth is, these areas of study are as subject to fashion as anything else; despite the apparent objectivity of design studies, in practice you can usually tell within a few years when an interface was designed by the features it uses, such as tabs or combo boxes. Designers need to consider if the elements of an interface are truly useful, and not just throw them in because everyone else is doing so
Don't view function and aesthetics as separate
One of the surest signs that design decisions are being made by amateurs armed with a little knowledge is that an interface choice is defended purely on aesthetic grounds. An interface design should not be added because it is abstractly beautiful, but because it enhances a function.
Users, on the whole, have only a brief appreciation of beautiful design if it doesn't make a function easier to user. In fact, forced to choose between aesthetics and function, most will probably choose function every time (which is why, for instance, people are enthusiastic about the ebook manger calibre: the menus may be ramshackle, but calibre contains almost every function to do with ebooks that anyone could want).
If a design is too noticeable, then maybe it's too clever to use
An effective interface is one that allows users to get on with their work without noticing the design after they first time they use it. An interface that users continually notice, either because of the eye-candy or its restrictions is one that gets in the way of ordinary productivity.
You might say that such interfaces are the equivalent of a book that uses a dozen different fonts per page, or an online document that uses a variety of background colors and text frame layouts. Just because a widget set allows you to do do new things doesn't mean that you need to use all of them at once.
Talk to your readers as you work
Don't spring radical changes on users without any preparation. Blog about what's happening throughout the development process, and be prepared to alter plans after hearing feedback. Users who know what's happening, and even feel a small part of the process are more likely to accept changes.
There may be other guidelines that could be added to this list. However, if you keep aware of these seven, I suspect that it would be hard to create anything that would cause serious complaints without being aware of what you were doing.
Just as importantly, with these guidelines, developers might actually stand a chance of developing interfaces that everybody can use, instead of interfaces that they think we should use.
desktop powerI think if you read point “1. Getting your script ready” at the top of this blog post, you will probably find the answer you are looking for.
<a href="http://www.cabletiesandmore...tribution.php">desktop power</a>
GNOME3 unusableThe latest GNOME 2 has its short comings, but it is the best desktop environment for serious work in the Linux world. One of the niggles is that your desktop gets corrupted if you attempt to have 25 virtual desktops, as I had grown use to and had found suited my work flow patterns involving private, work, and local system administration activities - especially as I tend to remain logged in for several days at a time. The spatial of GNOME 2.4.2 was good: directories remembered their size and location, but did not hang around unwanted if you clicked on a sub directory.
However, GNOME 3 is essentially unusable for serious work. They talk about distract free computing, but G3 has no way of making the desktop clear and uncluttered. With G2 you could have a bland background and have the panels hide themselves unless needed. G3 does not allow you to have panels where you want them, nor to place applets where they most suit one's manner of working. Not to mention breaking key apps like calendar: I have friends and relatives around the world, so being able to have clocks for several cities and knowing when they had daylight was incredibly useful under G2, but not in G3.
The xfce desktop environment is better than GNOME 3, but not as good as GNOME 2.
GNOME 3 is effectively defective by design - it has been Applefied (having its design based on treating users as inferior beings that must accept whatever the UI gods deem to be best for them irrespective of user needs, a la Apple).
Let's re-invent the wheelUI's are like shell's, every graduate student in CS thinks they have to do their own. Now having worked with Bash, Korn, tcsh, etc. I can tell you they all do the same thing, just each one is a little twist different different way. And so we should not be surprised that the current fad will be for every QT, XWin, MSWin, etc to think they have a better idea. Every generation of new software engineers has got to do it their way even if functionality wise they add nothing. Unity revision 1 was a perfect example. Se la vie!
Whoa, Adam WilliamsonAdam cites a number of technical reasons for why things from Gnome2 were not ported forward into Gnome3.
Of many things computing, you seem to have brushed aside the idea that UI means USER interface. Users depend on OSes to get USEFUL work done. When you screw around too much in one step resulting in a buggy and incompatible USER interface you get USER revolt. If you're only making Gnome for the beauty of making what YOU wish to make, then I think you miss the entire issue of making a product that folks USE and depend on.
If folks want to develop for their own aesthetic they should do so where it won't hurt the actual professional use of the operating system. Extend the current system to include what you like without destroying what folks use. Make yet another word processor or yet another music player or editor. Don't screw too much with folks' livelihoods. If you had redesigned the automobile interface (to take up an analogy made earlier here) to make it totally different and slightly buggy then people would DIE because of this hubris. For the case of the UI, making it totally different and buggy just infuriates folks who have something to do and find the new mess gets in their way for no apparent useful purpose.
So, for me, what I've seen following the tales of this pain inflicted on Ubuntu with unity and on Gnome3 and earlier on KDE4 makes me concerned that the lack of user orientation of UI developers is making my long Linux experience suddenly risky.
I want to be free to choose useful interface developments when they seem ready for prime time. I do not want to be forced into them prematurely in a way that interferes with the smooth workflow that I need from my Linux desktop.
UIMy computer is like my car, I use it every day to get things done. The basic car controls have not changed for at least the last 80 years. The gauges are moved around from model to model, year to year. There is more or less trim, etc. but the basics are always the same. Steering wheel, shift lever (either on console or steering column), gas, brake and clutch turn signal all in the same place. They don't mess with the basic interface. I want the same thing from a UI. Ford, GM and Toyota don't move that stuff around, they don't have per manufacturer interfaces. You can get in any car and drive it. You may not be able to turn on the radio, but you can drive the damn car. Standard interfaces that all work, more or less the same way and don't change over time is what we need. Not this constant churn.
Why I switched from GNOME 1.x to KDE 3.x back thenWhen I first tried out KDE, I didn't like it. I found GNOME 1.x more in line with the way I generally work, so I stuck with that and rather liked it.
That all changed when KDE 3.0 came out. I think it was Slackware 8.1 that had it, and it was also my first serious amount of time with that distro. KDE 3.0 rocked! It did everything I needed to do and a lot of what I wanted it to do. As it advanced from 3.0 to 3.5, it simply got better and better, adding more functionality to an already very-useful core desktop. Like Linus, I found GNOME 2.x rather restrictive by comparison. KDE 3 made Slackware really fun to use.
However...then KDE 4 came out. It was so radically different that I had to re-learn how to use it. It didn't help that the desktop environment was totally buggy (I see they've fixed a lot of that by now). But unfortunately, the smooth flow that KDE 3 gave me is gone with KDE 4. It was like going from Windows XP to Vista or Windows 7. There is still no equivalent yet for kprinter, which, since many people use GNOME apps on KDE (GQview and Evolution, for instance), can cause a usability issue. Yes, *I* can figure out a workaround, but most people aren't systems engineers like I am, let alone an actual technical whiz like Linus. Most users can and do have problems with this.
I have actually gone back to the GNOME 2.28 that comes with CentOS 6. On the new Slackware box that I'm about to build, I'll download Trinity ("KDE 3.5.11" and use that. Compiling KDE 3.x is actually pretty easy. The fact that I can do that at all speaks to why Free Software is a Big Deal.
The desktop projects would do well to consider Mr. Byfield's advice here.
A goal issuewhat recent change has shown *again* is that developpers care mostly about their own needs: having something fun to code, which means usally coding something new whereas users don't want something new: they would prefer to keep their existing desktops but with bugs fixed.
You can talk all day about what should be done, but given that users are not paying the developpers this is unlikely to happen..
gnome2We have to keep articles like this one in perspective, move towards uniting those looking for an alternative. It's high-time we form a foundation that will cater towards what we have been use to, a gnome2 classic desktop. And this need be done with money & organizational skills--should be fairly easy. I'm not against complaining, but providing a solution afterwards is what we need.
JustAnotherOption:Try 'start key, type "fire", enter'.
Bugs, Bugs, BugsMy biggest issue with the newest desktops has to do with bugs. All of the new desktop environments crash, won't run on slightly older hardware, eat major amounts of RAM, and interfere with the performance of applications. I have tried every version of KDE 4.X, along with Gnome, and Unity and have found them to be lacking in stability.
Aside from the bugs, I find that I have to do more to get less out of these environments. For instance, if I want to start Firefox from Gnome 2.8, KDE 3.5, or LXDE the pattern is:
Click -> Move mouse up (or down) -> Move mouse over -> Click
Each of the new environments involves a process similar to this:
Click -> Move mouse into text box -> Type "firefox" -> Press Enter
or worse if you don't remember the exact spelling of the application (Nautilus). The menus are too nested to find anything in a reasonable fashion.
At one time, I was excited about KDE 4.0 being 20% faster than KDE 3.5. I was also enthused about Gnome spending extra time to make 3.0 a "nice" experience. Unity was heaped upon us. As it is, I can't wait for the transparency effect and 3d windows to go away so I can get to work.
sudo apt-get install lxde
Slower pace of changes doesn't helpOverall I agree. Except one thing.
> Don't change too much too quickly
This is wrong take on the problem. It is not about slow introduction of changes: even if one slowly dismantles user's work flow without providing a viable alternative, the end result is the same.
The way the DEs go about right now, they turned into monolithic dinosaurs which can't make a step without squashing somebody. That got to go. Developers should be given the choice back - to be able to provide the users with the choice too.
What I like the most about Linux is the choice. Empowering user by providing him with tools which are best fit for the task at hand. Yet, DEs (notably Gnome) adopted the "one size fits all" strategy.
I think we come to the point where DEs need to redo their architecture: move from monolitic DE to the split foundation and chrome. Users do not care how precisely the list of files and directories is actually fetched from OS (the foundation's job) - but they would feel strongly about how the list is displayed (the chrome's job).
By moving all the tedious work to the foundation layer, one can allow the chrome layer to be thinner, to be simpler to implement and (the main goal) make the chrome easily replaceable/rewritable/switchable.
That way, I hope, user can be given back what he is slowly losing - the choice. Because the split done well would allow developers to have the choice, using the foundation, to write a new chrome easily: to test new ideas and concepts and so on. And users would be able to install it easily, without needing to fetch another gigabyte worth of packages.
Responding to Adam WilliamsonWe really have two things going on here.
Firstly, you say that Gnome 3 applets were buggy and there was much wrong with the implementation.
To some extent I would agree with that. There were many things in the Gnome infrastructure requiring rewrite and bug fixing. I don't think anyone would disagree that fixing bugs and rewriting to be technically superior is a laudable aim.
So why didn't the Gnome developers just do that? The answer? Boring.
A huge number of users of Gnome 2 (myself included) LOVED the gnome DE experience. I could certainly do without the bugs and some of the klunky behaviour. But you don't need to fundamentally change the entire desktop experience to remedy that.
Could I ask exactly how many users of Gnome expressed a desire for a totally new desktop paradigm for Gnome? Could I also ask how many Gnome users asked for the bugs to be fixed?
Secondly, we have Gnome Shell. For some users this might be a useful piece of software. But it would seem that most Gnome users (all that I have talked to in fact) do not like it, it is needlessly restrictive and radically different from the old DE for no obvious reason other than it is different. It is SO disliked that one of the main hot topics of conversation in the Linux world is "What will everybody use, now that Gnome is unusable?". I kid you not. Gnome is not alone here. Lots of users are engaged in similar discussions about Ubuntu and their Unity interface. "Can we turn to Linux Mint for some sanity?" I hear people say. "What about Trinity? Is it worth a try?"
For me however, I feel bitterly the betrayal of Gnome to a Desktop Environment that I have lovingly used for a number of years now. I would love to continue using Gnome 2 because, believe it or not, it is JUST what I need. Over time though, that will become less and less tenable as it falls by the dependency wayside.....
functionality and aestheticsI agree entirely with the author on choosing functionality over aesthetics. That is particularly true when discussing gnome3. On one of my systems I can use gnome3 with the new interface and with some tweaking I'm not displeased. On all the others the graphics card requirements cause gnome3 to be unusable and the only way to use gnome is in fallback mode. If you haven't seen fallback mode, it's a vastly inferior copy of the gnome2 interface. Those other systems have no difficulty running either kde4 or gnome2.
The problem is...They both went to fix something that wasn't broken.
Too obvious ;-)Nice post, but too obvious . I totaly agree, with emphasis of not taking care of users by developers.
The problem is KDE4, Gnome3 and Unity already happened and screwed big time. As the matter of fact KDE4 convinced me that any open-source (front-ends, not libraries) involvement (except for your own software) does not make any sense and helping in any way is just waste of time. KDE4 (as many other projects) is purely for developers fun, not about users.
It was good experience after all, I stick with KDE3.5.10, and turned into more selfish user, a.k.a "I don't care".
Revolutionizing desktopsNot surprisingly, Bruce, I agree by and large with your post. I think sometimes developers get so caught up in their work, and all the wonderful new features they're able to create they forget why users are using what they develop. Users are unlikely to be enthusiastic about having to learn new ways to do what they've already learned to do, and this is especially true if in the process of creating something new the developers leave out features the users have come to rely upon. The other danger is that not all the pieces will be worked on at the same time.
The creation of KDE4 offers some perfect examples. To many users of KDE3, KDEPIM was the heart of KDE3. It offered a robust, complete, integrated email,newsreader, news aggregator, notepad, and calendar that worked well together. Yet when KDE4 emerged it didn't even include KDEPIM at first. And when KDE4 finally did include KDEPIM it was, and is still missing vital features like distribution lists that work.
To me this demonstrates not only that KDE developers don't understand the needs of users, but that they don't care about users at all. Those who complained about the lack of features were basically ignored, or worse, called whiners or told to f off.
I like many of the new features of KDE4. I can live with the new menus and the flashy rotating windows, even though I don't feel they help me do my work any better. But I'll always resent the extra work they've put me to, and the abandonment of features that helped me do that work.
I simply hate themgnome3 kde4 unity i tried but they are useless.
while kde4 (unless you try it on a netbook) at this point is actually highly customizable, it's too much pain to do so. it feels like the boss has to speak with every worker in person to get the message thought.
i won't repeat all things they did wrong in they desktop-design, pretty much everything has been said already and was ignored.
i my opinion, the first thing done wrong was to combine window task tabs.... must turn that thing off to work efficient. a innovation would have been if i could open 100 windows and still know instantly what the content of the window is by its tab. well, "..." isn't very informative when the tabs get to small for names and a preview picture is pretty useless too, if you have a lot of content that doesn't differ much.
Interesting, but...Looking at this from the GNOME 3 perspective, I think some of these points are simply wrong, and some of them - though you write as if they weren't observed - actually were.
"Don't change too much too quickly"
this is really one of a set with:
"Whenever possible, leave legacy features in place"
they're nice aspirations, but they have significant problems. My favourite example is the whole business with applets.
GNOME 3 drops the GNOME 2 panel applet interface. Why? Well, first the devs looked at the interface and noticed there were significant technical problems with it, which meant it would need an overhaul. It was also clear that GNOME 3 was going to be customizable with a different approach - extensions.
So, the decision was simply to drop the applet interface in favour of extensions.
Would it be nice to do a gradual changeover, with an overhauled-but-mostly-API-compatible applet interface available alongside the extension interface? Well, in some ways, sure. But that would involve investing a lot of developer time - a very limited resource for GNOME - into maintaining a legacy interface which was planned to become obsolete in a short time, and substantially increase the complexity (and hence susceptibility to bugs) of all the code in question.
It's not a straightforward 'win', in other words. It's worth noting that gradual change while maintaining a lot of compatibility with the old way of doing things is the way Microsoft does stuff. It's why you can still run apps from 1991 on Windows 7, but on the other hand, it's also a lot of the reason for a lot of the bugs that exist in Windows, a lot of the reason why Microsoft needs such a huge development staff yet innovates so surprisingly slowly, and a lot of the reason why Windows is such an unnecessarily complex platform.
Is there a benefit to this approach? Sure. Are there costs? hell yes. Do the costs outweigh the benefits for a small project which wants to maintain code efficiency and maintainability while making major changes? Arguably, yes.
"Build user testing into each stage of the development"
This was done, to a pretty laudable extent, I think. Fedora and other distros have had GNOME Shell available as an optional interface, through a simple GUI wizard, for many releases; this was quite often promoted as a feature, and written about by journalists. jhbuild has been available and well maintained as a relatively easy way for moderately-skilled, interested parties to stay up to date with the absolute bleeding edge of development. It seems to be fashionable to claim the GNOME team developed GNOME 3 in some sort of secretive environment and then dumped it on people suddenly, but it's really not the case.
"Don't impose work-flows from above"
This is another one I've written about at length elsewhere. It's based on a false premise. Does GNOME 3 impose a workflow from above? Well, yes. Does every other desktop ever written? Yes.
There's that old trick where you ask someone if they'd have sex for ten million dollars, and if they say yes, you say 'well, now we know you're a whore, so let's find out the lowest price you'll give me'. This is sort of like that: it's a question of degree, not of absolute principle.
Imagine the perfectly configurable desktop, which you can change in absolutely any way you like. What is it? Well, it's your text editor of choice and a copy of gcc, is what. The only way to have a perfectly configurable desktop is *to write it yourself*. Is GNOME 2 more configurable than GNOME 3? In some ways, using some approaches to what you define as 'configurability', sure. Is it really perfectly configurable, in that it imposes no restrictions on what type of a workflow you want to use? Heck, no. No desktop is. In much the way that the only way to have complete power over how your system works is to build your own distro from scratch, and using *any* distro 'restricts your choice', so using *any* pre-built desktop 'restricts your choice'. It's only a question of which desktop's restrictions match your workflow the best. Is there somewhat of a change between GNOME 2 and GNOME 3 there? Yes, but then, how could there not have been? The whole point of GNOME 3 is to overhaul the desktop in what its designers feel is an improvement on the previous design. If GNOME 3 imposed the exact same restrictions on the user workflow as GNOME 2, then it would effectively be the same desktop. It wouldn't have been overhauled at all. The fact that it's a re-design *inevitably implies* that the required workflow changes.
(There's also an element of the previous point, here. Take your 'desktop icons' idea. Desktop icons simply do not fit into GNOME 3's design at all. Having an option to allow them would involve investing a lot of development resources into maintaining a legacy design which would conflict completely with the intended workflow of GNOME 3. To make a bad analogy, it would be like designing an F1 car with the option of a fully-automatic gearbox in mind: you'd be wasting effort and making design compromises in order to allow the driver the option of doing something which the product is fundamentally not intended to do anyway.)
"Beware of designer fads"
this one I agree with. I think it's true that, in general, people who claim to be experts on interface design usually are guessing almost as much as the rest of us most of the time. I do think the GNOME design team could bear to keep in mind that they just might possibly be wrong a bit more often than they do...
"Don't view function and aesthetics as separate"
This is mostly true, although it's easy to underestimate the impact which a pretty, smooth interface has on the user's experience. (Many people will swear blind that iOS does some operations faster than Android when actually it does them slower, because iOS does them more prettily and more smoothly). But I'm not sure it's something that GNOME or KDE 4 have actually got wrong, anywhere. Unity I still haven't run, so I don't know about.
"If a design is too noticeable, then maybe it's too clever to use"
Ditto with the above.
"Talk to your readers as you work"
Again, in the GNOME case, I think this is done very, very well. All the lists are open. The GNOME developers and designers blog incessantly - planet.gnome.org is always active. I follow the news just by reading general news sites and planet.gnome and I don't think I've ever been completely surprised by a change to GNOME, I've always known about it ahead of time.
Unity, Gnome 2 and Impact on UsersAll very important points.... I think with Ubuntu ignoring the majority of the complaints about moving to Unity and not offering a Legacy/Classic Desktop going forward will itself alienate developers. After all Linux Developers generally don't like much GUI if any so hopping from Gnome 2 to Unity is bad omen in my opinion and I don't think I have met anyone who has liked Unity over Gnome 2.
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?