[PROPOSAL] Dashboard Rows in OpenSearch Dashboards

[jkowall]

Requirements - What kind of business use case are you trying to solve?

• Dashboarding today allows for long and complex dashboards, but they are hard to scroll and manage on screen
• Allow dashboards to link to other dashboards or copy configurations from them
• Create centralized views of data into a single dashboard for use cases in a NOC/operations center for example.

Problem - What blocks you from solving this today?

There is a missing feature to create rows or separators between sections of a long dashboard. This would allow for separations of parts of a dashboard and the ability to collapse sections when not in use.

Everything in a dashboard is singular to a specific dashboard. We would need to create the notion of the ability to link dashboards or copy dashboard configurations into another dashboard.

Proposal - what do you suggest to solve the problem or improve the existing situation?

There are two ways we can solve this:

1. Adding a “Row container” that will contain tiles (Visualizations )
   1. Every row will have a name and an arrangement of tiles
   2. The user can minimize or collapse rows
   3. Instead of placing visualizations one by one, Rows could clone (or reference?) all visualizations of an existing dashboard (later?)
2. Adding a new object that will contain dashboards
   4. Same as creating dashboards and adding visualizations, but adding dashboards

We would like to create a way to add a row and drag existing panels into and between rows for example this is possible in Grafana.

When adding a new panel in OpenSearch Dashboards, you should also have an option to add a row.

The row could be renamed, or deleted for example this in Grafana.

The user may drag panels into rows or between rows.

Assumptions

The user can create dashboards as new, or editing existing dashboards or linking existing dashboards, or copied into existing dashboards.

Any open questions to address

How would the export of these dashboards work in Kibana? We would need to think about how this feature works with backward and forward compatibility.

[JacobBrandt]

I like this idea of being able to show/hide sections of your dashboard. I'd really like an option that takes this further and doesn't limit to just working with rows. For instance, I'd like a way to create a panel that I could cycle through views as horizontal tabs. Someone else might like it as vertical tabs and not full width rows. Temporarily hiding individual visualizations that you could easily bring back would also be great.

WARNING: Last paragraph summarizes my solution to this immediate need. However, I'm about to explain how dashboard creation and management of visualizations could be much better. No judgement if you skip this section.

I think the whole dashboard functionality is a little rudimentary. It's pretty basic and most of the time annoying to use. Right now we perform these tasks:

1. Add visualization to a dashboard.
2. Find visualization that was randomly placed at the bottom of the page.
3. Resize visualization to what you want it to be.
4. Move visualization to where you want it to be as long as it's stuck to the top of the page or bottom of another visualization (no floating visualizations are allowed at the moment)

I bring this up because if this proposal will be worked in a similar way to Grafana as suggested then where do new visualizations get placed? Below all rows? It's already annoying the way it currently is but if I have all my rows expanded and go to add a new one its now potentially even further away from where I would like it placed.

What if instead there was a whole new way of creating dashboards. I imagine a future world where I can do the following:

1. I draw a box in this dashboard space. a. This drawn box becomes the size of a view that will be placed at this location.
2. I'm prompted with a choice to create another view or choose a view to place here. a. The neighboring views adjust to accommodate the space of this new view by either moving to side of it or above/below it.

I made steps 2, 3 & 4 obsolete from the previous workflow. You no longer have to find the visualization, resize it or move it. You picked exactly where and how large you wanted the view in this new workflow in step 1.

I say view in the workflow above because this should not be limited to just visualizations. Why can't I place a dashboard in a dashboard? All the fundamental pieces are in place within the code to make this happen. SearchSource can have parent SearchSource. So a view could contain children views. Every view will have a SearchSource and these children views will have a SearchSource whose parent is their parent view's SearchSource.

Now imagine that this View can do the following:

1. Create context switching options a. Full width row based headers b. Horizontal tabs c. Vertical tabs
2. Can apply their own filtering (since every view has their own SearchSource) a. I can then copy/drag/create views in this view and they will start using the additional filters applied to this view.
3. Can be temporarily removed. a. Imagine being able to remove temporarily a view from your screen, but it be placed in a location that you can easily bring it back. Like putting tools back on your tool belt, you know it's there and can access it when you want/need it.

If you reached all the way here than thank you for listening.

Potential Solution My proposal to the solution of this need is to first start with creating a View object that can at first just allow the context switching options (which is your immediate need) but make sure we're not just limiting the option to just rows. This way we are better prepared for potential future enhancements of the tool.

[galangel]

@JacobBrandt what do you think about adding tags to Viz's?

I am thinking that instead of arranging them into groups, we could show and hide Viz's in dashboards (filtering) based on tags.

So maybe instead of this, we should add tagging functionality.

Maybe the default tag that will be available from the start is "Favorite", it could also accept special styling, Other tags could be created and applied to Viz's. Then in a dashboard view, you could toggle on or off Tags and it will show or hide the corresponding Viz's

Other Functions to the tags could be: (some ideas I had)

• in dashboards view: bring to top -> will bring all related viz's to the top of the dashboard
• in dashboards view: show only -> will hide all Viz's without selected tag
• when creating dashboard: quick dashboard creating by just selecting tags, and all related viz's will be added automatically.

[JacobBrandt]

@galangel I like that you're thinking about tagging as I believe tagging should be possible for when saving the saved objects (visualizations, dashboards, saved searches). I also have thought of an idea that utilized tags but not used in a way as filtering the dashboard view as you proposed here. Tagging would be useful for users to be able to quickly find related views and has benefits not just on the dashboard.

One thing that makes a UX great is for features to be instinctively deterministic. I think using tags in the filtering of the dashboard view as you mentioned above has a few grey areas on what the behavior will be. Here are the questions I immediately had when thinking about.

in dashboards view: bring to top -> will bring all related viz's to the top of the dashboard

• What will the layout look like at the top?
• What will the layout look like for where they used to live?
• How do they get back to their previous layout?
• This seems particularly unmanageable if they started rearranging the remaining visible objects.

in dashboards view: show only -> will hide all Viz's without selected tag

• What will the layout look like for the ones that remain visible?
• I'm presuming also a hide tag would exist in which case an object with tag A and B and user has chosen to hide tag A and show tag B. What is the state of this object?
• How do they get back to their previous layout?
• This seems particularly unmanageable if they started rearranging the remaining visible objects.

Both of these above dashboard view filtering options for tags you mentioned above are still solvable with the grouping I mentioned I would like to see with views. The benefit to the groups is that they are deterministic because the layouts were designed by the user. So when they switch between views they know what they are getting and exactly how it will look. Also, when they hide views they can bring that view back exactly the same as when they hid it.

when creating dashboard: quick dashboard creating by just selecting tags, and all related viz's will be added automatically.

• Allowing the user to use tags to find what to add to the dashboard would be useful. However, adding all saved objects for a selected tag is potentially problematic.

Overall, tagging would be a good addition for saved objects as they can help solve many use cases throughout the tool. I still think grouping is the better option though for viewing these saved objects on a dashboard.