From www-vrml-owner@vag.vrml.org  Sat Mar  1 20:15:08 1997
Return-Path: <www-vrml-owner@vag.vrml.org>
Received: from speckle.ncsl.nist.gov by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id UAA22266; Sat, 1 Mar 1997 20:15:07 -0500
Received: from kether.vrml.org (vrml.organic.com) by speckle.ncsl.nist.gov (4.1/SMI-3.2-del/cas.6)
	id AA24175; Sat, 1 Mar 97 20:14:57 EST
Received: from localhost (daemon@localhost) by kether.vrml.org (8.7.5/1.0) with SMTP id BAA18846; Sun, 2 Mar 1997 01:10:35 GMT
Received: by vag.vrml.org (bulk_mailer v1.5); Sun, 2 Mar 1997 01:09:15 +0000
Received: (from majordom@localhost) by kether.vrml.org (8.7.5/1.0) id BAA18773 for www-vrml-out; Sun, 2 Mar 1997 01:09:13 GMT
Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by kether.vrml.org (8.7.5/1.0) with ESMTP id BAA18769 for <www-vrml@vag.vrml.org>; Sun, 2 Mar 1997 01:09:07 GMT
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id UAA02227 for <www-vrml@vag.vrml.org>; Sat, 1 Mar 1997 20:10:13 -0500 (EST)
From: Sascha Becker <sab@cs.brown.edu>
Received: (sab@localhost) by point.cs.brown.edu (8.8.3/BrownCS1.0) id UAA23882; Sat, 1 Mar 1997 20:10:00 -0500 (EST)
Date: Sat, 1 Mar 1997 20:10:00 -0500 (EST)
Message-Id: <199703020110.UAA23882@point.cs.brown.edu>
To: www-vrml@vag.vrml.org
Subject: Widgets/UI/Navigation Working Group
Sender: owner-www-vrml@vag.vrml.org
X-Info: To remove yourself from this list, send the command "unsubscribe" to www-vrml-request@vag.vrml.org.
Precedence: bulk
Status: RO

User Interface and/or Widgets and/or Navigation Working Group

At VRML '97, Mark Pesce called for a standard of prototype widgets for
VRML 2.0. This idea triggered me to propose a "Widgets" working group,
which several people then suggested expanding to "User Interface" in
general. Dozens of people gave me their contact info and expressed
interest in that sort of working group. The question we now face is 
how many working groups do we form, and what each group's focus should
be. 

I see two possibilities:

One Group, Many Purposes
------------------------
In this scenario, we form a single umbrella group, "User Interface," 
and perhaps issue several RFP's, for each of several topics: widget
standards, navigation standards, and whatever people had in mind for
"user interface" specifically. 

One Group, One Purpose 
-------------------------- 
In this scenario, we form at least one group, "Widgets," with a narrow
focus: building a common set of VRML widgets, and a mechanism for
adjusting these widgets for particular applications. People interested
in broader topics of user interface, or different foci in the field,
would be free to start their own working groups.

I favor the second scenario, because IMHO user interface is too broad
and vague a topic to productively address as a whole. Widgets are a
more concrete problem domain, with a clear deliverable: a set of VRML
widgets. I am eager to help coordinate a Widgets working group.

What, exactly, do I mean by VRML widgets? Here's a few ideas, with
influences from Inventor and the Brown Graphics Group, among others
* Heads-Up Display (HUD) 
* Forms (a la HTML)
* Direct-Manip Geometries: vectors, line segments, points
* Buttons: toggle, radio, push
* Viewpoint manips
* Sliders
* etc.

Please contact me at sab@cs.brown.edu if you are interested in
participating in a Widgets or UI working group-- I'm especially
interested in your ideas on how our efforts could best be 
directed. 

-Sascha Becker
sab@cs.brown.edu
http://www.cs.brown.edu/research/graphics
http://www.cs.brown.edu/people/sab

From sab@cs.brown.edu  Sun Mar  2 17:57:50 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA01895; Sun, 2 Mar 1997 17:57:48 -0500
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id RAA14099; Sun, 2 Mar 1997 17:57:46 -0500 (EST)
Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id RAA01580; Sun, 2 Mar 1997 17:57:43 -0500 (EST)
Message-Id: <199703022257.RAA01580@point.cs.brown.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: gseidman@zing.ncsl.nist.gov
cc: sab@cs.brown.edu
Subject: thanks for your vrml-ui comments
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 02 Mar 1997 17:57:43 -0500
From: Sascha Becker <sab@cs.brown.edu>
Status: RO

May I re-post your comments to the discussion list I'm putting
together? (I'll include you on the list, as well.)

Your widgets work sounds like a good bit of fuel for discussion--
the problems you mention with particular widgets are, IMHO, worthy
of investigation by a larger group with a shared goal of building
a standardized 3D widget library. If a group of us builds a
requirements document, then  requests and reviews proposals 
for a widget library, we can eventually present the VRB with
what we think is the best way to standardize VRML widgetry. 
Endorsement by the VRB would hopefully mean not a spec change
but becoming a "recommended practice" for browser writers to
implement and support; this is the way lots of the working
groups' output will be brought to light. 

As for the brown cs program, it sounds like you're a great
match for the graphics lab, and they'd have to be wearing
very dark glasses to miss that. A lot of the VRML heavy hitters
(including myself) will be graduating this may, and Andy 
just got elected to the Consortium's Board of Directors-- 
are you starting to get the picture? If your application
didn't include mention of your work with VRML and 3D widgets,
why don't you drop andy a line yourself, avd@cs.brown.edu,
and describe your work briefly? 

-Sascha

From sab@cs.brown.edu  Mon Mar  3 13:55:57 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id NAA12738; Mon, 3 Mar 1997 13:55:55 -0500
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id NAA02204; Mon, 3 Mar 1997 13:55:41 -0500 (EST)
Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id NAA07456; Mon, 3 Mar 1997 13:55:28 -0500 (EST)
Message-Id: <199703031855.NAA07456@point.cs.brown.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: Bernie Roehl <broehl@ece.uwaterloo.ca>
cc: bill@yisup.com (Bill Enright), pell@newfire.com, sulam@construct.net,
        steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net,
        misty@well.com, matsuda@arch.sony.co.jp, joel@blacksun.com,
        shags@nortel.com, pauli@sgi.com, braden@shadow.net,
        michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com,
        gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk,
        dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com,
        w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com,
        erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu,
        ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com,
        philippe@vdi.com, gseidman@zing.ncsl.nist.gov, jch@jch.com,
        bl@pobox.com
Subject: Re: vrml-ui/vrml-widgets 
In-reply-to: Your message of "Mon, 03 Mar 1997 10:29:25 EST."
             <199703031529.KAA29943@watt.uwaterloo.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 03 Mar 1997 13:55:28 -0500
From: Sascha Becker <sab@cs.brown.edu>
Status: RO

Bernie wrote: 
>
>Are we planning to look strictly at navigation, or are we interested in
>examining manipulation as well?  Certainly navigating through 3D space and
>moving an object through 3D space have many elements in common.
>

I'm personally interested in manipulation more than navigation, 
but there's probably a good deal of overlap. If I implement
slider, dashboard, pushbutton, and trackball widgets as PROTO'S
with configurable geometry, then (shazam!) I can implement the
cosmo dashboard with any geometry I like. In other words, part
of navigation ui is just the general widgets problem applied to
a bound viewpoint. 

In private mail to me, there's been significantly more
interest in a widgets-only group than a more general ui group. 

Perhaps mapping out the problems we're facing would help us
to define our goals-- here's a rough list I've created, please
contribute more. (Note that I don't think that all of these
issues are necessarily appropriate for a widgets group-- this
list is more intended as grounds for discussion about  

* Spatial Navigation 
	- navigation controls that a world author can 
configure to be appropriate to each world, both in terms
of geometry and behavior. 
	- a mechanism for browser sensitivity to user 
preferences for navigation, ie, "start up with a walk
viewer if the file doesn't specify otherwise." 
	- non-standard devices to control navigation, so that
a user can decide to drive the fly viewer with a joystick or
the examiner viewer with a spaceball.
	- a mechanism for specifying additional basic viewer
types, beyond examine/walk/fly. 
	- standards for keyboard navigation-- which keys are
used, what they mean in each viewer type.

* WWW Navigation/Information
	- mechanisms for world authors to specify how the presence of
anchors in the scene will be revealed. This is another case of
"the ui is the content is the ui"-- an inappropriate cue could 
disrupt the feel of the world.
	- similar mechanisms for specifying the appearance of an
inline while it's loading
	- ditto for textures.

* Widgetry
	- Joel Dubiner's list:
> A text entry area
> A Cursor/Caret insertion point
> Scroll Bars
> Drop Down/Hierarchical Menus
> Slider Bars
> Tool Bar
> List Menu
> Minimize/Maximize/Resize controls
> Selection tool (with single and group selection semantics)
> Common idioms for selection states: unselected, activated, inactive,
> process pending
> Radio Buttons
> Check Boxes
> User Prompt (status line)
> Context-sensitive help (baloon help)
	- Valuators: geometry widgets that spit out values. I expect
these will be helpful in building simple interactive systems, when
combined with routes. 
	- Layout tools for widgets. I'd like to be able to make a row/column
grid of widgets, size them all down to fit a particular region of space, then
make all of that a child of a billboard node. 
 
* Devices:
	- standard mechanism for using 3D and 6D input devices in VRML
browsers. It would be good if device manufacturers could write a single
driver that would work for all the browsers. 
	- picking metaphors for >2D input devices-- it gets a lot more
complicated, especially with a very jumpy device. Without careful ui 
design, lots of >2D interface devices are useless for picking, only good
for navigation. Brown's done some work on this in the last few years--
contact me for references, or see http://www.cs.brown.edu/research/graphics/res
earch/pub
 	- stereo viewers-- either the user or the world author needs
to specify things like interocular distance, minimum frame rate for
stereo, fishbowl vr vs. immersive vr, etc. 

* Implementation issues:
	- Architecture: will the extensions we want be implemented as
PROTOs, reserved-word PROTOS, more official nodes (I just threw that
in for the sake of completeness; changing the spec is *not* a goal of
mine wherever possibly avoidable)
	- Manpower: should the output of our group simply be a 
document, RFPs, and recommendations on proposals we receive, or
should we try as a group to solve the problems we select? 

Please not a revised list of recipients. I'll get us on an
official mailing list within a few days. 

-Sascha

From broehl@ece.uwaterloo.ca  Mon Mar  3 15:33:02 1997
Return-Path: <broehl@ece.uwaterloo.ca>
Received: from ece.uwaterloo.ca by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id PAA13113; Mon, 3 Mar 1997 15:32:59 -0500
Received: from watt.uwaterloo.ca (watt.uwaterloo.ca [129.97.56.5])
	by ece.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id PAA13888;
	Mon, 3 Mar 1997 15:32:17 -0500 (EST)
From: Bernie Roehl <broehl@ece.uwaterloo.ca>
Received: (from broehl@localhost)
	by watt.uwaterloo.ca (8.8.5/8.8.5) id PAA02177;
	Mon, 3 Mar 1997 15:32:15 -0500 (EST)
Message-Id: <199703032032.PAA02177@watt.uwaterloo.ca>
Subject: Re: vrml-ui/vrml-widgets
To: sab@cs.brown.edu (Sascha Becker)
Date: Mon, 3 Mar 1997 15:32:12 -0500 (EST)
Cc: broehl@ece.uwaterloo.ca, bill@yisup.com, pell@newfire.com,
        sulam@construct.net, steve@division.com, brush@vnet.ibm.com,
        cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch,
        munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, joel@blacksun.com, shags@nortel.com,
        pauli@sgi.com, braden@shadow.net, michaelp@netscape.com,
        kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com,
        dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu,
        slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov,
        matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil,
        bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com,
        thinktank@infomaniacs.com, robert@oz.com, philippe@vdi.com,
        gseidman@zing.ncsl.nist.gov, jch@jch.com, bl@pobox.com
In-Reply-To: <199703031855.NAA07456@point.cs.brown.edu> from "Sascha Becker" at Mar 3, 97 01:55:28 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: RO

Sascha Becker writes:
> I'm personally interested in manipulation more than navigation, 
> but there's probably a good deal of overlap. If I implement
> slider, dashboard, pushbutton, and trackball widgets as PROTO'S
> with configurable geometry, then (shazam!) I can implement the
> cosmo dashboard with any geometry I like. In other words, part
> of navigation ui is just the general widgets problem applied to
> a bound viewpoint. 

I definitely agree.  I was just a bit concerned because many of the
messages to this list have specifically mentioned navigation.
 
> 	- Layout tools for widgets. I'd like to be able to make a row/column
> grid of widgets, size them all down to fit a particular region of space, then
> make all of that a child of a billboard node. 

That's an interesting thought.  Of course, that widget grid would itself
be a widget.

> * Devices:
> 	- standard mechanism for using 3D and 6D input devices in VRML
> browsers. It would be good if device manufacturers could write a single
> driver that would work for all the browsers. 

Right, agreed.  Under Windows95, that's already in place (DirectInput),
and I believe there's something analogous to that in the Mac world.
So far as I know, there's no standard for 3D and 6D input devices under
Unix.  Of course, it would be even better if the device manufacturers
would agree on a standard over-the-wire protocol, at least for serial
devices.

> 	- picking metaphors for >2D input devices-- it gets a lot more
> complicated, especially with a very jumpy device.

Yes, agreed.  It's fortunate that the various "sensor" nodes (notably
the TouchSensor) were redesigned a while back to make them suitable for
use in immersive environments.

>  	- stereo viewers-- either the user or the world author needs
> to specify things like interocular distance, minimum frame rate for
> stereo, fishbowl vr vs. immersive vr, etc. 

Hmm... to me, that's a browser issue.

-- 
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: broehl@sunee.uwaterloo.ca    Voice:  (519) 888-4567 x 2607 [work]
   URL: http://sunee.uwaterloo.ca/~broehl/bernie.html

From sab@cs.brown.edu  Mon Mar  3 15:35:28 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id PAA13136; Mon, 3 Mar 1997 15:35:26 -0500
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id OAA03581; Mon, 3 Mar 1997 14:39:45 -0500 (EST)
Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id OAA08001; Mon, 3 Mar 1997 14:39:38 -0500 (EST)
Message-Id: <199703031939.OAA08001@point.cs.brown.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: Bernie Roehl <broehl@ece.uwaterloo.ca>
cc: joel@blacksun.com (Joel Dubiner), bill@yisup.com, pell@newfire.com,
        sulam@construct.net, steve@division.com, brush@vnet.ibm.com,
        cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch,
        munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com,
        braden@shadow.net, michaelp@netscape.com, kluster@sgi.com,
        riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu,
        jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com,
        houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com,
        rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com,
        athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com,
        robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com,
        jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu,
        vidinick@aol.com
Subject: Re: vrml-ui/vrml-widgets: Widget List 
In-reply-to: Your message of "Mon, 03 Mar 1997 13:53:56 EST."
             <199703031853.NAA01428@watt.uwaterloo.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 03 Mar 1997 14:39:36 -0500
From: Sascha Becker <sab@cs.brown.edu>
Status: RO

In message <199703031853.NAA01428@watt.uwaterloo.ca>, Bernie Roehl writes:
[quotes Joel's list of 2D widgets]
>Almost all of the above are strictly 2D metaphors, mostly text-oriented.
>I doubt if there's much to be gained from having text-oriented widgets
>in a 3D environment, since text entry and editing is really a 2D activity.

The advantage of 2D or text widgets that exist in a 3D scene is simply that 
they allow the user to perform non-spatial tasks in a semi-immersive 
space. This capability is desirable when the 2D widgets are controlling
an aspect of the 3D scene (ie, the brightness of a spotlight) or 
referring to a component of the 3D scene (ie, a form next to a sculpture
in a virtual museum that records the users comments on the sculpture.) 
Putting these controls directly in the scene enriches the metaphor 
(lighting technichian in a theatre, visitor to a gallery) where seperate
2D widgets might interfere with it. 

>The rest of Joel's list is much more interesting:
>
>> Slider Bars
>> Tool Bars
>> Selection tool (with single and group selection semantics)

*** don't forget hierarchical selection semantics, ie, how does
the user indicate whether a click on a model's right index
finger refers to the finger, hand, forearm, arm, or the entire
model? 

>> Common idioms for selection states: unselected, activated, inactive,
>> Radio Buttons
>> Check Boxes
>
>All of these are potentially adaptable to a 3D context.
>
>In addition, we should be looking for  widgets that are by their
>very nature three-dimensional.  I think we would do well to look
>to the real world for guidance in finding those widgets.
>Cindy's steering wheel is the first example that springs to mind, of
>course.

I completely agree-- I think that's where the work of this group
will get very interesting. 

>What we need to do is identify new types of widgets that are suitable for
>a 3D (and potentially immersive) environment.  Much as I dislike Cosmo
>Player's controls, they're a step in the right direction.

[...]

>Joel proposes:
>> 
>> 1) informal brainstorming for another week or so, then:
>> 2) the creation of a list of class names and behaviors
>> 3) the creation of a formal design document
>> 4) the creation of a standard EXTERN_PROTO library for UI widgets
>
>That sounds reasonable.
>

