+1 on visibility. I like real-time graphing for performance data and events, and showing me the gist of what's going on. Configuring triggers on a scope? I'm totally there, GUI-wise.
Then, when I find something interesting in the data, I'll start grubbing through logs with perl and Emacs. [I was happy to be able to open a 1.2 GB file the other day in a few seconds, in my editor. It's tools that /just work/ that make your day, sometimes.]
This is like cats and dogs: A good environment has both! And they should work together well.
[Bruce Tognazzini, an ex-Apple human interface designer, claimed that keyboard shortcuts were on the average slower than using a GUI. I have always disagreed with him.]
Real time graphs and other real time data aside, the example on copying a few files from one place to another is not a very good one to demo the concept of visibility here.
When I need to copy a few files from somewhere to another place, I usually know which files I want to move and where to put them. His opinion is that GUI is superior in this case because you can _see_ the files (their icons) and then select them. There are a few flaws in this thinking.
If you know what you're copying, locating and selecting them will take you longer than to type and tab complete.
If you don't know what files you're looking for, then scanning through the list visually will take an incredibly long time. If you just have a few files, this is not a problem in the first place. In general, if I don't know exactly what I'm looking for, trying to find the stuff I need by browsing is too slow. I either know what I'm looking for or I have to find it using an automatic tool like find or grep.
The second problem in the copy file example is less fundamental: it's the simple fact that selecting multiple files in a GUI file manager is difficult. You have to ctrl-click or do something similar (that's definately not keyboard friendly).
It's nice that the author has spent time pondering where GUI's are good, but unfortunately there are still lots of use cases where GUI's are not good enough.
What's positive about the article is that he acknowledges the fact that most GUIs suck - not because GUIs are inherently bad but because some are just so badly designed.
If I knew the file name, I could type it and it would be as efficient with a GUI as with a CLI. However, my initial assumption is that I don't know the file name (or it's location in a directory hierarchy) but I have to search for the file based on name, content, size, modification date, etc. A list view in a GUI can help a little but I still prefer find and grep to their GUI alternatives.
Thanks for the Ctrl-Space tip. I didn't know that shortcut. Seems to work in Nautilus too.
Then, when I find something interesting in the data, I'll start grubbing through logs with perl and Emacs. [I was happy to be able to open a 1.2 GB file the other day in a few seconds, in my editor. It's tools that /just work/ that make your day, sometimes.]
This is like cats and dogs: A good environment has both! And they should work together well.
[Bruce Tognazzini, an ex-Apple human interface designer, claimed that keyboard shortcuts were on the average slower than using a GUI. I have always disagreed with him.]