From bowman@cc.gatech.edu Wed May 27 10:39:40 1998 Received: from burdell.cc.gatech.edu (root@burdell.cc.gatech.edu [130.207.3.207]) by lennon.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id KAA06633 for ; Wed, 27 May 1998 10:39:34 -0400 (EDT) Received: from wheaten.hitl.washington.edu (YLLo+vLIzRHHqT0CSG9guXMFeQH8rLBG@[128.95.73.60]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id KAA19296 for ; Wed, 27 May 1998 10:39:32 -0400 (EDT) Received: from burdell.cc.gatech.edu (root@burdell.cc.gatech.edu [130.207.3.207]) by wheaten.hitl.washington.edu (8.8.8/8.6.12) with ESMTP id HAA05198 for <3d-ui@hitl.washington.edu>; Wed, 27 May 1998 07:39:21 -0700 (PDT) Received: from lennon.cc.gatech.edu (bowman@lennon.cc.gatech.edu [130.207.9.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id KAA19248 for <3d-ui@hitl.washington.edu>; Wed, 27 May 1998 10:39:19 -0400 (EDT) Received: (from bowman@localhost) by lennon.cc.gatech.edu (8.8.4/8.6.9) id KAA06199 for 3d-ui@hitl.washington.edu; Wed, 27 May 1998 10:39:05 -0400 (EDT) From: bowman@cc.gatech.edu (Doug Bowman) Message-Id: <199805271439.KAA06199@lennon.cc.gatech.edu> Subject: Re: UI design in a new medium To: 3d-ui@hitl.washington.edu (3D UI List) Date: Wed, 27 May 1998 10:39:05 -0400 (EDT) In-Reply-To: from "Jeff Pierce" at May 26, 98 11:45:01 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO A while back, Jeff Pierce wrote: > At 10:52 AM 5/26/98 -0400, Doug Bowman wrote: > >Second, Ernst's article regarding the use of 2D interfaces in 3D > >had some good points. After a (rather lengthy ) message, he > >concluded that the requirements of most VE interactions are very > >task-specific, and there will not be one simple solution for all > >of them. > > As long as we're talking about tradeoffs, note that there's a tradeoff > here. Yes, task specific interaction techniques will generally be better > (depending on the metric you're using for better) than more general > interaction techniques. But the price you pay is that you've got to > generate new techniques for every task. This is fine if VEs are > curiosities developed by a few researchers (the current state of affairs). > However, if VEs ever become mainstream then I would argue that a few > general interaction techniques will predominate over different interaction > techniques for every application. Of course this tradeoff does exist. I'd have to disagree with the statement "You have to generate new techniques for every task", though. It's extremely likely that a new task will be satisfied with an old technique - it's just not clear how to get the correct mapping. That's part of what I'm proposing in my thesis: that we can evaluate techniques in a very generalized, systematic way, producing a "performance profile" for techniques for selection, for example. Then when I have a selection task in my application, I can specify what _requirements_ I'm interested in (e.g. I need to be able to select objects at a medium distance range which are densely packed in among other objects). Now the problem of mapping becomes one of simply matching up the specified requirements with a technique that has been shown already to meet those requirements. Easy, huh? ;-) On the subject of whether VEs will be "curiosities" or "mainline", I would argue that they're more likely to be somewhere in the middle - domain-specific applications that are used widely within that domain. > >I wholeheartedly agree, and would like to add more to this statement. > >I think the complexity and domain-specificity of most VE applications > >make them much more difficult to design interactions for. In my > >thesis, I'm trying to look at this in a generalized fashion, and > >consider characteristics of not only the task, but also the user, > >environment, and system, along with the performance requirements of > >the application, to determine a good interaction technique. There > >are many more variables than I can hope to consider in a a few > >experiments, but I think this framework is a good way to start > >making the design of interaction techniques for VEs more systematic. > > How about including cost (user time, $) in the framework? Customize-ability? Costs (time and money) or customizability would be performance metrics in my framework. Let me explain a bit more what I mean. I would like to do evaluations where the main independent variable is the interaction technique, and secondary independent variables are [task, user, system, environment] characteristics. These evaluations produce results in terms of performance metrics (dependent variables) such as speed, accuracy, ease of use, presence, etc. I think this latter section is where cost and customizability would fit. They are (hopefully measurable) performance characteristics of the interaction technique. If cost is the most important value to an application designer, that could be specified with the performance requirements, as described above. By the way, anyone who would like to take a look at some of these ideas in more detail should feel free to peruse my thesis proposal presentation at: http://www.cc.gatech.edu/gvu/people/Phd/Doug.Bowman/proposal/ --Doug -- Doug Bowman, Ph.D. Candidate College of Computing, GVU Center, Georgia Tech Room 388 CRB, (404) 894-5104 bowman@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Phd/Doug.Bowman/