[Dashboard] Adds Save as button to top menu

[cqliu1]

Summary

Related to #85666.

This adds a Save as button that triggers the dashboard save modal for editing the dashboard title, description, and tags and changes the Save button to quick save without triggering the save modal.

Changes:

• Relabels Save button as Save as
• Adds new Save button that performs quick save action
• Removed Library and Create new buttons from the top menu

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[cqliu1]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[ryankeairns]

Looking good and feeling more natural, nice work.

Is there a technical reason for having both Cancel and Discard? I feel like we could just have Cancel to cover both situations:

• if there are no pending changes, then it just switches out of Edit mode
• if there are pending changes, then it shows the dialog to confirm continue/discard

[ThomThomson]

The reason there is both a cancel and discard is because during the dashboard unsaved changes PR, I noticed that the user can get into a situation where they are in view mode with unsaved changes simply by pressing the browser back button after doing their edits and I didn't want that action to discard their changes. I also wanted that to feel intentional, instead of like a bug.

The badge from #88901 will partially mitigate this by showing their changes are still around, but I thought that separating out 'cancel' and 'discard' would make it more explicit.

@cqliu1 has mentioned before that having two buttons feels redundant and I agreed, but didn't have a better solution at the time. Now I'm wondering if we can cover this by adding an extra option in the cancel dialog... something that could look like this:

@cqliu1 & @ryankeairns, do you think this could work?

[ryankeairns]

Ah right, thanks for the refresher @ThomThomson !
That suggestions looks good to me, but I'd like to hear from @cqliu1 on the feasibility.

[cqliu1]

I think this should be doable. I'd prefer to handle this in a separate PR and go ahead and merge this one if we're good with the save button changes.

Just to clarify, the Keep changes button would keep the changes unsaved and switch to view mode, the Discard changes button should discard the changes and switch to view mode, and the Cancel button should just dismiss the dialog and stay in edit mode?

[ThomThomson]

@cqliu1, that is exactly the way I envisioned it! And a followup will definitely work. I wonder if there is a better way to word keep changes that makes it obvious we are still leaving Edit mode.

[ryankeairns]

We can hash it out further in the next PR, but one idea comes to min:

• Keep unsaved changes which is how we refer to them on the Dashboard home page callout, or
• Switch to view mode which is in effect what you're doing. For the latter, an iconTooltip might be helpful as well to indicate that changes will remain in Edit mode.

[kmartastic]

• Switch to view mode which is in effect what you're doing. For the latter, an iconTooltip might be helpful as well to indicate that changes will remain in Edit mode.

My 2 cents. I am not a fan of "unsaved changes" persisting while leaving Edit mode and going back to View mode.

As a customer, I go to edit mode to make changes, I decide not to, and hit cancel. I go back to View mode.
As a customer, I go to edit mode to make changes, I make a change, but I don't like it, I hit cancel. I go back to View mode.
As a customer, I go to edit mode to make changes, I make a change, I like the change, I hit save and return. I go back to View mode.
As a customer, I go to edit mode to make changes, I make a change, I like the change, I hit save. I want to keep making changes, I stay in Edit mode.

It starts to become fringe for us to support unsaved changes, while allowing a customer to navigate back to View mode. The trade-off here is flexibility for the customer vs complexity for the customer to be aware of (i.e. they go back to Edit mode and discover previous edits, that would be surprising to many I would guess).

Happy to chat about this further, there is likely other context that I am not aware of.

[ThomThomson]

The reason this difference exists in the first place is mostly technical. The edit mode is stored in the URL, so the user can change it simply by using the back and forward browser buttons. Fully discarding any unsaved changes shouldn't be done without a warning / confirmation, and it would introduce design challenges to show a modal when the back button is pressed, and then potentially stop the navigation.

I agree that if a user has decided to 'cancel' out of edit mode, they are more than likely looking to discard the changes. Perhaps switching the default call to action on the modal from Keep changes to Discard changes would be sufficient to allow the flexibility of seeing the last saved state without losing your changes (and keeping the implementation simpler) while avoiding the complexity of having to remember that canceling out doesn't always discard.

As a customer, I go to edit mode to make changes, I make a change, I like the change, I hit save. I want to keep making changes, I stay in Edit mode.

This is actually a different, but equally interesting discussion. I can see this being true, but it currently does not work that way. Saving will always boot you out of edit mode, though it is trivial to get back in.

[ryankeairns]

+1 to keeping the conversation alive post merge. There are some things we've learned to live with here that are atypical / could be improved upon.

[ThomThomson]

Code is looking great! Tested locally on chrome. I have a few small changes that will help this editing experience align with the others.

1. When creating a new item in Visualize, Lens & Maps, the main CTA button is named save whereas on dashboard it's currently named save as
2. In Maps / Vis / Lens, when editing an existing item, the 'save as' button opens with 'save as new ...` preselected.

Overall, everything works as expected, and the quicksave is an awesome addition. This will help us make 7.12.0 feel vastly different / better!

[cqliu1]

@ThomThomson I updated the label when creating a new dashboard.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: b49ff61

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
dashboard	177.6KB	178.4KB	+866.0B

History

• 💛 Build #105769 was flaky d015cd9
• 💛 Build #105411 was flaky d3168ba
• 💔 Build #105358 failed 8e5878f
• 💔 Build #105018 failed ae7ac2c
• 💔 Build #105004 failed 1808abd

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kmartastic]

though it is trivial to get back in

I appreciate that -- and yes, move your mouse and click Edit again is trivial.
To the customer, it's unnecessary, if not annoying, and potentially... an example of a poorly designed product.

Let's continue the discussion.

[ThomThomson]

You're absolutely right. If you look at other products, saving doesn't boot you out of edit mode, and we should try to be as consistent with the wider ecosystem as possible. I think a meeting would be ideal for us all to talk through the behaviour of all the dashboard top nav buttons, and settle on all of the improvements that need to be made, as well as a time frame for these changes.

Dashboard is meant to be the easier / more out of the box presentation tool, so it's important that we make it as intuitive as possible.