[Dashboard] Prompt Visualize users to start with Dashboard

[ryankeairns]

As part of the Time to Dashboard project, we would like to reinforce the new, preferred workflow that starts from Dashboard.

Many existing users are accustom to first navigating to Visualize and creating visualizations. Next, they create a new Dashboard whereupon they add those previously created items. In order to help users re-learn this flow, we are proposing the addition of a callout or toast message within Visualize.

~While we have not settled on a final solution, recent user testing leads me to believe that the toast message would be more effective. That said, it would potentially necessitate a bit more work to manage its state (i.e. when to show it; use of localStorage).

The added benefit of the toast is that it could persist on both the Visualize home and editing screens without affecting the page layout. Technically speaking, the callout could also be made dimissible and have its state stored in localStorage, but it would push things down making for a less desirable layout, even if momentary. ~

Update: Current consideration (October 30)

The thread below has moved in the direction of updating the Save modal. These additional redirection points could be considered separate/future updated after an initial evaluation period for the modal changes. As an aside, the proposed usage of a toast doesn't seem to follow best practices on usage and the callout is likely to be more in line with precedent.

Save modal updates

Clickable Figma prototype

https://www.figma.com/proto/YA02RZlZQ6IQWlyzyiFzZx/Dashboard?node-id=1544%3A64&viewport=1079%2C1471%2C1.1890755891799927&scaling=min-zoom

---

Prior considerations

As an aside, the proposed usage of a toast doesn't seem to follow best practices on usage and the callout is likely to be more in line with precedent.

Sample toast

Sample callout

[elasticmachine]

Pinging @elastic/kibana-canvas (Team:Canvas)

[AlonaNadler]

Toast looks great @ryankeairns

When users start in Visualize and click create visualization
What if we give them 3 options:

[ryankeairns]

Here are a couple of options which could be done separately or together.

Adding a popover to 'Create visualization'

Pros

• Intercepts the user early in the flow
• Places them onto the dashboard-first flow
• Keeps new viz items from getting added to the library (if we can create a dashboard on the fly?)

Cons

• Introduces a stopping point where one did not exist; ad-hoc creators will be most affected
• Adds complexity in logic that might be avoidable (see next alternative); For example, have to hoist user on to dashboard-flow which means adjusting breadcrumbs and the Save button (er, more specifically, creating a dashboard on the fly).

Adding a select input to the Save modal

Pros

• Standalone solution or could be combined with above
• Feels expected at this point in the flow
• Its optional, so it doesn't introduce a stopping point for ad-hoc creators
• This pattern of searching and selecting dashboards could be componentized for use elsewhere
  Cons
• It's later in the flow, so it may be less effective in breaking the Visualize-first pattern. However, it could be coupled with the above solution.

My recommendation would be to start with the latter and see how effective it is. The popover menu might detract from the current UX although, on the other hand, this heavier-handed approach might ultimately get more people on the new flow.

Clickable Figma prototype

https://www.figma.com/proto/YA02RZlZQ6IQWlyzyiFzZx/Dashboard?node-id=1544%3A64&viewport=1079%2C1471%2C1.1890755891799927&scaling=min-zoom

[nreese]

I prefer the "Adding a select input to the Save modal" option. When nudging users towards Dashboard first, Maps should also provide similar UIs as visualize. Adding a select modal is less intrusive and would be a great addition for Maps.

[AlonaNadler]

I think looking at the mocks I agree with Nathan. It might come off a bit aggressive making the users choose their path before they start. maybe when finishing the visualizations we should give them the 3 option:

1. save to a new dashboard -> checkbox that once saved we move the user into the new dashboard
2. Save to existing dashboard - > checkbox that once saved we move the user into the new dashboard
3. add to visualization library -> stay in the visualization

on the other hand. If we go with this approach I'm not sure how much it changes the users' behavior in the long run. They can just continue with their usual path starting from visualize

[ryankeairns]

Let's do this...

• Start with the proposed focus on updating the save modal
• Zhuzh up the visual design of the proposed 'Add to dashboard' section (of the save modal)
• Evaluate its effectiveness and consider (later) the addition of more aggressive means such as the upfront popover menu, if necessary

