Live data from Hacker News

Don't animate height

granola.ai

131–140 of 276 posts

Re: Don't animate height

#132

Earlier quoted context omitted.

If the bars are not related to actual data and are purely just pre-canned animation, the gif would just come with additional file size for a one time cached type of download. If the bars do need to be animated to real-time data coming in, then the gif would not be the right fit for that need.

Can't imagine anyone is deriving much information value from a visualizer with 3 bars. Apple Music has a similar animation and it will start bouncing when you click play, while the music is clearly downloading and there's no sound.

This was true pre iOS 18. The bars respond to the music now (at least on iOS)!

Re: Don't animate height

#134

Wouldn’t the real fix be to use an animated gif?

I think the idea is to have the animation respond to the actual volume in realtime. The animation property is only so that the 10 updates per second get interpolated according to the framerate, I think. The real solution would be to remove the gimmicky animation and show a red circle.

Re: Don't animate height

#135
This article doesn't apply to every single use case and should not be taken purely at face value.

A few week ago I needed to animate height for a banner like message that appeared in the layout (e.g. it was not absolutely positioned) once a user clicked a button. This banner message would cause a layout shift no matter what because its height was being added to the layout and shifting the elements underneath it down. Thus, to mitigate a jumpy layout, making the height animate made the layout shift easier on the eyes.

And before you say "well design it differently" - I didn't design this.

Re: Don't animate height

#136

Earlier quoted context omitted.

Can't imagine anyone is deriving much information value from a visualizer with 3 bars. Apple Music has a similar animation and it will start bouncing when you click play, while the music is clearly downloading and there's no sound.

This was true pre iOS 18. The bars respond to the music now (at least on iOS)!

Ah, look at that, so they do!

Re: Don't animate height

#137

Earlier quoted context omitted.

Dart/Flutter was never a technical issue, but a political/monopolistic issue. The underlying monopoly has not changed, so I don't really see a path forward unless the chromium team magically changes leadership.

I guess my point is, if the big Chromium team couldn't pull something like this off, who else would? At this point major web updates tend to get born in one of the big tech companies funding web development, either directly or indirectly (Mozilla being funded by Google)

I personally don't think dart/flutter was good enough of a solution to be worth everyone's time. When this actually happens it will be more of a paradigm shift than that. That's why (which I said in the other comment) what needs to happen is that innovating in this space needs to become a lot easier.

Re: Don't animate height

#138
How about we create tools that don't consume 5+ % of user's CPU (and keep it busy, not allowing it to sleep, decreasing battery life significantly) when idling or doing some background work?

Re: Don't animate height

#139
post #116

Why are the bars on a little button animated in the first place? I don't get it.

This looks like a very typical audio recording UI element. The bars are animated to the volume of the recorded audio. Helps the user see that the application is picking up their mic.

It's a digital analog of a VU meter on a mixing console, though the UI has morphed over time. (Like that the lines vertically centered, vs. being on aligned bottom like you might see on a real-world meter.)

Re: Don't animate height

#140
post #31

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the or whatev…

> I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. […] But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume?

The animation (which is not suppose to be constant/static) conveys whether audio is being picked up by the application. I.e., it's VU meter.

Post reply on HN