Added Party Characteristics Tab and Visualizations to Dashboard

[davidye007]

Implemented both API endpoints and UI for the Party Characteristics Tab:

1. Number of Responses (Table)
2. Yearly Average Response (Timeseries)
3. Distribution of Responses (Side-by-side Bar Chart)

Note: As of now, the Party Characteristics tab will show up for all available projects (assuming user has logged in and access to the Visitor Characteristics tab). In other words, any project that includes sites with chatbot data will have party characteristic visualizations available.

Currently, there isn't a way to toggle which projects have access to which tabs (e.g. Party Characteristics, Home Locations, Demographics). Though this could be a useful functionality for us to add.

Fixes #249
Fixes OutdoorRD/west-cascades#159

[EmiliaH]

Thanks @davidye007! Cool to see the PR for this! @jblehr, curious to know if you have any ideas on a simple way to allow us to specify which projects display this data? As David mentioned currently any site with chatbot data will show these data visualizations.

[EmiliaH]

Also adding here that we talked about a couple additional improvements that we're leaving on the table for now. Specifically highlighting this one:

Convert number of responses table into a bar chart with x-axis as years, y-axis as counts, and categories as the total number of conversations, as well as each of the 4 party characteristics. This may also eliminate the need of the count display mode in showing distribution of responses.

From this comment on west-cascades/issue159

[jblehr]

Nice work @davidye007! One request before I get started on this: Can you please open (and link) the corresponding PR in trails-viz-data with the data I should use to test the new functionality?

That way, I can run this in dev mode on my computer to test it out. Or, is there a newer/better way for me to do test/review this?

Edit: Also, other than @EmiliaH's request above, is there anything specific you'd like me to look at within this PR?

[davidye007]

@jblehr the chatbot data in trails-viz-data is already on the master branch found here. I believe running git pull inside the trails-viz-data repo will be the quickest way to get the data locally and test on your computer.

I locally tested the Party Characteristics tab a bit with clicking around on different sites as well as projects. I think the main thing would be for you to check if the tab and visualizations run smoothly on your computer as well (e.g. maybe click on a few different sites/projects).

[davidye007]

Updates made to projects_and_sites.py and home_locations.py closes #259

[davidye007]

Hey @jblehr, I just finished linting the code and the PR successfully passed the CI/CD checkpoints. Could you please check if the dashboard runs locally on your computer?

To generate the chatbot data used by the dashboard, you can either:

1. Generate the data using the chatbot data prep make target. The steps are outlined here.
2. Pull the data directly from trails-viz-data PR #74. This is the data generated from 1. and will be merged into main (deployed on the droplet) simultaneously with this PR.

Please let me know if you have any questions or concerns, thanks!

[davidye007]

Documenting issues this PR covers.

trails-viz: Fixes #263, #262, #260, #251, #249.

west-cascades: Fixes #159, #158

[jblehr]

Hey @davidye007, I'm confirming two things: I can run the dashboard locally on my computer (at least with firefox - I still run into CORS issues with chrome), and that it looks awesome! You've built a ton of stuff on here and it's especially cool to see the new data that shows which sites are receiving chatbot data.

I just had one main comment/question on the chatbot home locations process:

It seems like the chatbot home locations map and tree map functionality is identical to our generic "home locations" map and tree map functionality. And, my quick look at the code in several files shows significant duplication:

• trails-viz-app/src/components/HomeLocations.vue and trails-viz-app/src/components/ChatbotHomeLocations.vue
• trails-viz-app/src/components/HomeLocationsMap.vue and trails-viz-app/src/components/ChatbotHomeLocationsMap.vue

Further, within trails-viz-api/trailsvizapi/repository/home_locations.py, it also seems like there's a lot of similar code to process the chatbot home locations as the more general home locations workflow.

My main thought is: why can't we just use (more of) our existing home locations workflow and code to produce the home locations tree map and states/counties map? For example, for the WestCascades project, we have a projects/WestCascades/homes_by_site_census.csv file that is read in and displayed. The parallel here might be that https://github.com/OutdoorRD/vic-flaskbot/pull/241 (or a different script elsewhere) could just create a trails-viz-data/chatbot/homes_by_site_census.csv, then the rest of this workflow could largely use the existing code.

I don't think this should hold up merging in this branch, but I'm curious to hear your thoughts and we can decide if it's worth creating an issue for this, etc.

[davidye007]

@jblehr Thank you for testing out the dashboard and for your brilliant suggestions!

I really like your idea of merging the frontend components into a general HomeLocations.vue or HomeLocationsMap.vue, which accepts a parameter like data_source='chatbot' or data_source='reveal' to call the appropriate endpoint.

I also like your idea of using the existing home locations workflow for the API, and switching between the chatbot data and reveal data based on the parameter passed in.

I think implementing the approaches you suggested will significantly reduce code duplication, as well as make it easier to add new data sources in the future.

I'll create an issue for this!