I'm worried about committing a working group to delivering 
an _implementation_ of a widget library, as opposed to issuing
a set of requirements and then selecting from a variety of 
implementations. (I'm thinking of the initial VRML 2.0 standard
selection process as a model.) I guess the point is moot if no-one
other than the members of this list are actually interested in 
developing such a library. 

-Sascha

From www-vrml-owner@vag.vrml.org  Mon Mar  3 16:20:11 1997
Return-Path: <www-vrml-owner@vag.vrml.org>
Received: from speckle.ncsl.nist.gov by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id QAA13352; Mon, 3 Mar 1997 16:20:09 -0500
Received: from  by speckle.ncsl.nist.gov (4.1/SMI-3.2-del/cas.6)
	id AB03491; Mon, 3 Mar 97 16:18:20 EST
Received: from localhost (daemon@localhost) by kether.vrml.org (8.7.5/1.0) with SMTP id TAA04894; Mon, 3 Mar 1997 19:29:48 GMT
Received: by vag.vrml.org (bulk_mailer v1.5); Mon, 3 Mar 1997 19:28:37 +0000
Received: (from majordom@localhost) by kether.vrml.org (8.7.5/1.0) id TAA04756 for www-vrml-out; Mon, 3 Mar 1997 19:28:35 GMT
Received: from glacier.binc.net (glacier.binc.net [205.173.176.10]) by kether.vrml.org (8.7.5/1.0) with SMTP id TAA04743 for <www-vrml@vag.vrml.org>; Mon, 3 Mar 1997 19:28:27 GMT
Received: from xxx.binc.net by glacier.binc.net (8.6.12/4.03)
          id NAA25790; Mon, 3 Mar 1997 13:29:28 -0600
Message-Id: <331B25AC.31AD@mailbag.com>
Date: Mon, 03 Mar 1997 13:25:32 -0600
From: Gavin Bell <gavin@mailbag.com>
Reply-To: gavin@acm.org
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: www-vrml@vag.vrml.org
Cc: rikk@best.com
Subject: Reminder: Review the VRML97 Editor's Draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-www-vrml@vag.vrml.org
X-Info: To remove yourself from this list, send the command "unsubscribe" to www-vrml-request@vag.vrml.org.
Precedence: bulk
Status: RO

Another reminder:

There is a new version of the VRML 2.0 spec available at: 

http://vag.vrml.org/VRML97/DIS/
 or
http://vrml.sgi.com/moving-worlds/spec.DIS/

PLEASE:  Take a close look at it and help the editors (Rikk Carey and
Dick Puk) find the mistakes in it.  Rikk will be posting a list of major
changes (all of which are quite minor) soon.

If you are implementing or have implemented part of a browser, I would
particularly encourage you to take the time to read the parts of the
spec that apply to what you've implemented. We might have changed
something inadvertently, or the spec might have been clarified in a way
that makes your implementation non-conformant.  If you're managing a
team implementing a browser or tool: make them read the new spec, your
products will work better and you won't kick yourself when you find out
it is too late for us to fix some problem in the spec that makes it
impossible for your product to work correctly...

If you do find problems: Please bundle them together (it is much harder
to deal with a constant stream of tiny email messages) and send them to
Rikk Carey, rikk@best.com.  As always, www-vrml is the place to discuss
anything that might be controversial or non-obvious.

-- 
Gavin Bell -- gavin@acm.org -- http://www.mailbag.com/users/gavin

From broehl@ece.uwaterloo.ca  Mon Mar  3 16:27:07 1997
Return-Path: <broehl@ece.uwaterloo.ca>
Received: from ece.uwaterloo.ca by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id QAA13442; Mon, 3 Mar 1997 16:27:03 -0500
Received: from watt.uwaterloo.ca (watt.uwaterloo.ca [129.97.56.5])
	by ece.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id PAA14093;
	Mon, 3 Mar 1997 15:44:29 -0500 (EST)
From: Bernie Roehl <broehl@ece.uwaterloo.ca>
Received: (from broehl@localhost)
	by watt.uwaterloo.ca (8.8.5/8.8.5) id PAA02300;
	Mon, 3 Mar 1997 15:44:27 -0500 (EST)
Message-Id: <199703032044.PAA02300@watt.uwaterloo.ca>
Subject: Re: vrml-ui/vrml-widgets: Widget List
To: sab@cs.brown.edu (Sascha Becker)
Date: Mon, 3 Mar 1997 15:44:26 -0500 (EST)
Cc: broehl@ece.uwaterloo.ca, joel@blacksun.com, bill@yisup.com,
        pell@newfire.com, sulam@construct.net, steve@division.com,
        brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net,
        misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com,
        pauli@sgi.com, braden@shadow.net, michaelp@netscape.com,
        kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com,
        dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu,
        slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov,
        matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil,
        bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com,
        thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov,
        philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca,
        sab@cs.brown.edu, vidinick@aol.com
In-Reply-To: <199703031939.OAA08001@point.cs.brown.edu> from "Sascha Becker" at Mar 3, 97 02:39:36 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: RO

Sascha Becker:
> *** don't forget hierarchical selection semantics, ie, how does
> the user indicate whether a click on a model's right index
> finger refers to the finger, hand, forearm, arm, or the entire
> model? 

Absolutely.

> I'm worried about committing a working group to delivering 
> an _implementation_ of a widget library, as opposed to issuing
> a set of requirements and then selecting from a variety of 
> implementations. (I'm thinking of the initial VRML 2.0 standard
> selection process as a model.)

You know, I'm not sure that the two situations are really the same.
Certainly widget specification and construction has the potential
to be an open-ended, ongoing activity -- unlike the VRML 2.0 standard
process which was very specifically focussed.

I think we need to:

 1. Describe (at least in general terms) how widgets should be designed

 2. Organize a list of the kinds of widgets people would find useful in
    VRML, and who's working on creating them

The first gives developers some guidelines, the second helps us avoid
getting five different steering wheels and no toggle switches (for example).

> I guess the point is moot if no-one
> other than the members of this list are actually interested in 
> developing such a library. 

I think that's *very* likely.  After all, just turn it around: Anyone
who's interesting in developing such a library will probably join the list.

-- 
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: broehl@sunee.uwaterloo.ca    Voice:  (519) 888-4567 x 2607 [work]
   URL: http://sunee.uwaterloo.ca/~broehl/bernie.html

From sab@cs.brown.edu  Mon Mar  3 16:46:16 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id QAA13751; Mon, 3 Mar 1997 16:46:12 -0500
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id QAA07229; Mon, 3 Mar 1997 16:34:29 -0500 (EST)
Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id QAA12120; Mon, 3 Mar 1997 16:34:10 -0500 (EST)
Message-Id: <199703032134.QAA12120@point.cs.brown.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: Bernie Roehl <broehl@ece.uwaterloo.ca>
cc: joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net,
        steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com,
        braden@shadow.net, michaelp@netscape.com, kluster@sgi.com,
        riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu,
        jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com,
        houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com,
        rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com,
        athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com,
        robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com,
        jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com,
        john.martellaro@lmco.com, rcg@rd.engr.sgi.com, mpesce@netcom.com,
        jonpruyn@inkstone.com, sab@cs.brown.edu
Subject: vrml-widgets group output [Was Re: vrml-ui/vrml-widgets: Widget List] 
In-reply-to: Your message of "Mon, 03 Mar 1997 15:44:26 EST."
             <199703032044.PAA02300@watt.uwaterloo.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 03 Mar 1997 16:34:10 -0500
From: Sascha Becker <sab@cs.brown.edu>
Status: RO

In message <199703032044.PAA02300@watt.uwaterloo.ca>, Bernie Roehl writes:
>Sascha Becker:
>> I'm worried about committing a working group to delivering 
>> an _implementation_ of a widget library, as opposed to issuing
>> a set of requirements and then selecting from a variety of 
>> implementations. (I'm thinking of the initial VRML 2.0 standard
>> selection process as a model.)
>
>You know, I'm not sure that the two situations are really the same.
>Certainly widget specification and construction has the potential
>to be an open-ended, ongoing activity -- unlike the VRML 2.0 standard
>process which was very specifically focussed.
>
>I think we need to:
>
> 1. Describe (at least in general terms) how widgets should be designed
>
> 2. Organize a list of the kinds of widgets people would find useful in
>    VRML, and who's working on creating them
>
>The first gives developers some guidelines, the second helps us avoid
>getting five different steering wheels and no toggle switches (for example).

For #1, above, I think we can and should get rather specific
about the technical details of how widgets should be _implemented_,
though perhaps remain vague about the fuzzy issues of widget
_design_. That is, I think we need some naming conventions 
for widgets, guidelines for poly count and scene graph structure, 
a standard mechanism for documenting the widgets' behaviors, 
(both at user-level and author-level), and a model for how 
widgets will be used in the scene (ie, SFFields for input 
and output values, positioning external or internal to the 
widget, particularly relevant for widgets subject to a layout 
manager.) I also think we need a central repository for 
wg-blessed widget implementations and their documentation. 

Also, your breakdown above leaves out the possibility
of multiple versions of the same widget, each of which
have the same behavior but different geometry. If the
steering wheel I write is sufficiently general, I'd 
like to be able to plug in geometry for a porsche 
steering wheel, a caddy, an indycar, etc. Buzzwords:
allow the user to modify "look" without touching "feel."

>
>> I guess the point is moot if no-one
>> other than the members of this list are actually interested in 
>> developing such a library. 
>
>I think that's *very* likely.  After all, just turn it around: Anyone
>who's interesting in developing such a library will probably join the list.
>

Agreed. Our numbers swell hourly... 

From broehl@ece.uwaterloo.ca  Mon Mar  3 17:07:09 1997
Return-Path: <broehl@ece.uwaterloo.ca>
Received: from ece.uwaterloo.ca by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA13964; Mon, 3 Mar 1997 17:07:05 -0500
Received: from watt.uwaterloo.ca (watt.uwaterloo.ca [129.97.56.5])
	by ece.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id QAA16688;
	Mon, 3 Mar 1997 16:56:13 -0500 (EST)
From: Bernie Roehl <broehl@ece.uwaterloo.ca>
Received: (from broehl@localhost)
	by watt.uwaterloo.ca (8.8.5/8.8.5) id QAA03436;
	Mon, 3 Mar 1997 16:56:09 -0500 (EST)
Message-Id: <199703032156.QAA03436@watt.uwaterloo.ca>
Subject: Re: vrml-widgets group output [Was Re: vrml-ui/vrml-widgets: Widget List]
To: sab@cs.brown.edu (Sascha Becker)
Date: Mon, 3 Mar 1997 16:56:08 -0500 (EST)
Cc: broehl@ece.uwaterloo.ca, joel@blacksun.com, bill@yisup.com,
        pell@newfire.com, sulam@construct.net, steve@division.com,
        brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com,
        braden@shadow.net, michaelp@netscape.com, kluster@sgi.com,
        riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu,
        jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com,
        houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com,
        rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com,
        athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com,
        robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com,
        jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com,
        john.martellaro@lmco.com, rcg@rd.engr.sgi.com, mpesce@netcom.com,
        jonpruyn@inkstone.com, sab@cs.brown.edu
In-Reply-To: <199703032134.QAA12120@point.cs.brown.edu> from "Sascha Becker" at Mar 3, 97 04:34:10 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: RO

Sascha Becker writes:
> I think we can and should get rather specific
> about the technical details of how widgets should be _implemented_,
> though perhaps remain vague about the fuzzy issues of widget
> _design_. That is, I think we need some naming conventions 
> for widgets, guidelines for poly count and scene graph structure, 
> a standard mechanism for documenting the widgets' behaviors, 
> and a model for how  widgets will be used in the scene

To me, those are design issues rather than implementation -- but it's
clear that we agree on what needs to be specified.

The reason I would like to see hardware devices (such as joysticks and
spaceballs and whatnot) included under "widgets" is because they
would have most of those same properties.  And the issue of whether a
user moves around by using a real trackball or a virtual one should be
determined strictly by whether or not a real one is available to them.

> I also think we need a central repository for 
> wg-blessed widget implementations and their documentation. 

Definitely.  Probably on the Consortium site...?

> Also, your breakdown above leaves out the possibility
> of multiple versions of the same widget, each of which
> have the same behavior but different geometry.

Good point.  I would suggest that each widget have a default
geometry which can be overridden when the widget is instanced.

-- 
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: broehl@sunee.uwaterloo.ca    Voice:  (519) 888-4567 x 2607 [work]
   URL: http://sunee.uwaterloo.ca/~broehl/bernie.html

From robert@oz.com  Mon Mar  3 17:22:13 1997
Return-Path: <robert@oz.com>
Received: from xanadu.oz.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA14041; Mon, 3 Mar 1997 17:22:11 -0500
Received: from robofly 
	by xanadu.oz.com (8.8.3/OZnet/12-01-97); Mon, 3 Mar 1997 15:41:44 -0800
Message-Id: <3.0.32.19970304013625.008cf210@xanadu.oz.com>
X-Sender: robert@xanadu.oz.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 04 Mar 1997 01:36:39 -0800
To: Sascha Becker <sab@cs.brown.edu>, Bernie Roehl <broehl@ece.uwaterloo.ca>
From: Robert Bjarnason <robert@oz.com>
Subject: Re: vrml-ui/vrml-widgets: Widget List 
Cc: joel@blacksun.com (Joel Dubiner), bill@yisup.com, pell@newfire.com,
        sulam@construct.net, steve@division.com, brush@vnet.ibm.com,
        cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch,
        munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com,
        braden@shadow.net, michaelp@netscape.com, kluster@sgi.com,
        riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu,
        jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com,
        houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com,
        rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com,
        athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com,
        gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com,
        bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu, vidinick@aol.com,
        gunnar@this.is, ragnar@this.is, ramman@centrum.dk, mpesce@netcom.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: RO

Hi,

[>-Sascha wrote:]

>The advantage of 2D or text widgets that exist in a 3D scene is simply that 
>they allow the user to perform non-spatial tasks in a semi-immersive 
>space. This capability is desirable when the 2D widgets are controlling
>an aspect of the 3D scene (ie, the brightness of a spotlight) or 
>referring to a component of the 3D scene (ie, a form next to a sculpture
>in a virtual museum that records the users comments on the sculpture.) 
>Putting these controls directly in the scene enriches the metaphor 
>(lighting technichian in a theatre, visitor to a gallery) where seperate
>2D widgets might interfere with it. 

After being the head of the lighting departament @ the Icelandic Opera for
almost two year's, I really identify with virtual lightning tech guy. I've
designed light's for operas like Othello and the Magic Flute. I want to
share with you a little fantasy that takes place in cyberspace.

