Please have exactly one person in your group create project repo through the GitHub Classroom link here and create a team. Please name your team
project2-groupX, where X is your group number.
Then, the other team members should use the same link and join the existing group.
Each person should then create a project in RStudio which is initialized using the GitHub URL that you are provided when you joined the project on GitHub Classroom.
The end deliverable of this project is the same as Project 1: Create a “blog-post” style writeup in the style of FiveThirtyEight or the NYTimes “The Upshot” column, centered on a related set of informative, accurate, and aesthetically pleasing data graphics illustrating something about a topic of your choice.
Now that we have more data-wrangling tools in our toolbox, however, we can be more flexible about the kinds of questions we can ask and the kinds of visualizations we can create. Specifically, this project adds the following requirements to those of Project 1:
joinoperation of some kind)
Beyond those requirements, you should use whatever tools are useful for examining the things you want to examine. Likely you will end up wanting to use a number of other data-wrangling tools, but you won’t necessarily need every tool we’ve learned in this class.
There may be things you want to do that aren’t easily done using the tools we’ve specifically covered — if that’s the case, you are welcome and encouraged to look into other tools that suit your purposes, but you should only do this if it would help you tell a more interesting story about the thing you’re studying, and only if you feel up to it.
In general, I will take the ambitiousness of your investigation into account when grading — an investigation that minimally meets the requirements will be held to a higher standard of technical precision than an investigation that goes somewhat beyond them — but please try to stay within the length guidelines.
Your group will work together to write a blog post about a topic of your choice, with insights informed by data and illustrated via at least three related data graphics.
The following are some examples of the kind of structure I have in mind (though most of these are longer than your post will be).
Conciseness is of value here: aim for a post in the 700-1000 word range (not including the Methodology section at the end). A suggested structure is as follows (though, apart from the inclusion of the Methodology section at the end, you do not have to adhere to this exactly):
Sets up the context and introduces the dataset and its source. Tell the reader what the cases in the data are, and what the relevant variables are. However, don’t just list these things: work them into one or more paragraphs that inform the reader about your data as though you were writing an article for a blog.
For each graphic you include, a paragraph or two discussing what the graphic shows, including a concise “takehome” message in one or two sentences. Again, don’t just show graphic, paragraph, graphic paragraph, …, connect your text and graphics in a coherent narrative.
The last section of the main writeup should tie together the insights from the various views of the data you have created, and suggest open questions that were not possible to answer in the scope of this project (either because the relevant data was not available, or because of a technical hurdle that we have not yet learned enough to overcome)
This should be separate from the main narrative and should explain the technical details of your project for a reader interested in data visualization. Explain the choices you made in your graphic: why did you choose the types of graphs (geometries) that you did; why did you choose the aesthetic mappings you did, why did you choose the color schemes you did, etc.
Collaboration on your project should take place via GitHub commits. Your
.Rmd source should be part of a GitHub repo from its inception, and changes should be recorded via commits from the account of the person who made the edit. Everyone in the group should be making commits to the repo.
Your final submission will consist of
.Rmdto compile successfully.
If your data is available on the web, prefer to read it directly from the web in your R code. If you needed to download and “clean up” the data outside of RStudio, and thus need to read it from a
.csv file stored locally (that is, in your RStudioPro server account), commit this file if it is relatively small (no more than a few MB in size), and make sure that you are using a relative path to the file when you read in the data. If you have a local data file which is larger than a few MB, you can instead share it via Slack and include instructions in your GitHub
README.md file that indicate where it should be placed.
Whatever state the files in your GitHub repo are in at the deadline is what I will grade.
You can use any data sources you want, but you will need to combine data from at least two sources, so find datasets that have shared variables.
Some possible sources for data are:
nycflights13: data about flights leaving from the three major NYC airports in 2013
Lahman: comprehensive historical archive of major league baseball data
fueleconomy: fuel economy data from the EPA, 1985–2015
fivethirtyeight: provides access to data sets that drive many articles on FiveThirtyEight
You can find data anywhere else you like. But don’t use a dataset we’ve used in class or homework, and this time, at least some of your data must not come from an R package.
Sometimes when a lot of people are reading in datasets and leave their RStudio sessions open, it can eat up a lot of memory on the server and slow things down. To minimize this issue, please close your RStudio project and sign out from the server (by clicking Sign Out in the upper right, not just closing your browser tab) after each session you spend working on it, so that the memory used by your session can be released.
pullbefore you do anything else. This will save you headaches.
commit. If you’re ready to share it with your group, then
pulling every time you sit down to work on it, but if not, you may need to go into the file and manually resolve the changes by finding the markup added by GitHub (look for
<<<<) and editing the file to keep what you want from each version, then
committo merge them in the repo and
push. If this happens, notify your group members that you are undertaking a manual merge, so they do not continue to make edits in the mean time!
A suggested division of labor is that each group member is individually responsible for
and the group as a whole works jointly on
Your group may choose to divide the work differently, but be sure that each person is involved in
.Rmd(not included from an external file)
mutate(), possibly involving other wrangling or cleaning functions within the definition of the new variables)
join()operations, and potentially with