Interactive Infographics: How the development process changes

Brainstorming and designing infographics is a hard process to get right, but one that people have slowly honed and now there are some great resources to help guide the process. Two great articles are Sarah Slobin's "The 7½ Steps to Successful Infographics" and our favorite, from Sneh Roy, "The Anatomy Of An Infographic: 5 Steps To Create A Powerful Visual".

In her article, Sneh breaks the infographic development process down into 3 main blocks:

  1. Visual (colors, graphics etc.)
  2. Content (statistic, references etc.)
  3. Knowledge (deductions)

It is easy to see that the break down makes a neat description of what makes up an infographic.

The process for designing an infographic changes slightly depending on whether you are starting with data or an idea or from some other point. However the process will generally follow along the lines of:

  1. Project Manager puts together the concept and gives to the designer.
  2. Designer designs and sends back design.
  3. A bit of back and forth to polish it off.

So far, so good.

Enter Interactivity

While any image can be faithfully and accurately displayed across the web, an interactive infographic is a whole different beast; to have it accurately and consistently render across the various browsers and mobile devices is no less difficult than it is for a normal webpage. In fact, it is more complex normally because interactive infographics will normally have a design that is non-typical of a webpage, and the interactive behavior adds further complications.

We just made an interactive infographic, and through the process realized just how true all this is. We faced a lot of challenges that simply weren't even a consideration with creating static infographics. All 3 of the components parts of an infographic mentioned above (Visual, Content, Knowledge) are impacted by deciding to make an infographic interactive.

What we realized is that the whole process of designing an interactive infographic is markedly different, and interactive infographics need their own process.

Process change #1: Multiple Target Audiences

Infographics tend to come about in one of 2 ways:

  • You (or your client) have some data that you believe could be interesting to people, and want to visualize it for some PR/links.
  • You (or your client) are aware there is some public data that could be represented as a cool visualization that would interest people.

In either of these scenarios it is likely that there is a specific demographic that will be interested in the visualization, so you ensure to tailor the design to target that audience.

However, with interactive infographics you are introducing another aspect: the technology you've used to build it. This can, if you are using cutting edge technology or techniques, attract another target audience. There will be many people who follow technology who will be interested by seeing a well built interactive infographic that uses it.

This actually introduces an important decision that the project manager has to decide on before you can continue.

Decisions #1: Which technology? Which audience?

Who is your primary target audience? Those that will love the data/design or those that will love seeing a new technology used well? Following on from that; which technology will you use?

The problem is that the more cutting edge the technology the more you restrict your target audience. For example, a full HTML5 infographic will leave Internet Explorer users unable to see your infographic properly, but would likely attract more attention from the HTML5 crowd.

If you choose HTML5, you'll find some parts of it are more fully supported than others; you'll find the same with the SVG image format whereas Flash and traditional HTML/Javascript infographics will probably be fully supported.

This decision will impact the rest of the process, as it can add constraints to the design right from the outset.

We decided to use HTML5 as the delivery technology for this project even though we knew it would produce a worse experience for some users (Internet Explorer users). We felt that using this delivery method significantly increased the potential audience but while offering the least amount negative experience compared to other technologies such as SVG.

