Learning from Terminals to Design the Future of User Interfaces • Hacker News Board

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

#331

Post by b0rsuk » Sat, Aug 04, 2018, 6:33 PM UTC

ken wrote: 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…

You just gave me an idea for a vim plugin... I guess it's already done? Recent changes could be highlighted with a background color. For example changes from the last 10 edits would have green background. That way if I pressed a key by accident and caused vim to change who knows what, I could spot it.

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

#332

Post by tomaskafka » Sat, Aug 04, 2018, 6:36 PM UTC

rtisdale wrote: post #240

NegativeLatency wrote: post #189

Earlier quoted context omitted.

But it needs plugins, fish has it builtin. Nothing to configure

I’ve tried fish shell a few times and ended up preferring ZSH. To my understanding Fish shell doesn’t have complete BASH compatibility and it breaks many scripts. It also doesn’t seem to have nearly as wide of an adoption as ZSH so less overall community support in genera. Sure you can just specify the interpreter with hash bang but it’s something worth noting before considering a switch.

This. Just please don't be so dogmatic, Fish, it's ok to also allow && together with AND and not break my scripts ...

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

#333

Post by tomaskafka » Sat, Aug 04, 2018, 6:39 PM UTC

theclaw wrote: post #267

ken wrote: 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…

We can probably learn a lot about UI animation from video games. In fighting games there are the concepts of animation priority[0] and cancelling[1], which essentially govern whether the animation for your previous move will block your next move, and whether an animation can be interupted by a new move. Most good video game UI animates after-the-fact, so you can navigate very quickly and the UI animation lags behind…

YES! Please, Apple, listen. I hate that Safari scrolling on iOS is blocked during the animation of link opening in background tab. Let the icon fly, just let me use the browser meanwhile!

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

#334

Post by b0rsuk » Sat, Aug 04, 2018, 6:40 PM UTC

mikeryan wrote: post #164

sleepyams wrote: post #140

Earlier quoted context omitted.

Will we ever solve UI? UI is the meeting place of tech and user, and in a sense it is THE problem for humanity right now. UI informs how we tend to use the internet, and for example we are currently involved with UIs that tend towards consumption (e.g. discovery mechanisms, feeds, etc). To solve UI would imply a certain optimal way to live our lives, if that exists. I agree with you that UI is unsolved and extremely…

There’s an inherent dichotomy in UI in that the most “efficient” interfaces generally have the steepest learning curve. You can be really efficient in a terminal or VIM. But figuring those out take a lot of work. When we design interfaces we try to make them have a short learning curve but expose greater ability as you use them but it’s still hard.

I think this is nowhere more evident than in the world of games. In my opinion RTS games stagnated and died because they failed to innovate in interface department, outside of a few like Total Annihilation / Supreme Commander. The classic Dune2/Warcraft interface only works for selecting single units and squares. So when any bigger engagement happens, it's just people throwing blobs at one another and juggling group hotkeys.

I think RTS games should be controlled primarily by keyboard, not mouse. Select units of X type by pressing a key, target them at units of Z type, make the command 'attack' by pressing A. Vim-inspired.

It's not surprising that games are chiefly aimed at the least patient people - the goal of publishers is to sell to as many people as possible.

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

#335

Post by emilsedgh » Sat, Aug 04, 2018, 7:05 PM UTC

arendtio wrote: post #256

JoshMnem wrote: post #241

Animation is unnecessary in most cases. Minimal animation can be added where the UI would otherwise be unclear, but other than that it's visual spam. Animation should be like a very thin layer of icing on a cake, but we're getting fed cakes with 4 inches of icing on the top. There is often little aesthetic restraint. Designers should be asking, "how can I remove as much animation as possible?" It spammy and also an a…

I wouldn't say animations are unneecessary. There are cases where they do add something positive. For example I see this open/close animation of yakuake [1] up to a hundred times per day since years and I still like it. I think the key to good animations is that they use the right timing. They are best when you barely even see them. They should transport a notion, but as soon as you see it clearly, you have to wait f…

I used to use Yakuake heavily. Loved it. It made me much more productive.

Then I realized what was the reason behind it. And it's not the animation.

Yakuake has a specific shortcut that your muscle memory can remember. Making Yakuake super accessible. It's like my brain has now O(1) to access my konsole.

So I removed Yakuake and saved a specific shortcut for Konsole.

It's much better. Because there's no annoying notification and the window is full screen.

I applied this pattern to all my apps and I'm far more productive than I've ever been in any environment:

F1 opens up browser

F2 opens up pdf viewer

F3 opens up text editor...

(You can apply a shortcut to any application/window using Kwin -> Special Application Settings -> Arrangement & Access

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

#336

Post by thinkmassive » Sat, Aug 04, 2018, 7:18 PM UTC

Izkata wrote: post #319

sharmi wrote: 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…

> (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 t…

I think the parent is referring to “delete and go next” and “delete and go previous” rather than simply “go next” and “go prev”

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

#337

Post by sharmi » Sat, Aug 04, 2018, 7:23 PM UTC

Izkata wrote: post #319

sharmi wrote: 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…

> (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 t…

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.

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

#338

Post by laumars » Sat, Aug 04, 2018, 7:45 PM UTC

TeMPOraL wrote: post #251

laumars wrote: post #123

Earlier quoted context omitted.

Skype supports the regex s/search/replace/ notation as well. Which threw me off guard one evening.

Does it? I know it did 7 years ago on Linux clients, but AFAIR it doesn't now. It's definitely the feature I missed the most on Windows client.

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?

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

#339

Post by rane » Sat, Aug 04, 2018, 8:13 PM UTC

apetresc wrote: post #83

lylecubed wrote: post #70

Earlier quoted context omitted.

> Every time a programmer adds an animation, a settings option should also be added to "disable animations". You can disable every animation in OS X itself via the command line (defaults write). I put them all in a shell script that I run on new installs. You may be out of luck with 1Password.

Unfortunately, not every animation. In particular, the Spaces transition animations that the OP is complaining about is not one of the ones you can disable with `defaults.write`. I re-check if it's been added with every new macOS release; no luck so far :(

One way to make the Spaces animation tolerable is to enable "Reduce motion" in Accessibility preferences.

https://i.imgur.com/zg4gZA7.png

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

#340

Post by Izkata » Sat, Aug 04, 2018, 8:17 PM UTC

pwg wrote: post #312

ken wrote: 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…

The problem with the animations are not that they are bad, per se. They do provide a visual guide to new users of what just occurred. That has value for the new user. The problem is that too many systems/programs that provide these animations forget that the animation that was useful to one as a new user the first few times, becomes an irritating time sink when it has been watched the ten thousandth time. After the t…

What about GP's suggestion: The more a particular animation occurs, the faster it runs. Remove some milliseconds from it each time, down to some very low limit, so new users get the clarity benefit and experienced users get the speed.

I remember reading about such auto-adjusting UIs long ago, but the idea from then was things like shrinking labels to make room for more advanced features showing up. Not good for consistency, but auto-adjusting animations...