Nuggetty Goodness

Some ponderings as I learn the wonders of CSS-grid, fluid typography, and all the shiny new toys kids these days have.

Gosh, CSS has gotten so much nicer since the days when we had to haul water to the top of the hill both ways barefoot in the snow.

No, designers shouldn't code
I don't think designers need to be able to write production quality code. It stands to reason that I have a vested interest in this "no", as I haven't committed production code in over a decade. Plus, production quality code, especially at an enterprise-level, is a completely different beast from building a small static website. When it comes to enterprise code, scalability, maintainability, extensibility are all very important - and I prefer to leave them to the experts (my developers).

Yes, designers should code
Ideally, designers should have some familiarity with, and understanding of the basic "materials" used to build the digital products they design. Additionally, the "materials" will vary, even across digital products. Just because I can write js and css certainly does not mean I know the "materials" for native Windows, Mac, Android, or Linux.

With that as the caveat - being able to code just enough to know my materials is a very big plus. I did a basic Vue course fairly recently. Nothing fancy, just a single page app. However, what I learnt from that course gave me a much better idea of how Vue (and React, and Angular) work at a very high level, and how that can translate into implementation. It also made it collaborating with front-end web developers easier, as we had some degree of shared knowledge.

I've also been experimenting with the "new" (not so new, I know) CSS toys all the kids have these days. What's really cool about this is that unlike the Vue course, what I'm learning about CSS is changing the way I think and design - and think about design. These learnings change the bounds of what I know are possible.

For example, I have been reading about fluid typography on the web for a couple of years now - and before I started poking around the code, it's been a very abstract sort of interest. E.g. "Nice and interesting abstract concept, I should try to design for that when I have the opportunity". Now that I've poked around the code, and gotten a basic understanding of how things work, this has changed to a much more real and practical, "ZOMG now that I actually know how that bit of code holds together, I can actually set a typographic scale that way, and see it work. And I can see how I could make it work in so many places. Waoohh!"

Here's my supernoob code-pen, which I'm modifying on the fly as I learn more about css-grid and fluid typography.
All the noob inline comments, every noob inline comments!

See the Pen Flying Red Horse - CSS-Grid Experiments by JC (@nuggettyone) on CodePen.

This is the simplest way to achieve what we want, in terms of animation.

What we are doing here can be considered "semantic" animation, as it is the animations that "explain" to the user why and how the map is being displayed to them. The equivalent is a book opening, or a page turning.

If possible, make the timings and the animation types customisable, with defaults.


Why 200ms?
Because when it comes to things we interact with mostly visually, 200ms is the amount of time it takes the human brain to register that something has come into view, or changed. At 200ms, UI animation feels almost instant.

Now, we could get pickier, and make it 300-400ms for XS, SM, and 200ms for MD, L, XL, because the distance travelled by the animated objects also influences how fast they feel. However, this lies in the realm of "fancy extras". They are nice, but if we start doing that, then to be consistent, we need to do it EVERYWHERE.

So 200ms. ;) For everything.

Please note that this is a visual thing. If you are writing with a stylus, and the lag is 200ms (or you're gaming! ;) ) 200ms, is way way way too slow. When writing with a digital stylus, or drawing with a mouse, the latency has to be as close to 0 as possible. Even 100ms feels laggy when you draw with a stylus or a mouse.


Why Ease In-Out?
Easing makes animations look more natural, by visually mimicking the laws of physics.

We're using Ease In-Out as the default, as it mimics physics, AND is less confusing for most people who aren't professional animators.

But whyyyyy! ;) Ok here's why...

If we wanted to be picky, when something animates INTO view, we should use Ease-Out. Ease-Out is when something moves fast at first, and then slows down. This mimics physics in the real world, where stuff loses momentum as it moves, due to friction. So it starts fast (because as it's animating into our view, it's already moving), and as it runs out of energy, it slows down.

Likewise, when something animates OUT OF view, we should use Ease-In. Ease-In is when something moves slowly at first, and then speeds up. Again, this mimics physics in the real world, where it takes time for stuff to build up momentum, and then it goes faster as it collects enough energy to overcome friction. So it starts slow (because it's charging up, while still being in our view), and then the animation speeds up as the item leaves our view.

^And yes, for stuff that comes INTO view, it's better to use Ease-OUT, for stuff that LEAVES our view, it's better to use Ease-IN. Yes. It's horribly confusing.

Ease In-Out to the rescue! ;) Our :X compromised best of both worlds. It's not really... but it's the least confusing to remember.

Ease In-Out is when something moves slowly at first, gets quicker... then slows back down. In UI terms, this is a nice compromise if we don't wanna be fancy, because as humans, we're lazy about how we perceive things.

When we use Ease In-Out for something that animates INTO view, the human-goldfish mind has most likely already stopped paying attention before the last "slow" in the slow-fast-slow sequence. So to the human-goldfish, most of the time it'll look like an Ease-Out.

When we use Ease-In-Out for something that animates OUT of view, the human-goldfish mind (you see where this is going) takes a while to notice what's going on. ;) So it likely doesn't notice the first "slow" in the slow-fast-slow sequence.*

*Updated on 28 Jan 2022 to change ease in-out to accurately reflect a slow-fast-slow sequence. I got sequence of what happens with ease in-out wrong originally, but using it still works, because the human-goldfish principle still applies.

Some samples, using 200ms and (naughty naughty, ALL ease-in).
Each click as shown is triggering a new 200ms animation to the next keyframe.