v2

[timwis]

A few issues have lead me to think about a second version of the community health explorer:

1. Editing the CSV on prose.io is not as easy and common as we expected. For one thing, each year they start with a new file, rather than just editing the existing file. Typically by copying it to a new file and renaming it, but prose.io does not make this easy, so they use excel and send us the file.
2. It's very difficult to preview "next year's data" with the current architecture. We've had to manually deploy branches to surge.sh each time the department makes a change.
3. Every year that data gets added, we have to add 1-to-3 columns to each of the data files, for the new year's values. Ideally this would be a one-to-many relationship between indicators and years/values.

For a new version, I'd imagine two pieces of the application: (1) the admin interface, which makes it easy for department staff to add/edit new values roughly once per year, and (2) the public-facing application.

For the public-facing application, I think it's pretty straightforward: a Vue.js app with the same charting library (Chartist) and we can pull in the City's basemap via esri-leaflet while we're at it. The application would need to pull from some public-facing API to fetch the data.

For the admin interface, I'm not entirely sure. We've considered fieldbook, but it looks like they've eliminated their free tier and I don't know where they'll be a year from now. Flask-admin may be sufficient, though then we'd have to run a server/database to serve this application (unless we sync it to Carto).

The database schema could probably be as simple as:

indicators

• id
• name
• dimension (citywide_over_time, etc.)
• category
• chart_type
• description
• chart_comment

values

• id
• indicator_id
• year
• label
• value
• source
• comment

[awm33]

Simpler the better for me. Fieldbook may still be useful of they can share a user or something cheap. We basically want whatever the enter it into to have some validation and enforce the structure. Maybe flask-admin if Fieldbook or Airtable isn't an option.

A question that comes to mind, do they actually compose this in Excel or another program? If they compose it in a stat environment like R or SAS, maybe we can read the dataset package.

For the UI, getting a data visualization expert to design a better visualization would be cool. If we're just going to recreate the UI in Vuejs, that may not be worth the time.