Improve rotate UX

[HarelM]

This changes the drag-rotate on desktop to be around the center and respect the distance from the center.
It also improves the roll pixel factor.

The following comment started this:
#4780 (comment)

Before:

Screen.Recording.2024-10-17.at.1.24.36.mov

After:

Screen.Recording.2024-11-20.at.0.52.35.mov

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Add an entry to CHANGELOG.md under the ## main section.

[HarelM]

CC: @NathanMOlson FYI.

[birkskyum]

It behaves more like I'd expect it to at high pitch, where it was opposite before.

[NathanMOlson]

The new behavior looks great to me!

[kubapelc]

I built maplibre from the latest main without checking new changes, so I had no idea this was implemented, and this was my first time experience: I noticed that map rotation behaviour felt very weird and seemingly inverted in the X axis. I could not figure out what was going on and how to rotate the map the way I wanted, the rotation seemingly had no relation to mouse movement, it accelerated randomly, and then stopped moving at some point. I thought it was a bug before finding this PR.

This new behaviour feels very unintuitive for me, especially since the rotation seems to depend on relative position to screen center, an invisible and somewhat arbitrary point. Both google maps and earth use the old way, and that feels much more consistent with mouse movement and simple to use for me.

When the mouse crosses near the screen center, the map flicks upside down:

2024-11-21.01-13-47.mp4

I might very well be an outlier, but it may be good to see how more people feel about this change. Maybe posting a link to a demo with the new behaviour in the OSM slack would work?

[HarelM]

The idea is that much like panning, you grab a point on the screen and move that.
The rotation itself is around the center, so this is not an arbitrary point.
Having said that, when the drag is close to the center the behavior isn't great, and it might be good to revert to the previous behavior (plus below and above center different direction).

You can see the original video of how you drag the map and it rotates to the opposite direction, which is what I wanted to solve mainly, and also better adjust the rotation to "move" what's currently under the mouse.

I'll open a PR to improve the center experience.

[HarelM]

@kubapelc I've opened the following PR to address your concern:

• Improve rotate experience when close to center #5104

Please let me know if you think this is enough.

[zta6]

Just chiming in to agree with @kubapelc in saying that this doesn't feel like an improvement to me. I assumed it was a bug too, and after playing with it for 20 minutes I still can't get it to do what I want.

I understand that any UX change results in some change aversion but I don't think that's what I'm feeling unfortunately.

With the previous controls the mental model was simple. Move the mouse laterally and the map will rotate. Move the mouse vertically and the map will pitch.

With these new controls I can't tell what inputs are required to get the map to turn the way that I want it to turn. I understand what you were going for with 'grabbing' a piece of terrain and moving it. But I don't think it really works in 3 dimensions, and even if it would work I'm not sure you've achieved the 'grabbing' feeling you were looking for. Even just watching your video - your mouse quickly separates itself from the location you clicked or 'grabbed'.

As an example of the complexity of this mental model - Try to rotate the map 360 degrees in one continuous gesture without drastically changing the pitch. I can't do it for the life of me. These controls don't feel orthogonal to me and non-orthogonal controls don't tend to be considered easy to use.

[HarelM]

Dragging the map vertically pitches the map exactly as before, dragging the map horizontally rorates the map, the only difference is that rorating is taking into consideration the center point and when you are above the center it rotates to what I believe is the right direction.

If you don't like it you are welcome to open a PR.

[zta6]

Dragging the map vertically pitches the map exactly as before, dragging the map horizontally rorates the map

Except that things break when you put your cursor near the vertical center of the map, because the code can't decide which direction a drag should make the map rotate so it ends up rotating the map an unpredictable amount in an unpredictable direction. IMO near the centerline is a pretty natural place to put your cursor when attempting to rotate the map. Even if it's not, crossing the vertical centerline mid-rotation is also something that's bound to happen and the rotation reversing direction when that happens doesn't make any sense.

I can move my cursor 10cm horizontally and have the map rotate <10 degrees. And then on another attempt, or when the cursor is on a different part of the screen I can move my cursor an 2cm and have the map turn 180 degrees. As a user I can't tell if I need to move my cursor 1 cm or 10cm+ to achieve the outcome I'm looking for.

Screen.Recording.2024-12-04.at.12.22.34.PM.mov

[birkskyum]

If the change brings improvements to some cases, and regressions in others, then it's probably safest to revert it until we know how to only target the behavior that was problematic before.

[gustavo80br]

Hey folks, arriving late to the discussion. I had to change to v5.0.0-pre releases, to take the improvement #3854, which is really necessary. I had to stop at v5.0.0-pre.6 because this rotation change is creating multiple undesired behaviors.

