8 ms·

No way. I've been designing and coding interfaces for 10 years, and time after time one of the biggest constraints for what is on/off the screen is the user's m

• 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 ago
    This is brilliant. Do you have suggestions for where I can go to read more about this idea?
    • mitchtbaum 11y ago
      This 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 ago
        I 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 ago
      The 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 ago
      It 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 ago
      Naked 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 ago
    A 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 ago
    Glad to see this suggested. This is very similar to why OO programming was such a more humane system.
    • miguelrochefort 11y ago
      A 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 ago
        Over 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 ago
    Interesting. 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 ago
      Except 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 ago
        Yep I'm wrong sorry.
        • kuschku 11y ago
          And then you have German, where VSO/VOS is a question, and SVO/SOV/OSV/OVS are normal sentences.
  • ap22213 11y ago
    Assuming 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 ago
      I 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.
      • ap22213 11y ago
        Yeah a basic CLI is super easy. I mean at the sophistication required to be as usable as the parent post implies may be more difficult.
        • qu4z-2 11y ago
          Do people build those GUIs without toolkits or GUI builders though? An advanced shell concept would presumably come with tooling too...
  • vitd 11y ago
    This 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 ago
      As 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 ago
        A 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 ago
          Simply 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 ago
    It 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 ago
    I 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 ago
    One 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).
• agumonkey 11y ago
  You're both right and wrong. Text doesn't mean obscure and cryptic. Things are converging. Emacs, light table, ipython notebooks. REPL, text, different views, both expressive and welcoming. GUI are to harvard for me, data and actions are two distinct worlds, too distinct worlds.
• DanBC 11y ago
  And it doesn't help that many man[1] pages are incomprehensible to some people. If I had FU money I'd set up a project to improve man pages, coordinating with the other documentation projects. [1] on Linux. It's a bit different for the BSDs.
  • uxcn 11y ago
    It's a little better with info documents.
• ddingus 11y ago
  Is there any reason why we aren't teaching a command line concept with the alphabet and multiplication tables? Not that I disagree on how discoverable a GUI is. However, many of us got that exact experience on 8 bit computers and it proved high value. There isn't a lot of difference for young people today. If they do learn what a command line is, options, syntax, pipes, arguments, they learn a whole lot. Done in the context of common apps they would use is a very good thing too.
• mitchtbaum 11y ago
  What about simplifying the range of options and making them more predictable based on common knowledge?
  • Avshalom 11y ago
    For what though? For image editing, file managing, audio play back, web browsing, text formatting?
    • deleted 11y ago
      [deleted]
• radicalbyte 11y ago
  I'm sure that people at Lyros, AltaVista and Excite were saying the same whilst building their heavy UIs before Google came along. The problem is on-boarding - once the user learns to ask for computer a question then the text (or voice) interface has the potential to be on a completely different level than a graphical interface. Just imagine - instead of searching through a dozen menus for an option you just ask. Hell, that's how most people work with Microsoft Office now - fumble around trying to find out where they've hidden the option. Fail. Open Google and type "how to change signatures in Outlook 20XX". Slack solve that brilliantly - their on-boarding is well designed - the way it gradually introduces features and reinforces concepts is excellent. It reminds me of modern videogames in design.
  • _of 11y ago
    > Lyros Lycos
    • radicalbyte 11y ago
      Oops. Dunno who voted you down, considering I can no longer correct the typo this post adds value :)
  • ryanpetrich 11y ago
    Oddly enough, the team that built Slack first worked on a MMORPG.
  • duncanawoods 11y ago
    This is not a good example. Google did not beat Lycos etc. by on-boarding any non-geeks to text commands, instead they proved the effectiveness of page-ranking dumb searches. Non-geeks do not use additional search syntax compared to the number using the nice obvious and clickable "Images" or "videos" tab.
    • felipeerias 11y ago
      The Google example points at one mayor constraint of text-based UIs: either you severely restrict the language that people can use to query the system, or you will be dealing with a really hard, Google-size problem.
• omginternets 11y ago
  What about semantic UIs a la spotlight? I always found those convenient because they allow me to dump what's in memory rather than seeking out the elements that correspond to what I have in memory.
  • Flow 11y ago
    That is more or less like M-x in Emacs, especially if you have Helm activated. But OS wide.
• indubitably 11y ago
  What's a "pleb"? Someone who doesn't live in San Francisco?
  • klibertp 11y ago
    https://en.wikipedia.org/wiki/Plebs https://en.wikipedia.org/wiki/Plebs
  • fit2rule 11y ago
    Yeah, your snark is getting down voted but the OP is not, probably because something about it 'resonates', and by resonate I mean 'has mass appeal', and by mass appeal, on this particular subject, I mean 'probably adopted the snark from someone they heard in a coffeeshop', i.e. San Francisco. Have an up vote.
