7 ms·
This simply is an artifact of the original design of CLI. You start by writing the command or function, and then you provide parameters or arguments. The order
by miguelrochefort 11y ago
This simply is an artifact of the original design of CLI. You start by writing the command or function, and then you provide parameters or arguments. The order in which these things are provided leads to poor discoverability.
Instead of starting with the command, we should start with an argument. Given a "thing" (that likely exists in your UI), such as a file, a song, a person, a chunk of text, show me the list of commands that accept it as a parameter. You'll quickly discover that a chunk of text can be passed to functions such as "tweet", "copy to clipboard", "create memo", "search on Google", "translate". Congratulations, you just invented the contextual menu, which people have been using for decades.
"Things" are easy to discover; you can see them. Commands that interact with them, are not as easy to discover; you can't see them. Let people touch or name things (with or without a query language), and once they grabbed the instance they care about, show them what can be done with it. It's that simple.
Before:
> /tweet "some random thoughts" // where you had to know 'tweet' existed as a command
After:
> "some random thoughts" -> tweet // where 'tweet' was auto-suggested, along with 'search', 'translate', 'copy', etc.
- seagreen 11y agoThis is brilliant. Do you have suggestions for where I can go to read more about this idea?
- mitchtbaum 11y agoThis question seems to point in this direction of changing our shell syntax from `vo` to `ov`, based on Jef Raskin's Humane Interface http://ux.stackexchange.com/questions/48051/how-to-extend-the-noun-verb-paradigm-to-multiple-nouns http://ux.stackexchange.com/questions/48051/how-to-extend-th... .. I imagine pluggable shell grammars would allow open ended exploration this way.
- agumonkey 11y agoI see this strongly related to many combinators in FP too. (system command arguments) flip -> (system arguments command) curry -> (system arguments) command # and for the humane touch: thread (system (completing-read)) (completing-read) etc etc Oh, and BTW, GUIs didn't buy ergonomy, sometimes you need to open an application then the data (aka /tweet "bla"), early systems had a simple 1:1 map 'type' 'program' with an 'open-with' intermediate. Then they added 1:N ... One day it will be a tiny Hindley-Milner unifier ;)
- a3n 11y agoThe gui equivalent would be right-clicking on a thing. There's probably a lot on what you should put in that menu, and you could probably take some general principles from that.
- IanCal 11y agoIt sounds to me (apart from the auto-suggest) that this is exactly like piping on the command line. echo "My random thoughts" | tweet
- jeremysmyth 11y agoNaked Objects is an example of a UI driven by the underlying objects rather than by the use cases thought up by a programmer. https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects
- perlgeek 11y agoA nice example for discoverability in conjunction with text commands is JIRA's search capability with JQL. It allows you to type queries, and each point offers dropdowns that list valid attributes, operators, values (in case of limited choice of values). I like it.
- drudru11 11y agoGlad to see this suggested. This is very similar to why OO programming was such a more humane system.
- miguelrochefort 11y agoA problem with most OO programming languages is that methods are declared as part of the class itself. This makes it difficult to extend an existing class you don't control, or reuse a method elsewhere. C# supports extension methods, which are basically static helper methods whose first parameter is the type to which you want to attach the method. For example, I could create a 'ToTitleCase' extension method on type 'string'. Then, given a string instance, I can simply do 'myString.ToTitleCase()'. One step further would be to add support for multiple parameters. For example, instead of listing all functions that accept an 'int' as an argument, you could ask for all functions that accept both an 'int' and a 'string' as an argument. Given 3 and "test", the 'repeat' function could be suggested, resulting in "testtesttest". To make things even better, one could provide (explicitly or not) the return type of the function they're looking for. For example, if you're assigning to a variable of type 'int', and all you have is a 'string', then you probably want to see a list of all functions that take a 'string' as an argument, and return an 'int'. In that case, you would see functions like "parseInt" or "getLength". It's kind of like playing domino, where you already know the type of the input and output, and only need to connect them together. Keep in mind that you can't always transform one type to the other in a single function call, which means the system would also need to recommend combinations of functions, such as "parseDateTime + getDayOfWeek" when you need to transform a 'string' to an 'int'. Perhaps the name of the arguments could even be used as some kind of sorting heuristics (a 'string' variable named "date" surely should be parsed to some kind of DateTime at some point).
- dllthomas 11y agoOver in Haskell-land, hoogle will perform fuzzy searches on type signatures. Having something like that at hand in the shell could certainly be neat.
- lomnakkus 11y ago
- JupiterMoon 11y agoInteresting. I'd not realised this before but in terms of human language classic CLI is of the form: Verb Subject Whereas English (and other European languages that I know some grammar for) are of the form: Subject Verb I.e. you're advocating that CLI interfaces should be more like English...
- rafaelnonato 11y agoExcept the text to tweet is not the subject, but rather the object. And English is VO, just like the command line. The suggestion is that we use Japanese's OV order.
- JupiterMoon 11y agoYep I'm wrong sorry.
- kuschku 11y agoAnd then you have German, where VSO/VOS is a question, and SVO/SOV/OSV/OVS are normal sentences.
- ap22213 11y agoAssuming a CLI is on parity w/r/t usability as a GUI, which takes a shorter amount of time and less effort to construct? GUI certainly.
- jakeva 11y agoI don't think I would entirely agree with that. Surely it depends on the developer. I can build a traditional CLI program faster than I can arrange a GUI for an equivalent program in something like interface builder although I've met developers who are faster the other way around.
- vitd 11y agoThis sound about as useful as a man page. For me it often goes like this: "What's the command that shows me file system usage again?" > man -k file system usage result = 5 pages of matching commands, often poorly formatted, word wrapping oddly, sometimes without even carriage returns between the commands, so it's all one long list. And this is in Unix which has had something like 45 years to clean up this mess. I don't hold out hope that this sort of interface will ever be presented usefully, and we already have a better system in a GUI.
- falcolas 11y agoAs opposed to the discoverability within the Mac interface for showing disk usage? I can't tell you how long it took me to find it. And heaven help you if you want to find out where all of that data is on the hard drive. Oh, by the way, it's at: Apple menu -> About This Mac -> Storage And don't alt-tab away from it; you can't get back to it using the keyboard. You have to use Mission Control or back through the Apple menu again.
- kitsunesoba 11y agoA simpler alternative that has existed for decades in Mac OS is right-click disk -> Get Info, which is analogue to right-click disk -> Properties on Windows. That’ll give you usage/free space remaining and is probably as discoverable as it gets short of creating an entirely separate app explicitly named “Disk Usage” or some such.
- falcolas 11y agoSimply getting to a finder window where I can do a "Get Info" on a hard drive requires finding your way to the "Computer" finder window, which requires digging in menus or right click context pulldowns on window titles (?). While it works on folders, it just gives you a question mark for the size while it is working out the size of the sub-items on disk with no indication that it's actually going to change that. So yes, there are alternative methods, but they are no more friendly to discoverability as the Apple Menu method.
- 11y ago
- j2kun 11y agoIt would be an interesting exercise to take a corpus of user CLI commands, and try to use the types and formats of the arguments to predict the command.
- zyxley 11y agoI don't understand what makes this more useful as a text-based thing, rather than, say, something like the OS X right-click Actions/Share menus, especially when when the latter can work on fragmentary parts of other documents without needing to juggle interfaces.
- epicureanideal 11y agoOne of the problems with this that probably occurs to everyone is that there are many more actions you can do with a file than there are files in a typical directory. So you might say > how file, and it might return 1000 things you can do with it. To answer my own objection, > how (or whatever the tool is called), or just the object itself as in the author's example, could display categorized actions, or offer a way to navigate submenus, or it could limit initial output to things that a non-superuser would want to do and offer additional options for superusers to browse more advanced options (or assume they know what other tools exist and use them directly).