Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UA: Adding FunnelChartNext #1733

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft

UA: Adding FunnelChartNext #1733

wants to merge 8 commits into from

Conversation

envex
Copy link
Collaborator

@envex envex commented Oct 4, 2024

What does this implement/fix?

Adding FunnelChartNext and SparkFunnelChart.

Eventually FunnelChartNext will replace the current FunnelChart, but for the sake of speed, we're going to support 2 versions.

Figma
Doc

Does this close any currently open issues?

Partially resolves https://github.com/Shopify/core-issues/issues/78198

What do the changes look like?

image

Also adds a SparkFunnelChart for smaller card sizes

image

Storybook link

https://6062ad4a2d14cd0021539c1b-lugmjeekld.chromatic.com/?path=/story/polaris-viz-charts-funnelchartnext--default

Before merging

  • Check your changes on a variety of browsers and devices.

  • Update the Changelog's Unreleased section with your changes.

  • Update relevant documentation, tests, and Storybook.

  • Make sure you're exporting any new shared Components, Types and Utilities from the top level index file of the package

@envex envex force-pushed the envex/funnel-chart-next branch 2 times, most recently from 8316d3e to 2dc5f46 Compare October 4, 2024 19:49
Copy link

github-actions bot commented Oct 4, 2024

size-limit report 📦

Path Size Loading time (3g) Running time (snapdragon) Total time
polaris-viz-core-cjs 61.42 KB (+0.03% 🔺) 1.3 s (+0.03% 🔺) 1.3 s (+45.18% 🔺) 2.5 s
polaris-viz-cjs 219.01 KB (+1.5% 🔺) 4.4 s (+1.5% 🔺) 2.2 s (+2.02% 🔺) 6.5 s
polaris-viz-esm 179.08 KB (+1.41% 🔺) 3.6 s (+1.41% 🔺) 1.4 s (-5.94% 🔽) 4.9 s
polaris-viz-css 4.87 KB (+3.11% 🔺) 98 ms (+3.11% 🔺) 252 ms (+5.41% 🔺) 349 ms
polaris-viz-esnext 184.92 KB (+1.46% 🔺) 3.7 s (+1.46% 🔺) 1.3 s (-15.78% 🔽) 5 s

@envex envex force-pushed the envex/funnel-chart-next branch 3 times, most recently from c72c654 to 7af7534 Compare October 9, 2024 20:11
@midokab
Copy link

midokab commented Oct 9, 2024

Looks good to me. A few things:

  • how do we specify what the summary % is? is it just the bottom of the funnel?
  • are all the rates calculated in the front end? This is informational because we need to be able to have an open and closed funnel with different session counts that calculate different rates (without needing to introduce different metrics) cc @williecostello
  • how would the comparisons look?
  • we should consider renaming the "reached this step" - is that clear enough that its directly related to the last step? @MeredithCastile
  • not important: but in the example, it looks like the reached next step and dropped off are flipped

@envex
Copy link
Collaborator Author

envex commented Oct 10, 2024

@midokab

how do we specify what the summary % is? is it just the bottom of the funnel?

  • The main summary is (lastValue / firstValue) * 100.

are all the rates calculated in the front end? This is informational because we need to be able to have an open and closed funnel with different session counts that calculate different rates (without needing to introduce different metrics)

Yes, those are calculated on the front-end, but if the API will give us those values, we can just accept strings/numbers.

how would the comparisons look?

No clue. Any thoughts @pabmtl

not important: but in the example, it looks like the reached next step and dropped off are flipped

Can you post a screenshot of what's flipped?

@williecostello
Copy link

Are all the rates calculated in the front end? This is informational because we need to be able to have an open and closed funnel with different session counts that calculate different rates (without needing to introduce different metrics)

Yes, those are calculated on the front-end, but if the API will give us those values, we can just accept strings/numbers.

This sounds good to me. Just to clarify: For a visualization like this, the API should only need to provide the count values (i.e., Sessions, Sessions with cart additions, Sessions that reached checkout, Sessions that completed checkout). Currently the plan is to have two sets of these metrics available in the API, one for the open funnel and one for the closed funnel. The API will also include separate metrics for (at least some of) the rates displayed in this viz (e.g., Conversion rate (open funnel), Conversion rate (closed funnel), Added to cart rate (closed funnel), etc.). But the API shouldn't need to pass through any of these rate metrics in order to generate this viz. They should just be consistent with the rates displayed in this viz (which, given everything I've seen about this, they should be).

@pabmtl
Copy link

pabmtl commented Oct 10, 2024

The steps label have been updated

Figma

Tooltips are slightly off

updated tooltip

The hover interaction for the main columns should only happen on the bar and not the entire section

@envex
Copy link
Collaborator Author

envex commented Oct 10, 2024

@pabmtl I'm not seeing updated steps.

Also, the hover interaction being in the entire section is how the tooltips work on all the other charts, so I don't think we want to deviate from that.

@pabmtl
Copy link

pabmtl commented Oct 10, 2024

@envex here's a screenshot

Funnel

@envex
Copy link
Collaborator Author

envex commented Oct 10, 2024

