From: Maarten van Dantzich [maartenv@MICROSOFT.com]
Sent: Friday, October 08, 1999 11:57 AM
To: 'Niklas Elmqvist'; '3d-ui@hitl.washington.edu'
Subject: RE: Task Gallery 3D Window Manager


I'm answering these out of order, since that may help clear things up:

From: Niklas Elmqvist [mailto:d97elm@dtek.chalmers.se]
> - How do you use a mouse and keyboard in the gallery? If this is
>	displayed in a CAVE, I can understand it, but not if it's running
>	in a HMD. 

What HMD? :-)

>  And if it's running on a desktop system, you lose much of the idea
>  behind a 3D-UI, don't you? Doesn't 3D-UI equal 3D-environment for
>  the best effect?

Yes, HMDs and CAVEs are powerful. But you're not going to get anyone to use
them in the next 10 years, so they're not going to produce widespread
acceptance of 3D UI in the short term.

Our approach is to keep the barrier to acceptance low--thus, no unusual
devices, nothing the user has to wear, etc. Yes, this is a conservative
approach to 3D if you want to think of it that way. We're hoping that we'll
still manage to do really interesting things, and maybe push some of them
into MS products some day. No chance of that if we do HMD-based research.

Note that Desktop 3D doesn't mean that it can't be immersive in the sense of
capturing the user's attention and giving them a good sense of the space. We
did a follow-up paper on some of Randy Pausch's research, contradicting his
claims that Desktop 3D performs worse than head-mounted 3D. The term
"immersive" has unfortunately been co-opted to mean "head-mounted". (See
UIST97, Robertson et al., "Immersion in Desktop 3D"--and note that the
design of the task was replicated from what Pausch et al. did--if you don't
like it, yell at Randy. ;-)

I realize that our work is kinda on the fringe for the audience on this
mailing list...  :-)

>  - Why did you choose to constrain the viewing of applications 
>    to the walls (as well as floor and ceiling) of the gallery? 
>    Why not have	applications floating in midair in arbitrary
positions? 

Why have them float in mid-air? What does that buy you? (Serious question.)

Actually, it may be hard to tell, but the individual windows more or less DO
float in mid-air, at least in the active project on the stage. 

We wanted to create a "container" that would bundle together windows
belonging to one task (project); we wanted a bit of a metaphor. We also
needed to limit the number of currently live-updating apps so we could get
decent performance. (Having all apps run with live output updating would be
a bit like displaying dozens of video streams into a 3D environment: a huge
amount of per-frame texture updating.) We wanted a focus + periphery
arrangement (current task focus is in the center of the screen; other
projects are arranged in the periphery when you back up from the stage).
Etc.

That's not to say that you can't make free-floating windows work if you
wanted to. 

Actually, it may be hard to tell from the stills, but the "floating window
stack" in the active project _does_ have the windows floating in mid-air. We
found that that was actually very undesirable: it's hard to tell where in
the space the window is if it's not anchored, since we don't have stereo
cues. So we created little posts that prop up the windows and give them
'anchors' in the space.

Furthermore, note that the things on the wall are task-spaces, not
individual windows. Yes, it is like having multiple desktops.

> - I seriously like the notion of aligning an application with the user's
>	viewpoint when it receives focus to make interaction easier. (Does
>	this allow for some special optimizations, sort of like blitting
>	to a flat 2D surface using DirectDraw instead of drawing a
>	textured quad? 

I considered doing this, and it's a good idea; it means you bypass the
fuzzing of the texture filter. Right now, for ease of implementation, we
texturemap the windows into the environment even when they're
screen-aligned. 

>> Maarten.