Behind the scenes: How we came up with our visualizations of Google search interest around the German elections

Christian Laesser
9 min readNov 2, 2017

--

Can we make it more 3D?

Wahl 2Q17 was a joint effort by data visualization freelancers Moritz Stefaner, Dominikus Baur and Christian Laesser, with the Google News Lab (Isa Sonnenfeld, Jörg Pfeiffer and Simon Rogers) and project advisor Alberto Cairo.

Our goal was to visualize the Google search interest around the German elections end September 2017.

Over the course of the project, we launched a lot of different smaller and bigger visualizations, from daily to yearly views of the top searched terms for the candidates on our project site 2Q17.de over embedded widgets on external sites to special interfaces for live events and debates and images and movies for social media.

→ Find a good overview of all the products we produced here.

This article sheds some light on the process behind the project, and all experiments and designs that did not make into the final product — enjoy!

Data explorations and decisions

We started early, and, as usual, key part of our process was to work with real data from the start. Only when working with real data, you can immediately test and see what was actually interesting to look at, and also which new ideas the data can supply you with. While developing, we ran the site in test mode for several months, and explored many many angles on the data in parallel.

In this project, we used

  • pandas for data preprocessing: rapidly exploring different sortings, groupings, aggregations were made extremely easy with this powerful toolkit for statistical computing in Python.
  • Tableau for exploring a variety of data perspectives early on, and even providing our project partners with interactive dashboards to explore the data themselves. Especially the word cloud, bubble chart and treemap features proved very helpful in this project.
  • Gephi for some network analysis early on, although we did not pursue this direction further.

Here are some of the early data and concept explorations we looked at:

Which media are searched for which candidates?
Who occupies which topics, and how does this shift over time?
Tableau dashboards to explore the available data. One could filter on candidate, category, term, time…

Long word clouds (week by week)

Categorized word clouds — grouped by party, people, media, gossip, other

Search “signatures”

How does the association of a term with two candidates develop over time?

Blobby peak charts

😍 but, pretty unreadable
The Tableau chart that later became the design inspiration for the timeline used on the website.

Topics per party

Which topics are associated with which parties? And does this change over time?

Pole position streaks

Showing streaks of being top searched candidate. Luckily, we didn’t go for those, as with Merkel’s almost uninterrupted lead, this one would have turned out quite boring.

Term-candidate networks

Can we identify niches and communities of topics and candidates?

Concept explorations

We also documented potential project directions or components as single slides in a presentation, making it easy to share potential angles with the team and talk about combinations, priorities, …

Concept

All this wide-reaching data and visual immersion is essential for our process, to identify the most interesting angles and perspectives and to strengthen the project’s focus.

Generally speaking, it became clear that we wanted to produce something that

  • provides really good and direct access to this previously unopened data source
  • had appeal to journalists and general public alike, and
  • is interesting and new every single day.

The most important data decision was probably — what is the primary entity we talk about? Candidates? Parties? Topics? … Of course, all those things are tied together, and one can basically “hang” the whole project on one of those, and the rest would follow. But which one?

After a few experiments, we kept coming back to the candidates as the focal point, as their associated queries presented an interesting mix of politics with personal, general interest topics, which seemed like a good representation of what people are looking for in the elections.

But even once that decision was clear, a lot of detail decisions need to be made:

  • Which candidates do we track?
  • How about the parties that have two candidates?
  • How wide a net do we cast — e.g. do we also use terms from microsessions or only words that strictly occur right next to the candidates name in a query?
  • And finally, do we show the most searched terms, or the top trending ones?

All these decisions are design decisions in a sense that they affect the nature of the final data product to a large extent, and in our experience, you really need to immerse yourself into the data first before you can make a good call in all these areas.

Structure

We found two angles especially interesting:

  • the closer look on one candidate on one day with a wide range of search terms
  • and the overview that shows the big picture of the whole election and how interest over the time changes.

