geodacenter / covid-atlas Goto Github PK

In the alpha app, the data panel shows national data until you click on a state/county. @ariisrael and I discussed that currently it may not be clear to the user that the graphs have been updated to reflect a different geography.

A few thoughts on how to handle this going forward:

• The data panel could always be visible and show national data to start. When you click on a state/county, there would need to be a way to return to national data (back button on data panel?)
• The national data could be be side-by-side with the county-/state-level data, in its own section?

The current Atlas uses GeoDa wrapped as a WebAssembly module for a few spatial analysis tasks:

• Hotspot/cluster analysis (aka LISA)
• Cartograms
• Possibly others (wondering if @lixun910 might have more insights?)

This is a really interesting approach and has been fun to explore from an engineering standpoint—however, I did want to bring up a few discussion points as we start to migrate these features into the refactored app.

• Browser support: WebAssembly has wide support on modern browsers, but is not implemented on legacy browsers such as Internet Explorer. Based on our user analytics, about 2.2% of visits came from IE. That's a small number to be sure, but my concern is that some of these folks are key stakeholders at less-resourced institutions, or are working under IT policies that bar them from installing their own browser (this is common at hospitals and gov't agencies). As we consider the overall accessibility of the site, we may want to keep these users in mind.
• Performance/scaling: My understanding was that there were some issues with the in-browser LISA analysis taking too long when the app started, which is why we've been caching the results as JSON files and checking them into the repo (if I got any of that wrong, please feel free to weigh in @lixun910). As our data grows over time and as we add new sources, this will likely become a larger issue.
• Packaging: the current WebAssembly module injects a variable called Module into the global JavaScript scope, which presents some challenges when integrating with a Node-based project such as the refactored app. I've started a repo that would turn the module into a Node package, but this may take more time than we've allocated for the refactor.

At the same time I think we can all recognize that GeoDa is driving some of the most important insights in the Atlas, so I wanted to make a few suggestions around how we could modify the stack to provide the best user experience possible without compromising on spatial analysis.

• Preprocessing: One option would be to preprocess the data with GeoDa so that the WebAssembly module isn't needed for things like viewing clusters; this would address both browser support and performance issues. As I mentioned above, we may already be doing this to some extent, so it would just be a matter of formalizing the caching process and possibly using pygeoda in place of the browser workflow. I think this would be the most straightforward approach and would be my recommendation.
• Server-side processing: Another option would be to deploy pygeoda as a lightweight backend service, such as an AWS Lambda function, that the browser app could call when it needs to run analysis. We could use something like this in the case of the cartogram, which I'm not sure could be pre-processed as easily.

I was wondering if the group had any additional thoughts or ideas re: Geoda on the front end. Once again, I think this is a fantastic feature of the app and looking forward to finding a long-term solution for supporting it in the Atlas 😄

/cc @jkoschinsky @Makosak @lixun910 @linqinyu

Because our Redux store is large and fairly normalized, we will most likely want to start using Reselect at some point to cache computed values.

More from the Redux docs:

https://redux.js.org/recipes/computing-derived-data

We need a new solution for the time slider that lets you see a cut of data from a particular date, reflected on the map and in the data panel.

The alpha app loads in a file called /data/counties_usfacts.geojson that seems to contain static data for counties, i.e. population and hospital beds. Need to do the same in the beta app.

Set up a pattern for loading data in from the existing (alpha) repo and normalizing it for use in the new app. This data should go into the Redux store.

We would like to have a nav bar at the top of the app (above map) for accessing secondary content (about, press, etc.)

This is mocked up for the control panel, but we would want one on the data panel as well. It just slides it off screen enough to reveal more of the map. Demo here:

https://5e978fbcbac2e30267c42105--covid-atlas-rbrtmrtn.netlify.app/

The first iteration of this looked like:

Since then we decided to use Bootstrap in favor of Semantic UI (see #2). As of now it's not being styled.

We should formalize what our style guidelines for the app and implement them for the beta release of the Atlas.

Ari (I can't tag you for some reason), you sold me on this—it looks like Semantic UI is not actively developed and Bootstrap has really nice React bindings, so it seems like that's the way to go. I'll try to work on swapping those components out today or tomorrow. Also, just to touch on what we had talked about last week, I'd prefer to use Bootstrap just for small components that would be tedious to write ourselves (like form elements) rather than broader layout and styling—just don't want this to get that "yet another Bootstrap app" look and feel. But let me know if you have any other thoughts, happy to discuss.

This is a task to recreate the existing map visualizations in the alpha app in this code base.

For managing global app state

Currently this is just the create-react-app boilerplate.

It might be good to decide on a code standard that covers JS and any other code we're writing in the React realm (JSX? CSS modules?) and set up automated linting on commit.

One ESLint plugin for React:
https://github.com/yannickcr/eslint-plugin-react

We should plan how routing should work vis-a-vis navigation, browser history, bookmarks, etc.