I am fairly new to React as a front-end technology. I’ve mainly been a Ruby on Rails developer. Needless to say, after completing one project using React, I was sold. What I didn’t expect, however, was to be thrown into a world of vector mathematics, trigonometry and snazzy animations.

I thought I’d share my learnings with respect to converting a visual design into mathematics and then translating this mathematics into code. I will also discuss the pro’s and con’s of two popular web graphical elements we considered using as the basis for animating this design.

Design Considerations

Our particular application required an input field. The input had to be within a certain range, so a slider seemed to be the natural choice as an input type. Pretty standard stuff…

Except most sliders are boring.

I’m glad i’m not a designer…the limitations of the human body are such a curse to creativity. Hopefully humans evolve out of it soon.
In addition, using a linear slider with a human thumb on a small mobile screen is really hard. When input on a mobile is challenging for me, I generally grab the laptop and rant “Look at what these devices are demanding of our stubby human fingers!!”.

Charles Darwin

We wanted our users to be able to easily (and happily) interact with the slider. Luckily I work with very clever designers that devised a wonderful solution.

When you move your thumb across your mobile screen, it naturally traces a curve, not a straight line. So we decided create a slider that was curved rather than linear. Makes sense?
We also wanted a change in colour when the user entered their input.

The animation below is indicative of the widget we implemented in our project. The curved arc to track input combined with a varying gradient to indicate movement and change.

Animation

Tech Choices

I’m not ashamed to admit I love maths

I have spent a large portion of my life learning maths, yet a relatively small portion actually applying it. Which is a shame really. A web developer doesn’t really get to do any exciting maths. Not the hard sort anyway.

So when I realised that we needed maths to solve our UI challenge, I quietly celebrated inside — desperately hoping it would be difficult and hairy. We quickly rubbed off the model diagrams from the whiteboard and started filling it with trigonometric functions and even (dare I say it) vector’s.

In addition, we needed to understand how gradients function, in order to achieve the colour changes required whilst dragging the slider handle. Oh, I had lots of fun playing with gradients, they can be made to look incredibly ugly with very little effort. As this example from w3schools reveals.

#grad {
background: repeating-radial-gradient(red, yellow 10%, green 15%);

Gradient example from w3schools

Maths == Code

The next step was translating this maths into code. How wonderful….using code to transform mathematical symbols, concepts and diagrams into moving pictures that are people friendly. Coders gettin’ creative.

SVG or Canvas?

We needed to make an important decision with respect to which web graphical elements would best suit our design problem.

This decision was one that had to be made fairly early on in the development process, as it would dictate how one of the main widgets in our application would be structured. We spent some time considering the pro’s and con’s for both alternatives. It was a decision that we didn’t want to take too lightly, as the project had budget constraints that would have been stretched if we changed our mind at a later date.

Two of the options considered were SVG’s (Scalar Vector Graphics) and Canvas. Both are popular ways of generating graphics on the web, yet they are very differ greatly in their approach. We ended up choosing SVG’s, here’s why…

The good

SVG’s, as their name suggests, are scalable. This means that you can change the size of the image without losing clarity and sharpness. This resolution independence was a big plus for us, as we wanted our graphic to look clear on both mobile and desktop screen sizes. Canvas does not support this resolution independence.

Attaching JavaScript event handlers to SVG elements is fairly straightforward, as SVG’s have a DOM (Document Object Model). The opens up a world of flexibility with respect to controlling elements. Canvas, on the contrary, has no support for event handlers.

The Bad

SVG’s can often be slow to render, particularly if they are composed of a large number of object or are complex. Too many DOM elements and the browser will take a long time to render them. This is where Canvas really shines. Luckily this wasn’t an issue for us, as our graphic was composed of simple objects.

Some Gotcha’s

The SVG viewport coordinate system has its origin (0,0) at the top left corner. Just something to keep in mind when translating maths from paper onto screen. A slight trap for those accustomed to the good old cartesian coordinate system.

A slight trap

Building the Animation

Our SVG consisted of both the gradient coloured circle component and the draggable slider component.

<Svg id='scoring-widget' width="300" height="300">
 <GradientCircle
  ...
 />
 <ArcDraggable
  ...
 />
</Svg>

We used vector calculations to determine the position of the coloured circle’s origin and to also position the small circle on its perimeter. We made use of the vec2 library to assist with defining and dealing with vectors. This made it nice and easy to translate the maths into code. We animated the angle of the slider using component state and this in turn changed the SVG linear gradient coordinates.

In Summary

Combining animated SVG’s with React worked really well — it was intuitive and fairly straightforward to implement. For more complex animations with lots of moving parts, Canvas would probably have been a more appropriate technology.

I would encourage any web developer to delve into the world of mathematics. I found that it unlocked both the fun and nerdy parts of my brain. Above all else, it gave me the confidence to attempt even more detailed animations in the future.