Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

111–120 of 379 posts

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

#111
Get paid weekly by PayPal free to join click below for more information when you become a free member watch all the tutorial videos join the amazing facebook group learn step by step training from the best of the best free to start earning commission make money online Internet marketing opportunity try our marketing courses learn how to run a business from the ground up plus make money online real legitimate company Internet marketing opportunity for more information click below to join https://internetmarketingsolution.club

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

#112
post #6

Yes! I am so glad somebody called out the UI animations! The one in 1Password bugs me every time, I don't use Spaces because it takes too long for the animations to play out. There are more examples. Every time a programmer adds an animation, a settings option should also be added to "disable animations". Advanced users will love you for it!

I'm confused. By Spaces animation, are we talking about the horizontal sliding transition?

On my machine (High Sierra) the transition time between Spaces is dependent on the finger gesture swipe velocity. I'm not really sure I would even call this an animation- the Spaces x-offset is being adjusted as I move my fingers along the track pad in the same way as scrolling up/down in a browser behaves. There's literally no waiting for the "animation" to complete; when I lift my fingers I'm either in one space or the other.

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

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

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

#114
post #96

I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…

I think a simple data-display UI shouldn't be that hard to code. Every program you run has access to a terminal, which it can use to display and read text. It shouldn't be hard to extend that to displaying and reading structured data. One dream I have is to have a Desktop where each program can send an ioctl to stdout that turns it into a stripped-down browser, so it can then just dump XHTML data and have it be visua…

The difficulty is not just in coding the UI, but crafting one that's easily and intuitively understood by users. We haven't yet established a universal design pattern for GUI's yet, to the parents point, just a bunch of conventions that are often tossed in favor of something new.

A 'solved' UI example would be of a car (not the radio, but the operation of the vehicle). Learn to drive one car, and you can pretty much drive any car - same pedals, steering wheel, gear shift, turn signals, etc. I don't know if we'll ever get to something like that for software though.

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

#115
That "Composability" bullet point rang so true for me just now. There are command line tasks for which I can just be 10x productive. And it usually comes down to the simple portability of stream IO.

Cloud functions may create a set of standard libraries or tasks that can be ported to any interface. You can get a sense here from this snapshot from a recent Google Cloud Next talk:

https://imgur.com/a/RghGkQE

Many of the libraries are multimedia related. But its easy to see how the set can also include Cloud ML functions for pre-trained scene recognition.

Another welcome development is an anecdotal renaissance in IRC. Slack and Discord are killing it due to the ease with which new users can come onboard. But the communities forming around mission critical infrastructure, chaos engineering and SRE seem to rely on the old tried and true minimal ircd configurations from last generation.

There is no reason for web application entropy to make sites unusable. Modern browsers have high performance timers, request animation frame, gpu acceleration, background workers, and of course access to low level instructions via web assembly. It comes down to investing in the web again.

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

#116
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.

What you need then is a compact overview of what is available, like `man intro`, and something like `apropos`.

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

#117
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.

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

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

#118

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…

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

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

#119

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…

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.

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

#120
post #6

Yes! I am so glad somebody called out the UI animations! The one in 1Password bugs me every time, I don't use Spaces because it takes too long for the animations to play out. There are more examples. Every time a programmer adds an animation, a settings option should also be added to "disable animations". Advanced users will love you for it!

I'm confused. By Spaces animation, are we talking about the horizontal sliding transition? On my machine (High Sierra) the transition time between Spaces is dependent on the finger gesture swipe velocity. I'm not really sure I would even call this an animation- the Spaces x-offset is being adjusted as I move my fingers along the track pad in the same way as scrolling up/down in a browser behaves. There's literally no…

Agreed on the gesture, I feel that’s implemented well. But I suppose the author is talking about the animation you get when using the keyboard. I also find myself annoyed switching spaces on macOS vs. dwm, tmux, etc.

Something else: I got myself a tablet a few weeks ago and now find myself disliking the constant scrolling and wishing for (instant) pagination instead.

Post reply on HN