Project: Time to visualize

[AlonaNadler]

Background: One of Kibana’s unique advantages is its ability to combine multiple visualizations into a single dashboard and allow users to interact with the visualizations in a quick and smooth way, showing how all the panels focus on the area the user is interested in.

Building the first dashboard and seeing live data with high-quality interactivity is one of the first “wow” moments users experience when they start using Kibana, and how Kibana increased its user base over the years. The “wow” moment is the moment when new users first realize the value in Kibana, which later can evolve into Canvas, Solutions and more of the Elastic offering.

Challenges with creating dashboards :

• The experience requires the users to move between different Kibana apps
• Users need to explicitly choose to create a dashboard instead of being gradually introduced to this powerful capability when starting to visualize data.
• Users need to save the changes in multiple steps or risk losing their work (save each visualization, save after adding or changing visualizations or dashboard)
• Every panel in a dashboard is saved as an independent visualization whether they need it for that purpose or not:
• Saving each visualization as an independent/public visualization risks that another user might delete that visualization, not knowing it’s part of an important dashboard.
• Saving each visualization creates a massive amount of objects in Kibana instances which creates complexity to manage and navigate.
• At the moment when new users start exploring Kibana, they tend to get lost in the various applications kibana provides. There is no clear path to visualizing data and creating a dashboard. Simplifying this flow cuts down on the cognitive load.

Goals:

• Get users quicker to experience the value of a Kibana dashboard. Allow users to immediately start visualizing their data without the need to make many configuration choices, move between different applications, and save multiple visualizations with meaningful names.
• Gradually introduce users to more capabilities and the benefits of dashboards.
• Easier UI/UX experience when creating a dashboard - fewer clicks to visualizing data and creating dashboards:
  • Straightforward flow
  • Intuitive flow
• Optimize to encourage users to create dashboards - Dashboards are a differentiating aspect of Kibana.

Simplified suggestion:

One of the challenges in this project is the object reference model, which raises a bigger and more complex question of whether we want to change it. This question introduces invasive changes that require migration plans and further details.

The suggestions below are an attempt to come up with an approach that will be feasible in the short term and still allow us in the future to take a larger technical decision if we choose to.

Current empty dashboard

First phase: COMPLETED

• [x] Optimize the creation of visualization from the dashboard
• [x] Show the first panel on a large screen for those who don’t come explicitly with the goal of creating a dashboard
• [x] Steps 1.5: By selecting “Create new” Lens will be open (reduce the friction, less decision on chart type and index pattern to immediately land in Lens and start visualizing)

Second phase: In progress