{

I turn on my VRML console, [select] the show/opera/play I'm working on. I
immerse into they scene @ they same location as when I turned off my
console last night. I'm currently in OB (Out of body) mode, I walk my
avatar around in the set. I stop by the bed, I [command] my avatar to sit
down. Then I [turn] my viewpoint so I'm facing my avatar and [zoom] in to
his head.

I [hit] the Widgets hotkey and a 3D VRML selection panel unfolds from the
left of me. I [select] the time line, I [slide] through time until I'm in
Act IV, light cue 298, I [select]. I [hit] the main Widgets hotkey and the
3D VRML panel folds back and disappears.

There is an light blue (cold) light on my avatars face, I look up from the
VRML console and [grab] the script, that is beside the console on my
(real/unreal) living room table. I [look] up Act IV, "oh, no" I must have
been sleepy last night, the ghost doesn't appear until in cue 299 and
things have to be warm until then because this is the most romantic scene
in this whole techno-opera.

I look back @ the console, [hit] my control panel key, [select] the light
grid. The scene it self goes 75% transparent and fly's into the background,
3D grid with all my lights appears. I quickly [select] all the lights I
need with my pointing device. I [select] the color module
(http://wish.i.had.alink.to.mpesce's.vrml97.demo/) and [give] the light
approximately the right flavor. I [hit] the panel hide button and it's
folds back and disappears.

I'm back in the scene, I still have the [controls] for the brightness of
all the [selected] lights, I [zoom] out from my avatar and look @ it from
[many] viewpoints and [adjust] the color heat @ the same time until I'm
happy ...

}

With warm regards,

Robert Vidar Bjarnason
Ambassador
robert@oz.com

From robert@oz.com  Mon Mar  3 19:49:42 1997
Return-Path: <robert@oz.com>
Received: from xanadu.oz.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id TAA15110; Mon, 3 Mar 1997 19:49:40 -0500
Received: from robofly 
	by xanadu.oz.com (8.8.3/OZnet/12-01-97); Mon, 3 Mar 1997 18:10:28 -0800
Message-Id: <3.0.32.19970304040508.007b9340@xanadu.oz.com>
X-Sender: robert@xanadu.oz.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 04 Mar 1997 04:05:21 -0800
To: Sascha Becker <sab@cs.brown.edu>, Bernie Roehl <broehl@ece.uwaterloo.ca>
From: Robert Bjarnason <robert@oz.com>
Subject: Thoughts on Layers
Cc: joel@blacksun.com (Joel Dubiner), bill@yisup.com, pell@newfire.com,
        sulam@construct.net, steve@division.com, brush@vnet.ibm.com,
        cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch,
        munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com,
        braden@shadow.net, michaelp@netscape.com, kluster@sgi.com,
        riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu,
        jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com,
        houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com,
        rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com,
        athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com,
        gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com,
        bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu, vidinick@aol.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: RO

Hi,

Where do the widgets fit in the layer system of our being ?

Proposal>

(int) Layer 1 - (reserved)
(int) Layer 2 - The soul
(int) Layer 3 - Unconsciousness
(ext) Layer 4 - Consciousness
(ext) Layer 5 - Our body
(ext) Layer 6 - The keyboard
(ext) Layer 7 - The Widgets
(int) Layer 8 - Content

Our goal is to try to connect L2 to L8. Then L2 routes back info into L4.
L7 is mission critical, if it's not enable to communicate transparently to
L3 we have a broken chain. L4 must not have to deal with L7 except in the
learning phaze of L7.

With warm regards,

Robert Vidar Bjarnason
Ambassador
robert@oz.com

From pauli@uniblab.engr.sgi.com  Mon Mar  3 20:23:06 1997
Return-Path: <pauli@uniblab.engr.sgi.com>
Received: from sgi.sgi.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id UAA15210; Mon, 3 Mar 1997 20:23:03 -0500
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15395; Mon, 3 Mar 1997 17:20:37 -0800
Received: from uniblab.engr.sgi.com (uniblab.engr.sgi.com [198.29.108.116]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA04519; Mon, 3 Mar 1997 17:20:21 -0800
Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA23816; Tue, 4 Mar 1997 01:18:36 GMT
From: "Paul Isaacs" <pauli@uniblab.engr.sgi.com>
Message-Id: <9703031718.ZM23814@uniblab.engr.sgi.com>
Date: Mon, 3 Mar 1997 17:18:34 -0800
In-Reply-To: Bernie Roehl <broehl@ece.uwaterloo.ca>
        "Re: vrml-ui/vrml-widgets: Widget List" (Mar  3,  3:44pm)
References: <199703032044.PAA02300@watt.uwaterloo.ca>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Bernie Roehl <broehl@ece.uwaterloo.ca>, sab@cs.brown.edu (Sascha Becker)
Subject: Re: vrml-ui/vrml-widgets: Widget List
Cc: joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net,
        steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net,
        misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com,
        pauli@sgi.com, braden@shadow.net, michaelp@netscape.com,
        kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com,
        dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu,
        slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov,
        matt@cicadaweb.com, rob@relay.engr.SGI.COM,
        erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu,
        ouch@relay.engr.SGI.COM, thinktank@infomaniacs.com, robert@oz.com,
        gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com,
        bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com"
Status: RO

--
--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
Content-Type: text/plain; charset=us-ascii

Hi everyone,

I'm glad this group has formed and I'm sure I'll have plenty to say as time
goes by.  As far as approach and organization, I'll sit back for now since I
mostly agree with what's been said. In particular, I like Mike Pell's comments
on Widgets:

    "I believe that the working group should _not_ try to propose or impose an
    "official" set of user interface widgets on authors or the Consortium. What
    would be great, in my opinion, is for the working group to publish a set of
    high quality widgets for authors to either use either "as is" or to extend
    to their fit their needs. As much as I see the value in standardization in
    user interface widgets for operating systems, I also see it as stifling
    creativity. The consumers of VRML content will ultimately decide which
    "look and feel" suits their own needs. Let's encourage experimentation by
    authors, but give them a solid base to work from.

In this spirit, and just for fun, I've attached some PROTOs I've been using for
a project I'm working on.  They (or some variation) may prove useful as
building blocks for a widget set.  If not, some of you may enjoy using them
anyway.

The two protos roughly correspond to the Inventor classes SoTranslate1Dragger
and SoTranslate2Dragger.  They add two configurable geometries and appearances
to the PlaneSensor for a two-state draggable object. One appearance/geometry
combo is shown in the inactive state, the other is shown while the object is
being dragged. The first may be dragged in a line (min/max will apply) and the
second may be dragged in a plane.

I'll be making other classes to complete the Inventor suite of 'simple
draggers' and I'll be happy to share these as they develop. My feeling is that
any widget set will need a set of dragger-like PROTOS as a support layer.

To try these, you'll need to stick all 6 attached files in one directory,
then read the test files into your browser.  The attached files are:

testTranslate1Dragger.wrl
testTranslate2Dragger.wrl
       Each of these contains a couple of draggers used in different ways.
       They show how the geometry can be changed and a couple use the min/max
       features to limit motion.

translate1DraggerProto.wrl
translate2DraggerProto.wrl
       These are the PROTO files for the two dragger classes.

geometryProtos.wrl
appearanceProtos.wrl
       PROTOs for some geometries and appearances that I use frequently.

Implementation Gotcha:
The tricky part about turning a SENSOR into a dragger is insuring that:
[1] You can put the dragger somewhere by setting an input field
[2] You can know where the dragger is placed by reading an output field.
Getting this right is tricky, because the only way to put the sensor somewhere
is to set its set_offset field.  However outputs can come from the sensor in
two places (offset_changed and translation_changed) and you have to monitor
both of these to get the desired result.
So you have to connect the input to the Sensor's set_offset
field, and then you have to connect BOTH the Sensor's offset_changed and
translation_changed fields to the PROTO's output field. (I chose to do this
indirectly by routing these first to the Geometry's translation and then
from the Geometry's translation to the PROTO's output).

Everything else is fairly straightforward.
I chose to make the myGeometry and myActiveGeometry fields be actual geometry
nodes.  For true generality, it would probably be better to allow these to
be arbitrary scene graphs and stick them in toto inside the dragger instead
of setting them as a geometry field.

pauli.

-- 
  

Paul Isaacs, pauli@sgi.com          Cosmo VRML Engineering, Silicon Graphics

---- New York Serenity Prayer:   -------------------------------------------
God give me the strength to crush those in my way, the money to bribe 
those who can help me, and the wisdom to know the difference.

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
X-Zm-Content-Name: testTranslate1Dragger.wrl
Content-Description: Text
Content-Type: text/plain ; name="testTranslate1Dragger.wrl" ; charset=us-ascii

#VRML V2.0 utf8

EXTERNPROTO Blue []         "appearanceProtos.wrl#Blue"
EXTERNPROTO Magenta []      "appearanceProtos.wrl#Magenta"
EXTERNPROTO Red []          "appearanceProtos.wrl#Red"
EXTERNPROTO RylonFlames []  "appearanceProtos.wrl#RylonFlames"
EXTERNPROTO White []        "appearanceProtos.wrl#White"
EXTERNPROTO Yellow []       "appearanceProtos.wrl#Yellow"

EXTERNPROTO ArrowheadGeom []       "geometryProtos.wrl#ArrowheadGeom"
EXTERNPROTO Horizontal4UnitBar []  "geometryProtos.wrl#Horizontal4UnitBar"
EXTERNPROTO VerticalNubbin []      "geometryProtos.wrl#VerticalNubbin"

EXTERNPROTO Translate1Dragger [ 
			  exposedField SFNode myAppearance 
			  exposedField SFNode myGeometry 

			  exposedField SFNode myActiveAppearance 
			  exposedField SFNode myActiveGeometry 

			  field SFFloat maxPosition
			  field SFFloat minPosition

			  eventIn  SFVec3f translation_in
			  field    SFVec3f translation_init
			  eventOut SFVec3f translation_out

			  eventOut SFBool  isActive_out
			]
		"translate1DraggerProto.wrl"

Group {
    children [
	Transform {
	    translation 0 2 0
	    children Translate1Dragger {
		myAppearance Red {}
		myGeometry  Box {}
		myActiveAppearance Yellow {}
		myActiveGeometry  Cone {}
	    }
	}
	Transform {
	    children [
		Translate1Dragger {
		    myAppearance Magenta {}
		    myGeometry  VerticalNubbin {}
		    myActiveAppearance Yellow {}
		    myActiveGeometry  VerticalNubbin {}
		    minPosition -2
		    maxPosition 2
		}
		Shape {
		    appearance Blue {}
		    geometry Horizontal4UnitBar {}
		}
	    ]
	}
	Transform {
	    translation 0 -2 0
	    children Translate1Dragger {
		myAppearance RylonFlames {}
		myGeometry  ArrowheadGeom {}
		myActiveAppearance Yellow {}
		myActiveGeometry  ArrowheadGeom {}
		minPosition 0
		maxPosition 100
	    }
	}
    ]
}

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
X-Zm-Content-Name: testTranslate2Dragger.wrl
Content-Description: Text
Content-Type: text/plain ; name="testTranslate2Dragger.wrl" ; charset=us-ascii

#VRML V2.0 utf8

EXTERNPROTO Blue []         "appearanceProtos.wrl#Blue"
EXTERNPROTO Magenta []      "appearanceProtos.wrl#Magenta"
EXTERNPROTO Red []          "appearanceProtos.wrl#Red"
EXTERNPROTO RylonFlames []  "appearanceProtos.wrl#RylonFlames"
EXTERNPROTO White []        "appearanceProtos.wrl#White"
EXTERNPROTO Yellow []       "appearanceProtos.wrl#Yellow"

EXTERNPROTO Translate2Dragger [ 
			  exposedField SFNode myAppearance 
			  exposedField SFNode myGeometry 

			  exposedField SFNode myActiveAppearance 
			  exposedField SFNode myActiveGeometry 

			  field SFVec2f maxPosition
			  field SFVec2f minPosition

			  eventIn  SFVec3f translation_in
			  field    SFVec3f translation_init
			  eventOut SFVec3f translation_out

			  eventOut SFBool  isActive_out
			]
		"translate2DraggerProto.wrl"

Group {
    children [
	Transform {
	    translation 0 2 0
	    children Translate2Dragger {
		myAppearance Red {}
		myGeometry  Box {}
		myActiveAppearance Yellow {}
		myActiveGeometry  Cone {}
	    }
	}
	Transform {
	    children [
		Translate2Dragger {
		    myAppearance Magenta {}
		    myGeometry  Sphere { radius .1 }
		    myActiveAppearance Yellow {}
		    myActiveGeometry  Sphere { radius .1}
		    minPosition -.5 -.5
		    maxPosition .5 .5
		    translation_init -.5 -.5 0
		}
		Shape {
		    appearance Blue {}
		    geometry Box { size 1 1 .05 }
		}
	    ]
	}
    ]
}

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
X-Zm-Content-Name: translate1DraggerProto.wrl
Content-Description: Text
Content-Type: text/plain ; name="translate1DraggerProto.wrl" ; charset=us-ascii

#VRML V2.0 utf8

PROTO Translate1Dragger [ 
			  exposedField SFNode myAppearance Appearance {}
			  exposedField SFNode myGeometry Box {} 

			  exposedField SFNode myActiveAppearance Appearance {}
			  exposedField SFNode myActiveGeometry Box {} 

			  field SFFloat maxPosition -1 
			  field SFFloat minPosition  0 

			  eventIn  SFVec3f translation_in
			  field    SFVec3f translation_init 0 0 0 
			  eventOut SFVec3f translation_out

			  eventOut SFBool  isActive_out
			]
{
  Transform {
    children	[

      DEF SENSOR PlaneSensor {
	set_offset IS translation_in
	isActive   IS isActive_out
      }
      DEF GEOM_XFORM Transform {

	children	DEF GEOM_SWITCH Switch {
	    whichChoice 0
	    choice [
		Shape {
		  appearance	IS myAppearance 
		  geometry      IS myGeometry 
		},
		Shape {
		  appearance	IS myActiveAppearance 
		  geometry      IS myActiveGeometry
		}
	    ]
	}

	translation_changed IS translation_out
    }
    DEF TRANSLATE_1_DRAGGER_SCRIPT Script {
	field   SFFloat maxPosition      IS maxPosition
	field   SFFloat minPosition      IS minPosition
	field   SFVec3f translation_init IS translation_init

	eventIn SFBool isActive_in
	eventOut SFInt32 whichChoice_out
	eventOut SFVec2f maxPos_out
	eventOut SFVec2f minPos_out
	eventOut SFVec3f translation_out

	url "vrmlscript:
	function initialize()
	{
	    // setting the second values to 0 clamps the translation in the
	    // y direction, so motion occurs only in x.
	    maxPos_out = new SFVec2f( maxPosition, 0 );
	    minPos_out = new SFVec2f( minPosition, 0 );

	    translation_out = translation_init;
	}
	function isActive_in(value,time) 
	{
	    if (value == FALSE)
		whichChoice_out = 0;
	    else 
		whichChoice_out = 1;
	}"
    }

    ]
  }
  ROUTE SENSOR.offset_changed TO GEOM_XFORM.set_translation
  ROUTE SENSOR.translation_changed TO GEOM_XFORM.set_translation
  ROUTE SENSOR.isActive TO TRANSLATE_1_DRAGGER_SCRIPT.isActive_in
  ROUTE TRANSLATE_1_DRAGGER_SCRIPT.whichChoice_out TO GEOM_SWITCH.whichChoice
  ROUTE TRANSLATE_1_DRAGGER_SCRIPT.maxPos_out TO SENSOR.maxPosition
  ROUTE TRANSLATE_1_DRAGGER_SCRIPT.minPos_out TO SENSOR.minPosition
  ROUTE TRANSLATE_1_DRAGGER_SCRIPT.translation_out TO SENSOR.set_offset
}

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
X-Zm-Content-Name: translate2DraggerProto.wrl
Content-Description: Text
Content-Type: text/plain ; name="translate2DraggerProto.wrl" ; charset=us-ascii

#VRML V2.0 utf8

PROTO Translate2Dragger [ 
			  exposedField SFNode myAppearance Appearance {}
			  exposedField SFNode myGeometry Box {} 

			  exposedField SFNode myActiveAppearance Appearance {}
			  exposedField SFNode myActiveGeometry Box {} 

			  field SFVec2f maxPosition -1 -1 
			  field SFVec2f minPosition  0  0 

			  eventIn  SFVec3f translation_in
			  field    SFVec3f translation_init 0 0 0
			  eventOut SFVec3f translation_out

			  eventOut SFBool  isActive_out
			]
{
  Transform {
    children	[

      DEF SENSOR PlaneSensor {
	set_offset IS translation_in
	isActive   IS isActive_out

	maxPosition IS maxPosition
	minPosition IS minPosition
      }
      DEF GEOM_XFORM Transform {

	children	DEF GEOM_SWITCH Switch {
	    whichChoice 0
	    choice [
		Shape {
		  appearance	IS myAppearance 
		  geometry      IS myGeometry 
		},
		Shape {
		  appearance	IS myActiveAppearance 
		  geometry      IS myActiveGeometry
		}
	    ]
	}

	translation_changed IS translation_out
    }
    DEF TRANSLATE_2_DRAGGER_SCRIPT Script {
	field   SFVec3f translation_init IS translation_init

	eventIn SFBool isActive_in
	eventOut SFInt32 whichChoice_out
	eventOut SFVec3f translation_out

	url "vrmlscript:
	function initialize()
	{
	    translation_out = translation_init;
	}
	function isActive_in(value,time) 
	{
	    if (value == FALSE)
		whichChoice_out = 0;
	    else 
		whichChoice_out = 1;
	}"
    }

    ]
  }
  ROUTE SENSOR.offset_changed TO GEOM_XFORM.set_translation
  ROUTE SENSOR.translation_changed TO GEOM_XFORM.set_translation
  ROUTE SENSOR.isActive TO TRANSLATE_2_DRAGGER_SCRIPT.isActive_in
  ROUTE TRANSLATE_2_DRAGGER_SCRIPT.whichChoice_out TO GEOM_SWITCH.whichChoice
  ROUTE TRANSLATE_2_DRAGGER_SCRIPT.translation_out TO SENSOR.set_offset
}

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
X-Zm-Content-Name: appearanceProtos.wrl
Content-Description: Text
Content-Type: text/plain ; name="appearanceProtos.wrl" ; charset=us-ascii

#VRML V2.0 utf8

PROTO Magenta  []
{
    Appearance {
	material	Material {
	    diffuseColor	0.8 0 0.266667
	    emissiveColor	0.102041 0 0.0340136
	}
    }
}

PROTO Red  []
{
    Appearance {
	material	Material {
	    diffuseColor	1.0 0 0.0
	    emissiveColor	0.1 0 0 
	}
    }
}

PROTO White  []
{
    Appearance {
	material	Material {
	    diffuseColor	0.8 0.8 0.8
	    emissiveColor	0.1 0.1 0.1
	}
    }
}

PROTO Yellow  []
{
    Appearance {
	material	Material {
	    diffuseColor	0.8 0.8 0
	    emissiveColor	0.1 0.1 0
	}
    }
}

PROTO Lavender  []
{
    Appearance {
	material	Material {
	    diffuseColor	0.8 0 0.8
	    emissiveColor	0.102041 0 0.1
	}
    }
}

PROTO Blue  []
{
    Appearance {
	material	Material {
	    diffuseColor	0 0.710535 0.8
	    emissiveColor	0 0.0906295 0.102041
	}
    }
}

PROTO RylonFlames  []
{
    Appearance {
	material	Material {
	    diffuseColor	.6 .6 1
	    emissiveColor	.06 .06 .1
	}
    }
}

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com
X-Zm-Content-Name: geometryProtos.wrl
Content-Description: Text
Content-Type: text/plain ; name="geometryProtos.wrl" ; charset=us-ascii

#VRML V2.0 utf8

# A crosshair shape, .3x.3x2 units

PROTO ArrowheadGeom []
{
    IndexedFaceSet {
	coord	Coordinate {
 	  point	[  0 .3 0,
		   1 .3 0,
		   1 -.3 0,
		   0 -.3 0,
		   1 .6 0,
		   1.5 0 0,
		   1 -.6 0]
	}

	coordIndex	[ 0, 1, 2, 3, -1, 4, 5, 6,  -1 ]
	solid	FALSE
  }
}

PROTO VerticalNubbin []
{
  Box {
	size    .05 .5 .15
  }
}

# A skinny box, .5x.1x.1
PROTO Horizontal4UnitBar []
{
  Box {
	size    4 .1 .1
  }
}

--PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com--

From cph@vesta.cms.dmu.ac.uk  Mon Mar  3 22:50:07 1997
Return-Path: <cph@vesta.cms.dmu.ac.uk>
Received: from macondo.dmu.ac.uk by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id WAA15708; Mon, 3 Mar 1997 22:50:04 -0500
Received: from vesta.cms.dmu.ac.uk (root@vesta.cms.dmu.ac.uk [146.227.102.3]) by macondo.dmu.ac.uk (8.6.12/8.6.11) with ESMTP id DAA25459; Tue, 4 Mar 1997 03:44:16 GMT
Received: from sargent.cms.dmu.ac.uk (cph@sargent.cms.dmu.ac.uk [146.227.102.121])
	by vesta.cms.dmu.ac.uk (8.8.5/1.5V) with ESMTP id DAA06655;
	Tue, 4 Mar 1997 03:38:45 GMT
From: Chris Hand <cph@dmu.ac.uk>
Received: (from cph@localhost)
	by sargent.cms.dmu.ac.uk (8.8.5/1.4C) id DAA03624;
	Tue, 4 Mar 1997 03:38:37 GMT
Message-Id: <199703040338.DAA03624@sargent.cms.dmu.ac.uk>
Subject: Re: vrml-ui/vrml-widgets: Widget List
To: pauli@uniblab.engr.sgi.com (Paul Isaacs)
Date: Tue, 4 Mar 1997 03:38:37 +0000 (GMT)
Cc: broehl@ece.uwaterloo.ca, sab@cs.brown.edu, joel@blacksun.com,
        bill@yisup.com, pell@newfire.com, sulam@construct.net,
        steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net,
        misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com,
        pauli@sgi.com, braden@shadow.net, michaelp@netscape.com,
        kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com,
        dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu,
        slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov,
        matt@cicadaweb.com, rob@relay.engr.SGI.COM,
        erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu,
        ouch@relay.engr.SGI.COM, thinktank@infomaniacs.com, robert@oz.com,
        gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com,
        bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com
In-Reply-To: <9703031718.ZM23814@uniblab.engr.sgi.com> from "Paul Isaacs" at Mar 3, 97 05:18:34 pm
Reply-To: cph@dmu.ac.uk
X-Chris-Fax: +44 116 254-1891
X-Chris-Phone: +44 116 257-7498
X-Chris-WWW: http://www.cms.dmu.ac.uk/~cph/
Content-Type: text
Status: RO

I think my brain has just about recovered from the trip back
to England, so here are some initial reactions to the discussion
so far:

* Selection doesn't mean "click" -- we need to make sure
  that our UI thinking allows for a wide variety of 3D input
  devices *properly* (as opposed to the passing references 
  made in the VRML2.0 spec).   Perhaps having a small number
  of usage scenarios would help to make this mindset more
  common, e.g. Michael has a mouse, Stephanie has a spaceball
  *and* mouse (TWO-HANDED INPUT IS NOT AGAINST THE LAW!) and 
  Jaron is fully immersed with head-tracked HMD and a glove 
  or two.  :)

