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

71–80 of 379 posts

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

#71

Post by dllthomas »

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…

I still think we should let expert users tweak it manually, but as a default I think that's a great idea!

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

#72

Post by tonysdg »

ProfessorLayton wrote: post #64

I highly disagree that the animations are superfluous for the vast majority of users. Yes, they can be superfluous, but that's not by their nature of existing. History shows us that consumers value good UX, of which animation is a key component. The iPhone wasn't the first smartphone, but it was the fist one to take UX as seriously as the hardware. As for the examples: - Slack: Yes, it takes forever to load and I hat…

> Spaces: The animation tells the user what is going on! Having the entire screen change instantly would be confusing for the vast majority of users.

That's an interesting point, and it makes me wonder if there's a level of nuance to be found here. For example, animations are acceptable iff they do not extend the time required to perceive the requested action.

In other words, it's already going to take me some fraction of a second to perceive any change; animations within that fraction of a second are perfectly fine. Anything that extends the change past that fraction of a second, however, is eating into my productivity (or at least, so the author would claim).

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

#73

Post by 0942v8653 »

SomeHacker44 wrote: post #62
gav wrote: post #60

Earlier quoted context omitted.

> 45-second video of Slack opening (surely the worst offender among modern apps I hate to defend Slack as it's far from snappy, but comparing it to a console app seems hardly fair. I wonder how much of it's slowness is due to network requests? I could make the argument that git is slow because when I clone a large repository it takes a while.

I do not see how that comparison is unfair. Terminal IRC clients, for example, accomplish the same exact functionality as Slack in a curses UI in a vastly faster way.

Wouldn't say that IRC has the same exact functionality as Slack. But the Slack mobile app does, and it runs far better than the desktop version (starts up in 3 seconds on a low-powered device instead of 30 on a much faster machine).

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

#74

Post by arg84 »

juancampa wrote: post #53
arg84 wrote: post #19

Ironic that the author uses up 2/3 of valuable screen space for the title of the article when a much smaller size would have sufficed. It took me extra time to scroll down to the main content. This just goes to show that aesthetics have more value than perhaps the author is conscious of.

An article, something you use once, is different from an application, which you use continuously for long periods of time

Following that logic would mean that the more time we spend interacting with the medium the less important aesthetics/gestalt is, and that the medium should instead be focused solely on function. I think one thing the low level tech focused individual can sometimes overlook is that it is humans interacting with these interfaces, and humans are varied, and as such interfaces need to incorporate many different methods of engaging the user.

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

#75

Post by TheOtherHobbes »

There are very few web apps where users need - or want - to do any kind of intelligent, complex text editing.

Most web apps are virtual paper forms with pre-filled menu options and - usually - a bread crumb trail so users can change their choices and/or their minds.

Animations are largely irrelevant to the user experience. The best way to speed up this kind of web app is to iterate over and over to find the sticking points empirically, and then nuke them from orbit.

That means minimising the number of menus, making sure they have useful defaults, and spending extra time on problematic elements like date and time selectors.

The user should type as little as possible and click as little as possible to get the job done. Beyond that, "productivity" does not apply as a concept. Users do not need composability or grep-like text manipulation options.

It's also handy if a page looks good, because this makes an impression on many users and is one factor that can persuade them to come back.

So no - I do not think there's anything of value in the OP, except perhaps as another example of "Developers want to turn everything into a emacs and a build system, because that makes them happy, even though it's 100% inappropriate for non-developers."

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

#76

Post by KirinDave »

nomdehn_180714 wrote: post #51
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.…

I think your criticism misses the mark. [1] You're answering an article that starts with a 45-second video of Slack opening (surely the worst offender among modern apps) with something about latencies measured in thousandths of a second. [2] As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways. Note that…

[1]:

Maybe you should read the article and see subsequent videos (e.g., animation jank) where we are in this time domain rather than skipping that part? TBF: the videos didn't play for me without opening them in a different tab. I'm not sure how they accomplished this, since typical embedding tags don't have this problem.

[2]: > As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways.

Multiple interactions were offered in the article that were native apps that had animation. Principles of UX are not exactly the same between local and web, but the principles of how animation guides user attention and context are more universal than you make them out to be.

For example, I love to make fun of the 1pass animation but I think it does serve a valuable purpose: making sure the user has realized the environment is now authenticated as a result of password entry. A unique cue for that is a good idea.

> Note that generally "directing user attention" isn't necessary in a shell...

This is fantastically wrong!

We have a long history of working to make sure that user attention is directed in shells! From guidance on how to do a menu with highlighting (folks have settled on doing the chosen option in a select menu with inverse text and an extra glyph to keep degenerate cases like 1-tuples and 2-tuples from being ambiguous) to ongoing refinements to midnight commander.

Another example in a more command-line domain is silver searcher's bash integration, which makes history search a lot better.

And there is a whole world of UI around log aggregation, search and UI that extends onto the console and has seen rapid evolution over the last 5 years.

[3]:

> Yes, internationalization is still hard. At least for Terminal.app, this is basically a solved problem

It's really not. Lots of tooling breaks.

> he situation with web tech is about the same,

CSS makes this dramatically better on the web side, and we haven't even gotten to support for folks with physical differences that make precise keyboard input or traveling eyesight easy.

The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.

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

#77

Post by bichiliad »

I think this article points out some very valid problems (I relate a lot with Slack's loading, OSX spaces taking too long to switch between, etc), but the conclusions may be a little misguided. To address specific examples first:

1. Slack is slow to start, and, as others have pointed out, uses animations to remind the user that it's working and not just frozen. The fix here is to improve the application's performance, but there will never be 0 network lag.

2. Animations are good here so that you remain spatially aware of a "space" relative to other spaces. I agree that the animations are too long, and I myself have shortened their duration.

My biggest disagreement is with this quote:

"We should stop babying our users and try to raise beginners and the less technical to the bar of modern day power users rather than produce software that’s designed for the lowest common denominator."

I think the best software is intuitive to use for novices, yet leaves room for people to improve. I'm learning how to use OSX's Logic right now, and I've been really happy with the amount of guidance it gives me. There are options to expose advanced controls, and there are a fleet of really convenient shortcuts, but I have no problem getting around.

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

#78

Post by KirinDave »

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?

I obviously disagree with your interpretation of the article. I think the author made these points implicit their demonstration.

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

#80

Post by stevefolta »

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.

mlterm also works great with non-monospaced fonts (but doesn't, to my knowledge, have a way to switch between fonts within terminal output, which seems to be what the OP wants).
Post reply on HN