[DISCUSS] Top Nav \ Search Bar behavior consistency

[lizozom]

NOTE

While working on #40262, @cchaos requested to remove the old custom behavior that used to "tuck" EuiSuperDataPicker in the same row with TopNavMenu, if it was the only SearchBar component.

The goal of this issue is to define and implement consistent behavior for TopNavMenu and SearchBar.

Summary

Our top navigation section (aka TopNavMenu or kbn_top_nav) consists of:

• Navigation menu of items that perform an action when clicked on. Some behavior examples are:
  • Open a modal
  • Open the side bar
  • Show a menu of sub items
  • Refresh the page
• SearchBar component that contains the FilterBar and QueryBar. QueryBar is also a composite component that wraps around QueryInputBar, EuiSuperDataPicker and EuiSuperUpdateButton.

While the general rule is that apps show SearchBar in it's full configuration, there are some exceptions. These exceptions create inconsistent UX when navigating between apps (and even within the same app).

Current exceptions

Visualizations

Most visualizations use SearchBar in it's full configuration, but there are some edge cases.

Controls

Has FilterBar and EuiSuperDataPicker.
I think we could show QueryInputBar in disabled mode here.

TSVB and Timelion

Show only EuiSuperDataPicker, as filters and query are set by the visualization editor itself.

Query input inside TSCB:

Markdown

Shows only the autorefresh component of EuiSuperDataPicker.
I think we could show the rest of the components in disabled mode here.

Timelion App

--> Screenshot needed

[lizozom]

One suggestion was showing the unused components as disabled.
This would work great for markdown and controls, but would be strange for Maps, TSVB and which provide alternative input controls in the scope of the app.

[elasticmachine]

Pinging @elastic/kibana-app-arch

[elasticmachine]

Pinging @elastic/kibana-design

[nreese]

Maps provide filters as part of the layers setup, so it shows a SearchBar only a full QueryBar.

We will most likely add the filter bar to the maps application in 7.4. #34663

[lizozom]

@cchaos Do you think this is going to happen for 7.4?
If not, is the UI at the moment OK to be released the way it is?

[nreese]

Filter bar has been added to maps application with #42756

[lizozom]

@nreese I removed maps from the exceptions list

@chrisronline I remember you had mentioned that you are planning to add a custom configuration of TopNavMenu to monitoring, right (timepicker + menu).

You can link the issue here to track UI updates.

[cchaos]

@lizozom The different combinations of the query and filter bars, time picker, top menu, and possible tab navigation is making it hard to define a pattern. I don't foresee a solution being derived at for 7.4.

However, can we make one small change? When the query input is not available, can we keep the time picker flush right? This will at least keep the position stable across (most) apps and especially keeps the Refresh button in the same position as well.

[snide]

cc @katrin-freihofner and @hbharding on this thread as well so they have some background for the challenges.

[lizozom]

@cchaos I could do that if you like.

But what do you think about this -

If only timepicker is required - show a disabled query input + timepicker, and a collapsed + disabled filter bar.
Lets add a tooltip on the disabled query input: In cases where query input is supported within the app (like in TSVB), it could say where you can find it. In cases where query input is not supported, the tooltip will simply say so.

This solution would cover Timelion visualization and app, markdown and TSVB visualizations and the upcoming version of the monitoring app.

For the weird case of controls (supporting filter bar + filter bar) we could go with a similar approach - showing a disabled query input field and a timepicker + uncollapsed filter bar.

However, I wonder if this could maybe be solved from a product standpoint (@AlonaNadler, I know I've asked you about it, but I'm still wondering why it's the only place with this configuration in all of Kibana :) )

[chrisronline]

the upcoming version of the monitoring app

My only issue with the new implementation is how the time picker isn't flushed to the right, like it has been historically. If the plan is to change the implementation to do that, I'm all for it!

[lizozom]

@chrisronline originally, the timepicker wasn't only flushed to the right, but it was in the same row with the menu. I think the latest suggestion is to flush it right, but it still won't be in the same row, so there will be quite a lot of blank space.

I could implement either option @cchaos and design team prefer of course.

[chrisronline]

I think the latest suggestion is to flush it right, but it still won't be in the same row, so there will be quite a lot of blank space.

I think that's better than the alternative. I'll defer to the design team for the whitespace concerns, but I think the consistency of the placement is important for our users

[lizozom]

I think the consistency of the placement is important for our users

Yes! The current situation is obviously bad and temporary.

@cchaos I could implement this solution or if you like my idea, we could try that.
Let me know.

[AlonaNadler]

In general the preference is to have consistency on the location of the elements, we had an issue in the past that users couldn't find the time picker. The location was improved in 7.x and I will like to ask we keep it in the same place for every app/page no matter which of the query bar or filter elements are used.

If only timepicker is required - show a disabled query input + timepicker, and a collapsed + disabled filter bar.

I'm not sure I see the benefits of having elements that are disabled like the search bar, I think it raises missing capabilities in our product, what do you think is the benefit of doing that?

For control I think the search bar is not there for a historical reason (no sure why, @nreese do you recall) currently in 7.3 in control there is a filter bar but it is broken (I will open a bug separately). No objections to having search bar and filters on control if it makes it easier.

[nreese]

For control I think the search bar is not there for a historical reason (no sure why, @nreese do you recall)

The search bar was removed from the controls visualize editor because the search bar does not effect the results of the control. Users were getting confused when they entered/saved queries with their controls visualization and the results were not filtered by the query.

[cchaos]

@lizozom I think for now, just stick with having that empty space there. I think we're going to find more problems with disabled controls than we will with not great layouts.

[lizozom]

No problem @cchaos
@AlonaNadler @nreese So which components should controls have? Only timpicker? Timepicker and the filter bar?

[nreese]

So which components should controls have? Only timpicker? Timepicker and the filter bar?

Controls needs the filter bar so users can see what the component does. Controls also needs time picker since time picker is used to limit the search results

[cchaos]

I wouldn't quite consider this one closed. The problem still exists, but #43255 was mainly a shim for now. We do have some designers thinking on this so I'd like to leave this issue open as a reference.

[lizozom]

@cchaos any updates on this? Can we close it?

[cchaos]

No there hasn't been any movements on this yet. This is a very hard problem to solve as different apps require different components and different teams implement different layouts. We do have some current efforts happening around trying to unify this experience across all plugins, but there most likely won't be a (final) solution until 8.0.

I can create a sort of "Meta" ticket to congregate the different individual items being discussed and reference this particular issue. But we can close it out since it was mainly Kibana App specific.

[lizozom]

I'll close this issue for now @cchaos
Feel free to tag me on any new meta issue that's being created