* Creativity vs standards -- we definitely need to generate and
  evaluate some ideas/implementations soon.  Since the
  results will be open, we need to create a "gene pool" to 
  start with before we can have evolution... the successful
  creations will be adopted and may be improved by anyone 
  who's interested.  

  But having a standard set of tools is also pretty important, 
  since (as Mark said) naive users want to grab stuff and 
  start playing according to their expectations.

  So, I would suggest we can have both: there are some some 
  obvious candidates for immediate implementation (mostly
  direct analogues of 2D widgets, e.g. sliders, buttons), but
  there is also a need for more complex, "less obvious" widgets
  which use or require 3D.  For example, there are many flavours
  of bounding-box-with-graspable-handles-for-rotating-object 
  in use or reported in the literature, with different   
  functionality.  We might implement several kinds of these 
  and let people play with them for a while (or even -- gasp! --
  get interested HCI people to perform proper user trials) 
  before trying to standardise on them.  

  As a comment on "stifling creativity", this was my original
  reaction, but remember: VRML users/programmers will always
  be able to extend nodes themselves (creatively), which isn't 
  anywhere near so easy in most 2D GUIs.  Personally I'm all in favour 
  of ignoring UI standards when you want to, as long as you
  "know what you're doing" (Metatools stuff was a good example).

* Our focus needs to include input devices and not just widgets
  (otherwise we'll all still be using mice, badly).  Bernie's
  recent point about whether users make use of a virtual or
  a real trackball is *really important*.  We must make sure  
  that input devices and the interaction techniques used are
  abstracted apart in a suitable way.

  We should also encourage input device manufacturers to 
  provide suitable nodes with their kit.    At least one
  Input Device Guy I spoke to last week (Todd Yocum at
  Cybernet) says they intend to do this -- perhaps there's
  some input device forum we can infiltrate/influence...?  

* Structure of working groups: I think having too many groups may
  be counter-productive.    On reflection I think a Widgets group
  (covering software objects for Object Manipulation, Viewpoint
  Manipuation and misc. other Application Control tasks)
  plus an Input Devices group might be enough, but we need to
  carefully work out what the nodes that each group produces will 
  require of each other.

Finally, to re-iterate comments from the UI panel: the last 10 years
has seen *lots* of papers from SIGGRAPH, CHI, UIST and various
graphics journals reporting results on 3D interaction techniques.  
It's really important that we BUILD on this work rather than
starting from scratch.    We really do have something to offer
the 3D UI community *in general* here -- a portable platform for
prototyping and experimenting with 3D interaction techniques
and widgets.  This is exactly what we need to accelerate the evolution
of 3D interfaces.

Chris

-- 
Chris Hand, Senior Lecturer             | Dept of Computer Science,
e-mail: cph@dmu.ac.uk                   | De Montfort University, The Gateway 
   WWW: http://www.cms.dmu.ac.uk/~cph/  | LEICESTER, UK   LE1 9BH            

From gseidman Sun Mar  2 17:22:40 1997
Subject: Re: Widgets/UI/Navigation Working Group
To: sab@cs.brown.edu (Sascha Becker)
Date: Sun, 2 Mar 1997 17:22:40 -0500 (EST)
In-Reply-To: <199703020110.UAA23882@point.cs.brown.edu> from "Sascha Becker" at Mar 1, 97 08:10:00 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2904      
Status: RO

} User Interface and/or Widgets and/or Navigation Working Group
} 
} At VRML '97, Mark Pesce called for a standard of prototype widgets for
} VRML 2.0. This idea triggered me to propose a "Widgets" working group,
} which several people then suggested expanding to "User Interface" in
} general. Dozens of people gave me their contact info and expressed
} interest in that sort of working group. The question we now face is 
} how many working groups do we form, and what each group's focus should
} be. 

I have widgets. I have been doing widgets. I like widgets. See
http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html to take a look.

} What, exactly, do I mean by VRML widgets? Here's a few ideas, with
} influences from Inventor and the Brown Graphics Group, among others
} * Heads-Up Display (HUD) 

I've tried working with this, but I've found it very difficult,
particularly as an EXTERNPROTO.

} * Forms (a la HTML)

The difficulty with this is capturing keyboard input. The only standard way
of doing this is with a Java window external to the VRML browser. This
would require a spec change.

} * Direct-Manip Geometries: vectors, line segments, points

I have a Line-To kind of widget already. It works pretty well. It is
available at the URL above. (A non-PROTO version that does not crash
CosmoSGI 1.0.1 is available at
http://zing.ncsl.nist.gov/~gseidman/vrml/comparison/linetest.wrl)

} * Buttons: toggle, radio, push

I have one kind of button that can be wired as radio buttons or toggle
(I am not sure what you mean by push). I also have a light switch.

} * Viewpoint manips

This is not entirely clear to me. You mean something like the CosmoSGI Walk
handle?

} * Sliders

I have several different kinds of sliders.

} * etc.

I also have a knob (like a car radio volume knob), a dial (like the
volume dial on the front of many CDROM drives), an up-down widget (like
a digital tuner control, which can be either continuous or discrete),
and a Text popup thing (which is only sort of a widget).

By the way, I would rename the above:

Direct manipulation:	viewpoint manipulators, movement of objects, etc.
Boolean control:	button, switch
Continuous control:	sliders, knob, dial, up-down
Discrete control:	switch, up-down, pop-up text

...and I would let the Visualization group continue working on the HUD, as
they said they have been.

} Please contact me at sab@cs.brown.edu if you are interested in
} participating in a Widgets or UI working group-- I'm especially
} interested in your ideas on how our efforts could best be 
} directed. 

I am interested. This is my favorite stuff. By the way, I applied to the
Brown Graduate School in Computer Science and, if accepted, I would be
delighted to work on this stuff with you. If you find the work I have
done interesting and useful, please mention my name to appropriate
people there.

} -Sascha Becker
} sab@cs.brown.edu
--Greg

From gseidman Mon Mar  3 23:40:41 1997
Subject: what I sent to Sascha
To: cph@dmu.ac.uk
Date: Mon, 3 Mar 1997 23:40:41 -0500 (EST)
Cc: pauli@uniblab.engr.sgi.com, broehl@ece.uwaterloo.ca, sab@cs.brown.edu,
	joel@blacksun.com, bill@yisup.com, pell@newfire.com,
	sulam@construct.net, steve@division.com, brush@vnet.ibm.com,
	qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
	mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net,
	misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com,
	pauli@sgi.com, braden@shadow.net, michaelp@netscape.com,
	kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com,
	dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu,
	slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov,
	matt@cicadaweb.com, rob@relay.engr.SGI.COM,
	erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu,
	ouch@relay.engr.SGI.COM, thinktank@infomaniacs.com, robert@oz.com,
	philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca,
	vidinick@aol.com
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2706      
Status: RO

I sent this message to Sascha in response to the original message, and
meant to give permission for it to be sent out to everyone. Here is what I
sent:

Subject: Re: Widgets/UI/Navigation Working Group
To: sab@cs.brown.edu (Sascha Becker)
Date: Sun, 2 Mar 1997 17:22:40 -0500 (EST)
From: gseidman

} User Interface and/or Widgets and/or Navigation Working Group
} 
} At VRML '97, Mark Pesce called for a standard of prototype widgets for
} VRML 2.0. This idea triggered me to propose a "Widgets" working group,
} which several people then suggested expanding to "User Interface" in
} general. Dozens of people gave me their contact info and expressed
} interest in that sort of working group. The question we now face is 
} how many working groups do we form, and what each group's focus should
} be. 

I have widgets. I have been doing widgets. I like widgets. See
http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html to take a look.

} What, exactly, do I mean by VRML widgets? Here's a few ideas, with
} influences from Inventor and the Brown Graphics Group, among others
} * Heads-Up Display (HUD) 

I've tried working with this, but I've found it very difficult,
particularly as an EXTERNPROTO.

} * Forms (a la HTML)

The difficulty with this is capturing keyboard input. The only standard way
of doing this is with a Java window external to the VRML browser. This
would require a spec change.

} * Direct-Manip Geometries: vectors, line segments, points

I have a Line-To kind of widget already. It works pretty well. It is
available at the URL above. (A non-PROTO version that does not crash
CosmoSGI 1.0.1 is available at
http://zing.ncsl.nist.gov/~gseidman/vrml/comparison/linetest.wrl)

} * Buttons: toggle, radio, push

I have one kind of button that can be wired as radio buttons or toggle
(I am not sure what you mean by push). I also have a light switch.

} * Viewpoint manips

This is not entirely clear to me. You mean something like the CosmoSGI Walk
handle?

} * Sliders

I have several different kinds of sliders.

} * etc.

I also have a knob (like a car radio volume knob), a dial (like the
volume dial on the front of many CDROM drives), an up-down widget (like
a digital tuner control, which can be either continuous or discrete),
and a Text popup thing (which is only sort of a widget).

By the way, I would rename the above:

Direct manipulation:	viewpoint manipulators, movement of objects, etc.
Boolean control:	button, switch
Continuous control:	sliders, knob, dial, up-down
Discrete control:	switch, up-down, pop-up text

...and I would let the Visualization group continue working on the HUD, as
they said they have been.

[...]
} -Sascha Becker
} sab@cs.brown.edu
--Greg

From bill@yisup.com  Tue Mar  4 13:00:47 1997
Return-Path: <bill@yisup.com>
Received: from proxy2.ba.best.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id NAA26452; Tue, 4 Mar 1997 13:00:45 -0500
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.5/8.8.3) with ESMTP id JAA07120; Tue, 4 Mar 1997 09:51:18 -0800 (PST)
Received: from [206.86.217.60] (demolish.vip.best.com [206.86.217.60]) by shellx.best.com (8.8.5/8.8.3) with ESMTP id JAA29223; Tue, 4 Mar 1997 09:49:33 -0800 (PST)
X-Sender: demolish@best.com
Message-Id: <v03007802af42115891f2@[206.86.217.60]>
In-Reply-To: <199703032134.QAA12120@point.cs.brown.edu>
References: Your message of "Mon, 03 Mar 1997 15:44:26 EST."            
 <199703032044.PAA02300@watt.uwaterloo.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Mar 1997 09:51:28 -0800
To: Sascha Becker <sab@cs.brown.edu>, Bernie Roehl <broehl@ece.uwaterloo.ca>
From: Bill Enright <bill@yisup.com>
Subject: vrml-widgets: base funtionality
Cc: joel@blacksun.com, pell@newfire.com, sulam@construct.net,
        steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov,
        jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu,
        philippe@e-spaces.com, otto@interport.net, misty@well.com,
        matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com,
        braden@shadow.net, michaelp@netscape.com, kluster@sgi.com,
        riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu,
        jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com,
        houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com,
        rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com,
        athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com,
        robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com,
        jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com,
        john.martellaro@lmco.com, rcg@rd.engr.sgi.com, mpesce@netcom.com,
        jonpruyn@inkstone.com, sab@cs.brown.edu
Status: RO

Take a look at the basic Mac (I know, I know) control manager.  Controls can=
 be defined as these *things* that output a range of values when=
 manipulated.  There's a way to plug in your own representations for parts=
 of these controls, but the basic function stays the same.  The system uses=
 the control manager to create the standard look and feel, but if you wanna=
 break the rules, the api is there to be hacked.

How do we describe the basic functionality of a widget in such a way that we=
 can build the various widgets from the basic functionality.  Perhaps we can=
 create or simply describe the equivalent of a Control Manager that lets us=
 build the various widgets we need on top of it.  Would this help?  Is this=
 possible?  I believe that it 1) would help and 2) is possible.  If I had a=
 simple package of VRML 2.0 nodes (perhaps minus the geometries) that let me

Show and Hide=20
Draw/Update
Handle Events/Track (from arbitray source(s))
Move/Resize
Plug In different control  and tracking functions (i.e. custom, not standard=
)
Set Min/Max values

Then I'd have a nice, working, consistent framework.  My creativity would be=
 happily stifled and I would rule the world.

=3D8^o
bill@yisup.com

From pauli@uniblab.engr.sgi.com  Tue Mar  4 18:34:35 1997
Return-Path: <pauli@uniblab.engr.sgi.com>
Received: from sgi.sgi.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id SAA09857; Tue, 4 Mar 1997 18:34:28 -0500
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18987 for <@sgi.engr.sgi.com:gseidman@zing.ncsl.nist.gov>; Tue, 4 Mar 1997 15:34:23 -0800
Received: from uniblab.engr.sgi.com (uniblab.engr.sgi.com [198.29.108.116]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA04705 for <@cthulhu.engr.sgi.com:gseidman@zing.ncsl.nist.gov>; Tue, 4 Mar 1997 15:34:23 -0800
Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA27594 for gseidman@zing.ncsl.nist.gov; Tue, 4 Mar 1997 23:34:22 GMT
From: "Paul Isaacs" <pauli@uniblab.engr.sgi.com>
Message-Id: <9703041534.ZM27592@uniblab.engr.sgi.com>
Date: Tue, 4 Mar 1997 15:34:22 -0800
In-Reply-To: gseidman@zing.ncsl.nist.gov (Gregory Seidman)
        "what I sent to Sascha" (Mar  3, 11:40pm)
References: <199703040440.XAA16119@zing.ncsl.nist.gov>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: gseidman@zing.ncsl.nist.gov (Gregory Seidman)
Subject: Re: what I sent to Sascha
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: RO

Greetings Kindred Spirit,

>> I have widgets. I have been doing widgets. I like widgets.

Ditto.  I'm the guy who wrote the Inventor dragger/manipulator stuff,
as well as the 3D widgets for CosmoWorlds.

>>  See
>> http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html to take a look.

I just took a look at the website you mentioned in your posting.
Great stuff!  Hopefully I'll get a chance to read your paper as well.

I'm working on some related-but-different stuff and if you like I'll let
you know as I put things out on my website.

Keep up the good work!

pauli.

-- 
  

Paul Isaacs, pauli@sgi.com          Cosmo VRML Engineering, Silicon Graphics

---- New York Serenity Prayer:   -------------------------------------------
God give me the strength to crush those in my way, the money to bribe 
those who can help me, and the wisdom to know the difference.

From vrml-ui-owner@vag.vrml.org  Wed Mar  5 04:46:49 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id EAA12707; Wed, 5 Mar 1997 04:46:47 -0500
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by kether.vrml.org (8.7.5/1.0) with ESMTP id JAA02087 for <vrml-ui@vag.vrml.org>; Wed, 5 Mar 1997 09:41:57 GMT
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy3.ba.best.com (8.8.5/8.8.3) with ESMTP id BAA26961 for <vrml-ui@vag.vrml.org>; Wed, 5 Mar 1997 01:40:51 -0800 (PST)
Received: from [206.86.217.60] (demolish.vip.best.com [206.86.217.60]) by shellx.best.com (8.8.5/8.8.3) with ESMTP id BAA29570 for <vrml-ui@vag.vrml.org>; Wed, 5 Mar 1997 01:40:26 -0800 (PST)
X-Sender: demolish@best.com
Message-Id: <v03007804af42f03c524a@[206.86.217.60]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 5 Mar 1997 01:42:22 -0800
To: vrml-ui@vag.vrml.org
From: Bill Enright <bill@yisup.com>
Subject: REPOST: base functionality
Status: RO

Take a look at the basic Mac (I know, I know) control manager.  Controls can=
 be defined as these *things* that output a range of values when=
 manipulated.  There's a way to plug in your own representations for parts=
 of these controls, but the basic function stays the same.  The system uses=
 the control manager to create the standard look and feel, but if you wanna=
 break the rules, the api is there to be hacked.

How do we describe the basic functionality of a widget in such a way that we=
 can build the various widgets from the basic functionality.  Perhaps we can=
 create or simply describe the equivalent of a Control Manager that lets us=
 build the various widgets we need on top of it.  Would this help?  Is this=
 possible?  I believe that it 1) would help and 2) is possible.  If I had a=
 simple package of VRML 2.0 nodes (perhaps minus the geometries) that let me

Show and Hide=20
Draw/Update
Handle Events/Track (from arbitray source(s))
Move/Resize
Plug In different control  and tracking functions (i.e. custom, not standard=
)
Set Min/Max values

Then I'd have a nice, working, consistent framework.  My creativity would be=
 happily stifled and I would rule the world.

=3D8^o
bill@yisup.com

From vrml-ui-owner@vag.vrml.org  Wed Mar  5 14:31:33 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id OAA24409; Wed, 5 Mar 1997 14:31:32 -0500
Received: from xanadu.oz.com (root@[207.105.191.57]) by kether.vrml.org (8.7.5/1.0) with ESMTP id TAA06749 for <vrml-ui@vag.vrml.org>; Wed, 5 Mar 1997 19:25:21 GMT
Received: from robofly 
	by xanadu.oz.com (8.8.3/OZnet/12-01-97); Wed, 5 Mar 1997 13:31:30 -0800
Message-Id: <3.0.32.19970305232639.008d6730@xanadu.oz.com>
X-Sender: robert@xanadu.oz.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 05 Mar 1997 23:26:40 -0800
To: vrml-ui@vag.vrml.org
From: Robert Bjarnason <robert@oz.com>
Subject: Open standards
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: RO

Hi,

Prove of point>

We should prove that VRML Widgets can be used with VRML, and other open
Internet standards to create compelling consumer ($) content/product's.

Future of 3D Widgets in general>

How will Microsoft and other large scale Widgets distributors react to this
innovative, there are high stakes. What is Windows 95 now
(Widgets/Devices/DOS/Network)? 

With warm regards,

Robert Vidar Bjarnason
Ambassador
robert@oz.com

From vrml-ui-owner@vag.vrml.org  Fri Mar  7 13:23:08 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id NAA23073; Fri, 7 Mar 1997 13:22:56 -0500
Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id SAA08882 for <vrml-ui@vag.vrml.org>; Fri, 7 Mar 1997 18:13:54 GMT
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12140 for <@sgi.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 7 Mar 1997 10:15:05 -0800
Received: from rd.engr.sgi.com (rd.engr.sgi.com [198.29.108.114]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA29965 for <@cthulhu.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 7 Mar 1997 10:15:04 -0800
Received: (from rcg@localhost) by rd.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA10616; Fri, 7 Mar 1997 10:15:03 -0800
Date: Fri, 7 Mar 1997 10:15:03 -0800
From: rcg@rd.engr.sgi.com (Rich Gossweiler)
Message-Id: <199703071815.KAA10616@rd.engr.sgi.com>
To: vrml-ui@vag.vrml.org
Subject: widgets
Reply-To: rcg@sgi.com
Status: RO

A while back I made some simple widgets which I put on my web-page and
gave to the world, no strings attached. I think the push-button and the
toggle-button need a re-write, but the slider is good-to-go. I set up
my page to have a GIF image of the widget, a stand-alone proto (for easy
inclusion into your world) and an example world using the widget:

Scroll down to the widget section of

http://reality.sgi.com/rcg/vrml/vrmlIndex.html

-----
Rich Gossweiler (rcg@sgi.com) MS 982 http://reality.sgi.com/rcg 415.933.6572 

The opinions I express are my own and do not necessarily reflect those
of my company. 

From vrml-ui-owner@vag.vrml.org  Sat Mar  8 04:28:53 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id EAA28390; Sat, 8 Mar 1997 04:28:51 -0500
Received: from xanadu.oz.com (root@[207.105.191.57]) by kether.vrml.org (8.7.5/1.0) with ESMTP id JAA24523 for <vrml-ui@vag.vrml.org>; Sat, 8 Mar 1997 09:27:13 GMT
Received: from robofly 
	by xanadu.oz.com (8.8.3/OZnet/12-01-97); Sat, 8 Mar 1997 01:28:26 -0800
Message-Id: <3.0.32.19970308132840.008dc740@xanadu.oz.com>
X-Sender: robert@xanadu.oz.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 08 Mar 1997 13:28:41 -0800
To: <vrml-ui@vag.vrml.org>
From: Robert Bjarnason <robert@oz.com>
Subject: Re: [vrml-ui] Sounds like we're getting somewhere
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: RO

Hi,

>---------------------------------------------
>Re:   Working Group Charter
>
>Sascha Becker wrote:
>> ...we should be building a set of
>> public-domain, fully-functional, customizable 2D and 3D
>> widgets which are amenable to arbitrary input devices. 
>
>This seems to be a great first cut at a charter statement. 
>Here's my attempt at a little more generalized one:
>
>The VRML User Interface Working Group has been formed to provide insights,
>expertise and examples of VRML 2.0 user interfaces. By providing a freely
>distributable set of professional quality, fully-functional, highly
>customizable user interface widgets and worlds, the Working Group hopes to
>foster exciting advances in the area of immersive 3D user interface design.

Goals>

* Define a standard for arbitrary input devices. 
* Implement adaptive AI into our widgets.
* Work with artists to create compelling look & feel.
* Cooperation with the VRML binary format WG in terms of response time.
* Encourage browser developers to move their UI-widgets into VRML.

>I would really hate to see "cyberspace" have a tired and worn user
>interface cast upon it. There are so many great new ideas, let's not be too
>hasty in suggesting that what we have today is good enough for the next
>decade. The Desktop is dead. Deal with it.

I hope we will see much diversity in 3D UI-widgets in soon, you should be
able to switch widgets and still continue to work in the same application.
If this is going to be realized in the future, we need some kind of a
standard/framework on some level for people to start building on ?

With warm regards,

Robert Vidar Bjarnason
Ambassador
robert@oz.com

From vrml-ui-owner@vag.vrml.org  Sat Mar  8 12:26:16 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id MAA04329; Sat, 8 Mar 1997 12:26:14 -0500
Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com [205.217.237.47]) by kether.vrml.org (8.7.5/1.0) with ESMTP id RAA26841 for <vrml-ui@vag.vrml.org>; Sat, 8 Mar 1997 17:23:35 GMT
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id JAA22959 for <vrml-ui@vag.vrml.org>; Sat, 8 Mar 1997 09:24:15 -0800 (PST)
Received: from jch-isdn.mcom.com ([205.217.243.40]) by dredd.mcom.com
          (Netscape Mail Server v2.02) with SMTP id AAA2789;
          Sat, 8 Mar 1997 09:24:15 -0800
Message-ID: <3321768B.78DB@netscape.com>
Date: Sat, 08 Mar 1997 09:24:11 -0500
From: jch@netscape.com (Jan Hardenbergh)
Reply-To: jch@netscape.com
Organization: Netscape Communications
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: Robert Bjarnason <robert@oz.com>
CC: vrml-ui@vag.vrml.org
Subject: Re: [vrml-ui] Sounds like we're getting somewhere
References: <3.0.32.19970308132840.008dc740@xanadu.oz.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO

> >decade. The Desktop is dead. Deal with it.

Has everyone checked out Gelentner's Life Streams? Written up
in WIRED, netgrep it. It has a very intuitive post WIMP interface
to information streams. The globe, etc.
 
> I hope we will see much diversity in 3D UI-widgets in soon, you should be
> able to switch widgets and still continue to work in the same application.
> If this is going to be realized in the future, we need some kind of a
> standard/framework on some level for people to start building on ?

There are two forces, one which wants to make EXTERNPROTOs for 
a bunch of standard widgets - sliders, box draggers, etc...
One interfaces are clear, the visual & interactions methods can
be varied, but the VRML App does not need to change.

Hey, we could be talking about a VRML style sheet, soon.

-- 
YON jch@netscape.com /       "If you spend enough time talking to the 
Jan Hardenbergh  / Martians, everything becomes clear" Tamara Munzner
www.arts.gla.ac.uk/IPA/ipa.html

From vrml-ui-owner@vag.vrml.org  Tue Mar 11 20:38:33 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id UAA07809; Tue, 11 Mar 1997 20:38:32 -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 BAA14241 for <vrml-ui@vag.vrml.org>; Wed, 12 Mar 1997 01:35:01 GMT
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id UAA03503 for <vrml-ui@vag.vrml.org>; Tue, 11 Mar 1997 20:36:14 -0500 (EST)
From: Sascha Becker <sab@cs.brown.edu>
Received: (sab@localhost) by point.cs.brown.edu (8.8.3/BrownCS1.0) id UAA21291 for vrml-ui@vag.vrml.org; Tue, 11 Mar 1997 20:36:09 -0500 (EST)
Date: Tue, 11 Mar 1997 20:36:09 -0500 (EST)
Message-Id: <199703120136.UAA21291@point.cs.brown.edu>
To: vrml-ui@vag.vrml.org
Subject: a proposal for a widget repository
Status: RO

Mike Pell and I have been talking offline, and have come up with an
outline of a user interface element repository. We see this repository
as a deliverable from this group; we would still call the group
vrml-ui, but initially focus on developing this repository. The group
would be responsible for designing and creating the repository and
associated technology, as well as a core set of a dozen or so widgets
as examples of how to use the repository. The community at large would
then submit widgets to the repository; the wg would catalogue widget
submissions (hopefully a lightweight task) according to what they do
and to what degree they fit the suggested framework. We expect that
the members of this working group would in fact be the principal
contributors to the repository, but want the repository to be open to
submissions from all corners.  

The Problem: 

- Not enough people know how to build interesting or good vrml widgets
- It's unecessarily hard to add a self-revealing user interface to 
VRML worlds.
- Some people have lots of insight, and are willing to make their
efforts public, but their efforts are distributed all over the web,
not easy to find
- Also, their efforts follow a diverse API. we'd like a consistent 
framework.
- We want to foster community expertise in developing 3D user
interface design
- ... and make VRML a platform that 3D ui designers choose for their
research and experimentation

Our proposal: 

A suggested framework for reusable widgets, including:
- fields for positioning, scaling, showing, hiding widgets
- API for getting and setting values on valuator widgets
- javadoc-style documentation (automatic documentation generation)
- plug-in geometry for author customization

A repository of: 
- reusable, customizable widgets & ui elements, either
meeting the framework above or not
- sample world files showing the widgets in use
- insights into widget writers' design decisions
- insights into widget writers' implementation strategies
- resources for widget/ui designers

