Command Line and User Friendliness • Hacker News Board

Re: Command Line and User Friendliness

#31

Post by NeutronBoy » Thu, May 31, 2012, 5:22 AM UTC

jasomill wrote: post #30

marknadal wrote: post #2

But you are missing something... Try photo manipulation with a CLI. Art requires spatial interaction, not merely "conversational" expressions.

Not just art. Try writing and editing text with nothing but shell tools. One thing that I'd love to see in all GUIs is a unified "search box" for commands, settings, and tasks. The OS X help menu comes close (but it only searches help and menu bar items); the "Control-Q" box in the Visual Studio 11 beta comes even closer (but it only works in Visual Studio). Neither, however, go beyond basic substring matching, and t…

Interestingly, this is what Unity tries to achieve but has been overshadowed for other reasons.The search box in the Windows 7 Start Menu also does a great job at searching programs, files, and the control panel.

Re: Command Line and User Friendliness

#32

Post by ricardobeat » Thu, May 31, 2012, 5:52 AM UTC

underwater wrote: post #19

ricardobeat wrote: post #8

Earlier quoted context omitted.

I have no idea what you mean by "passing around objects", and I guess that wouldn't make it any more friendly. An "object" is an abstract concept that must be known beforehand, and is just one in a myriad that could exist in the context of interacting with a computer. Have you heard of TermKit? It was an experiment in intertwining graphical and command-line interfaces: https://github.com/unconed/TermKit/

If I want to work with e output of ls, why do I need to manually parse fragile strings? It would be neat to have basic stringable primatives, like maps and tables, that scripts could write and read.

You can't approach things from a programmer's perspective when thinking about interfaces. I mean, I see your point, but how would that make it any more user-friendly? More powerful, sure, but it would require an extra layer of abstraction, which is going in the directly opposite way of user-friendliness.

Besides, you already have all that right now, by using the dynamic language of your choice + file system APIs.

Re: Command Line and User Friendliness

#33

Post by ricardobeat » Thu, May 31, 2012, 5:54 AM UTC

saraid216 wrote: post #26

What I think would be interesting would be some strongly-coupled CLI-GUI interactions. For instance, let's take Word as a start. What if you could swap to your CLI and say "load letter template" and it would walk over to Word and do that for you in the GUI? Or in Excel, instead of clicking through the charting wizard, instead have a CLI that lets you configure the options at will? I think that would be the next great…

AppleScript?

Re: Command Line and User Friendliness

#34

Post by maigret » Thu, May 31, 2012, 7:11 AM UTC

jasomill wrote: post #30

marknadal wrote: post #2

But you are missing something... Try photo manipulation with a CLI. Art requires spatial interaction, not merely "conversational" expressions.

Not just art. Try writing and editing text with nothing but shell tools. One thing that I'd love to see in all GUIs is a unified "search box" for commands, settings, and tasks. The OS X help menu comes close (but it only searches help and menu bar items); the "Control-Q" box in the Visual Studio 11 beta comes even closer (but it only works in Visual Studio). Neither, however, go beyond basic substring matching, and t…

Right. Even Vim and Emacs in the terminal are actually GUIs.

Re: Command Line and User Friendliness

#35

Post by jeremysmyth » Thu, May 31, 2012, 10:44 AM UTC

What seems to be getting lost is that "user-friendly" has the word "user" in it. And "user" is relative to the situation.

A Formula 1 car is not designed for novices, but it gives the driver maximum control in a very high-stress situation. I would suggest that the interface is as "friendly" to the intended user as millions of $cash and hours of research can possibly make it.

The CLI is the result of 30-40 years of similar evolution, and the fact that it has survived this long, and mutated in the helpful ways mentioned by the article, would similarly suggest that many users find it useful. I know I do, and I'm a user.

Re: Command Line and User Friendliness

#36

Post by dave1010uk » Thu, May 31, 2012, 12:42 PM UTC

saraid216 wrote: post #26

