The purpose of this project is to show how some visualizations are "good" or "bad" for a given question or task involving the data, as modeled by some transform on the data or its representation, within the conceptual framework of Algebraic Vis Design described in [Kindlmann-AlgebraicVis-2014]. The (slightly experimental) premise of this project is that we don't need "expert" advice on making "good" visualizations, provided that we know enough about our data and its representation to design and implement these kinds of transforms.
When viewing index.html through a webserver, your page should show at least three demonstrations, each of which fill up the page width to show two visualizations side by side; we'll call them VisLeft and VisRight for each of demo. VisLeft and VisRight get the same inputs, but show them differently. Above each demo should be a title and a little bit of text explaining what is being shown, and a button for interactively applying/unapplying the change. Your demonstrations should include at least one of each of the following:
- A hallucinator (violating Representation Invariance): Something arbitrary about the storage/representation of the data is so visible that it risks changing our judgments of the data based on the visualization. VisLeft is susceptible to the hallucinator, VisRight is not. The change should be in the representation of the data (i.e. the ordering of data array elements), not to the underlying data set itself.
- A confuser (violating Unambiguity): An interesting possible change in the data is either invisible or hard to notice. VisLeft has the confuser, VisRight removes the confuser (so that the data change is clearly visible). The change should be in the data set itself.
- A jumbler or a misleader (violating Visual-Data Correspondence): A jumbler is a meaningful change in the data that the vis shows in some way that defies clear interpretation (i.e. we can't clearly "read" the change in the data from the change in the vis). A misleader is a change in the visual structure of the vis that seems very natural given its appearance, but which corresponds to some uninteresting, implausible, or impossible change in the data. VisLeft shows the Correspondence failure, VisRight does not (i.e., an important data change is legibly as such in the vis).
For each demonstration, you create the visualizations, but you also have to engineer the change. A button above the visualizations (but after the title and text) should toggle whether the change is applied to the inputs to both VisLeft and VisRight: D3 must recompute the visualization for both VisLeft and VisRight, even if (in the case of the confuser for VisLeft, or a hallucinator for VisRight) the change is invisible or negligible. It should be possible to repeatedly press the button, to repeatedly see the same change (no non-seedable randomness), but without creating an ever-increasing number of sub-elements in any SVGs, and without changing the layout of the rest of the page.
For each demonstration, your page should identify what kind of AVD change is being demonstrated (hallucinator, confuser, jumbler, or misleader), and in about 60 words or less, concisely describe what the change actually is, and why VisRight is better then VisLeft with respect to that change. Use this text to connect back to things we've learned in the class (about "resources", about the human visual system, about expressiveness and effectiveness, about AVD, etc).
You could get full credit by demonstrating one hallucinator, one confuser, and one jumbler. It may be that all of these can be done well with one type of visualization (such as three different kinds of scatterplots), but different vis types for different demos is encouraged.
Additional interactive elements (such as "tooltip"-style annotations) are welcome but not necessary. Definitely do these if you couldn't get them to work in p3. It is expected that we'll scroll through the page to see all three demos. The aspect ratio of each of VisLeft/VisRight can be as tall as 1:1 if you want, but probably not taller. Just how bad VisLeft is, is basically up to you, but try to create a visualization that someone might earnestly (even if misguidedly) make, rather than something comically bad. If you feel inspired, make more than three demonstrations.
There are no checksum checks for this project, but:
- There are still student-code blocks as a hint for where you work could go, and to delineate where GLK's code is (in any demos he shows).
- You must use ES6 modules to organize and combine your code (as has been used in all previous coding assignments).
- You must not import any modules from the internet except d3, as in the given code (re-implement anything else you need).
The provided glkrnd.js provides a seed-able random number generator (first seen in lab7), which my be useful. Feel free to copy any other functionality from previous assignments (either given code or your code). Acknowledge external sources in the place indicated at the top of p4.js. Whether you put all your code in p4.js versus other files is up to you, but make sure that your project works from a fresh checkout of its directory (i.e. you don't depend on files that haven't been svn added and committed).
Unlike in other projects, the "data" directory you start with is not full of data, since which datasets you use is up to you, but some possible starting datasets are in the whole-class read-only "datavis22" repo, in its new "data" subdirectory:
- m100m.csv: The progression of men's 100 meter dash world records, based on https://en.wikipedia.org/wiki/Men%27s_100_metres_world_record_progression. This could be shown with a line plot.
- infmort.csv: Per-state infant mortality rates (infant deaths per 1000 live births). For the 50 states I averaged data from https://www.cdc.gov/nchs/pressroom/sosmap/infant_mortality_rates/infant_mortality.htm over years 2020, 2019, 2018, 2017 (except for Vermont where there are only 3 years of data), and for DC I copied the 2020 rate from https://www.cdc.gov/nchs/pressroom/states/dc/DC1.htm. This could be shown with a colormap on the same hexmap as used in p3 (you do have data/hexRC.csv and hexmap.js from p3).
- diamonds.csv: Copied from https://www.kaggle.com/datasets/shivam2503/diamonds , and the likely data source behind Figure 7.3 of [Munzner-VAD7-2014]. If you use this, please find some smaller subset of the data that suffices for your demo (since this .csv file has about 54000 lines), using whatever tool you like for pre-processing .csv files, and save this to a new smaller .csv file in your p4/data. This data could be shown with a scatterplot.
You can also use any data from p2 or p3, or anything you compute from it and save in a .csv file, or you can go out and find a completely different dataset to visualize (describe it in the text above the demo). In any case, whatever data you use should be copied into your own p4/data directory, and svn add'ed and svn commit'ed there, so that everything is in place for viewing your work upon doing a new svn checkout.