Why this is a good thing:   
- The framework would provide widget developers with a 
template for each new widget, thus reducing the cost of
widget development. 
- Widgets that adhere to the framework standards would
be highly interoperable. A world author would not need
to rely on a single vendor for all his widgets; instead
he could simply plug in geometry with a unified look.
- The widget source would show people how to hack their own
widgets. Sample code is a fantastic way to learn.  
- Common widget behaviors could be abstracted out, allowing
world authors to customize geometry without touching code. If
more control is desired, the author can hack the widget source
and build their own widget. 
- The designers' description of why they did what they did, and
the resource list, would help spread UI design knowledge 
to the VRML community. 

Issues: 

- Where do we draw the line betwen generally smart objects
and user interface elements? 
- Versioning: what happens if I update my slider, which you
use? what happens if I change a field name? 
- There is strong support on the list for dealing with input devices
and navigation. to what degree, and how, should the widget repository
address these issues?
- Since each browser supports different languages for internal
messaging, a completely accessible widget would need three parallel
implementations, one for each of VRMLScript, JavaScript, and Java. 
- Does the flexibility inherent in the framework design cause a
performance hit? 

-Sascha
sab@cs.brown.edu

From gseidman Tue Mar 11 22:55:54 1997
Subject: Re: choosing a chair or co-chairs
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Tue, 11 Mar 1997 22:55:54 -0500 (EST)
In-Reply-To: <199703120146.UAA21400@point.cs.brown.edu> from "Sascha Becker" at Mar 11, 97 08:46:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1454      
Status: RO

} I'm interested in chairing or co-chairing this working
} group, whether it comes out to Widgets or User Interface
} or whatever. Is anyone else interested in chairing or
} co-chairing? 

I would be interested in co-chairing. I don't think I could be the one
and only chair, however. My bio is not quite as impressive as Sascha's,
but I have produced ten or eleven working VRML widgets. Bio:

I'm a senior CS major at University of Maryland College Park and accepted
(and going to) Brown University for grad school (in their Graphics Group,
I assume/hope). I intend to get a Ph.D. with work in (3D) HCI. I've
worked at NIST for the last three years and messed with user interfaces in
everything from PHIGS to World Toolkit using a dataglove to VRML widgets.

} For those of you who joined the list after my initial post,
} here's my bio again: 
} I'm a senior at Brown University, concentrating in Computer Science,
} particularly graphics and human-computer interaction. I've worked
} on several 3D interaction techniques as part of my participation
} in the Brown Graphics Group (http://www.cs.brown.edu/research/graphics)
} and worked with VRML for two summer internships, first at SGI where
} I worked on WebSpace Author, then at Intervista where I developed
} VRML 2.0 demos. I'm about to go work at First Virtual (www.fv.com)
} where I'll be creating VRML advertisements which require ui to
} support in-scene transactions. 
} 
} -Sascha
--Greg

From vrml-ui-owner@vag.vrml.org  Tue Mar 11 20:47:14 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id UAA07863; Tue, 11 Mar 1997 20:47:13 -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 BAA14290 for <vrml-ui@vag.vrml.org>; Wed, 12 Mar 1997 01:44:51 GMT
Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id UAA03649 for <vrml-ui@vag.vrml.org>; Tue, 11 Mar 1997 20:46:06 -0500 (EST)
From: Sascha Becker <sab@cs.brown.edu>
Received: (sab@localhost) by point.cs.brown.edu (8.8.3/BrownCS1.0) id UAA21400 for vrml-ui@vag.vrml.org; Tue, 11 Mar 1997 20:46:01 -0500 (EST)
Date: Tue, 11 Mar 1997 20:46:01 -0500 (EST)
Message-Id: <199703120146.UAA21400@point.cs.brown.edu>
To: vrml-ui@vag.vrml.org
Subject: choosing a chair or co-chairs
Status: RO

I'm interested in chairing or co-chairing this working
group, whether it comes out to Widgets or User Interface
or whatever. Is anyone else interested in chairing or
co-chairing? 

For those of you who joined the list after my initial post,
here's my bio again: 
I'm a senior at Brown University, concentrating in Computer Science,
particularly graphics and human-computer interaction. I've worked
on several 3D interaction techniques as part of my participation
in the Brown Graphics Group (http://www.cs.brown.edu/research/graphics)
and worked with VRML for two summer internships, first at SGI where
I worked on WebSpace Author, then at Intervista where I developed
VRML 2.0 demos. I'm about to go work at First Virtual (www.fv.com)
where I'll be creating VRML advertisements which require ui to
support in-scene transactions. 

-Sascha

From gseidman Thu Mar 13 17:31:42 1997
Subject: Re: a proposal for a widget repository
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Thu, 13 Mar 1997 17:31:42 -0500 (EST)
In-Reply-To: <199703131454.JAA13422@watt.uwaterloo.ca> from "Bernie Roehl" at Mar 13, 97 09:54:34 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3926      
Status: RO

} Sascha Becker writes:
[...]
} > Our proposal: 
} > A suggested framework for reusable widgets, including:
} > - fields for positioning, scaling, showing, hiding widgets

Somewhat reasonable, but I think it is external to the widgets themselves.
This would be, essentially, a Transform and Switch wrapper around the
widget itself.

} > - API for getting and setting values on valuator widgets

Absolutely. I would go with set_value and value_changed (since this is what
I have been using in my widgets, after all).

} > - javadoc-style documentation (automatic documentation generation)

Hrm. A bit more difficult. I'm rather inclined to have documentation
external to the definition, especially since one can expect that these
widgets will be sent over the net as EXTERNPROTOs and the smaller the file,
the quicker the transfer.

} > - plug-in geometry for author customization

Fairly simple for certain widgets, more comples for others. It makes some
sense to replace slider thumb geometry and the geometry of what it slides
on, but suppose you have a dial? I think plugin geometry will be a problem
for some widgets, very reasonable for others.

} We should probably categorize widgets in some way.  There are widgets that
} return a continuous value and widgets that return discrete values.  The
} value that a widget returns can be any of the basic VRML types (SFBool,
} SFInt32, SFFloat, SFVec3f, SFRotation), and some widgets may return more
} than one type of data or even arrays of various types.

Absolutely. I suggest we develop a widget taxonomy including discrete vs.
continuous, data types, etc.

} > Issues: 
} > - Versioning: what happens if I update my slider, which you
} > use? what happens if I change a field name? 
} 
} So long as everything that worked before the change continues to work,
} it's just a better version of the same widget.  If you change field
} names or alter the functionality in some way, it should be considered
} to be a new widget.  It would be very nice if there were some way to
} do the equivalent of "subclassing" using VRML, but there's not.

There is subclassing in VRML, though it is perhaps not as clear. If you
want to add something to a widget, include an instance of the widget in a
new PROTO. There is no such thing as public subclassing, but IS allows
private subclassing (sorry, I'm taking a very thorough object-oriented
class this semester).

} > - Since each browser supports different languages for internal
} > messaging, a completely accessible widget would need three parallel
} > implementations, one for each of VRMLScript, JavaScript, and Java. 
} 
} I would say forget about VRMLScript; it's just an offshoot of JavaScript,
} and SGI has indicated they'll be migrating towards JavaScript instead.

And I would say forget about JavaScript unless you absolutely need
something from it. VRMLscript is easier to implement that JavaScript and,
since VRMLscript is designed to be a proper subset of JavaScript, any
browser that runs JavaScript runs VRMLscript.

} That does mean that widgets will still need two implementations, but I
} think that should be left up to the author of the widget.  Our widget
} collection should clearly indicate which language (if any) is required
} for each widget.

I have implemented all of my widgets in both VRMLscript and Java. I find
the translation very easy with practice. The differences in API are not
terribly big (e.g. adding a setValue() or getValue() for Java), and going
from functions named for events and a single event-handling function is
not a big deal either. (Yes, I develop with VRMLscript and port to Java.)

Note that I also have some convienient glue PROTOs (in both
VRMLscript and Java) for connecting widgets with Interpolators,
Transforms, other Widgets, etc. They can be found at
http://zing.ncsl.nist.gov/~gseidman/paper.rev.html in the paper
I submitted to VRML '97.

}    Bernie Roehl
--Greg

From vrml-ui-owner@vag.vrml.org  Thu Mar 13 17:33:14 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA07377; Thu, 13 Mar 1997 17:33:12 -0500
Received: from zing.ncsl.nist.gov (zing.ncsl.nist.gov [129.6.84.33]) by kether.vrml.org (8.7.5/1.0) with SMTP id WAA07638 for <vrml-ui@vag.vrml.org>; Thu, 13 Mar 1997 22:30:32 GMT
Received: by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA07365; Thu, 13 Mar 1997 17:31:43 -0500
From: gseidman@zing.ncsl.nist.gov (Gregory Seidman)
Message-Id: <199703132231.RAA07365@zing.ncsl.nist.gov>
Subject: Re: a proposal for a widget repository
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Thu, 13 Mar 1997 17:31:42 -0500 (EST)
In-Reply-To: <199703131454.JAA13422@watt.uwaterloo.ca> from "Bernie Roehl" at Mar 13, 97 09:54:34 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: RO

} Sascha Becker writes:
[...]
} > Our proposal: 
} > A suggested framework for reusable widgets, including:
} > - fields for positioning, scaling, showing, hiding widgets

Somewhat reasonable, but I think it is external to the widgets themselves.
This would be, essentially, a Transform and Switch wrapper around the
widget itself.

} > - API for getting and setting values on valuator widgets

Absolutely. I would go with set_value and value_changed (since this is what
I have been using in my widgets, after all).

} > - javadoc-style documentation (automatic documentation generation)

Hrm. A bit more difficult. I'm rather inclined to have documentation
external to the definition, especially since one can expect that these
widgets will be sent over the net as EXTERNPROTOs and the smaller the file,
the quicker the transfer.

} > - plug-in geometry for author customization

Fairly simple for certain widgets, more comples for others. It makes some
sense to replace slider thumb geometry and the geometry of what it slides
on, but suppose you have a dial? I think plugin geometry will be a problem
for some widgets, very reasonable for others.

} We should probably categorize widgets in some way.  There are widgets that
} return a continuous value and widgets that return discrete values.  The
} value that a widget returns can be any of the basic VRML types (SFBool,
} SFInt32, SFFloat, SFVec3f, SFRotation), and some widgets may return more
} than one type of data or even arrays of various types.

Absolutely. I suggest we develop a widget taxonomy including discrete vs.
continuous, data types, etc.

} > Issues: 
} > - Versioning: what happens if I update my slider, which you
} > use? what happens if I change a field name? 
} 
} So long as everything that worked before the change continues to work,
} it's just a better version of the same widget.  If you change field
} names or alter the functionality in some way, it should be considered
} to be a new widget.  It would be very nice if there were some way to
} do the equivalent of "subclassing" using VRML, but there's not.

There is subclassing in VRML, though it is perhaps not as clear. If you
want to add something to a widget, include an instance of the widget in a
new PROTO. There is no such thing as public subclassing, but IS allows
private subclassing (sorry, I'm taking a very thorough object-oriented
class this semester).

} > - Since each browser supports different languages for internal
} > messaging, a completely accessible widget would need three parallel
} > implementations, one for each of VRMLScript, JavaScript, and Java. 
} 
} I would say forget about VRMLScript; it's just an offshoot of JavaScript,
} and SGI has indicated they'll be migrating towards JavaScript instead.

And I would say forget about JavaScript unless you absolutely need
something from it. VRMLscript is easier to implement that JavaScript and,
since VRMLscript is designed to be a proper subset of JavaScript, any
browser that runs JavaScript runs VRMLscript.

} That does mean that widgets will still need two implementations, but I
} think that should be left up to the author of the widget.  Our widget
} collection should clearly indicate which language (if any) is required
} for each widget.

I have implemented all of my widgets in both VRMLscript and Java. I find
the translation very easy with practice. The differences in API are not
terribly big (e.g. adding a setValue() or getValue() for Java), and going
from functions named for events and a single event-handling function is
not a big deal either. (Yes, I develop with VRMLscript and port to Java.)

Note that I also have some convienient glue PROTOs (in both
VRMLscript and Java) for connecting widgets with Interpolators,
Transforms, other Widgets, etc. They can be found at
http://zing.ncsl.nist.gov/~gseidman/paper.rev.html in the paper
I submitted to VRML '97.

}    Bernie Roehl
--Greg

From vrml-ui-owner@vag.vrml.org  Thu Mar 13 21:23:53 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id VAA08218; Thu, 13 Mar 1997 21:23:51 -0500
Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id CAA08628 for <vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 02:19:15 GMT
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13050; Thu, 13 Mar 1997 18:20:15 -0800
Received: from uniblab.engr.sgi.com (uniblab.engr.sgi.com [198.29.108.116]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA18577; Thu, 13 Mar 1997 18:20:13 -0800
Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA04577; Fri, 14 Mar 1997 02:20:11 GMT
From: "Paul Isaacs" <pauli@uniblab.engr.sgi.com>
Message-Id: <9703131820.ZM4575@uniblab.engr.sgi.com>
Date: Thu, 13 Mar 1997 18:20:11 -0800
In-Reply-To: gseidman@zing.ncsl.nist.gov (Gregory Seidman)
        "Re: a proposal for a widget repository" (Mar 13,  5:31pm)
References: <199703132231.RAA07365@zing.ncsl.nist.gov>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: gseidman@zing.ncsl.nist.gov (Gregory Seidman),
        vrml-ui@vag.vrml.org (vrml user interface)
Subject: Re: a proposal for a widget repository
Cc: pauli@uniblab.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: RO

First off, I think the widget repository is  a great idea.
And I think the proposal Sascha sent is an excellent start.

I've got some more specific comments, mostly in reply to what has been said by
Bernie Roehl and Gregory Seidman.

> From Bernie:
> We should probably categorize widgets in some way.  There are widgets that
> return a continuous value and widgets that return discrete values.  The
> value that a widget returns can be any of the basic VRML types (SFBool,
> SFInt32, SFFloat, SFVec3f, SFRotation), and some widgets may return more
> than one type of data or even arrays of various types.

I agree.
Also, in my work I tend to deal with 3 'strata' of objects for widgets.
(Please forgive me for being mouse-centric as I explain this.  I know that some
of you are concerned with other input devices, and that these thoughts may need
to be expanded upon).

At the lowest level are 'surfaces I use to intersect the mouse.'   When I click
and drag, what kind of surface is the mouse passing over?  In VRML, we've got
PlaneSensor, CylinderSensor and SphereSensor for this purpose.  For those of
you who are familiar with OpenInventor, these correspond roughly to the various
SbProjector classes. It would be difficult to get other variations of these
objects without revising the spec, but I think that the current set is
sufficient.

In the middle level are 'things that move a particular way.'  When I drag the
mouse over one of the low-level surfaces, the cursor intersects that surface to
trace a path through space.  I can interpret that path in any number of ways
and produce different kinds of motion.  For example, I can click-drag over a
PlaneSensor and interpret this as angular motion relative to some center (as
with a dial or gear) as linear motion (for a slider or uniform-scaling knob) or
as planar motion (for a virtual screen cursor or interpreting virtual joystick
motion). I can click-drag over a SphereSensor and get rotating motion (as with
a trackball or spotlight-direction-controller) or I can get
translation-on-a-sphere-surface motion (for positioning flags on a globe).
If we categorize and wrap-up these various categories, we can then use them in
the next level up to make our widgets.  Objects at this middle level correspond
to the OpenInventor 'simple draggers' and have no equivalent in the VRML spec.
The PROTOS I sent earlier for Translate1DraggerProto and Translate2Dragger are
of this variety.

At the top level (perhaps this term is inappropriate -- there will doubtless be
higher-level constructs presented!) are widgets at the level Bernie described.
I agree with his ideas for categorization.
Note that if we've got the middle level objects in place, we can then re-use
these objects to build our top-level widgets.  For example, I can make a slider
by bundling a 'thing that moves in a line' with some geometry that sits still
as a background, and then having a short script (or bundling in some PROTO)
that maps the translation of the 'thing that moves in a line' into the desired
range of slider values; the resulting slider value can be the exposed output of
the slider.

On Mar 13,  5:31pm, Gregory Seidman wrote:
> Subject: Re: a proposal for a widget repository
> } Sascha Becker writes:
> [...]
> } > Our proposal:
> } > A suggested framework for reusable widgets, including:
> } > - fields for positioning, scaling, showing, hiding widgets
>
> Somewhat reasonable, but I think it is external to the widgets themselves.
> This would be, essentially, a Transform and Switch wrapper around the
> widget itself.

