Intuitive UX for bar value chart

[paolodamico]

We currently offer two different bar value displays. "Time" & "Value". These options are confusing. At best you have to think what each option is and which one is it that you're looking for. This is a barrier for a good experience. Some recent new designs (e.g. #4514) add considerations on how to display a graph of this type in a different way that is useful and not confusing, but in the meantime, we could simply turn this off. My hypothesis is that we're losing more value from introducing this friction that what we're gaining from having this extra functionality.

For context, the bar value graph represents 1% or less of all insights generated in a week.

Thoughts? @mariusandra @marcushyett-ph @corywatilo @kpthatsme @samwinslow

[timgl]

I use this option a ton. I think we should just rename that option to "breakdown by" as that's the only point where it's valuable

[marcushyett-ph]

This is one of the few features I've used so far - the functionality was helpful and reliable for what I was trying to, aggregation on a breakdown - to see how many people had installed certain plugins.

I feel the name "value" is a little confusing - as its more of an "aggregation by breakdown".

Is there a motivation for dropping it beyond user confusion?

[samwinslow]

If the use is typically breakdown of a whole, how about trying a 100% stacked bar chart like so. It could show discrete values in a legend/tooltip. Yes, this functionality overlaps with pie charts a bit, but there's evidence that it's easier to visually compare the area of rectangles vs. arc segments -- which is probably why some people use this chart for breakdowns.

[marcushyett-ph]

Sounds interesting - would be great to have an intuitive default for breakdown queries.

[kpthatsme]

I'm inclined to agree with Marcus and Tim. In general I think this kind of chart does unlock analysis that is valuable i.e. this breakdown of plan types.

Even though the usage is limited, I think for the people that need it – it's critical.

So my takeaway isn't that we should drop it (even temporarily) but we should instead think about the right way to communicate it in the UX and show it as an option (maybe as the smart default for breakdowns, as raised earlier).

Also, when we are ready to prioritize those improvements, might be worth thinking about this in terms of "property aggregation parity" instead of solely for the bar-values chart. There's a lot other applications can do with property aggregates (for example, creating a normalized distribution of a value) and I think us aiming to provide the same levels of analysis will help inform the specific charts we keep / add / remove.

[macobo]

+1 to what has been said before, I added it and have gotten a ton of mileage out of it. Agree though that my naming sense is not the best.

Suggestion: Rename the options "over time" and "breakdown"? Also perhaps worth disabling the option when there isn't multiple lines being shown (no breakdown or not a multigraph)

@samwinslow I would find that chart confusing. My intent using it has been to get top N for a breakdown and list/compare them against each other. Stacked sizes like that are hard to identify and measure against each other.

[paolodamico]

Thanks for chiming in everyone 🙌 , I'm surprised by the outcome, thought value was pretty low based on usage numbers. Changing the scope of this issue to figure out now the right UX for this.

Re @marcushyett-ph this could be interesting, #4330.

[marcushyett-ph]

@timgl and I did some quick analysis yesterday on how its used - turns out it's used by very few users - but the very few users who use it - use it a LOT.

So I guess it's potentially a really valuable feature just hard for people to discover.

@paolodamico +1 to #4330 - I think we can improve the experience a lot (for new and existing users) by giving user the best possible default option based on their query etc.

[clarkus]

I spent some time on visualizing breakdowns in the latest funnel designs today. This isn't done yet, but there are definitely limitations with this visualization. Depending on the palette used, we're very constrained in our ability to clearly label values.

Stacked sizes like that are hard to identify and measure against each other.

I agree with @macobo here. The more options in the breakdown, the less effective the visualization becomes. With the design below, a user would be dependent on the tooltip / legend, and the table to really understand the data. While this is specific to funnels, I think it's generally applicable to any visualization that uses area to communicate values.

I'm not sure what the solution is here other than setting an upper bound on the number of options shown in the visualization. We can expand our palette of colors as well, but at some point it won't scale. Perhaps we allow users to configure a limit to show in the visualization? Show the top [N] items, and roll the remaining items up into an aggregate.

Another option would be to follow the design at #4403 (comment) and break bars into distinct items. This would require more space, but it would be more effective at communicating values clearly. Thoughts?

See more details at #4535 (comment).

[paolodamico]

That is a great point. I do think that like funnels it'll make sense to limit the amount of values we can display, even if we find a good way to scale the amount of colors, visualizing that much information in such a small space might not be useful anyways. I think that by default we might want to select the first n (~15-20 probably) items, and then group the rest into other. As an improvement in a second stage we can provide a bit more granularity to allow users to decide for themselves.

[clarkus]

That is a great point. I do think that like funnels it'll make sense to limit the amount of values we can display, even if we find a good way to scale the amount of colors, visualizing that much information in such a small space might not be useful anyways. I think that by default we might want to select the first n (~15-20 probably) items, and then group the rest into other. As an improvement in a second stage we can provide a bit more granularity to allow users to decide for themselves.

That makes sense. So by default we will show the top 15–20 options, but we will only visualize 9 of those in detail with a 10th option that rolls up all other values.

[clarkus]

