After the redesign to add a header (which is awesome), I can't see the legend button:

I assume it's because of the header content wrapping unexpectedly.

Originally posted by @pcaisse in #6 (comment)

It would be good to have a sense of how much traffic the site is getting and from where it is being accessed.

Open and privacy-conscious analytics would be required. Plausible seems like a good choice: https://plausible.io/

Overview

Currently the app supports visualizing snapshots for one of several years. It would be very cool to show how speaker counts are changing over time per language via a heatmap.

This would require the user to be able to select a range of years and likely call for a different choropleth.

Problem Description

Earlier testers are indicating that it's not clear that they can zoom for more detail; they don't seem to be discovering that they can view PUMAs or to be aware of the switch between states and PUMAs. We need a way to convey that to the user somehow (make it more obvious/discoverable).

The problem is worse on mobile where you see less of the screen but still have to zoom in to the same extent to see PUMAs -- you get in a position where you can only see a few states but still no PUMAs. For example:

My initial thought was that the "zoom for more detail" was so ingrained that people would know to do it. However, with other slippy maps, you can zoom and get incrementally more detail. This is not the case with this app since you need to cross a certain threshold of zoom level to get finer/coarser granularity.

Possible Solutions

I like the idea of having a UI component that when clicked will zoom you to the other level (either PUMA or state). If this were a radio-button type component that would have the advantage of showing the two distinct possible states (eg. "[x] State [ ] PUMA") and thus make the user aware of them. However, the word "PUMA" will mean nothing to users and I'd rather not have to explain it because it still won't mean a whole lot even after explaining it. A "Zoom In/Out" toggle may be more appropriate, but that doesn't indicate a threshold.

In addition to making it clear that you can switch levels, I think this would be a nice feature to have since I sometimes find myself manually zooming to try to hit the threshold when using the app.

Very open to other ideas on this!

EDIT: A promising solution to this issue is to overlay PUMA outlines on top of states once you hit a certain zoom level.

It's not always clear to the user that you can click for more info or zoom to see smaller areas (PUMAs).

Perhaps some hover action or auto-zooming would be appropriate here.

• "No results" popover below the search input when the search doesn't match anything
• Consider highlighting the puma that the user is zoomed to to emphasize that the search has been completed
• Consider using " — " instead of "--" wherever relevant [NOTE: This is a value coming directly from the database. I could add a migration to change those values]
• Consider adding an "x" button in the input so that the user can easily clear their search [EDIT: I ended up clearing the search on click/focus. I don't think users will want to edit their search so much as make an entirely new one]
• Highlight matching text

Taken from: #10 (review)

The state geometries are represented on the map but we have no data for them (see https://languagemap.us/?languageCode=6930&year=2019&boundingBox=132.45263078348523%2C7.2127487231898755%2C166.52441692272453%2C25.381259928837807):

Assuming there's no PUMS data available for those geometries, they should be filtered out so as not to show up black on the map.

A laundry list of changes to be made before showing the app to a general audience:

• Fix flicker when mousing between PUMA outlines
• Make hamburger icon easier to tap on mobile
• Make sure icons in filters widget are nicely aligned in latest Chrome and Firefox
• Pull general app information out into a header (working on this in a branch)
• Put most popular languages in dropdown first (?)
• Fix bug where PUMA outlines aren't always removed correctly

• Is there no data for other United States territories, like Guam, Northern Mariana, USVI, or American Samoa available?
• I see data break down for Cantonese and Mandarin in the table but is there no data for other Chinese variants like Hakka or Szeyap and such? Is the parent category "Chinese" a sum of these data or?
• Is there no data for English? While I guess it will not have much meaning as I assume all states will have more than 10% people being able to speak English,I still think it would be nice if that's added to the site

Users have said that it's difficult to distinguish between the color buckets without looking closely.

They currently always show up on the map with zero counts, but they shouldn't show up at all.

language_map=# select statefp, name from states where statefp not in (select distinct(state_id) from people_summary);
 statefp |                     name
---------+----------------------------------------------
 66      | Guam
 69      | Commonwealth of the Northern Mariana Islands
 78      | United States Virgin Islands
 60      | American Samoa
 72      | Puerto Rico
(5 rows)

These rows are not needed and are being scanned needlessly.

language_map=# select count(*) from people_state_summary where language_id is null;
 count
-------
 20625
(1 row)

language_map=# select count(*) from people_summary where language_id is null;
 count
--------
 467406
(1 row)

Will require:

• new migration to create a new materialized view and drop the old ones
• wiring up of API to refer to new mat views

A couple of things we could do here:

• Use comma separation for thousands
• Consider making the percentage more prominent
• Consider making the state/puma name more prominent

Overview

Census data is collected every 10 years, whereas ACS data is collected every year. The PUMAs (geometries) change as per population data from the census so they are per decade but the PUMS data (speaker counts) is per year. That means that PUMS data for a given year has to be shown with the right PUMAs for that decade for the speaker counts to make sense vis-a-vis the population. (A further complication is that there is also 3 and 5 year PUMS data which is aggregated over those year spans; that data hasn't been used in this project to keep things simple.)

Currently the data processing code is such that there is a hard-coded assumption that the PUMA data is from the 2010's (see https://github.com/pcaisse/language-map-us/blob/main/data/scripts/build_geojson#L97). It would be nice to support data from the 2010's and the 2020's.

Notes

One important thing to note is that the way they asked about language spoken at home changed in 2016 (see https://www.census.gov/content/dam/Census/programs-surveys/acs/tech-doc/user-notes/2016_Language_User_Note.pdf) with very many more language options being added. This would mean that the language options would need to be change based on the year instead of being hardcoded as they are currently, breaking some assumptions that the frontend makes currently.

See also

PUMS datasets for all years: https://data.census.gov/mdat/#/

This path results in a 500:

http://localhost:4000/?boundingBox=-102.26,15.33,-63.92,32.58&language=1200&level=state&zoomLevel=6&age=0,97

PUMS data is available here: https://www2.census.gov/programs-surveys/acs/data/pums/2016/5-Year/csv_ppr.zip

PUMA is here: https://s3.us-east-2.amazonaws.com/language-map-us-public/cb_2016_72_puma10_500k.zip