I'm pretty sure I agree in the case of a single widget, but remember that there
will also be organizational widgets (for example, something like the dreaded
motif form widget), used for laying out some set of sub-widgets. These objects
will certainly have parameters related to the ones Sascha proposed.

> From Gregory:
> } > - API for getting and setting values on valuator widgets
>
> Absolutely. I would go with set_value and value_changed (since this is what
> I have been using in my widgets, after all).

And if the widget has two values of interest?
I might prefer something more descriptive.

> From Gregory:
>
> } > - plug-in geometry for author customization
>
> Fairly simple for certain widgets, more comples for others. It makes some
> sense to replace slider thumb geometry and the geometry of what it slides
> on, but suppose you have a dial? I think plugin geometry will be a problem
> for some widgets, very reasonable for others.

I feel strongly that every single piece of geometry must be configurable or
people will not want to use them.

> From Gregory:
>
> Note that I also have some convienient glue PROTOs (in both
> VRMLscript and Java) for connecting widgets with Interpolators,
> Transforms, other Widgets, etc. They can be found at
> http://zing.ncsl.nist.gov/~gseidman/paper.rev.html in the paper
> I submitted to VRML '97.

These are cool.  I like them.
I might prefer to see them broken into lighter-weight classes, but I'm not
sure. Either way, something along these lines will be useful.

pauli.

-- 
  

Paul Isaacs, pauli@sgi.com          Cosmo VRML Engineering, Silicon Graphics

---- New York Serenity Prayer:   -------------------------------------------
God give me the strength to crush those in my way, the money to bribe 
those who can help me, and the wisdom to know the difference.

From vrml-ui-owner@vag.vrml.org  Fri Mar 14 10:42:41 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id KAA16317; Fri, 14 Mar 1997 10:42:39 -0500
Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id PAA12655 for <vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 15:33:20 GMT
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA17442 for <@sgi.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 07:34:28 -0800
Received: from rd.engr.sgi.com (rd.engr.sgi.com [198.29.108.114]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA05901 for <@cthulhu.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 07:34:28 -0800
Received: (from rcg@localhost) by rd.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA25577; Fri, 14 Mar 1997 07:34:27 -0800
Date: Fri, 14 Mar 1997 07:34:27 -0800
From: rcg@rd.engr.sgi.com (Rich Gossweiler)
Message-Id: <199703141534.HAA25577@rd.engr.sgi.com>
To: vrml-ui@vag.vrml.org (vrml user interface)
Subject: Tris-stratificiation
In-Reply-To: <9703131820.ZM4575@uniblab.engr.sgi.com>
References: <199703132231.RAA07365@zing.ncsl.nist.gov>
	<9703131820.ZM4575@uniblab.engr.sgi.com>
Reply-To: rcg@sgi.com
Status: RO

Another advantage to Pauli's tri-stratification is that I find myself
making at least two types of widgets: efficient ones (bare minimum
polygon count, functional) and more visually pleasing ones.  Both could
stem from the same middle-level class that Pauli described.

I also find myself building widgets that affect one simple aspect (a
floating point value, a vec3f or a color) and using these building-block
atomic widgets as input to compound "filter" scripts that take some set of
input types and produce different output types (e.g. floats to
vec3f). So that is a useful division for me (atomic and compound/filters).

So useful are little time-widgets (pulse a time-beat or alarm-trigger a
time after X seconds) that I include these in my atomics, even though
they are not necessarily user-driven.

Given some coverage with the atomics and filters, it is pretty easy to
string these widgets together.

Paul Isaacs writes:
| Also, in my work I tend to deal with 3 'strata' of objects for widgets.
| (Please forgive me for being mouse-centric as I explain this.  I know that some
| of you are concerned with other input devices, and that these thoughts may need
| to be expanded upon).
| 
| At the lowest level are 'surfaces I use to intersect the mouse.'   When I click
| and drag, what kind of surface is the mouse passing over?  In VRML, we've got
| PlaneSensor, CylinderSensor and SphereSensor for this purpose.  For those of
| you who are familiar with OpenInventor, these correspond roughly to the various
| SbProjector classes. It would be difficult to get other variations of these
| objects without revising the spec, but I think that the current set is
| sufficient.
| 
| In the middle level are 'things that move a particular way.'  When I drag the
| mouse over one of the low-level surfaces, the cursor intersects that surface to
| trace a path through space.  I can interpret that path in any number of ways
| and produce different kinds of motion.  For example, I can click-drag over a
| PlaneSensor and interpret this as angular motion relative to some center (as
| with a dial or gear) as linear motion (for a slider or uniform-scaling knob) or
| as planar motion (for a virtual screen cursor or interpreting virtual joystick
| motion). I can click-drag over a SphereSensor and get rotating motion (as with
| a trackball or spotlight-direction-controller) or I can get
| translation-on-a-sphere-surface motion (for positioning flags on a globe).
| If we categorize and wrap-up these various categories, we can then use them in
| the next level up to make our widgets.  Objects at this middle level correspond
| to the OpenInventor 'simple draggers' and have no equivalent in the VRML spec.
| The PROTOS I sent earlier for Translate1DraggerProto and Translate2Dragger are
| of this variety.
| 
| At the top level (perhaps this term is inappropriate -- there will doubtless be
| higher-level constructs presented!) are widgets at the level Bernie described.
| I agree with his ideas for categorization.
| Note that if we've got the middle level objects in place, we can then re-use
| these objects to build our top-level widgets.  For example, I can make a slider
| by bundling a 'thing that moves in a line' with some geometry that sits still
| as a background, and then having a short script (or bundling in some PROTO)
| that maps the translation of the 'thing that moves in a line' into the desired
| range of slider values; the resulting slider value can be the exposed output of
| the slider.
| 
| 
| 
| On Mar 13,  5:31pm, Gregory Seidman wrote:
| > Subject: Re: a proposal for a widget repository
| > } Sascha Becker writes:
| > [...]
| > } > Our proposal:
| > } > A suggested framework for reusable widgets, including:
| > } > - fields for positioning, scaling, showing, hiding widgets
| >
| > Somewhat reasonable, but I think it is external to the widgets themselves.
| > This would be, essentially, a Transform and Switch wrapper around the
| > widget itself.
| 
| I'm pretty sure I agree in the case of a single widget, but remember that there
| will also be organizational widgets (for example, something like the dreaded
| motif form widget), used for laying out some set of sub-widgets. These objects
| will certainly have parameters related to the ones Sascha proposed.
| 
| 
| > From Gregory:
| > } > - API for getting and setting values on valuator widgets
| >
| > Absolutely. I would go with set_value and value_changed (since this is what
| > I have been using in my widgets, after all).
| 
| And if the widget has two values of interest?
| I might prefer something more descriptive.
| 
| 
| 
| > From Gregory:
| >
| > } > - plug-in geometry for author customization
| >
| > Fairly simple for certain widgets, more comples for others. It makes some
| > sense to replace slider thumb geometry and the geometry of what it slides
| > on, but suppose you have a dial? I think plugin geometry will be a problem
| > for some widgets, very reasonable for others.
| 
| I feel strongly that every single piece of geometry must be configurable or
| people will not want to use them.
| 
| 
| 
| > From Gregory:
| >
| > Note that I also have some convienient glue PROTOs (in both
| > VRMLscript and Java) for connecting widgets with Interpolators,
| > Transforms, other Widgets, etc. They can be found at
| > http://zing.ncsl.nist.gov/~gseidman/paper.rev.html in the paper
| > I submitted to VRML '97.
| 
| These are cool.  I like them.
| I might prefer to see them broken into lighter-weight classes, but I'm not
| sure. Either way, something along these lines will be useful.
| 
| pauli.
| 
| -- 
|   
| 
| Paul Isaacs, pauli@sgi.com          Cosmo VRML Engineering, Silicon Graphics
| 
| ---- New York Serenity Prayer:   -------------------------------------------
| God give me the strength to crush those in my way, the money to bribe 
| those who can help me, and the wisdom to know the difference.

From vrml-ui-owner@vag.vrml.org  Fri Mar 14 11:57:14 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id LAA17264; Fri, 14 Mar 1997 11:57:13 -0500
Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id QAA13373 for <vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 16:53:35 GMT
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA06885 for <@sgi.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 08:54:50 -0800
Received: from uniblab.engr.sgi.com (uniblab.engr.sgi.com [198.29.108.116]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA17762 for <@cthulhu.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 08:54:49 -0800
Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA06692; Fri, 14 Mar 1997 16:54:44 GMT
From: pauli@uniblab.engr.sgi.com (Paul Isaacs)
Message-Id: <199703141654.QAA06692@uniblab.engr.sgi.com>
Subject: Re: Tris-stratificiation
To: rcg@sgi.com
Date: Fri, 14 Mar 1997 08:54:44 -0800 (PST)
Cc: vrml-ui@vag.vrml.org
In-Reply-To: <199703141534.HAA25577@rd.engr.sgi.com> from "Rich Gossweiler" at Mar 14, 97 07:34:27 am
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Status: RO

> 
> 
> Another advantage to Pauli's tri-stratification is that I find myself
> making at least two types of widgets: efficient ones (bare minimum
> polygon count, functional) and more visually pleasing ones.  Both could
> stem from the same middle-level class that Pauli described.

At either the middle-level or high-level, all geometry needs to be 
replaceable for use as you describe.

The middle level is for "move one thing this one way."  Here I picture the
fields having names like 'translation' and 'rotation,' to reflect this.
It's at the higher level where we wrap it up to be a valuator, or bundle it 
with other parts/widgets. And it's at this higher level where fields might 
more reflect their use with names like 'sliderValue,' 'diffuseColor' 
(where this is actually an aggregate culled from 3 separate sliders) etc.

> I also find myself building widgets that affect one simple aspect (a
> floating point value, a vec3f or a color) and using these building-block
> atomic widgets as input to compound "filter" scripts that take some set of
> input types and produce different output types (e.g. floats to
> vec3f). So that is a useful division for me (atomic and compound/filters).

These 'filter' scripts are the kind of thing Gregory Seidman examines in the 
paper he posted. He also broaches the topics of logic gates
and an arithmentic calculator. 

> 
> So useful are little time-widgets (pulse a time-beat or alarm-trigger a
> time after X seconds) that I include these in my atomics, even though
> they are not necessarily user-driven.

Yes! I agree.
The time sensor can be programmed to do lots of different things. Wrapping
these up into specifically tuned PROTOS is a whole other useful category.

So let's see, we got a whole bunch of 'atomic' elements coming up:
    TimeControls
    Draggers
    Gates
    TypeConverters
    MathFunctions
What other 'pet categories' do people have?

Do any of you out there dislike this way of thinking?  Why?
What other approaches might we take?

pauli.

From gseidman Fri Mar 14 15:28:35 1997
Subject: Pluggable geometry
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Fri, 14 Mar 1997 15:28:35 -0500 (EST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 950       
Status: RO

Well, okay, I revamped my widgets so that they (some of them) can take
geometry as exposedFields. For some it was important that the geometry
passed in be an SFNode for the geometry field in a Shape, but wherever
possible the geometry is an MFNode exposedField. The revamping has broken a
couple of the PROTOs, the Button and LightSwitch in particular, under
CosmoSGI 1.0.1.

In any case, if you haven't taken a look at
http://zing.ncsl.nist.gov/~gseidman/vrml/refer.wrl yet (look at the source,
don't bother browsing it), you probably should. I have the appropriate
EXTERNPROTO references (listing all fields/events) for essentially every
PROTO I have made available.

Note that the PROTOs do not break under Liquid Reality, though there is
some weirdness with the Mapping PROTO, possibly a bug in my Java code.

Demos of the widgets themselves (using only default geometry) remain at
http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html

--Greg

From gseidman Fri Mar 14 16:55:59 1997
Subject: Twisting extrusion as widget
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Fri, 14 Mar 1997 16:55:59 -0500 (EST)
Cc: www-vrml@vag.vrml.org (vrml)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 661       
Status: RO

Okay, so at the suggestion of the VRML-UI mailing list I have revamped
several of my widgets to have geometry fields allowing real customization
of the widgets. Yeah, sure, it works, but a slider is a slider no matter
how it works, right? Well, no, not exactly, not if it is a Nifty Twisty
Thingy as well. For those of you who enjoyed the original Nifty Twisty
Thingy, I now bring you the TwistSlider (which, I suppose, could become a
PROTO at some point if there is any demand).

see http://zing.ncsl.nist.gov/~gseidman/vrml/twistsliderdemo.wrl

It is nothing more than my BoxSlider with the geometry replaced. Take a
look at the source for details.

--Greg

From sab@cs.brown.edu  Mon Mar 17 23:46:37 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id XAA23456; Mon, 17 Mar 1997 23:46:35 -0500
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 XAA07170; Mon, 17 Mar 1997 23:46:29 -0500 (EST)
Received: from cs.brown.edu (localhost [127.0.0.1]) by poplar.cs.brown.edu (8.7.1/BrownCS1.0) with ESMTP id XAA01854; Mon, 17 Mar 1997 23:46:27 -0500 (EST)
Message-Id: <199703180446.XAA01854@poplar.cs.brown.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: gseidman@zing.ncsl.nist.gov
cc: sab@cs.brown.edu
Subject: vrml-ui biz-buzz
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Mar 1997 23:46:27 -0500
From: Sascha Becker <sab@cs.brown.edu>
Status: RO

Hi Greg--
 
So, looks like we're gonna be co-chairs-- cool! I hear
you'll be visiting Brown soon; we should definitely sit
down and hammer stuff out f2f. I'll be at JavaOne from 
April 1-6, and moving to San Diego in late April; it'd be
good if you could come up before that. 

As far as I can tell, the big thing we need to do as 
co-chairs now is to come up with a charter-- that would
be especially good to do f2f, IMHO. Also, the CHI'97 
meeting is coming up-- will you be attending? (I won't.)
Either way, we need to come up with an agenda for that
meeting, and it'd be good if we could have the proposed
charter for them to discuss there. Mike Pell will be
there, and he's agreed to lead the meeting. 

Right now, where would you like to see the group go? 
Or, as Don B. is fond of saying, "what does success look
like?" To me, the widget repository we're talking about
is "success," or rather, an implementation of the widget
repository that addresses these needs/problems:
- plug-n-play geometry
- well-documented sample code
- widgets that are written with a behavior model amenable to 
  living worlds and maybe the db work group
- iron out the inherent problems of widgetry design in VRML
  enough that it is a solid platform for 3d ui designers. 
- input device-friendly widgets
- widgets that are easily composable, either into functional 
  or spatial groups
- a set of core widgets that demonstrates how the widget
  repository is supposed to work
- widget categories according to both function and level
  in Pauli's stratification 

Last thing to deal with is, pretty soon we should name
ourselves co-chairs-- this is probably an announcement
that you should make, so people start to get a feel for
you as one of the mechanics leaders, too. If you're up
for that, how about running a draft of that email by me--
I don't think it'll be politically sensitive with this
nice bunch of folks, but it's worth being careful about. 

FYI, my home phone is 401 274-9699, and my work fone is
401 863 7693, and I'm generally available noon to late, late
night-- give a call if you want to talk. 

-Sascha

From vrml-ui-owner@vag.vrml.org  Tue Mar 18 01:33:54 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
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 <vrml-ui@vag.vrml.org>; 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 <vrml-ui@vag.vrml.org>; Tue, 18 Mar 1997 01:32:52 -0500 (EST)
From: Sascha Becker <sab@cs.brown.edu>
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
 

From sab@cs.brown.edu  Tue Mar 18 00:28:13 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id AAA23713; Tue, 18 Mar 1997 00:28:11 -0500
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 AAA07911 for <gseidman@zing.ncsl.nist.gov>; Tue, 18 Mar 1997 00:28:09 -0500 (EST)
Received: from cs.brown.edu (localhost [127.0.0.1]) by poplar.cs.brown.edu (8.7.1/BrownCS1.0) with ESMTP id AAA03070 for <gseidman@zing.ncsl.nist.gov>; Tue, 18 Mar 1997 00:28:07 -0500 (EST)
Message-Id: <199703180528.AAA03070@poplar.cs.brown.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: gseidman@zing.ncsl.nist.gov
Subject: chairing responsibilities
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Mar 1997 00:28:07 -0500
From: Sascha Becker <sab@cs.brown.edu>
Status: RO

Paul Isaacs asked me what the chairing responsibilities
were, and I sent him this-- thought you'd be interested
too. These are just my opinions, on the basis of what I
read on the consortium site, and talking to Jan, James
Waldrop, and Mark P. 
 
Does this sound about right to you? Anything I missed?
Having a shared sense of what our responsibilities are
will help a lot, I think.

-Sascha

I think the main responsibility of the chair will
be to keep a steady stream of energy and debate
going. I don't think that chairing means doing
all the work, or even doing all the work that 
nobody else wants to do. As a group, we'll discuss
what we think we should do; the chair or chairs
would then summarize what the group has said,
identify decisions, identify areas that need more
discussion. When we've decided on action items,
the chair[s] will be responsible for keeping
track of who's committed to what, and checking
on their progress. If this widgets repository thing
gets more support, or for that matter if we get
support behind any proposal for concrete deliverables,
I expect the chair[s] will be responsible for 
hammering out details of the proposal, though that's
perhaps a side effect of chairing, not a 
responsibility. The responsibility there is simply
to see that the details do get hammered out,
and that the whole wg has a chance to look at
experiment with, and critique it. 

Other responsibilities involve communicating with the
rest of the community: keeping the www-vrml list 
informed of major milestones, checking policies and
procedures with the BoD, coordinating with other
working groups where appropriate (the Java and Viz
groups will probably be relevant to us). We'd
also need to find a secretary/webmaster, or be
responsible for documenting our work ourselves. 

From gseidman Tue Mar 18 16:30:59 1997
Subject: Widget Layers
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Tue, 18 Mar 1997 16:30:59 -0500 (EST)
In-Reply-To: <199703180632.BAA04332@poplar.cs.brown.edu> from "Sascha Becker" at Mar 18, 97 01:32:49 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 9289      
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. 

I see this as much closer to a layer architecture (such as networking and
the OSI layer model) than a component archictecture. I see some of the
levels below bleeding into each other, as well as having certain
restrictive assumptions built in (such as the mention of a mouse). I'll
give my layer model below comments on the quoted message from Sascha, which
I have rearranged slightly for convenience.

} Level 1: spatial, invisible, non-mathematical
} 	Sphere/Cylinder/PlaneSensors
} 	TimeSensors
} 
} * 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. 

