posted by Richard Spindler on Tue 8th Mar 2005 19:07 UTC
IconSince usability seems to be a major topic on the OSNews forums, I think time has come to clarify some common misconceptions. Usability is not about selecting the fanciest Theme from, it's not about 'Reading the F*** Manual', it's not about having all application share the same looks, it's not about nice front-ends to obscure command line programs, it's not about newbie-friendliness, it's not about apt-get install foobar and it's not about setup.exe.

Whenever I read comments that suggest something of the above, It makes me believe that the author has only a very basic and incomplete idea of usability.

Unfortunately, it's not that easy to explain the term usability. I'll try anyway. I'd say that usability refers to whether a certain Product, software or not, enables a user to perform a certain more or less well defined task. It's not that one single feature decides whether a product has "usability" or not. Usability is more about the overall feature set, appearance and above all, usefulness of the Product.

Throughout this article I'll briefly explain common misconception that usually appears when the discussion turns towards usability, then I'll try to identify some usability problems that might not be obvious to the average developer, and as a conclusion I'll propose some suggestions that will hopefully overcome the shortcomings of today's Software.

Common Misconceptions

The problem of "usability" should not be confused with "User Interface", because there is a set of usability problems that can not be solved on the UI-Level, take for example network browsing (think of Apple's Rendezvous). This has to be implemented on a rather low-level network basis. So this time we need a network engineer to solve a usability problem.

Novice Users:
Among the most common misconceptions is that usability engineering aims towards the novice user. Software with bad usability is actually more of a hindrance to advanced users, because while a new user can learn complex software, an advanced user will be saddled with broken usability for years, hindring their job. Certainly the advanced user might be able to master obscure, overly complex, 'not self-explaining' software. This may be true, but certainly he has more interesting ways of spending his weekends.

Front ends:
Another thing that pops up randomly as soon as the magic word usability flows around is: "Just add nice front end to cdrecord/cups whatever" (see ESR's Cups Rant) Well, how good is a front end if the back end is broken? Let me give you an example: Do you know a gui front-end that discovers Windows and Samba Servers in your LAN quickly and reliably, without starting obscure services, setting strange options and requiring you to hit the "refresh" button ten times? The answer is: there is no such thing. It doesn't even work in Windows. Have you ever read the Samba Documentation on how to set up network-browsing in your Windows network? Don't even try. The whole protocol seems to be so broken and overly complex that it can't be fixed on the implementation level. I admit that some of these features might be necessary to run a network with a hundred machines attached. However I do not care, as it does not work for my environment therefore it's broken. In contrast, have you ever used a Apple Rendezvous-based Network? Surprisingly, it works, it's fast and it's reliable. In conclusion, I think this proves my former statement: if the back-end is broken, the front-end won't fix it.

Common Problems

Another non-UI Usability Problem is the issue of deployment. Think of "how good is program if you're unable to install it on your machine?"

Under Linux, people tend to use a so-called package system that integrates a lot of different applications into the distribution. This is a really nice feature, however, people complain that it's next to impossible to exchange packages between distributions, and therefore it's difficult to install a piece of software and resolve dependencies if it's not integrated by your distributor.

Actually there is a reason why these package systems exist, and why it's a good idea for certain applications and why it's not so good for others. For example, a typical server application like Apache needs to be integrated fairly deep into the OS. There might be cron jobs referring to the application, config files for logrotate have to be setup, init-scripts have to be added. This is a task that might be difficult for a generic installer, therefore it's good idea and a usability improvement to handle this at the package-system level. Other Applications like Firefox or OpenOffice, on the other hand, are more or less independent from the underlying OS. Therefore Applications like these should, and some do, provide standalone installers.


One thing that severely decreases usability on some occasions is unneeded complexity in a solution to a problem where a simpler solution would be possible. This is usually an issue that is invisible as long as everything works as intended. However, as soon as something is broken, it becomes apparent that it's increasingly difficult to fix it, as the underlying system is too complex. For example, take Slackware; indeed it requires a fairly experienced Linux user to keep control of it, but it's fairly easy to fix if something is broken. So in one sense Slackware is not usable because of its high barrier to entry, but in a more important sense it exhibits good usability because its configuration is straightforward and fixable for its target users.

Table of contents
  1. "Usability, Page 1/2"
  2. "Usability, Page 2/2"
e p (0)    132 Comment(s)

Technology White Papers

See More