I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console".
I realized that people love Slack because it has introduced them to the CLI paradigm of computing for the first time. CLI is so much more efficient and powerful if users can somehow be incentivized to put in the time and effort to become productive, which Slack has focused on a lot. As inefficient and silly as it may seem to us developers, Slack with it's endless command based integrations has succeed wildly at that where nothing else has so far.
Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under the same paradigm. They have some finite number of templates/recipes that they can respond to, and just enough "NLP" to attempt a fuzzy matching between what you ask for, and the triggers to the recipes.
The key point is that communication is fundamentally serial, in both voice and basic text consoles, whereas GUIs allow parallel communication streams (and hence "exploration") organized spatially.
I find it ironic how the same people consider GUIs a more newbie friendly interaction paradigm than the terminal/console, and then say the same for voice interfaces over GUIs.
Maybe because, the cli mode means, you need to remember the commands?
In GUI mode, though inefficient, you know exactly where to access help and a few basic params (like dropdown menu on top, usually save under file, cut and copy under edit) that smoothens the learning curve. They have some solid ground from which to start exploring.
Whereas under console mode, there is no unifying paradigm. So each tool has a different way of doing the same thing. There is a lot of inertia at the start. Like what command is it for help 'h' or 'h?' or 'help' or 'H' ? What command is it for quit 'q' or 'quit' or 'ctrl+d' or 'ctrl+c' or 'bye' ?
For example, in gmail, I expected archive to be 'a' and delete to be 'd' or atleast "DEL". Very basic operations and basic expectations. Turns out, archive is '#' and delete is some char I can't remember now (I think '{' and '}' to indicate whether to go to the previous mail or the next mail. A 'd' to go to next mail and a 'D' to go to previous email would have been a lot more intuitive). Of course, you can customize the key bindings, but then you got to go do it across all your accounts.
While people may be quite happy to be able to wield so much power within the slack environment, they are very quickly going to lose their enthusiasm with the introduction of each new console tool, unless what they have learned in the slack environment translates into easier learning curve in the next console env.
Basically for users to be able to adopt the console mode, there is should be some sort of standardization.
It seems like DWIM features gained popularity from the 60s to the 80s, but more recent systems avoid it in favour of explicit (although sometimes cryptic) error messages ("weak types", like `==` in PHP and Javascript, are a remaining example of DWIM).
This might be connected to the rise of GUIs: more "general user" software became GUI driven, or menu driven, rather than using a free-form input language. That reduced the need for DWIM as a way to help new/casual users. It also meant that the CLI software that remained was generally more powerful, and therefore more dangerous (e.g. bash rather than zork), in which case there's a higher chance for a DWIM system to cause problems.
TBH, outlook hotkeys generally are a mess like that - not even when compared with their "competitors", but also when compared with Windows itself. I can't even tell how many times I wanted to search for text in a long email only to find that "Ctrl+F" forwards the open email.
Press delete accidentally or intentionally and you should see a notification about the delete.
If you want to undo, then Ctr + Z. At least that's the way computers have worked for eons.
Ctr + Z is the reason I prefer computers to typewriters. Software without the ability to undo or reset actions are devolving the user experience to typewriter age.
"In GUI mode, though inefficient, you know exactly where to access help"
I wonder how useful "help" is to the average user. I've personally never been aided in a strange GUI by visiting the help. Usually there is a cryptic search box that returns useless results when I try to look for what I want, or else I'm presented with what is essentially a book to read about the entire philosophy of the interface. *nix manpages/infopages have a similar problem, but Windows help pages seem to be worse for some reason.
Help was the first command that came to my mind. Atleast in my very early days, (this was in early 2000s) I did use lots of help. Maybe help was better then or I was so clueless that even the insipid quagmire of the help pages still proved to be useful.
But in general, I am talking about certain consistency among ui. Say you have opened a new program and you do not know where to start. We can go to 'File' and there is sure to be a "New Document"/"New Object"/"New Diagram"/"New <whatever-model-the-program-work-with>" available to start.
Similarly Edit, Insert, Preferences, Script, Debug and their visual and keyboard access methods are all paradigms that are consistent across GUI.
At the worst case, you can do a systematic exploration of the ui to find all possible actions one can perform. This has to be standardized to CLI also for a shot at widespread adaptation.
Yeah, I guess we're talking less about "help" (F1 in Windows, or at least it used to be) than about the user-interface guidelines that mandate the "File" dialog and so. As for doing a "systemic exploration", this is largely the role that manpages or "-h" fills in traditional Unix programs, but you're right that we need a better solution for widespread adoption of a "modern" Slack-y CLI for nontechnical users. Maybe show HELM-style autocomplete "menu" of possible subcommands in the input area or sidebar?
> (I think '{' and '}' to indicate whether to go to the previous mail or the next mail. A 'd' to go to next mail and a 'D' to go to previous email would have been a lot more intuitive)
It's "j" for next conversation, "k" for previous - comes from hjkl, vim (and older [0]) keyboard navigation. Then "n" for next and "p" for previous, for emails within the same conversation.
Thing is, just like vim, these are supposed to become short-circuited so when in the right context, you don't think of the letters anymore. It's not "that key is j, which is up", it becomes "that key is up". It's the same newbie discovery vs power-user productivity problem described in the post.
Just as thinkmassive specified, I was talking about the two keys for "delete this email". One key deletes the currently open email and opens the preceeding email, another deletes the current one and moves to the succeeding email.
> Like what command is it for help 'h' or 'h?' or 'help' or 'H'?
It's all about smart desing of commands. In your example all of those options could work, plus options like 'he', 'hel', 'help', 'help!!!', 'Help???', and even 'HALP' or 'WTF?'. Combine this with smart autocomplete, and good hints (i.e. I don't understand 'hlp'. Did you mean 'help') and you can mitigate the drawbacks of CLI commands greatly.
As for Gmail, you are talking here about keyboard shortcuts, NOT commands, and that's something I completely different IMO.
also there's no method of discovering the commands in a CLI.
A GUI shows you what you can do, by having all the buttons and widgets displayed.
People google for "how to close Vim". I know I did when I started climbing that learning cliff. GUI's usually don't suffer this problem (except Google's UI's, which for some reason are bizarrely complex and hard to navigate).
It would be interesting to make an Alexa-style device, which instead of natural language used a set of composable voice commands, like Bash and the unix utilities but pronouncable.
Yes. At the moment, voice interfaces are a novelty and it makes sense that we're assuming they will use the language we use. But I wonder if that will continue?
Given one of the problems with voice interfaces is false triggering between humans and machines and humans and humans ("You want to know what?" "No, I was just talking to Alexa!" "Sorry, I can't find any results for that.") I wonder if in the far future we will have worked out a "machine language" partly for this reason.
It might be a bit like radio procedure words mixed with "machine syntax". So rather than "Alexa, give me a list of the top ten companies by market capitalisation", or "Alexa, who was the director of the Poseidon Adventure?" you'd say "Chip list market capitalisation companies ten" or "Chip, director Poseidon Adventure", where "Chip" is the universal signal for invoking voice commands (followed optionally by the name of the device you're addressing) and the grammar of the query is ordered from general to specific. This would minimise linguistic ambiguities and allows accurate but imprecise answers if necessary (eg if the machine can't order by market cap). It might also be sufficiently different for humans in earshot to screen it out. There might be specialised words too, similar the Bash and the unix utilities you mentio (eg for recalling queries and modifying them, stealth mode invocation, even piping perhaps).
Are you referring to Google Home being able to stack up a few commands or the routines feature?
eg Google, whats the weather and set a timer for 15min?
On Alexa you can enable a follow up mode which listens to the next command for a bit. It's a bit more natural, e.g. Alexa, whats the weather... you wait for her to complete, she then listens again and you can say, Set timer for 15min, she completes and listens, Read news, etc.
Sometimes I just feel like the machines are teaching us how they would like to be talked to vs us teaching them, as some commands require specific verbal markers in proper order to complete as otherwise they just give you a completely random answer or they simply don't process it at all.
Problem is it doesn't scale well for people. Imagine if everything you did in slack was via CLI - there are dozens, hundreds of commands to learn? Imagine if every app had dozens of commands you had to learn and memorize. Sure you could do it and be blazing fast, but that's a really steep learning curve a lot of users wouldn't adopt.
Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote <tab>`, a listing shows all of the possible commands, such as `add` or whatever. Just make the console smarter, _with good algorithms that aren't slow_, and people would use it a lot more.
On the plus side, by picking and choosing what you want, you can get the precise performance and usability ratio that fits you best. Fish is a great shell but nothing beats the zsh plugin ecosystem.
Or in my case: spend a bunch of time messing with and tweaking my shell config. Sometimes the tyranny of default options is helpful to getting things done.
Do you mean it just ships with support for a list of preset commands, or can it provide autocomplete for any command? (I have no idea how that could possibly work, mind)
Sure, but configuration is more powerful. I the shell a lot, I’m not going to choose a suboptimal solution for my use case just because of a little bit of configuration.
Yet there's no standard way for system and user programs to expose their parameters and help to the command line, like most TOPS-20 programs did. So bash's completion and help facilities pale in comparison.
PowerShell has this; all cmdlet parameters are parsed by the PowerShell environment, so you don't have to write argument parsing code over and over; parameters to cmdlets are a standard form with many using the same common names where it makes sense.
Because of that design they are long and readable words but tab completable, and ctrl-space will bring up a menu of available matches starting with what you've typed so far.
Indeed Don, why don't you extend gnu getopt to generate a special ELF section with an argument grammar and then modify bash to load this section? Shouldn't take too long and then this feature would become automatic!
A piece of system design "philosophy" had emerged at BBN and among some of the ARPA research sites that was to have a large impact on the overall feel of TENEX and, ultimately, TOPS-20. At the time, we called this "human engineering" -- we wanted the system to be easy to learn and easy to use, and we wanted the system to take care of as many grungy details as possible so that the programmer or user did not have to deal with them. Beyond that, we were willing to spend real machine cycles and real (or at least virtual) memory to make this happen.
This philosophy led initially to the human interface features of the EXEC, including "escape recognition", the question-mark help facility, optional subcommands, and "noise" words. Few people now argue against the need to provide effective human interfaces, but at that time there were many detractors who felt that it was a waste of cycles to do such things as command recognition. These kinds of things, they said, would "slow the system down" and prevent "useful work" from getting done. Other contemporary systems used short, often one-letter, commands and command arguments, provided no on-line help, and did not give any response to the user other than the "answer" (if any) to the command that had been entered.
[...]
Escape Recognition, Noise Words, Help
One of the most favored features among TOPS-20 users, and one most identified with TOPS-20 itself, is "escape recognition". With this, the user can often get the system to, in effect, type most of a command or symbolic name. The feature is more easily used than described; nonetheless, a brief description follows to aid in understanding the development of it.
A Brief Description of Recognition and Help
Typing the escape key says to the system, "if you know what I mean from what I've typed up to this point, type whatever comes next just as if I had typed it". What is displayed on the screen or typescript looks just as if the user typed it, but of course, the system types it much faster. For example, if the user types DIR and escape, the system will continue the line to make it read DIRECTORY.
[...]
Question-mark Help
Finally, if the user still isn't sure what input comes next in a command, he types question-mark, and the system will provide a list of choices that are legal at that point. The list includes specific keywords (e.g. FILE, DIRECTORY) and generic descriptions (e.g. "input file") Most importantly, the question-mark request does not destroy the previous command input. After the list of alternatives is displayed, the partial command is redisplayed, and input continues from the point just before where the user typed question mark.
As a result of this feature:
Users never have to go grab a manual and search around trying to find the name of a forgotten reserved word (command or parameter). This eliminates the "I know a word, can you guess it" aspect of many computer interfaces.
The user can often figure out from the choice of parameters what an unfamiliar command or option will do. This further eliminates laborious searching of manuals.
Because the context of the current command is not lost when help is requested, the user can go step-by-step through a command, figuring out each field in turn. In systems where getting help is a command itself, the user may have to write down a long unfamiliar command on a piece of paper in order to be able to enter it completely.
As menu-oriented interfaces have become more widely used, the advantage of having all choices visible to the user has become obvious. The question-mark help feature can, in retrospect, be seen as a "menu on demand" kind of approach, and it was one that worked even on terminals too slow to support full menu-based interfaces.
Origin of Recognition
The Berkeley Timesharing system for the SDS-940 had an earlier form of recognition. It didn't use escape however. On that system, recognition was automatic; whenever the user had typed enough to unambigiously identify a command or symbolic name, the system would spring to life and type the rest of it. This made for the minimum keystrokes in the ideal case, but had one major, and ultimately fatal, problem: if the user typed too much in one field, i.e. more than the amount necessary for the system to recognize that field, the input would go into the next field where it wasn't intended. For example, the system would recognize COP as sufficient for COPY and supply the "Y". But if you typed the whole verb, you would get:
* COPY Y
|
|- typed by the computer
Then, you would at least have to erase the extra "Y". If you didn't notice what happened and continued to type the remainder of the command, what you had intended as:
* COPY OLDFIL NEWFIL
would come out as
* COPY Y OLDFIL NEWFIL
This would at least produce an error, and in pathological cases could do major damage. [In the foregoing example, note that the old file name winds up in the new file parameter field.]
Actually natural language scales quite well. Aza Raskin and his father Jeff did a lot of good work in this area.
The discoverability of commands in a system like Emacs is much more powerful than a menu based system. In fact, I bet most people navigate the web now days by typing part of the URL in the omni bar and letting the browser fuzzy match versus mainting large bookmark lists.
I’m accustomed to typing “s” for StackOverflow, “g” for GitHub, “gm” for Gmail, and probably several others I don’t even realize. This sort of “smart” / reachable interface seems like an improvement over having to type entire words over and over.
Fish's abbr feature does this. They're aliases that expand in place. For example I have gph abbr'd to "git push origin HEAD", and I can continue editing the command after expansion.
Is there a way to expand special commands (and optionally aliases) in BASH without executing them.
Like if I put `ll !$` it would show, say, `ls -al /home/user/downloads` on a new line.
I'd love tab style completion that offered explicit history as well as standard completions. So if I `find` and then press the completion key-combo I get a list of the last 10 unique find commands (and I can choose one and edit before running).
This may be possible with fzf but I'm not sure of all the features it's capable of.
This type of behavior would be a great addition to the terminal or popular shells. Instead of having the command prompt always display at the end of output, have it stay in the same place at the top or bottom.
Something like you get with the Emacs mini-buffer with tools like helm but for the terminal.
Actually I got this by turning OFF fuzzy search. I don't use bookmarks anymore. I just type gi<DOWNARROW> or gm<DOWNARROW>, or st<DOWNARROW> and press enter.
I agree about the learning curve but not about your point that it doesn't scale. I, and many people I know from my generation that basically live in a command line environment (including often vim) know thousands of commands and their options by heart. It's like another language.
At some point you are fluent and coming up with the right commands and options is effortless. The challenge becomes being efficient and elegant.
Even then you learn about knew tools or options regularly and it's not a problem. It's much like with a natural language, there is no point were you stop learning new words.
CLIs work well when the universe of commands is small or the user is very familiar with the application. Discoverability suffers, even with man pages. Where a GUI helps is for the casual user who needs help understanding the options. An interface that can allow both styles of interaction has the flexibility to give both kinds of users what they need.
Ding, ding, ding!!! I've been beating this drum for a few years now. The interesting thing about chat bots is the UI not natural language processing.
I think people are completely overwhelmed by the massive lack of consistent UI the Web has brought us. I also think the more "apps" that could be brought into platforms like Telegram, the happier users would be.
There's also evidence of this in China where 100's of millions of people use WeChat for a large percentage of their needs.
Really? It seems that with the advent of Bootstrap and responsive design, website UIs are more consistent and generic than ever before.
Every corporate landing page is a jumbotron/full-width image, followed by three columns of bullshit, followed by a few rows of random glyphicons and more vague nonsense to cross the minimum text SEO threshold, and a footer.
The early internet was a much wilder place. Frames or no frames? Tables for layout or not? Dare we use an imagemap? Fuck it, let's do the whole thing in Flash. It was chaos.
Now, one thing that has also come to pass is websites with straight up cryptic UIs. Buttons no longer have labels. We have hamburgers and hieroglyphs. I think that might be more of a driving frustration.
I'd agree with you when you're talking about websites that are, for the most part static and just conveying information. But when you're talking about actual web applications designed to get work done I think things are wildly disjointed.
If I were to show you the web apps I interact with regularly, both personally and professionally, you'd see what I'm talking about.
At the very least all those mini UIs are cornered into a more standardized system just from the limitations presented by the chat environment. On the other end, most of the functionality can be driven from textual commands the way SMS "apps" used to be.
Of course the elephant in the room to this entire thread is advertising and analytics, which IMO is the biggest reason the web has devolved so badly. I mean it's much harder to generate revenue if you're just serving me textual content that I'm interested in.
You may check telegram’s games, services and other bots that allow to manage your entire world via chat (with programmatic buttons and menus to ease /cmds a little). I don’t use it much, but my coworker said that he almost lives there, visiting sites only for long, static content.
From this perspective, “we” don’t “need” as the article says, since it’s already there and writing a simple bot is a no-brainer. (Downsides of proprietary protocol are obvious.)
I’m not really into social games in my language (maybe should try english areas). Anyway, discoverability is a hard part of telegram. Like you don’t see tg-links on the internet often. For bots part I just didn’t go there yet – no particular need. I’ve written two utility bots for my company though.
Reminds me of a former coworker's Emacs workflow. He organized his work in orgmode. He used emacs for email, jabber, and irc. He would copy paste new tasks between email and orgmode, and he could copy paste the code snippets he was working on to irc if he needed help.
This can be, and probably is, automatically targeted by some simple pre-send hook. Basically, if you're trying to send >4 lines, automatically gist them and send URL instead.
I remember being giddy about the potential of Ubiquity to bring the CLI to a wider audience, and bring more power to existing CLI users. Too bad it never played out.
That kind of stuff comes up every so often. I heard rumors in the early 2000s about Microsoft implementing a version of Office that was more commandline oriented (this was when people were getting sick of their "smart" menubar, before the ribbon interface).
My partner is a lawyer and we both agree that the rich text editors are massively killing productivity in the space, where plain text is PLENTY powerful enough. The dumb shit they deal with documents and formatting and PDF's. It's fucking dumb, plain text & markdown for life.
But yes, Slack is basically IRC with a built in bouncer.
And i case people wonder, a bouncer or BNC, was a personal proxy that would be running on some server somewhere, and that maintained a presence on the IRC networks for you when you logged off.
And when you logged back on, you got a log of all the traffic on the relevant channels and direct messages while you were gone.
I don't think the sed syntax was implemented in an effort to make a good interface; rather, they simply implemented what many (albeit technical) users have been writing for years. I've been using sed-like notation to chat with colleagues for years. HipChat just chose to do something about it.
I believe you could also edit your last message with the mouse, or by pressing "up" (but I don't remember if that was opt-in).
Correcting yourself using sed syntax is a common IRC idiom. In that sense the design is sensible; you build your interface on what a lot of users already do habitually and let it have the desired effect. For everyone else it's just a very terse and simple syntax that anyway has an obvious mouse based equivalent.
Last time I used that feature was probably a couple of years ago (also on Linux). But I've not used Skype much (if at all) in the last 12 months so maybe things have changed since then?
Buggy mobile client (andriod) and dumpster tier performance are two areas they have been dropping the ball on since release, and requires innovation in some sense of the word.
Those are both very important. Innovation is generally important and I'm half curious as to why you ask.
> Buggy mobile client (andriod) and dumpster tier performance are two areas they have been dropping the ball on since release, and requires innovation in some sense of the word.
Making your program meet what really should be a minimum acceptable standard is considered innovation now? Multimedia chat clients that performed well and weren't crippled by bugs existed in the 90s.
> Those are both very important. Innovation is generally important and I'm half curious as to why you ask.
Has Slack's attraction ever been that it's an innovative product? My understanding is that it's all about convenience. It's like IRC+bouncer with some shiny things and without the hassle.
> Has Slack's attraction ever been that it's an innovative product?
Yeah, it's just IRC with a new hat, but sure, I'm willing to say it was innovative. Nothing like it existed and now many things like it exist. It was an innovation in the smaller parts - that judging by how things have gone, are maybe not so small.
> Making your program meet what really should be a minimum acceptable standard is considered innovation now?
It's not ~disruptive techmologi~ but it would require genuine innovation in terms of creating a proper cross platform native UI framework, or at the very lest a large shift in their product to move to multiple frameworks (innovation in the company rather than in tech generally.)
I realized that people love Slack because it has introduced them to the CLI paradigm of computing for the first time. CLI is so much more efficient and powerful if users can somehow be incentivized to put in the time and effort to become productive, which Slack has focused on a lot. As inefficient and silly as it may seem to us developers, Slack with it's endless command based integrations has succeed wildly at that where nothing else has so far.