Update navigation pattern within Advanced Settings

[KrooshalUX]

Within the Advanced Settings feature, there appears to be a search filter that a user can apply in order to limit the display of the number of settings on the page at any given time. However, the use of the search bar category filter is intended to be for OuiDataGrid or OuiBasicTable, not a described form / content page. This pattern also has the potential to interfere with the search bars incremental search and ultimately cause errors if modified.

To align to more of an expected navigation pattern as well as clearing runway for further improvements to Advanced Settings, what would be ideal is to utilize children within OuiSideNav to surface up these sub categories within Advanced Settings, and providing jump links to those page sections.

The change would appear as:

When the user loads the Advanced Settings page, the Advanced Setting category would display its children, with General being the default active section. When a user clicks any of the children, the content within the page would scroll, anchoring the user to the content within the sepcific OuiPanel. See "Nested item options" within OUI Documentation.

This change would ideally result in exposing individual paths (ex: /app/management/opensearch-dashboards/settings/visualization) for each of the panels for deep linking opportunities within documentation, call outs, errors and loading states.

In addition to existing incremental search functionality (hiding irrelevant content within category panels), display match count within OuiSideNav for each section.

[KrooshalUX]

cc @kgcreative & @kamingleung - As a heads up - this is the precursor to introducing UI options to Advanced Settings as a new category for managing light mode, dark mode and other UI settings I am going to pull out from General.

[ashwin-pc]

Can we also add how many settings we have available like this?

The number of setting available reduces in count based on the search field

[KrooshalUX]

@ashwin-pc This is a proposal that I would take into serious consideration. I think UX needs to dive a bit deeper into some of the count patterns given that in some cases, counts cost $ or cause pages to hang.

Re: "The number of setting available reduces in count based on the search field" - do you mean an incremental search would dynamically update the count? How would you feel if that is the only time counts would appear - is on incremental search, at least at the launch of this change while we work towards an opinion on counts from the design system overall?

[joshuarrrr]

This design guidance should take precedence over other mitigations proposed in https://github.com/opensearch-project/OpenSearch-Dashboards/issues/3963

[KrooshalUX]

@joshuarrrr would we include removing the HOC custom search bar that mitigated the issue from EUI with incremental search in this work as well? It does appear that issue was fixed by the time we forked into OUI, rendering the HOC potentially irrelevant ?

[ashwin-pc]

@KrooshalUX Thats a neat idea too, I personally dont need the counts until im widdling down my settings. Thats when i need it to tell me if im searching for the right thing

[ashwin-pc]

Another tangential suggestion i have here is to make that settings tree collapsible and pinned to the side so that when the content scrolls, we dont lose the navigation options.

[KrooshalUX]

Another tangential suggestion i have here is to make that settings tree collapsible and pinned to the side so that when the content scrolls, we dont lose the navigation options.

@ashwin-pc that is a change we intend to make to OUI page template - and migrate all of these experiences to that page template.

I will update the mockup to include counts on search - and then I think this can be put into queue. I will create the OUI page template stub also.

[KrooshalUX]

@ashwin-pc - the issue has been updated with incremental search counts in OuiSideNav