Project 2

Important dates

TODO

• Proposals for peer review: due Thu, Mar 28 at 11:59pm.
• Revised proposals for instructor review: due Thu, Apr 11 Wed, Apr 10 at 11:59pm.
• Project drafts for peer review: due Thu, Apr 25 at 11:59pm.
• Write-up and presentation: due Sat, May 10th at 9am

Important

The details will be updated as the project date approaches.

Introduction

Your task for this project is to create something related to data visualization.

This is intentionally vague – part of the challenge is to design a project that showcases best your interests and strengths.

One requirement is that your project should feature some element that you had to learn on your own. This could be a package you use that we didn’t teach in class (e.g., a package for building 3D visualizations) or a workflow (e.g., making a package) or anything else.

If you’re not sure if your “new” thing counts, just ask!

Ideas

Your first task is to come up with a goal for your project. Here are a few ideas to help you get started thinking:

• Build a Shiny app that that has an Instagram-like user interface for applying filters, except not filters but themes for ggplots().
• Create an R package that provides functionality for a set of {ggplot2} themes and/or color palettes.¹
• Do a deep dive into accessibility for data visualization and build a lesson plan for creating accessible visualizations with ggplot2, Quarto, and generally within the R ecosystem.
• Create a data-driven story using scrolltelling.
• Build a complex dashboard.
• Create 3D printed data visualizations.

And, of course, your project can be about visualizing a dataset of interest to you (similar to your first project). The only rule about this dataset is that it can’t be from TidyTuesday. Beyond that, it should be something truly of interest to your team, and a dataset that allows for a deep exploration.

Most importantly, be prepared to brainstorm a bunch of ideas and discard them until you settle on a topic that everyone in the team is happy with and feels like a good choice for showcasing what you’ve learned in the class and how you can use that to learn something new and implement for your project.

Deliverables

TODO

The primary deliverables for the project are:

1. A project proposal.
2. A reproducible product in a format based upon the type of project you propose.
3. A final report that explains the process and results.
4. An oral presentation.

There will be additional submissions throughout the semester to facilitate completion of the final product and presentation.

Repository organization

Since you have complete freedom on the focus of your project, you also have complete freedom on the organization of your repository. But… it should be organized in a logical way!

At a minimum each project should have a README. This can be a README.md that you edit directly or a README.qmd that you edit and render to README.md. If your project is analyzing a dataset, you’ll probably want to structure your repo similar to your Project 1 repo. If you’re building a package, it should be structured like a package.

Deliverables

Proposal

Your proposal should include:

• A one sentence description of your high-level goal (such as the ones listed under Ideas above).

• A one to two paragraph description of your goals, including your motivation. Depending on the focus of your project, the following might go in here.

  • If using particular dataset(s), a brief description of each dataset including the reason why you chose the particular dataset, its dataset, its dimensions and any other relevant metadata. (Make sure to load the data and use inline code for some of this information.)

  • If answering a particular research question, the question itself and the reason why you chose this question.

• A weekly “plan of attack” outlining your steps to complete your project and including the team member(s) assigned to that task.

• The final organization of your project repository. This means describing the project organization in your proposal as well as implementing that organization in your repo. Create any folders needed and place a README.md in each folder explaining what goes in there.

Peer review

Reviewer tasks

Each team will review the proposals of two other teams during the project. On those days teams will have access to the project repos of the two teams whose work they’re reviewing.

The peer review assignments are as follows:

TODO

Teams will develop the review together, with discussion among all team members, but only one team member will submit it as an issue on the project repo. To do so, go to the Issues tab, click on the green New issue button on the top right, and then click on the green Get started button for the issue template titled Peer review.

This will start a new issue with a peer review form that you can fill out. Make sure to update the introductory paragraph with your team name and the names of the team members participating in the review. Then, answer each of the questions in the spaces provided underneath them. You’re expected to be thorough in your review, but this doesn’t necessarily require lengthy responses.

Remember, your goal is to help the team whose project you’re reviewing. The team will not lose points because of issues you point out, as long as they address them before I review their work. You should be critical, but respectful in your review. Also remember that you will be evaluated on the quality of your review. So that’s an additional incentive to do a good job.

Reviewee tasks

