[Reporting] Document vision for Reporting

[tsullivan]

What is the future vision of Reporting? What work needs to happen in the next 6 months to make that vision a reality?

Reporting has a few long term initiatives that are currently not well known.

• Scheduled Reports
• Monitoring of Reporting
• Integrate Reporting into more applications
• Create a general service for screenshots
• More CSV export types: Export of CSV aggregate data from Visual Builder #41600 [Reporting] Full data table content must be contained in the pdf generated #17950

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[jloleysens]

Thanks for opening this issue @tsullivan ! I think we can use this to get crystal clear on the "whys" for work we are considering for reporting. Starting with goals for reporting I've pseudo-randomly gone with the order below. I'd appreciate your help getting them in the right order :) (drawing from our earlier discussion)

1. Screenshot capabilities separate from reporting. Give Kibana the general ability to screenshot any piece of UI on any URL.
2. Scheduled reports, many users and customers are asking for this. Perhaps this should be 1.?
3. Plugins should provide "print-friendly" views of their UI, reporting should not own any aspect of this.
4. We want to see more plugins using reporting. The more generally available reporting is the better.
   • Maps (complex due to async loading of map tiles)
   • Timelion
5. Alerts that take screenshots
6. Monitoring reporting
   • Reports are taking too much RAM or time to generate
7. Expression function for screenshots

Looking at each of these, we should walk through what these enable specifically and work required in order to achieve these goals. Perhaps some of the items contain blockers due to technical debt - in that way we know which tech debt we should prioritise.

I think we should add to these items anything critical to be done for 8.0 (personally I would classify anything linked to 8.0 as highest priority).

For example:

Screenshot capabilities separate from reporting

This work will enable Kibana to capture pieces of UI in screenshots for sharing in, for example, Slack message embeds or reports in a generalised way.

This is a capability "native" to x-pack/plugins/reporting. It should be a fairly straight-forward piece of functionality to extract to src/plugins but requires research and design for exposing APIs.

A tricky piece of this AFAICT is how screenshots might be shared: this implies screenshotting server-side and so doing screenshot work in some way. This makes me think of capabilities like that in Task Manager or the work done in Upgrade Assistant - both of which live in x-pack.

And so on...

Once we have this we can create individual issues and link them back to this meta issue that captures the vision (or link to the existing relevant issue as you have done for some these)

Let me know what you think! Not sure whether you were planning on documenting in this issue or capturing this somewhere else?

[tsullivan]

"Integrate Reporting into more applications" -- I think this needs to be rephrased as "Improve the UX of Reporting."

Having Reporting integrated into more applications could help or hurt UX. It could hurt it by creating confusion, especially in the area of CSV exports since Kibana already has various solutions for getting the data as CSV.

On the other hand, if we focus on improving the UX, we can use the improvements to cleanly add more integrations of Reporting.

[tsullivan]

1. Screenshot capabilities separate from reporting. Give Kibana the general ability to screenshot any piece of UI on any URL.
2. Scheduled reports, many users and customers are asking for this. Perhaps this should be 1.?
3. Plugins should provide "print-friendly" views of their UI, reporting should not own any aspect of this.
4. We want to see more plugins using reporting. The more generally available reporting is the better.

• Maps (complex due to async loading of map tiles)
• Timelion

5. Alerts that take screenshots
6. Monitoring reporting

• Reports are taking too much RAM or time to generate

7. Expression function for screenshots

Numbers 1, 5 and 7 fall into the same area: extracting the screenshot modules from Reporting so we have other ways of generating screenshots besides scheduling a report

3 and 4 fall under the category of "Transfer ownership to the apps on where and how Reporting is integrated"

Let's stick to using Jira to track these as Epics. Then we can categorize all the bugs by Epic. We can spot areas where new tickets need to be filed as meta issues or to start a discussion.

Here are the epics, as I would add them:

• Scheduled reports
• Monitoring of Reporting
• Improve UX
• Refactor the screenshot modules as a new plugin
• Aggregate-based CSV exports
• Transfer ownership of integrations to the app teams

Thanks for all your energy on this @jloleysens !!!

[jloleysens]

@tsullivan Tracking in Jira sounds good to me 👍🏻

[tsullivan]

Going to close this as we've built a structure of our roadmap in Jira.

High level initiatives

Focus on UX Improvements