Dashboards: lock visualization to a specific date range

slavafomin commented 2 years ago

Hello!

Is your feature request related to a problem? Please describe. Right now, all visualizations are using time range selected for the dashboard. However, we want to display visualizations that show information for various time periods. For example, we have Gauge, that shows RPS for the selected time range and we would like to see three gauges: for 1, 5 and 15 minute periods (like top program shows CPU load in Linux). However, if dashboard time range set to e.g. a week, then all three gauges will display the same value for the week.

Describe the solution you'd like It would be extremely useful if we could configure a preset time range on a visualization or visualization instance level. The relevant feature in Kibana is called a Per panel time range.

Describe alternatives you've considered I can't really find an alternative for this.

Additional context We find this a very important and a must-have feature without which we just can't effectively use the OpenSearch dashboards.

Thank you!

dblock commented 2 years ago

Moved to OpenSearch-Dashboards.

Big-al commented 2 years ago

A workaround was linked in the Kibana github repo about the original issue: https://github.com/elastic/kibana/issues/3578 the specific comment with a workaround is available here: https://github.com/elastic/kibana/issues/3578#issuecomment-216810928 before it was finally fixed here: https://github.com/elastic/kibana/pull/43153

I hope that helps anyone else looking for this feature as well.

kavilla commented 2 years ago

Bump for priority. We put as a good first issue and we welcome anyone to implement. But this seems to a great feature and very requested.

Pinging @ahopp, @kgcreative, @btzeng to seek if we are able to prioritize this.

kgcreative commented 2 years ago

@kavilla - I'd like to see custom filters and custom time ranges as options for individual visualizations. @btzeng - let's explore this from a UX/Visual perspective

btzeng commented 2 years ago

@ahopp @kavilla see panel time configuration design below.

User story As a devop / or [ ] user, I want to specify a time range for individual panels so that I can get a customized time in different panels. This provides more granular control in each visualization panel. Also I can lock the time so it won’t be affected by global time range chage.

Design (key screens) Select customize panel time range in the menu

Configure panel time range

Customized time range displayed in panel header

kavilla commented 2 years ago

[Groom]:

@kavilla will follow-up about ownership about this.

venkawu commented 2 years ago

A workaround was linked in the Kibana github repo about the original issue: elastic/kibana#3578 the specific comment with a workaround is available here: elastic/kibana#3578 (comment) before it was finally fixed here: elastic/kibana#43153

I hope that helps anyone else looking for this feature as well.

im on opensearch version 1.2. I do not see the "custom panel time range" open in the visualization/panel menu. I only see "inspect" and "maximize panel"

joshuarrrr commented 2 years ago

@btzeng @ahopp I'm definitely a fan of adding this feature, but have a couple questions and concerns about the ramifications of this approach that may warrant further discussion.

1. Global Query Bar behavior may become surprising

One large risk is that we're breaking the fundamental information hierarchy implied by the Global Query Bar. Currently, that component behaves so consistently that users don't really have to give it much thought: the queries and filters in the bar affect nearly everything below it, including all core dashboards applications (discover, dashboards, visualizations). I'd argue that the few cases where that doesn't hold true are actually confusing bugs (such as the field summaries in discover, which only use a data sample of the total global query). Not only is it a single place to control global queries and filters, but it's also a single, consistent place to check for which queries and filters are in place.

Allowing individual UI elements to opt-out or ignore it increases the cognitive load on the user, and increases the likelihood of misinterpreting a dashboard or visualization.

2. Clutter of query controls/displays on any number of panels

I'm also concerned about adding visual clutter to dashboards that use locked visualizations - this exploration is only for time range, but I imagine that it would be similarly useful for a panel to lock/override any other component of the global query bar (filters, as @kgcreative mentioned, or query). And then you're stuck with the design challenge of providing both the controls and status display on many panels at once.

