Closed MichaelMarcialis closed 3 months ago
Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)
@MichaelMarcialis just to make sure I got this correctly - are these the layouts you imagine?
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
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:
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?
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:
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"
Valid points, what do you think @MichaelMarcialis ? Is this worth a more detailed design phase?
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.
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:
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):
Two comments:
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?
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.
Great point @jughosta - unifying Lens and Discover would be awesome!
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):
For the smallest viewpoint, maybe we could:
Let me know what you think on these suggestions.
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)?
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.
@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).
EuiTabs
for small breakpoint (tabs view) to avoid overly used blue colour within the same breakpoint view.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
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.
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 https://github.com/elastic/kibana/issues/184459
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:
I believe some design exploration can be performed to potentially improve and alleviate some of these concerns, including: