The future of UI is text
partyline.rocks
partyline.rocks
Want to know why the command line is hard for plebs? It's because they don't know what the options are. They don't even know what they don't know.
The whole point of a GUI is to convey the possibilities. Show users a menu and they get to pick something. This isn't going to change anytime soon. At least not until terminal commands are taught in school alongside 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.
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.
Lycos
Non-geeks do not use additional search syntax compared to the number using the nice obvious and clickable "Images" or "videos" tab.
I disagree, and I think we can see the counter-example very clearly with altavista.
You could go to altavista and type in "dumb" search queries, just like google.
But simultaneously, with no change at all in the UI and no constraints imposed on the "dumb" users, you could also type in very sophisticated boolean searches like:
linux grep ("regular expression" and "regex")
and get very precise and sophisticated search results.
I miss this every single day
That's what I was trying to get at :)
For the time I'd also argue that their "on-boarding" was excellent: a textbox and two buttons, you can't get simpler :)
The 2015 equivalent would be adding animated instructions in a pencil typeface on the search box and buttons. The demographics and expectations are different now.
A lesser example: half the time I want to use a menu-item in OSX now, I find it by going to the Help menu and typing something in the fuzzy-match box. I'm not sure why this hasn't been made the primary OSX menu interface.
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.
(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 ;)
echo "My random thoughts" | tweetIt 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.
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).
For practical reasons it isn't always text, but more importantly (the first bit is a subset of this problem): almost every program has to understand (100%) the output of every other program it has to interact with.
If output were typed our applications could ignore (reliably) the bits they don't care about.
If output were typed we could search by output-type (e.g. diff produces patch-like-output, so don't bother piping to "xargs", but allow "less" (any type of input) or "git apply" (patch-like-input) or "patch" (patch-like-input).
Types could add a huge amount of searchability to CLIs -- and for some reason this isn't appreciated even though we've seen it in a much more limited context such as OOP.
(I think my original inspiration for this line of thinking is Paul Chiusano, and he probably deserves most of the credit, honestly.)
EDIT: Actually, pondering this a little more: All programs should be forced somehow(!) to carry a "source location" for the source of their output. This is such an annoyance in the daily life of a programmer if you perform a chain of commands like "git diff ... | grep FIXME | grep ^+ | ..." just to get a grip on the FIXMEs you've introduced. The output doesn't show line numbers, because... well, for no really good reason, really. It's just that transformation as text meant that we sort of lost that bit.
grep -n '^+.*FIXME'
Note: on a phone so -n may not be correct.
EDIT: ... and it's actually possibly(!) even worse in the web world where you often have a ridiculous number of levels to your "transformation". Personally, I have never got "bower (source) -> grunt -> ts/(scala.js+closure) -> babel -> es5" (with source maps) to ever work even semi-reliably.
(I know we have too many things in this pipeline, but it's what we have to deal with.)
Basically, however widespread our personal workflows are, there are vastly more workflows we havent't even thought of that are essential to someone else's livelihood, for whom automatic numbering (or whatever) would ruin everything.
As for source maps, yeah, that's got room for improvement.
Hah!
EDIT: I had a really complicated thing here, but decided to delete it... because I don't think anyone understands any of this "computers" thing properly, including me. Hope you understand :).
EDIT#2: Is there a "flowers for you" emoticon?
While I mostly agree with your thesis that types could be great in the shell, I think this particular bit is incorrect in a way that undermines your argument (not, I think, fatally). If a program's output doesn't match up with another program's input, a bit of sed (and maybe some awk) will usually do the trick. And if we added types, that would still be the case - output from one command would have to be the right type to be input to another.
Btw, I didn't mean that types should be the arbiter of "a | b", just that it should guide the search process. Obviously, you should always be allowed to really choose "c" even if the system determined "b". But our UI could be so much efficient if the system chose "b" most of the time.
EDIT: Classic case, btw: "find ... -print0 | xargs -0 ...". Unless we have pervasive and dependent types, how is any formalism going to know that?
Well, it's been sufficient. That doesn't mean we can't improve on it. My point was simply that assigning types doesn't actually change things - it is still the case that every program needs to be able to interpret whatever is generated by every program you want to pipe into it, or you need some kind of translation.
'Classic case, btw: "find ... -print0 | xargs -0 ...". Unless we have pervasive and dependent types, how is any formalism going to know that?'
Dependent types aren't necessary for that. They might be necessary for `find ... $MIGHTBEPRINT0 | xargs $MIGHTBEDASH0`
Edited to add - or wait, you mean the resulting command built by xargs may have a type dependent on the arguments produced by find? That's... messy, yeah.
Yes! Thinking about interactive CLIs... yes.
EDIT: I should add: My main point here is that types would constrict the search space to be reasonable, rather than seeing that "1200 commands are available, do you want to show them all?" prompt. I really think we could be doing much better in this space.
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...
"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.
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.
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.
The answer lies in your question. A lot of power user (yes, relative but Apple have focused on consumer) functionality is buried in the gui, and every release pushes stuff deeper in to the interface.
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).
GUI are to harvard for me, data and actions are two distinct worlds, too distinct worlds.
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.
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.
On the disagreement part, one thing is particular stands out:
> Interacting with the stream
Only developers care about that.
>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.
Go ahead, do something productive without using text.
[0] http://www.cisco.com/c/en/us/td/docs/security/fwsm/fwsm31/co...
[1] http://zsh.sourceforge.net/Doc/Release/Completion-System.htm...
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..
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.
This should have been called "The present of UI input is text for this particular use case".
Text (or speech) as an input method is alright when you know exactly what you want. However, this is not a very good exploration interface, where you need to interact with things that are presented in a 2D/3D space. Text also isn't very expressive when it comes to consuming content.
The future of UI, in most cases, is no UI. Let some AI study and understand you, and let it make decisions on your behalf.
Humanity needs a formal language, which requires formal thinking. Ambiguity is not a problem when a language is used to browse, explore and clarify thoughts, but this kind of interaction needs to be feedback-driven.
You can't just input an ambiguous natural language query and expects accurate results. However, you can start with an ambiguous natural language query, and quickly make it into a formal one thanks to smart auto-completion. Only when the query reach a formal threshold should it be executed.
Words are better than pictures of hamburgers and floopy disks because we think in words not icons.
Assuming for the moment that this is a desirable outcome, how would you train that AI?
Today we have a vast programming industry and software supports a huge amount of what we do, yet we still struggle to write non-trivial software that behaves correctly in all cases. That’s partly because even with precise and unambiguous programming languages, specifying exactly the behaviour we want turns out to be hard. It’s also partly because we sometimes don’t even specify what behaviour we want in advance, because we forgot to consider a certain case or didn’t anticipate a certain interaction.
What you’re talking about would require advancing beyond programming with precise technical instructions and into creating systems that can handle complicated but unanticipated situations in the way the humans running the system would choose themselves or at least consider an acceptable or desirable alternative. But how will such a system “study” and “understand” what is required of it in an unanticipated situation?
I’m not saying no-one will ever have better ideas than we have today for dealing with these issues, but I suspect we’re a very long way from achieving the kind of general purpose AIs you’re talking about. I can believe that within some of our lifetimes we will see systems that make educated guesses but are on balance more reliable than humans in certain specific cases, perhaps if the people working on self-driving cars continue to make good progress. On the other hand, that’s also a great example of something where some very smart people have been working for several years and with vast resources to handle a single situation that we teach kids to deal with after a few days of training, yet they’re still a long way from the kind of futuristic AI we’re talking about, which perhaps gives a sense of how hard this kind of problem really is.
Sigh.
If anything this points to the future of UI being a combination of text and point and click.
People who use Twitch a lot love to use them. People who don't use Twitch much don't bother. This backs up the argument that power users like macros.
When people use emojis and other such things they usually use a text macro.
True, but that might be because PC keyboards don't have emoji. There's no other option. People certainly don't use a macro on mobile; they use a an emoji keyboard because that's what they prefer.
If you've noticed with programs like photoshop and illustrator, it's recommended for novices to learn all of the keyboard shortcuts.
There's an assumption when you're learning something with the end goal of understanding that application that you're on the first steps to becoming an expert (aka power user). If someone is only learning how to achieve a single end result they don't start with the shortcuts. For example, someone who just wants to learn how to resize and crop images in Photoshop just learns the two or three features they're going to use and then they stop.
I don't know very many people outside of the software industry who are happy with a command line interface, and even fewer who're happy with macros on a command line.
Also, if Partyline is the future, then I don't like it. The two examples in the article are inconsistent;
/partyline create Signup endpoint is 500'ing label:bug
vs
/partyline create:task Write about the future of text-based interfaces
Why is the first one using a "create" verb with a "bug" label and the second using a "create:task" verb? Why not "create:bug" in the first one, or "label:task" in the second?
I actually set up the few emoji I use as macros, so I don't have to switch keyboards. Then again, I fall into the power-user category
Text generally has a higher signal to noise ratio, but I wouldn't agree that interfaces are evolving that way. Text is typically a power user interface, but I it could probably be more effective for simple things too if it were designed well. It's faster to interact with (see Fitts' Law) among other potential benefits.
If i were to find out who is starring in a movie for example i would search for the movie title, click on imdb and browse through the actor-list. If a non techie would do the same thing the query would be something like "who was the lead actor in X?".
Now translate this into replying to a comment in a bug tracker, google has thousands of engineers just working on interpreting "stupid" queries, there is no way this type of AI can scale and work against some arbitrary API to a bug tracker maintained by 5 people.
Discoverability of available commands is also still an issue, not even solved by google. In their case people only know about one command because there is only one: search. If you were to add commands such as "create task", "reply", "send email", "tweet", how would that even work, is it first interpreted as a search query about how to send emails and then it suggests opening your email client? While it's a nice way to start your email client, and exactly how windows start menu works, it doesn't help any further in the workflow of translating GUI-tasks into command line tasks because it only takes you past the first step.
Stricly using commands, discoverability probably is still an issue. Text doesn't necessarily need to be command based though. For example, if there are 10 (100, 1000, etc...) options on a screen I suspect it's probably easier to select using text. In some ways it could be similar to a touchscreen.
The second example is about using /remind.
The third example is about using a command called /tweet.
None of those are from software development workflows. It's not until the fourth (and final) example that a dev workflow is mentioned.
It's super intuitive, entirely customizable, and every button press results in a listable text record of each command with combined access to either windowed variables (spline radii, inputting coordinates for start and finish points, entering macros on the fly, routines, accessing algorithms)
This has all been old news for decades.
Now, adapting Autodesk's approach for other fields?
Can't be impossible. Still, engineers in many fields have enjoyed such flexibility as a matter of course. Take a page from their experiences.
If you are optimizing for some variable (speed, ease, movement, etc.) there are cases where each of CLI and Mouse are the best choice.
For instance, selecting text: I know very well how to do this in screen, pine, vi, etc., but there's really no point and it is never the right choice. Even in a fully CLI terminal environment with not even a browser open, I do still want a pointing device for selecting text.
Unfortunately, the current paradigm of tools for gui's (and even cli's) remain incredibly static and inflexible in their approach and design. It's not a problem that we don't know how to do it, as the autoccad example shows, but rather developers and companies lack the gumption to figure out how to make portable libraries and platforms based on it.
By this I mean, that the autocad program would have to have some kind of dynamic data and code system with rules and an internal grammar for composing them. It reminds me of the old joke "every program evolves until it reimplement common lisp -- poorly". This can be done in C++ and java, etc, but you end up basically building your own dynamic lisp like system. This often gets encapsulated in design patterns built into complex class hierarchies.
Basically, my take is that while it's possible to build on autodesk's and others examples, most efforts are either too academic and esoteric or just poorly executed. I think the culture in development is getting to a point this approach could be widely adopted.
> The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).
>In the past, we thought the future of computing would look complicated: lots of buttons, multiple screens, and crazy interfaces.
... followed by a shot of the 1960's Star Trek ship's deck, then saying we're headed for command lines instead. Since 50 years have passed since that set was designed I thought I'd google how designs have changed. Here's the space shuttle
http://cdn.visualnews.com/wp-content/uploads/2013/03/Discove...
and here's a modern ship
http://www.motorship.com/__data/assets/image/0020/705404/THE...
Still looks more like lots of buttons, multiple screens, and crazy interfaces than command line to me. Still give it another half century.
I wish CLIs would become more popular amongst the general population, but it seems GUIs (which are also becoming "flatter" and less discoverable, ironically enough) have taken over completely for almost everyone.
I like the terminal, and I am also a reasonable touch typist. I don't particularly enjoy typing though. I've tried a few different keyboards. And I _do_ get the power of the CLI. But I think it's a barrier to computer input. And it's a barrier to free conversation. Check Youtube comments for example. I think some of the terseness (think Twitter) results as a result of text entry being laborious. I'm not familiar with using a tablet - and I always feel somewhat restricted and impotent when using mobile devices, which I figure others feel when using a keyboard.
OSs could make text entry far better and centralise it. Portable dictionaries and shortcuts for example. Yeah you can do that by keeping shell scripts on a remote, but it all feels a bit hodge podge.
Jumping from one CLI to another, different apps, etc can feel nasty. And I'm personally not happy putting my primary CLI in a cloud based SILO.
Didn't have. A screen.
So I asked the guy, "Where are your MP3s?" (Answer, "D:\Mp3"), turned on the computer, then hit:
- WinKey-R
- D:\ <Enter>
- Mp3 (quickly, in order)
- Context Menu Key
- P (as in "P"lay in Winamp)
Let me see you control a computer blindly with nothing but a mouse :).
- WinKey-R
- narrator <enter>That's not to say that you couldn't come up with an interface for controlling a computer blindly with a mouse.
The future of UI is having graphical and text interfaces at the same time. Throw in touch, speech and sight for fun if you want. None of it is going away. Most programs need a simple and very well thought out GUI, aimed both at new users and at discoverability of features for experienced users, and more powerful text based interfaces and keyboard shortcuts for power users. This is what the best programs do now, and what Slack does too.
The interesting thing about having both/multiple kinds of UI is that it guides the overall design structure of a program. Having both GUI and text interfaces forces MVC patterns to emerge, and it requires having a strong underlying foundation for your data and the operations that manipulate it.
*edited for typos
I understand that this works for some things. A command-line interface is good for giving commands! Yet using it to paint is a lot harder.
Essentially, text interfaces are good at manipulating text. As a software developer you're often manipulating only text. So you think text interfaces are good, always. This is a syllogistic fallacy.
This has the effect that we actively reject some really good tools as being 'unsuitable for programming' because they are hard to work with with our text based tools.
I think there's a lesson in both directions here: the fact that often the kinds of tools software developers use could actually be of use in some other domain (lawyers could get a lot of benefit out of distributed version control and markup languages, for example), but also software developers can sometimes get caught up in text editors and command lines and forget that sometimes a nice graphical visualization or interaction is really helpful.
Tree:
'(root (left (left-left left-right)) (right (right-left right-right)))
'(graph (#1=node1 #2=node2) (#2# #3=node3) (#3# #1#))
> Yet using it to paint is a lot harder.
Sure, but drawing is only one activity among many possible activities.
> As a software developer you're often manipulating only text.
I think that's true for most users: they are reading articles (text); writing comments (text); sending social updates (rich text); watching videos (not text); playing games (not text, but may have textual content, e.g. in-game chat).
You lose spatial intuition with this representation. You could make up for it on small trees somewhat with indentation and vertical spacing, but you'd lose it again for larger trees and graphs. We don't pictorially represent our trees like this [1], for instance, which is roughly how the S-exprs visually appear.
When I author graphs in LaTeX, it is often easier to run through a compilation cycle to see what the result looks like and which edits are needed, rather than mentally reasoning about the edges by looking at the code.
Text based interfaces and audio programming languages such as SuperCollider open up a whole new world of musical creativity, and would lend themselves to collaboration (IMO) better than GUI based ones. The obvious hurdle for people is learning how to create things/music/art with text.
https://supercollider.github.io/ http://sccode.org/ music written with supercollider: https://open.spotify.com/track/4VecDB1uhp44posWgt85yN
It would be great if there was a system-wide, standardized way to do this in every app, but until an OS with this ability exists, we'll just have to do it ourselves.
It's not really practical to use Emacs as your only OS right now, but it certainly has many of the applications I need day to day: a text editor (obviously), a web-browser (that can display images, but currently does not run JavaScript), a PDF viewer, email clients, feed readers, command shells, several videogames, etc.
I was hoping I would be able to things like the following -
* backup Fizz Buzz project (and have it intelligently backup the Fizz Buss Visual Studio project to a default location)
* open Fizz Buzz issue 131 (and have it open a browser to the github issue tracker to the correct issue #)
* email the Fizz Buzz project plan to Jim (you can *kind of* do this but it hardly ever works as you would want)
* open Fizz Buzz todo.txt when I next login
* copy the Fizz Buzz project plan to my Dropbox projects folder
Considering most (all?) of these things could be done with PowerShell cmdlets it is annoying there is no way to script Cortana via PowerShell in such a way.
Maybe one day.
As far as I can tell it is not [yet?] possible to integrate features from a classic Win32 application into Cortana to do things like I listed. Shame as that would have been very cool.
My examples are very specific to my domain for sure but they were just some examples for my use, the general concept of using Cortana as an actual digital assistant to automate/speedup boring and often done tasks.
The future of UI (for the general public) is probably voice-based like "Hey Siri/Google/etc, I'd like a sandwich" and a sandwich is ordered and delivered to you. "Tweet 'Who's down for a sandwich party?'" and a tweet is tweeted.
Whenever I hear or read someone argue that "command line is the future" I think of my dad; barely able to make a bookmark in a browser and not really knowing how folders work. And he's been using a Mac for decades.
Having seen the pain of many users even when trying to dig down through a GUI they're unfamiliar with, I think that while text based interface are often more powerful there's a long way to go before they're more popular.
Even worse, it is marketing that failed -- all it has done here is invoke disagreement from a tech community.
Sigh...like so many other things, what is old is new again.
Forcing people used to touch interaction with their phones to grok command line UX seems more like wishful thinking then the Next Thing.
If we're going to go this route, let's at least use something not so patronizing and infantile, like HipChat.
And I'm pretty sick of all these "Slack is going to change/has changed THE WORLD!!!" articles in general.
Ordinary people type web addresses into browsers...or heaven forfend, at least "microsoft" into their Google toolbar for IE8. There's a point at which information redundancy is overwhelming even for people who don't care about information theory or how the web works or anything else.
The WIMP interface was a great innovation. But it was built for a time when women were in the typing pool, entrepreneurs were called "businessmen" and managers were afraid of catching keyboard kooties. The meteor hit and CEO's type their own correspondence and answer phone calls on their direct line [which lives in their pocket].
There's a case [and a reasonable counter case] to be made that WIMP was the installation program for widespread computing. Once the important system is up and running it can be discarded. The degree to which this is plausible correlates to the inverse to which one sees WIMP as an end in itself. Yesterday, it was rounded corners on shiny buttons, today it's flat sharp corners. In the interim, people have learned from experience that pixels can't cut human fingers. A buggy whip industry would count this as progress.
Given that I don't think I'll be looking to Slack as "the future of UI".
I am the one who designed it, and I can confidently say that engagement is way higher than using traditional forms and button. The bounce rate is extremely low, almost everyone at least tries interacting with the bot.
Now this is not a testimony that text will always beat traditional web UI, I think a big factor in this case is the fact that it seems so unconventional and people are curious to try it out. Also depends on the purpose of the interface you are creating. Like 1971genocide pointed out, UI is good for giving commands and not learning for example.
In our case, it was important for us to get a limited number of very precise information from the user. Therefore having a Text based interface worked out.
That is more a long-term goal. Currently the future of UI is physics systems. The little bit of UI animation that happens today often uses interpolation routines (e.g. easing in it's many forms). Interpolation is time based and has annoying limitations like it is hard to coordinate multiple animations, it is hard to update animations smoothly on the fly and it can be non-trivial to reverse out of an in-progress animation.
I think we'll see a strong movement towards natural looking physical based movement throughout the UI.
> Americans' preference for mediated experiences is obvious enough, and I'm not going to keep pounding it into the ground. I'm not even going to make snotty comments about it—after all, I was at Disney World as a paying customer. But it clearly relates to the colossal success of GUIs and so I have to talk about it some. Disney does mediated experiences better than anyone. If they understood what OSes are, and why people use them, they could crush Microsoft in a year or two.
There's so much expertise in animation, games, 3D, physics, illustration etc while most UIs are boring, boxy, and slow. The UIs inside of simulated computers in computer games are cooler than the actual UIs!
I wonder what will happen with virtual reality UIs. With movement tracking you could really get next-level point and click. I want my IDE to be a VR spaceship mission where I write code with some kind of sign language syntax!
Pixar artists will be switching to CLI, over direct-manipulation graphical interfaces?
Sound-designers will use text to look at waveforms?
The title is overly broad because it focuses on only a certain class of applications.
Together with intelligent completion (similar to programming environments) text UI could in many cases be significantly more convenient than widgets for mouse. And it can be much cheaper develop.
Text UI is a great way to hide complexity but difficult to teach and form habits around. The learning curve is steep and probably something we need to invest more in because "have you read the man page" isn't gonna cut it for most.
To update the view call update_content(0,"Some\nLines.") on the appropriate Pane object.
Not for learning. When I see a UI of an app - I can at one instant see all the possible things that can be done using it.
text starts becoming a problem when their is a combinatronical explosion in what you can do with your app.
I cannot imagine Photoshop, Maya or After Effects to be text based.
Its a fairly interesting computer science question to me.
Copy and Paste, although poor operators in retrospect, is such an example. Undo is an other, much better one.
I firmly believe that we could reduce or eliminate most application-specific commands by increasing the standard set provided by the OS. Some kind of semantic primes that could be composed into anything. A new UI language if you will.
The real heavy lifting comes from the tight integration between MEL and that GUI, which permits all sorts of things to be made and then quickly manipulated using the SAME MAYA GUI.
But What I meant is When I started working with Maya initially - I was already put off by the extremely complex GUI. Trying to program ? I do not think many programmers appreciative the deep learning curve needed - and the average modeler is not adequately equiped.
The data is complex, there are nearly always multiple interaction modes, selections, etc... going on too.
Back when I learned on 8 bit computers, it was kind of easy because they didn't do much. One soon found themselves into the guts of the machine doing assembly language to make any magic happen. All from books, magazines, peers, etc...
Looking at listings was high value.
Well, today we've got YouTube and it's awesome! I can watch somebody model, or program, or do both.
It is a deep curve, but we've got so much better learning now. Back when I learned CAD and things like MAYA, I had to do it old school. Get the book, go. I had the advantage of some peers who would give me some help, or do a quick tutorial. Know what? I videotaped one of those, a little precursor to what we have today.
There is a worry I have of hobbling great UI models by over engineering this learning curve bit. Where we can simplify, we should, but not at the expense of the peak use capability possible by experienced and adept users.
MAYA, and many CAD packages are bending that line, and it hurts at times. People who know their stuff could be sharing it just as much as relearning or working around the changes needed to reduce the need for said sharing.
ImageMagick is amazing. There are certainly tasks for which the interface is more awkward than Photoshop (or GIMP), but there are tasks for which the opposite is true. For instance, I was easily able to write a script for "take a screenshot, detect where the variably-sized error message box appears within it and crop to it".
This is by far the thing that eats the most time when I'm working on the commandline.
All that has been done before. It should be done more.
https://www.youtube.com/watch?v=ubNfWarTawI - how UI replication will be used in the matrix