Make superset dashboard improvements for user testing

[bendnorman]

Before we do user testing we need to make a few improvements. We'll check in on this work after 5 hours.

High Priority

Preview Give feedback

1. Rework welcome dashboard (see comment below)
2. PIck 5 tables to create Table Dashboards for. Make sure PK and filter columns are on the far left side of the table. Pick a variety of table shapes and sources.
3. Add a description of the table and and explantion of how to download the data as a csv
4. Allocate minimum amount of Cloud Run resource to improve performance. What's our benchmark? What are we willing to pay?
5. Clean up permission to make sure new users dont see all our superset junk
6. Test permissions once we've made all these improvements
7. Restore PUDL logo to top-left

Bonus

Preview Give feedback

1. Is it possible to have a site tour pop up on superset? - Possibly by embedding it into a react app, but I don't think this is going to be trivial unless I'm missing something.
2. Can we save SQL Queries - Yes! Can we make them visible by default to new users? - Not obvious.
3. Get rid of the bar for numeric fields in table charts
4. Figure out how redirect or emphasize the welcome dashboard
5. Figure out if we can spruce up the auth0 text
6. Customize the home page - e.g., https://medium.com/towards-data-engineering/customize-apache-superset-home-page-to-fit-any-html-block-85f8d4b58419

[bendnorman]

For the welcome dashboard, we want to:

• generally have less text
• Have people look at data and interact with the data ASAP. Something like a quickstart guide
• Explain the three different methods for interaction with the data on superset: table dashboard, creating charts and SQL lab

The flow for welcome dashboard improvements:

• Have a couple of sentences about what PUDL and Superset are
• Link to one of the Table Dashboards. This dashboard will explain how to filter and download data
• Maybe a section that goes into more detail about the table dashboards
• Section about how to find the data you need in the data dictionary
• Section on how to create charts
• Section on how to use SQL Lab
• FAQ

We can divide these sections up by using tabs.

[bendnorman]

Ugh, some very frustrating findings while trying to iron out the permissions for user test. When you give a user permission to a datasource, it gives them read access to all the datasets, charts and dashboards that are derived from the datasource including ones made by other users :/ This poses some UX and privacy concerns for us. I wrote up a discussion in the superset repo about this issue.

UX: If users can see everything built off PUDL it will get difficult to navigate the UI. You can filter dashboards and charts by owner. We could tell users to filter for charts owned by themselves and an admin account that is responsible for creating all the default PUDL charts and dashboards. Superset does expose a way to restrict the owners that appear in the filter dropdowns however I don't think it actually restricts the dashboards and charts you see when the lists are unfiltered.

Privacy: all users' first and last names will be available to anyone who registers. Users won't be able to publish dashboards and keep them private.

Solutions?

• Just live with it? We could encourage people to filter for dashboards created by us and themselves but this isn't ideal from a UX perspective. Maybe people would be comfortable with their name being out there? Maybe having charts and dashboards public amongst registered users could actually serve as helpful examples and knowledge sharing? Also, the views that list dashboards, charts and datasets might not be the most intuitive method for navigating PUDL data. I think treating the PUDL Tables tab of the welcome dashboard feels more intuitive anyway.
• Another option is to not give users access to the PUDL database or any of the datasets but give them access to specific dashboards. This gives them read only access to the charts associated with the dashboards. Users won't be able to use SQL Lab or create charts. This would be a significantly stripped-down version of Superset where it's just the table dashboards for downloading data. I think we can easily hide elements of the UI associated with these extra features so it's clearer.
• Dig into the superset code and figure out how to hide other dashboards, charts and datasets via the UI or in the actual permissions system.
• It looks like superset is considering redesigning its permissions system to allow for more granular control but there isn't much movement on it.

[zaneselvans]

Hmm, this is unfortunate. How do larger organizations deal with this? Letting everybody see everything all the time seems like chaos?

Only providing access to dashboards seems like we'd be hiding a lot of functionality -- not the functionality we want the CSV folks to see maybe, but still a lot of power and flexibility I think we'd been hoping to expose for folks that want it. It would also mean that we'd only be able to roll out access piecemeal, as we build out appropriate dashboards that eventually come to cover all of PUDL.

My intuition is that it's probably best to make it clear that this is all publicly visible, and do our best to use the UI, tagging, or whatever other organizational tools are available to us to provide direction to the best resources.

Getting into the guts of the Superset code to make it do something we want that's different feels like a recipe for madness.

Separately, I've wondered whether we might be able to offer public access -- with everything you create being visible to everyone else -- as the free option, and then offer the ability to create private dashboards, saved queries, maybe access to other non-PUDL data? etc. as a paid option.

[zaneselvans]

Even more separately, I've also been wondering whether there's an extremely simple way that we could provide an in-browser interface that can be pointed at the URL of a Parquet file in S3, display its metadata, and provide a barebones GUI in the vein of Datasette for folks to build a SELECT stuff FROM url WHERE whatever and click a "Download CSV" button -- but have the work of translating the stream of Arrow data from the S3 Parquet file into that CSV be done on the client side, in the browser, so we don't actually have to run any service and can just use the free S3 bucket data.

As an added benefit... this would make every publicly visible Parquet file on the internet accessible to CSV users... which would also include all the datasets at Hugging Face, and a bunch of other stuff in the AWS Open Data Registry.

Some suggestions from the Hive Mind included:

• https://reflex.dev/docs/getting-started/introduction/
• https://perspective.finos.org/
• https://www.npmjs.com/package/@duckdb/duckdb-wasm

[jdangerx]

tl;dr: I think we can make our users live with this permissions thing; we can also try to build our own thing for "download a CSV" use case, and see if that's better than trying to hack it into Superset.

I think "just live with it" is probably OK... we can tell people not to publish things unless they want to have them be public.

Even more separately, I've also been wondering whether there's an extremely simple way that we could provide an in-browser interface that can be pointed at the URL of a Parquet file in S3, display its metadata, and provide a barebones GUI in the vein of Datasette for folks to build a SELECT stuff FROM url WHERE whatever and click a "Download CSV" button -- but have the work of translating the stream of Arrow data from the S3 Parquet file into that CSV be done on the client side, in the browser, so we don't actually have to run any service and can just use the free S3 bucket data.

I think that makes sense - it really seems like Superset isn't really designed for this important use case of "download the data so you can use it with Excel." I'm imagining some sort of frontend-only interface that lives alongside our data dictionary, which lets people preview/filter/download, or click on a link to make custom dashboards/visualizations in Superset.

This would let us stop fighting with Superset to get the "download data" use case, and just let it be what it was meant to be: a data viz and exploration tool.

We also wouldn't have to programmatically create dashboards for every table we want people to be able to filter, and so maybe people won't have as much of a reliance on Superset dashboards, making this permissions thing less of a problem.

[e-belfer]

Given that we're on the cusp of actually testing out this tool, I'd like to just ask our users how they feel about this and whether it's a dealbreaker for them when we do the tests, rather than assuming it will be. I don't think mocking up another option is a bad idea at all, but I would like to wait until we see how people respond to our current set-up.

[jdangerx]

Yeah, agree that we should do any additional frontend stuff after the first user calls!

[e-belfer]

I'm moving the remaining bonus items to #3908 and closing this. Everything absolutely crucial to address prior to user testing has been addressed.