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

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

#241

Post by JoshMnem » Sat, Aug 04, 2018, 9:01 AM UTC

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 accessibility issue[1][2][3], especially when the animation is designed to mimic physical motion (parallax, Material Design, etc.).

To try and make computing bearable, I switched to i3wm and turned off all CSS animation in my browsers with Stylus. It's still too much.

I also have a suspicion that animation is causing cognitive damage to users by regularly breaking attention.

[1] http://simplyaccessible.com/article/animations/

[2] http://accessibility.psu.edu/animations/

[3] https://www.smashingmagazine.com/2018/04/designing-accessibi...

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

#242

Post by baxtr » Sat, Aug 04, 2018, 9:03 AM UTC

Isn’t one of the most successful companies ever built on that principle? (Google.)

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

#243

Post by kiriakasis » Sat, Aug 04, 2018, 9:06 AM UTC

daleco wrote: post #165

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…

A good animation should be barely perceptible. If it’s too slow, the application feels sluggish. Too fast, you may not know what happened. It reminds a UX talk from Airbnb, where they have this one guy that focus only on animations. It’s a good idea to provide the ability to skip the transition with the press of a button. It’s reminds me how one can skip the dialogues in video games.

> If it’s too slow, the application feels sluggish.

> It’s a good idea to provide the ability to skip the transition with the press of a button.

It is not really about animation speed, but more about responsiveness, commonly animation block all inputs because it is easier.

Few days ago there was a discussion on the BEAM/Erlang ecosystem designed so that everything is as responsive as possible. I believe that is really cool.

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

#244

Post by pavlov » Sat, Aug 04, 2018, 9:19 AM UTC

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…

Animation in UIs is like corridors in architecture. If the user can’t get directly from A to B, you need to have something in between to carry them through the transition.

An architect would never dream of adding extra corridors just because they’d be a nice place to display some framed art. Neither should a UI designer add animation for its own sake.

I used to work on a UI modeling tool, and users were constantly disappointed to learn that they couldn’t build custom element animations in the tool (i.e. Flash / After Effects style choreographed view layout changes). When we looked at the use cases, inevitably they were looking to add superfluous motion to a view whose data was immediately available and which was displayed in a screen that already had an OS-level standard navigation transition animation applied to it. There was no reason to move things around when the screen was already fully rendered and ready for interactions.

But I’m not sure if I convinced anyone: there is a generation of designers currently who want to think of UIs as motion graphics showcases and who assume usability is an intuitive quality that will be automatically be present in their designs.

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

#245

Post by EdiX » Sat, Aug 04, 2018, 9:22 AM UTC

0942v8653 wrote: post #73

SomeHacker44 wrote: post #62

Earlier quoted context omitted.

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

I've read this opinion a few times and at one point (before trying mobile slack) I believed it. Is this true for iPhone users maybe?

I've used slack on mobile and I find it worse than the desktop version.

It starts slightly faster (10 seconds vs. almost 20) but navigating through channels is bad (and slower) and threads are completely unusable. It also runs my device hot like nothing else.

The faster startup speed isn't a big victory for me because it's still a factor of 10 away from what I would consider acceptable.

The "best" interface for slack, IMHO, is the web version, provided that you are already using Chrome.

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

#246

Post by sriku » Sat, Aug 04, 2018, 9:34 AM UTC

One way to think about interface power is in terms of thresholds and ceilings. CLIs are powerful with a somewhat high threshold and high ceiling. In the attempt to lower the threshold, most UIs and OSes significantly lower the ceiling too.

I don't recall who originally described it this way. One of Logo's motivations was to have an experimentation environment for kids with low threshold and no ceiling. Perhaps Seymour Papert.

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

#247

Post by GordonS » Sat, Aug 04, 2018, 9:43 AM UTC

NegativeLatency wrote: post #189

eikenberry wrote: post #185

Earlier quoted context omitted.

Zsh can also do this.

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

Do you mean it just ships with support for a list of preset commands, or can it provide autocomplete for any command? (I have no idea how that could possibly work, mind)

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

#248

Post by chin123 » Sat, Aug 04, 2018, 9:43 AM UTC

jamesrcole wrote: post #216

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 agree. I've long thought that animation could potentially make it much clearer what's going on in Vim. Like if the user types 'das' to delete the current sentence, and it quickly highlights the text to be deleted, and then shows it shrinking away, as the text that was following it moves in to take its place. (Obviously, you'd want the animation to happen pretty quickly). Such animation could make it clearer what th…

You might like kakoune, a vim-like editor which focuses on interactivity: https://github.com/mawww/kakoune It flips around a few of vim's operations (like for example, to delete a word, you do 'wd' and not 'dw'). This allows it to highlight the text before performing an operation, which makes what you're doing much clearer.

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

#249

Post by TeMPOraL » Sat, Aug 04, 2018, 9:43 AM UTC

erikbye wrote: post #230

chocolatebunny wrote: post #126

Earlier quoted context omitted.

Reminds me of a former coworker's Emacs workflow. He organized his work in orgmode. He used emacs for email, jabber, and irc. He would copy paste new tasks between email and orgmode, and he could copy paste the code snippets he was working on to irc if he needed help.

He'd get a lot of flack unless he gisted his snippet first. But, of course, we have gist.el.

This can be, and probably is, automatically targeted by some simple pre-send hook. Basically, if you're trying to send >4 lines, automatically gist them and send URL instead.

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

#250

Post by chj » Sat, Aug 04, 2018, 9:44 AM UTC

TheOtherHobbes wrote: post #75

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…

I think the value of the OP is the proposal that we can have web-like "terminal" that accepts text commands. It's very unlikely that clicking is the best way for human to communicate with machines.