Coders & interfaces

I received a bit of feedback on one of my web pages (Guess which one)

The writer disagreed with one thing I said in particular: The bit that reads:

When somebody devotes a large chunk of his own time to create a piece of software, he will make the user interface (UI) as good as possible. The UI is a hugely important part of the software: there's no point having functionality if you can't access it via the UI. You might not know what it is, but there is always a reason why the UI works the way it does. That reason? Because it is the best UI the creator could create.

Before you insist that a more Windows-like UI would make the software better, bear this fact in mind: The creator of this software, a coder who, by definition, knows far more than you do about this piece of software, doesn't agree with you. He might be wrong, but the odds are against it.

He essentially was of the opinion that coders make awful interfaces, and that a coder's idea of a good, simple interface was an end-user's nightmare.

I disagree, as I said in my reply, quoted below for the interest of anybody who's interested:

Your points are all completely valid and accurate, but irrelevant to the point I actually make in the article. Your stated definition of a good user interface is exactly the one I address as a problem in the article: The definition of "User friendly software", which has become a synonym for "easy to use immediately without any prior knowledge"

Undoubtedly, a coder who sits down to write a piece of software for text manipulation will write a piece of software that a "typical" user will find horrendous to use. This is perfectly illustrated by vi, clearly a coder's text editor, and absolutely nothing like a non-coder's text editor, such as Windows Notepad. By "user-friendly" standards, vi is an utter loss and worthless as a text editor. And yet it's still in widespread use today, gaining new converts (such as myself) as well as keeping it's "old-school" users.

A coder who writes a piece of software for a task writes it to do so as efficiently and easily as possible. But because he writes it for himself, he has to take no account of "user friendly" concerns: He can happily say "'[ESCAPE] colon double-you queue [EXCLAMATION]' is a great way to save a file and quit the application!" His software will do everything it needs to do, with just a few keystrokes. It will also be an absolute nightmare for other users who don't know what keystrokes to use, but that's not his problem: He wrote it to do a specific job well, not to be intuitive and obvious to other people.

Or for a perhaps more relevant example, let's consider a simple, everyday task: Unzipping a multi-file archive.

On "user-friendly" Windows, this involves double-clicking the file. Up pops a new WinZip window, showing you all the files in the archive, the location in which it will extract them to, and some big, easy-to-understand buttons. To extract the file, you click the "extract" button, and with just one or two more mouse clicks, you're done.

Sit a "user-friendly" addict in front of a Linux shell and tell him "Unzip that .tbz file" and he won't even know where to start. Even if you give him the hint "Use 'man' for help and the unzipper is called 'tar'", how long will it take him to work out that "tar xvjf filename" is the magic combination he needs?

By a "user-friendly" definition, tar is a complete failure: It's a coder's unzipper, and unsuitable for "user-friendly"-demanding end-users. And yet it's still ubiquitous throughout the Linux world. Why? Because its nasty, unfriendly, failure of an interface is simply better than WinZip in many circumstances.

Consider, for example, you have a hundred Zipped archives, one of which contains a file you need - a possible enough occurrence if you run regular backups on your machine and accidentally delete a file you shouldn't have.

Using "friendly" WinZip, I may have a hundred double-clicks to do to find this file. I'm going to be there a long time.

Using our "failure", tar, I can find it with a one-line instruction by using tar's "list contents" switch and piping it through a "grep filename". I'm going to find my file in a matter of seconds.

So to return to my point: I never say, anywhere in the article, that a coder will create a "user friendly", intuitive, simple-to-use interface to his software. To do so would be laughable, and your point that coders make poor interface-creators is self-evident in a vast multitude of software.

Even in "user friendly" browsers like Firefox & IE, there is failure to make use of simple UI rules. The "Back" button is the most used browser button, and should therefore be larger and more obvious than the others. Instead, it's no more prominent than the rarely used "Forward" and "Stop" buttons. Why? Probably because coders use "Alt-Left" and never actually touch the "Back" button.

However, I do say, and I maintain, that a coder will make the user interface as good as possible. Not as friendly as possible, nor as intuitive as possible, but as efficient, powerful, simple, and effective as possible. An important thing to remember when comparing comemrcial projects to FOSS ones is that, typically, in FOSS the coders creating the software are almost invariably also the end-users as well. They aren't hired by another concern to create software that they will never use, they're creating software for their own use.

The coders out their working on Firefox are all browser-users. The people coding the Gimp are graphical designers who are adding the features they require in the way they require them. Gnome is being created by people who want a better Desktop. And so on.

So while it may be true that that the end-user should be the one who defines the interface, not the coder, in most FOSS projects, unlike most commercial projects, the end-user is the coder. That's an important factor to consider: If somebody is both a knowledgeable end-user and a knowledgeable coder, and he says "This is the best way to do it", he's in a position of authority on the subject that few others are qualified to match.

Easy to use and "ease of use" are two very distinct concepts today. It's easy to use tar to find that one file from a hundred archives, but WinZip is unquestionably the software that scores highest in typical "ease of use" comparisons. That's all well and good, but it completely ignores the fact that spending a little time learning how to use a more-efficient but less-intuitive application can result in saving time perpetually afterwards.

I work in an office where our job consists entirely of writing medical reports, which contain many frequently-used terms. By spending a half-hour teaching my technically-illiterate co-workers how to use MS Word's AutoReplace option to effectively write out long, frequently-used terms for them, I've increased the amount of work they can do in any given day. By making them invest some time in learning how to do something non-intuitive, they've made back a significant amount of time ever since. And will continue to do so tomorrow, and ever after.

An application's "user-friendliness" only ever matters at the start. If you have a totally non-intuitive, "unfriendly" piece of software, that only matters when you first put the users on it. After you've taught them how to use it, it no longer matters that it isn't friendly, because they can use it perfectly well regardless. If that application then means they save five minutes out of every hour because it makes up for its lack of intuitiveness by being superbly efficient at its task, then that application is the one that should be used, even if it does mean you had to spend an hour or two teaching them how to use it on day one. In under a week, that investment in time will have paid for itself. Considering an application's suitability for a task solely on the basis of how fast a user can start using it will result in bad decisions most of the time.

As a personal example, I recently wanted to design a new theme for a window manager: Icons, wallpaper, and all. MS Paint is unquestionably easier to use than the Gimp or Photoshop: I had to do a Google search just to find out how to draw a rectangle in the Gimp, for Heaven's sake!

But while I could draw a rectangle in Paint the moment I started out, how long would it have taken to create a graphic such as the wallpaper in this image:

with just "friendly" Paint? I'd have been there forever! By spending a little time learning to use less-friendly software, I accomplished a task in minutes that would have taken hours or just been downright impossible with friendlier but less powerful software.

So I must say again: I disagree that coders make poor interfaces. They don't often make good "user friendly" interfaces, agreed, but they make supremely efficient and functional interfaces. And that's what counts in Linux software.

If you doubt that fact, try a simple test: Go onto a typical Linux forum and ask "How do I unzip this .tbz file?" and see if you get pointed to tar, or to some user-friendly, GUI-touting unzip software.