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

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

#31

Post by eridius » Fri, Aug 03, 2018, 7:44 PM UTC

jwr wrote: 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!

It would not surprise me in the least if the 1Password unlock animation is a deliberate attempt to hide the time it takes 1Password to decrypt your password list.

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

#32

Post by digi_owl » Fri, Aug 03, 2018, 7:48 PM UTC

swiley wrote: post #25

GlenTheMachine wrote: post #10

I'm switching away from macOS to Linux with the i3 window manager for precisely this reason. But all of his criticisms of terminals are spot on: no multimedia, no support for anything other than monospaced fonts, etc. Lord, somebody give me a terminal program that produces laid-out text and can show inline video.

If you use mlterm (and supposedly xterm with the right compile flags) you can have inline pixelmaps via DEC -regis- sixel escapes.

Actually i think REGIS is for vector graphics, SIXEL (six pixels pr character) is the pixel graphics.

I seem to recall that at least one terminal browser can pull some tricks to insert images into the window in X as well.

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

#33

Post by juancampa » Fri, Aug 03, 2018, 7:49 PM UTC

calcifer wrote: post #27

KirinDave wrote: post #13

So to sum up, Terminals Are So Responsive & Fast Users Always Feel It [1]. Animations are bad because they take too long but add no value [2], and terminals render non-english characters super well [3]. I've been researching for a bit, and actually research on how to make a "good" and "accessible" terminal interface is pretty thin on the ground. You can find a lot of opinions but very few with any data backing them.…

> So to sum up You start with this, and then make two-and-a-half points (I'll kinda give you animation) that the article doesn't. How is that a summation?

IMO animation is only useful in certain cases like notifications and smooth scrolling.

If the user is the one initiating an interaction though, there's usually no need to animate anything (opening a menu, for example) because he/she is already expecting something to happen

Edit: s/animation/transitions/g

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

#34

Post by alkonaut » Fri, Aug 03, 2018, 7:55 PM UTC

I think it's probably easier to make a web app or desktop app as fast/bare/responsive/etc as an old terminal app, than it is to add good rendering of mixed fonts images etc into terminals.

So what he's arguing for is simpler, faster traditional non-terminal apps. Because those are good.

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

#35

Post by amiga-workbench » Fri, Aug 03, 2018, 7:55 PM UTC

fhood wrote: post #23

"UIs that are pretty and friendly are nice to have, but the true values of a good interface should be speed and efficiency to make their users as productive as possible." Nonononononono! Both. I want both. The biggest problem with terminal interfaces is that very little of the functionality is obvious from the outset.

Ease of use and utility/efficiency seem to exist on the opposite ends of a continuum.

The more common "easy to use" software is designed to be up-front and intuitive but because of its nature it is hobbled from a maximum utility/efficiency standpoint. The interface usually relies on interaction modes that are severely limited in bandwidth (poking things with a pointer).

And the stuff on the other end is designed to be as useful and efficient as possible, but because of this its functions aren't immediately obvious and it requires the user to actually read the manual instead of fumbling their way around the interface. Once you actually put the time and effort in and learn the program you will be working far faster with this than the friendlier software.

There is one piece of software that comes to mind which seems to exist in a happy medium, the nano text editor can be extremely powerful once you learn the hotkeys but it meets you half way and gives you a heads up of all the main functions without you asking.

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

#36

Post by Posibyte » Fri, Aug 03, 2018, 7:56 PM UTC

I get the idea, and I agree in general. However, I've always struggled with DE's like i3 because they were so barren with visual information up front. I respect the power they present, but I appreciate a nice balance. Animations, more than anything, just need to be paced appropriately. They help a lot in easing a user into a flow within an app. Slack for me does this perfectly. It doesn't feel kludgy, slow, nor does it feel like everything pops up in your face loud and obnoxiously. The interface and animations helped me feel like I was getting down a flow, and when I learned the hot keys and patterns, it felt like playing an instrument well.

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

#37

Post by swiley » Fri, Aug 03, 2018, 7:57 PM UTC

digi_owl wrote: post #32

swiley wrote: post #25

Earlier quoted context omitted.

If you use mlterm (and supposedly xterm with the right compile flags) you can have inline pixelmaps via DEC -regis- sixel escapes.

Actually i think REGIS is for vector graphics, SIXEL (six pixels pr character) is the pixel graphics. I seem to recall that at least one terminal browser can pull some tricks to insert images into the window in X as well.

Oops, you're right.

The browser you're thinking of is w3m.

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

#38

Post by t1amat » Fri, Aug 03, 2018, 7:58 PM UTC

GlenTheMachine wrote: post #10

I'm switching away from macOS to Linux with the i3 window manager for precisely this reason. But all of his criticisms of terminals are spot on: no multimedia, no support for anything other than monospaced fonts, etc. Lord, somebody give me a terminal program that produces laid-out text and can show inline video.

You can get all of that with Electron-based terminals. Perhaps take a look at Hyper.

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

#39

Post by stevebmark » Fri, Aug 03, 2018, 7:58 PM UTC

please, god no. i've watched so many "terminal gurus" painfully hold left or right keys to jump to editing text (I use vi mode, but it still sucks). i've watched them fumble with !! to do something they think is efficient, but really slows them down. i've watched them write unreadable buggy awk scripts over the course of hours that end up not getting the job done. terminals are a classic example of fundamentally bad design.

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

#40

Post by yourapostasy » Fri, Aug 03, 2018, 7:58 PM UTC

neeasade wrote: post #30

Everything the author describes lacking in the end exists in emacs. Come on in, the water is fine.

Are there Emacs-based terminal UI libraries?

Looking at how insanely fast competent line staff are with terminal interfaces like in retail POS settings, I sometimes wonder if Emacs would be fast enough to keep up with them. If so, instead of using a browser as the base UI framework, would a terminal-screened Emacs (that is, in console mode or perhaps inside xterm, and not the graphical Emacsen) with an appropriate text UI library be feasible?

It can't possibly be worth the effort unless the text UI in the code is the only presentation layer, I'd imagine. But if you have to go down that route, it might be faster and easier than rolling your own termcap-based text UI, especially with all the elisp goodness within. The only extensive text UI I knew of was Vermont Views' product, which has since disappeared off the Net and was closed source anyways. There are some open source libraries, but none with nearly the power that came with that closed source offering, and all still quite low level.