Get Explore & Analyze closer to solution docs and better identify Kibana & Elasticsearch content

[florent-leborgne]

Issue

Explore and Analyze is a mix of Elasticsearch & Kibana concepts that dilutes Elasticsearch content and makes it unclear what is specifically about it and about Kibana. Consistent feedback received so far indicates that blurred lines between products aren't working well in the new documentation. This is especially true with Elasticsearch content now being distributed between: API docs, Reference docs, Elasticsearch solution docs, and Explore and analyze docs. The same goes for Kibana, with core Kibana features being too separated from solution docs, which UIs are built on top of Kibana.

Users relying on our navigation have a hard time navigating between these docs sets when they would like to browse the "Elasticsearch" documention, or the "Kibana" documentation, two fundamental products of the Stack.

Goal

Without compromising our metatask approach for new docs, make a step towards more unified product-based docs especially for Elasticsearch and Kibana.

Tasks

• Identify and move content from Explore and analyze that belongs to the Elasticsearch reference
• Identify and move content from Explore and analyze that belongs to the Elasticsearch solution narrative docs
• Make the remaining set of content in Explore and analyze only about Kibana core features
• Bring this set next to solution docs to help transitions between doc sets and have a whole set focusing on using Kibana once data is ingested (meaning Kibana core features + solutions)

Related to: #1644 (comment)

[shainaraskas]

I agree that these sections aren't nicely split, especially when it comes to the reference/conceptual divide, but these fundamental elasticsearch concepts (esp querying and filtering) are not unique to the "search"/"elasticsearch" solution.

I also think our "reference" content is badly scoped: what is truly reference? where do we put decision-making information?

I think the elasticsearch/kibana divide makes a lot less sense given the way that cloud presents the kibana UI. there's very very little kibana branding or signposting, especially when it comes to serverless.

Would be interested to know what the long term vision and perspective from product is here. Would also like a perspective from the dev docs team that owns the pieces that would be moving out.

[szabosteve]

I'm concerned about the potential collateral impact of this split. For example, the ML content could end up scattered: some of it might be placed under ES or Search (which isn't ideal, as it's not solution-specific content) while other parts would stay in the Explore and Analyze section due to their Kibana focus. This fragmentation would be detrimental to the ML content overall. We would be solving one problem while creating another. Even the recent renaming of the section to Explore and Analyze with Kibana made some of the content feel out of place, just for the trade-off of highlighting Kibana.

I agree that this is an issue we need to address, but I'm not convinced that this approach is the best path forward. If the goal is to better surface Kibana-related content, perhaps we could introduce a dedicated top-level section within Explore and Analyze called "Kibana." That way, strongly Kibana-focused content would be clearly grouped, without forcing the rest of the material to be relocated.

I'm definitely open to continuing the discussion and finding a third option that might balance our goals better.