Once you receive feedback from your peers, you should address them. You should do this by directly updating your proposal or making any other updates to your repo as needed. You can do these updates all in one commit or you can spread it across multiple commits.

Regardless, in the last commit that addresses the peer review comments, you should use a keyword in your commit message that will close the peer review issues. These words are close, closes, closed, fix, fixes, fixed, resolve, resolves, and resolved and they need to be followed by the issue number (which you can find next to the issue title). So, your commit message can say something like “Finished updates based on peer review, fixes #1”.

Write-up

Your have a lot more freedom in how you structure your write-up for this project compared to Project 1. This also comes with responsibility. You should make sure you have a clear introduction and a clear conclusion. You should also have other interim section headings that help the reader. Your write-up should be somewhere between 1000 and 2000 words. There is no expectation that you get close to the upper limit, anywhere in that range is fine as long as you have clearly explained yourself. The limits are provided to help you, not to set stressful expectations.

Note

Many project teams are creating interactive web applications, packages, and/or things that are not traditional “reports”. The write-up component is intended to evaluate the design and implementation of whatever “final product” your team creates. Rubric elements will be interpreted by the instructor in light of whatever approach your team takes for the final product.

Presentation

Your presentation should generally follow the same structure as your write-up. Each team will have 5 minutes for their presentation, and each team member must speak (roughly equally) during this time.

You should create your presentation in a reproducible way, e.g., using Quarto. However you don’t have to use a package that is designed specifically for slides. If you prefer to build a dashboard or a Shiny app or a website, that’s fine too. The only rule is that it’s built reproducibly in R.

Your evaluation will be based on your content, professionalism (including sticking to time), and your performance during the Q&A (question and answer). We don’t care how many slides you use to do this.

Website

Each of your projects will have a website. You can use the same workflow as for your first project or create something different. For example, if your project is building a dashboard, you might consider making your write-up a tab on that dashboard. Or if it’s building a package, you might consider making your website using the pkgdown package. Feel free to google your way around it or ask on the discussion forum or in office hours!

Each of your projects should have some sort of online presence. For instance:

• Static dashboards can be published using GitHub Pages.
• Shiny applications can be published using shinyapps.io.
• Packages should be organized in the repo so they are directly installable using remotes::install_github(); documentation websites can be generated using pkgdown.
• Reports or tutorials can be published as a Quarto website.

Overall grading

TODO

Total	100 pts
Proposal	10 pts
Presentation	35 pts
Instructor	30 pts
Peers	5 pts
Report	35 pts
Reproducibility, style, and organization	10 pts
Between team peer evaluation	10 pts

Evaluation criteria

Proposal

Category	Less developed projects	Typical projects
Dataset	Dataset is missing from the data folder. Dataset lacks a codebook.	Dataset is in the data folder. Codebook for the dataset is included as the README.md file in the data folder
Write-up	The write-up is missing one or more required components.	All required components are included in the write-up.
Workflow	Peer review issues are left open or do not have associated commits which respond to the feedback.	Peer review issues are closed via a commit message.
Teamwork	One or more team members do not have commits in the repo.	All team members contribute to the repo via commits.

TODO old criteria

• High level goal
• Expanded description
• Plan
• Repo organization
• Workflow - Peer review issues closed via commits. (1 point)
• Teamwork - All team members must contribute to the repo via commits. (1 point)

Presentation

Teaching team

Category	Less developed projects	Typical projects	More developed projects
Time management	Only some members speak during the presentation. Team does not manage time wisely (e.g. runs out of time, finishes early without adequately presenting their project).	All members speak during the presentation. Team does not exceed the five minute limit.	Team maximally uses their five minutes. Clearly communicates their objectives and outcomes from the project.
Professionalism	Presentation is slapped together or haphazard. Seems like independent pieces of work patched together.	Presentation appears to be rehearsed. There is cohesion to the presentation.	All elements of typical projects + everyone says something meaningful about the project.
Slides	Slides contain excessive text and/or content. Team relies too heavily on slides for their presentation.	Slides are well-organized. Slides are used as a tool to assist the oral presentation.	All elements of typical projects + graphics and tables follow best-practices (e.g. all text is legible, appropriate use of color and legends). Slides are not crammed full of text.
Creativity/originality	Project meets the minimum requirements but not much else. Project is incomplete or does not meet the team’s objectives.	Project appears carefully thought out. Time and effort seem to have gone into the planning and implementation of the project.	All elements of typical projects + project goes above and beyond the minimum requirements.
Content	Questions are not clearly stated. Questions are unanswered or not supported by the data visualizations. Data visualizations are poor quality and do not adhere to practices as taught in class.	Questions are clearly articulated. Questions are answered using supporting data visualizations. Data visualizations follow good practices. Conclusions made based on the visualizations are justified.	All elements of typical projects + data visualizations are of exceptional quality. Conclusions are justified and limitations are carefully considered and articulated.

