Pipeline Incidents

Energy Visualization

Pipeline Incidents is an interactive data visualization featuring open data from National Energy Board-regulated pipelines. It is a variation of the parallel coordinates visualization that allows for limitless customization and filtering for free exploration into the dataset.

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

Role:

  • Visualization Designer

  • Interaction Designer

Tools:

  • Tableau

  • Adobe Illustrator

  • Adobe InDesign

  • Paper Prototypes

  • Interactive Prototypes (Invision/Atomic)

Design Process

Overall Objective

We want to make NEB's data not just open, but accessible to the general public through the use of interactive visualizations. We also want to create a visualization that is not only engaging for the general public, but allows them to find interesting stories that can be shared and used as a starting point for public engagement between members of the public and the NEB.

Background

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.

Data Exploration

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. We also worked with data experts in order to get a handle on the stories behind the data which were not immediately clear without background context.

data_explore1

Exploring Incident Locations with Tableau

data_explore2

Data Collaboration Workshop at the NEB

Ideation

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.

ideation1

Design Wall of Ideas

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 was not the most compelling given this dataset.

ideation2

Timeline+Map Mockup

I learned a valuable lesson here about the benefits of low fidelity mockups and iterating quickly, as I had spent over a week creating a more polished mockup than necessary to communicate my ideas. 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.

ideation3

Parallel Coordinates

ideation4

Breakdown of Categories

Design Iteration

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.

iteration1
iteration2
iteration3

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 palete that fits client criterias while still looking cohesive.

iteration4

Basic UI Template

Incident List: A Case of Unstacking Interactions

The most challenging aspect of the visualization was differentiating between a category selection (eg. Alberta incidents) and an individual incident selection (eg. An incident that occurred in CHEECHAM, Alberta on Nov 1, 2012). Our initial way of handling this involved click and hover interactions on top of the bar which leads to a mode switch with a different set of interactions. These stacked interactions were confusing even for us designers, so it would be very frustrating for users to learn.

interactions1

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

I was tasked with creating an 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.

interactions2

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.

Our first fairly rudimentary prototype was created with Illustrator assets and Invision. Click the image to try it out!

interactions4

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.

(Note we switched from Invision to Atomic because we were trying different tools to discover what worked best for our collaborative workflow)

interactions5

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.

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.

One valuable lesson I learned here was that prototypes and early testing are the keys to designing the right interactions. It’s easy to imagine how they might work in your mind but we are not the users and have a different mindset about how to do things.

Style Guide

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, and more.

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

style2
style3
style1

Presentation and Public Engagement

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.

present1

We also had a chance to showcase the visualization at this year’s TEDx Calgary! It was part of the Interactions exhibit and we had the opportunity to engage with many interested members of the public.

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