This has the problem of mentioning a mouse, but is otherwise pretty
clearly the lowest level.

} Level 2: non-spatial, non-visible, mathematical
} 	dragging on a plane constrained to dragging on a line
} 	clamping to legal ranges

The stuff above can all be accomplished with a single VRML node, and I would
therefore place them in the lowest level.

} 	mapping between coordinate systems or data representation
} 	discretizing continous values, other type conversions
} 	logic gates
} 	math functions 

I would class these as "internal glue" and place them in a level just
above the lowest. I'll come back to this in the layer model.

} * 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.

The problem here is that the various -Sensors already have clamping and
several other attributes of the second level built in. Given that we are
working with the existing spec including the -Sensors, I would lump much
of this into the lowest level as well. I would put the -Interpolators into
this level. More on where I would make the split in the layer model below.

} 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

This last example (the clock) belongs in one of the two lower levels,
since it is not visible and can be done with a composition of two
VRML nodes.

} * 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. 

I agree that geometry can be active. Take a look at my TwistSlider
(http://zing.ncsl.nist.gov/~gseidman/vrml/twistsliderdemo.wrl) for a
somewhat cheesy example. I also have the LightSwitch interpolating colors
from red to green.

} Examples: 
[moved above]

Here's the layer model I propose:

1. Sensors
2. Internal Glue
3. Geometry
4. External Glue
5. VRUI (Virtual Reality User Interface, analogous to GUI)

To explain the layers I am going to use specific examples from both my
VRML widgets and 2D GUIs. This does not mean that a 2D GUI can be layered
in the same way, by the way, so you will find that the analogies to 2D
are occasionally a stretch.

1. Sensors

These are the VRML -Sensor nodes, including their clamping and constraints
(e.g. the cycleInterval and loop fields in the TimeSensor). This is how
user input is gathered by the browser. A 2D analog is reading the mouse
position or a mouse click, including things like the behavior of a modal
dialog box where clicking the mouse outside the dialog does nothing but
beep.

2. Internal Glue

The VRML -Interpolator nodes fall into this layer, as does a certain
amount of scripting. This layer is concerned with type casting
(e.g. extracting the X coordinate of a SFVec3f into a SFFloat), arithmatic
operations (both those which require a script and those which can be
performed with the right -Interpolator), logical (boolean)
operations/gates, etc. The 2D equivalent would be the mapping in a
scrollbar from screen pixels to fraction of the bar.

3. Geometry

This is where actual widgets come in. You have a -Sensor which you want to
attach to some geometry (ignoring TimeSensors for the moment), some
internal glue to map the values the -Sensor produces to the desired output
(SFFloat, SFVec3f, SFRotation, whatever), and all you need is that
geometry. This should presumably be pluggable in the sense that it can be
represented outside the PROTO definition of the widget and receive events
and such from outside the PROTO scope. An example here is the TwistSlider,
which is nothing more than a BoxSlider with some external glue (see below)
making it twist as it slides. In a 2D GUI, consider the size, color, and
label on a button.

4. External Glue

This is the layer that attaches user input garnered from widget output
to action in the virtual world. It is also desirable to express feedback
to the user with widgets, such as having a Slider representing a number
from 0 to 255 and 8 Buttons representing the number in binary (see
http://zing.ncsl.nist.gov/~gseidman/vrml/buttondemo.wrl). I can go on
and on about this layer, but I will restrain myself.

It can be as simple as ROUT'ing the output from a Button to the
set_enabled eventIn of a (looping) TimeSensor controlling an animation,
thus connecting the state of the Button with whether the animation is
on and looping or not. It can be at least as complex as three Sliders
combining their values into the X, Y, and Z translation of an object or
the viewpoint. This is where type casting, logic gates, and arithmatic
operations become the most useful in a general sort of way. A 2D example
would be a slider that controls the volume of a CD that is playing.

5. VRUI (Virtual Reality User Interface, analogous to GUI)

This is the layer we want the user to see and use in, one hopes, an
intuitive manner. Consider the CosmoPlayer Examiner dashboard (I like
the SGI one better) as such a VRUI. There are widgets to rotate the world,
translate the world, zoom in on a particular object, etc. These all work
together to form a user interface that is easy to understand and use (no,
really, the SGI dashboard is better than the one on the PC). Consider a 2D
dialog box, including buttons, text fields, etc. as analogous.

} Questions: 
} Where do compound widgets fit in? Level 4?

I'm not sure what you mean by "compound widgets," but if you mean something
resembling what I'm calling the VRUI, the answer is layer 5.

} How do interactions between these levels work? Figuring that out will
} be a good test of how strong this model is.

That's why I changed the model. I think the layer interaction is clearer
and more intuitive this way.

} -Sascha
--Greg

P.S. It looks like Sascha and I will be co-chairs of the working group.
Unless there are objections we will be making an official announcement
this week.

From vrml-ui-owner@vag.vrml.org  Wed Mar 19 19:36:32 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id TAA18560; Wed, 19 Mar 1997 19:36:30 -0500
Received: from cinna.ultra.net (cinna.ultra.net [199.232.56.8]) by kether.vrml.org (8.7.5/1.0) with ESMTP id AAA18882 for <vrml-ui@vag.vrml.org>; Thu, 20 Mar 1997 00:33:11 GMT
Received: from [199.232.102.172] (tiamat.jch.com [199.232.102.172]) by cinna.ultra.net (8.8.5/ult1.04) with SMTP id TAA05657; Wed, 19 Mar 1997 19:34:26 -0500 (EST)
Message-Id: <199703200034.TAA05657@cinna.ultra.net>
X-Sender: jch@pop.ultranet.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 19 Mar 1997 19:36:48 -0500
To: Sascha Becker <sab@cs.brown.edu>, vrml-ui@vag.vrml.org
From: jch@jch.com (YON - Jan C. Hardenbergh)
Subject: Re: proposed charter
Status: RO

Good. I'd make the first sentence its own paragraph.

-Jan

P.S. Is this right???:

To join the mailing list, send mail to vrml-ui@vag.vrml.org with

subscribe

in the message body, or contact the co-chairs.

YON - Jan C. Hardenbergh - http://www.jch.com/~jch
To endure, regenerate. Each scale has its seasons. -Tetras.

From vrml-ui-owner@vag.vrml.org  Wed Mar 19 20:42:31 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id UAA18850; Wed, 19 Mar 1997 20:42:28 -0500
Received: from lloigor.axial.com (axial.com [205.179.192.202]) by kether.vrml.org (8.7.5/1.0) with SMTP id BAA19337 for <vrml-ui@vag.vrml.org>; Thu, 20 Mar 1997 01:39:38 GMT
Received: by lloigor.axial.com from localhost
    (router,SLmailNT V2.0); Wed, 19 Mar 1997 17:36:08 Pacific Standard Time
Received: by lloigor.axial.com from lizardo.newfire.com
    (205.179.192.131::mail daemon; unverified,SLmailNT V2.0); Wed, 19 Mar 1997 17:36:08 Pacific Standard Time
From: "Mike Pell" <pell@newfire.com>
To: <vrml-ui@vag.vrml.org>
Subject: Re: proposed charter
Date: Wed, 19 Mar 1997 17:43:22 -0800
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970319173608.1b1704c0.in@lloigor.axial.com>
Status: RO

Hi All:

I think this draft of the working group charter is good. I could live with
it the way it is. I like the focus and it embodies alot the initial
conversations Sascha and I had. 

Glad to see that Gregory is interested in co-chairing. Always helps to have
someone who's been building these things helping to steer.

I have these dates to throw out for your consideration:

March 28, 1997  - Charter proposed to consortium  (after our first f2f
meeting at CHI '97)
April 1, 1997      - Widget repository problem statement (Sascha has
already summarized this)
May 1, 1997      - Groupwide consensus on widget architecture (one month to
argue and test)
SIGGRAPH August 1997 - Widget repository goes live (three months to
implement/test core widgets)

M. Pell
-----------

Mike Pell                  
Interface Architect         "The Desktop is dead. Deal with it."
Newfire, Inc.                                        - me
408.996.3100
pell@newfire.com
www.newfire.com

From gseidman Thu Mar 20 17:07:26 1997
Subject: CHI97 Agenda posted
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Thu, 20 Mar 1997 17:07:26 -0500 (EST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 371       
Status: RO

I can post the HTML if it is really important to anyone, but I am hoping
that someone who can bring up the URL will print a bunch of copies for the
people at the meeting. The URL for the agenda that Sascha and I worked out
last night is:

http://zing.ncsl.nist.gov/~gseidman/vrml/ui/chiagenda.html

...and it will probably eventually get moved to vag.vrml.org.

--Greg

From sab@cs.brown.edu  Thu Mar 20 19:16:52 1997
Return-Path: <sab@cs.brown.edu>
Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id TAA03650; Thu, 20 Mar 1997 19:16:50 -0500
Received: from larch.cs.brown.edu (larch.cs.brown.edu [128.148.31.16]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id TAA17580; Thu, 20 Mar 1997 19:16:44 -0500 (EST)
From: Sascha Becker <sab@cs.brown.edu>
Received: (sab@localhost) by larch.cs.brown.edu (8.7.1/BrownCS1.0) id TAA26983; Thu, 20 Mar 1997 19:16:41 -0500 (EST)
Date: Thu, 20 Mar 1997 19:16:41 -0500 (EST)
Message-Id: <199703210016.TAA26983@larch.cs.brown.edu>
To: panic@construct.net
Subject: an account for greg seidman?
Cc: gseidman@zing.ncsl.nist.gov
Status: RO

Hi Nic--

Greg Seidman is the co-chair of the vrml widgets working
group; he'll be interim webmaster, as well. Can you please
set him up with an account on vag.vrml.org, also with access
to the vrml-ui mailing list files? And, we have a charter
that we'll want to post fairly soon (I think we need BoD 
approval first) --does anything special need to happen for us
to throw up web pages? 

Thanks,
Sascha

From vrml-ui-owner@vag.vrml.org  Thu Mar 20 19:46:45 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id TAA03872; Thu, 20 Mar 1997 19:46:43 -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 AAA26338 for <vrml-ui@vag.vrml.org>; Fri, 21 Mar 1997 00:43:22 GMT
Received: from larch.cs.brown.edu (larch.cs.brown.edu [128.148.31.16]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id TAA18002 for <vrml-ui@vag.vrml.org>; Thu, 20 Mar 1997 19:44:42 -0500 (EST)
From: Sascha Becker <sab@cs.brown.edu>
Received: (sab@localhost) by larch.cs.brown.edu (8.7.1/BrownCS1.0) id TAA27627; Thu, 20 Mar 1997 19:44:38 -0500 (EST)
Date: Thu, 20 Mar 1997 19:44:38 -0500 (EST)
Message-Id: <199703210044.TAA27627@larch.cs.brown.edu>
To: vrml-ui@vag.vrml.org
Subject: temporary home page for our group
Status: RO

Since we've started to get a bunch of documents and links
posted here, I've started a loosely organized collection, at
http://www.cs.brown.edu/people/sab/vrml/home.html

In particular, you can find the proposed charter and proposed
agenda for the CHI meeting there. Please take a minute to
look over the charter; if it's okay with you, just post a note
to that effect. 

If you've got other links that you think should be included, send them
to me, or better yet, the whole list, and they will be.

(This location is temporary; we'll move to vag.vrml.org
as soon as we get our charter approved and work out mechanics
of server space there.) 

-Sascha

From vrml-ui-owner@vag.vrml.org  Thu Mar 20 17:11:32 1997
Return-Path: <vrml-ui-owner@vag.vrml.org>
Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA02880; Thu, 20 Mar 1997 17:11:30 -0500
Received: from zing.ncsl.nist.gov (zing.ncsl.nist.gov [129.6.84.33]) by kether.vrml.org (8.7.5/1.0) with SMTP id WAA25602 for <vrml-ui@vag.vrml.org>; Thu, 20 Mar 1997 22:06:06 GMT
Received: by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4)
	id RAA02860; Thu, 20 Mar 1997 17:07:26 -0500
From: gseidman@zing.ncsl.nist.gov (Gregory Seidman)
Message-Id: <199703202207.RAA02860@zing.ncsl.nist.gov>
Subject: CHI97 Agenda posted
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Thu, 20 Mar 1997 17:07:26 -0500 (EST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: RO

I can post the HTML if it is really important to anyone, but I am hoping
that someone who can bring up the URL will print a bunch of copies for the
people at the meeting. The URL for the agenda that Sascha and I worked out
last night is:

http://zing.ncsl.nist.gov/~gseidman/vrml/ui/chiagenda.html

...and it will probably eventually get moved to vag.vrml.org.

--Greg

From gseidman Tue Apr  1 21:20:59 1997
Subject: Re: Report on Working Group meeting at CHI '97
To: vrml-ui@vag.vrml.org (vrml user interface)
Date: Tue, 1 Apr 1997 21:20:59 -0500 (EST)
In-Reply-To: <19970401105544.152e8a89.in@lloigor.axial.com> from "Mike Pell" at Apr 1, 97 11:02:29 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1096      
Status: RO

} Has everyone bailed on this list or has my last message caused lots of
} backroom discussions?

I believe that Sascha is at JavaOne now, and I haven't been in touch
with her since the report. I have been meaning to put out a new charter
proposal, but due to a tremendous workload coming due right around now
I have not yet done so. I don't really have time until Friday, here's
a quick rundown on what I was thinking:

Granted, we want to be working on the larger user interface issues and
not just widgets. On the other hand, we would also like to establish the
User Interface WG as 1) official, and 2) productive.

I am very much in favor of producing the core widgets and widget
repository by SIGGRAPH'97, and that involves getting to work on it
now. We need a charter to make us official, and I think for that we
need a short-term timeline including the deliverables listed in the CHI
meeting agenda.

I will try to produce a proposal on Friday, but I will be out of town
until then. If anyone wants to takes these thoughts and either run or
argue with them, go for it.

} M. Pell
--Greg