TODO old criteria

• Time management: Did the team divide the time well among themselves or got cut off going over time? (2 points)

• Professionalism: How well did the team present? Does the presentation appear to be well practiced? Did everyone get a chance to say something meaningful about the project? (2 points)

• Teamwork: Did the team present a unified story, or did it seem like independent pieces of work patched together? (3 points)

• Slides: Are the slides (or other presentation medium) well organized, readable, not full of text, featuring figures with legible labels, legends, etc.? (3 points)

• Creativity / Critical Thought: Is the project carefully thought out? Does it appear that time and effort went into the planning and implementation of the project? (3 points)

• Content: Including, but not limited to the following: (12 points)

  • Is the question/objective well articulated in the presentation?
  • Can the question/objective be answered with the data?
  • Do(es) the final product answer the question?
  • Do(es) the final product follow good visualization practices?
  • Is/are the conclusion(s) made based on the final product justifiable?
  • Are the limitations carefully considered and articulated?

Peers

• Content: Is the project well designed and is the data being used relevant to the focus of the project?

• Content: Did the team use appropriate methods and did they interpret them accurately?

• Creativity and critical thought: Is the project carefully thought out? Are the limitations carefully considered? Does it appear that time and effort went into the planning and implementation of the project?

• Slides: Are the slides well organized, readable, not full of text, featuring figures with legible labels, legends, etc.?

• Professionalism: How well did the team present? Does the presentation appear to be well practiced? Are they reading off of a script? Did everyone get a chance to say something meaningful about the project?

Product

TODO

• Introduction: The introduction provides a clear explanation of the question and the dataset used to answer the question, including a description of all relevant variables in the dataset. (3 points)
• Justification of approach: The chosen approach and methods are clearly explained and justified. (3 points)
• Code: Code is correct, easy to read, properly formatted, and properly documented. (10 points)
• Final product: The final product is appropriate, easy to read, and adheres to best-practices as taught in this class. (10 points)
• Discussion: Discussion of results is clear and correct, and it has some depth without begin excessively long. (4 points)

Report

TODO

Reproducibility, style, and organization (10 points)

Category	Less developed projects	Typical projects
Reproducibility	Required files are missing. Quarto files do not render successfully (except for if a package needs to be installed).	All required files are provided. Project files (e.g. Quarto, Shiny apps, R scripts) render without issues and reproduce the necessary outputs.
Data documentation	Codebook is missing. No local copies of data files.	All datasets are stored in a data folder, a codebook is provided, and a local copy of the data file is used in the code where needed.
File readability	Documents lack a clear structure. There are extraneous materials in the repo and/or files are not clearly organized.	Documents (Quarto files and R scripts) are well structured and easy to follow. No extraneous materials.
Issues	Issues have been left open, or are closed mostly without specific commits addressing them.	All issues are closed, mostly with specific commits addressing them.

Between team peer evaluation

Peer reviews will be graded on the extent to which they comprehensively and constructively address the components of the reviewee’s team’s proposal.

• 0 points: No peer reviews

• 2 point: Only one peer review issue open, feedback provided is not constructive or actionable

• 4 points: Both peer review issues open, feedback provided is not constructive or actionable

• 6 points: Both peer review issues open, feedback provided is not sufficiently thorough

• 8 points: Both peer review issues open, one of the reviews is not sufficiently thorough

• 10 points: Both peer review issues open, both reviews are constructive, actionable, and sufficiently thorough

Acknowledgments

• Project instructions draw in part from STA 313: Advanced Data Visualization and INFO 2951: Introduction to Data Science with R

Footnotes

1. Never built an R package before? See https://r-pkgs.org/whole-game.html for a great introduction.