Aza on the Linguistic Command Line

UNCATEGORIZED

Recently, the Assosciation for Computing Machinery approached Aza Raskin, one of our founders, to see if he would write an article for the first online issue of their magazine, interactions. As you might expect from the one of the people who brought you Enso, Aza decided to write an article about command lines. The first issue of interactions is now available, and Aza’s article about The Linguistic Command Line has been published. Enjoy!

Correction: This is the first online issue of ACM’s interactions magazine, not the inaugural issue of the magazine itself, which is approaching 13 years old. My apologies for the confusion, and my thanks to Srikanth and Christopher for pointing this out. –Andrew

Direct link to the article:
http://delivery.acm.org/10.1145/1340000/1330535/p19-raskin.pdf?key1=1330535&key2=4155903021&coll=GUIDE&dl=GUIDE&CFID=16490606&CFTOKEN=93648138

I believe this would be the first time my school has had access to a technical journal when I wanted to read an article in it. :)

I always enjoy hearing/reading your arguments in favor of a command based interface, but it always occurs to me that you miss out on what makes a *nix command line more powerful than anything else: the pipe.

The pipe is powerful for some of the same reasons that breaking down the barrier between applications is powerful, you get to hook things together because they speak a common language. It happens that at some point a trend occurred to encapsulate functionality in command line tools, so we use tar -z to (un)gzip, but this used to be done via a pipe:

gzcat | tar -xf -

Which in the end tends to be more memorable then knowing all the weird switches, and like you say reduces memory and disk footprints. I don’t need my image viewer to have an http client, I can just use fetch/wget/curl. The pipe, and the ubiquity of tools designed to take advantage of it, is why I still use *nix.

Hey, This isn’t the inaugural issue of Interactions, it has been around for quite some time now. Probably 10-15 years.

I did read the article in the recent issue of Interactions and greatly enjoyed it. Aza articulates the problems that modern GUIs faces really well. I wish I could give Enso a try, but you guys don’t do mac. I use QuickSilver on mac, which I’m guessing shares quite a bit of functionality.

I can’t say I was fully believe that command line interfaces are the way to go again. I use it mainly because I am familiar with the environment and crave an increase in interaction. One of the main problems with these interfaces is that it suffers from a well-recognized problem in HCI - the vocabulary problem. People use a wide range of words to mean the same thing and if they are constrained by an armchair name, they will eventually find it very confusing. For example, imagine what people would try if they wanted to retrieve the location of a file. Of course, all the functions can be aliased and the reachability of functions drastically improved. But the danger of blanking out looking at a blank command-line still exists.
If you haven’t come across the paper I’m talking about, here is a link to it - http://portal.acm.org/citation.cfm?id=32212
A related problem is that users cannot logically arrive at what the function is called , as is possible in a menu-based GUI.

Also, the interface needs a high amount of contextualizing. For example, QuickSilver gives an option that I can copy a file that I’ve searched for, to a webpage or an old email. Just a simple example that illustrates the extent and the hardness of the problem.

Of course, I greatly laud your efforts and envy your intuition about certain things :) I just wanted to highlight some problems that I’ve come to think about during my study of the same. Keep up the good work.

It’s the first online issue, not the first issue.

@Srikanth,

“People use a wide range of words to mean the same thing and if they are constrained by an armchair name, they will eventually find it very confusing. For example, imagine what people would try if they wanted to retrieve the location of a file.”

People have been successfully using file search for decades. So I guess you mean what command name people would try, to search for a file. Synonymous command names, such as “find file” and “search for file”, can be encoded in the UI. Quick feedback showing command descriptions would help distinguish between homonyms and between senses. The canonical command names can be displayed to help the user learn them. These approaches are not considered in the paper you refer to.

“[…] the danger of blanking out looking at a blank command-line still exists.”

Does the danger exist when typing a URL in the address bar or when performing a web search?

“Also, the interface needs a high amount of contextualizing.”

Yes, and because of the paradigm of applications it has to be done artificially.

How ironic that the article takes 3 clicks and 2 new open browser windows to get to…

Indeed, Nigel.

And you don’t want to know how difficult it was to obtain a halfway decent print copy of that article.

I’m finding BW Chicago to be one of the worst implementations of an online magazine I’ve ever seen.