What I think would be interesting would be some strongly-coupled CLI-GUI interactions. For instance, let's take Word as a start. What if you could swap to your CLI and say "load letter template" and it would walk over to Word and do that for you in the GUI? Or in Excel, instead of clicking through the charting wizard, instead have a CLI that lets you configure the options at will? I think that would be the next great…

I believe this is the idea behind Ubuntu's HUD: http://www.markshuttleworth.com/archives/939

Re: Command Line and User Friendliness

#37

Post by Scene_Cast » Thu, May 31, 2012, 2:52 PM UTC

ori_b wrote: post #9

Scene_Cast wrote: post #3

I am one of those people who thing that CLIs are not user friendly. The premise - giving a computer instructions via Natural Language (NL) - is very sound. However, the way CLI is done right now (from the ground up) - is broken. The most obvious example - why are CLIs ASCII-based? I want to pass around objects - "ls" should only give me just that, an array of objects (which can be serialized for output in any graphic…

> I can't even count the number of times I wanted to pipe an output of one program to multiple others ls | tee >(frob x) | grep y should output the output of ls to both 'grep x' and 'grep y'. The '>(foo)' syntax in bash will create a subshell to run the pipeline in the parens, and evaluate to the name of the FD for the pipeline (eg, /dev/fd/42). For multiple inputs, similarly: grep foo

Thanks! I didn't know about tee. My gripes were from working with something like this ( http://i.imgur.com/LnAvV.jpg ), and then trying to emulate that in CLI. (The picture shows a graph-based image processing system, Blender's compositing mode) --- Source: http://www.blender.org/typo3temp/pics/ca33eb4833.png

Re: Command Line and User Friendliness

#38

Post by ori_b » Thu, May 31, 2012, 3:44 PM UTC

Scene_Cast wrote: post #37

ori_b wrote: post #9

Earlier quoted context omitted.

> I can't even count the number of times I wanted to pipe an output of one program to multiple others ls | tee >(frob x) | grep y should output the output of ls to both 'grep x' and 'grep y'. The '>(foo)' syntax in bash will create a subshell to run the pipeline in the parens, and evaluate to the name of the FD for the pipeline (eg, /dev/fd/42). For multiple inputs, similarly: grep foo

Thanks! I didn't know about tee. My gripes were from working with something like this ( http://i.imgur.com/LnAvV.jpg ), and then trying to emulate that in CLI. (The picture shows a graph-based image processing system, Blender's compositing mode) --- Source: http://www.blender.org/typo3temp/pics/ca33eb4833.png

That should probably get a domain-specific tool regardless; Generalizing the command line UI is probably going to end up getting too hairy for the common case.

Re: Command Line and User Friendliness

#39

Post by dllthomas » Thu, May 31, 2012, 8:54 PM UTC

saraid216 wrote: post #26

What I think would be interesting would be some strongly-coupled CLI-GUI interactions. For instance, let's take Word as a start. What if you could swap to your CLI and say "load letter template" and it would walk over to Word and do that for you in the GUI? Or in Excel, instead of clicking through the charting wizard, instead have a CLI that lets you configure the options at will? I think that would be the next great…

This is supported by some individual applications. For instance, firefox will let you open a new tab in a running browser, ratpoison will let you run a bunch of commands against it, etc.

I'm still not thrilled because it's usually still difficult to move data the other way (although xclip or xsel can certainly help).

Re: Command Line and User Friendliness

#40

Post by quesera » Fri, Jun 01, 2012, 2:16 AM UTC

saraid216 wrote: post #26

What I think would be interesting would be some strongly-coupled CLI-GUI interactions. For instance, let's take Word as a start. What if you could swap to your CLI and say "load letter template" and it would walk over to Word and do that for you in the GUI? Or in Excel, instead of clicking through the charting wizard, instead have a CLI that lets you configure the options at will? I think that would be the next great…

AutoCAD has a simultaneous GUI and CLI. SketchUp has a partial implementation of a similar model.

You could argue that Vi and emacs do both. Certainly the primary mode is a (curses-based) GUI, and the command modes operate on the same data. They're not quite always-on, but close enough.

I often wish more applications would do this!