5 ms·

At the risk of sounding like a broken-record aging neckbeard (reality: I'm a college student with light stubble), I think the title of this thread is very misle

At the risk of sounding like a broken-record aging neckbeard (reality: I'm a college student with light stubble), I think the title of this thread is very misleading, even if the blog post itself contains valuable material. First, I'm just barely old enough to remember using DOS on a machine without Windows -- which I believe is the last time that a GUI/DE wasn't viewed as 'essentially essential' for an end-user computing environment. However, I'm just young enough to remember growing up with Windows for most of my computing life, so it's not like I was indoctrinated into the ways of the command line from an early age. Far from it - I'd forgotten all the DOS commands I knew by the time I turned 10, and I actually only began learning Unix very recently (while in college). I don't think command-line tools have a UX problem. If anything, we have a teaching problem. Command-line tools have a slight learning curve, but really nowhere near as much as many people think. The story of how I got into using the command-line for all (well, almost all) my daily tasks is a bit too long to post here (unless people are interested), but in short: I went from not knowing the difference between cd and dd all in the span of a month. (Thankfully, I did not have to learn those two commands the hard way!) Why was I able to do it? Because Unix has a ridiculously uniform design, and is unbelievably modular. UI designers today should strive for the uniformity that my GNU system has. (I use GNU, but this comment applies for the most part to other systems, like the BSD-based varieties, and is largely, though not completely, true even when comparing two different systems!). There are a few wrinkles around the edges, but when you consider the very distributed/patchwork way that modern POSIX systems came to be, it's almost miraculous that the single-dash switches vs. double-dash options distinction works in most cases the way you'd expect. The difference between required arguments and optional parameters is implemented very well in most utilities (it's rare that I have to specify unnecessary flags for required parameters, for example). Combining switches also works the way you'd expect on most utilities, and even the naming is consistent (-h, -v, -l, -a, --help, --verbose, etc. follow the Principle of Least Surprise (POLS) in all but very few cases). Even if there are differences between, say, ls -G on BSD and ls --color on GNU, that's a matter of the way those basic utilities were implemented, and the interface itself is still fairly uniform. (And I'm willing to grant some leeway for such fundamental utilities as 'ls', since these tools develop over a period of time). That's not to say that everything has to follow the Unix-like model. I'm not saying that Opa's efforts aren't valuable simply because they're not standard POSIX. On the contrary, I think that tailoring a command-line tool to the task at hand can be very valuable - SQL queries fall into this category as well. But they're valuable because they provide a modular (scriptable) tool that modify a familiar interface to make it easier to use in a domain-specific context with minimal violations of the POLS. That's fundamentally different from improving the UX of the command line; instead, it's applying the general UI principles of command line tools to a specific context. All instances of a general UI violate the POLS in some way by definition; the goal is to minimize that. In the end, I can't think of any other UI that follows the Principle of Least Surprise as well as Unix does, and it's the most fundamental command-line tool in my life. We may have a problem with the command line, but the command line does not have a problem with UI. (Edit: Does someone know how to write an asterisk without causing it to be parsed as the opening of an italicized block, as in <asterisk>-nix to refer to the wildcard 'Unix-like'? I'm on choppy in-flight internet and can't figure this out reliably with trial-and-error).

fcurella 15y ago
I think there is much more that can be done to make tools more user-friendly. An example that pops to my mind is when you misspell a git command, and git suggest what you could've intended: $ git pill git: 'pill' is not a git command. See 'git --help'. Did you mean this? pull That's already one step towards a better UI, but it could go even one step further if I could answer the question, ie: I press 'y' and git will pull. Of course I'm not criticizing GIT (which I think as a better UI than many tools already), it's just an example.
- aeroevan 15y ago
  zsh will actually do this for commands if you make a typo when the correct option is turned on. I don't think it will correct options though (but can autocomplete).
- chimeracoder 15y ago
  I'm not saying that the UI couldn't be improved - I'm just saying that what they're doing isn't really an improvement on the the command-line as a UI, as it's just a domain-specific application. (And, I implied this but didn't state it explicitly: domain-specific applications should aim to be as 'compatible' as possible from a UI standpoint with the generic tool - ie, Unix - deviating only when there's a specific need to, and defaulting to the generic toolset. I'd need to see more to judge if Opa fits this; it's just a general principle). More importantly, though: what you're looking for can already be done! Just use zsh (or, even simpler: a bash correction tool). Because Unix is so modular, you can make these kinds of UI changes without breaking or even changing the underlying toolset. That means that you and I can tailor the UI to our specific needs, and we don't even really have to touch the general purpose toolset. Other examples include using Vim keybindings for the shell instead of Emacs (try modifying keyboard shortcuts with most pre-compiled GUI applications!) or scripting and aliasing. Thanks for mentioning that, actually, because it illustrates my point very well! The command-line UI's strength is that it's literally as modular and as minimal as possible (at least, as far as I can conceive of). That's what I personally love the most about it. It defines only the bare minimum of tools necessary to satisfy two conditions: 1. By default, [almost] everything works as expected, with no customization (but assuming knowledge of the system). 2. Those who want to customize will find that it provides all of the tools necessary to create the exact interface they want, without modifying the underlying toolset as well. (This customization can be done to an essentially arbitrary level -- the technical limitations are well beyond what a reasonable person would consider 'sane'). You may make the argument, then, that the command-line isn't even an interface at all! It's more like an abstract interface that lets you stitch the tools together to define the interface you want, all the while providing a 'default interface' - a sensible set of defaults for those who can't be bothered to customize. (Edit: I understand that tools aren't perfect - the git-pull/git-push asymmetry is an example - but the inconsistencies are vastly outnumbered by the overarching uniformity. And again, with such a modular model, you can create the UI you want without waiting for Linus to change the behavior of git).

fcurella 15y ago

I think there is much more that can be done to make tools more user-friendly. An example that pops to my mind is when you misspell a git command, and git suggest what you could've intended: $ git pill git: 'pill' is not a git command. See 'git --help'. Did you mean this? pull That's already one step towards a better UI, but it could go even one step further if I could answer the question, ie: I press 'y' and git will pull. Of course I'm not criticizing GIT (which I think as a better UI than many tools already), it's just an example.

aeroevan 15y ago
zsh will actually do this for commands if you make a typo when the correct option is turned on. I don't think it will correct options though (but can autocomplete).
chimeracoder 15y ago
I'm not saying that the UI couldn't be improved - I'm just saying that what they're doing isn't really an improvement on the the command-line as a UI, as it's just a domain-specific application. (And, I implied this but didn't state it explicitly: domain-specific applications should aim to be as 'compatible' as possible from a UI standpoint with the generic tool - ie, Unix - deviating only when there's a specific need to, and defaulting to the generic toolset. I'd need to see more to judge if Opa fits this; it's just a general principle). More importantly, though: what you're looking for can already be done! Just use zsh (or, even simpler: a bash correction tool). Because Unix is so modular, you can make these kinds of UI changes without breaking or even changing the underlying toolset. That means that you and I can tailor the UI to our specific needs, and we don't even really have to touch the general purpose toolset. Other examples include using Vim keybindings for the shell instead of Emacs (try modifying keyboard shortcuts with most pre-compiled GUI applications!) or scripting and aliasing. Thanks for mentioning that, actually, because it illustrates my point very well! The command-line UI's strength is that it's literally as modular and as minimal as possible (at least, as far as I can conceive of). That's what I personally love the most about it. It defines only the bare minimum of tools necessary to satisfy two conditions: 1. By default, [almost] everything works as expected, with no customization (but assuming knowledge of the system). 2. Those who want to customize will find that it provides all of the tools necessary to create the exact interface they want, without modifying the underlying toolset as well. (This customization can be done to an essentially arbitrary level -- the technical limitations are well beyond what a reasonable person would consider 'sane'). You may make the argument, then, that the command-line isn't even an interface at all! It's more like an abstract interface that lets you stitch the tools together to define the interface you want, all the while providing a 'default interface' - a sensible set of defaults for those who can't be bothered to customize. (Edit: I understand that tools aren't perfect - the git-pull/git-push asymmetry is an example - but the inconsistencies are vastly outnumbered by the overarching uniformity. And again, with such a modular model, you can create the UI you want without waiting for Linus to change the behavior of git).