Cadastrapp Evolutions

[tdipisa]

When using cadastrapp, users have reported uses of Cadastrapp that bother them:

• the loss of the search bar when Cadastrap is open
• the impossibility of accessing the other functions of the burger menu when Cadastrapp is open: printing, urban planning, etc.
• the impossibility of printing a selection of parcels

The development requested here should allow Cadastrapp to solve these problems of use. Explore:

• Moving the burger menu and search zone
• Possible reduction of the Cadastrapp window (without closing it)
• Export of parcel selections in an annotation layer

[offtherailz]

Here an analysis

Allowing to access to other tools while using Cadastrapp

Here in this image I resized a little cadastrapp window to allow usage of urbanisme and burger menu.

The result is very confusing and there is not too much space on the screen to use both the tools in the same time.

The design is made this way to use all the space of the screen to focus on a single activity and avoid confusion between tools.

One solution can be to make cadastrapp window draggable and re-scale the window to make tools smaller.

Anyway the interactions remains very complicated

• We have 2 selection tools that should work in mutual exclusion (now they don't)
• Urbanisme popup should be always active, but it is disturbing the selections.

https://user-images.githubusercontent.com/1279510/152978203-cb8e4d27-0e5f-4759-a2d4-0a24bf2fdaf7.mp4

So summarizing we can do it by:

• Scaling all cadastrapp to be smaller and making it a resizable window
• Adding glue code for mutual exlusion of Urbanisme and Cadastrapp (urbanisme may need to change the selection tool from normal click to DrawSupport, in order to support mutual exlusion)
• Adding a button in urbanisme that activate/deactivate the popup, instead of activating it automatically --> Here to allow it we need to downgrade the functionalities of urbanisme
• Add also code to auto deactivate popup when one drawing tool is active.
• General check to avoid other tools from burger menu to conflict with drawing tools of cadastrapp (implementing mutual exclusion).

note: In my opinion the current design is a better compomise between usability and functionality then the suggested solution, because forces the user to use one tool at a time, that is and intuitive and causes less conflicts.

Printing

Even if we have access to the print plugin, we can not print the cadastrapp layer(s). This because both the selection and the parcels layers are temporary selection layer that are not available in the TOC. while the Print plugin prints only layers present in the TOC (the same happens for instance with the current row selected on the feature grid, for instance)

• We can provide the possibility to print the layer by adding the functionality to export the selection as annotation or vector layer. (the layer of parcels needs to be anyway added to the TOC, if need to print). This solution works for both we decide to make the burger menu accessible from cadastrapp or not.
• Another alternative is to add a checkbox to the print plugin to "print also overlays" that adds the layers not in the toc to the list of layers to print.

[landryb]

i was originally strongly against having the cadastrapp pane be made a floating/resizable window, because in the mfapp version of cadastrapp this quickly led to bazillions of distinct windows/toolbars and was a UI nightmare.

i see two options:

• leave the cadastrapp pane as static/fixed as it is now, and shift the burger menu/search bar on the left (like done with the zoom in/out toolbar). Dunno if that would be asthetically pleasant or not confusing for users.
• make the cadastrapp pane a floating/resizable window as you propose, which should be okay as long as we have a single window (and there's already the parcel info window on top....) - would allow access to the burger menu and to address search.

as for printing, now that i've fixed all the printing issues i had with WMTS/non-geoserver WMS, i know for sure users will complain that their printed/exported PDFs doesnt contain their selections/overlays/drawings.

Imo a single checkbox in the printing window with 'print selection and annotations' would solve the issue, taking into account the annotation layer/the feature grid selection/cadastrapp plots selection. The only downside would be sending a larger payload to mfprint (too large if many objects ?), and i dunno if mfprint supports printing arbitrary geometries.

[landryb]

see also #133 & #137 for other discussions.

[tdipisa]

After some first considerations (e.g. the one above from @offtherailz) I've reviewed with the team the general goal. For this development we are evaluating to review a part of the MS UI.

The general aims are:

1. Remove the burger menu, with other buttons like Home (and the Login one in MS) to move all of them, along with all menu options, in a vertical side toolbar

2. Reduce the size of side panels that opens on the right to make them smaller (around width: 550px) and with a smaller header

3. The Search bar will move to the left when a right-side panel open, to be collapsed in a spyglass button and be opened when that button is clicked. The Search bar is opened by default when there's no panels opened on the right

4. As far as the annotation panel is concerned, it will be moved on the left side to be more "driven" by the TOC: a new button ("Create annotations") in the TOC toolbar will open the annotation panel on the left. When annotations have been created (the related layer is present in TOC with the others) an annotation pencil icon in the TOC toolbar ("Edit annotations") will allow to open the annotation panel again for editing purposes as soon as the annotation layer is selected in TOC

5. The DrawSupport will be also reviewed a bit to ensure there will be no conflicts between tools interacting with the map using a proper policy

6. The position of the Urbanisme tool, when opened, will change accordingly as shown in the above screenshot

7. The printing tool will provide an option to include additional layers (eg. selection of parcels) in the final print

note : we have to shedule the migration from BurgerMenu to this new menu (e.g. existing contexts)

[Gaetanbrl]

Remove the burger menu, with other buttons like Home (and the Login one in MS) to move all of them, along with all menu options, in a vertical side toolbar

What whill happen with a big number of tools with the right vertical black/white toolbar ?

[landryb]

fwiw i really like this UI proposal. More 'obvious' to the user..

[MaelREBOUX]

Remove the burger menu, with other buttons like Home (and the Login one in MS) to move all of them, along with all menu options, in a vertical side toolbar

What whill happen with a big number of tools with the right vertical black/white toolbar ?

I have the same question.

But I really like these proposals.

One thing to have in mind : our users have 1600 x 900 screens. It is horrible but it is reality.