I have been spending a lot of time on visualizations that use bar charts. My learning so far is that the stacked bar chart should probably be reserved for visualizing related sets of data. A better initial view be grouped bars. The group would repeat for each point on the axis. The benefit here is that each bar has the same starting offset, same width, and this makes comparing by area much easier. The trade off is that it increases the width of each point on the axis and potentially displaces some of the visualization outside the viewport. I proposed this change at #5130 based on a conversation with a user. If we consider the breakdown use case as well as time comparison ranges, the need for distinct bars in a group becomes more apparent.

Attached is some sample work from my time on breakdowns and comparison ranges. It's mostly to ensure contrast between items, but you can also see how it's easy to discern items that have large differences in values.

[clarkus]

I think the core problem here is that we're overloading the chart type with calculation methods.

We need to communicate two things here and I'm not sure if they need to be tightly coupled or not:

1. Calculation Method - How is the data organized? Is it shown over a time axis? Is it just a grouping of values based on some non-time attribute? How is data aggregated? Is this a continuous series of data, or are we charting cumulative data?
2. Visualization Type - How does the user want to visualize this? Stacked bars or discrete bars are both valid visualization types for either scenario, it'd just up to the user to select the type that is most appropriate for the data being visualized. They could even use pie charts 😲 . Note that some calculation methods might disqualify some visualization types.

Proposed solution - break insight options into distinct menus of calculation type and visualization type. Drop the chart type sub-groupings. It's kind of weird to only have two options under the calculation methods. I'm not sure what other options could add value here... maybe logarithmic calculations?

Related issue based on feedback from a user #5130

[paolodamico]

The separation makes total sense and in line with what I was thinking. Only thing I'm not 100% sure about is if stacked chart communicates well enough that the data is aggregated instead of a time series. Wdyt ?

[clarkus]

@paolodamico I think this ultimately depends on the insight type, the query structure, and what other options are being applied. Some insights don't have any visualization options. Lifecycle is always a stacked bar, but Trends has way more options.

The user is opting for categorical groupings of data instead of continuous (time) groupings. It's not really a different calculation method, just a different "group by" option. Any ideas on how we might expose that in a clear way? Maybe categorical options are only offered when a breakdown is applied?

The other idea I had was to group visualization types by their grouping method - for example:

• Values shown over time
  • Line
  • Area
  • Bars
• Values grouped by category
  • Bars
  • Stacked bars
  • Pie
• Tabular data
  • Tables

[marcushyett-ph]

This is from excel (probably an old version) - the information architecture is kind of a bit muddled here as well. Most of them are types of visualization (although some won't be possible depending on the data you have to work with), except for things like "Stock" graph which is a specialized time-series graph.

Tableau do something more consistent:

Each option is a different type of visualization (you have to work out which one you want pretty much entirely visually), but certain visualization options are greyed out based on the data you have. For example if you only have one dimension, probably only a pie chart would be possible.

I'm not sure if any of this context is helpful - but I don't think there's an obvious standard out there for us to fit inline with.

[paolodamico]

I like the idea of having that option only when it makes sense (and grayed out the rest of the time). I guess we can have it as a visualization option with a really useful icon that communicates the type of graph (perhaps the same one you have but horizontal?). Wdyt?

Can implement afterwards

[clarkus]

I put together a quick matrix of options based on what we support today. This issue is pretty isolated to Trends. The visualization options display in other insight types, but are never actually made available.

Can we reliably infer the compatible visualization types based on a query? Time is a constant in every scenario except User Paths. I think @paolodamico's idea makes sense, but it feels like we could do more to be clear. What if we took that idea and then changed the groupings to be based on the x-axis. The group labels here could be better but it's really "stuff shown over time" or "stuff shown in categorical groupings". And then there's tables which doesn't really fit in either. Maybe if we had alternate table formats?

There's a secondary case when breakdowns are applied. That could result in a secondary option for bars where the user opts for discrete bars or stacked. I think discrete would be the most actionable default, but it makes sense to provide the stacked option for users who want to use it. This could also impact the Lifecycle insight. That has no secondary visualization options and always renders as a stacked bar. We might consider providing a secondary option there for discrete bars.

[paolodamico]

Keen on trying this! Think the separation makes sense, let's see if it helps users discover insights better. Will add to my to-do list.

[paolodamico]

@clarkus would you mind sharing the final designs for this, think it's worth implementing this sprint.

[posthog-contributions-bot]

This issue has 2030 words at 20 comments. Issues this long are hard to read or contribute to, and tend to take very long to reach a conclusion. Instead, why not:

1. Write some code and submit a pull request! Code wins arguments
2. Have a sync meeting to reach a conclusion
3. Create a Request for Comments and submit a PR with it to the meta repo or product internal repo

Is this issue intended to be sprawling? Consider adding label epic or sprint to indicate this.

[clarkus]

You can find this in figma at https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=5546%3A30687. There isn't much more to this other than the decoupling of parameters into distinct "calculation type" and "visualization type" lists. Tactically it would mean an additional "calculation type" select input in the graph container for an insight. I think this would be limited to trends for now.

[paolodamico]

Perfect, super clear for whomever works on this! Adding a screenshot here for easy reference. Thanks @clarkus!

[Twixes]

I think this is now mostly resolved.