[Dashboard Usability] Unified Dashboard Options

[ThomThomson]

Describe the feature:
Currently, options and settings for dashboard are spread around the application. As part of the Dashboard Usability initiative we should seek to unify them into one pane for ease of editing. These options include:

• Title
• Description
• Tags
• Time restore (Save dashboard with time range)
• Dashboard Options
  • Use margins
  • Show panel titles
  • Sync cursor across panels
  • Sync tooltips across panels
  • Set/change color palette across an entire dashboard Set/change color palette across an entire dashboard #124462
  • Configure legends across an entire dashboard [Dashboard] Configure legends across an entire dashboard #124461
  • Configure axes across an entire dashboard [Dashboard] Configure axes across an entire dashboard #124460
  • Dark mode per dashboard Ability to set dark mode per dashboard rather than only globally within a space. #75081

This will allow dashboard authors to more easily rename their dashboards, and to change settings without opening up the save as panel and accidentally creating a new dashboard.

The existing options top nav menu item should be extended to provide this functionality.

[elasticmachine]

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

[nickpeihl]

Here's an early design mock-up (definitely missing some of the options). The "Options" (maybe this should be "Settings") link on the nav bar opens a flyout showing the settings. This is similar to the new flyout for changing Panel Settings.

However, there is one key difference that I want to get a consensus on. The Dashboard settings flyout does not have a "Save" button. Any changes to the settings in the flyout apply immediately to the dashboard (as the current "Options" do) which puts the dashboard in a dirty state triggering the "Unsaved changes" badge. Persisting the changes simply requires clicking the "Save" button in the Navigation bar.

Also, we currently try to dissuade the user from saving a dashboard when a matching title already exists. The screenshot below shows how we warn the user about a duplicate title, but still allow the user to save, creating the duplicate titled dashboard.

Should we warn the user in the flyout if their new title matches an existing dashboard? If so, when do we perform the duplicate title check? I think there are a few options, but happy to hear more suggestions.

1. Check for duplicate titles on input change (debounce to accomodate user typing). Show the warning in the flyout form using form validation.
2. Check for duplicate titles when focus is lost (such as switching to the description textarea). Show the warning in the flyout form using form validation.
3. Only perform the duplicate title check when the user clicks the "Save" button? Show the warning as an EuiConfirmModal.

Of those options, I'm leaning towards number 3. IMO, this is a very common (but maybe undesirable 🤔) UX pattern. But I would love to get other opinions.

[Heenawter]

Hmmm... I wonder if the lack of a Save button in the flyout is ideal? To me, having two different saving patterns between panel options and Dashboard options could be quite confusing, especially since the flyouts look so similar - I would expect their behaviour to be similar, as well. Users may be cautious to leave the flyout, because they do not realize that their changes are being automatically applied - and it may not be totally obvious how to discard these changes once they do leave the flyout (although this could be mitigated when we finally add the Reset button to the TopNavMenu, since discarding changes by switching to view mode is something users already struggle with).

If we decide to give the Dashboard options flyout a Save button, I personally think going with number 3 for warning about duplicate titles is a pretty good solution - if they click save and their Dashboard has a duplicate title, the warning can take them back to the flyout if they say Cancel, which makes it easy for them to change the title to something unique.

If we continue with the Dashboard options being automatically applied, it might feel a bit awkward to change the title when you find out it is a duplicate... Open the flyout, change some settings, exit the flyout, go to save your changes, find out the title is a duplicate, press cancel on the confirm modal, go back in to the settings flyout, change the title, then click save again. That's a lot of steps! We could include a way to change the title in the confirm modal (as we currently do), which could make the experience a bit smoother... But if we go this route, I'm almost leaning towards something more like number 2 so that they don't have to leave the context of the flyout in order to determine that the title is a duplicate?

[ThomThomson]

The flyout looks great, and very standardized, nice work @nickpeihl! I think the only option it's missing at the moment is store time with dashboard.

In regards to changes applying immediately vs using a save button, I agree with @Heenawter that we should standardize on one approach or the other, rather than having it work differently depending on the context. So far, everything that is in a flyout follows the pattern of apply changes on a button click in the footer, so that's the one I'd prefer standardizing on.

If we did that, we could fire off the duplicate title check when the user hits save and close on the flyout, and if it fails the check, we leave the flyout open.

The one problem I'm starting to see with this pattern is the copy. If we continue using the verbiage ✔️ Save and close, it makes it seem like when you exit the flyout you're actually saving the changes you've made into the Dashboard Saved Object, because we're using the term save. In reality you aren't saving anything until you hit the save button in the top nav. I figure this could be confusing.

@KOTungseth, Is there any precedent for using a word more like apply in these cases? If we can, I'd be interested in standardizing all of these flyouts on the same copy, without using the word save.

[nickpeihl]

We have a Save button already for the Dashboard. I'm concerned that adding another Save button to the flyout would be confusing.

In the Panel settings, the Save button applies the changes to the single panel, but doesn't save the dashboard. So the panel settings are still an ephemeral state and the dashboard has Unsaved changes. But you can move on to another panel and change its settings without saving the dashboard. The panel settings only persist when the entire dashboard is saved.

Also a "Save" or "Apply" button in the flyout means (I presume) the user loses the ability to immediately see the results of changing options like "Show panel titles" or "Use margins between panels". These options would only update on the dashboard if the "Save"/"Apply" button is clicked. If the user doesn't like the results, they have to re-open the flyout again, adding another couple of clicks.

dispatched-changes.mp4

Although, now I realize that is exactly what we do with "Show panel title" in the panel settings. The change isn't applied to the panel until the "Save" button is clicked. 🤔

[ThomThomson]

I forgot about tags! Man that flyout looks so nice with tags!

the user loses the ability to immediately see the results of changing options

We discussed this when creating the Control editor and decided that it didn't make sense to have things change underneath the flyout in response to user action. The flyout feels to users like a separate context, so they expect their clicks to be localized in there until they close the panel.

[Heenawter]

We have a Save button already for the Dashboard. I'm concerned that adding another Save button to the flyout would be confusing.

To get around this with Controls (and it looks like for the panel options as well), we disable the Dashboard Save button in favour of the flyout Save button - I think sticking to this pattern makes the most sense, especially if we don't change things underneath the flyout in response to an action as Devon suggested 👍

[nickpeihl]

Oh, yeah. I forgot that Controls uses pattern. 👍