This exercise was developed for a client project. It would accompany the description of their service on the site homepage. The steps in the animation were designed to reflect that service. The company provides analytics and analysis of their client’s digital audiences. They then delivers certain pieces of advertising to those audiences. Our concept was to use an abstract interactive animation to visualise that service. The process the company follows with their clients goes something like this: firstly they observe the behavior of the audience; secondly they deliver content to certain segments of the audience; thirdly they analyse the results, therefore building a better picture of their audience.
When delivering this piece we were limited by budget (time) and skills. These two limitations are very familiar for any designer or developer when delivering successful design for a client. Our audiences (and clients) are exposed to ever higher quality digital design made in ever more varying languages and frameworks. This leads to the perception that these things are cheap and easy to produce. Our challenge is to deliver beautiful interactions within clients’ limited budgets and in technologies we have the skills or resources in. This takes a mix of ambition and pragmatism on our part, along with clearly managing client expectations.
My rule of thumb is to do one thing really well. You can always build on it once it is done if you end up with time. It is important not to get frustrated with these restrictions, you must embrace them if you are working within the commercial world. Luckily, simple design solutions are the most beautiful and, as a bonus, are more likely to remain timeless.
In this case, we were careful not to bite off more than we could chew. We pushed ourselves whilst retaining a manageable amount of risk. This meant framing our concept around a technology I (as developer) had experience with and an existing example in that technology that proved the basic concept for the animation was possible. The technology was paper.js and the example that we discovered to best match our concept was Tadpoles. This example proved that we could use flocking boids (see here and here for more resources on flocking) that aligned to a shape when some event (ie. a mouse click or scroll) was triggered. This became the core concept.
Even with all the pragmatism we embarked with we still worked more than the hours we’d budgeted on this feature. This was OK as we had made up a lot of time elsewhere but it is still disappointing to not have foreseen some of the time suckers that we ran into. A lot of time was spent getting our completed piece working smoothly in production. We encountered a few irritating issues with integrating Paper.js with another library controlling our page transitions (Smoothstate.js). As well as that, making canvas animations (which is what this is) successful across all screen sizes proved much more difficult than we anticipated. These could mostly be put down to this being the first time we had done those particular things. So they are unlikely to be repeated. They are all good lessons to learn regardless.
The exercise can be seen here.