[Maps] layer creation wizard

[nreese]

The existing layer creation wizard has the following problems

1. coupled to source implementations so really Add layer is Add source
2. Growing number of sources is turning menu into a long list for users
3. No good place to add solution layers without exacerbating first 2 issues.

The layer creation wizard needs to be refactored to meet our future needs.
@jsanz and I developed this initial proposal for a 2-level hierarchy that groups layers by tasks.

• Upload data
• Base layers (Reference layers). Layers behind thematic data that provide geospatial context. Non-interactive, no configuration of tooltips or styling control.
  • EMS basemap (hidden when EMS is disabled)
  • Kibana configured basemap (hidden unless configured)
  • TMS
  • WMS
• Custom layers - (Thematic layers). Please suggest better name.
  • EMS boundary (hidden when EMS is disabled)
  • Kibana configured boundary (hidden unless configured)
  • Clusters. Maybe this can be merged with ES documents but want to decouple that conversation from this discussion.
  • ES documents
  • Heat map
  • Point to point
  • Vector tiles
  • Choropleth map that simplifies setting up join
• Observability (includes uptime)
• SEIM
• Workspace search

When providing feedback, please take care to limit the discussion to the layer creation wizard only and not dive into source specific things that we would like changed like combining ES documents and clusters.

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[kindsun]

Looks like a generally good flow, thank you both for this! A few questions/comments:

• I'm guessing Upload Data would segue into Custom Layers similar to how it does now, correct? It will be really nice to have the option of going straight to a Heat Map, Point to Point, etc. rather than defaulting to a doc layer.
• Your comment so really Add layer is Add source is related to the issue we ran into on the first attempt to allow File Upload to add to existing indexes. What we really wanted was the concept of Edit source & update derived layers. This may only be an issue for File Upload and may require a more fleshed out future workflow for that process, so it's perfectly ok to kick this can down the road for now, just dropping it here since we're in the area on the off chance it fits somewhere.
• Why are we adding solutions like SIEM and Observability that leverage Maps embeddables at the top-level of the wizard? Should we put it under a top-level category of something like "App integrations"?

[nreese]

Why are we adding solutions like SIEM and Observability that leverage Maps embeddables at the top-level of the wizard? Should we put it under a top-level category of something like "App integrations"?

The thinking was that we wanted to provide as much visibility to each solution as possible and that putting them under a single category would hide those solutions more then they should be. No strong feelings on this topic. What is the consensus from the team?

[jsanz]

I'd prefer to have the three main themes Search, Observe, Protect as top
level items, but only once we have enough layers. So if for any topic we only have one layer, then we keep it at the top until we have more. Also not strong feelings about this, but I'm sure this will need a few iterations.

I'm thinking also that we should keep using the icons to clearly establish a mental relationship with their corresponding applications.

[nickpeihl]

Since we're making a broad scope of changes can we reorder the cards? I think we may really want to push Products higher and move basemaps below Custom Sources. Here is my suggested order.

