Automatic grouping of duplicated layers annoys some users

[gregwolanski]

No description provided.

[orangemug]

The question we need to consider here is what would we replace it with. Although not perfect, it is a really easy way to cut down the amount in this list is an easy to understand way (well hopefully anyway).

Sounds like a feature for later as we have quite a few other bits to do first. Lets leave it open to discuss though.

[pathmapper]

After reading this request/complaint the first time, I understood that the automatic grouping in general annoys some users. Now, re-reading it, I think it is only regarding the grouping of a layer which was just duplicated by using the duplicate icon:

Options to fix this:

• Open the group where the duplication took place automatically.

or

• Use an uncommon prefix for the ID of the new layer, e.g. add copy- before the duplicated ID instead of appending it.

Regarding automatic grouping in general:

Although not perfect, it is a really easy way to cut down the amount in this list is an easy to understand way

👍

Later there could be a settings panel, where beside other things the user would be able to turn automatic grouping on/off.

[orangemug]

Open the group where the duplication took place automatically.

I like this option, it seems the cleanest to me.

This code https://github.com/maputnik/editor/blob/master/src/components/layers/LayerList.jsx also needs to be modified in #431 so whoever takes it on might want to consider a refactor, as the file breaks my brain at the moment :)

[orangemug]

So question should we remove the grouping from the Maputnik layers list? It would make a few of the other tickets easier if it was an non-grouped list

• Keyboard accessible layer menu #320 - we could use a vertical tab panel (see https://github.com/davidtheclark/react-aria-tabpanel)
• Layers list: The order #431 - becomes really simple because it's just reversing the order of an array, reversing a tree makes a lot less sense form a UI perspective
• Layers list: Filtering layers #437 - we could add a 'filter input' at the top of the layers list, which would make finding things a lot easier.

So shall we remove the grouping all together?

[kateler]

Personally, I use the grouping to collapse a long layer list into a more manageable form. I am constantly expanding and collapsing as I work. A filter input is likely to be slower for someone (like me) who knows exactly where in the layer list a layer is, and just needs to get there quickly.

[orangemug]

Hi @kateler I have a few more questions

...someone (like me) who knows exactly where in the layer list a layer is, and just needs to get there quickly

What is the advantage for you of

1. scroll layer list
2. click to expand group
3. click layer

Over scrolling a long list and clicking the layer?

I use the grouping to collapse a long layer list into a more manageable form

What if you could filter by multiple things, so for example currently grouping is by the prefix_, so if you have the layers

• road_motorway
• road_minor
• bridge_motorway
• bridge_minor
• waterway_tunnel
• waterway_river
• And lots more...

In the filtered version you would enter the filter road, bridge which would filter the layer list to

• road_motorway
• road_minor
• bridge_motorway
• bridge_minor

[kateler]

My stylesheets have something like 150 layers, so it's hard to scroll precisely and quickly to the right place. When layers are collapsed into groups, the list is a little more than one screen high. Most of it is visible at once so I don't often have to scroll, just expand.

If filtering existed in addition to the grouping, I would use it sometimes. But probably not most of the time, because cartography is such a mouse-heavy activity and I'd avoid the extra step of moving my hands back and forth between mouse and keyboard.

[pathmapper]

If you are having many layers in a style I also see the advantages of the current grouping as described by @kateler:

• better visual overview of the layer tree
• less scrolling (I also prefer to expand and collapse groups compared to scrolling)

But there are also a lot of drawbacks of the current implementation:

• all the points @orangemug outlined in Automatic grouping of duplicated layers annoys some users #428 (comment).
• automatic grouping is certainly confusing for some users (as reported in the survey), because it's not entirely clear why it's happening. It's especially confusing if you duplicate a layer.
• also the current implementation isn't "complete":
  • it's not possible to show/hide a layer group (No way to hide whole layer group #376)
  • it's not possible to drag a layer group
• the automatic grouping is a hack using the layer names, so it could result in ambiguous group names. E.g. for the OSM Liberty style there are two groups named road and a group and a layer named water:

Because it looks like currently there are far more drawbacks than advantages, I think we should remove the grouping all together for now.

