Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment from John Carmack (Score 5, Insightful) 188

John Carmack wrote the following about 3D interfaces and VR:

This was an internal post I made in 2017, and my position has only strengthened in the following years:

3D interfaces are usually worse than 2D interfaces.

Last year, I argued that cylindrical panels were surprisingly effective, and we should embrace them for VR Shell UI. There was a lot of push back about giving up the flexibility of putting UI wherever you want in 3D, and curtailing the imagined future world of even more 3D interfaces, but the argument for objectively higher quality with the native TimeWarp layer projection kept it from being a completely abstract design question.

Reviewing a position description before an interview last week, I saw that one of the responsibilities for the open Product Management Leader position was:

"Create a new interaction paradigm that is 3D instead of 2D based"

Sigh.

Iâ(TM)m going to try to make the abstract argument against 3D interaction paradigms more strongly now.

Obviously when you are dealing with a 3D object, as with Medium, Quill, or a 3D data visualization, then you have a 3D interface, but I contend that the majority of browsing, configuring, and selecting interactions benefit from designing in 2D.

Splitting information across multiple depths is harmful, because your eyes need to re-verge (and, we wish, re-focus). This is easy to demonstrate if you have a convenient poster across the room in your visual field above your monitor - switch back and forth between reading your monitor and the poster, then contrast with just switching back and forth with the icon bar at the bottom of your monitor.

It may be worse in VR, because you have to fight the lack of actual focus change. With varifocal we would be back to just the badness of the real world, but no better. This is fundamental to the way humans work.

There is a related notion that varifocal is a hardware feature necessary for good text readability. This is wrong - it is only important for making text at widely separated distances, like a piece of paper six inches away from your eyes and a billboard, comfortable. Static HMD optics can have their focus point put wherever we want, and we should put it at the UI distance.

If you have the freedom to place interfaces wherever you want, as we do in VR, you would not place the interfaces at common reading / monitor distances. "Reading glasses" are usually necessary specifically because older people can't force their eyes to focus so close anymore. The exact relaxed eye distance will vary from person to person, but it is going to be several meters out.

This is an advantage of VR! Focusing on close monitors all day long is a stress on your eyes that can be removed.
If you want to be able to scan information as quickly and comfortably as possible, it should all be the same distance from the viewer and it should not be too close.

Depth cues give important information when you are making sense of an environment and moving relative to elements of it. If you want to hit something with a spear or time a dodge, it is valuable information. The actions you are doing in a UI almost never benefit from this.

Your view of a 3D environment is a pair of 2D projections. Unless you move significantly relative to the environment, they stay essentially the same 2D projections. Even if you designed a truly 3D UI, you would have to consider this to keep the 3D elements from overlapping each other when projected onto the view.

I think 3D may have a small place in efficient UI design as a "treatment" for UI elements, using slightly protruding 3D buttons sticking out of the UI surface in places where you would otherwise use color changes or faux-3D effects like bevels or drop shadows. Possibly 3D modeled "icons" on the UI layer, but basically staying within a few inches of the UI surface. The visual scanning and interaction is still fundamentally 2D, but it is another channel of information that your eye will naturally pick up on. This isn't convenient to implement in a VrShell style environment, though.

This doesn't mean that VR interfaces should just be "floating screens" - I really disliked how our first Home design was basically a console UI design floating in the middle of the screen, complete with TV "safe zones" around the entire thing.
The core advantage of VR from a UI standpoint is the ability to use the entire field of view, and allow it to be extended by "glancing" to the sides.

I always urge content selection to go off the sides of the screens, and have a size/count that leaves half of a tile visible at each edge when looking straight ahead. If the half-tile is at all interesting, it will draw a glance to bring the rest of it in. Actually interacting with UI elements at the angles well away from the center is not good for the user, because if they havenâ(TM)t rotated their entire body, it is a stress on their neck to focus there long, so the idea is to glance, then scroll.

The other key element that we could take more advantage of is putting less frequently used UI elements off to the sides or back. The void theater button in Netflix or the old "skip new user intro" button that was in Home are good examples of this, and things like options menus could easily be pushed off to the side.

We need to slightly "untrain" users for this, though. Today's computer UI's hide options in ways that definitely aren't intuitive - how was I supposed to know that clicking that obscure icon was going to reveal a whole window of other choices? However, this trains people to look for hidden meanings in UI elements, rather than actually looking around.

Comment Re:Firefox is starting to use Rust (Score 5, Interesting) 603

I doubt it.

Linus Torvalds:

I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.

To anyone who wants to build their own kernel from scratch, I can just wish them luck. It's a huge project, and I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed.

Slashdot Top Deals

Friction is a drag.

Working...