[Dashboards List Integration] Create button now requires 2 clicks to create dashboard

[kavilla]

Origin:
#3090

When creating a dashboard with the new integration defaults to making the create button a drop down list. This makes creating a dashboard a 2 click process.

Enhancement

• There should be a one click workflow for dashboards incase there is any workflow attached with the previous existing functionality.

[pjfitzgibbons]

Ack

[pjfitzgibbons]

@kavilla If I understand correctly, the actual concern is whether the changed HTML will break customer-written browser-automation scrips. Dashboard-Create is a low-activity interaction, so making it 2-click when there are integrations is not a super important affect IMO.

[anirudha]

may be we add something like this

[pjfitzgibbons]

@kgcreative @dagneyb I like @anirudha suggestion. It preserves the "default" create (Dashboard/Dashboard), and offers a drop-arrow for additional options?

[kgcreative]

Tagging @KrooshalUX. Let's talk about introducing a "split button" component to OUI for this behavior. Another example is the github "Close with comment" button that's right below the comment box.

In the meantime, OUI does have this pattern: https://oui.opensearch.org/1.0/#/navigation/button#split-buttons

Demo: https://codesandbox.io/s/uqwyek?file=/index.js

[KrooshalUX]

@kgcreative Thanks for tagging me in.

A sort of brain-dump which may not be quite directional yet...

• I don't quite see an issue with it being 2 clicks, here is why: given all of the cool functionality that is coming to dashboards core via our plug-ins/extensions/integrations (appologies I dont have a single word to refer to all of the things existing outside of OSD Core) , I think the notion of "default" might be ... outdated. We have an increasing discoverability challenge for when a plugin/extension/integration gives Dashboards Core new functionality. I am not yet aligned to providing a button that gives you an OSD Dashboard and a separate way to access the plugin/extensions/integrations functionality extended into Dashboards Core. With this split button suggestion, it reflects more of our organizational architecture more than what a user may expect (one button that gives me a menu to show me all my options, kind of like what happens when you create a new visualization).

• Additionally - I think the current OUI split button pattern is very confusing - I have no idea what to press - and this does need to get a new treatment in OUI. I think we can prioritize a change, but I will need to meet with the team to strategize further.

• Currently the majority of menus are triggered by the boxesVertical - so for alignment to trigger OuiContextMenu we should be using that, though I am also partial to arrowDown when its in combination with a button, so I am a bit more aligned to the solution @pjfitzgibbons made in his original issue.

I would like to hear more thoughts on where I am going with the discoverability issue, primarily.

[kgcreative]

@pjfitzgibbons & @kavilla -- please let us know what makes sense to you guys, and then we can make a final determination

[pjfitzgibbons]

@kgcreative @KrooshalUX
So, an interesting thing about the "split button" a-la Github Merge , is that the "option" selected from the drop-down "becomes" the primary button when-selected.

I'll take a couple screenshots next time I get a merge prompt.

This might be an option in that it gives the user a clear interaction, and a clear "target" with meaning, and also gives the test-suite an equally clear "target" to perform the click... and the default no-integrations operation can be the single consistent button.

Screenshots to come...

[canascar]

We have begun working on designing the split button component.

Definition: A split button is a button with two components: a label and an arrow; clicking on the label selects a default action, and clicking on the arrow opens up a list of other possible actions. (Reference)

There are some open questions related to functionality:

1. Navigation on selection of option without button click, or single click as opposed to 2 click function. (Possibly not recommended unless action can be cancelled or delayed.)
2. Using only an icon for the action button (Possibly not recommended or used sparingly unless icon clearly defines the action.)
3. Popover v Dropdown container - most examples opt for a dropdown container as opposed to a popover container.

More design updates coming soon.

[canascar]

I discussed with @pjfitzgibbons about some design issues. We both agreed that a dropdown works best than a popover on click of the expanding secondary (split options) button. This is also consistent throughout most split button/dropdown patterns I've observed - Cloudscape, Adobe, Zendesk, Github - and it will allow us to reuse the existing component SuperSelect which we'd like to use for the selection mechanism.

We also think that the dropdown can be either left/right aligned and defined as a prop. We can also consider making this dependent on where the button and the dropdown appear in regards to the browser window.

Reference:
https://oui.opensearch.org/1.3/#/forms/super-select

Anatomy
A split button consists of:

1. A primary action button containing a label and an optional left icon
2. A secondary action button that expands a dropdown with options to select from that will impact or modify the primary action to be taken.
3. These buttons are separated by a 1 pixel border.

Primary action button width will be determined by the label (and icon and/or combination) consistent with our existing button pattern. Secondary button width should be proportional and use only an icon to denote action of dropdown expansion (in most cases, a down arrow icon but we can allow customizing if necessary.)

We can have split buttons for all our button states and types:

• Filled
• Outline
• Filled small
• Outline small

As far as things to consider for UX

1. Use of Icon only for primary action button - we can have this capability but should write guidelines and warnings around using only an icon for an action. We can also set constraints for when it may be appropriate to use only an icon for such cases.
2. Number of options in the dropdown - we should have a limit for number of items in a split button so it does not become overwhelming. If there is a need for many options, perhaps a component like a dropdown select field is more appropriate in these cases.
3. Option Selection can A. Change the label and contents of the primary action button (ex. Another action is selected and swapped as the primary action.) B. Label and contents remain static but the type of action is modified depending on what is selected (ex. An execution of an action but executed with varying parameters.)
4. Action is triggered by clicking on the primary action button.

Prototype
https://www.figma.com/proto/m3JvQ6e0pQztyywt8xdJdc/Split-button?page-id=41%3A2795&type=design&node-id=41-2796&viewport=386%2C464%2C0.29&t=b7xU3TuGlmyPR2nR-1&scaling=min-zoom&mode=design

@kgcreative, @shanilpa for visibility

[kgcreative]

reuse the existing component SuperSelect which we'd like to use for the selection mechanism.

Also consider popover attached inside an input element(reference: https://oui.opensearch.org/1.3/#/layout/popover%23popover-attached-to-input-element) - which super select may be using under the hood, in combination with selectable (https://oui.opensearch.org/1.3/#/forms/selectable%23single-selection)

[canascar]

We are considering Super Select to be able to use the more complex option that allows for title/description parameters, but yes will look at all reusable options currently available.
https://oui.opensearch.org/1.3/#/forms/super-select#more-complex

[pjfitzgibbons]

Also consider popover attached inside an input element

@canascar and I discussed popover vs select. Our feeling was that the connect-arrow of popover feels like it interrupts the graphical continuity of a drop-down.

If we must consider this as an option, it will add a possilby considerable amount to the code, since the useage of pop-up is different from the plain super-select. Maybe we can plan for this option for a next phase?

@kgcreative

[kgcreative]

So what i'm calling out is that OuiInputPopover is what super select uses under the hood (https://github.com/opensearch-project/oui/blob/main/src/components/form/super_select/super_select.tsx#L321C15-L321C15) to render the context menu attached to the control.

I'm not disagreeing that the visual style of super select is what we want. I'm just sharing that popover has a modality that doesn't render as detached and might allow you for extra flexibility.

[pjfitzgibbons]

I see now. I'll keep that in mind and list it in the alternatives