Skip to content

Interactive Visualization Project

For the latter half of this course you will be focusing on building an interactive visualization project.

See 2024 Projects for examples.

The final deliverable will be a hosted webpage at a public URL that gives readers/viewers the opportunity to better understand the topic of your choice by allowing them to interact with the data in some meaningful way.

You will have a lot of flexibility in what you build, static visualizations shared in class and on Ed may provide some idea of the enormous range of visualization options available to you.

You may consider:

I encourage you to be creative, and think about work that has captured your imagination.

If you are unsure if replicating something would be achievable in the allotted time, please reach out ASAP to discuss. Public Ed questions would be appreciated as they may help inspire others.

Final Deliverable Choices

All final projects must include:

  • A public, hosted website. Hosting options will be shared during the quarter.
  • One or more HTML pages containing interactive visualizations (see options below)
  • Standalone data files in CSV, JSON, or similar format.
  • Python or JavaScript code to produce the interactive, in one or more standalone JS files.
  • Python or JavaScript code used to clean/prepare your data.

Beyond these guidelines, the intent is to allow a great deal of flexibility/creativity.

In order to help answer the question of "is this interactive enough" consider the following options:

Option A: Large Interactive

An interactive focused on a single major visualization with significant interactivity.

This option should use D3.js or P5.js. D3 will be introduced in class. The visualization should be the centerpiece of your narrative, taking up the majority of the page with explanatory text and details in the periphery.

It may be helpful to have auxiliary visualizations to help support the narrative.

The interactivity must be non-trivial, beyond hover effects/tooltips or zooming/panning a chart. Examples might include:

  • A simulation written in JavaScript, allowing a user to visualize different outcomes based on different starting conditions/assumptions.
  • Exploration of a large data set by allowing users to drill down into specifics which will update the central visualization. This should extend beyond a single choice, allowing users to evaluate different scenarios or compare data from different regions/time spans. (It is also possible to approach something similar via Option B below.)

Option B: Dynamic Ensemble

Instead of a single centerpiece, you may focus on three or more distinct visualizations, allowing for more limited interactivity compared to Option A.

At least two of your visualizations must use features beyond tooltips/hover/etc. There should still be choices a user can make (drop-downs, sliders, etc.) to interact with your product.

This is the only option for which it is possible to avoid JavaScript. You may use Altair but it will require exporting to Vega/HTML and embedding those results in your HTML page alongside additional copy.

If you choose this path, your page must still have text, HTML, and CSS to provide a cohesive theme and narrative experience.

Option C: Geospatial Visualization

If your visualization is primarily geospatial, you may find that using a library like MapLibreGL is the best choice. While you should pick the right tool for the job, geospatial libraries often provide a lot of interactivity out of the box, so if you choose this option you are required to also have at least one JavaScript visualization written in D3, or with permission another JS library.

Your custom-written JavaScript visualization does not need significant interactivity of its own, presumably it is responding to actions that the user takes by clicking on your map.

Option D: Custom Option

If there are tools you would like to use, or you have something in mind that does not fit the above I will gladly entertain other options that exhibit a comparable level of interactivity.

We will need to discuss to come to an understanding of a minimum level of interactivity on par with the above options. If you are planning to go this route, I would recommend providing as much detail as possible in your proposal so we can start the discussion early.

Milestone 1: Proposal

For your proposal you will provide a Git repository (reused or new) containing milestones/interactive-proposal.md:

# {Your Name}

## Description

{what are you trying to accomplish?}

## Technical Plan re: Option A/B/C/D

{
which path are you planning on? why?
what libraries?
include 2 or more pieces that you plan to draw inspiration from
}

## Mockup

{
At least one image file with a mock-up of what you're considering.
If multiple images help make the intent clear, please include more.
This can be a quick pen & paper sketch of your current idea, or you can use Inkscape/any tool you wish.
A rough sense of what will be shown and how the user will interact with it should be clear from your illustration(s).
}

## Data Sources

{
include 1-3 data sources with the following,
you may re-use data sources from before or switch topics
}

### Data Source 1: {Name}

URL: {URL}

Size: {Number of Rows} rows, {Number of Columns} columns

