Tim,

In a previous column, you wrote:

. . . After a small barrier to entry, it [the vi editor ] is orders of magnitude more powerful and easy to use than commercial word processors. (But that's true of emacs as well!)

Agreed--for the most part. Ease of use comes primarily from (1) understandable, as-you-work, on-screen help, and (2) a complete and systematic set of typing-zone command keystrokes. Have you ever wondered why both of these elements were missing from successful new commercial word processors between 1982 and 1992?

Dan Strychalski

Dan,

I agree with your assessment. The craze for "everything GUI" (a bit like Wil E Coyote's "Everything Acme" in the old Warner Brothers' "Roadrunner" cartoons) that took over in the 80s crowded out an awful lot of other powerful user-interface ideas, especially interfaces that are optimized for advanced users rather than beginners. There were also a lot of short-sighted legal roadblocks in which vendors tried to protect their interfaces, and ended up turning them into dead-ends instead of standards.

In terms of missing user-interface features for power users, far and away the most significant of these is the absence of integrated scripting. As I wrote in UNIX Power Tools, one of the beauties of the Unix command line is that it's optimized for "letting the computer do the dirty work." Computers are great for repetitive tasks--the very tasks that humans find most tiresome. The Unix shell lets you issue a unique command once, but at the same time, it gives you programming constructs that make it easy to run that same command again and again on new data sets. Simple things like loop control can make the difference between having to repeat a command a hundred times or having to do it just once.

Editing tools like the macros in vi and emacs, or stream editors like sed and awk, take the same concept and apply it to text manipulation. And of course, the genius of Perl is that it unified the Unix system-programming universe with the shell-programming universe and the text-processing universe, providing a single, multi-purpose power tool. Successive languages like Python have had the same goal.

One of my favorite pieces about the virtues of the command line and the "under the hood" visibility of Unix is Tom Scoville's UNIX as Literature. Also wonderful is Neal Stephenson's In the Beginning Was the Command Line.

In various books over the years, from my own Windows 95 in a Nutshell, Windows 98 in a Nutshell, and upcoming Windows XP in a Nutshell, as well as all our Windows administration books, we've tried to evangelize this philosophy for Windows users as well. In addition, books like Writing Word Macros and Writing Excel Macros focus on the scriptable aspects of the most common applications.

To return more specifically to vi's command mode and the user-interface lessons we can take from it, I agree very much with the idea that a complete and consistent set of keystroke commands is an extremely valuable UI feature. For example, considering spreadsheets, I still remember with fondness the old Lotus 1-2-3 "slash" command line, where typing a slash followed by the first letter of any command would walk you through a menu tree. Lotus cooked their own goose by suing competitors who used this interface. By the time their suit was overturned in 1993, other user-interface paradigms had become common. Windows now replicates some of this functionality with its ALT commands. (ALT followed by any letter will drop down the eponymous menu, with the next letter selecting an item from the menu. For example, ALT-F-N will create a new file in most applications, ALT-F-S save a file, and so on.) But applications are not entirely consistent in following this convention, and the presence of an older system of keyboard shortcuts using the CTRL key for the most common operations keeps many users from picking up the more systematic ALT keystroke system.

GUIs are optimized for new users, while command-based systems are optimized for experienced users who know what operation they want to perform and just want the quickest way to invoke it. And because the first generation GUIs spent all their time trying to supplant command-based interfaces, rather than complementing them, users got out of the habit of expecting applications to have a consistent system of keystroke commands or ready scriptability. What's more, in the critical period when GUIs were first spreading like wildfire, legal roadblocks kept these features to a minimum.

Fortunately, we're coming up to an inflection point where user interfaces are about to change radically, once again. Within a few years, I expect voice-driven applications to be much more common as applications look to support not just PCs but a variety of smaller devices, and as the technology for both recognizing and synthesizing speech becomes more powerful and more widespread. And of course, voice commands are a natural for scripting and repetitive execution.

As to "understandable, as-you-work, on-screen help," I'm afraid I can't agree with you there. Or rather, I agree with you in theory, but as the oft-copied usenet .sig says, "The difference between theory and practice is always greater in practice than it is in theory." Most online help is just awful. It tells you what is obvious, and leaves out what is hard, when it should be doing exactly the opposite. Of course, many user manuals and consumer computer books do the same. This is why we've tried to pitch our books for more advanced users, going quickly through the basics and spending the bulk of the time documenting information that is hard to find or intuit from the user interface.

I have yet to see a help system in a GUI-based system that is a patch on old-style Unix man pages. Unlike most help, the man pages didn't assume you were stupid. They tended to assume an intelligent reader. Sometimes they were obtuse, but they never wasted your time on inanities. A shallow help system is often less useful than no help at all.

This is part of the reasoning behind our Safari Tech Books Online service, which now includes books from Pearson imprints such as Addison-Wesley, Prentice-Hall, Peachpit, and New Riders, as well as O'Reilly books. It lets you really drill down into a subject. It's also why we license online versions of our books to vendors who want to incorporate richer content into their help systems.

Tim

Got a question? Just ask!

Copyright © 2007 O'Reilly Media, Inc.