Danny's Lab

Engineering the World

The Linux Usability Problem: How to improve the Desktop

Published on: Oct 3, 2010
Reading time: 7 minutes


In this article, I'll discuss some of the issues surrounding usability of open-source software and propose what I hope is an elegant solution. I'll use GNOME as an example because that's what I'm familiar with the most, and is my personal preferred Linux desktop.. However, keep in mind that my comments are not specific to the GNOME project.

A bit of History

Ever since around 1995, when Linux and the OpenSource movement was just starting to get popular, there's been a big push towards making software more useable. They've certainly made huge strides in that area since then. Anyone who still remembers the Athena widget set can probably attest to that (no disrespect to the authors of Athena, but it certainly was feeling a bit dated at the time). Indeed, when GNOME 1.0 came out, it was a huge blessing for the Linux Desktop. For the first time ever, we had nice fonts, pleasing icons, and a consistent feel for the whole desktop, not "just another window manager".

In addition, GNOME 1.0 seemed to have all the features, I (and many other Linux users) enjoyed. It made life easier for us while at the same time being relatively pleasant to work with. However, when GNOME 2.0 (or perhaps 1.2; it's been a while) came out, I was rather shocked. The fonts were certainly even nicer than before, at the cost of noticeably more horsepower. But it started lacking a lot of features that I enjoyed, and the default settings seemed to be ones that no one liked. This trend seemed to continue with every release more useful features being removed. Amongst my peers, we had a running joke that GNOME was not only copying Microsoft Windows, but they were copying all the bad features of it.

The GNOME developer's rational, however, was that they wanted to make the software more accessible to the average user. A noble goal to be sure. But clearly there was an underlying disconnect here that seems to have stuck with the project to this day. (From what I've seen on the soon to be released 3.0, it's quite possible they've remedied my issues with it. But I believe the points I'll make below will still stand).

Know Your Customer

All software is developed with the intent that someone out there will use it. However, for development efforts to be best directed, it's useful to understand two key things:

  • Who is your customer?
  • Who is your end-user?

These aren't always the same. One could argue for example that for Apple, they're the same (predominantly home users and specialized small businesses), but for Microsoft, the customer is OEMs, while they're end-users are businesses and home users.

For Open Source Software, specifically Open Source Linux Software, the answer to these questions isn't entirely obvious. And how we got here is both unique and interesting.

Before Linux, most Open Source software was just that. Independent software that people could install on their Unix systems (typically one of big irons like IBM, Sun, HP, etc. with the occasional DOS/MS-Windows support thrown in as well).

However, when Linux came about it became too cumbersome for people to not only load their operating system but then also install all the applications they wanted on top of that. In addition, to help attract additional users and developers, it was useful to have a "demo" installation that showcased everything it offered. Thus was born the Linux Distribution. SLS[wikipedia], I believe was the first of it's kind. For the first time ever, people could have not just a working shell and compiler but a full X-Window system complete with "standard" applications.

Soon after came the Slackware distribution, largely to cleanup issues with SLS. But eventually RedHat, Debian, and a host of variations came about. But what's interesting is what started happening. The reason all these distributions occurred was because they were all trying to solve different problems. Mandrake, for example, was largely (in the beginning) and optimized version of RedHat. But we have distributions now aimed specifically for the scientific community, academia, musicians, etc. To date there are easily hundreds of Linux distributions[wikipedia].

These days, most Linux users in fact don't download and compile software. While it's still possible, it for the most part just isn't necessary. So then, to answer our initial question: Who is our customer? In the case of GNOME, it's the Linux Distributions.

We must also take care in identifying the end-user. In this case, we actually need to split it into two parts:

  • Who are our current end-users?
  • Who do we want our end-users to include?

In the case of Linux Application software, especially in a high profile project like GNOME, you're in an interesting position. Like it or not, Linux is still for the most part a niche OS. Your current-end users are for the most part are going to be relatively technical people or people that are willing to put up with a higher learning curve the "average Joe."

However, in the case of GNOME, they wanted to extend their end-users to include "the average Joe." But you have to be careful that in doing so you don't alienate your current users. So what are you to do?

It's in the Policy

In the case of GNOME, they decided to side with their vision of the "Joe". It got to the point where GNOME really wasn't that pleasant to use. Personally, I could live with it, but I started to realize that I didn't dislike Windows as much anymore. The problem I realized that I was equally irritated using GNOME and MS-Windows. Neither really let me do what I wanted as conveniently as I wanted. And there really isn't much of an alternative. KDE suffered from different problems, but I believe rooted in the same issues with direction and focus. So what happened? Numerous Linux developers, while still Linux fans at heart, went to Mac OSX. But I digress.

The heart of the problem was that the GNOME developers decided on Policy issues. However, in most networked environments I've worked in, it's the network administrators that really want to decide what the policy is. And that's one of the reasons why I would choose Linux over MS-Windows when I'm in those roles. Linux generally makes it easier for me to implement those policies across the board. However, GNOME didn't do that. They didn't give me the choice, they decided for me.

But to their credit, this was a conscious effort on their part. They realized one of the big challenges in usability was too many options. The Sawmill window manager is an excellent example of this. This window manager was one of my favorites and I still miss it to this day. But even I have to admit it had way too many options for the typical user. Their mistake was in falling for the mantra "you can't satisfy everyone". So they ended up trying to satisfy a mythical person that they hoped would eventually exist.

The Solution

So how do you resolve these issues? How do you provide the features that your end-users want, given that you have such a diversity in users, while still making things easy for "Joe"?

The key lies with the customer. Remember, one of the things that developed with Linux Distributions is that each Distribution tailors their software a bit to fit with their targeted audience. So as a software developer, you must recognize that the decision as to whether folders should open a new window when you click or use the existing window is a policy decision. The software developer should not decide that, as that is rightly an option. It's the people who decide the policy that should have control over that.

So what specifically should GNOME do? What's needed is a Policy Engine. Something that lets someone decide details like that and whether the user has the ability to view/modify these things easily and what default settings to use. These should be in an easy to setup configuration file.

The natural extension of this is that Distributions with a general audience will now have the ability to offer several variations, perhaps a Beginner/Intermediate/Advanced mode. Or perhaps defaults for users migrating from MS-Windows or MacOSX.

So now you have end-users, as varied as they are, who get a product that's useable to them. And your job as a software developer is simpler because you're not trying as much to guess on which direction will satisfy the most users.