This feels like a low risk approach that may get us all that we need. Let's also keep in mind that we've since changed the home page, added a Kibana overview page (which does not display Visualize), and (soon) the main menu link text to Visualize Library. Other changes we have up our sleeve are the product tour and changes to the 'Add panel' UX within Dashboard. If we nail that latter UX, then users should want to stay in that Dashboard loop.

We may find that this set of changes does the job. If it does not, then we'll re-evaluate our options and points of contact... of which there are many.

[ryankeairns]

As I re-read @AlonaNadler 's comment, I might have misunderstood the suggestion. If I'm following now, I believe the suggestion was a popover menu on the Save button (similar to what I had proposed on the 'Create visualization' button). With that feedback, plus my response in mind, I've come up with the following alternative which I hope melds our thoughts.

By adding a bit more UI, and thus visual weight (i.e. radio buttons and a scoped down search/select input), we can imply to the user that they should strongly consider adding this new viz to a dashboard.

This approach results in a single, re-used, 'Save' modal whereas a popover menu (on the Save button) would result in varying conditional elements within the form. It's nuanced, but I'm hopeful this is a good balance of visual emphasis along with a relatively less-complex technical approach.

[nreese]

I would keep text as generic as possible so the same modal can be used in Maps. So "No dashboard (add to visualization library only)" should be "No dashboard", or better yet, maybe these should be check boxes and there is no option for "No dashboard". For "No dashboard", users just will not select an option under "Add to dashboard".

[shaunmcgough]

@ryankeairns would it be possible to add another icon (a little plus sign) under the actions column of the Visualization Library screen with the action of opening the same drop-down as the 'Create Visualization' drop-down (expect no 'No Dashboard' option), or is there another way you are thinking of doing this / exists in another issue?

[ThomThomson]

I like the save modal dashboard select design, but I can think of a few small issues:

• This is maybe too much visual noise to give the user right away, especially combined with tagging. You would quickly get into 'scroll bar on a modal' territory which I think we should avoid.
• The default option is still 'save to the visualize library only'.

I think we could use this design with the radio buttons as a standard 'dashboard select' component, but display it as the second step in a 2 step process.

Step 1:
Here, the most emphasized action is 'save to dashboard'. Clicking 'save' would save it to the visualize library only without ever showing you the dashboard selection.

Step 2:
If the user chooses the 'Save to Dashboard' option, it would be much more natural to present them with the dashboard selection in a second modal that replaces the first. The cancel button would return you to the previous modal, and the finish button would finish the save and redirect you to the dashboard if that option is selected.

[ryankeairns]

Great feedback y'all, I'll keep iterating and report back.

[ryankeairns]

Ok, I'm back with some new designs.

Taking into account the feedback above, I think these address the concerns related to:

• modal size (including tagging)
• prominence of the suggestion
• reducing the amount of decision-making/clicking
• arriving at a universal 'widget' that can be shared across applications

First, I want to call out the 'widget' (i.e. shared component) itself. Imagine this being used in any Kibana save modal, where applicable.

If we really want to streamline things, we can consider having it start in the 'on' state with the 'New' dashboard selected (as shown above). This means you could, in theory, supply a title, click Save, and boom you end up on a dashboard.

The pros are that it reduces clicking and lifts you onto the dashboard flow. The question I have is - does it do this too well? Will users be surprised and will we proliferate the number of dashboards in a bad way? Perhaps not, but curious your input.

Aside from the default switch state, I've made an attempt to generalize the copy, and reduce the number of options to two (new or existing).

Note: These mockups are macbook/laptop size; somewhat small, but realistic

Mockups with new widget

Single-wide

I share @ThomThomson 's concern, this thing is getting long and feels untenable

Double-wide

This feels attainable in the short to medium term. Reduces the potential for scrolling, but doesn't leave much room for future growth.

Full house

As part of the tagging design, Michael proposed moving the save modal to a flyout to gain more real estate. It's an interesting thought that potentially requires a significant-ish amount of addtional effort and, as you can see, its not without the potential for scrolling. It does provide potential for growth in terms of steps, etc.

Recommendation

Of this set - and given the timeline - I'm thinking the 'Double-wide' approach gets us where we need to be and seemingly addresses the requirements. It seems like a great candidate to be a shared component across Kibana apps, and we can also circle back to the flyout later (and still re-use this component).

