Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

Post reply on HN
Print view View original

41–50 of 379 posts

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

#41

Post by cnasc »

juancampa wrote: post #33
calcifer wrote: post #27

Earlier quoted context omitted.

> 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

In my opinion, animations should be like reverb in music. If it's noticeable, you're probably using too much (surf music excepted). A little bit of animation can smooth things out and enhance the experience with helpful cues. Too much makes the application a pain to use.

> he/she is already expecting something to happen

Just as an example, if I were to trigger Mission Control [1] in macOS without animations, it would be pretty jarring. In this case, I control the speed of animation with the speed of my mouse gesture, and it's quick enough not to get in my way, but animated enough so that I have a sense of continuity between my full screen web browser and the view of all windows on that desktop.

In contrast, the default minimize/restore animations in macOS are too long and cutesy for me.

[1] https://en.wikipedia.org/wiki/Mission_Control_(macOS)

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

#42

Post by thestoicattack »

stevebmark wrote: post #39

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…

I'm not understanding what awk has to do with your other points.

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

#43

Post by juancampa »

eridius wrote: post #31
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.

Stating that they are decrypting (and it takes time) would probably change users' opinion from "this is slow" to "this is secure"

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

#44

Post by dsnuh »

GlenTheMachine wrote: post #16
micheljansen wrote: post #11

I recently got gifted an old Commodore PET. It boots straight into BASIC, so anything you type can be a command or a program, but what’s even cooler is the way the console (they call it “monitor”) works. If you press “up”, rather than scrolling through past commands one by one like in Bash, DOS etc. the cursor simply goes up the screen. You can modify anything you see and hit return to commit. This can be a previous…

IIRC all Commodore machines did this. The C64 did. That's how you edited a program: you LIST'ed it, and then scrolled up and changed the lines on the screen. When you hit ENTER the new line overwrote the original one. The C64 did not have any way to directly show or edit system memory, though. That's cool.

Are you forgetting about POKE and PEEK?

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

#45

Post by npunt »

eridius wrote: post #31
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.

I seem to recall reading this when I investigated before. Article is shooting the messenger in a way, the animation is not the problem. Agilebits (the co who makes 1password) generally aren't the types to introduce superfluous elements.

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

#46

Post by cnasc »

A related sort of idea, which has been posted to HN before but never gotten a huge amount of attention is the Arcan project [1].

Basically an interesting implementation of a display server and desktop environment being worked on by a lone dev as far as I know. Really impressive stuff, and in the author's own words: it is keyboard dominant, building a better and more efficient CLI than the flaccid terminal emulators of yore

[1] https://arcan-fe.com/

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

#47

Post by juancampa »

justamus wrote: post #8

I absolutely agree that aesthetics shouldn't come at the expense of efficiency, but I don't think it's practical to expect every user to be a power user. There are some products and programs, like the Adobe Suite and a bunch of terminal programs, that are marketed for and should be designed with power users in mind. But I'd say the majority of programs we use every day aren't designed with professionals in mind - the…

In an ideal world everyone would get a UX specifically tailored to their expertise level. Software must be a LOT cheaper to build for this to ever happen though.

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

#48

Post by xnzakg »

juancampa wrote: post #33
calcifer wrote: post #27

Earlier quoted context omitted.

> 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

I think animations are pretty useful for some touchscreen UIs, for example if you have a menu that can be swiped away, or to attract attention to things that happen without user interaction. The only issue is a lack of consistency. Also, animations can hide load times while making things seem fast (see iOS app opening animation)

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

#50

Post by slrz »

sandinmyjoints wrote: post #22
micheljansen wrote: post #11

I recently got gifted an old Commodore PET. It boots straight into BASIC, so anything you type can be a command or a program, but what’s even cooler is the way the console (they call it “monitor”) works. If you press “up”, rather than scrolling through past commands one by one like in Bash, DOS etc. the cursor simply goes up the screen. You can modify anything you see and hit return to commit. This can be a previous…

Emacs’ Dired mode lets you interact with the file system this way. Imagine the output of ‘ls -l’ as an editable document — seeing this in action was one of the killer features that made me an Emacs user.

What's an Emacs? Running that command just seems to reduce my disk quota.

The functionality you're describing sounds pretty much like vidir (from moreutils[1]), though.

[1] https://joeyh.name/code/moreutils/

Post reply on HN