Getting Started: The data

When developing my visualization for the IronViz competition I wasn’t sure where to begin. I thought that I needed a good data that would stand out from all other competitors. From early submissions, I saw a lot of competitors using similar datasets—I’m no different in this regard, but I think my process to get to this conclusion was much different than other competitors. The data I decided to use was more a product of my design philosophy for this competition than being able to find a unique, distinguishing dataset. Actually, I considered a number really interesting ideas—all which I possessed at some point during this month, but I decided to go a different route altogether.

Originally, I really focused on trying to find a very unique data set. I scraped data from the webz to find the locations of major grocery store locations and then determined  the distance from the centroid of every census track to the nearest grocery store. The plan was to look for trends in this data and make a color-coded clickbait map. I was actually almost done with the proof-of-concept when I stumbled upon a different dataset. As a Blue Apron user, I considered scraping recipe ratings and gathering insights about the best and worst meals. Finally I gathered geodata on food deserts in the United States at the census tract level and identifying patterns between food deserts and the characteristics of people who lived in these places. I decided to save this a future project, as well.

It bothered me about all this is I was finding a really cool data sets that would be very interesting in general, but I wasn’t really showcase seen the quality of tableau desktop. In one last search, I’ve came across a National Geographic visualization about food consumption. This I thought was really interesting and I wanted to see the underlying data. Luckily, National Geographic provided a link to FAOSTAT, a site that contains information about about food consumption around the world. I really wanted to data about overall foot habits in my data tool but my kept focusing and wondering about world meat consumption. I know that meat consumption was a big issue—as populations develop more more meat is consumed by population and generally speaking meat has a large impact on the environment. It also fit nicely with the theme #foodtipsmonth, so meat consumption became the focus of my visualization as did showcase the possibilities of data visualization in Tableau.

Tableau: The Focus of the Competition

Because it’s in written form, I feel like the context of this next section might be missed. Tableau is a great tool, but in some areas it falls short. In this next section, I discuss what I feel are some of the shortfalls of Tableau.

Story Points. When developing this visualization—this data tool—I really wanted to tell the story of meat consumption across the world, the differences in meat consumption by major world regions, and the impact it has on the environment. I also wanted to highlight some features of Tableau that I wish were present, but, generally, are still not possible without a lot of work. I tried really had to try to hack as much of the data tool as I could, I really think that this speaks more about the competition then a really interesting data set.

The final design I came up with reminds me of my first ever encounter with Tableau. I wanted to make a dynamic report combining both text and data-based graphics—because I believe that we should go beyond just a dashboard, we as developers should really should create a tool with some context. And other experts like Stephanie Evergreen agree.  And when we often create dashboards with lots of filters on the right part of a screen and and multiple visuals scattered on a single page, the story within the data gets lost. I wanted to go back to the style of my first project in Tableau—provide a mini report and interesting graphics that enhance the story.

I really wanted to the use the Story feature in Tableau. I’ve used it once before, but I found the functionality rather limited. Story points uses a lot of screen real estate. The borders are too large. The captions take up too much space. And what if I wanted to put the caption at the bottom of the page? Or what if I didn’t want captions altogether? I see the concept as perfect for both mobile design and as a best practice for focusing users. I think it’d be really cool if I used it in mobile and when I swipe left or right the story points moves to the next card. I see all of these as opportunities to highlight in this competition. When I saw a tweet from Jewel Loree on how others use story points, it was the tipping point.

Interactive Text. I think in part because of my design philosophy, I think copy (text) is a big an integral part of data telling the story. It’s always been my desire to have text that interactive and linked to charts in Tableau. For instance if the text focuses on a specific subset of the data, and this is something that is color-coded in a graphic, I might want to highlight that information by hovering my mouse over the text. When I do this, it highlights a specific part of the chart. This way the graphic and the copy are linked and interactive. We often see this right now in some of the HTML/javascript/D3.js designs on the New York Times, Wall Street Journal and other major online news sources. With my data tool I developed here, I tried to create interactive text by embedding visualizations within a text to show exactly what I want. It’s not perfect, but I think the concept is there.

