Pipeline Incidents

Energy Visualization

Pipeline Incidents is an interactive data visualization featuring open data from National Energy Board-regulated pipelines. It is based around a parallel coordinates visualization that allows for unlimited customization and filtering for both an overview and targetted exploration into the dataset.

The visualization is available online at https://apps2.neb-one.gc.ca/pipeline-incidents/


  • Data Visualization Designer

  • Interaction Designer


  • Tableau

  • Adobe Illustrator

  • Adobe InDesign

  • Paper Prototypes

  • Interactive Prototypes (Invision/Atomic)


This visualization is a part of the Energy Visualization Project: a collaboration between the Interactions Lab at the University of Calgary, the Government of Canada's National Energy Board (NEB), and VizworX.

The NEB has a vast amount of open datasets, but much of it is in cryptic and complicated spreadsheets that only data scientists can understand. We want to make it so that this data is not just open, but accessible to the general public through the use of interactive visualizations. The overarching design goal for the project is to create a platform to explore interesting data stories that can be shared and used as a starting point for engagement between the public and the NEB. Every dataset has countless stories behind it, our goal is to present them in an accessible and engaging manner.


The dataset for this project has 1112 incidents that occurred on NEB-regulated pipelines. Each individual incident has various aspects related to it such as location, company, what happened, substance released, reported date, and so forth.

Our initial exploration for data understanding involved manipulating the data with various tools such as Tableau, in order to understand its form and find interesting trends that might be worth highlighting. Collaboration with data experts was a big part of this project as the stories behind the data were not immediately clear without extra background context. 


Exploring Incident Locations with Tableau


Data Collaboration Workshop at the NEB


We knew early on that location data was important for this visualization because it provides a familiar grounding to understand the incidents from a layperson’s perspective. Another direction that we explored was timeline driven selections for similar reasons. Of course, we didn’t want to restrict ourselves to this and explored a vast contrast of different ideas, as evident in our design wall from weeks of exploration.


I tried to incorporate the map and timeline idea to create an interface where users can use these as controls to browse and filter down to specific incidents. I created this mockup of my timeline+map vis to communicate my idea to the team. However, after presenting it, we decided that we wanted something that dug deeper into the data as map driven exploration narrowed the possibilities of the dataset too much.


Timeline+Map Mockup

I learned a valuable lesson here about the benefits of low fidelity mockups and quick iterations. I had spent a week creating a polished mockup but we ultimately ended up moving away from this idea. I had become proud of my work even though it was not the greatest idea. However In the end, some of these concepts came back so the effort wasn’t entirely wasted.

After many more rounds of design exploration, the team settled on a variation of a parallel coordinates visualization. Each column represents one of 14 key aspects of the data, and the gradient/thickness of the lines encode categories and individual incidents. This design was able to express various aspects of the dataset at the same time, allowing users to see overall breakdowns as well as explore deeper into categories of interest.


Rather than entirely abandoning the timeline+map idea, we found a way to incorporate elements of it into the parallel coordinates design. The timeline naturally fits as a column while the map can be represented as if it was a column with connecting lines between adjacent columns.

We went through various iterations to represent the unselected category columns. A basic list  of column headers on the side was not very visually compelling, nor was a bottom legend bar. In order to keep the spirit of the columns, we went with a collapsed sidebar with staggered, cascading bars. This was analogous to pulling a book off a shelf and adding it to the current workspace. A slight on-hover animation gives feedback on the column being selected.


Design Variations for the Sidebar

After many rounds of design iteration and feedback, this is the UI we ended up going with: a minimal looking layout with a very meticulously chosen color palette that fits client criterias while still looking cohesive.


Basic UI Template


A Case Study of Unstacking Interactions

The most challenging aspect of the visualization was differentiating between a category selection (eg. all Alberta incidents) and an individual incident selection (eg. A specific incident that occurred in CHEECHAM, Alberta on Nov 1, 2012). Our initial way of handling this involved click/hover interactions on top of the bar which leads to a mode switch to a different set of interactions. These stacked interactions were confusing even for us designers, so it would be very frustrating for users to learn. Although mobile support was not a high requirement at the time, we still wanted the visualization to be able to have basic functionality cross platforms.


The fact that we needed a table to organize interactions was already a bad sign.

The fact that we needed a table to organize interactions was already a bad sign.

I was tasked with creating a new interaction flow that made more sense and felt intuitive to use. Trying to stay mobile-friendly was tough because there were too many layers of interaction stacked into the bars. I created paper prototype pieces of the various UI components and had various lab members try them out through a self-discovery experiment. This involved describing an interaction goal and then telling participants to describe the most intuitive action to achieve it. We also used these pieces to try and validate our ideas.


Paper Prototyping

This exercise gave us a lot of insight: both comments that verified which of our ideas worked, as well as new ideas that we wouldn't have even considered. Even though it was a fairly informal process, the benefits from spending an afternoon conducting this activity was well worth it.

Through this exercise, we decided we needed to separate the individual incident selection to a separate UI element. A separate Incident List was created as a replacement to hover behavior, which also helped alleviate issues with mobile interactions. More design iterations for this list was conducted, such as deciding whether to stick with pins or switch to the more common “star” interaction. This time, we created interactive prototypes using online tools to test our ideas more throughly.


Invision Prototype, Click the image to try it!

We quickly found out with this prototype that having the star list on the top lead to a “shifting” problem since the bottom list moves as the top list expands, which was quite disorienting. Had we not created this prototype, we might not have noticed until implementation.

Our second prototype moved the star list to the bottom, and separated the star behavior from the selection. Again, click the image to try it.


Atomic Prototype, Click the image to try it!

In this version, clicking to select an incident is a separate control from clicking the star to save it. This was the final interaction flow that we went with after user testing to verify it made sense.

We also moved the show/close button to the bottom of the list in order to properly group related controls together. Overall, the entire list feels more cohesive.

(Note: We switched from Invision to Atomic as we were exploring design tools that worked for our collaborative workflow)

Since these interactions had to be communicated to multiple stakeholders and teams, we created a video in order to walk through the prototype in case the hotspots were lost without guidance.

The most valuable lesson I learned here was that prototypes and early testing are the keys to interaction design. It’s easy to imagine how the interaction flow might work in your mind but we are not the users and have a different mindset about how to do things.


Finally, as a way to deliver our design and assets to the development team, we put together multiple style guides that highlight specific details such as pixel dimensions, color hexcodes, typography and more.

The Style Guide itself was an ongoing process that we iterated on, learning what works best for the developers through a continous conversation to try and communicate vital details.



After the first version of the visualization was launched, we had a chance to showcase it to various NEB staff as well as the general public. We had a launch party involving an assortment of NEB staff from data analysts who work regularly with the data, to enginners working in the field.


We also had a chance to showcase the visualization at 2017 TEDx Calgary! It was part of the Interactions exhibit and we had the opportunity to engage with many interested members of the public. Many people gave good feedback about how this visualization can be a good start in trying to understand pipeline incidents that the media often depicts from a potentially bias perspective. They suggested deeper exploration and links to more details about each incident, showing that our goal of public engagement was definitely on the right track.


Finally, this visualization was also selected for a demo paper presented at 2018 ACM CHI, one of the most prestigious HCI Conferences!

The visualization is available online at https://apps2.neb-one.gc.ca/pipeline-incidents/

peter buk | pushing pixels into ideas.