Since 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 kde-look.org, 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.
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.
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.
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.
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.
Release early, release often. This is a popular motto for Free Software Developers. However, I do not really like it because it encourages developers to mark unstable software as a release. There is one thing that I consider very, very poor usability, and that is crashy software. It’s about reliability. If a program behaves nicely, and doesn’t crash on my system, I start to trust this piece of software, and I like to trust my programs. I can then happily recommend this software to friends, and they will be happy too, hopefully.
But if you really want to get your cutting edge software out, I recommend to use CVS as some kind of secondary release mechanism. Encourage your most enthusiastic users to check out from CVS, and they’ll happily comply and compile, but without the presumption of stability.
File Formats, Config Files:
One thing that should be considered carefully is the file-format for application data. That includes both, configuration data and user data.
Take, for example, Firefox. I installed the 1.0 Version, imported my Preferences from Mozilla, and after some days, I became aware that some sites were subtly broken. I did some research on the Net and found out that I had to delete my .mozilla file to fix Firefox, because the old preferences file was screwing up something. That’s poor usability too. This case actually describes a bug, but the point I am trying to make is, make sure that your file formats and configuration data is at least forward compatible.
Some Words on Documentation: avoid lengthy complicated instructions. Nobody likes to read it. Provide simple examples and provide commented screenshots if the application includes a GUI.
If your software requires lengthy descriptions, rethink your front-end design. Where the front-end includes plain text configuration files and APIs (See Writing Small Software by Felix von Leitner) this of course depends on the type of application.
One common complaint about Linux is that binary packages from one distribution are not compatible with other distributions, and there is a need to create a Technology to circumvent this problem. Well, a solution exists, it’s named “static linking”. For those unfamiliar with this term, it’s a means to include parts of an application normally distributed as shared libraries into the application executable. Some people dislike this solution because of the additional overhead if two programs statically link to the same library. However, there are cases where the tradeoff is insignificant compared to the advantages. With careful selection of libraries to compile into your binary and some serious testing of your binary packages, it is possible to create a program that works well on the vast majority of the standard Linux distributions.
Vendors of closed source software do this all the time, and it works surprisingly well. The only thing that’s missing in the Open Source World is an awareness of the importance of high quality binary packages.
Test your Program on different Machines, Distributions, test whether they import old File formats, whether the preferences file from the previous version screws it up.
Test your binaries, if you really can’t make them work on a specific Distribution, provide a note on your Download Page.
Keep your Website up to date. If you’re too lazy, provide yourself with an easy to use web-based tool to manage your project homepage. I’d recommend a wiki based System for this, for example PmWiki. Make sure that you provide a decent selection of screenshots at every new release, I love screenshots, and so do a lot of other people I suppose.
Free Software Advantages:
There are of course areas where Free and Open Source Software provides a better usability then others. One such example Is that most applications are available for multiple platforms. I appreciate it actually very much to have all my commonly used applications ready whenever I have to work on a win32-based machine. I recommend everybody to recognize this as a key-superiority of Free Software and encourage everyone to provide win32 binaries of your applications.
Why should you care about Usability? Because it improves the quality of the product. If you do not care for quality, maybe you should ask yourself why do you actually publish software. A severe usability problem should be rated as important as for example a memory-leek in your program, it’s a simple “Must fix it”!
About the Author:
Richard Spindler is a computer-science student, usability, security and free-software advocate. Homepage:http://ggseq.sourceforge.net/
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.