From vrml-ui-owner@vag.vrml.org Tue Mar 18 01:33:54 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id BAA24031; Tue, 18 Mar 1997 01:33:53 -0500 Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by kether.vrml.org (8.7.5/1.0) with ESMTP id GAA05891 for ; Tue, 18 Mar 1997 06:31:40 GMT Received: from poplar.cs.brown.edu (poplar.cs.brown.edu [128.148.38.3]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id BAA08783 for ; Tue, 18 Mar 1997 01:32:52 -0500 (EST) From: Sascha Becker Received: (sab@localhost) by poplar.cs.brown.edu (8.7.1/BrownCS1.0) id BAA04332; Tue, 18 Mar 1997 01:32:49 -0500 (EST) Date: Tue, 18 Mar 1997 01:32:49 -0500 (EST) Message-Id: <199703180632.BAA04332@poplar.cs.brown.edu> To: vrml-ui@vag.vrml.org Subject: [vrml-ui] more on the Tri-Stratification of Widget Components Status: RO I want to try to re-state Pauli's widget stratification with some changes of my own, characterize each level according to whether or not it is spatial, visible, and mathematical, and then present some examples of components in each category. This kind of classification suggests a component-based widget architecture, which just makes me endlessly happy. * Level 1 is for "surfaces I use to intersect the mouse"-- these objects are spatial, and invisible, and for the most part non-mathematical (the browser does the math, not the VRML object.) They output spatial information, but in general it's raw spatial information, in object-space, unbounded, unmonged. Time controls can also fit in here, I think. * Level 2 is for "things that move in a particular way", or, to restate, "a simple way to interpret level 1 widget output." This level maps from one representation of spatial, object-space information to another, more constrained representation of the same information, ie, (to use Pauli's example), from representing the point of the click-ray's intersection with a SphereSensor as translation to representing it as a rotation. Changing the representation includes clamping the values, disallowing certain actions based on state, and changing discrete values into continuous. In Pauli's presentation, this level has geometry associated with it, though I think all the geometry should be inserted in Level 3; I don't see why you need geometry here, and in fact the geometry may depend on what the third level does (ie, the slider's thumb color changes as you drag.) This level filters the values input from Level 1 to create bounded dragging behavior. Filter scripts and compound-building scripts fit in to this level. It is purely mathematical, not sitting in space anywhere or having any associated geometry, assuming that the Level 1 widget will output a value in normalized object-space. This level determines the "feel" of a widget. * Level 3 is the first "useful" level of widgets-- I'm having a hard time coming up with a succinct phrase to describe this level. It maps from Level 2 widget output into the user-specified "space," ie, a value in between min and max for a slider. It also adds geometry (inactive in Pauli's stratification, both inactive and active in mine) affordances and create the "look" of a widget. Mapping into the desired output space feels like a fairly different operation than adding background geometry, although they both fit into the same stage of widget building, ie, taking a general spatialized interaction technique and turning it into a specific application of the widget. I think these mapping techniques deserve a seperate place in this taxonomy, because we'll want to reuse them-- how many times have you written the code that takes a value in between two arbitrary numbers and maps it into some other range? Maybe when you actually build a widget, you take one element from Level 1, tack on as many Level 2 objects as you need, then wrap it up with Level 3 to add geometry. Examples: Level 1: spatial, invisible, non-mathematical Sphere/Cylinder/PlaneSensors TimeSensors Level 2: non-spatial, non-visible, mathematical dragging on a plane constrained to dragging on a line mapping between coordinate systems or data representation clamping to legal ranges discretizing continous values, other type conversions logic gates math functions Level 3: spatial, visible, mathematical draggers with output values in user-specified range and user-specified geometry a clock that runs from 0 to 60 Questions: Where do compound widgets fit in? Level 4? How do interactions between these levels work? Figuring that out will be a good test of how strong this model is. -Sascha