• ised 11y ago
  "Want to know why the command line is hard for plebs?" Not really. These type of comments are almost always pure speculation, based on one's own experience. Here's one thing that is true: Everyone who uses the command line was once a "pleb". Txt'ing is what its name implies. Typing short lines of text. (And anticipating a quick response.) Seems reasonable to make a comparison to using the command line. IRC, or today's "chat", is also arguably similar. Typing short lines of text, and expecting a quick response. I have wondered about this for years as SMS and later Twitter, and now "enterprise chat", i.e., typing short lines of text, became popular. But winning a popularity contest for how people interact with a computer is not something that really interests me. My prediction based on last 30 years of computing history is that command line interface is never going to disappear (that is one reason I stick with it). It is there for whomever may discover and choose to use it. "They don't even know what they don't know." Exactly. And yet countless GUI lovers/CLI haters continually ask us to believe that some hypothetical user would _choose_ not use a command line interface when they do not even know that such a thing exists; they were never given a real choice. Who cares what other users want to use? It is their choice, not yours. Give them a choice a see what happens. Experiment.
• zamalek 11y ago
  I mostly agree with you. There are related exceptions. Take the Metro UI language as an example - minimal use of icons, high usage of text and plain shapes. It's becoming quite pervasive, the new iPhone UI is loosely Metro and Material seems to be inspired by it. On the disagreement part, one thing is particular stands out: > Interacting with the stream Only developers care about that.
• brudgers 11y ago
  Design paradigms based on mapping of user interaction to memory rather than intent may be the reason that memory is a constraint. Query is to memory as search is to intent.
• ksk 11y ago
  I think you're dismissing this idea prematurely. >Want to know why the command line is hard for plebs? It wasn't hard for the decades before GUIs. Why is it hard now? Are you conflating not knowing with being hard? >It's because they don't know what the options are. They don't even know what they don't know. The same criticism applies for voice interfaces. If the users can expect the command line interface to be similarly intuitive, then it becomes easy. >This isn't going to change anytime soon. At least not until terminal commands are taught in school alongside the alphabet and multiplication tables. Why do they need to be taught commands? Maybe the command processors need to be taught different ways commands can be expressed and composed.
• fit2rule 11y ago
  I've been designing and coding interfaces for 30 years. Text is still the #1 easiest and most efficient way to train a user on how to use your app. Go ahead, do something productive without using text.
• aexaey 11y ago
  The answer to the "knowing what options are" is auto-complete [0], [1]. (Almost) nobody knows all the commands by heart. [0] http://www.cisco.com/c/en/us/td/docs/security/fwsm/fwsm31/command/reference/fwsm_ref/usecli.html#wp1046291 http://www.cisco.com/c/en/us/td/docs/security/fwsm/fwsm31/co... [1] http://zsh.sourceforge.net/Doc/Release/Completion-System.html http://zsh.sourceforge.net/Doc/Release/Completion-System.htm...
• ape4 11y ago
  This is something that I don't like with so many mobile apps. The options are evident by looking. Tinder has swipe left, right. Pinch to zoom. Buttons are just text, etc.
• openfuture 11y ago
  As soon as I learned to start every interaction in the CLI with the word 'help' I became many orders of magnitude more proficient with it. Good CLI programs have a relatively straightforward path from 'help' to where you need to go. Contrast this with GUI's, which is what people are familiar with: - The help is basically the instructions manual for your new gadget that you won't read, too detailed, not helpful and you'd rather just play with the thing and learn how it works. - That's also how people solve problems, by playing around with the available options in the interface or if you are a 'superuser' by googling. So basically people have been trained not to ask the program for help, they'd rather go on the internet or ask their tech friend for help. Which means they are predisposed to not 'get' CLI programs. There's also the fact that man pages are way to threatening (and ancient). They should be structured like a wiki (with links between each other and to definitions as well as a conversation layer for improvement etc.). Telegram bots are CLI programs that follow the unix philosophy (in a sense) and are a step in the right direction when it comes to starting an organic conversation with the user. However they are also very small programs and there is still a lot of improvements to be made. So no terminal commands don't need to be taught in school and GUI's aren't the ultimate solution. If we were to pour the same amount of effort into improving CLI interfaces as we have with GUI's computers would become much easier to use. However that doesn't mean that CLI's are the ultimate solution either. Hopefully people will one day realize that personifying tools is actively harmful and that everything is context dependent. Edit for formatting..
  • emj 11y ago
    With CLI help we could do a lot better than we are doing, when I used Juniper routers I found that very refreshing they really tried to make help very easy to get.
• AdmiralACK 11y ago
  Because it's really hard to type "?" or "help" into a command prompt? Please. It's not difficult to do at all. No one needs a GUI, it just makes it easier for "mom n pop" to do their thing.