• [x] Change the “Visualize” application name to “Visualization Library”. (https://github.com/elastic/kibana/issues/62834)
• [x] Move “Visualization Library” to the bottom of the navigation next (below or inside) the Management application.
• [x] Move the “Dashboard” application to be on the top of the navigation instead of Discover.
• [x] Any visualization created in the dashboard will only be part of the dashboard and will not be added to the “Visualization Library” https://github.com/elastic/kibana/issues/59645, https://github.com/elastic/kibana/issues/52682: Tracked in https://github.com/elastic/kibana-team/issues/231
• [x] Users who want to reuse specific visualization in multiple dashboards can add the visualization to the “Visualization Library” or add visualization to their dashboard from “Visualization library”
• [x] All existing visualization will be added to the “Visualization Library” - no migration plans or massive changes to existing customers’ objects.
• [x] Allowing to duplicate/clone a panel from the dashboard
• [x] Visible create new visualization when the dashboard is not empty

Third phase: improving existing dashboard editing

• [x] Any panel added will be saved automatically, no need to save frequently or lose panels since they were not saved.
• [x] Adding callout on the Kibana home page, “start visualizing/exploring your data”, which land users in a new dashboard, ready to start visualizing.
• [x] Adding input control from the dashboard, not as a chart type.

Other changes which can be considered in the future:

• Adding an organic editing module inside for creating/editing visualization inside the dashboard.
• Consider introducing the concept of the empty panel with a call to action in Canvas workpads, for quickly getting started similar to a dashboard
• Change the dashboard application name. Often times people don’t know ahead of time they want/need a dashboard, it is a progression after creating the first visualization to create another visualization explore them on the same screen. Dashboard is a name with intent which alludes to the creation of a dashboard instead of visualizing data or exploring data.

@majagrubic @timroes @rayafratkina @ryankeairns

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

@AlonaNadler Could you please clarify how this relates to https://github.com/elastic/kibana/issues/35334 and how those are different from each other in which parts, or close one of them if they are not meant to represent different topics?

[AlonaNadler]

Done @timroes

[stacey-gammon]

related:

• https://github.com/elastic/kibana/issues/52682 (embeddables/lens visualizations "by value" instead of by reference)
• https://github.com/elastic/kibana/issues/53335 "make it slow" efforts via search collectors will have an issue with the 'by reference' visualizations in that saved edits will cause the searches to no longer use the cached/background versions.

[AlonaNadler]

Next steps fo time to visualize:

• @majagrubic will start working on hiding/embedding visualizations in a dashboard in order to keep them hidden and not listed in Visualize listing page + removing the saving popup between visualizing and the dashboard

• Input control will be moved to the dashboard instead of Visualize

• Input control meta issue: Add items we want to improve in control. Add design changes we need @ryankeairns @AlonaNadler

• Title of visualizations:

  • No module requiring saving and naming when moving from visualizing to dashboard
  • If there is no name to a visualization, the dashboard will not use the space on reading mode and the title will be blank
  • On edit mode - emphasize the ability to add title, reevaluate how we change the titles @ryankeairns
  • Need mock to add a panel to the visualize library @ryankeairns

• Toolbar issue -https://github.com/elastic/kibana/issues/46341 :

  • Alona to add more items (image, URL etc..)
  • @ryankeairns provide the updated design

[ryankeairns]

7.7 enhancements

• [x] Remove save modal for Dashboard → Visualize → Dashboard flow
• [x] Emphasize 'Add title' in Dashboard edit more (don't use space in read mode)
• [x] Add visualization to library (no longer included by default)

7.7+ enhancements

• [ ] Move input control from Visualize to Dashboard
• [ ] Move text embed from Visualize to Dashboard (use enhanced Markdown editor)
• [ ] ^^ Incorporate native Dashboard elements into UI (vs using panels)

Prototype / mockups

This is a 'live' link that will contain the latest updates as items are checked off (above) and feedback is addressed. 👁 https://www.figma.com/file/EwodWYRUIjbNvYoi9G4Hnh/Lensboard?node-id=611%3A0

Providing feedback

There are two ways to provide feedback:

1. Add comments on the mockup
2. Add comments to this issue

The former will be less transparent and is best reserved for smaller, well-defined change requests. The latter is generally better for all other feedback as it generates more discussion and shared context. When in doubt, comment here.

[ryankeairns]

^^ Initial designs for the 7.7 enhancements have been added to the prototype. Please provide any feedback; see notes regarding how to do so in my previous comment.

In particular I'm looking for feedback on:

1. Using the existing panel hover design (yellow bar in edit mode) to indicate the ability to add a title. Showing the 'Add title' placeholder text on hover/focus means the user won't see this text repeated on all title-less panels while in edit mode. It also leverages existing UI with the assumption this may save some development effort. The title can still be added via the actions panel.

2. Adding to point 1, it might be helpful to make the placeholder 'Add title' text clickable so that you can open the 'Customize panel' modal directly. If that is technically challenging, then we can simply rely on the existing 'Customize panel' link in the actions panel and re-word the placeholder text.

3. Maja noted in a previous conversation that we may need to add a Cancel menu item in Visualize so that users have a way back to the Dashboard when they decide to abandon their visualization. This seems like a necessity, just pointing it out since it may not an obvious addition at first glance (see the 'Cancel' menu item in screenshot below).

4. The 'Add to library' feature introduces a new concept; however, the design here is intentionally subtle in this iteration. Keeping in mind the impetus for this change (reducing the volume of items in the Visualize list/flyout), it seems logical to not visually over-emphasize this capability. Given that assumption, I've opted to slot this under the 'Share' menu item in Visualize.

5. You can also find the 'Add to library' feature listed in the panel actions menu when in Dashboard edit mode. This strikes me as an intuitive, second location for this link though I'm uncertain how complex this might be.

Additional questions and considerations

• As discussed, the 'Save visualization' modal should likely remain as-is when a user enters Visualize directly and clicks on 'Save'. This is not in the prototype, but assumed to be the case.
• When adding a title-less Visualization to the library, should we prompt the user for a title? Adding a visualization to the library without a title feels like a situation we should avoid. It would not only look odd in the listing, but it would be incredibly difficult to find that item.

I'm happy to walk through this over zoom if people feel that would be helpful.

cc:/ @timroes @AlonaNadler @majagrubic @rayafratkina

[ryankeairns]

The mockups have been updated to address the latest feedback:

• Remove the hover-to-edit interaction in favor of using the existing 'Customize panel' feature
• Refer to 'library' as 'Visualize library' (updated all references)
• Prompt to add title prior to adding to Visualize library (if title does not exist)
• Show [No title] (when you return from the 'autosave' flow)

👉 Link to Figma prototype for Autosave

[ryankeairns]

An issue was brought up in #59134 regarding the use case where a user removes a panel from a dashboard and that panel contains/displays an object that does not live in the library. In that case, a user may want to use that object again in the future, but it would seemingly become inaccessible as it would not display in the visualizations list.

I commented on that PR that it might be handled via a modal, as follows:

Perhaps we could do something like show a modal confirmation to confirm the deletion with an alternative action being to add it to the Visualization library for future use.

So the modal might read: "Removing this panel will permanently delete this object since it does not exist in the Visualization library. If you would like to save it for future use, then you can add it the library now."

With button actions like: Cancel | Add to library | Delete permanently

I can mock this up later if we like this route.

[AlonaNadler]

Yes indeed when a visualization created in a dashboard is deleted unless it was explicitly added to the visualization library it will be gone. I think we can live with that. Few things:

• It might be good to add a popup that explains that.
• will browser undo help if someone deleted and change their mind ?

[majagrubic]

I like the solution of making a popup prompting the user to save it to visualize. Do you think we should also add "Remember for future" option, as ideally we don't want this to show up every time the users need to delete something?

Yes, undo could work same as it does now.

[ryankeairns]

I don't think the remember is necessary, but it might be convenient. In other words, having a confirmation dialog when deleting something feels like a good practice, generally speaking.

[rayafratkina]

It seems there are 2 models for the Visualization library 1. Reusable component model When user wants to reuse a visualization they created for a dashboard, they can save it to the library. That means visualization becomes a separate object and we switch the dashboard to embedding by reference. Any other dashboards using the library vis will be embeding by reference as well. So if visualization in the library is edited, all places using it are updated. When deleting something from the library, the shared object will be removed and all dashboards using it will get a copy included by value.

2. Template model When user wants to reuse a visualization they created for a dashboard, they can save it to the library. This action creates a visualization object but does not change anything on the dashboard. In the future users can create their own copies of the visualization from the library. Changing the library vis does not change any of the dashboards. Deleting the library vis does not affect the dashboards.

[AlonaNadler]

1. Reusable component model When user wants to reuse a visualization they created for a dashboard, they can save it to the library. That means visualization becomes a separate object and we switch the dashboard to embedding by reference. Any other dashboards using the library vis will be embeding by reference as well. So if visualization in the library is edited, all places using it are updated. When deleting something from the library, the shared object will be removed and all dashboards using it will get a copy included by value.

Option1 is how I think this should behave. Right now users can use specific visualization in multiple dashboards. When they change the visualization it applies in all the dashboards this visualization appears on. We do want to preserve and still allow this behavior. The big change is that it is not the default anymore. Meaning in the past everything was saved in Visualize and used by reference. However, users don't need it for most visualizations and it created lists of thousands of visualizations that companies need to manage. With the new dashboard behavior, by default, every panel added from a dashboard is strictly tied to that dashboard, unless users decide to explicitly add that to the library. If a panel is added to a library it is used as a reference and can be used in multiple dashboards

[rayafratkina]

Starting to think through the rollout of the Visualize library phase, I think we want to take a bit of extra care with user experience of the whole switch. This includes

• Promote the new experience https://github.com/elastic/kibana/issues/66445
• Do some user testing before release?
• Review telemetry requirements https://github.com/elastic/kibana/issues/61663
• Plan a documentation update

[ryankeairns]

@rayafratkina The UX Labs team, with assistance from Customer Experience, has built a pool of ~200 current customers who are willing to provide feedback. I can reach out to several people for some feedback once we have something to show them.

In the spirit of discovering issues early (when they're cheaper to fix), I can arrange a round of tests (3-5 to start) via a Figma prototype. Others are welcome to attend (or wait for recordings) and we can collaborate on the test script to insure we're hitting the right portions of this UX.

I have some test scripts which can be used as a template. I'll update one and circulate for feedback prior to scheduling any sessions.

[ThomThomson]

Updates on Phase 2 will continue to be tracked in https://github.com/elastic/kibana-team/issues/231

[ThomThomson]

Closing this meta issue because the project is finished!