Windows, Linux, Cars and Lego's (Part 4 of 5)
Problem #4: Designed for the designer
In the car industry, you'll very rarely find that the person who designed the engine also designed the car interior: It calls for totally different skills. Nobody wants an engine that only looks like it can go fast, and nobody wants an interior that works superbly but is cramped and ugly. And in the same way, in the software industry, the user interface (UI) is not usually created by the people who wrote the software.
In the Linux world, however, this is not so much the case: Projects frequently start out as someone's toy. He or she does everything himself or herself, and therefore the interface has no need of any kind of "user friendly" features: The user knows everything there is to know about the software, he or she doesn't need help. Vi (MS-Word like) is a good example of software deliberately created for a user who already knows how it works: It's not unheard of for new users to reboot their computers because they couldn't figure out how else to get out of vi.
However, there is an important difference between a Free & Open-Source Software (FOSS) programmer and most commercial software writers: The software a Free & Open-Source Software (FOSS) programmer creates is software that he or she intends to use. So while the end result might not be as 'comfortable' for the novice user, they can draw some comfort in knowing that the software is designed by somebody who knows what the end-users needs are: He too is an end-user. This is very different from commercial software writers, who are making software for other people to use: They are not knowledgeable end-users.
So while vi has an interface that is hideously and unfriendly to new users, it is still in use today because it is such a superb interface once you know how it works. Firefox (IE like) was created by people who regularly browse the Web. The Gimp (Photoshop like) was built by people who use it to manipulate graphics files. And so on.
So Linux interfaces are frequently a bit of a minefield for the novice: Despite its popularity, vi should never be considered by a new user who just wants to quickly make a few changes to a file, use Open Office Writer (MS Word like). And if you're using software early in its lifecycle, a polished, user-friendly interface is something you're likely to find only in the "To Do" list: Functionality comes first. Nobody designs a killer interface and then tries to add functionality bit by bit. They create functionality, and then improve the interface bit by bit.
So to avoid #4 issues: Look for software that's specifically aimed at being easy for new users to use, or accept that some software that has a steeper learning curve than you're used to. To complain that vi isn't friendly enough for new users is to be laughed at for missing the point.
Problem #5: The myth of "user-friendly"
This is a big one. It's a very big term in the computing world, "user-friendly". It's even the name of a particularly good webcomic. But it's a bad term.
The basic concept is good: That software be designed with the needs of the user in mind. But it's always addressed as a single concept, which it isn't. If you spend your entire life processing text files, your ideal software will be fast and powerful, enabling you to do the maximum amount of work for the minimum amount of effort. Simple keyboard shortcuts and mouseless operation will be of vital importance.
But if you very rarely edit text files, and you just want to write an occasional letter, the last thing you want is to struggle with learning keyboard shortcuts. Well-organized menus and clear icons in tool bars will be your ideal.
Clearly, software designed around the needs of the first user will not be suitable for the second, and vice versa. So how can any software be called "user-friendly", if we all have different needs?
The simple answer: User-friendly is a misnomer (example: Animal crackers are not crackers but cookies.), and one that makes a complex situation seem simple.
What does "user-friendly" really mean? Well, in the context in which it is used, "user friendly" software means "Software that can be used to a reasonable level of competence by a user with no previous experience of the software." This has the unfortunate effect of making lousy-but-familiar interfaces fall into the category of "user-friendly".
Subproblem #5a: Familiar is friendly
So it is that in most "user-friendly" text editors & word processors, you Cut and Paste by using Ctrl-X and Ctrl-V. Totally unintuitive, but everybody's used to these combinations, so they count as a "friendly" combination.
So when somebody comes to vi and finds that it's "d" to cut, and "p" to paste, it's not considered friendly: It's not what anybody is used to.
Is it superior? Well, actually, yes.
With the Ctrl-X approach, how do you cut a word from the document you're currently in? (No using the mouse!) From the start of the word, Ctrl-Shift-Right to select the word. Then Ctrl-X to cut it.
The vi approach? dw deletes the word.
How about cutting five words with a Ctrl-X application? From the start of the words,
Ctrl-Shift-Right
Ctrl-Shift-Right
Ctrl-Shift-Right
Ctrl-Shift-Right
Ctrl-Shift-Right
Ctrl-X
And with vi?
d5w
The vi approach is far more versatile and actually more intuitive: "X" and "V" are not obvious or memorable "Cut" and "Paste" commands, whereas "dw" to delete a word, and "p" to put it back is perfectly straightforward. But "X" and "V" are what we all know, so whilst vi is clearly superior, it's unfamiliar. Ergo, it is considered unfriendly. On no other basis, pure familiarity makes a Windows-like interface seem friendly. And as we learned in problem #1, Linux is necessarily different to Windows. Inescapably, Linux always appears less "user-friendly" than Windows.
To avoid #5a problems, all you can really do is try and remember that "user-friendly" doesn't mean "What I'm used to": Try doing things your usual way, and if it doesn't work, try and work out what a total novice would do.
Subproblem #5b: Inefficient is friendly
This is a sad but inescapable fact. Paradoxically, the harder you make it to access an application's functionality, the friendlier it can seem to be.
This is because friendliness is added to an interface by using simple, visible 'clues' - the more, the better. After all, if a complete novice to computers is put in front of a WYSIWYG word processor and asked to make a bit of text bold, which is more likely:
* He'll guess that "Ctrl-B" is the usual standard
* He'll look for clues, and try clicking on the "Edit" menu.
Unsuccessful, he'll try the next likely one along the row of menus: "Format". The new menu has a "Font" option, which seems promising. And Hey! There's our "Bold" option. Success!
Next time you do any processing, try doing every job via the menus: No shortcut keys, and no toolbar icons. Menus all the way. You'll find you slow to a crawl, as every task suddenly demands a multitude of keystrokes/mouse clicks.
Making software "user-friendly" in this fashion is like putting training wheels on a bicycle: It lets you get up & running immediately, without any skill or experience needed. It's perfect for a beginner. But nobody out there thinks that all bicycles should be sold with training wheels: If you were given such a bicycle today, I'll bet the first thing you'd do is remove them for being unnecessary encumbrances: Once you know how to ride a bike, training wheels are unnecessary.
And in the same way, a great deal of Linux software is designed without "training wheels" - it's designed for users who already have some basic skills in place. After all, nobody's a permanent novice: Ignorance is short-lived, and knowledge is forever. So the software is designed with the majority in mind.
This might seem an excuse: After all, MS Word has all the friendly menus, and it has toolbar buttons, and it has shortcut keys. . . Best of all worlds, surely? Friendly and efficient.
However, this has to be put into perspective: Firstly, the practicalities: having menus and toolbars and shortcuts and all would mean a lot of coding, and it's not like Linux developers all get paid for their time. Secondly, it still doesn't really take into account serious power-users: Very few professional wordsmiths use MS Word. Ever meet a coder who used MS Word? Compare that to how many use emacs & vi.
Why is this? Firstly, because some "friendly" behavior rules out efficient behavior: See the "Cut & Copy" example above. And secondly, because most of Word's functionality is buried in menus that you have to use: Only the most common functionality has those handy little buttons in toolbars at the top. The less-used functions that are still vital for serious users just take too long to access.
Something to bear in mind, however, is that "training wheels" are often available as "optional extras" for Linux software: They might not be obvious, but frequently they're available.
Take mplayer. You use it to play a video file by typing mplayer filename in a terminal. You fast forward & rewind using the arrow keys and the Page Up & Page Down keys. This is not overly "user-friendly". However, if you instead type gmplayer filename, you'll get the graphical front end, with all its nice, friendly , familiar buttons.
Take ripping a CD to MP3 (or Ogg): Using the command-line, you need to use cdparanoia to rip the files to disc. Then you need an encoder. . . It's a hassle, even if you know exactly how to use the packages (imho). So download & install something like Grip. This is an easy-to-use graphical front end that uses cdparanoia and encoders behind-the-scenes to make it really easy to rip CDs, and even has CDDB support to name the files automatically for you.
The same goes for ripping DVDs: The number of options to pass to transcode is a bit of a nightmare. But using dvd::rip to talk to transcode for you makes the whole thing a simple, GUI-based process which anybody can do.
So to avoid #5b issues: Remember that "training wheels" tend to be screwed-on extras in Linux, rather than being automatically supplied with the main product. And sometimes, "training wheels" just can't be part of the design.
No comments:
Post a Comment