Dive dashboard launch

[tiina303]

We worked on this during the offsite, but there are a couple of things that are still needed to productionize it:

1. move it to ee & release for all paid customers
2. product design: currently we just prepend the dashboardItem we came from, but dashboards can have layouts, which would get messed up if we did it this way. It would be great to be able to see where we came from (e.g. to know when the spike in the graph happened exactly that made me click on the dive link, but I don't know how to design it)
3. Code changes based on ^
4. Blog post (including a diving hedgehog @lottiecoxon) - I propose with the different user stories we used in our demo

cc @samwinslow @jamesefhawkins anything else I'm missing?

[samwinslow]

Agree that from a UX perspective, ordering the focused item is a priority. I suppose we can build "wrapping" rules into the layout logic such that it will cause other tiles to move down to the next line — will look deeper into the API here.

For highlighting a focus area, the Chartjs crosshair plugin (which we already use) supports dragging. See example.

Though, as we talked about at the offsite, I think we should allow the user to select a region, but not automatically zoom into it, as that loses context for the data.

[samwinslow]

Also, this minor issue can be fixed in minutes — will get around to it soon:

#5917 (merged)

[lottiecoxon]

Sounds great - add a request in the art request board with a deadline so I can factor this into my schedule

[paolodamico]

Taking a step back here, I want to make sure we fully understand all the context so we can work on it in the best possible way. CC @clarkus

• What problem(s) are we solving with dashboard dives?
• Who are we solving this for?

[samwinslow]

@paolodamico My 2¢ on the following:

What problem(s) are we solving with dashboard dives?

Broadly: lack of context.

• Information is missed when the person preparing the dashboard is different than the person consuming its data. At the offsite, we used the example of a CEO who wants to dive into some metrics prepared by an analyst.
• Breakdowns add only 1 more dimension to a graph. Dive dashboards allow you to add another dimension via related graphs. This means more ways to explore data and/or detect anomalies.

Who are we solving this for?

I am not sure. At this point the "need" is admittedly somewhat theoretical, and that could be why we haven't felt more urgency here.

[paolodamico]

That's helpful @samwinslow, thanks! So my proposal would be, let's consider this in the context of Collaboration, both in terms if we want to solve the problem and if this is the best way to do it. If so, we can pick up anything outstanding and ship, and if not we can remove it. Thoughts? CC @alexkim205

[tiina303]

In addition to the CEO the lack of context problem also exists between junior/senior engineers/data analysts/support heros, e.g. trying to understand what's happening if some graph looks odd. Agree for grouping with collaboration.

[alexkim205]

Thanks for the context here. I think there's still a gap in understanding which dimensions we're diving into for a specific insight that needs to be explored here. For example (I might not be understanding how to use this feature exactly) I'm not sure what's happening when I set the dive dashboard of dashboard item, dive from insight to dashboard, and dive back. A simple explanation or copy could clarify what a "dive" actually is. I think this falls under the general "understanding an insight better" collaboration milestone but should be deprioritized until we figure out how to best expose this feature in a usable way.

[paolodamico]

Sounds like a plan @alexkim205! I do think we may benefit of rethinking the problem from scratch, just cause it's taking us so long to realize how it works and all the value from the feature. We should have a clear idea of what collaboration could look like for the next few sprints, and decide whether we want to move forward with this or not.

[mariusandra]

<rant>
Putting on my grumpy old man hat here, and just flyby commenting, that it would have been great if this dive dashboard code would have never ended up in master, but lived in a separate branch, like e.g. the hackathon features of group analytics... or in-product tutorials.

Yes yes, it's behind a feature flag, but while working on insights, I've had to strip out, refactor or fix bugs coming from code related to dive dashboards on at least 3 different occasions. That's a large blast radius for a hackathon project that is not even used. Let's do better next time.
</rant>