[Design Proposal] New Chart Creation flow

[dorq]

This is a proposal for multiple changes to the current chart creation flow. Please share any concerns or comments directly in this issue.

How to access the new chart flow

We recently added a universal “New” button to the Superset navigation bar:

This “New” button is available from every page in Superset. Users enter the flow proposed here by selecting the “New… Chart” option.

Users can also access this chart creation flow via all existing modes:

• From the SQL Lab Editor by clicking on the “Explore” button above the Results tab table
• From the datasource list by clicking on a datasource name
• Anytime they edit an existing chart

When a user selects the “New… Chart” option above, we propose this new chart creation experience...

New Chart Creation Flow (proposed)

First, the user must choose a datasource:

• Chart creation and configuration flow is a 3-step wizard that expands and collapses as an accordion.
• The wizard auto-advances when an item in step 1 or step 2 is clicked.
• We display “# Charts” that use this datasource to help guide users.
• The “Select datasource” banner includes an info icon that explains what a “datasource” is; copy TBD.
• We add Sort and Filter capabilities at the top of this list.
  • Sort options:
    • # charts that use it (DEFAULT)
    • Datasource name
    • Type (e.g., Presto)
    • Owner
  • The filter searches:
    • Datasource name
    • Type (e.g., Presto)
    • Owner
• The chart is automatically titled “- untitled” as a placeholder.
• Users can go back and forth between any of the 3 steps once the datasource has been selected.
• Chart area cues “Need datasource” until a datasource has been selected
• If a user lands here from the SQL Editor or the Datasource list, we pre-select the datasource for them like we do in the current interface. So they skip to step 2, with step 1 complete.

Then, the user selects a chart type. This employs the same thumbnail grid we currently show for changing vis type.

We’re suggesting here that “Line Chart” be the default selection, rather than a null selection. This should be behind a feature flag or a config for orgs to control.

Superset will automatically configure the chart to show some valid data by default; in this example it has selected the first time series value available in the datasource (COUNT(experiment) by experiment_start) and updates the title accordingly (if not already named).

If we default to any particular type (as suggested to use “Line Chart” above), this second step be skipped/”completed” by default and the user will jump to step 3.

Notes on previous steps: Now that datasource has been selected, the icons for viewing datasource configuration (eyeball icon - suggestion is to update this icon) and accessing the datasource in SQL Lab (beaker icon - keep existing icon) are viewable in the datasource selection banner:

The CTA in the datasource section is “Configure” rather than “Edit” because the datasource cannot currently be changed (We’re actively discussing bringing back this functionality, but it is not decided yet).

Step 3 is to configure the chart using all the options we currently have in the Superset sidebar:

The previous screens detail the flow for when a user creates a new chart. When users edit an existing chart, these same changes apply there as well, but the user is brought directly into step 3 of the proposed wizard since steps 1 and 2 are already complete.

If the current configuration is sufficient to produce a working chart (that is, one that actually renders a chart rather than an error), this is the “Success” state:

If, however, the state contains an error, we surface it to the accordion header like this:

How to move forward

Lyft is proposing these changes as a result of research and many iterations with multiple teams. Airbnb (cc @elibrumbaugh) will further iterate if needed, but at the time of this proposal, the general consensus is that this is an improvement on the current UX for chart creation, so we would like to enable development of this ASAP.

[michellethomas]

Hi, thanks for creating this design proposal. I recently worked on the datasource control, and have a few comments about that section of the designs. We recently brought back the ability to change datasources from the explore view (#6816), it's been an important feature for users and one we'd like to keep around. We also tried to move away from using icons to avoid having a number of icons when there are lot of actions (I don't have a super strong opinion about this but just thought I'd note it).

@xtinec also had a PR to bring back the + metadata button next to the datasource control (not sure if this is something they still need to keep #6911).

We also have some pretty long table names, so something short like def.fact_dags fits into the space between "Select datasource" and the icons, but many of our datasource names are longer and showing more of the table name is important. I can get more specific about this if it's helpful.

[dorq]

Hi @michellethomas Thanks for bringing up these issues. I did these designs assuming that we did not have the ability to change datasources from the explore view, because at the time it hadn't been merged. I agree that it's important and I understand why you want to keep it around.

What do you think about doing this instead of what's mocked up here?

• keep the datasource+dropdown visible when the "Select datasource" section is expanded
• keep the same dropdown options you implemented
• remove the icons from the section header that I proposed above; these actions are redundant with the dropdown options
• for long names, we allow them to wrap to a second line if needed (making the header for the section a bit taller in those cases)

[elibrumbaugh]

I could shed a tear for how long I've wanted to see a new button / creation flow.

• The space between sort by and search is a bit large. I suggest lengthening sort by a bit and then allowing search to fill in the rest of the gap. It would be great if it matched how we do this on the dashboard editor pane > charts section.
• The need datasource notice in the middle of the canvas could use a little more visual hierarchy. Right now it looks slightly like a disabled button. Maybe something happens when you click on it? Focuses the user on section 1.
• The hover state highlight will be a neutral color right? Right now it looks like a Lyft specific color?
• Can we get rid of the "-" before untitled? Maybe say Untitled to promote human readable titles.
• Love the thoughtful move to step 2 if coming from SQL Lab!
• Under select a chat type could we add sort by and search? Sort by popularity. You're kind of doing this already with the order roughly I think?
• In place of sort by add a dropdown for selecting the goal of the vis such as comparison and apply a different visual treatment to the types that aren't ideal for comparison. It wouldn't be too hard for us to all align on groupings of the visualizations.
• For eyeball and beaker icons. The icons in Superset today are pretty bad. I would learn on textual buttons in place of icons when/if possible.
• Between step 1 and 3 the styles look similar but appear to me as a little different. To reduce visual fragmentation can we leverage the existing styles as much as possible? Or plan on updating the step 3 styles to match?
• I wonder if the brand green color would work better for the 1, 2, 3 step headers? If we want to adopt the dark headers we should replace it throughout the UI. I'm a little worried the grey isn't as discoverable or communicative of current/active step.
• Re: "If, however, the state contains an error, we surface it to the accordion header like this" Why aren't we applying a disabled color to the section and throwing an error message in the notification banner?

This is awesome work Anita! Thank you so much for pushing this forward!

[williaster]

thanks @dorq for the designs!

@kristw and I just looked it over more thoroughly and our biggest comment is the top-level Data / Query split. we think this probably should be updated from bing a container for the 3 steps, and instead be pushed into the step 3 since it only affects the configuration of the chart. otherwise overall it looks good!

[dorq]

@williaster @kristw Apologies for the delay in responding to your last comment:

...our biggest comment is the top-level Data / Query split. we think this probably should be updated from bing a container for the 3 steps, and instead be pushed into the step 3 since it only affects the configuration of the chart. otherwise overall it looks good!

Can you clarify this a bit for me? I don't understand what you're suggesting here.

[williaster]

@dorq sure.

Basically it does not make sense for this set of tabs (Data<>Visual Properties) to exist outside of the 1/2/3 flow. It only makes sense in the context of step 3, and therefore we think it should not contain steps 1/2/3, and instead be moved inside step 3 where it's relevant. Make sense?