In the current mocks, displaying the date range alone is already adding a significant amount of ink (and we'd also need to figure out how to condense/simplify for tiny panels or mobile).

3. Which object "owns" the customized time range?

I may be misinterpreting the mocks, but it appears as if the locked time range is a property of the panel (the embedded instance of a particular visualization on a particular dashboard) rather than as a property of the visualization itself (where the particular visualization is created with a locked time range). In @slavafomin's example, it might actually be more practical to create a "locked" gauge visualization that always shows the same time range on any dashboard you add it to.

Depending on the implementation, we could still allow edits from the panel, even if it's a property of the visualization.

Additional ideas

I wonder if it's worth exploring other ways to visually distinguish pinned/locked panels from those that can be controlled globally (1), without taking the kitchen sink approach (2). I know one of the design concepts @KrooshalUX has been exploring is using the canvas itself to distinguish between global/app controls and actions, and it seems like something similar would help here. If pinned/locked panels are visually not part of the same canvas as the global query bar, it would be more obvious at a glance which panels will be updated by the global query bar and which won't, even if we aren't displaying the complete locked query information.

Finally, I think it might be useful to allow users to lock/unlock a panel without losing the custom time range it has defined, the same way they can disable/enable filters without having to lose/recreate the filter definition.

btzeng commented 2 years ago

@joshuarrrr Related to the panel header component that Kroosh is working on, we'll adopt the panel component here. I'll also talk to her and Xenia about the display of custom time range since it's an information that users want to see upfront. I don't think it should be buried inside the meatball menu.

joshuarrrr commented 2 years ago

We had a chat today where we talked about the larger context that this feature fits into (including other "anywhere" projects that will also be adding more features to dashboard panels). UX will provide updated mocks, and we'll make sure that the devs all working on these similar issues are in contact and working together. Overly simplified summary to the concerns I raised above:

Yes, panel state/indicators are part of an in-progress UX challenge; indicating locked state is but one of several things that may need indicators or icons
We do have plans for panel-specific filters, and overall panel component is still evolving
TBD - it's probably important to be consistent here with the other anywhere projects.

jimkaba commented 2 years ago

Here's a data point, if it helps.

The company I work with put a significant amount of effort into developing an ELK stack and NMS dashboards based on Elastic/Kibana. They then put a lot of effort into transitioning to OpenSearch, despite the fact that there were several Elastic/Kibana features that were not (yet?) available with OpenSearch.

When the operators learned that they would not be able to have certain charts/graphs with fixed time ranges, that effectively put the transition to OpenSearch completely on hold. It was the one feature they would/could not do without.

If users are continually asking for an established feature/functionality that appears to be "missing" compared to alternative products, it might be beneficial to give them something to work with. (...even if it isn't perfect, isn't a complete solution, or will eventually evolve to better tie in with a more extensive development effort...)

Also, the dashboard mockups presented earlier may be slightly misleading (i.e. pessimistic) in that they show a full date/time range. The basic Elastic/Kibana time ranges are things such as "Last 1 minute", "Last 1 week" etc. These do not take up nearly as much screen real estate. The user also sometimes has the option of working the fixed time range directly into the visualization title if they don't expect it to change.

I realize this one specific feature request is part of a more broadly-scoped effort and that you're factoring in many considerations...so weight my feedback accordingly.

joshuarrrr commented 2 years ago

Thanks @jimkaba, it's always super useful to have specific user feedback like that! I think this is still very much a feature we intend to implement.

joshuarrrr commented 1 year ago

https://github.com/opensearch-project/OpenSearch-Dashboards/issues/3077 is a user request for similar pinning/locking behavior for all filters, not just time range filters.

BalzGuenat commented 1 year ago

In a similar vein as @jimkaba, we are currently in the process of building up our observability and are trying out different solutions. This issue and the resulting difficulty in creating effective dashboards is a major argument against OpenSearch.

cerealcoder commented 1 year ago

Per the comment added by @jimkaba, having a date range is essential for the project I'm working on. Not having a date range option is a show-stopper for me.