Ahh, the labels and everything we set via web, so if they're wrong in storybook that's fine, we can change them when we implement in web.

Copy link
Contributor

@carysmills carysmills left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will go through the code soon, but from 🎩

  • it feels a bit weird when both these tooltips show up, or at least when they overlap
Screenshot 2024-10-16 at 11 32 19 AM
  • Is it intentional there's no tooltip on the first 100% bar?
  • Sparkchart isn't showing up for me with just today's data
  • Can we check accessibility handling? Right now tabbing through the main chart just goes to the connectors. I don't see an aria-label on the spark one
  • The text gets a bit squishy at small widths and will be worse in some other languages/with other values. Any thoughts?
Screenshot 2024-10-16 at 11 42 59 AM

@envex
Copy link
Collaborator Author

envex commented Oct 16, 2024

it feels a bit weird when both these tooltips show up, or at least when they overlap

Going to look into this. I'm thinking we shouldn't try and use the same Tooltip logic as the other charts and just share the UI.

Is it intentional there's no tooltip on the first 100% bar?

Yes

Sparkchart isn't showing up for me with just today's data
Can we check accessibility handling? Right now tabbing through the main chart just goes to the connectors. I don't see an aria-label on the spark one

I'll dig in

The text gets a bit squishy at small widths and will be worse in some other languages/with other values. Any thoughts?

According to the Figma it should truncate, but we can run it by UX

@pabmtl
Copy link

pabmtl commented Oct 16, 2024

The text gets a bit squishy at small widths and will be worse in some other languages/with other values. Any thoughts?

According to the Figma it should truncate, but we can run it by UX

I think updating to the new labels will help with this.

@pabmtl
Copy link

pabmtl commented Oct 16, 2024

Those secondary hovers on the transition portion can also be removed, we should keep them as part of the code as a prop if marketing needs to use them and have them show by default with no interactions

@envex
Copy link
Collaborator Author

envex commented Oct 16, 2024

The text gets a bit squishy at small widths and will be worse in some other languages/with other values. Any thoughts?

According to the Figma it should truncate, but we can run it by UX

I think updating to the new labels will help with this.

Those labels will come from the API, we don't do any conversion, so if the labels in the API aren't changing we won't get any new benefit.

@pabmtl
Copy link

pabmtl commented Oct 16, 2024 via email

@envex
Copy link
Collaborator Author

envex commented Oct 16, 2024

@pabmtl Awesome!

Copy link
Contributor

@carysmills carysmills left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some initial comments from a first pass, but will need to go over this again later, when you've responded to the first comments.

I didn't leave this comment everywhere, but let's move out the pixel values, colours and constants currently at the top of files into a constants file for this chart.

Related to our chat yesterday: what do you think about making a new directory for this chart (and possibly future others) that's called experimental or something, so we indicate to any other consumers of the repo that the chart and API are unstable? Could also indicate that in the changelog

Can we add any tests that would be helpful?

@@ -0,0 +1,3 @@
export function calculateDropOff(value: number, nextValue: number) {
return ((nextValue - value) / value) * 100;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should calculate this in the viz or if it should be passed in 🤔 I'm fine with keeping it as is for now, but maybe something to consider for a more refined version of the chart. I'm wondering if the dropoff might ever be calculated differently

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We talked about getting this from the API but Willie suggested we keep it on the front-end (for now at least).

rawValue: number,
yScale: ScaleLinear<number, number>,
) {
const rawHeight = Math.abs(yScale(rawValue) - yScale(0));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll never have a negative bar value, right? I think this might fall apart if we did

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'll "clamp" it to MIN_BAR_HEIGHT if it's negative.

I think in the future we may want to support negative, but for now 🤷

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we end up letting users use this for unexpected data, like the example we've seen, we'll need there to be proper handling for negatives.

}

export function SingleTextLine({
ariaHidden = false,
color,
dominantBaseline = 'hanging',
fontSize = FONT_SIZE,
fontWeight = 400,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're adding a font weight in the constants, so it feels weird that this is defaulting to a different weight

fontFamily={FONT_FAMILY}
y={y}
x={x}
>
{truncated}
</text>
<title>{text}</title>
{willTruncate && <title>{text}</title>}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we check our other uses of this to ensure the changes don't break any existing text?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this change it would always display the title so we default to true. There should be no change aside from my new case that I pass false to willTruncate

formatPositionForTooltip: (index: number) => TooltipPosition;
}

export function getTooltipPosition({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There have been some bugs lately with tooltip positions in notebooks and on the dashboard. Can we make sure we test this with the chart further down/to the left and right on the page?


function formatPositionForTooltip(index: number | null): TooltipPosition {
// Don't render the tooltip for the first bar
if ((index === 0 && xAxisOptions.hide === false) || index == null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to check xAxisOptions.hide === false? Can't we just check the index?

Comment on lines +8 to +11
const LINE_GAP = 5;
const LINE_PADDING = 10;
const GROUP_OFFSET = 10;
const LABEL_FONT_SIZE = 12;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could also move these to a constants file

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought about that but they're only used in this file so moving them felt a little off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants