How Technology Changes Our Jobs

Team Members: Sira Horradarn, Swojit Mohapatra, Ryan Pham


Design Rationale

Inspiration

We are trying to explore how jobs have changed over the decades. This was inspired by Jeff's Job Voyager. We thought that while his visualization was a good start, we wanted to address a broader question. It lacked categories. Though Job Voyager allowed you to see how jobs changed, you couldn't see the overall trend of a category such as agriculture. We intend to incorporate salary changes between 1950 and 2010 to better understand how industries are changing, not just individual jobs. We stuck with the stack graph visualization to stay true to the original idea of Job Voyager. We didn't cosider sex while visualizing the changes because we felt it would clutter the visualization and sex isn't a relevant topic for our theme.

Interactions

A major change in our prototype is the visualization starts off displaying the percentage of each job category, compared to Job Voyager which displays all the job titles. This concept is a better fit as our theme has a main focus on the change between job categories. Furthermore, this change still allows the exploration of individual job titles under each category after selecting a single category. We added some intuitive interactions such as highlighting when you hover over a category. Also, when you hover over a category, it will display a tooltip that displays relevant information.

When you click on a category, the visualization changes to display the data about job titles. The main change that occurs is the change of scale. When the visualization displays categories, the y-axis is from 0 to 100. However, when displaying titles, the scale changes from 0 to the percent of population of the selection. To ensure that the viewer is aware of this change, there is a short fade out and fade in of the data along with a scale animation. The y-axis then fills so that the highest tick mark is the largest percent that the category accounted for. This transition is also present when clicking the back button to return to the main page.

Color

Another noteable change between Job Voyager and our prototype is the color pallete. Job Voyager splits its color pallete in two hues of red and blue because it focused on sex differences. Because we get rid of this aspect of the data, we have no 'default' color pallete to fall back on. Also, because there are more than 20 categories and more than 20 titles per category, we relied on D3's default colorscheme to differentiate nominal data.

Development Process

Ideation

Originally we thought about displaying a transposed version of Job Voyager side-by-side with our visualization for quick look up and comparison. However, we believed that this idea would be too cluttered with partitions of the two graphs. Our next idea was to use a bilevel partition that would allow a user to quickly visualize the percentage each category accounts for and how much each title accounts for. We soon realized this was too ambitious. We attempted to port Mike Bostock's example from v3 to v4, but failed. From this point, we realized it made the most sense to keep a similar visualization to the original Job Voyager. We were able to find an example of an Interactive Stream Graph to start our prototype with.

Pivot

The first step we took was to port the example from D3 v2 to D3 v4. This task was much more involved than we anticipated. Given that we were beginners in D3, the API change bewildered us. It took us a couple days to port the example rather than the expected couple of hours even though the three of us were working on it. As we had decided to work on Bi Level Partition, we had to process our data accordingly. Alas, we ran into other bugs and hence, we had to pivot to our streamgraph idea.

Teaming Up And Splitting Tasks

Sira took the lead of development and he delegated tasks to each of us. Swojit lead the ideation portion and helped us narrrow our project. Sira and Ryan split the data wrangling, using Pandas. We met up around 5 times, for 4 or more hours each, and peer programmed with Sira as the "driver." Because Sira took on a larger part in porting the code to v4, Ryan and Swojit took the lead to compelete the rationale and documentation and let Sira get some much needed rest.