[AlonaNadler]

I like the direction I offer a slight change
We don't want users by default to add to the visualization library unless they explicitly want to.

The default should be add to existing dashboard (will likely be the most common need) with the ability to add to a new dashboard or add to the visualization library if the users are adding to a new or existing dashboard the ability to add tags is not relevant.

Ryan please also add an i next to the visualization library option, we can explain what it is. list of assets that can be used on multiple dashboards or canvas. Use this option if you need the same visualization in multiple dashboards.

[AlonaNadler]

Folks how do you suggest going forward here?

This is the option I think we should go forward with

might be nice to simplify the save menu a bit

cc: @clintandrewhall

[ryankeairns]

@poffdeluxe has started work on the 'Add to dashboard' piece of this modal. Last week was crazy :) , but I did finally start working on your latest feedback this morning @AlonaNadler . The side-by-side approach was the most accommodating for the smaller (laptop) screen sizes.

Poff and Devon also suggested not having the checkbox since it presented additional complexity that could be avoided (i.e. we'd have to handle creating a dashboard and not redirecting to it).

I've also worked in the suggested tooltip and am now showing the Tags input in a disabled state when we're adding to a dashboard (i.e. not adding to the library). We could alternatively hide it, visually, but I wanted to avoid having the modal size jump around as the switch is toggled.

[ryankeairns]

If we want a more explicit 'Add to library' option, then we could remove the switch and add a 3rd radio option

[AlonaNadler]

Perfect @ryankeairns thanks !

I've also worked in the suggested tooltip and am now showing the Tags input in a disabled state when we're adding to a dashboard (i.e. not adding to the library). We could alternatively hide it, visually, but I wanted to avoid having the modal size jump around as the switch is toggled.

I think we should hide the tags when it is not relevant. It is sort of tempting to try to understand what's the library? why don't I have tags? and in general a disruption.

On the radio button, can you please change the order: first radio is the default ( add to existing dashboard), add to new dashboard, add to visualize librarythat order represent what we think users will use more and what we want them to use more

[poffdeluxe]

One other case we'll want to think about (that I don't think is covered above.. lemme know if I missed it): if a visualization is in the visualize library already, what options for adding to a dashboard to we give the user in the save dialog? Perhaps if they're wanting to save an existing visualization to a dashboard in this modal, the "Save as new visualization" would automatically get enabled (and couldn't be disabled) since we'd basically be taking the saved visualization and copying it to the dashboard as a by-value embeddable.

This is something we can mess with though to get right. I'm working on getting a PoC together so we can see how we feel about this flow

[ryankeairns]

Thanks @poffdeluxe , happy to talk through that UX once you're ready.

[ryankeairns]

Updates:

• Changed radio button order
• Tags are hidden when adding to dashboard
• Changed button text to signify that you'll go to Dashboard

cc:/ @gchaps - need some help finalizing the radio button labels. Let me know if you'd like further explanation of the overall situation. Thanks!

[poffdeluxe]

@AlonaNadler @ryankeairns As a part of this issue, are we adding this flow to maps as well? The No dashboard, add to library copy probably doesn't make a lot of sense for maps (until maps are added to the visualization list as described in #82189)

[ryankeairns]

I believe the Maps team would handle that addition once they're ready. cc:/ @nreese

[AlonaNadler]

That is the way I understood that as well

[nreese]

I believe the Maps team would handle that addition once they're ready.

Can you clarify? What do you mean by "handle that addition"?

[ryankeairns]

I believe the Maps team would handle that addition once they're ready.

Can you clarify? What do you mean by "handle that addition"?

@nreese we're referring to enabling the 'Add to dashboard' feature within the save modal.

From what I understand, these apps share the same modal, but I think we were unclear if Maps currently supports the functionality proposed by this issue. Specifically, does Maps yet support the by-value/Library workflow? Once it does, then the 'Add to dashboard' feature could be displayed in the modal which allows those who to start from Maps to be, essentially, redirected to a dashboard with a by-value map.

[nreese]

Specifically, does Maps yet support the by-value/Library workflow?

Yes, maps supports by-value library flow. That was merged with #82486

I will have to look into the 'Add to dashboard' feature for maps save modal.

[poffdeluxe]

Closed by #83140