{Short Description, including any exploration you've done already}

## Questions

{Numbered list of questions for course staff, if any.}

1.
2.
3.

When looking for inspiration, focus on the behavior and presentation, not the issue area.

Perhaps you want to simulate outcomes of environmental policy changes to show what would happen if some countries met their goals and others did not. You might cite https://www.270towin.com/2024-simulation/ as an example since allows users to run simulations on a map. It is fine that the topic area & map-based presentation are different, your focus is on the simulation idea itself.

When choosing data sources, take into consideration the same things you did for the static project, with a few changes:

  • If you are focused on 1-2 larger visualizations, you will not need as wide a variety of data. If you want to take a more dashboard/interactive chart approach you may still need a wide variety.
  • The kind of data you select will likely guide what libraries will work for you. Consider if you want to get d3 experience or work with maps. (Choropleths may still use D3, but maps requiring streets and geographic features will need a map library.)
  • If you want to stick to Python, you will be using Altair's interactive charts, it may be useful to look at Altair's interactive documentation and examples to think about what you can achieve.

Grading Specification

To earn an S on this assignment it must be complete. If any portion is missing (e.g. no sketch/mock-up) you will receive an N.

You are not being graded on having the "right" answers to any of these questions, this is to get you thinking about it early— and for us to get you feedback.

Milestone 2: Draft

You will again have about two weeks to create a draft/prototype.

At this point you should have the basic framework of your website created with interactivity in place. This will, as before, serve as the basis of critique, so you can explore the ideas you have and how they are resonating with your peers.

Specifications

To receive an S you must:

  • Have a webpage (in a single HTML file) that can be opened in the browser to allow someone to interact with your data & experience your prototype. You must include:

    • A working prototype of your planned interactions. A user must be able to click/type/etc. and see the result of their interaction.
    • Be using data (real or mocked) loaded from CSV/JSON/API/etc.
    • A standalone CSS file with your custom styles. You may use a pre-built theme/etc. but you should be providing some customization at this point.

  • Answer the following questions in milestones/interactive-draft.md:

# {Project Name}

{Your Name}

## Goal

{What is your current goal? Has it changed since the proposal?}

## Data Challenges

{Are there data challenges you are facing? Are you currently depending on mock data?}

## Walk Through

{Walk us through an interaction, either in words and pictures or you can record a quick 2-3 minute video.}

## Questions

{Numbered list of questions for course staff, if any.}

1. 
2. 
3.

Non-Factors

A few things that you will not be graded on at this point:

  • Quality of design choices, beyond fulfillment of requirements stated above. (You must have some custom CSS in place, but we won't penalize based on color/font/etc.)
  • Cohesiveness, which is only a factor in the final submission.
  • Bugs, use of mock data.
  • Code quality, comments.

Milestone 3: Critique

You will again meet with and provide feedback among a group of peers, and fill out a form documenting your participation.

As before, good-faith participation in this process will earn you an S.

Milestone 4: Final Submission

Your final submission will be:

  • a URL to a hosted web page (hosting instructions will be shared)
  • a repository of your work with data cleaning/preparation code cleanly separated from the final deliverable

Grading Specification: Design

The design of your final webpage will be taken into account. An S would have:

  • Well-reasoned choices on the visualization itself, based on criteria discussed throughout the quarter. (Use of chart types, visual encodings, color, etc.)
  • No significant presentation errors such as misleading axes or improper encodings.
  • Demonstration of critique feedback incorporated into final product.

Grading Specification: Interactivity

The focus here will be on the manner in which your interactive is implemented and enhances your narrative. An S requires:

  • Minimum interactive criteria met (See options A-C above.)
  • Writing and visuals are clear and relevant to stated goal.
  • Visualization enhances understanding of/engagement with chosen topic. In other words, it isn't just visual noise/flashy, but utilizes what we've discussed about interactivity to go beyond what would have been possible with pure static visualization.
  • Cohesive visual design between graphic and rest of page.
  • Including data citations via working links on the HTML page is mandatory.

Grading Specification: Code Quality / Documentation

Finally, for your code quality and documentation. An S requires:

  • Your repository should make use of at directories to keep it manageable, as was the case with the first project.
  • A README.md file that contains:
# {project name}

{your name}

## Description

{a short description of your project and its goals}

{REQUIRED: an embedded screenshot of your final project}

## Data Sources

{ citations for your data }

Reminder: Your final PDF/HTML also **must** contain citations for your data.