This had to make me laugh a little bit. Jaron Lanier actually designed this UI to intentionally be unusable and bad, because the film was described to him at the time as a Dystopian film, so he designed a computer interface to be equally dystopian. Yet, the effects look so cool, that people actually thought it was a good idea
Learning from Terminals to Design the Future of User Interfaces
221–230 of 379 posts
Re: Learning from Terminals to Design the Future of User Interfaces
#222The animations serve a valuable purpose, though, especially for new users. They show what's happening. Lots of old UIs (like those running in VT100 emulators) had instant wipes from one view to another, but made it impossible to tell what had happened, or why. Even when I wish animation was faster (like with Spaces, sometimes), I rarely wish it didn't exist at all. I often have people watching me, and with animations…
I agree. I've long thought that animation could potentially make it much clearer what's going on in Vim. Like if the user types 'das' to delete the current sentence, and it quickly highlights the text to be deleted, and then shows it shrinking away, as the text that was following it moves in to take its place. (Obviously, you'd want the animation to happen pretty quickly). Such animation could make it clearer what th…
Re: Learning from Terminals to Design the Future of User Interfaces
#223Earlier quoted context omitted.
I agree. I've long thought that animation could potentially make it much clearer what's going on in Vim. Like if the user types 'das' to delete the current sentence, and it quickly highlights the text to be deleted, and then shows it shrinking away, as the text that was following it moves in to take its place. (Obviously, you'd want the animation to happen pretty quickly). Such animation could make it clearer what th…
That’s great for someone watching over your sholder eg if you’re doing a product demo but less good if you’re on your own. There it just slows you down when you want to move on to the next task.
And why should it necessarily make things slower? The animation could be quite fast, and I don't see why such animations would necessarily need to block or hold up future inputs or animations. (I do think, though, that you'd need to actually try it out to see if it works in practice)
Re: Learning from Terminals to Design the Future of User Interfaces
#224The animations serve a valuable purpose, though, especially for new users. They show what's happening. Lots of old UIs (like those running in VT100 emulators) had instant wipes from one view to another, but made it impossible to tell what had happened, or why. Even when I wish animation was faster (like with Spaces, sometimes), I rarely wish it didn't exist at all. I often have people watching me, and with animations…
Classic Mac interface (one of best interfaces of all time, IMHO) actually had special animation to show how a folder opens from a small icon into a larger window with contents. The whole interface was very economical, they just could not afford extra cruft those days, yet they decided that this animation was crucial for understanding.
I’d compare that with the too slow IMHO animation when an app goes full screen on macOS.
Or look at Split View, it was clearly designed for ios touch and then later shoehorned into macOS.
My pet theory is that they left out keyboard ahortcuts for Split View because moving windows about with the keyboard would be too fast and highlight how slow the animations are.
Using a touch pad or mouse is slow anyway so you notice less.
Re: Learning from Terminals to Design the Future of User Interfaces
#225Earlier quoted context omitted.
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 communica…
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 differ…
Re: Learning from Terminals to Design the Future of User Interfaces
#226Earlier quoted context omitted.
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 differ…
Just so no one accidentally deletes an email on Gmail, 'e' is archive and '#' is delete.
Re: Learning from Terminals to Design the Future of User Interfaces
#227I 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…
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.
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.
Re: Learning from Terminals to Design the Future of User Interfaces
#228Earlier quoted context omitted.
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.
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.
Is there a terminal with similar ability?
Re: Learning from Terminals to Design the Future of User Interfaces
#229Earlier quoted context omitted.
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 `, a listing sh…
Re: Learning from Terminals to Design the Future of User Interfaces
#230Earlier quoted context omitted.
In a lot of ways, chatops is even better than a CLI. It basically can turn a channel into a shared terminal, with history, search, and the ability to comment
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.