Put layer switcher into sidebar-v2

[mstenta]

Follow up to #3

See https://github.com/Turbo87/sidebar-v2

[mstenta]

I tried this, but ran into some issues getting it to work. Worth another try in the future...

[paul121]

Oh hey! Just recently came across the ol-layerswitcher Sidebar demo and was going to open an issue for this exact feature! We're currently using the ol-ext library to add a legend to the map. This works OK, but makes it challenging to add additional UI components to the map. The Sidebar would be great to have in farmOS-map since it would provide a cohesive space for adding additional UI features/behaviors within the Map container. It also seems to work well on mobile!

Before finding this issue I was going to propose including a sidebar property in the options object of createInstance({target, options}). That would allow the Sidebar to only be rendered in contexts that want the additional UI. But perhaps we could default to including the Sidebar in all farmOS-map views to be more consistent?

I haven't tried integrating this with farmOS-map yet, but it seems like it will require some thinking. In the demo I linked to above, the Sidebar is largely defined in separate HTML divs: A high level sidebar-content div, with "panes" defined in child sidebar-pane divs (html source). The high level sidebar-content div is referenced when building the Sidebar control (js source):

var sidebar = new ol.control.Sidebar({ element: 'sidebar', position: 'left' });

Some questions/considerations that come to mind...

• How to integrate this with the farmOS-map API?
  • Can farmOS-map generate the Sidebar HTML itself?
  • Should an HTML element for the Sidebar be provided when creating an instance of farmOS-map (similar to how the maps target element is provided)? Allowing the Sidebar element to be provided might allow for more flexibility with placing & styling the Sidebar?
• How will other map behaviors provide additional Panes for the Sidebar?
  • Have behaviors append sidebar-pane elements under the sidebar-content element?
  • Create an internal API such as instance.addSidebarPane({id, name, content}) that generates the sidebar-pane and sidebar-header elements, which might help maintain consistent styling?
• How would this affect multiple maps? Should each sidebar & pane have unique IDs?
• Would this affect current farmOS-map behaviors & control elements? Eg: Should edit controls be moved into the sidebar?

Would love to hear your thoughts @mstenta @jgaehring !

[mstenta]

Great summary of the considerations @paul121 ! When I was first starting farmOS-map I found sidebar-v2 and got excited about making it a default part of the maps, for exactly the reasons you describe. I did some quick testing to see if it would be an easy drop-in, but realized that it needed additional markup and just stopped there (wasn't a priority to get to parity with farmOS for https://www.drupal.org/project/farm/issues/3083352). I'm still interested in exploring/considering it! Thanks for giving this thought - looks like we've got our work cut out for us. :-)

[jgaehring]

This is cool!

The Sidebar would be great to have in farmOS-map since it would provide a cohesive space for adding additional UI features/behaviors within the Map container.

I guess I'm still trying to think what kinds of UI features / behaviors those would be. Any examples?

Can farmOS-map generate the Sidebar HTML itself?

I kind of like the separation between the map and the markup, and would vote nay on rolling the markup into farmOS-map itself. I'm still not sure how I would use this in FK, but if I were, I'd certainly prefer the freedom to write the markup with Vue and incorporate the component library for consistency of look and behavior.

The markup seems like a fun challenge though! I would probably nitpick and suggest that the sidebar, when closed, does not need to span the entire vertical length of the page, like it does in the example. ;-)

[mstenta]

I guess I'm still trying to think what kinds of UI features / behaviors those would be. Any examples?

Apart from the layer switcher itself, I also thought it might be a nice space to put some help text / map user guide - directly in context, but hidden in a sidebar tab.

I wonder if it could also provide a space for information that might normally go into a popup too. Eg: imagine clicking on a geometry for an animal's location and seeing more info/options in the sidebar. The popups are a bit more constrained in their size... and they are also limited to a single popup. Perhaps sidebar could accommodate multiple geometry selections. And maybe even include actions like "Move these animals". Thinking big here... ;-)

But if we think about Field Kit specifically: I like how we are able to keep the map relatively simple and focused on the particular use-cases we need in each field module. So making the sidebar optional would make sense to me.

The layer switcher works fine as-is right now in Field Kit - especially considering we include much fewer layers in FK maps - so moving it to a sidebar might not really improve much. It's more helpful in farmOS where there are sometimes lots of layers, and the layer switcher needs to scroll/collapse groups to make it manageable.

[jgaehring]

I wonder if it could also provide a space for information that might normally go into a popup too. Eg: imagine clicking on a geometry for an animal's location and seeing more info/options in the sidebar. The popups are a bit more constrained in their size... and they are also limited to a single popup. Perhaps sidebar could accommodate multiple geometry selections.

Oh nice! I really like that idea. Kind of how Google maps uses the sidebar when you click on a business. Shows pictures, profile info, etc. We could basically put a mini version of the area's page right in there. Cool!

[paul121]

Great ideas! I like including help text, as well as using the sidebar as an extension of the "popup" feature. And area/asset "bios" haha

One specific use case we're interested in is viewing sensor data & log quantities associated with an area. The sidebar would give more space to display a small graph or even tabular data. We're also curious about creating a "tool" that helps highlight areas of interest on the map based on different properties. For example, high/low sensor values, specific logs that need to be completed, etc.. just having space to put simple Form elements like this would be very helpful.

Also with Drone & Satellite imagery the number of layers can add up quick. So a UI to search & filter those based on date & area is another feature that could use that space.

@jgaehring re: Using Vue, thats a good consideration.. reason for making this more flexible maybe. We're also pretty interested in getting custom imagery layers into FK, which might be easier to implement with the Sidebar, but understand that feature may be a little ways out!

[mstenta]

Oh yea! Perhaps the timeline slider controls would fit better inside a sidebar too: #53

[jgaehring]

We're also pretty interested in getting custom imagery layers into FK, which might be easier to implement with the Sidebar, but understand that feature may be a little ways out!

Oh nice! More I think of it, the more I'm on board with bringing this into FK. Again, like Google maps, I think it'd work pretty well as a drawer that slides up from the bottom, rather than the side. Which is another reason to keep it separate and flexible. I'd love to explore that more if your interested. I'd really like to split out the the Movements tab to its own module, too. Perhaps that'd be a good space to experiment with the sidebar/drawer as well.

[jgaehring]

Oh yea! Perhaps the timeline slider controls would fit better inside a sidebar too: #53

Oh man, or mstenta/farm_crop_plan#28!

[mstenta]

Cross-linking to this comment: #87 (comment)

Perhaps the snapping grid control would be a good feature to consider moving into a sidebar, along with some help text.

[paul121]

Some issues getting the sidebar library to work as an ES module with ol5+:

Turbo87/sidebar-v2#143

Turbo87/sidebar-v2#144 (comment)