Hacker News Reader

Comment by eridius | Hacker News Reader

Clever idea. But scrolling the little VR scene on the right with my mouse is backwards. When I click and drag to the right, the camera pans to the right. But since I'm clicking on the content and dragging, it feels like the content should pan to the right, meaning the camera should pan to the left.

View on HN

This is impossible to get right. If they had done it the other way around, other people would be complaining.

Source: I've done it both ways for several apps and people always complain, either way.

If people complain about the other way, it's just because they're used to things doing it wrong. When you're dragging something, the thing you're dragging stays under your mouse. Here you're clicking and dragging on the scene, so the scene should stay under your mouse, but it doesn't. It flies in the opposite direction.

It depends on whether you consider it to be sitting in a stationary position and dragging the environment around or sitting in a fixed environment and dragging yourself around. Largely personal preference, but if you're expecting one and get the other it's pretty disorienting.

Having to click and drag in the opposite direction is pretty weird though. First person shooter style "move mouse left to look left / move environment right" is just mouse movements. You're not grabbing something to drag it, so there's no clicks.

Tough to translate that into a windowed thing where you can't do fullscreen mouse ownership like shooters do.

If I get the grabbing cursor when I press the mouse, I expect the dragging logic. That actually would be good way to make it unambiguous but here it's used wrong.

That's a really good point. Regardless of which style of dragging someone prefers, the grabbing cursor is a clear indication to expect "natural" style dragging.

After all, when you press the button, the fingers close as if they are grabbing something in the scene. In real life, when you grab something and move it, it goes in the direction you move, not the opposite direction.

Someone correct me if I'm wrong, but I believe in large part it's gamers who tend to expect the reverse dragging. I think at this point far more people expect natural dragging as used in most online maps and street views, etc.

360cities used to have the reverse dragging, but I see they have changed it to natural dragging now. Try the panorama on their home page for example:

http://www.360cities.net/

But the other thing I was told about gamers is that they don't expect to drag with the left button, but with the right button.

This suggests a possible solution: a left-button drag can use natural dragging, and a right-button drag can use reverse dragging.

The finishing touch would be to have the cursor change to something other than the closed hand when the right button is down. I'm not sure what a suitable cursor would be, but there must be something - anything other than the closed hand. Maybe a four-way arrow?

If you want camera-drag with right-click, ideally you'd just hide the mouse (and capture it so it can't leave the bounds of the view). That's normally what games do when they have right-click dragging in the fashion you describe.

That said, I have no idea if JavaScript can capture the mouse like that.

It can! For a capture that lasts until the mouse button is released:

https://developer.mozilla.org/en-US/docs/Web/API/Element/set...

Or for a capture that works even if the mouse button is not pressed, and remains until the Esc key is pressed:

https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Loc...

The first option would be the one to use for right button dragging.

The first one is Firefox only, the second one is everything-except-Safari.

While WebVR scenes can be viewed in a browser, their intended target is the vr headset, where the "dragging" is not at issue, and you are turning the view by turning your head. I think it would make more sense to keep the reverse dragging and change the mouse icon here. The intended experience is not "here is a scene that you can drag around" but "here is a virtual scene you are standing in and you can look left and right". So the intended context is that, headset or not, you are controlling the viewers head.

Exactly, no approach is clearly correct: https://ux.stackexchange.com/questions/93350/an-intuitive-wa...

Isn't this just "nurture"? I am used to dragging the camera, but you are used to dragging the scene?

What's right?

But you are in 3D space, hence your view rotating in the direction that you drag the mouse (think first person shooter, you wouldn't invert controls for that).

In an FPS you don't hold the mouse button down to change your camera. In an FPS the cursor _is_ the camera. But here, you're literally clicking and dragging, and dragging actions always go the other way.

A-Frame defaults the desktop drag (which acts as a preview for VR experiences) to dragging the camera. For static scenes such as panorama, it can feel weird, but A-Frame does have options now to reverse the drag direction. But when you're building 3D scenes and using WASD, it feels more natural to drag the camera.

Pointer lock should be done, but we count the desktop drag as a non-invasive preview mode, but experiences can implement pointer lock if they need.

I agree. If you use the mouse to point, then the camera should move in the direction the mouse moves. If you use the mouse to grab the world and move it, then the world should move in the direction the mouse moves.

But since there's a "hand" pointer, it seems more logical that it would drag whatever it is holding, in this case the 'scene'

While we're discussing the dragging behavior, you also can't click on the bottom ~1/3 of the pane, seemingly because of the little cardboard/vr goggle graphic in the bottom corner.

Reply on news.ycombinator.com