Designers vs Developers — Accurat @ Visualized Milan
On March 11th we had the chance to give a speech on a subject we are really passionate about, the struggling — but sometimes loving — relationship between Designers and Developers in data visualisation projects.
It’s something that we think needs an improvement, and the two don’t have to be isolated from the other but instead what we think works best is a continuous cooperation of the two.
This speech was written and delivered by Marco Bernardi, cesare soldini and Tommaso Zennaro (me), with the help of giorgia lupi.
What you’re about to read is an adaptation of our speech on the subject.
When Accurat started, we mainly designed projects such as static data visualisations for print. We’re sure lots of you are familiar with the infographics we did for the publication La Lettura, which is the Sunday cultural supplement of Corriere della Sera.
As Accurat we published more than 30 pieces from 2012 to 2014, and as you can see here, they are not very standard data visualisations, as every time we intentionally created a 100% custom visual model to represent the combination of the main datasets we overlapped.
The particularity of these pieces is that they’re entirely made by hand, spending days on Excel macros to analyse data and then spending weeks on Illustrator creating custom visual models and positioning hundreds of elements manually.
There were no automation, no presets, thus each of our piece was visually unique to the very data it represented.
The average workstation of an Accurat team member, during those years, consisted in just a laptop with illustrator.
At Accurat, in 2017, we mostly have multi-display workstations — including a vertical monitor to show off a bit.
That’s because in the last 4 years we’ve put together a proper development team and started to work more and more with interactive projects.
Lately we’ve been visualising data about credit card transactions, hacker attacks, fashion trends, on-line traffic, financial markets and much more.
But even working with interactive visualisations and interfaces, we each time imagine very custom visuals and interactive experiences based on the specific data and audiences we are working with.
How do we select the members of the development team?
Well, we look for them in the most appropriate fields.
That’s why our developers have backgrounds in electronic music, physics, IT for digital communication, while some of them are not graduated.
None of them is a pure software engineer.
Of course, once Accurat started to welcome developers, and integrate them with the design crew that we shaped during years, problems started to come out. Having to work with more people, with a different background and modus operandi is not a simple thing. More often than not we have tight deadlines which need an accelerated back and forth between design and development, and to make everything work the right way without issues the team needs to have a strong connection between members.
Developers usually (and rightfully so) want pixel perfect specifications from designers, who sometimes provide files that… are pretty far from that.
But also designers usually need to see if the design they’re working on actually makes sense with a prototype, and they usually don’t care which node version you’re using, if you use Grunt, Gulp, Webpack or Yeoman; if the ECMAScript version is 7, 6 or Mambo Number 5…
The end result is what matters after all.
Designers need to deliver the right assets, developers have to try to make everything as close as possible to the concepts, but most of all everyone has to keep in mind they’re working with other human beings.
We had the demonstration that all the stereotypes about the designer/developer relationship are absolutely real! 🙂
But, together with problems we also achieved greater results.
→ World POTUS is one of them.
For those of you not familiar with it, it’s a project that we released before the US Elections of 2016. We teamed up with Google News Lab to create a web-app that visualised data coming from Google Trends to show the people’s interest in the elections of the president of the United States.
One of the challenges we set ourselves in the making of this project was designing a data visualisation that had to be mobile first, something not really common, as most projects revolve around interactions that require a mouse and a decent compatibility with web libraries.
We had to make sure everything we sketched and sent to the client was doable and fully compatible with a wide range of devices.
We selected 12 Google Trends Entities, related to specific issues of Clinton’s and Trump’s political platforms and searched for them in every country, therefore moving the attention outside the US, creating an interest rating based on the Google Trends Index.
Instead of showing you the final results and then commenting on the process, we will guide you through this process.
Part One: the sketching and messing around
On the build up and unexpected results
Usually, when a project starts, designers begin to sketch before developers, and, at least in this part, there was no exception.
Since Google Trends allows to see searches aggregated by country, one of the first concepts that we brought to the table was using a world map as a base.
Showing which term was most googled from each country, consequentially, we linked all the dots to form a shape resembling a constellation.
Each country, if pressed, would show a planetary system of related entries.
Other concepts focused more on countries’ details, one used abstract 3D shapes to represent certain values which altered the shapes in the number of faces; another one used a module to create an unique pattern for each country, again influenced by key values in the number of rows, columns and rotation.
The third concept tweaked a bit the map theme, this time starting from the Google Trends country chart instead of the geography itself.
We created a vertical scrollable map that reflected the scores of the chart itself.
The country with the highest score would stay on top, while the others would follow.
The distortion was obtained straightening the line connecting the countries, and the distance between them would match the difference of the score.
So, as the concept was kind of settled, our developers started coding a working prototype, to see if this was actually doable.
What a developer needs to do to prototype what a designer sketched in the early phases of a project in a few hours, is to make order in something that usually is very low fidelity and just a little more than a rough idea.
It can be pretty hard to find solutions on the spot for issues that pop up once you start doing things more rigorously, especially when building custom tools and visualisations such as this one.
The approach to get a similar result was to cycle every single point of the map, find its distance from the nearest point on the curve and find the length of the curve to this nearest point. These two values were then drawn on the two axes, resulting in the distorted map.
The prototype was obviously far from perfection, but its purpose was to show the feasibility of the idea and find the improvable areas.
We were starting to improve the algorithm, but then someone noticed a distraction on the screen of Cesare — one of our developers.
This little experiment was a sphere, distorted by oscillating tridimensional functions, resulting in interesting shapes. Even more interesting are the animations you can build by varying the parameters of the oscillations.
He called it CyberFlowers — it’s developer humor, I suppose.
Another designer of our team saw it and got inspired, so he decided to introduce a similar blobby shape in the long scroll map design.
And to play with the morphing behaviour to explore data.
We started using that shape to give a first glance of the difference in Google Trends’ score between the US and the selected country.
Blobs were used also in the details section for each country, and I think they should already look somewhat familiar by now if you’ve seen the final product, especially on a blue background!
To emphasise the gooey nature of the visualisation we chose, working title for this was Goo-gle.
Blobs were well received, as they are a soft and intentionally fuzzy depiction of data, despite the idea that data visualisation should always be rigorous and hyper precise. They fit quite well in describing Google Trends data, as each chart is scaled on a 100 score individually, for example the country that searches one entity the most has always a score of 100, even if the actual number of queries is 2, 150 or 30'000'000.
And, most of all, Google Trends’ data only give us a hunch of what the country might be interested in, but it’s absolutely not a perfect depiction of the reality of this country, as not everyone uses internet or uses Google search to gather information about their interests.
With Google Trends we get a glimpse of what a part of the population of a country is interested in, we can’t get the whole picture. And that’s fine.
When faced with kinds of data that are not perfect or based on absolute values, it’s often better to embrace a purposefully visual representation of uncertainty.
So we decided to scrap the map and instead go full blobby.
Part Two: developing, designing
On developing and designing for the unexpected
This was the shape we settled for, consisting in a circle showing each country’s value and a connection between them to make the gooey effect.
Once you have some data, these shapes are pretty easy to draw in your favourite editor, they are a couple of circles and a path that connects them filled with a gradient.
Coding such shape to be interactive and compatible with mobile devices, on the other hand, is another kind of story!
The first step was to draw the bubbles, easy to do with many modern web techniques, and to scale them from the data to highlight the difference between them.
The second step was to blur the bubbles. It’s very easy to do it using SVG or CSS filters, but it turned out to be very heavy on smartphones, so we fell back to the old HTML canvas.
Since pixel-manipulation blurring on canvas is very slow, we relied on drawing directly a radial gradient in place of a circle, with custom color stops to resemble a Gaussian blur.
The third step was to create the so-called gooey effect, by increasing the alpha-channel contrast. That means sharpening the blur narrowing the transparency variation to a single step.
This is usually done with SVG filters, but because of mobile support they were not viable, so we used pixel-manipulation within a custom WebGL shader in order to be super-fast.
At the fourth step, we needed gooey connections between bubbles. We tried lots of experiments on this, and the best method was to draw a blurred stick, and let the AlphaContrast do its job. The difficult part was to scale the width of the stick according to the size of the two bubbles it connects. The trick was to consider only the smaller of the two bubbles.
The last step was to put it all together and make every transition as smooth as possible on every device.
To do that we relied on custom easing functions to be able to tweak every single aspect.
Calibration and experimentation on random data was crucial to make it wonderfully blobby!
While the dev team refined the bubbles, we worked together with journalists at Google News Lab to define the final topics and related quotes.
Once the development of the shapes was polished, we were able to implement these shapes into the UI.
We were pretty satisfied with the result and, as the election date was getting closer and closer, we were getting anxious about releasing the app into the wild, as we wanted everyone to play with it.
But, as you all know, Murphy’s law is not very compassionate, so…
If everything seems to be going well,
you have obviously overlooked something.
In fact…
So things got a little crazy at this point, and we had to go through the UI quite a bit, to tweak the whole thing to add an on/off switch for the US data and remove the candidates’ quotes we had about each single topic.
While we were at it, we also took the chance to rework some other UI elements, because… why not right?
Part Three: the final product, finally!
On swipes, taps and wiggles
Side swipes change the view type, aka the way blobs are arranged on screen.
Vertical swiping changes topic, and most of the actionable area has been put on the bottom of the screen, to help users explore the website comfortably with just one hand.
As you can see we added a toggle on the bottom right of the screen for toggling US data on or off, and chat bubbles only show a description of what you’re looking at, instead of actual candidates’ quotes on that topic.
Part Four: what did we learn?
On why we think collaboration is 🔑
The most important thing we realised is that the collaboration between design and coding was the key for the success of this project, it was actually more than a collaboration.
It was a constant iteration and back and forth, where the inputs from the developers changed the design immensely, and helped us achieve something that was unexpected and definitely resulted in a fresher outcome.
We believe this type of integration is the key for our future, especially thinking about how in data visualisation both aspects are equally important.
It’s a domain in which mathematics and aesthetics must work together.
If you think about it, there are many people that find this balance in themselves already, like the masters Moritz Stefaner and Santiago Ortiz.
We, as a studio, have to find this balance among multiple human beings.
How to build and improve the relationship between designers and coders, is what we’re working on every day.
Working with developers from the beginning of the project and involving them in the creative process and not just in the production phase is what we believe is the proper way to go in this direction, and the results we got from this project tell us we’re on the right track.
Collaboration and mixing of different knowledge is something that must not be overlooked, and instead must be encouraged and embraced, especially in the present times, when unfortunately many things lately seem to point towards the opposite way.
