4 ms·

It's nice to see some more rigorous thinking about what command line interfaces are good at, but the findings in the research paper are limited to certain kinds

It's nice to see some more rigorous thinking about what command line interfaces are good at, but the findings in the research paper are limited to certain kinds of tasks. The authors describe these as "problem-solving situations where people need to learn the underlying rules of a system, or make as little mistakes as possible" In situations where the cost of failure is low, and one wants to quickly explore a problem space in search of the best solution, you often want an interface that encourages "epistemic action". This is action taken using the interface to think about the problem rather than directly solve it. David Kirsh uses the example of Tetris: https://www.sciencedirect.com/science/article/abs/pii/0364021394900078 https://www.sciencedirect.com/science/article/abs/pii/036402... People often rotate pieces when they're falling to see which way they'll fit best, because that's faster than doing the rotation in your head. So, the fact that users spend more time thinking before they engage with an interface may not be a good thing. It could be that the interface is just hard to use. Think about how you normally solve a jigsaw puzzle... There may be some amount of planning, but there's also a healthy amount of trial an error. The cost of making a mistake is low. Now imagine each piece of the puzzle weighed 50 pounds. In that case, one would make a detailed plan before moving many pieces around.

ElevenLathe 3y ago
Personally I find CLI to be great for this kind of "exploratory" work. Case in point: I recently had to plan a software upgrade for an AWS environment with zero documentation, accumulated over years by a defunct team without using IaC tools, or even much in the way of deployment infrastructure -- just a complete mess. My first order of business was to create read-only CLI credentials for myself, and spend time querying things with the usual combination of sed, awk, uniq, jq, etc. I did this "notebook style" in an org-mode file with org-babel. Within a few hours, I had internalized the structure of the setup, and even had the beginnings of documentation on it. I don't think I could have come to such a confident idea of everything clicking around in the AWS web console, and certainly not that quickly.
- transistordad 3y ago
  What you're saying makes sense, and I think it highlights that these days the line between a CLI and a GUI is less clear than it once was. Specifically, if an interface allows you to organize things spatially on screen in a way that's meaningful to you (eg org-mode) then it's already well on its way to supporting the epistemic action I was referring to. To me, CLI means you enter a series of sequential commands and you receive sequential responses. I'd put emacs somewhere between that and a GUI, as it includes features of both.
  - ElevenLathe 3y ago
    I get what you mean, but I think its a little ridiculous to call a chronological sequence of commands and their output in an org-mode file with running commentary NOT a CLI session. I could have done essentially the same thing by recording my session using the "script" command and adding commentary by starting commands with #. If it was 1972, I could have just marked up the paper output of my ASR-33 session with pencil and stuck it in my notebook for later. If this is "organizing things spatially on screen in a way that's meaningful to you" then I honestly don't know of a way of interacting with a computer that isn't that.
    - transistordad 3y ago
      I mean, it seems like we agree more than you might realize, and only seem to differ on where the line should be drawn between CLI and GUI. I'll totally grant that the place I decided to draw the line was arbitrary. I don't know that that question has a right answer. But the printer example is a great one. The value of printing the output is that then you can do things with it that help you think about it in ways that you couldn't do with the on screen interface. If you wanted to you could cut the paper up and rearrange it, draw diagrams etc. There is a whole genre of interfaces, called Tangible User Interfaces or TUI, that is all about giving physical form to digital information and using physical objects / tokens to represent and modify information inside the computer. Here's a paper with an example task that's similar in many ways to the task in the paper in the original blog post. https://www.cs.tufts.edu/~jacob/papers/chi02.pdf https://www.cs.tufts.edu/~jacob/papers/chi02.pdf So yeah, if an interface lets you organize things spatially in physical (or graphical) space, it can make you a lot more productive.

ElevenLathe 3y ago

Personally I find CLI to be great for this kind of "exploratory" work. Case in point: I recently had to plan a software upgrade for an AWS environment with zero documentation, accumulated over years by a defunct team without using IaC tools, or even much in the way of deployment infrastructure -- just a complete mess. My first order of business was to create read-only CLI credentials for myself, and spend time querying things with the usual combination of sed, awk, uniq, jq, etc. I did this "notebook style" in an org-mode file with org-babel. Within a few hours, I had internalized the structure of the setup, and even had the beginnings of documentation on it. I don't think I could have come to such a confident idea of everything clicking around in the AWS web console, and certainly not that quickly.

transistordad 3y ago
What you're saying makes sense, and I think it highlights that these days the line between a CLI and a GUI is less clear than it once was. Specifically, if an interface allows you to organize things spatially on screen in a way that's meaningful to you (eg org-mode) then it's already well on its way to supporting the epistemic action I was referring to. To me, CLI means you enter a series of sequential commands and you receive sequential responses. I'd put emacs somewhere between that and a GUI, as it includes features of both.
- ElevenLathe 3y ago
  I get what you mean, but I think its a little ridiculous to call a chronological sequence of commands and their output in an org-mode file with running commentary NOT a CLI session. I could have done essentially the same thing by recording my session using the "script" command and adding commentary by starting commands with #. If it was 1972, I could have just marked up the paper output of my ASR-33 session with pencil and stuck it in my notebook for later. If this is "organizing things spatially on screen in a way that's meaningful to you" then I honestly don't know of a way of interacting with a computer that isn't that.
  - transistordad 3y ago
    I mean, it seems like we agree more than you might realize, and only seem to differ on where the line should be drawn between CLI and GUI. I'll totally grant that the place I decided to draw the line was arbitrary. I don't know that that question has a right answer. But the printer example is a great one. The value of printing the output is that then you can do things with it that help you think about it in ways that you couldn't do with the on screen interface. If you wanted to you could cut the paper up and rearrange it, draw diagrams etc. There is a whole genre of interfaces, called Tangible User Interfaces or TUI, that is all about giving physical form to digital information and using physical objects / tokens to represent and modify information inside the computer. Here's a paper with an example task that's similar in many ways to the task in the paper in the original blog post. https://www.cs.tufts.edu/~jacob/papers/chi02.pdf https://www.cs.tufts.edu/~jacob/papers/chi02.pdf So yeah, if an interface lets you organize things spatially in physical (or graphical) space, it can make you a lot more productive.