Linked by David Adams on Fri 5th Aug 2011 16:08 UTC
Graphics, User Interfaces A couple of days ago I read a blog post by Stephen Ramsay, a professor at the University of Nebraska-Lincoln and a Fellow at the Center for Digital Research in the Humanities. In it, he mentions that he has all but abandoned the GUI and finds the command line to be "faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible than even the most well-thought-out graphical apps." I found this very thought-provoking, because, like Ramsay, I spend a lot of time thinking about "The Future of Computing," and I think that the CLI, an interface from the past, might have a place in the interface of the future.
Thread beginning with comment 483838
To read all comments associated with this story, please click here.
Unfortunately, it will always 'ls -l'
by whartung on Fri 5th Aug 2011 17:22 UTC
whartung
Member since:
2005-07-06

It may be some different switch, or some longer expression, but it's always going to be specific, nit picky and pedantic. It will also be equally "undiscoverable", which is the primary complaint against CLI.

GUIs are basically discoverable for most domains. Specific vertical applications (e.g. 3D modelers) have so many new concepts that outside training and information are required simply to understand what options might be available in the interface. Without that domain knowledge, discoverability isn't useful.

But with that knowledge, the GUI opens up many of the options by presenting them in front of the user. Click around and find what you want to do, or discover something new.

Most modern command lines don't have that, the Unix one especially. Not easily.

If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.

But either way, regardless of how you learn about an action, representing that action to the machine will be a detailed request. There are always defaults ('ls' vs 'ls -l') but that last thing that you want to do with a computer is have a conversation with it. You don't want it asking you questions, validating your choices. That's what makes the command line efficient. It does what it's told. But to tell it correctly, you have to be very specific.

Consider examples from the real world.

I eat at "In-N-Out", which is a burger stand. I know exactly what I want, and I've honed my ordered to work within their system to make it as efficient as possible. "Double double, lettuce, tomato, grilled onions only." I've learned this, USUALLY, expresses exactly what I want with little interpretation. I could order it "double double, no sauce, grilled onions", which is the same end result, but they almost always came back with "you want ketchup or mustard instead". A needless question, but obviously I'm not clear enough.

Still, I occasionally get the the server who asks the ketchup question.

Similarly, with generic drive through, I follow a specific regimen for the order. I make the basic order "#1 please". Then I wait for the questions. Why don't I just say "#1, hold the cheese, large fries, and a coke"? That's what I want. But a combination of the order speaker, the noise inside, the skill of the server trying to work the machine (which is very specific) inevitably overloads them and they just ask these questions anyway. So, I let them pace the order. In-N-Out tends to have a simpler system and better training, most restaurants don't.

Finally, when ordering eggs, order them "scrambled well" vs "scrambled hard". "Hard" gets conflated with "over hard", you say "scrambled hard", and either server hears "eggs hard" or the cook misinterprets it and you get the wrong result.

The point of this diversion is simply that even when involved with human communication, you have to be very specific. And computers are a) much worse at interpreting people and, moreso, folks hate 'interacting" with computers more than anything (witness the general praise for voice response applications).

The command line is great when you know exactly what you want, as it's very precise and concise. The problems with "-l" etc. are really secondary, because folks in time want those abbreviations.

Most any user would loathe being forced to routinely type:

list files with full description sorted by modification date in descending order.

Maybe some context, maybe always doing what it did last time. Remember options all the time, having really good defaults and simple setting and reseting and overriding of those defaults. But then everyones experience becomes different. When your "ls" is different from my "ls", expect support to explode.

Computers are hard to use. They're awful. Truly awful. But, then, so is everything else. Communication is hard, ask any married couple. How can you expect better from complete strangers and machines?

Reply Score: 9

righard Member since:
2007-12-26

If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.


Can can do 'info'.

Reply Parent Score: 2

pepper Member since:
2007-09-18

> list files with full description sorted by modification date in descending order.

Excellent example. When was the last time you *needed* to list all files sorted by modification time? Because I can't remember such a time. I'm always amazed how people browser their files by *manually* searching the list presented by their computer. I thought computers are meant to do the searching for you?

Many even don't know they can just start typing the first characters of the file if they know its name. By just browsing and clicking on names, they also usually don't know how the files and folders are called, they only learn to recognize them when they see them.

For most purposes, I find GUIs horribly slow and inefficient. I use them for graphics work and browsing, I didn't find good CLIs in those areas or they were too expensive to learn (e.g., I still use GIMP only once a year, so I'm not going to learn the shortcuts there..).

Reply Parent Score: 1

_txf_ Member since:
2008-03-17

Excellent example. When was the last time you *needed* to list all files sorted by modification time? Because I can't remember such a time.


I use it quite often. If you can't remember the name of the file but can remember the time you used it, then modification time helps. It even helps when you cannot remember exactly when you last used it by looking for it as an offset relative to a file that you do remember modifying.

Just because you don't use it, doesn't mean it isn't valid.

Reply Parent Score: 4

mrstep Member since:
2009-07-18

All the time - it's totally useful for development. Say I'm exporting from a graphics app, and then need to copy to another directory - I can easily see which files have most recently been updates (both source and resources) and know that things are in the right state. It's useful for photos if you browse the directory containing them, documents, etc. Name is useful if you know the name, but by last-modified is incredibly good to have too.

And speaking of command line, I just needed to concatenate multiple .pvr graphics files into a single file, and the GUI tools I have don't want to do that. Pity the person who doesn't know how to cat 1.pvr 2.pvr ... > merged.pvr. Just sayin'.

Reply Parent Score: 1

rcsteiner Member since:
2005-07-12


If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.

How about using the "apropos" command? Or man -k?

http://en.wikipedia.org/wiki/Apropos_%28Unix%29

Reply Parent Score: 3

sorpigal Member since:
2005-11-02

If I know a command, I can learn more about it via its man page. But I can't readily do "man commands" to get list and short summary of all the commands on the system. This could be done, it's just not.


Oh yeah? Try

man -k .

(don't forget the . at the end, it's important)

But given that you didn't know this I think this really only backs up the poor discoverability argument.

Reply Parent Score: 2