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 483834
To read all comments associated with this story, please click here.
Two distinct beasts...
by zima on Fri 5th Aug 2011 17:00 UTC
zima
Member since:
2005-07-06

Command line, CLI, with its usually a bit arcane commands, is a somewhat different concept from natural language interpretation. Treating them as very related (considering the topic used above, mentioning the CLI repeatedly; contrasting them both with GUI...) is possibly counter-productive.

As a side note, IIRC there were also some research suggesting that, in many scenarios, CLI merely is perceived as faster than GUI (supposedly because CLI requires greater attention, which masks perception of time); but actually timing some common tasks tells otherwise.

And scifi "computers" are mostly just a storytelling tool, to woo the audiences with cheap tricks...

PS. Winphone7 is a more real-life example to consider. Very text based. But TBH... I'm not entirely convinced it fits the way our minds work (particularly with the early demonstrations of WP7, I can't get rid of the feeling that the presenters appear relatively lost; people who were meant to promote the product, show how nice it is, hence supposedly familiar with it). It took us some time to get decent ~WIMPy paradigms, and maybe they are what works for humans... (obligatory car analogy: kinda like it took some time to develop the steering wheel; since then, no "refirement" was able to replace it; maybe autonomous cars can change that, maybe a central "swinging joystick" controller would be a fit in them - but that would be only because of very different overall approach, almost like "computer, do what I want to be done, so that I don't have to (authorisation: 8295 somebody-who's-not-quite-sure-why-he-is-needed-onboard)")

Edited 2011-08-05 17:20 UTC

Reply Score: 2

RE: Two distinct beasts...
by Alfman on Fri 5th Aug 2011 17:45 in reply to "Two distinct beasts..."
Alfman Member since:
2011-01-28

zima,

"As a side note, IIRC there were also some research suggesting that, in many scenarios, CLI merely is perceived as faster than GUI (supposedly because CLI requires greater attention, which masks perception of time); but actually timing some common tasks tells otherwise."

This is desperately asking for a citation.


My thought is that it is true that CLI apps have a higher learning curve, but knowledge of them pays off very quickly.

To the extent that GUI are inherently a superset of CLI, then in theory GUI should be every bit as good as CLI. However in practice GUI programs are incredibly difficult to automate. It's usually quite trivial to perform automation on top of CLI, and incredibly difficult with GUI apps.

We could always say that this is a weakness of the specific GUI program, which failed to incorporate macros, rather than a problem with the GUI model in general. However this is something many CLI apps get for free.

Even something as simple as renaming many files is error prone and painful without CLI tools.

You might need to replace "Company" with "Company, Inc" in all documents where it hasn't already been changed. If your documents are only accessible through a GUI interface, then you (or the intern) might need to spend several hours doing it manually.

Reply Parent Score: 5

RE[2]: Two distinct beasts...
by zima on Fri 5th Aug 2011 18:57 in reply to "RE: Two distinct beasts..."
zima Member since:
2005-07-06

Don't make out of it anything more than I wrote and you quoted (which includes "side note", "IIRC", "suggesting", "many" (!="most" for example); what is essentially everything I remember about it (well, plus how it was some research with a downloadable pdf, I think; and perhaps how it included more real-life, poorly-structured, end-user file management).

(so it's also not about finding an almost absolute edge case counterexample - simple, almost "atomic", highly repeatable text edit of every file at hand, what batch editing is pretty much about)

Seeing GUI as a superset of CLI is probably also not particularly helpful, when tons of data people care about doesn't really exist in textual form, but in graphical (sure, pedantically we might go down to how it is represented under the hood, but...)

That's kinda related to what I was pointing at, unnecessarily rigid distinctions and/or grouping of concepts. For example, is Google - or, even better, GMaps - a graphical or textual UI?

Well... both. It would be mostly quite horrible when presented and manipulated in a usual pure CLI fashion. But you do input textual commands (there's just no reason for them to be very CLI-like); and with routine automation even expected to be hidden by nice GUI, here and there.

Edited 2011-08-05 19:11 UTC

Reply Parent Score: 1

RE[2]: Two distinct beasts...
by WorknMan on Fri 5th Aug 2011 19:36 in reply to "RE: Two distinct beasts..."
WorknMan Member since:
2005-11-13

To the extent that GUI are inherently a superset of CLI, then in theory GUI should be every bit as good as CLI.


Well, GUI is not inherently a superset of CLI - it's a COMPANION. Meaning, each is better at some tasks than the other, so they go together like sugar and kool-aid, and I wouldn't be without either. Why must everything be turned into a pissing contest?

When it comes to GUIs, some have said how it's easier to pull up files in a CLI, like when you need to copy all files that are older than a certain date and with a certain extension. But what if you need to copy about 50 random files from a directory of 300 files that don't have any specific pattern to them? In that case, it's easy to CTRL+CLICK select the ones you need and drag them wherever. Similarly, the article mentions how it would be easier to manipulate music playlists, but what if you've got a playlist with 300 songs, and you want to custom sort them? Again, it's going to be easier to just drag stuff where you want them.

Of course, one could list dozens of examples were CLIs would be more useful... as I said before, it's not about which one is 'better', because that depends on the context.

However in practice GUI programs are incredibly difficult to automate.


Actually, no it isn't... at least on Windows, it's quite easy:

http://www.autoitscript.com/site/autoit

The only exception to this is if apps don't use standard widgets, which is one of about 486472343 reasons why I'm a fan of standards in this regard. Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...

Reply Parent Score: 4