Lab 06 - Ugly charts

Given below are two data visualizations that violate many data visualization best practices. Improve these visualizations using R and the tips for effective visualizations that we introduced in class. You should produce one visualization per dataset. Your visualization should be accompanied by a brief paragraph describing the choices you made in your improvement, specifically discussing what you didn’t like in the original plots and why, and how you addressed them in the visualization you created.

On the due date you will give a brief presentation describing one of your improved visualizations and the reasoning for the choices you made.

The learning goals for this lab are:

Getting started

Go to the course GitHub organization and locate your lab repo. Grab the URL of the repo, and clone it in RStudio. Refer to Lab 01 if you would like to see step-by-step instructions for cloning a repo into an RStudio project.

First, open the R Markdown document and Knit it. Make sure it compiles without errors. The output will be in the file markdown .md file with the same name.


Your email address is the address tied to your GitHub account and your name should be first and last name.

Before we can get started we need to take care of some required housekeeping. Specifically, we need to do some configuration so that RStudio can communicate with GitHub. This requires two pieces of information: your email address and your name.

Run the following (but update it for your name and email!) in the Console to configure git:

use_git_config( = "Your Name", 
      = "")


This is the second week you’re working in teams, so we’re going to make things a little more interesting and let all of you make changes and push those changes to your team repository. Sometimes things will go swimmingly, and sometimes you’ll run into merge conflicts. So our first task today is to walk you through a merge conflict!

Merges and merge conflicts

Git will put conflict markers in your code that look like:

<<<<<<< HEAD 
See also: [dplyr documentation](   
See also [ggplot2 documentation](  
>>>>>>> some1alpha2numeric3string4

The ===s separate your changes (top) from their changes (bottom). Note that on top you see the word HEAD, which indicates that these are your changes. And at the bottom you see some1alpha2numeric3string4 (well, it probably looks more like 28e7b2ceb39972085a0860892062810fb812a08f). This is the hash (a unique identifier) of the commit your collaborator made with the conflicting change.

Your job is to reconcile the changes: edit the file so that it incorporates the best of both versions and delete the <<<, ===, and >>> lines. Then Stage and Commit the result.


Let’s cause a merge conflict!

Our goal is to see two different types of merges: first we’ll see a type of merge that git can’t figure out on its own how to do on its own (a merge conflict) and requires human intervention, then another type of where that git can figure out how to do without human intervention.

Doing this will require some tight choreography, so pay attention!

Take turns in completing the exercise, only one member at a time. Others should just watch, not doing anything on their own projects (this includes not even pulling changes!) until they are instructed to. If you feel like you won’t be able to resist the urge to touch your computer when it’s not your turn, we recommend putting your hands in your pockets or sitting on them!

Before starting: everyone should have the repo cloned and know which role number(s) they are.

Role 1:

🛑 Wait for instructions before moving on to the next step.

Role 2:

🛑 Wait for instructions before moving on to the next step.

Role 3:

🛑 Wait for instructions before moving on to the next step.

Role 4:

🛑 Wait for instructions before moving on to the next step.

Everyone: Pull, and observe the changes in your document.

Tips for collaborating via GitHub


Run the following code in the Console to load this package.


Take a sad plot and make it better