Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

221–230 of 379 posts

Re: Learning from Terminals to Design the Future of User Interfaces

#221
> I think we can all agree that the interface of this prospective future is incredible and desirable, but if we drill into it, what’s its most amazing aspect?

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

Re: Learning from Terminals to Design the Future of User Interfaces

#222
post #28

The 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…

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.

Re: Learning from Terminals to Design the Future of User Interfaces

#223
post #222

Earlier 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.

I gave reasons why it could help the user themselves. (Here's another: for users learning Vim)

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

#224
post #28

The 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.

Agree the Classic Mac animations were really good and didn’t really slow you down.

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

#225
post #212

Earlier 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…

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

#226
post #212

Earlier 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.

That's what ctr+z is for isn't it?

Re: Learning from Terminals to Design the Future of User Interfaces

#227
post #113

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…

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.

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.

Re: Learning from Terminals to Design the Future of User Interfaces

#228
post #113

Earlier 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.

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.

Is there a terminal with similar ability?

Re: Learning from Terminals to Design the Future of User Interfaces

#229
post #113

Earlier 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…

I've been working this way in my shell for a couple of decades.

Re: Learning from Terminals to Design the Future of User Interfaces

#230

Earlier 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.

He'd get a lot of flack unless he gisted his snippet first. But, of course, we have gist.el.
Post reply on HN