[Maps] embedded maps and edit capabilities

[nreese]

Should embedded maps have all of the edit capabilities available in the Maps application?

1. Should "Add layer" button be visible?
2. Should layer details panel be allowed to open?
3. Should layer details panel allow users to delete layer?
4. Should layer details panel allow users to update any layer properties like Layer transparency and zoom level?
5. Should layer details panel allow users to update non-style layer properties like terms joins, metrics, ...?

cc @alexfrancoeur @cchaos

[elasticmachine]

Pinging @elastic/kibana-gis

[nreese]

Dashboard has the concept of read only mode. What will the embedded maps look like in this mode?

I think the easiest answer is that nothing can be changed in read only mode so

• add layer button is not displayed
• layer details panel can be opened
  • all inputs are disabled
  • Delete layer and saved layer button are not displayed. Cancel button is renamed Close

The only thing missing is that I could see users potentially wanting to fiddle with layer transparency locally to better see stuff. Maybe the other condition of ready only mode would be that the layer transparency slider is added to the layer actions panel below visibility toggle.

Then, for map embeddables phase one, all maps are embedded in read only mode. We could release with the most limited set of functionality and see what users ask for in the future to drive further conversations.

How does that proposal sound?

cc @stacey-gammon

[thomasneirynck]

Then, for map embeddables phase one, all maps are embedded in read only mode. We could release with the most limited set of functionality and see what users ask for in the future to drive further conversations.

+1. I would remove all editing capabilities in a first implementation. Basically, prevent users on a dashboard to open up the layer-details panel and hiding the add layer button. I think the division between an authoring step (in the Maps-app) and a presentation step (in the Dashboard) is fine to preserve. Editing visualizations/embedded objects in-place would also see to be a bigger topic that not only applies to Maps (but also visualizations, saved searches, ...)

[nreese]

I would remove all editing capabilities in a first implementation. Basically, prevent users on a dashboard to open up the layer-details panel and hiding the add layer button

I still think there is value in showing the details panel. That way, users can view the source, see how each aspect is styled and so on. Without the details panel, there is a lot of missing information

[alexfrancoeur]

@nreese @thomasneirynck I had a separate issue opened for a read only mode (#30313), let me know if we should just close this out. While related to embeddables, this is actually a separate use case that is specific to the app and will only become more important with feature controls (#20277)

I'll try and address each comment in order with my thoughts.

Should "Add layer" button be visible?

I don't think it's necessary.

Should layer details panel be allowed to open?

I think so, but not by default. And the layers panel should probably only show layer actions available and legend (when we have one)

Should layer details panel allow users to delete layer?
Should layer details panel allow users to update any layer properties like Layer transparency and zoom level?
Should layer details panel allow users to update non-style layer properties like terms joins, metrics, ...?

I don't necessarily think this level of configuration is needed initially. I'd be comfortable with limiting to actions only (and eventually, legends). Today that would be show / hide and fit data. As adoption grows, we can see what our community wants down the road.

The only thing missing is that I could see users potentially wanting to fiddle with layer transparency locally to better see stuff. Maybe the other condition of ready only mode would be that the layer transparency slider is added to the layer actions panel below visibility toggle.

I think this is a good idea, but in my opinion something we may be able to punt on and probably not necessary for the first implementation. If it's a low effort add, let's do it. Otherwise, we can wait and see what gets requested.

Then, for map embeddables phase one, all maps are embedded in read only mode. We could release with the most limited set of functionality and see what users ask for in the future to drive further conversations.
+1. I would remove all editing capabilities in a first implementation. Basically, prevent users on a dashboard to open up the layer-details panel and hiding the add layer button. I think the division between an authoring step (in the Maps-app) and a presentation step (in the Dashboard) is fine to preserve. Editing visualizations/embedded objects in-place would also see to be a bigger topic that not only applies to Maps (but also visualizations, saved searches, ...)

+1 for both comments 👍 👌 🙆‍♂️

I still think there is value in showing the details panel. That way, users can view the source, see how each aspect is styled and so on. Without the details panel, there is a lot of missing information

If you feel strongly about this, maybe we could limit this functionality to when the map is expanded from a dashboard vs. when it's a panel amongst other panels? I'm not sure if we can differentiate the states, but it might be a good compromise.

Separately, I'd be really interested in seeing what a the collapsed layer controls would look like. Also, do we consider legends a requirement for embedded mode? I feel like this is one of our larger gaps right now but probably something that could be addressed outside of the embeddables scope.

One more note, when we begin to think about adding layer specific filters, it might be worth taking a similar approach as TSVB. Where you as the map creator can configure if you want that layer to be updated by global filters or not. While this is applicable from within the maps app, it'll be equally if not more important for the embeddable use case.

And I'm done, sorry for the novel 😄

[thomasneirynck]

Also, do we consider legends a requirement for embedded mode?

yes, I would think. The absence of a legend really will stick out on a dashboard when users don't have any additional context from the layer-panel editor. We'll need to investigate (timing, resources, ...), but should definitely try and improve legends at the same time as we're working on embeddability.

[nreese]

Separately, I'd be really interested in seeing what a the collapsed layer controls would look like. Also, do we consider legends a requirement for embedded mode

Just so we are all on the same page, when discussing legends, we are talking about additional context in the layer control - not a separate control. Correct?

[thomasneirynck]

Just so we are all on the same page, when discussing legends, we are talking about additional context in the layer control - not a separate control. Correct?

imho yes.

[alexfrancoeur]

@nreese yes, from previous discussions that what I was thinking as well. If @cchaos has any alternative suggestions that might work for better UI/UX, it might be worth a conversation. Off the top of my head, I can't think of a better way to handle legends differently.

[nreese]

closed by #31318