R Server. Finally, it’d be great to showcase R’s capabilities in Tableau Public, but it’s not available so all the cool stuff I do in R has to be done ahead of time. This isn’t a big deal, but it’d be nice to showcase the possibilities. I use R A LOT. Often if I want to do some cool graphic in Tableau I prep the data ahead of time in R. This is no different. But it’d be great to be able to use it on Public. Here is 1/3 of the code I used for the IronViz challenge

meat_summary %

##  Select only meat data from 1992 to 2011
    stringr::str_detect(Item, 'meat') | stringr::str_detect(Item, 'Meat') | stringr::str_detect(Item, 'Seafood'),
    Year <= 2011, Year >= 1992,
    Item != 'Meat'
  ) %>%

##  Edit variables
    Item = ifelse(Item == 'Meat, Aquatic Mammals', 'Meat, Other', Item),
    Region = ifelse(Country == 'World', 'World', Region)
  ) %>%

##  Select specific columns
  dplyr::select(Region, Country, Item, Year, Value, Population, Total) %>%

##  Set aggregation level
  dplyr::group_by(Region, Country, Item, Year, Population) %>%

##  Create aggregated variables
    Value = sum(Value),
    Total = sum(Total)
  ) %>%

##  Set new aggregation levels
  dplyr::ungroup() %>%
  dplyr::group_by(Region, Year, Item) %>%

##  Create aggregated variables
    `Value Wt` = sum(Value*Population)/sum(Population),
    Total = sum(Total),
    Population = sum(Population)
  ) %>%
  dplyr::ungroup() %>%

##  Left join meat_id -- for sorting meats
  dplyr::left_join(meat_id) %>%

##  Order rows in data frame
  dplyr::arrange(Region, Year, meat_id) %>%

##  Set aggregation levels
  dplyr::group_by(Region, Year) %>%

##  Get cumulative sum of varibles (for stacked bar charts)
    ValueStacked = cumsum(`Value Wt`),
    TotalStacked = cumsum(Total)
  ) %>%

##  Set aggregation levels
  dplyr::ungroup() %>%
  dplyr::group_by(Region, Year) %>%

##  Create steam chart data.
    ValueSteam = ValueStacked - (max(ValueStacked)/2),
    TotalSteam = TotalStacked - (max(TotalStacked)/2)

Other Design Considerations

Mobile or Desktop? I struggled with the layout. Should it be for mobile? Or should it be a larger tool made for a desktop? When I think about the usage of dashboards and tools in the way that most information is consumed today, I think mobile design. First, the constraint forces the designer to create a tool that clearly and concisely tells the story at hand. Second, designers are forced to create clean, relatively simple data graphics,—whether it is a bubble chart, a line graph, or some other way of displaying data. When desktop tools are utilized, we data tool designers are more likely to make some lazy decisions and might not think about the full data tool experience.

Plus, a competitive event like the IronViz Feeder necessitates a zig while the competition zags.

Scrolling vs. Drilling down. When it comes to mobile design, you basically have two options, scroll or drill down. I’d normally design for scrolling. I really think thats just what people like to do. Look at most websites today, most sites have infinite scrolling to keep the user engaged. The only reason I chose to go the drill down route was to show off how I’d like to see story points look in the future.

Is seafood a meat? According to FAOSTAT: no. But if I talked to a vegetarian, would they call it meat: maybe, but generally yes. When creating the tool, I had to decide whether or not to include seafood as a meat. Clearly, overconsumption of seafood, particularly fish, is an issue. So in the end I did include seafood and fish. Most other articles out there don’t consider seafood meat, so my story is slightly different.

Bacon Charts. I was playing around with the data and I made a mistake in R doing the calculations, but I liked the end result, I thought I generally resembled bacon. I added a cosine function in Tableau and added a wave to it and came up with a food-themed bacon chart. With the case of the chart, the whitespace in the bacon chart represents an earlier time where meat consumption was lower. It also looks like like bacon. MMmmmm, bacon. See, sometimes mistakes can be good. Bacon.

Testing for multiple browsers. I use Tableau Desktop on a Mac and I check my work on Tableau Public using Chrome. I always worry about rendering—fonts in particular. They tend to render differently on different systems, so when doing my work I also check to see how things render in Internet Explorer on a PC. Doing the quality assurance on this project was not fun, I kept finding that my interactive text boxes were not aligning perfectly in Internet Explorer like they where in Chrome. This meant lots of tweaks. Over a few hours I worked out all of the minutiae.