First, kudos to the team for all the hard work. I do mobile UIs so I don’t just focus on the bad. There are two specific things I notice:
As others have stated, there are “planes” the mouse moves on. At least one is closer to the user as the mouse moves around and the one where interaction can happen is further away. The mouse visibly jumps from close to far, then back again as you move around. It makes grabbing some things harder than others and it’s terribly distracting.
The bigger one (for me) is the mouse “jumping up in my face”. I’m not sure If this is an MSFS thing or a WMR thing but here is a perfect example of it, and why it’s a problem:
On climb out, need to adjust trim
Looking down, I know to not grab the trim with the mouse but, instead, use the scroll wheel. So, I use the wheel to adjust the trim up a little, then I look up to see what effect that had
As soon as I look up the mouse cursor leaps up from the trim (on a 172) and jumps in my face, dead in my line of sight. This is bad, and extremely disruptive to my experience. But wait! There’s more!
It turns out I over adjusted the trim and I’m about to stall if I don’t change the trim back, quickly. So I look down and frantically try to get the mouse back onto the trim wheel. I finally get it there as the stall warning is blaring and I scroll the wheel on my mouse to make the adjustment.
Then, of course, I have to look up again to see what effect it had…
And the mouse jumps in my face just as I realize I need to change the trim because I’m now in a dive and…
The cause of this is that when the mouse is at the edge of some boundary someone defined for your viewport, and then you touch the mouse, it leaps to the center of your view. I imagine it’s designed to be helpful in case you leave the mouse somewhere off to the side and look away. I assure you, this is NOT helpful. It’s disruptive as can be. If I put the mouse on the trim wheel, it needs to stay there no matter where I look or what else I do. If I scroll the wheel while looking at the ceiling of the cabin, it needs to still scroll the trim because that’s where I left it.
In fact, that’s exactly what I’m trying to do. Put the cursor on the trim wheel, look up, and then adjust the trim with the mouse wheel. But I can’t do that because the mouse cursor keeps jumping up into my view as soon as I look away from the trim wheel.
This “teleporting cursor” behavior needs to go, or at least be something the user can disable. Please tell me this is something the team at MSFS can do something about?
Similar issue apples when you’re adjusting the weather and want to look up to check the changes. The mouse pointer leaves the tiny slider handle and the slider jumps to zero. (UX designer speaking). Raise a bug in Zendesk.
By the way, you shouldn’t be using the trim wheel so much that you stall! The trim is only to remove any pressure on the yoke. Use the yoke (and throttle) only for pitch adjustments.
The teleporting cursor is annoying. But what is the alternative. Would you really want to be looking around in 3 dimensions to find the cursor? I suppose one fix would be allow us to map an input to “recenter mouse”.
I also think it might be nice if the mouse was a bit more sticky if it was over a control. So if I hover over the VS wheel and start us use it, then if I look away (maybe even if I don’t) I need to move the mouse over a certain threshold to unstick it from this input. This is really only an issue on axis inputs I think.
I don’t understand why you would ask what the alternative would be. It would be that the cursor stays where it was put until you move the mouse again. Also, why would you want a recenter function to find the mouse when all we would need is for the mouse to reappear when it’s been moved, like it does now.
And if the mouse just stayed where we put it, that would pretty much be the same as your idea of making it a little sticky if you look away.
You missed the point of my saying that. I’m a UI and UX dev, specializing in user interfaces and user experience. This means I understand the challenges and limitations they have to deal with better than most, and so my suggestions are with those things in mind.
Quite simply that it’s easy to lose a cursor, especially in 3 dimensions. Any UX designer should know this
The point about the mouse being sticky is also a pretty standard UX concept. It prevents accidental micro movements from breaking the input which is especially easy in the MSFS VR environment. It’s not the same as simply not auto-moving the mouse - but it is a fairly subtle difference. But in UX subtle differences make all the difference.
UX of menus, especially sliders is pretty poor on a monitor anyway. The thumb on the sliders is difficult to capture anyway. If they resolve that, it’ll improve things in VR for that aspect.
Capturing things like trim wheels, rotaries etc. again could be improved in 2D which again would follow on to help in VR.
The eye dominance issue that has already been raised would go further still.
Give them a chance, these things will get improved. I’d expect their backlog would scare most developers regardless of time served.
I totally agree on giving them a chance, that’s one of the main reasons I titled this as being from a dev. It’s an expression of empathy. Or is that sympathy?
But the main point is that this is the only application I’ve ever seen a cursor that wraps like this, and it’s extremely disruptive for several reasons. If it would just stop wrapping and stay where I put it, then I’m happy to live with needing to shake the mouse when I lose it and the fact that micro-movements might require me to be a little more careful.
And that backlog you speak of means they might have a chance to look into this in February… of 2023!
