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

[Lens] Explore responsive layout enhancements in smaller viewport widths #134377

Closed
Tracked by #184459
MichaelMarcialis opened this issue Jun 14, 2022 · 16 comments
Closed
Tracked by #184459
Assignees
Labels
enhancement New value added to drive a business result Feature:Lens 🧊 iceboxed impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@MichaelMarcialis
Copy link
Contributor

In a recent discussion with @m-adams, we were notified that he found the Lens layout difficult to understand and use at smaller viewport widths. Issues mentioned include the following:

  • The scrollable field list first appeared as if it was cut-off/incomplete when appearing above the visualization workspace.
  • Even though scrollable, the field list felt like it could be longer and show more fields before requiring the user to scroll.
  • The initially empty workspace looks odd when appearing after the field list. It causes the workspace to look like empty space that cannot be interacted with.
  • The visualization type selector (and subsequent sibling toolbar menus) is easily lost (i.e. not discoverable) when underneath the field list.

image

I believe some design exploration can be performed to potentially improve and alleviate some of these concerns, including:

  • Reorder the workspace to appear first at smaller viewport widths. This may make it more obvious that this is where fields can be dropped onto and where visualizations will be rendered. It will also move the visualization type selector back to the top of the app, making it more discoverable.
  • Explore positioning the field list next to the layers list before going full width with all sections. The may gain us another breakpoint at which the app doesn't require full-page scrolling, making it easier to use the drag-and-drop features and avoid hiding elements of the UI behind a page scroll.
@MichaelMarcialis MichaelMarcialis added enhancement New value added to drive a business result Team:Visualizations Visualization editors, elastic-charts and infrastructure Feature:Lens labels Jun 14, 2022
@MichaelMarcialis MichaelMarcialis self-assigned this Jun 14, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

@flash1293
Copy link
Contributor

@MichaelMarcialis just to make sure I got this correctly - are these the layouts you imagine?
Untitled drawing (2)

If yes, I have a question:

Since this issue was created, the data view picker was moved into the unified search header. Moving the field list below the chart preview would split it from the data view picker - is this a problem? Here you can see what I mean - the data view picker is shown as the very first thing
Screenshot 2022-09-06 at 09 50 42

Actually I would like to suggest a different layout. The field list is not strictly necessary for a functional Lens interface - it's just a shortcut to get fields, but you can do everything from within the layer menu in the same way. So what about omitting the field list on smaller screens? This is what we would end up with:
Untitled drawing (4)

