Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discover] Improve sidebar design #68206

Closed
andreadelrio opened this issue Jun 4, 2020 · 12 comments
Closed

[Discover] Improve sidebar design #68206

andreadelrio opened this issue Jun 4, 2020 · 12 comments
Assignees
Labels
Feature:Discover Discover Application Team:DataDiscovery Discover App Team (Document Explorer, Saved Search, Surrounding documents, Graph) Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.

Comments

@andreadelrio
Copy link
Contributor

Summary

In order to provide users a consistent experience across Kibana, we would like to improve the way we present fields in the left sidebar of Discover. To do so, we will align this feature to what we do in Lens to the extent where it is possible.

Target outcome

Improve the visuals of the Discover sidebar while providing a better experience which is consistent with a similar functionality that already exists in Lens.

demito

Proposed changes - Phase 1

image

  1. Use a popover instead of accordion to display field preview and the “Visualize” button.
  2. Move the “Add” button to inside the popover as “Add as column”. (See no. 2 in “Potential challenges” below)
  3. Use a more refined style of graph.
  4. Use EUI’s plus and minus icons instead of zoom in and zoom out icons to represent “filter in” and “filter out”.
  5. Use a compressed EuiSwitch inside the Filter menu and align copy with Lens.
  6. If possible, allow for the selection of multiple field types from within the Filter menu.

image

Prototypes and mockups

Figma prototype

https://www.figma.com/proto/4b9NHbsHMrJyWV87vMr0PZ/Fields-list?node-id=69%3A3&viewport=122%2C-146%2C0.38255298137664795&scaling=min-zoom (open in Figma desktop app to get images loading properly)

Potential challenges

  1. What about drag and drop?
    As the implementation of this functionality requires engineering resources that might not be available in the near future, we think this functionality could be implemented after Phase 1. For this reason, the styling of Discover and Lens should not be identical so as to not lead the user to believe that drag and drop is available in both applications.

  2. Placing the Add button inside a popover would make it be one additional click away. As an alternative to this, we could keep the Add button to the right of the field name. Note that the one disadvantage of this is that it increases the chances of the field name having to wrap into multiple lines.

image

Phase 2

  1. Drag and drop
  2. Once we have implemented the use of EuiDataGrid in Discover we could get rid of the “Selected fields” section and use EuiDataGrid to remove fields from the table.
@andreadelrio andreadelrio added the Feature:Discover Discover Application label Jun 4, 2020
@cchaos cchaos added Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.9.0 labels Jun 4, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-design (Team:Design)

@elasticmachine
Copy link
Contributor

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

@timroes
Copy link
Contributor

timroes commented Jun 4, 2020

Related around improvements in the sidebar: #68270

@cchaos cchaos removed the v7.9.0 label Jun 4, 2020
@flash1293
Copy link
Contributor

I created an issue for pulling out common components into a central place a while ago, the field list being one of them: #41108

Maybe some of the discussion is relevant for this.

@wylieconlon
Copy link
Contributor

We are also planning on changing the field list in Lens to use an accordion: #67203

@andreadelrio
Copy link
Contributor Author

andreadelrio commented Jun 4, 2020

@rayafratkina
Copy link
Contributor

Thinking about this a bit more, I worry about this direction. In Lens, the primary purpose of the field list is informational - you do not take any action from the field list except dragging fields onto the editor space.

By contrast in Discover users configure data table from the field list. I think we should be careful to keep that in mind in design and make sure actions are not more complex. For example, I think pushing "add" button to select the field for table into a flyout is a mistake - it's always harder to click those.

@mdefazio
Copy link
Contributor

Perhaps we could change the token icon to a plus icon for a quicker add action. It's possible there might be some confusion on the hit area though (does clicking the name add it as a column, or open the popout??). Maybe the popout then also needs to get triggered by an icon?

image

@rayafratkina
Copy link
Contributor

The token icon carries information - it's different depending on the type of the field. But maybe it can change to a plus on hover?

@cchaos
Copy link
Contributor

cchaos commented Jun 12, 2020

To reiterate some of @andreadelrio's thoughts:

We would only move the "Add as column" button to the popover IF we could implement drag and drop to add to add the fields to the table. Otherwise, yes we will still need to implement an "Add" button directly on the field name for quick adding them to the table.

I disagree that there are major differences between the Lens and Discover purposes of the fields list. Both:

  1. Allow you to explore the fields by showing field statistics
  2. Take action on a field by adding them to the content space whether it's the chart or table

The only extra action I see that Discover adds is the ability to "Visualize" which just starts a chart base on that field and not sure how often that is currently used today.


@mdefazio Your idea is intriguing. I think we still need to know that the primary action is for a field. Is it to see the field stats or add it to the table. Whichever it is should be the main click on the whole field item and the secondary option should be a button that appears on hover

@rayafratkina
Copy link
Contributor

Thanks for clarifying @cchaos I think I missed the connection between drag and drop and the design of the list. That part makes sense to me.

To dial into the differences/similarities between Discover and Lens: I agree that those are 2 things user does in both cases, but I think the user's intent and the expectations we set with users are different between these tools. It's not obvious up front that you can add columns to Discover, but in Lens we built the UI around this concept and it is very clear.
How do you see the expectations that user has coming in play into these UI choices? Are you imagining more UI changes in Discover to align with the field list changes?

@kertal
Copy link
Member

kertal commented Jun 15, 2020

@mdefazio Your idea is intriguing. I think we still need to know that the primary action is for a field. Is it to see the field stats or add it to the table. Whichever it is should be the main click on the whole field item and the secondary option should be a button that appears on hover

My 2 cents here: for me the primary action is adding a column, I like the hover/focus change to a plus icon. This is a difference to the current behavior, but I think it it's an improvement. Would be very interesting to have some telemetry here.

@andreadelrio andreadelrio self-assigned this Aug 13, 2020
@timroes timroes added Team:DataDiscovery Discover App Team (Document Explorer, Saved Search, Surrounding documents, Graph) and removed Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Discover Discover Application Team:DataDiscovery Discover App Team (Document Explorer, Saved Search, Surrounding documents, Graph) Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.
Projects
None yet
Development

No branches or pull requests

9 participants