Open gregwolanski opened 5 years ago
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:
or
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
:+1:
Later there could be a settings panel, where beside other things the user would be able to turn automatic grouping on/off.
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 :)
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
So shall we remove the grouping all together?
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.
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
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
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
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.
If you are having many layers in a style I also see the advantages of the current grouping as described by @kateler:
But there are also a lot of drawbacks of the current implementation:
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:
I want to add that we should directly implement a filter function for the layer list (https://github.com/maputnik/editor/issues/437, and good suggestion in https://github.com/maputnik/editor/issues/428#issuecomment-619352557 regarding filter by multiple things :+1:) 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.
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
v1.8.0
so users can try it out first.Does that sound like a good approach?
@orangemug makes totally sense :+1:
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:
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.
Ping @lukaswelte @sk1p
As a UI/UX designer and frequent Maputnik user I see a few different issues here.
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
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.
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 👍
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.