The rationale is that a tool like Lens isn't often used on small screens, but if it is used it's to make small adjustments to existing charts (Scenario like "someone noticed a configuration issue on a dashboard while checking an alert on the train and wants to correct it right away"), so the field list is not really required (and it's next to impossible to use effectively on a phone screen anyway)

What do you think?

@m-adams
Copy link

m-adams commented Sep 6, 2022

just to throw in omy 2c There is a difference between "small screens" and these layouts. When I hit some of the layout issues it was simply:

  1. Large 5k monitor
  2. Reduced resolution/increased text size which may impact (I'm not sure how the scaled settings affect the resolution on Macs)
  3. Multi tasking so using a window using only 1/3 to 1/2 of the screen

So you can hit some of these issues when not working on a phone or tablet.

Personally, in the screenshot I took, it wasn't so much the layout overall as it not being clear what was going on. If we are assuming Lens is being used by a novice then I guess we want to either guide them to pick a field first (maybe there could be a smaller field picker or just a field search) as the starting point of their analysis.
I always thought the flow was field picker to get to a course/basic viz, then the layer panel as "advanced settings"

@flash1293
Copy link
Contributor

Valid points, what do you think @MichaelMarcialis ? Is this worth a more detailed design phase?

@MichaelMarcialis
Copy link
Contributor Author

Since this issue was created, the data view picker was moved into the unified search header. Moving the field list below the chart preview would split it from the data view picker - is this a problem?

Yes, my original layout adjustment proposal would no longer make sense, given that data view selection was moved out of the field list section and is now part of the unified search header.

I like the idea of offering an alternative, condensed means of searching for fields and applying fields to your visualization. I do think it's worth a more formal design phase, but it's something we'll have to prioritize against competing design tasks. Probably worth discussing in our next planning sessions.

@yiyangliu9286
Copy link

Actually I would like to suggest a different layout. The field list is not strictly necessary for a functional Lens interface - it's just a shortcut to get fields, but you can do everything from within the layer menu in the same way. So what about omitting the field list on smaller screens? This is what we would end up with: Untitled drawing (4)

The rationale is that a tool like Lens isn't often used on small screens, but if it is used it's to make small adjustments to existing charts (Scenario like "someone noticed a configuration issue on a dashboard while checking an alert on the train and wants to correct it right away"), so the field list is not really required (and it's next to impossible to use effectively on a phone screen anyway)

What do you think?

I did some design explorations based on what you've suggested here @flash1293 in terms of limiting or omitting the field list when Lens page is in the narrow and vary narrow breakpoints. I also explored an option to keep the field list by collapsing it when the page width becomes narrower. Here are different options and breakpoints in design (figma link):

  • Breakpoint 1 - narrow (with vs. without field list)

Screen Shot 2022-10-27 at 4 19 26 PM

  • Breakpoint 2 - very narrow (with vs. without field list)

Screen Shot 2022-10-27 at 4 19 34 PM

@flash1293
Copy link
Contributor

Two comments:

  • The "Records" thing is part of the field list, so we should definitely show/hide it with the rest
  • I like the idea of showing the field list in a collapsed state by default on small screens

@MichaelMarcialis
Copy link
Contributor Author

MichaelMarcialis commented Oct 31, 2022

Thanks for putting this together, @yiyangliu9286! I've added a handful of comments to your Figma document. Ultimately, I'm personally leaning more towards your "Without Field List" direction. I think simplifying the interface this way largely make sense for an experience on smaller viewports.

The only real concern I have with that approach is that it requires users to scroll past the fairly large (and potentially empty) workspace before getting to the area that they can begin to configure their visualizations (i.e. the layers). Would it be a better experience to have layers appear before the workspace if we decide to proceed with this direction?

Alternatively, maybe it would be preferable to split the configuration and viewing experiences at these smaller viewport sizes? For example, on smaller viewport sizes, perhaps we switch the layout to have two views/tabs for users to select from: layer configuration and visualization preview. That way users are not having to constantly scroll up and down between sections, but can instead toggle quickly between views depending on what they are attempting to do (configure or preview). Thoughts?

@jughosta
Copy link
Contributor

jughosta commented Nov 1, 2022

Hi! On Discover page we have a different solution for mobile view: field list is presented as a button, once pressed it opens a flyout. Would be great if we could find a generic way of showing field list on any Kibana page in mobile view.

Nov-01-2022 18-34-43

@flash1293
Copy link
Contributor

Great point @jughosta - unifying Lens and Discover would be awesome!

@yiyangliu9286
Copy link

yiyangliu9286 commented Nov 9, 2022

Thanks for these suggestions @jughosta! I explored the possibility to align Field list Flyout into Lens, and also @MichaelMarcialis idea about making responsive view as two tabs for users to switch from "Layer configuration" and "Visualization preview" for better responsive viewing / selection experience, here is a zoom video of how the responsive view in narrow may look like (with Field list Flyout and the 2 tabs):

Screen.Recording.2022-11-08.at.10.34.00.PM.mov

For the smallest viewpoint, maybe we could:

  • simply the empty state visual
  • using hover tooltip to explain visualization selector + axis configuration options (because of the limited horizontal real estate)

Screen Shot 2022-11-08 at 10 29 13 PM

Let me know what you think on these suggestions.

@flash1293
Copy link
Contributor

flash1293 commented Nov 9, 2022

Why are the fields not available on the "Layer configuration" tab? I think they would be helpful there as well. Besides that I like tabs for this use case (should probably default to visualize preview but that's a detail). Unifying how fields work on mobile across Discover and Lens is perfect. Visually there's a lot of blue with these tabs, maybe they should be a more greyish color (just a subjective observation, I'm sure there are rules around this)?

@MichaelMarcialis
Copy link
Contributor Author

I'm really liking the direction this is headed, @yiyangliu9286! Well done. Using Discover's "Fields" button pattern makes sense. I also like the addition of the tooltip to indicate the currently selected visualization when the button text is removed at the small breakpoint. Here's a few quick comments that came to mind when reviewing:

  • As @flash1293 mentioned, I think the "Fields" button will need to be present in both layer and visualization views.

  • Similarly, the global visualization selector should likely also be shown in both layer and visualization views. Given that, it may also make sense to show the remainder of the toolbar's contents in both views (i.e. the various visualization option, warning count, "Apply changes" button).

  • I agree with @flash1293 that there's a lot of blue colored buttons on display in close proximity to each another (between the "Fields" button, layer/visualization button group, "Apply changes" button). It would be good to break this up a bit. One possible direction to explore might be to try using EuiTabs instead of EuiButtonGroup for the layer/visualization view selection.

  • Do you feel that tabbed layer/visualization view approach works at both the medium and small breakpoints? I only ask because it looks at though there may be a fair amount of horizontal real estate available at the medium breakpoint in your screenshots (which can make the layers feel overly wide at full width). Any thoughts on whether it would be viable to explore implementing the view tabs only at the small breakpoint (and showing both visualization and layers side-by-side at the medium breakpoint)?

  • For the empty workspace at these smaller viewport sizes, could we change the "Select from fields or layer list to start" text to something like "Add a field or configure layers to render a visualization"?

  • Also for the empty workspace at these smaller viewport sizes, is there a viable Elastic illustration we could use instead of an icon (for the sake of consistency with the empty workspace at larger viewport sizes)? A library of Elastic illustrations from our brand designers can be found in Figma, in case you wanted to browse them.

@yiyangliu9286
Copy link

yiyangliu9286 commented Nov 29, 2022

@flash1293 @MichaelMarcialis Thanks so much for the feedback, those are really helpful, very appreciated it.

Here are the updates for medium breakpoint (side-by-side view) and small breakpoint (tabs view). The following points are the updates in reflecting to the feedback (figma, prototypes).

  • Default to "Visualize preview" in small breakpoint (tabs view).
  • "Fields" button presents in both layer and visualization views.
  • Same with the global visualization selector, it is shown in both layer and visualization views (showing all toolbar's contents in both views incl. the various visualization option, warning count, "Apply changes" button).
  • Using EuiTabs for small breakpoint (tabs view) to avoid overly used blue colour within the same breakpoint view.
  • Exploring using side-by-side view for medium breakpoint (allowing "Visualize preview" to have more horizontal real estate than "Layer configuration“ because it visually needs more space).
  • Update empty workspace content to "Add a field or configure layers to render a visualization".
  • Update empty workspace illustration to the original one (same as in product), for consistent, and I also think there's enough real estate to use this illustration for small breakpoint.

Medium breakpoint: side-by-side view
https://user-images.githubusercontent.com/81987435/204593170-ee02a20a-683e-4970-b358-d9b214cbcdda.mov

Small breakpoint: tabs view
https://user-images.githubusercontent.com/81987435/204593303-a01b85f9-0ca0-4887-b751-c1f5cc9bf86a.mov

@MichaelMarcialis
Copy link
Contributor Author

Wow, these updates look great! Well done, @yiyangliu9286! I will give them a closer look and add any comments I have to your Figma document.

@stratoula stratoula added the impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. label Jan 4, 2023
@stratoula stratoula added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. and removed impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. labels Jun 1, 2023
@markov00
Copy link
Member

In order to provide better transparency of priorities, issues that will not be prioritized within the next 24 months are being closed.

Tracking request in Lens general improvements ice box #184459

@markov00 markov00 closed this as not planned Won't fix, can't repro, duplicate, stale May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Lens 🧊 iceboxed impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

8 participants