Extend Map Layers Functionality to Study Areas Side Menu

[hdinia]

Feature Request: Extend Map Layers Functionality to Study Areas Side Menu

Description:

Our current application includes a layer feature in the map view, allowing users to filter areas by groups, with each group only visible in its assigned layer. However, this functionality is limited to the map view. We've received user feedback requesting the extension of this layer-based filtering to the study areas side menu. This extension would enable users to focus on specific areas within a given layer, reducing the clutter of irrelevant information.

• Layer Functionality in Areas Menu:
  Extend the existing map layers functionality to the study areas side menu, allowing users to filter and work with areas based on the selected layer.

• Selective Visibility:
  Areas should only be visible in the menu when their corresponding layer is active, aligning with the current behavior in the map view.

• UI Integration:
  Add a select component beneath the search input in the areas menu. This component will facilitate layer selection, providing a user-friendly way to switch between different layers.

Sreenshots:

• Synchronization with Map View:
  Ensure that the layer selection is synchronized between the map view and the areas menu, providing a cohesive user experience.

• [To be confirmed] User Preference Memory:
  The application should remember the user's last selected layer in the areas menu and retain this selection across sessions.

• Performance Considerations:
  Implement this feature with attention to performance, ensuring that the additional layer functionality does not negatively impact the application’s responsiveness or speed.

[laurent-laporte-pro]

About the "User Preference Memory" paragraph: to implement this, an association table between the list of studies and visited layers would be needed, and events like the following should be managed to update the table:

• a layer is visited,
• a layer is deleted,
• a study is deleted.

This association table could be stored globally within the session and also at the level of the list of favorite studies.

At the back-office level, persisting this information is quite challenging because the list of layers is not specific to each user but rather global to the study.

[hdinia]

About the "User Preference Memory" paragraph: to implement this, an association table between the list of studies and visited layers would be needed, and events like the following should be managed to update the table:

• a layer is visited,
• a layer is deleted,
• a study is deleted.

This association table could be stored globally within the session and also at the level of the list of favorite studies.

At the back-office level, persisting this information is quite challenging because the list of layers is not specific to each user but rather global to the study.

I was thinking about local storage persistence, cause it's only UI-related information (layers does not affect the study configuration). This is a common method for persisting non-sensitive UI state across sessions. It's ideal for storing preferences like theme, layout choices, or the last state of certain UI elements.
But finally, I don't think it's a good idea from a user experience point of view. Maybe we can consider this as a future improvement if users asks for it