Project 03

Project

Modified

November 11, 2026

Important dates

Project drafts for peer review: due December 2nd at 11:59pm
Final product and report: due December 14th at 2pm
Oral interview: December 14-16

Learning objectives

By the end of this project, you will:

Design and implement a data visualization project from start to finish.
Create effective and engaging data visualizations using R.
Learn and apply new tools or techniques related to data visualization.

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:

A reproducible product in a format based upon the type of project you propose.
A final report that explains the process and results.
An oral interview with the instructional staff

Project 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
An interactive dashboard for tracking historic solar eclipses
A multipage Quarto website that teaches readers about investing in cryptocurrencies versus traditional assets.

You might want to:

Create an R package that provides functionality for a set of {ggplot2} themes and/or color palettes.¹
Build a lesson plan for creating accessible visualizations with {ggplot2}, Quarto, and generally within the R ecosystem.
Create an interactive and/or animated spatio-temporal visualization on a topic of interest to you, e.g., redistricting, vaccination, voter suppression, etc.
Build a dashboard with Quarto and R/Shiny.
Write a data-driven blog post incorporating substantial data visualizations on a topic of interest to you.
Create a package that makes it easy to create data visualizations in a particular style.
Build a website that teaches a data visualization topic of your choice, along with code examples and assessment items.

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:

Shiny
Leaflet
{mapboxapi}
{ggiraph}
{gganimate}
Quarto
Closeread for scrollytelling data stories

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

Deliverables

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 your new thing you are learning to use for this project?

No matter what you create, it needs to be reproducible and published publicly online.

Shiny app? Publish it using Posit Connect Cloud
Quarto website? Publish it using Posit Connect Cloud or GitHub Pages ²
A package? Make sure it’s installable using remotes::install_github() and generate a documentation website using {pkgdown}

Report

Your have a lot of freedom in how you structure your write-up for this project. 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 students 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” you create. Rubric elements will be interpreted by the instructional staff in light of whatever approach you take for the final product.

Oral interview

Each student will participate in a 15 minute oral interview. The first five minutes will 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.

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 spending 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?

The rest of the interview will be a discussion with a member of the instructional staff about your project. You should be prepared to discuss:

Your data exploration and insights
The rationale behind your chosen product
Specific design choices and their intended effects
Reflections on the effectiveness of your product
Implementation details and your code

Wrap up

Submission

Final product

Publish your product online. In the Canvas assignment, submit the URL to your product.

Report

Go to http://www.gradescope.com and click Log in in the top right corner.
Click School Credentials \(\rightarrow\) Cornell University NetID and log in using your NetID credentials.
Click on your INFO 3312 course.
Click on the assignment, and you’ll be prompted to submit it.
Mark all the pages for the assignment as Report and click Submit.

Oral interview

Grading and evaluation criteria

Total	120 pts
Product	60 pts
Report	30 pts
Oral interview	30 pts

Product

Category	Less developed projects	Typical projects	More developed projects
Problem framing + audience fit	Product purpose is unclear, audience is vague, or features do not match the stated need.	Product purpose and audience are clear; core features align with intended use.	All expectations of typical projects + design decisions are explicitly user-centered and tightly aligned to audience needs.
Approach appropriateness (data/methods)	Data/method choices are weakly justified, misaligned with goals, or contain major gaps.	Data/method choices are appropriate, justified, and support project goals.	All expectations of typical projects + choices are especially thoughtful, limitations are actively managed, and the approach shows strong technical depth.
Design + communication + accessibility	Visuals/UI are hard to interpret, inconsistent, cluttered, or inaccessible.	Visuals/UI are readable, organized, and generally follow good communication/accessibility practice.	All expectations of typical projects + communication is polished and accessible (e.g., clear labels, effective hierarchy, appropriate color/contrast, intuitive interaction).
Functionality + technical quality	Product is incomplete, unstable, or has errors/warnings that hinder use.	Product is complete for scope, runs reliably, and key features work as intended.	All expectations of typical projects + implementation is robust and maintainable (clear structure, modular code, thoughtful engineering choices).
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.

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.

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.

Oral interview

Note

The rubric for the oral interview will be posted prior to the interview period.

Late work policy

There is no late work accepted on this project. Your report must be submitted by the deadline.

Students are expected to attend their scheduled interview time slot. If you miss your interview without advance notice or sufficient rationale, you will earn a 20% deduction on your oral interview score. If you know in advance that you will miss your scheduled interview, please contact the instructor as soon as possible to discuss accommodations.

Footnotes

Never built an R package before? See https://r-pkgs.org/whole-game for a great introduction.↩︎
Upon request I will publish your repository to a website using GitHub Pages. Any content published to the docs/ folder will automatically be published as the project website↩︎