Later it would be nice to implement a new grouping which:

• allows manually grouping/ungrouping of layers instead of automatic grouping to avoid confusing the user and give precise control over which layers should be grouped
• allows to edit group names
• allows to show/hide whole groups
• allows to drag groups

[pathmapper]

I want to add that we should directly implement a filter function for the layer list (#437, and good suggestion in #428 (comment) regarding filter by multiple things 👍) if we decide to remove the current automatic grouping.

I suppose this would help users with long layer lists a lot until there would be a new grouping implemented, because it would be possible to "simulate" the automatic grouping to only show all layers which were automatically grouped before in one certain group.

[orangemug]

Thanks @pathmapper that's a really good overview of the problems.

So I think before we do anything we should try and reach out to a few more users to get some more feedback. Whatever we end up doing, it's going to be a big workflow change to the editor for regular users. Hopefully we can get a solution that users, like @kateler, are really happy with. However we're obviously going to need to make some compromises and accessibility should definitely be a key aim here. If we do impact users workflow lets try and come up with a solution that minimises that impact, although I still hopeful with can make Kate's experience better.

Here's how I suggest we proceed

1. Wait for a few more days see if we get any other commenters to this ticket
2. Start to reach out to users that we know use Maputnik regularly to collect more feedback
3. Once we have some more voices, build a proof of concept from that feedback. Hopefully we can add this into the editor behind one of our debug flags in release v1.8.0 so users can try it out first.

Does that sound like a good approach?

[pathmapper]

@orangemug makes totally sense 👍

Another drawback of the current implementation:
Because it's not possible to drag a group, it's also not possible to drag a layer between groups:

[orangemug]

Notifying a few people that have been active with Maputnik in the past/present, for some feedback.

@nspringer-trimble @fredj @kylebarron @keum @jonahadkins @BergWerkGIS @robert-claypool

If anybody/everybody has some time to give feedback on this ticket, it'd be much appreciated. As it's pretty core to the editing experience it's something we want to get right.

[pathmapper]

Ping @lukaswelte @sk1p

[nspringer-trimble]

As a UI/UX designer and frequent Maputnik user I see a few different issues here.

1. Not all users like automatic grouping: but... many do. I agree with @pathmapper that it took me a little while to figure out why things were grouping, but one I did I liked it and started naming layers on purpose for grouping. It is a bit arbitrary since Mapbox uses layer order for draw order (not a z-index like Mapzen), so the grouping is irrelevant if the layers are not next to each other in the stack. I suggest the following fixes (and forgive me if some of these are already in place):
   • Groups are expanded by default (but show the headers)
   • Add a toggle or setting to not show groups
   • Add a hover message on the toggle explaining how groups are formed
   • Use LocalStorage to save which groups are expanded (this will need to be done per style file)
   • Redesign the headers a little to make them more obvious and clickable
2. New layers appear outside their group: this we should just fix so the group expands when a layer is duplicated.
3. Can't drag between groups: expand groups on hover when dragging (with a 500ms debounce so things don't jump around too much)

[orangemug]

Thanks @nspringer-trimble would you still allow searching/filtering of layers based off of name?

Also a major concern is accessibility, writing a stable TreeView (https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-2/treeview-2a.html) with drag/drop reordering isn't easy. I'm unable to find one that seems to meet our needs. We could write our own, but I'm concerned with the effort/time that would take. Is there

1. A re-orderable treeview component we can use that you've seen?
2. Any tweak to the UI you can think of to make that less effort?

[nspringer-trimble]

I have never used searching or filter myself. The grouping essentially takes care of this. Our style files typically have 110+ layers and finding one has never been a problem.
I have never researched React tree controls, I am mostly an Angular developer :)
You could allow dropping on a group header (hightlighting it on hover) and then expanding the group after dropping it.

[orangemug]

I have never researched React tree controls, I am mostly an Angular developer :)

Ok thanks, if there is anything ARIA compliant in angular/vanilla web please also send that my way. The aria TreeView gets pretty complex spec wise 😬, anything would be good.

I think lets give a bit of time for others to respond, thanks for all the feedback @nspringer-trimble some very good points 👍