Kibana: Group visualization into "experience" groups in the new visualization wizard

[timroes]

We discussed this now in a couple of meetings, that it might be a better idea grouping the visualizations in the new visualization dialog (currently looking as in the screenshot) into more logical groups.

We talked about grouping it potentially into the different "editors" used so that different user-experiences are grouped together. The grouping could be something like the following:

• Lens
• TSVB
• Timelion
• Vega
• Maps
• Aggregation Based
  
  
  
  
  
• Tools
  
  
  
  • Markdown
  
  
  • Input Controls
  
  

This grouping is up for discussion. Also there are some questions if we would want the grouping to be happening within the same screen or cause users to navigate to a separate dialog for it.

@cchaos We'd be very happy for some design input on this.

[cchaos]

@miukimiu Can you take on this issue and help the App team with some mocks?

I've started a Whimsical to help detail the flow/organization and a Figma file for design.

My advice is to leave the split modal as we have now and write generous descriptions on the right hand side detailing what the different options support. Then when the user clicks on the "Advance aggregations" option, open a different modal with both the cart type and data type selector in one.

[miukimiu]

We had a similar issue in Maps "Add layers". We debated creating groups but we felt we would make a few options less discoverable. We ended up putting filters (categories) on top of the options. But I'm sharing just in case you think it makes sense as a solution. Even though I think this issue it's a little bit different because we wanted to make all the layers discoverable and in Lens, we want to prioritize a few options.

@cchaos I like the idea of "Advance aggregations" and prioritize the top applications. I'll finish the mockups.

[AlonaNadler]

Hey I wanted to summarize our needs in the new design
Currently, we have in the list names of editors (Lens, TSVB Vega) next to names of explicit visualizations (which take users to the visualize builder). It is more tempting and well understood to select the explicit charts, which we want to change.

