Project 2

Modified

May 5, 2025

Important dates

  • Proposal for instructor review: due Thu, Apr 10th at 11:59pm
  • Project drafts for peer review: due Thu, May 1st Wed, Apr 30th at 11:59pm
  • Peer review feedback: due Fri, May 2nd Thu, May 1st at 11:59pm
  • Final product, report, and presentation: due Sat, May 10th at 9am
Important

The details will be updated as the project date approaches.

Introduction

TL;DR: Create something related to data visualization.

Your task for this project is to create something related to data visualization. We are being intentionally vague with that statement because we want you to have the freedom to explore your interests and strengths. This project is an opportunity for you to showcase what you’ve learned in the class and to learn something new. One requirement is that your project must feature a substantial element that you have to learn on your own. At this stage of your education you should be able to utilize your existing knowledge and skills as a foundation to learn new things. The new element could be a package you use that we didn’t teach in class (e.g., a package for building 3D visualizations), a workflow (e.g., making a package or Quarto website), or anything else.

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

Deliverables

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 each team’s project will be different from the others, the organization of your repository will be unique to your project. However we still expect your materials to be reproducible. You should have a README.md in the root of your repository that explains the purpose of the repository, the organization and file structure, etc. This should include a brief description of each folder and what goes in it.

Teams

Projects will be completed in teams of 3-5 students. Every team member should be involved in all aspects of planning and executing the project. Each team member should make an equal contribution to all parts of the project. The scope of your project is based on the number of contributing team members on your project. If you have 4 contributing team members, we will expect a larger project than a team of 3 contributing team members.

Some lab section meetings will be devoted to work on the project, so all teams will be formed within each lab section (i.e. only students in your lab section can be your team members). The course staff will assign students to teams. To facilitate this process, we will provide a short survey identifying study and communication habits. Once teams are assigned, they cannot be changed.

Team conflicts

Conflict is a healthy part of any team relationship. If your team doesn’t have conflict, then your team members are likely not communicating their issues with each other. Use your team contract (written at the beginning of the project) to help keep your team dynamic healthy.

When you have conflict, you should follow this procedure:

  1. Refer to the team contract and follow it to address the conflict.

  2. If you resolve the conflict without issue, great! Otherwise, update the team contract and try to resolve the conflict yourselves.

  3. If your team is unable to resolve your conflict, please contact soltoffbc@cornell.edu and explain your situation.

    We’ll ask to meet with all the group members and figure out how we can work together to move forward.

  4. Please do not avoid confrontation if you have conflict. If there’s a conflict, the best way to handle it is to bring it into the open and address it.

Project grade adjustments

Remember, do not do the work for a slacking team member. This only rewards their bad behavior. Simply leave their work unfinished. (We will not increase your grade during adjustments for doing more than your fair share.)

Your team will initially receive a final grade assuming that all team members contributed to your project. If you have a 5-person team, but only 3 persons contributed, your team will likely receive a lower grade initially because only 3 persons worth of effort exists for a 5-person project. About a week after the initial project grades are released, adjustments will be made to each individual team member’s group project grade.

We use your project’s Git history (to view the contributions of each team member) and the peer evaluations to adjust each team members’ grades. Both adjustments to increase or decrease your grade are possible based on each individual’s contributions.

For example, if you have a 4-person team, but only 3 contributing members, the 3 contributing members may have their grades increased to reflect the effort of only 3 contributing members. The non-contributing member will likely have their grade decreased significantly.

Warning

I am serious about every member of the team equitably contributing to the project. Students who fail to contribute equitably may receive up to a 100% deduction on their project grade.

Please be patient for the grade adjustments. The adjustments take time to do them fairly. Please know that the instructor handles this entire process himself, and I take it very seriously. If you think your initial group project grade is unfair, please wait for your grade adjustment before you contact us.

The slacking team member

Please do not cover for a slacking/freeloading team member. Please do not do their work for them! This only rewards their bad behavior. Simply leave their work unfinished. (We will not increase your grade during adjustments for doing more than your fair share.)

Remember, we have your Git history. We can see who contributes to the project and who doesn’t. If a team member rarely commits to Git and only makes very small commits, we can see that they did not contribute their fair share.

All students should make their project contributions through their own GitHub account. Do not commit changes to the repository from another team member’s GitHub account. Your Git history should reflect your individual contributions to the project.

Deliverables

Proposal

Ideas

Your first task is to come up with a goal for your project. Some examples of previous student projects include:

  • A Shiny app to create generative art.
  • An R package that provides functions to improve the accessibility of {ggplot2} visualizations.
  • Physical 3D printed maps of opioid overdose rates in New York
  • A Shiny app to track Bigfoot sightings in the US
  • Interactive dashboard for tracking historic solar eclipses

There are also lots of technologies and tools you could use for your project, some of which are new and some of which we’ve only touched on in class:

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 should not be from TidyTuesday. Beyond that, it should be something truly of interest to your team, and a dataset that allows for a deep exploration.

Structure

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

Each team will produce an initial draft of their project for peer review.

Reviewer tasks

Critically reviewing others’ work is a crucial part of the scientific process, and INFO 3312/5312 is no exception. You will be assigned two teams to review. This feedback is intended to help you create a high quality final project, as well as give you experience reading and constructively critiquing the work of others.

The peer review assignments are as follows:

Your team name To review 1 To review 2
INFO-3312
Dank Corgi Dank Sloth (repo, site) Dank Seal (repo, site)
Dank Hedgehog Dank Corgi (repo, site) Dank Sloth (repo, site)
Dank Koala Dank Hedgehog (repo, site) Dank Corgi (repo, site)
Dank Leopard Dank Koala (repo, site) Dank Hedgehog (repo, site)
Dank Mink Dank Leopard (repo, site) Dank Koala (repo, site)
Dank Otter Dank Mink (repo, site) Dank Leopard (repo, site)
Dank Panda Dank Otter (repo, site) Dank Mink (repo, site)
Dank Seal Dank Panda (repo, site) Dank Otter (repo, site)
Dank Sloth Dank Seal (repo, site) Dank Panda (repo, site)
INFO-5312
Giving Hedgehog Giving Seal (repo, site) Giving Panda (repo, site)
Giving Leopard Giving Hedgehog (repo, site) Giving Seal (repo, site)
Giving Panda Giving Leopard (repo, site) Giving Hedgehog (repo, site)
Giving Seal Giving Panda (repo, site) Giving Leopard (repo, site)

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. 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 the final submission. You should be critical, but respectful in your review. Peer reviews will be evaluated on the quality of the feedback left for the other teams.

Reviewee tasks

Once you receive feedback from your peers, you should address them. You should do this by directly updating your project 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”.

Product

The format of the final product will vary depending on the type of project you choose to do. There is a general set of evaluation criteria that will be adapted for each type of project. Regardless of format, make sure to consider the following points:

  • What problem does this product solve?
  • Who is the intended audience?
  • How will it be used?
  • What is our new thing we are learning to use for this project?

No matter what your team creates, it needs to be reproducible and published publicly online.

Report

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 report 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 be a concise oral presentation that introduces the objectives and motivations for your project, articulates what you have created, and demonstrates the product in some form. This could be the results of traditional statistical analysis, something learned through interactive usage of your product, etc. 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.

Don’t spend the entire time demonstrating your product

This should be more than a product demo. If you build something like an interactive web app using Shiny, don’t plan on standing in front of the class for 5 minutes showing us how it works. That will be incredibly boring, and likely not a good use of your time. Instead, use the presentation to tell your design process - what problems does the product solve? How did you decide on the core functionalities or UI for the app? What are potential insights you could learn from the app?

Overall grading

Total 145 pts
Proposal 10 pts
Product 60 pts
Report 30 pts
Presentation 25 pts
    Instructor 20 pts
    Peers 5 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.
Organization Repository is unorganized. Does not contain required directories or files. Repository is organized according to the plan in the proposal. Required directories are created, files are located in appropriate locations, etc.
Teamwork One or more team members do not have commits in the repo. All team members contribute to the repo via commits.

Product

Category Less developed projects Typical projects More developed projects
Design + visualization The design/visualization are inappropriate for the data and/or audience. Charts are hard to read. Design is non-intuitive or hard to access. The design/visualizations are appropriate and easy to read. All expectations of typical projects + consistently adheres to best practices for high-quality, accessible data visualizations. Includes but not limited to deliberate choice of color palette, appropriate font size, intuitive labeling, etc.
Functionality Product(s) are incomplete or broken. Code generates numerous errors or warnings which cause usability problems. Product(s) do not provide value to the audience. Product(s) provide sufficient value to the intended audience. No errors or warnings present in final version. Product(s) are complete. All expectations of typical projects + product(s) are intricate and exceptionally designed. Showcases significant technical skills beyond those directly taught in the course.
Code Code is not efficient, hard to read, and/or lacks appropriate formatting or consistency. Clearly looks like multiple individuals wrote it instead of a single, cohesive approach. Code is efficient, easy to read, and properly formatted. All expectations of typical projects + code is thoroughly documented with comments. Adheres to consistent style guide. Clearly reusable and/or extensible for outside developers.
Impact Broader impact is unclear or lacking. Product(s) lack a discernible usefulness. Broader impact and usefulness of the deliverable(s) is clear. All expectations of typical projects + product(s) deliver clear benefits to target audience. Has clear applications beyond the scope of this course.

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.
Supporting materials

Slides (or other presentation medium) contain excessive text and/or content.

Team relies too heavily on slides (or other presentation medium) for their presentation.

Slides (or other presentation medium) are well-organized.

Slides (or other presentation medium) 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 (or other presentation medium) 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

Objective(s) are unclear.

Product is incomplete, non-functional, or designed poorly.

Objective(s) is clearly articulated.

Product is well-designed and meets the objective(s).

Team used appropriate methods.

All elements of typical projects + product is of exceptional quality.

Audience understands the design process and challenges overcome by the team.

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?

  • Supporting materials: Are the slides (or other presentation medium) 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?

Report

Category Less developed projects Typical projects More developed projects
Introduction

Less focused and organized. They may jump to technical details without explaining why the products are important.

Research questions or project objectives are not clearly stated.

Provides background information and context.

Introduces key terms and data sources.

Outlines research question(s) or project objectives.

 All expectations of typical projects + clearly describes why the setting is important and what is at stake. Even if the reader doesn’t know much about the subject, they know why they care about your results and products.
Justification of approach Simple description of some aspects of the dataset, little consideration for sources. Design process is not clearly summarized. Hard to understand what design choices were made during the project. Defines the deliverable(s) constructed for the project. The chosen approach is clearly explained and justified. When used, data is described in sufficient detail. Design process summarizes the final product. All expectations of typical projects + description of the design process includes not just the final product, but also addresses decision points and alternative paths not taken.
Limitations The limitations are not explained in depth. There is no mention of how these limitations may affect the meaning of results or the quality of the product. Identifies reasonable limitations to the scope of the work. Addresses potential biases in the data or model assumptions. Proposes potential remedies in future iterations of the project. All expectations of typical projects + design process clearly shows how the team considered potential limitations and worked to minimize their impact in the final product.

Reproducibility, style, and organization

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

Footnotes

  1. Upon request I will publish your team’s repository to a website using GitHub Pages. Any content published to the docs/ folder will automatically be published as the project website↩︎