I was working on a 'visual debugger' that centered around a 3D display of data structures evolving in time[0], and learned some lessons from it. I would say th

I was working on a 'visual debugger' that centered around a 3D display of data structures evolving in time[0], and learned some lessons from it. I would say the key thing is to understand the specific properties that differ when adding another dimension. The main thing you gain in terms of expressing information, or in terms of designing an interaction scheme, is another axis on which you can 'analyze' your problem: this is a generalization of the basic idea you see with a 3D data plot vs 2D. This 3rd dimension is a new element of the 'syntax' of your UI, which can be made to map to a specific concept in your program. So then the question is: does the problem you're trying to solve have a matching structure that would be clarified by having an additional axis to map its visual representation on to? Additionally, the property that caught my attention initially was about using 3D space + human visual processing to define an information prioritization scheme: 'depth' into a 3D scene is is a natural, ready-made system for indicating priority: Objects nearer to the camera (less 'depth'), occlude further objects. Further objects have their (projected) size reduced as a function of their depth, and are often darkened as well. All this adds up to a convenient/flexible way of talking about priority (from the programmer's perspective) and a natural way of reading priority (from the user's perspective). That's the theory anyway: my experience with it was a mixed bag, and at least for my specific project, when I've thought about how I'd do things differently now I think I'd just stick with 2D—at least to start with. There are a lot of more unsolved problems that show up when thinking about UI in 3D, possibly because the design space is larger, but certainly at least because it's less explored. And the number of possible ways things can go wrong, or at least considerations needing to be made, from both programming and design standpoints, is also significantly larger in my experience. [0] http://symbolflux.com/projects/avd http://symbolflux.com/projects/avd