With those two angles in mind, we planed out the overall website structure. We developed the idea of the “time zoom” to place our components into the right order:

  • We start with the word cloud, that shows the most used search terms per candidate of one day. This component is quite detailed and offers the reader new perspectives every day.
  • Zooming out a little bit, we picked the pulse charts as the second component. Those charts give an overview over the last 3 weeks and highlight the most active day with the most trending search terms.
  • The last zoom step is the time line that shows the whole election with the top search term of the day.

Structural design

After setting the flow of the website, we started to work on the details of each component. Which options should they have ? What are the needs of the users in a mobile vs a desktop environment? We had a lot of different questions to answer.

All those thoughts ended up in the first functional wireframe of our mobile site:

We used Sketch to design the wireframes and picked Googles Material Design Framework as our design basis. This had a lot of advantages, e.g. the Sketch app is already shipped with a great Material Design Template that made the wireframing process easy and quite fast.

Visual Design

Material Design

Google’s Material Design was our base framework. It answers rudimentary design questions and brings a lot of existing components with it.

The biggest advantage for us was that we can use all the different parts of the framework along the different professions and needs. We could use a predefined color in Sketch and use the same color in react via MUI CSS, that made the design and development process faster and easier.

Colors

Speaking of colors, it wasn’t easy to come up with a rich color palette for our project because most of the main colors were already taken by the political parties. We overcame that issue by normalizing the party colors to the corresponding Material Design colors and picking and additional accent color that wasn’t used by any party. We ended up with a fresh indigo as our main and action color and different tones of gray as our text colors.

Typeface

In terms of type, we stuck with Google’s Roboto as our base font. The type face has a good amount of weight to create well-balanced visual hierarchies and it is more condensed than other fonts, which works great in our text-heavy word clouds.

Branding

Having the structure and visual design basics in place, we worked on the branding aspect of the project. How would people recognize different components published at different places, and how can we set ourselves apart from other Material Design projects?

With purpose of the election and the possible readers in mind, we experimented with a mixture of serious and playful visual components. You can see that clash in our early logo explorations. We experimented with cursor symbols or search glasses to indicate the Google search terms. We played with different symbols to indicate the election as well as the candidates and even a whale because (fun fact) in German, the words for whale (“Wal”) and election (“Wahl”) are quite similar.

Iterating over and over, we found more subtle and promising design directions. We noticed that the letter Q is quite close to the Google search glass. This finding helped us to create a simple the word mark 2Q17, that is easy to use and has still is own flavor.

Upcycling data sketches

A further advantage of having produced a lot of exploratory visualization early on is the we had a lot of visual material to play with. For instance, the seperators on the page were inspired by a dismissed visualization approach — why throw things away when you can repurpose them? 😉

Blobby peak chart
The upcycled version used on the website

Simplicity is hard

One surprisingly challenging feature was the embedding dialog. We wanted to provide journalists with an easy way to embed word clouds in their news websites. Since the word clouds are quite flexible, our first drafts for the embedding dialog contained an abundance of options.

Too many options…

Several rounds of design iterations made us realize that all this complexity could be boiled down to a single choice: either embed the word cloud from 2Q17.de with the latest data and all controls available (“live”), or use a snapshot with a single candidate for a single time frame (day, week, month) (“fixed”). While the former option provides maximum flexibility for visitors, the latter is great for accompanying an article about a certain topic on a given day.

Here you can see parts of our iterative process in refining the embedding dialog:

before
after

Even though the super-flexible options no longer show up in the dialog, they’re still built into the embeddable word clouds — for extra credits, feel free to experiment with cryptic URL hashes for an afternoon to find all options! ;)

Bringing it all together

This is how it all came together in the end product.

The final look of the website was developed in parallel with the look-and-feel to be able to test our visual treatments. We started mobile-first and designed the desktop version as a larger-sized extension of the mobile site. The site was separated into the four different main sections and used a strong visual hierarchy to separate them. Each section consists of a header, a short intro and the component.

From a design point of view, it was really interesting which parts heald up from the beginning (for instance, the basic information architecture), while others needed a lot of iterations and tweaking (such as e.g. the word cloud navigation options — especially on mobile!).

Quite a journey!

This article is a joint production by Christian Laesser, Dominikus Baur and Moritz Stefaner.

If you enjoyed this write-up, make sure to check out also:

--

--