[Proposal] VisBuilder - Drag & Drop Visualization CX

[ahopp]

Problem Statement

Today, visualization and exploration in OpenSearch Dashboard is harder than it needs to be. Users need to preselect both the chart type and index pattern they will use to create a visualization. Additionally, users may need to navigate between multiple screens (e.g. discovery → visualize → discover → visualize, etc.) to find the right feature, the right chart, and the right index to include in their dashboard. Not only is this more work then it needs to be, it prevents the serendipitous discovery that more accessible exploration allows.

Proposal

Our proposal is to allow users of OpenSearch Dashboards to create data visualizations and gather insights without preselecting the visualization output and with the flexibility to change visualization types and index patterns on the fly. Users would be able to switch visualization types, index patterns, and data fields quickly and easily in a simple Drag & Drop experience. More specifically, we are proposing a number of key features for OpenSearch Dashboard Drag & Drop:

• Users can create visualizations by dragging a data feature or field and dropping them on the visualization canvas.
• Users can change the data features and the visualization within the Drag & Drop CX. Eventually this will also include the index pattern.
• Users will be able to see suggested visualization based on the selected data features.

The Drag & Drop experience we're proposing would be created as a first party plugin (i.e. within the OpenSearch Dashboards repo and part of the default Dashboard experience) and accessible via the “New Visualization” option within the Visualize page (example below).

Once Drag & Drop is selected, the UI will primarily consist of a column layout as seen in the example wireframe below: a data panel, a visualization config panel, and the visualization canvas.

1. Data panel: The data panel will feature an index pattern selector, a search bar to filter all the fields available within the index pattern for the given Top Nav filters, and the index pattern fields broadly subdivided (e.g. categorical fields, numeric fields and meta fields). Each field, when clicked, will show us a summary of the data in the field, similar to the discovery experience. There will also be a button within each field to add the field to the canvas if the user prefers. Lastly, the index pattern can be changed from a drop down at the top of this section.
2. Visualization Config Panel: This section has a visualization selector that will default based on feature inputs, but whose chart type can be changed at any time. The section will also display the different axis and breakdowns that the chart type supports and also the options to modify the styles of the visualization (e.g. the legend, labels and orientation). To add fields directly into the axes for the visualization without drag and drop, there will be an option within each axis to add a field from the valid available fields. Each field also has an icon to indicate the datatype of the field.
3. Visualization Canvas: If a user drags a data feature over the visualization canvas it will be highlighted signaling that it can be dropped. Once a user drops the feature into the visualization canvas, a default visualization will be created. Like the existing visualize experience, users can also click directly on visualization elements to modify where possible.

In addition to the primary sections, we are proposing the following additional changes;

1. Suggestions: Once a user has feature inputs, either in the config panel or the canvas, they will be able to see suggest visualizations in the suggestions panel. These suggestions can be selected to change the visualization automatically.
2. Top Nav: This section will be similar to the top navigation on the current visualize page with an extra button to add the visualization directly to a preferred dashboard.

Assumptions

1. Development will be incremental (e.g. progress not perfection). We should first build the core Drag & Drop experience as outline above, get community feedback, and then increment new scope and capabilities (e.g. new visualization types, multi-index selecting, etc.).
2. Like the current visualize experience, a Drag & Drop user should be able to perform all applicable visualization actions such as;
   1. Filter by selecting fields (or via “Add filter”) and filter by time/dates.
   2. Apply, or change, aggregation metrics on the visualization such as minimum, maximum, or average.
   3. View available fields with field types, search for field names, and filter by type.
3. If a user switches to a visualization that reduces some dimension of the selected data they will see a warning e.g. switching to a pie chart will remove any time dimensions so it would warrant a warning.
4. In this proposal, a user will not be required to use this experience to create visualizations.

Open questions to address

As we work to design this feature, we need to address the following with the help of community feedback:

1. Our goal is to support all field types and chart types in the long-term, but what should we prioritize in the the short-term? Similarly, what are the permutations of field types and aggregations should we prioritize?
2. What is the default behavior or visualization when the first field (of any type) is added to the visualization canvas, an axis, or the breakdown?
3. What happens when a second field (of each type) is added to the canvas that already contains a field (of any type), a chart axis that has an existing field, etc.?
4. What happens when more fields are added to each of the three sections?
5. How do we prioritize the recommended visualization ordering?
6. What features should we prioritize? Based on previous issues (e.g., Drag & Drop visualization creation #379) there are quite a few enhancements we'd like to see. For example;
   • Ability to use all pipeline and bucket aggregations.
   • Ability to place metric aggregations anywhere in the nested aggregation hierarchy.
   • Ability to apply custom calculations/formulas from aggregated results and display them.

Providing feedback

The purpose of this proposal is to introduce our recommendation to enhance the usability of data analytics and visualization capabilities of OpenSearch Dashboards as well as collect feedback from the community. This proposal is meant to cover the high-level proposal and functionality but does not go into implementation details and architecture. Once we get feedback from the community we will publish a more detailed design doc.

For any feedback on the problem statement, the proposal, or any open questions please leave your comments on this issue. Looking forward to your input!

[JacobBrandt]

Answer to some of the questions that I believe should be included in the MVP.

1. Our goal is to support all field types and chart types in the long-term, but what should we prioritize in the the short-term? Similarly, what are the permutations of field types and aggregations should we prioritize?

These are the basic ones to consider short-term with my thoughts on numbered priority.

Chart Types	Metric Aggregations	Bucket Aggregations
1. Metric	1. Count	1. Date histogram
2. Data Table	3. Avg	5. Date range
3. Bar	6. Cardinality	7. Filters
4. Line	4. Max	3. Histogram
5. Area	5. Min	4. Range
6. Pie	2. Sum	6. Significant Terms
	7. Value Count	2. Terms

2. What is the default behavior or visualization when the first field (of any type) is added to the visualization canvas, an axis, or the breakdown?

Depends on field type. There are sensible defaults for most field types.

3. What happens when a second field (of each type) is added to the canvas that already contains a field (of any type), a chart axis that has an existing field, etc.?
4. What happens when more fields are added to each of the three sections?

These depend on various factors. Here's a couple things to think about.

• Potential field type defaults.

Field Type	Default Bucket	Default Metric
Number	Histogram	Sum
Date	Date Histogram
String	Terms

• Visualization charts should have the ability to control dropped actions in both the config panel and canvas

  • For instance, a metric visualization could have various actions depending on the field type that is being dropped. String = split metric by term. Date = Change chart type to (Bar, Line, Area).

• Is Allow index pattern fields to choose a default metric/bucket aggregation #378 implemented? If so, then prefer those defaults first.

• Where is the field dropped at on the canvas? Ideally there should be visual indicators in the canvas dropping area that perform different actions. Also these could be in the visualization config area as well. Again these areas and their actions should be controlled by the charting type.

  • Example actions: Split "buckets" (Slices, bars, lines, etc.), add/change axis, add/change metric, change chart type.

• Look at Dimensions vs Measures in Tableau for some more inspiration.

5. How do we prioritize the recommended visualization ordering?

Is this the Suggestions view that was mentioned? I know Lens does this below its canvas view but it doesn't seem necessary.
It feels duplicative since there is already a switching chart dropdown present in the wireframe. There's other alternatives too, like removing the dropdown and showing a row of icons for the available charting types instead.

6. What features should we prioritize? Based on previous issues (e.g., Drag & Drop visualization creation #379) there are quite a few enhancements we'd like to see.

From that list here's what I would prioritize.

• Use index pattern OR saved search for data source
• Change data source
• See answer to question 1 above for chart types, metrics and buckets. I believe pipelines are too advanced for a MVP.
• Change chart types
• Everything else I mentioned as "Advanced Features" in that other ticket would be added on after a MVP. I could see this being prioritized as.
  • Metric placements in nested buckets
  • Pipelines
  • Custom calculations/formulas
  • Edit request payload
  • Multiple data sources

Additional Information

To ensure that major rework is not needed after an MVP the following features should be kept in mind up front so I'm mentioning them now even though I know you said not to go into implementation details yet 😄 .

Plugins should be able to participate in this new UX.

• Data source abstraction layer. The data source should not be limited to index patterns or saved searches. This abstraction layer provides the ability for plugins to define data sources with their own implementation of data source responsibilities (available fields, how to handle search parameters, how to perform search requests). All output from data sources will be tabulated so that the visualization layer can handle any data source. This abstraction provides endless possibilities for custom data sources managed by plugins which will then be able to use this same drag drop experience.
• Visualization abstraction layer. Available charting types should be determined and created from some sort of visualization factory. Plugins should be able to add or replace charting types in the factory's registry. This abstraction layer provides the ability for plugins to define configuration options for the charting type, how to visually represent data, where droppable areas exist on config panel and visualization canvas.

Table view interaction.

• Seeing the raw data broken down into a table view is useful for understanding how the data was grouped and will assist some of the "Advanced features" I mentioned in the other ticket.
  • Seeing where metrics live in each bucket, adding metrics in
  • Seeing what column names exist to assist custom calculations and formulas
  • Drag columns from the table to canvas to change metrics and buckets

[ahopp]

@JacobBrandt thanks as always! This is awesome input.

RE: chart types prioritization, what do you think about the ordering of Bar, Line, Metric, Data Table, Area, and Pie? While I do see a lot across metric and data table viz options, I think bar and line are table stakes for a drag and drop visualization experience. Otherwise, agree with metric and bucket.

RE: field dropped at on the canvas, yes, the canvas should have some visual cues on where a user can drop the field. For example, the axis space for adding specific fields to a specific axis. And there will be a visualization config - I was thinking at the right of the data panel after the first element is added.

RE: suggestions, your perspective here is something I'm a bit surprised by (that's good!) and makes me think that there might be an opportunity to reduce scope for the first iteration. Specifically, if we drop the requirement for a suggestions panel/view/bar (thing?) and rather added a more visual chart selection (e.g., row of icons, @kgcreative thoughts?) path we could focus on the core CX and determine if and when to incorporate suggestions. I like the idea of using suggestions to improve the output discovery in the future but this approach seems more iterative. @ashwin-pc what are your thoughts? Would this save us some scope?

RE: abstraction layers, good callout.

[JacobBrandt]

chart types prioritization, what do you think about the ordering of Bar, Line, Metric, Data Table, Area, and Pie?

My thoughts on that stemmed from the fact that Metric and Data Table are visualizations that don't require a charting library. Data table also just fits very naturally with how the data structure will most likely be delivered to visualizations. By removing the complexity of working with a charting library these two could quickly flesh out the communication between the two abstraction layers. While that development is going on someone else can determine which charting libraries to use for the more visual charts. However, I understand what you're saying. Depending on team size of this effort and whether or not a charting library has been selected already, I could see bar and line priorities move up or at the very least be worked in tandem with metric and data table.

[ashwin-pc]

@ahopp yes it would. It makes me wonder if we can skip suggestions entirely in the first iteration and bring it in later. I wouldn't eliminate its need entirely though because it does have its benefits.

The suggestion panel doesn't necessarily suggest different chart types, it can also suggest different ways to aggregate fields for the same chart type (e.g. one suggestion could be a metric that just shows the number of records while another could show the metric for median value of the field). This way as we improve the experience we can be smarter about the suggestions based on common use patterns and not be coupled to the chart type selector.

Another important use case for suggestions is to see in realtime what the suggested chart looks like for the data that you are visualizing. This makes it easier to know identify patterns that the user would have otherwise missed.

But if these are not as important for the initial iteration, it can simplify the scope significantly.

[ashwin-pc]

@JacobBrandt Thanks for the detailed comment, especially the additional information. We will definitely keep that in mind to make sure that it is extensible in future.

[JacobBrandt]

@ahopp @ashwin-pc Happy to help. Designing software is my passion.

I do agree that some form of suggestions to users could provide an improved experience. It's definitely something that could come later though in my opinion. Also, I wanted to give some insight into why I'm not really a fan of the suggestion panel Len's has.

The suggestion panel currently in Lens is mostly a waste of space. Len's version for the most part just shows the user what their current measures & dimensions will look like in other chart types. I guess that's neat and can be somewhat helpful.

it can also suggest different ways to aggregate fields for the same chart type (e.g. one suggestion could be a metric that just shows the number of records while another could show the metric for median value of the field). This way as we improve the experience we can be smarter about the suggestions based on common use patterns and not be coupled to the chart type selector.

I agree with you here. Suggesting other ways to view the data has potential for some improved experience for the user. However, I caution the approach of how Kibana did this within Len's. Len's show's you these suggestions as views and thus creates additional requests to Elasticsearch for each suggestion panel. It has to do this so that each panel can show the user what that suggestion would look like. This bolded statement right here is why I'm not a fan. It's making 5-6 additional requests to the cluster when the user is already focused on just the one they are building. It does this every time the user changes something as well. Len's has turned into a sort of suggested dashboard experience of visualizing data instead of a visualization editor. All these extra requests come with a cost and what if the majority of the time the user never interacts with any of the suggestions. Now it's wasting space as well as fetch & query cycles from the cluster.

I think suggestions can have potential, but I don't agree with them automatically making requests to the cluster all the time for what is supposed to be a visualization editor. With that being said I have a counter proposal.

Suggesting visualizations on dashboards when the user wants to add a new visualization. This is where I think the most power of a suggestion like system could have a huge impact. It has tons more data to look at and gather context to provide suggestions based on already created visualizations for this dashboard. I feel like this type of suggestion experience would greatly improve the dashboard workflow because at the end of the day the user is trying to build a dashboard to gather insights not a single visualization.

Hopefully I helped explained why I balked at the idea of the suggestion panel.

[ahopp]

RE: suggestions - Okay, I think we pull the suggestion path for now - let's keep thinking about how we capture the best of suggestion utility in long-term (for instance, maybe we can let the user prompt for suggestion rather than making it automatic or add visualization suggestion to dashboard) but I'm aligned with this direct! Thanks both!

RE: Metric and Data Table - Gotcha, that's helpful @JacobBrandtl! I think we should plan for working them in tandem and then cross than bridge if we come to it.

[ahopp]

Hey folks! We're planning on closing this proposal on Friday (10/25) and opening the design doc on the same. Please comment if you have any questions, thoughts, ideas, etc. regard the drag and drop feature set or any related topics! otherwise, we'll see you in the design doc.