Discover 2.0 - possibility to expand multiple documents at the same time

[maciejr-gain]

Is your feature request related to a problem? Please describe.

With all previous versions it was possible to expand as many Discover documents as users needed. It was heavily used by our users to compare few documents while debugging issues. The new Discover unfortunately removed this possibility. If one document is expanded, in order to expand another one the prior one has to be closed. This makes investigating by comparing three of four documents very difficult and time consuming. Would it be possible to somehow bring back the old functionality where user is able to expand few documents at the same time?

Describe the solution you'd like

Possibility to expand multiple documents on the same page

[abbyhu2000]

@maciejr-gain Thanks for opening up the proposal!

@ashwin-pc Since expanding document detail has been changed to a flyout, it makes expanding multiple documents impossible. Should we add feature to allow this? @dagneyb @andrross

[ashwin-pc]

@kgcreative @shanilpa any thoughts on how to solve this with our new layout?

[kgcreative]

@kgcreative @shanilpa any thoughts on how to solve this with our new layout?

I want to think about this more. Seems like expanding rows to view document details is a potentially desirable option, but I do think that the larger fly out does help with seeing more at once. We need to explore a few options.

First thing that comes to mind is making it so document details could be pinned and floated, that way you could have multiple floating windows that you could arrange and compare. I don't think we have a component for this today, but I could see it being useful for multiple use cases. Other options would be to allow for expanding or inspecting. Expanding would just expand the full json similar to legacy discover, but inspect would be the fully featured flyout with tabs and additional detail. I'm open to other thoughts as well

[maciejr-gain]

First of all, thank you for being interested in helping with this!

@kgcreative from my point of view the second proposal seems better tbh.

[kgcreative]

@shanilpa can you do a quick exploration of option 2, and propose a different alternative if it comes to mind? Once we have that, then @abbyhu2000 & @ashwin-pc can scope and break it down

[shanilpa]

Hey @maciejr-gain - thanks for filing this issue. I had a couple of clarifying questions around some of your users needs and workflows to help inform some of my ideation.

1. You mentioned in the previous versions of Discover users expanded multiple rows to compare against each other. Do you know how many they would typically open in a single view? 1-3, 4-7, or 7+?
2. Do you know what they are typically looking for when they expand the event?
3. Did the previous version of Discover that allowed for expanding events have missing functionality that your users wanted?
4. Do your users interact with other parts of discover while the rows were expanded in the previous version?

These are pretty nitty gritty questions, feel free to answer any you have details on.

[maciejr-gain]

Hi @shanilpa, let me try to reply to my best knowledge:

1. I am not sure exactly, we have quite a lot of users and I'm pretty sure the use scenarios vary between the teams. But my best guess would be that they would typically open 1-5 messages in a single view
2. In most cases they are trying to follow a stream of events, either within one application, or several applications that communicate with each other. They definitely rely on expanding the whole "@message" field, but they might be looking at other fields as well (most probably comparing "@timestamp", and several other, based on the application specific parsing rules).
3. We never got complaints about missing functionalities in the previous version of Discover
4. The one thing that I am sure they have been doing was adding additional filters based on the fields found in the Discover. Not sure if anything else.

I hope this helps, please ping me if you need anything else from me.

[shanilpa]

Hey @maciejr-gain thanks for those answers - they definitely helped inform some of the options below. Curious on your thoughts, feedback, and if they address your pain points.

Option 1 - Toggle experience

Allowing users to toggle between a flyout, and inline event detail views

https://github.com/opensearch-project/OpenSearch-Dashboards/assets/113368824/c9e22e73-0b2f-4ce8-95d4-c5a2f5394683

Benefit to option 1

• Users have the choice to cycle between options based on their use case and preference

Disadvantages to option 1

• Inline can be disorienting and require lots of scrolling up and down for users
• No existing components to support this

Option 2 - Sliding panels experience

Sliding panels that allow users to open multiple flyouts with the option to pin those panels.

Benefit to option 2

• Addresses the disorienting and scrolling disadvantage mentioned above by allowing users to open multiple flyouts that slide over each other. Users can also pin a flyout as a reference and open others to compare against aiding in exploration.
• New pattern that can be useful for other parts of the product

Disadvantages to option 2

• Not an existing pattern and requires lots of UX and engineering complexity

Recommendation

Personally, I think we should go with option 1 short term but aim for something like option 2 long term - with this approach we can have parts of both experiences (user control, and a better pattern for referencing).

cc @ashwin-pc @abbyhu2000 @kgcreative

[maciejr-gain]

@shanilpa thank you for providing the options! The first one looks definitely better and cleaner in my opinion. It gives choice, but when switched to inline the old look and feel are brought back.

The second options might work well for 2, maybe 3 expanded documents. If someone would like to expand 5 - I'm guessing it will not be readable anymore.

If I can vote, my vote is for option 1, no doubt.

[shanilpa]

@maciejr-gain thanks for the feedback!

@ashwin-pc @abbyhu2000 what would the engineering scope look like to get this change in for the next release?

[dagneyb]

I'm aligned with Option 1 FWIW

[kgcreative]

Yeah, let's go with option 1

[ashwin-pc]

cc: @ananzh

[michaelandrepearce]

+1 for option 1 (if my vote counts at all as an end user)

[kgcreative]

Your voice/vote as a user is even more important tbh

[damslo]

Hello, Option 1 looks great. Is there any chance to include it in 7.12.0? We have dozens users complaining about that.

[MadaniKK]

May I work on this? Thank you!

[ananzh]

@MadaniKK Thank you for the help!

[daihengbin724]

option 1 🎅

[AMoo-Miki]

Hello, Option 1 looks great. Is there any chance to include it in 7.12.0? We have dozens users complaining about that.

OpenSearch Dashboards is in version 2; they have no. version 7.

[xodat2]

Hello, Option 1 looks great. Is there any chance to include it in 7.12.0? We have dozens users complaining about that.

OpenSearch Dashboards is in version 2; they have no. version 7.

Yes, I mean 2.12.0, anyway, apparently it will be in 2.13

[kgcreative]

@wbeckler can we prioritize this for 2.12?

[abbyhu2000]

@MadaniKK How is the progress on this issue? Since we wish to target this for 2.12.0, do you have a timeline?

[MadaniKK]

Hi, I have not started on this issue because I was going to have a meeting with Anan to discuss this issue when she is back from her leave on 17th Jan. What should I do now?

[abbyhu2000]

@MadaniKK Since we wish to target this for 2.12, this issue will be prioritized by the team. Do you want to work on another issue that is not so urgent? For example, we can assign https://github.com/opensearch-project/OpenSearch-Dashboards/issues/5616 to you?

[MadaniKK]

Yes sure! And it is ok I l still have some other issues to work on first. Thank you!

[henrik-ticket]

Option 1 please :heart:

[ankraj1]

Option 1 🙏

[nitin-kumar-ttn]

Option 1 please 🙏

[mz118]

Option 1 please 🙏

[ashwin-pc]

We are going with option 1. Thanks for all the feedback :)

[shanilpa]

@ashwin-pc @abbyhu2000 could we also work to contribute the changes to data grid back into OUI? This doesn't have to block the release of this enhancement but would be nice to have as an option for use elsewhere in the application.

[ananzh]

We restore legacy table in 2.12, which partially resolve the issue. Now only datagrid table missing this functionality. Update tag: remove bug and 2.12.

[aavileli]

please revert to having inline event detail this is really a downgrade for people using it for debugging and logging. Option 1