Do not scale Popup menu and Context pad with canvas zoom level

[marstamm]

Problem

When I am working on a zoomed in canvas, the popup menu is significantly bigger than in a zoomed out state, while not offering more information or options.

This is also leads to inconsistent UI on the screen, as we do not scale other UI elements, such as the properties panel with the canvas zoom level. We end up with different font- and icon sizes on the screen.

Ideally, I want the popup menu to stay the same size no matter the zoom level to offer a consistent experience.

For this to work, we would also need to keep the context pad from scaling, as it serves the same purpose as the popup menu. Also, we do use both to achieve similar UI to the user, e.g. for the color changer:

Looking at other tools like miro, the context is also uses window scale instead of canvas scale and stays the same size no matter how far in or out you zoomed.

Proposal

Let's make "no zoom" the new default. We can keep the zoom configuration for applications that need it, but require them to enable the feature using the scale config.

Additional Info

Discovered during https://github.com/bpmn-io/diagram-js/pull/878 @marstamm will add this as a topic in the next HOC.

[marstamm]

We need to be aware of potential accessibility issues when we do not scale with zoom level, as the desktop modeler does not allow browser zoom. This was already reported as an issue with the current behavior: https://camunda.slack.com/archives/C0693F1NFK5/p1706806565700849

[nikku]

I'd like us to keep the existing zoom characteristics, cf. https://github.com/bpmn-io/diagram-js/issues/879#issuecomment-2037258910.

There is a reason you zoom in, and if that is for presentation or focus a UI that adapts (if only slightly!) supports you.

[philippfromme]

I think we should allow users to zoom the entire application and not bind the zoom of one (!) single UI element to the zoom of the diagram. UI !== diagram.

[marstamm]

We need to define what parts of the Interface are part of the Canvas and which are external. While I can see that the old context pad could be considered part of the canvas (same height as a task, similar style), I don't think this is the case for the new replace menu or improved context pad. If I zoom the Canvas, I do not expect my menus to zoom as well. Instead, we should have a reasonable size that aligns with the rest of the application and use browser zoom for these elements. This means also enabling UI zoom in the desktop modeler

[nikku]

Let's discuss this tomorrow in our weekly. Core diagram-js offers us all the tools we need, we just need to settle down on something.

[barmac]

I think there's a difference between browser zoom and canvas scaling.

Scaling canvas is not only about making the elements easier to distinguish by zoom in, but also for quick navigation. I'd compare it to a map application. If I want to move my focus from Berlin to New York City, I won't use the map on a street level, but rather zoom out to see the entire continent first. However, when NYC appears on my map, I will scale it up (zoom in) to see the specific spot that I am interested in.

On the other hand, scaling the UI is quite static action. I zoom in my UI (palette, context pad, popup menu - all at once) so that I can use it efficiently. I usually don't adjust the scale again unless I switch the screen or present it on a call.

[barmac]

Bottom-line is that the palette, the context pad, and the popup menu should ideally share the scale while canvas should be handled separately.

[marstamm]

In the weekly, we decided to disable auto-scaling of the context pad and popup menu