1. Enterprise Search
2. Observability
3. Security
4. Upload Data
5. Custom Sources (I'm still thinking about a better name)
6. Reference Layers

I also like the suggestion from @aaronjcaldwell to group the product layers. Maybe collapse 1-3 in a single group. I'm still trying to think of a name for that group. Currently we list these under "Products" on the homepage, but I don't think that works so well here.

Also 👍 on @jsanz suggestion for using the appropriate icons to link the products.

[nreese]

+1 for Nick's ordering and putting solution layers on top

[nickpeihl]

FWIW, I like the imperative solution names suggested by @jsanz more than mine. 😄

[mbarretta]

IMO burying access to ES aggs/docs under custom sources ("user defined sources"?) is suboptimal since it's the most common means of adding data to the Map. While I know we're pushing solutions, we shouldn't increase the friction for those on the "+1" track. Also, it could be confusing when seeing the pre-built solution layers that those are the only layers you can get for that type of data.

I think we have four types of sources:

• "internal" data (from ES)
• external data
• uploaded data (I'd argue since it starts external and becomes internal, it's really its own thing)
• reference data (base layers)

Within internal, we have

• elastic-defined / pre-built (solution layers)
• user-defined / custom

I'm not really arguing for a three tier hierarchy, but do think we could find a better way to make user-defined ES sources more prominent, understanding that there would be a confusing distinction made if we added "Elasticsearch" to the currently proposed list ("What, the solution data isn't in Elasticsearch?")

[jsanz]

From the UX point of view, we should explore the options to help users to find the correct layer straight from the first step, like having good helpers in each section (maybe even selectable). Something similar that comes to me is how Nabble forum works, where you have a hierarchy of "folders" and "forums" that in the case for the OSGeo Foundation space, can show up to four levels from the front page:

I'm not advocating for such a "busy" interface, but I wanted to just get the idea that we can provide hints of what's inside a hierarchy without forcing people to traverse the full tree of options.

Another idea would be to have the option for "pinning" the favorite options to get them in the first row (we would probably want that in the following phase for this task).

And yet another evident option if we ever get with a really big number of sources is, well, a search bar 😅

[elizabetdev]

Hello,

I've been working on improving the way we add layers. The first idea that I showed in one of the syncs was to add the layers into different categories. But by doing this we would complicate the users' interactions. By entering into one group and if it was the wrong one the user would have to go back.

I think it works well having all the layers listed right away. But I agree that it's hard to find the right one when we have a lot of them.

So I focused on:

• Decrease the size of the cards and add them in two columns (so now we can list more cards)
• Have filters on top that can help on discovering the right layer
• Also, multiple cards can belong to different groups (filters)

What do you think of this solution?

You can find the Figma Prototype here with more explorations: https://www.figma.com/file/LIk3wbKe5a9Mn8wC9VGqcu/Maps-Layer-Creation-Wizard?node-id=0%3A1

[nreese]

What do you think of this solution?

I really like the columns so you can see more options at a time and the ability to filter cards by category.

Maybe just two category filters are needed "elasticsearch data" and "reference layers"? I don't think having a category for each solution makes sense since they only have a single card and maybe a category for all solutions would also not make sense.

[jsanz]

I also like the columns to get better space usage, and being able to have a layer in more than one category. Also probably at this point we could have a category for all Solution Layers and we can eventually split that in the future if we end up with more than 8/10 layer types.

Nice work @miukimiu !!

[elizabetdev]

@nreese ad @jsanz,

What should be the final categories?

• Elasticsearch data
• Reference layers
• Solution Layers

Is this correct?

[nreese]

I think those are great categories to start with.

[thomasneirynck]

Is "Reference layers" a catch-all for EMS and everything else?

"3rd party layers"/"custom layers" need a home as well. e.g.

• TMS XYZ (raster + vector)
• WMS
• kibana-configured url
• kibana-configured geojson

[nreese]

"3rd party layers"/"custom layers" need a home as well. e.g.

Those would go in "Reference layers"

[jsanz]

Agree on those going to "Reference Layers" as the group of layers that provide context to your map as a background or overlay, compared to data that is coming from the cluster as a Solution layer or generic Elasticsearch data.
Makes sense @thomasneirynck?

[elizabetdev]

I just updated the design:

We can also use EuiFacetButtons to display the number of items for each category. What do you think of this option?

[nreese]

Is there a way to avoid wrapping filter bar? How about changing text to just Solutions, Elasticsearch, and Reference. I don't think we need an "other" category and the wording between "data" and "layer" is confusing.

[elizabetdev]

If we change the text to what @nreese suggested we can avoid wrapping.

I've been testing the EuiFacetButtons and if I create a compressed version we can also fit the buttons in one line.

You can find the tests here: https://codesandbox.io/s/pedantic-river-rermt?file=/index.js

[jsanz]

all in a single line is way better. Maybe we could eventually add a tooltip to the three buttons to provide more context.