Forem: Lucas Paetow

Innovation from within the team?

Lucas Paetow — Wed, 14 Jul 2021 12:16:08 +0000

How do you bring innovation to long term client projects?

Can you still be creative and try wild ideas?

We are working on a big project with many other people for quite some time now and we all will be working there for quite some more time. We have our set meetings, alignments, refinements, plannings, lunch times, reviews, and everything else for a smooth ride. But sometimes I wish I could bring more to the table, add my own ideas to existing stories or create new ones entirely.

Many of us have some expertise through other (side) projects or previous jobs and have ideas in that direction. For example, I really enjoy working with animations and therefore often see opportunities where to add them to increase the usability of the project. If I see some possibility to add them, I could of course write a ticket but it might never see the light of day on the bottom of the backlog (even if it suits the long term goals of the client).

But should it?

Is this kind of thinking more of a luxury problem?
Does the client always know which ticket order is best because in the end, all we can do is give advice to the best of our knowledge and priorities are always shifting anyways?

What about you

Were you able to convince your client to let you bring in your own ideas to even further improve the product?
If so, how?
With your own process like an “innovation sprint” or separate backlog?
Or did you find another solution entirely?

Advance your animations cRAFt to the next level

Lucas Paetow — Wed, 14 Oct 2020 12:29:56 +0000

The Javascript way

When animations get more complex and page reflows (the browser's process of recalculating element dimensions Read more about it in the first part of this series) can’t be avoided, we need help from JavaScript to achieve smooth motion.

With these JavaScript animations, we can't just declare a transition time and easing function (like with CSS transitions), we have to create them ourselves. This will get better eventually with the web animation API, whichs support is still not great for older browsers. Until then, we have to manually update the screen in many little steps to make it seem fluid. A good way to do it is with requestAnimationFrame.

Before requestAnimationFrame was a widely available, setTimeout or setInterval were used for this 'updating-the-screen-in-many-little-steps'-mechanism. To make them run every frame of a 60 Hz display, they both were given a timing argument of 1000/60 milliseconds. But this was a hack and sometimes, depending on the complexity of the animation, the browser couldn't make it with the calculation to the next screen update / interval / step (roughly 10ms). The animation wouldn't progress in the current frame but twice in the next one. This effect can add up and the animation might appear to be buggy.

requestAnimationFrame to the rescue.

requestAnimationFrame helps to orchestrate the animations and will ensure to run a callback / an animation step before the next screen update. It tells the browser about the intention of animating something and the browser in return can prepare and optimize beforehand.
Keep in mind that this function is only animating one frame. To use this in a full-scale animation, it needs to run again and again until the animation is done. This can be done with the function calling itself after each small step (a function calling itself is also known as a recursive function):

This is a very basic animation function taken from JavaScript.info (but with variables renamed for clarity):

function animateWith({duration, easing, animationStep}) {

  let startTime = performance.now();

  requestAnimationFrame(function animation(currentTime) {
    let timeFraction = (currentTime - startTime) / duration;
    if (timeFraction > 1) timeFraction = 1;

    let progress = easing(timeFraction)

    animationStep(progress);

    if (timeFraction < 1) {
      requestAnimationFrame(animation);
    }

  });
}

(This might look complicated at first but don’t be intimidated, we will go through this in a bit)

It will be used like this (e.g. for animating the width of an element):

let element = document.getElementByID("progress")

animateWith({
  duration: 1000,
  easing(timeFraction) {
    return timeFraction;
  },
  animationStep(progress) {
    element.style.width = progress * 100 + '%';
  }
});

Implementing this "animation engine" can be done differently but most implementations revolve around some key points:

a way to keep track of the animation progress (time elapsed of a total time can be expressed as progress),
the change in the DOM layout based on that progress
re-running the function again until the duration is up, often by recalling itself

The Animation Function explained

The whole animation function begins by setting a starting time, which is kept alive in a closure (or stored in a variable)
The inner function (the actual animation function) is called within the next frame
In here the current progress of the animation, the timeFraction, gets determined by subtracting the starting time from the current time (note for the current time parameter: requestAnimationFrame automatically gets a timestamp as an argument when it is called, which is used here for the current time). The resulting difference (the absolute time progressed since the starting time) will be divided by the duration to give us a relative time value between 0 and 1 of how much the full duration is already passed.
This timeFraction is also used for the easing of the animation (the speeding up or slowing down of the motion to make it seem more natural). To archive this, the timeFraction will get transformed to fit an easing curve (or a curve on a XY-coordinate graph — suddenly math becomes useful again)
1. not transforming the values at all (just returning them) is equal to a linear easing, the motion will be at the same pace for the whole duration. For example a linear progression for numbers from 0-1 could be 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1
2. In something else, like an ease-in function, the numbers would be transformed to the power of 2 (seen below) and our example numbers from the linear progression would look differently: 0.01, 0.04, 0.09, 0.16, 0.25, 0.36, 0.49, 0.64, 0.81, 1. They start much slower at first but progress faster in the second half

function quad(timeFraction) {
// pow is the power of n
  return Math.pow(timeFraction, 2)
}

more easing functions can be found here Easing Functions Cheat Sheet

The transformed timing fraction (progress) is then given to the actual DOM-changing animationStep function. Since the progress is always between 0 and 1, it's great for the use of percentage-based value changes
The last step is to determine if the function should run again. This is also based on progress and the reason why it can’t or shouldn't succeed 1 as value, because 1 means 100% of the duration is passed.

Great, let's see it in action

CODE EXAMPLE

CodeSandbox to see the code
live site to just see it in action

Some tips and tricks

If you want to animate properties that you also need for the calculations, like height or width, you can use minHeight/ maxHeight or minWidth/maxWidth for the animation instead. This way you won't have difficulties recalculating the original values again.
Animating values from 0 to your desired value is just desiredValue * progress and the opposite is desiredValue * (1-progress) but if you want to animate partial values to 1, the formula gets a little more complicated:
- partialValue + (desiredValue - partialValue) * progress or for the opposite partialValue + (desiredValue - partialValue) * (1 * progress)

The only new thing here is (desiredValue - partialValue), which means the amount without the starting value. For example, animating opacity from 0.25 to 1 this part would be the missing 0.75 and only these get animated.

Better Animations with this one FLIP`n trick

Lucas Paetow — Tue, 06 Oct 2020 15:20:17 +0000

Introduction

Animations are great. They guide the user focus and can make a site feel snappy and fast. But if done incorrectly, they will do the opposite: they will make the site feel sluggish and janky.

Janky?

When the browser needs to change the appearance of an element, it needs to recalculate every element affected by the change.
When a lot of elements are affected and need to be recalculated, the browser has to work longer for the calculations. If this process exceeds the time the screen takes to refresh it, it skips a frame.

An example: Most devices run at 60 frames per second. So the recalculation per frame shouldn’t take longer than roughly 10ms (1sec/60 => 16.66ms - housekeeping from the browser). Otherwise, the animation is not smooth and “stutters”

How to do it then?

There are two ways to make animations feel smooth and keep them at 60 FPS and jank-free:

The CSS way

Every change to the DOM triggers the calculation of the “critical render path” to bring the pixel updates to the screen. This involves up to 3 steps:

Layout / Reflow
In this step, the browser starts calculating the dimensions and space for each element, starting from the document root. This results in the elements box-model.
Paint
This step is about creating layers and filling them with pixels. Including but not limited to text, colors, images, borders, and shadows.
Compositing
Here the browser will send the layers to the GPU to finally draw them in the correct order onto the screen. This happens on a different thread.

The more of these steps are involved, the more work the browser has to do. Since the transform and opacity properties only require changes of the compositing step, they are very efficient.

How? With a FLIP

You might think, these transforms may only really work for small visual changes (e.g. a button press) but they can also animate seemingly heavy layout changes like expanding a card or transitioning to a new view.

Instead of scaling / transitioning / rotating an elements' starting appearance to make it look like the end appearance, (for example scaling up a card to a full-screen view) you would do the opposite: change the card to its final form and scale it down to the previous size without animation. This step happens so fast, it looks like nothing happened. Afterwards, you animate the difference (which is now a scale operation).

This process involves 4 steps and therefore coined the term FLIP (First, Last, Invert, Play - originaliy by Paul Lewis):

An Example: Apple News

CODE EXAMPLE
CodeSandbox to see the code
live site to just see it in action

First: get the dimensions of the starting element

first = collapsedImage.getBoundingClientRect();

Quick refresher: getBoundingClientRect() returns an object of values for height, width, top, right, bottom, left, x and y.

Last: change the layout and get its dimensions.

  collapsedCard.classList.add("active");
    ...
  last = fullscreenImage.getBoundingClientRect();

In this example, changing the layout is done via modifying the display-property. It's a simple yet very visual change, which triggers reflow.

Invert: Transform the element from it's last form to the starting form

  widthDifference = first.width / last.width;
  heightDifference = first.height / last.height;
  xDifference = first.left - last.left;
  yDifference = first.top - last.top;

    ...
  requestAnimationFrame(() => {
        fullscreenImage.style.transform = `translate(${xDifference}px, ${yDifference}px) scale(${widthDifference}, ${heightDifference})`;
        fullscreenImage.style.transition = "transform 0ms";
    ...
  });

On the next possible repaint, the image gets translated and scaled so it is placed over on the starting image. This change happens without a transition and is not visually noticeable (if the calculation for the change takes under 100ms, we will perceive it as instantaneously)

Play: Visually animate the difference

  requestAnimationFrame(() => {
        ...
    requestAnimationFrame(() => {
        fullscreenImage.style.transform = "";
        fullscreenImage.style.transition = `transform ${transitionTime}ms ${easing}`;
    });
  });

Again, on the next possible repaint, the changes get reverted, but this time with an easing. So it falls back into its original shape with a nice and smooth transition.
This has to be done with at least one frame between the two actions. Otherwise, javascript would just batch the commands together and we wouldn't see any visual effects. For the separation of these commands, we can use a requestAnimationFrame within a requestAnimationFrame. More on this topic will follow soon.

Things to consider

Some CSS properties (especially border-radius) might look different during this process and ruin the illusion.

For example: a 200x200px box with 'border-radius: 20px' and transform: scale(0.5) looks different than a 100x100px box with the same border-radius (percentage based values work, though)

Beware: since it has to be done for each element, it gets complicated fast, especially if multiple elements are affected (modern frameworks might help reduce the complexity)

Stay tuned

More on requestAnimationFrame and performant javascript animation will follow next week.