If you rotate the map around the vertical middle of the screen, while you are moving the mouse to the same direction, rotation changes to the other side for a reason I was not able to understand why. I suggestion that his feature to have a toggle, so that people can choose to turn it on or off, because for me this broke the lib completely, if this stays on v5 I will not be able to upgrade.

[HarelM]

The before and after videos at the top pf this thread explains very well, from my point of view, why this change was introduced.
Moving a map, that rotates around the center, to one direction while the rotation of the map is in opposite direction to the mouse movement is a bad user experience.
Reverting this PR will still keep this bad behavior, it's not a solution.
If you would like to suggest a solution, feel free to do so using a PR which addresses the issues that were solved in this PR and creates a reasonable experience as well.
Adding more configurations doesn't sound like a great solution to me, BTW...

[kubapelc]

Another suggestion: revert to the old behaviour, but with the addition of hiding the cursor while the map is being rotated. This might solve the original issue of users attempting to drag-rotate the map - hiding the cursor subtly implies that its position is irrelevant to rotation controls.

[HarelM]

I belive hiding the cursor breaks some accessibility rules, also not a great user experience if you'd ask me...

[birkskyum]

If you rotate the map around the vertical middle of the screen, while you are moving the mouse to the same direction,

@gustavo80br , I struggle to imagine this - can you make a small video recording of it?

[gustavo80br]

@birkskyum here is the video. You can see the mouse is moving in the same direction, but the rotation direction is changing. It happens when the mouse is close to the vertical middle. The actual behavior, that's present in the latest release, I see very intuitive and with no glitches like this. When I upgraded to the pre-release 9 the first thing I noticed was this rotation behavior change and started to look for some settings to revert it back, until I found this thread and rolled back to pre-release 6, and then to pre-release 5 as other rendering glitches were happening in pre-relase 6. @HarelM will see what I can do to submit a PR with suggestions.

Video.do.WhatsApp.de.2024-12-17.a.s.14.02.32_a13ebb09.mp4

[gustavo80br]

I have compared MapLibre actual rotation behavior with Google Earth. It's similar, the map rotates to the same direction that MapLibre does in the production release. Just the movement in Google Earth that is less sensitive to mouse movement and has some easing when you release the mouse. The actual rotation of MapLibre was intuitive to me, I just started to use it and already was familiarized with how to move the map perspective. After the change, navigating through the map became unpredictable.

I don't feel the pain that motivated this change. My way of thinking about rotation and pitch: move mouse up and down, changes the pitch; move mouse left/right, rotates the map to one side or the other. The pitch behavior did not change but now moving mouse left/right brings some unpredictable rotation change if you are around the middle of the screen.

[HarelM]

There are edge case in any definition of movement, dragging near the center is where this solution falls short.

[birkskyum]

For better or worse, it's definitely an adjustment. It's interesting how maps do this differently - I haven't thought about it before:

• google maps has up/down as pitch, right/left as bearing, pivot around center. Meaning when cursor is above center the rotation is opposite of mouse movement direction.

• apple maps has a up/down as pitch, right/left is not simply bearing, but the pivot point for rotation is here the point where the drag starts - meaning the curser almost never "grab"/follow the map around.

• maplibre after this change, has up/down as pitch, right/left is not simply bearing (more similar to apple maps), and rotation is around center (more similar to google maps)

[zta6]

Agreeing with @gustavo80br that I don't think we can upgrade with this behavior in place. I'd really like to, y'all did some incredible 3d/terrain related work that I'd love to have. But I think that this will be too disruptive + confusing for our users.

Were there lots of user complaints about the previous implementation? We haven't heard such complaints from our users, but maybe we just haven't heard from them yet.

The previous model to me wasn't unintuitively moving the map in the opposite direction of the mouse, because as far as I was concerned the movement of the map wasn't really "relative" to the mouse at all. The previous model, to me, is like a joystick on an arcade machine or similar. If you move the mouse left (push the joystick left) then the map rotates clockwise, if you move it right the mouse rotates CCW, move it up and the maps pitch increases, move it down and the pitch decreases. FWIW that model also creates a parity between the keyboard controls for the map and the mouse controls for the map. This change breaks that parity to some extent.

[justinclift]

Yeah, developing a new mapping application over the last few weeks and this new rotation behaviour is much less straight forward to work with, at least on macOS and iOS devices.

Will need to stick with 4.7.1 for now, then take a look at v5 again in a few weeks to see if it's been fixed. 😄