In an effort to improve the experience for Internet Explorer users who are running version 7 or 8 (as these versions don't properly display HTML5), we made use of the <section> tag in place of using div tags or a table layout. This is often referred to as the "shiv method", and is a common way to improve compatibility issues with older versions of internet explorer. This is a way to include a special JavaScript code that supports the HTML5 functionality in older Internet Explorer browsers that would otherwise be unable to support this functionality.

To do this, all sites that incorporate this technique end up linking to the following code provided from Google:

<!-- Pulled from http://code.google.com/p/html5shiv/ -->
<!--[if lt IE 9]>
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

The above code injects basic elements like <section> into the HTML DOM which allows the older Internet Explorer browsers to recognize these elements and lay them out as standard block elements, such as the <div> element. The above code injects the new elements into the HTML DOM:

<!--[if lt IE 9]>
<script>
document.createElement('header');
document.createElement('nav');
document.createElement('section');
document.createElement('article');
document.createElement('aside');
document.createElement('footer');
document.createElement('hgroup');
</script>
<![endif]-->

Additionally, a special set of CSS rules must be included for this purpose (which again pulls from Google):

<!-- Pulled from http://code.google.com/p/html5shiv/ -->
<!--[if lt IE 9]>
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Process change #2: Designer loses to gain

The designer must now operate under the constraints of the build technology, and probably which specific parts of that technology will be used. However, the designer now can add a whole new dimension to the infographic with interactivity:

  • Animation - Elements can pulsate, jiggle or dance to draw attention. They can also swoop in and out when hidden.
  • Click to reveal/hide - The data/story can now be broken down into bite-sized chunks that can be explored as the user wishes.
  • Data manipulation - This is an important point: the user can be given the opportunity to manipulate the data. The can choose to view custom subsets of it which interest them. They could even be given the opportunity to share their customized version.

However, with each of these elements, and the overall design concept the designer has to be fully briefed on what is and is not possible. This will mean close collaboration with the programmer to ensure the design is workable, and the project manager to ensure it stays within the vision.

In designing our infographic, we spent a lot of time going back and forth trying to figure out how to balance what our designer wanted to accomplish and what was possible in HTML. If we were to do this again, the process would be much smoother as the designer is now much better versed in what is and isn't possible with HTML5. This would help the process to be more efficient and we can optimize the experience that we want the user to have.

Process change #3: The Third Man

Previously, a Project Manager and a Designer were enough to create an infographic; sometimes these may have even been the same person. However, with interactivity a programmer is also needed to actually build the infographic in the technology that's been decided on, but also to help select the most appropriate technology to begin with.

It is essential that the programmer be brought on board at the start of the process. Not doing so is one of the biggest problems that can be encountered with interactive infographics; the designer and project manager may decide on a particular technology so as to also target a certain audience, and later find that what they've planned is not possible or suitable in that technology.

Get the programmer on board at the start.

Process change #4: Design Deliverables

For a static infographic, the designer has a nice neat job with a single deliverable: the infographic.

Once there is an element of interactivity this is no longer the case; the designer now has multiple deliverables. The infographic will consist of multiple images, font files, color codes and other elements that the designer will be responsible for delivering.

Again, the designer needs to work closely with the programmer to ensure they know what these deliverables are.

This is one area where we ran into some difficulties - we have resources in different places so the project manager, designer, and developer could all well be in different places. With the amount of intricacy involved in this project, we found often that having a good brief wasn't enough as it is with a static infographic. We spent a lot of time on Skype hammering out details and making sure that everyone was on the same page and things weren't lost in emails or were missed in a lengthy email.

The Interactive Infographic Process

The process now looks like:

  1. Project Manager decides to make an infographic with some data.
  2. Project Manager brings on board a Programmer and Designer.
  3. Project Manager must decide on the balance of technology vs audience, based on discussions with the team.
  4. Designer fleshes out some rough concepts.
  5. The team meets to discuss; each has specific input:
    1. Project Manager: vision and potential target audiences.
    2. Designer: design concepts and how to make it clean.
    3. Programmer: what is possible. Ideas based on what the technology can do which PM and designer may not be aware of.
  6. Designer creates fleshed out design.
  7. Team meets again and iterates over designs until everybody happy.
  8. Programmer puts together technical spec on how it will be built, which will influence deliverables from designer.
  9. Designer sends across deliverables decided by programmer.
  10. Programmer builds the first functional version.
  11. Team meets and probably iterates and refines design in same process.

Part II: Programmer's Notes

Infographics and IE 6

When we created the "Broken Appliance: Repair or Replace" infographic we wanted it to be supported in all browsers for all visitors. IE 6 visitors represent a significant percentage of our traffic, so IE 6 support was very important to us. In the past we have faced problems with IE 6 and transparent PNGs (the foundation of our interactive infographic) and there are also issues with IE 6 supporting HTML 5 elements that are discussed above (see "Decisions #1: Which technology? Which audience?").

These issues were both in addition to the use of ongoing animations that happen on a loop in some cases, and in response to user input in others. All of the animation sequences rely on transparent PNGs shown and hidden in layers (e.g. showing the clickable hotspots, or the symptom information each repair fixes). For example, one of the initial problems we faced was that the animation component images are placed using absolute positioning but all approaches used to resolve the IE 6 PNG transparency issue require the images to use "position: relative". As a result, we immediately experienced layout issues when trying to support IE 6.

We also found that the animations and the initial render of the infographic by the IE 6 browser were slow and cumbersome. After trying several approaches we felt the best solution was to display the entire infographic as a static image with all of the information fully displayed to IE 6 users. This compromise delivers a high quality experience to our IE 6 users even though it isn't as interactive.

Symptoms - Washer Leaks

Figure 1 - Layering of the symptoms animation

Deciding Factor: Complex Animations

Not only did jQuery animation sequences that ran smoothly in a modern browser run slowly in IE 6, the animation relies on several layers of transparent PNGs being revealed in sequence, each overlaying the other and resulting in an expanding cone starting with the appliance part that was affected (e.g. Water Pump).

It looks like the slowness of the animation was a result of the sheer number of PNGs used in the infographic and the layering. In the past, the transparent PNGs we have used have not been layered one on top of the other; we have also always applied animations to DIVs and not directly to images as was done here. Even when the animations were running smoothly we still had the issue of the animation layers not loading in with PNG transparency working.

We are still not sure why we could not apply the overlay transparency code as part of the animation sequence but feel it is related to the way in which IE 6 applies the filter that makes the PNG transparency work. It looks like this filter needs to be applied when the content is initially loaded and rendered by the browser. Because of this we did try pre-loading these images and making them transparent ahead of time, but this did not seem to carry through to the animation process.

Standard Approaches to PNG transparency in IE 6

We tried the following solutions for PNG transparency:

  1. UnitPngFix - http://labs.unitinteractive.com/unitpngfix.php - this excellent script is normally what we use when we need to deal with the IE 6 transparency bug. In the past we have been able to use this script and jQuery together (including using jQuery transitions like "fade()").
  2. When using this script with our infographic we found there was a very long delay in the page load and it failed to make any PNGs transparent that were subsequently loaded by the animations. We attempted to call PNG fix code after each element had been displayed by animation code but this did not result in them being rendered as transparent, and also further slowed the script.

  3. jQuery.pngfix.js - http://jquery.andreaseberhard.de/pngFix/ - because the infographic uses jQuery and our usual approach with UnitPngFix didn't work out well, we decided to then try the jQuery version of this script.

This method initially had good results from a transparency standpoint and is a more configurable solution but, as often happens with the PNG fix, the position of the images were dramatically altered. It is possible to correct the position of each image that has been moved using Javascript CSS positioning after the transparency code has been run, but again this was time consuming, complex, and error prone. Even with the position fixes, we were still unable to carry transparencies through the animation process (one of the key reasons we decided to try this jQuery transparency approach).

Conclusion

We spend significant time and resources supporting IE 6 on PartSelect.com. Each page that is created or changed is tested with IE 6 to ensure our customers using that browser have the best experience we can offer. Sometimes this experience is not identical to what they would have if they were using the latest version of Google Chrome. To make the decision on how we will proceed we ask questions like "Can we guarantee this animation sequence will be smooth and enjoyable for all of our IE 6 vistors?" and "What is more important to IE 6 visitors: the animation and interactivity or the valuable information this graphic conveys?"

In this case the information being delivered correctly was considered more important than providing an identical experience to all of our visitors regardless of their chosen browser.

Back to top