The new design should optimize users to click on Lens as the first priority - Lens will be the editor majority of users of Kibana is using and the go-to place to create visualizations.
Second priority TSVB and last Vega, and maps.
In addition, we discuss in the past grouping together all of visualize builder chart types under aggs based editor (maybe it's a collapsed button that expands it on click) . The idea here is not to show them by default as explicit chart and remove the focus and temptation to select them.
Under aggs based editor, we can also include Timelion

Again the goal is to point people to Lens while also allowing them to choose other editors if they choose

My poor pm attempt to create a wireframe

[rayafratkina]

I really like Alona's proposal, but I think it's useful to make tools easier to find, as Tim proposed. Can we add the 2 "tools" below in a separate section as a short term solution until we re-implement them within Dashboard?

I would also propose more directive language in the descriptions:

• Lens: Drag and drop intuitive way to create multiple types of visualizations. Best option for most visualizations.
• TSVB: Advanced time series editor that allows user to use complex calculations and add annotations.
• Maps: Create all map visualizations using your geo data.
• Vega: Use Vega library to develop new types of visualizations. Requires knowledge of Vega and programming.

[ryankeairns]

+1 for a short-term "tools" solution that can later be removed.

To Raya's point, I am currently working on mocks for adding a toolbar within Dashboard for the direct insertion of text/Markdown and input controls.

[timroes]

Can we add the 2 "tools" below in a separate section as a short term solution until we re-implement them within Dashboard?

I'd be very much for that, since especially them are not requiring index pattern or any aggregation configuration, so it feels kind of weird packing them under "Aggregation based", while you eventually don't configure any aggregations in there (and in case of markdown, even nothing related to data).

[AlonaNadler]

Continuing my wireframing

[miukimiu]

Based on @AlonaNadler wireframe here's the first idea: figma prototype (anyone at elastic can see).

I think the idea for clicking on "aggs based editor" to expand a list will look weird inside a modal. It will make the modal grow with a srollbar. So I opted out to add a small link to "see options".

By clicking the "see options" the users would go to a different screen where all the options would be listed with a description.

I'll be on PTO and I'm back on Agust 24. Please add comments on what you like on this first idea. Also, do we need the filter bar?

[cchaos]

The nice big card selection is a great idea for the initial selection, but there will be a lot more options for aggregation-based charts that I'd recommend going back to the Keypad menu for those.

Also, the bottom area with "Text" and "Controls" don't look enough like they're clickable. They just look like text. Can you work on another solution for those to make them feel like selectable items?

[miukimiu]

@cchaos based on your feedback I updated the figma prototype (anyone at elastic can see):

• For aggregation-based charts, I went back to the keypad menu
• Changed the "Text" and "Controls" titles to blue so they can look like clickable.
• I also updated a few icons: Vega and Markdown

[AlonaNadler]

Thanks @miukimiu that looks good !!
@ryankeairns can you please add it in your dashboard mocks

[cchaos]

I also gave @miukimiu some adhoc feedback including:

• Putting the agg-based option as its own card in the mix
• Attempting to combine the chart type and data selections into one modal for agg-based options

[miukimiu]

Based on @cchaos adhoc feedback I updated the figma prototype (anyone at elastic can see).

I moved the aggregation based to the left side and now it is a card. Also to follow our other getting started cards I added a link to our docs "Want to learn more? Read documentation".

If we click on aggregation based you go to the aggregation based panel. We can use the old design where on hovering we can read the information. Or we can have a card with a small description. With this approach, users won't need to hover the keypad menu to read the description. They can read right away.

But having the aggregation based living on its own panel creates a three steps process. So to attempt to combine the chart type and data selections into one modal we can use a popover. What do you think? Would this work? Or is it better to go to a new panel?

[ryankeairns]

Thanks @miukimiu , one quick observation as I was testing this out in Dashboard prototype... the overall size and scale struck me as being rather large in relation what I'm used to seeing across Kibana. I've been working from a laptop size frame in Figma (1440 x 900) and it looks like this:

I would like for us to consider decreasing the card title and icon size, for example, in order to shorten the overall height of the modal.

[miukimiu]

Thanks for the feedback @ryankeairns. I just updated the sizes: figma prototype (anyone at elastic can see).

[stratoula]

I really like it! I have started working on it but I have some questions that are not so clear to me:

1. How is going to be on OSS (as Lens and Maps won't be displayed). Can we have a wireframe for it too?
2. About aggregation-based content, it's not so clear. Are we going to keep the old implementation with the keypad menu or change it to cards? Is it finalized?

cc @cchaos @miukimiu

[miukimiu]

Hi @stratoula,

1. For OSS we're going to hide the cards for now. They should get the same height as the "aggregation based" card.

1. For the aggregation-based content. We're going to change it to cards:

But once we select a card we go to this screen (same as the old implementation):

Here's the design updated: figma prototype (anyone at elastic can see).

[stratoula]

Thank you @miukimiu! Now it is clear! Will start working on it but may need your help for missing icons etc.

[AlonaNadler]

I think we should have the same design for basic and oss and just disable the Lens and Maps options. That allows us to emphasize the difference between OSS and Basic and help users understand whats missing.
I would even go a step further to link a video that shows what is Lens (in youtube) and what is Maps

cc: @VijayDoshi

[timroes]

Sidenote: we've decided to keep an advanced setting, that will allow a user to revert to the previous dialog for the remainder of 7.x. It's not too much effort maintaining those two different dialogs in the code base, and that way we're following the pattern we also started with the navigation redesign, that especially those well trained users will have a chance (though we're not advertising it in the UI) have a way to revert to the previous design. We'll also collect telemetry data on users enabling that setting to fallback to legacy mode.

[AlonaNadler]

Why @timroes ? what's your concern?

[VijayDoshi]

I think we should have the same design for basic and oss and just disable the Lens and Maps options. That allows us to emphasize the difference between OSS and Basic and help users understand whats missing.

I think we should show disabled Lens and Maps options in OSS with a pointer to content that explains to the user what is missing and an upgrade/trial path. I have a meeting tomorrow where I'll bring this specific issue up for a decision - we are having a broader discussion about OSS differentiation. I'll report back with a recommendation from the team.

[ryankeairns]

@VijayDoshi I am curious on the outcome of that conversation as well. Currently, we have opted to hide this content from the home and overview pages.

cc:/ @alexfrancoeur

[VijayDoshi]

Yes - we would like to have a consistent answer since this is coming up more and more as we pile capabilities into Basic that are not in OSS. An experience where 3/2 of the OSS UX is disabled would suck; at the same time, finding ways to elegantly engage OSS users so they know what they are missing is a win-win - customers get a more capable product and we get more customers.

[VijayDoshi]

FYI - we reached a consensus decision to show Maps and Lens in a disabled state with pointers to a basic license (similar to what happens with CSV upload) in OSS.

We are working on a decision document that outlines more general guidance; however, I didn't want to wait on that to update this issue.

@alexfrancoeur @skearns64 @snide @smayzak

[timroes]

@VijayDoshi Could you clarify on or get some of the tech leads involved on how this will work code wise? We have a separation between x-pack code and OSS code, and in contrast to Basic+ where all the code will always be available (so we can hint towards gold features not enabled in Basic), we don't have the x-pack code at all present when running OSS.

If we decide to do a shift towards wanting to hint from OSS to Basic+ features we need a major shift in how that technology works together, and I don't want to make this on a case-by-case basis, but have a cross Kibana alignment and design on that architecture.

Could you also clarify if this enabling of Lens/Maps in OSS is important enough to block work on this for some minors until we have that general path forward, or if we should go with the currently working solution of not having them shown in OSS?

Why @timroes ? what's your concern?

@AlonaNadler The main concern is, that we're introducing an additional interaction into reaching some of the visualizations that are today the most commonly used ones. We have taken this kind of UX performance regressions rather light-hearted in the past, and trying to take them a bit more serious. Making a major change like that in a minor the question should not be: why are we keeping the legacy solution till the next major and collect telemetry data to quantify the situation better, but rather why are we NOT if we don't - and the answer to that will usually be maintanance costs. But since we don't consider this to involve large maintanance costs, there is no real reason, not to remove legacy support in a major, collecting all the telemetry data we can get until then.

[VijayDoshi]

@timroes We'll have an intentionally very limited number of places where we will want to do this sort of thing; however, we will need to do it. Timing is not prescribed - if we needed to ship as is for 7.10 that's okay.
I'd look to the Tech Leads to figure out what the right path is from a code perspective. We already do this for CSVs - I'd be surprised (or perhaps puzzled) if the team came back and said it's going to take multiple releases for a team build a dialog where we present disabled sections with a tooltip that indicates it is a Basic+ Feature. I must be missing the complexity, can you help me understand the complexity and the performance implications?

This is the sort of approach/pattern I assumed we'd follow.

[AlonaNadler]

@AlonaNadler The main concern is, that we're introducing an additional interaction into reaching some of the visualizations that are today the most commonly used ones. We have taken this kind of UX performance regressions rather light-hearted in the past, and trying to take them a bit more serious. Making a major change like that in a minor the question should not be: why are we keeping the legacy solution till the next major and collect telemetry data to quantify the situation better, but rather why are we NOT if we don't - and the answer to that will usually be maintanance costs. But since we don't consider this to involve large maintanance costs, there is no real reason, not to remove legacy support in a major, collecting all the telemetry data we can get until then.

In the current situation, we consciously decide to promote Lens and TSVB. We already know it's a change in behavior for some users and will require an adjustment. At the same time, we are not removing any functionality.
In the past when we introduced new functionality occasionally we had a setting that allowed users to revert back. This case is different. Kibana decided to promote Lens, TSVB cause we believe users will have a better experience. That is why I don't think we should have a setting to return to old chart selection. To me, this change will be done closer to when Lens is default

[miukimiu]

The Figma prototype is now updated with the modal for OSS: figma prototype (anyone at elastic can see)

[stratoula]

I have a question regarding the space we have on the wizard for promo texts.

I can't see anything like that in the new design so I assume that we don't want this anymore?
cc @AlonaNadler @miukimiu

[ryankeairns]

I have a question regarding the space we have on the wizard for promo texts.

I can't see anything like that in the new design so I assume that we don't want this anymore?

Some anecdotal feedback... I've witnessed a good portion of users miss this button during user testing. Granted, the entire layout has now changed and the keypad might have dominated the previous experience, but I don't think we'd be losing much by removing this button.

Also, we now have far fewer options and Lens is in the first position. In the future, if we find Lens needs more visual weight, then I would propose exploring visual enhancements to that first card.

[stratoula]

I agree, just wanted to be sure. Thanx @ryankeairns 🙂

[stratoula]

After syncing with @miukimiu we are missing an indicator for the controls that are on the experimental stage. So I think it should also be addressed on the wizard

[miukimiu]

@stratoula, I've just updated the prototype with an "experimental" beta badge for the controls.

<EuiBetaBadge iconType="beaker"  tooltipContent="..." />

Regarding the Vega logo, it has some guidelines: https://github.com/vega/logos. On a white background, we should use the colored version. The initial green version that I was using doesn't respect their guidelines so I changed it to the proper version.

Compared with Lens, Maps, and TSVB the colored Vegas logo stands out more. But in my opinion, we should use it as it is. @ryankeairns, what do you think?

[ryankeairns]

@miukimiu While it does follow their brand guidelines, this approach likely puts slightly too much visual emphasis on Vega relative to Lens, in my opinion. I see there was a request to use their official logo, so I suppose this means we want to discontinue using the visVega icon from before...

@AlonaNadler can we get your thoughts on this? If we must continue with the colored Vega logo, then we could consider doing something more bold with the other cards. For example, if we really want to emphasize Lens foremost, then we could fill the card with a background color.

[AlonaNadler]

having only Vega colored logo emphasized it too much. Either all logos are using the same shades or all colored

[ryankeairns]

@miukimiu let me know if you'd like to brainstorm on alternatives. Essentially, we want to make sure that Lens is not superseded, visually, by the other options.

The Vega option strikes me as an advanced tool since it requires Vega/programming experience. One consideration might be to treat it differently than the other three cards. Perhaps, in that way, the logo wouldn't be so prominent.

[alexfrancoeur]

Maybe a discussion for another day, but I've been following this thread and wanted to ask a quick question. We're in the early days of beginning to think through a more consistent approach for this type of promotion between license levels. Is there a call to action with Lens and Maps being disabled here or are only showing a tool tip? If we can't link out, maybe we can provide more context as to how they can "enable" Lens / Maps in the tooltip description?

[miukimiu]

Hi @alexfrancoeur,

This was the consensus mentioned by @VijayDoshi :

FYI - we reached a consensus decision to show Maps and Lens in a disabled state with pointers to a basic license (similar to what happens with CSV upload) in OSS.

So we're only showing a tooltip but it is possible to link out in case it's necessary or provide more context as to how they can "enable" Lens / Maps in the description. This change won't compromise the design.

We're in the early days of beginning to think through a more consistent approach for this type of promotion between license levels.

There was an idea that I started exploring that we can consider for the future. The Lens and Maps cards wouldn't be disabled but with a Basic badge. On clicking the card users navigate to an OSS Lens/Maps landing page (it would seem they navigating to the application).

The landing page would provide more context as to how they can "enable" Lens / Maps and also would give a little sneak peek of what it is. The following page is just an example. We would need to think about what is the right content to show.

I'll leave the prototype here: https://www.figma.com/proto/5tfLgoUL5qpiVdEpw0DImo/%E2%AD%90Visualize-modal?node-id=253%3A88&viewport=200%2C205%2C0.2802675664424896&scaling=min-zoom

[stratoula]

Yesterday @gchaps reviewed the texts and we made some changes:

We would love your feedback on the new texts!

Moreover, she suggested working more on the Aggregation based name. She proposed Classic visualizations. What do you think? I prefer the first one to the second as the word classic might be misleading. But I agree that maybe the aggregation based title is not ideal. @AlonaNadler any thoughts?

Finally, what are we going to do with the vega icon? I have kept the old one as you can see but do we have any updates on it? cc @miukimiu

[AlonaNadler]

I commented here https://github.com/elastic/kibana/pull/79627