From: owner-3dui@hitl.washington.edu on behalf of Ernst Kruijff [kruijff@fossi.uni-weimar.de] Sent: Tuesday, January 25, 2000 2:59 AM To: 3d-ui@hitl.washington.edu Subject: system control - techniques and guidelines Dear 3dui list! In this email, I would like to ask you all a couple of questions. I am currently restructuring the system control notes of the 3DUI tutorial (the one I am part of with Doug, Ivan and Joe), and would highly appreciate some comments! It is "pretty" long (I AM VERY SORRY!!!) , but hey, there hasn't been discussion on the list for quite some time :-) Feel free to cut large parts out of this mail when replying... Or give ma a "hint" and I'll subdevide the mail. I hope some people can find time to read through everything.. --- Just for the record: I understand under "system control" the issuing of a command (for example, change of mode of interaction) --- ----------------Question 1 First of all, I would like to ask if someone knows about "unusual" system control techniques used in virtual environments. I have been looking around through publications and projects and have come to a preliminary (rough) categorization of system control techniques and would like to see if it really works... You can find the categorization at: http://www.uni-weimar.de/~kruijff/systemcontrol.gif Any comment is appreciated! Useful publications or project links which might be applicable (next to the "obvious" ones I have from Mine, Conner, and so on) are therefor also very welcome! ---------------- Question 2 The second question I have applies on guidelines for system control. Due to the relative lack of evaluation on 3D system control, it is pretty hard to come to guidelines which are really applicable - I have come to the next list, which is "extracted" from several studies (including Mine, Shaw, Conner, and so on) and several studies we did here with our own software environment (largely user observations of over 1000 users over the last 5 years). We use a HMD and a stylus in our environment, by the way. Still, the guidelines might well -not- apply at the environment you have, or the experiences you have. Comments are very welcome, and so are new guidelines which might be added to the list! If you have publications which support or undermine (!!!) the guidelines, I would also appreciate it a lot to get a link!I have tried to order the guidelines a bit, and gave some comments to them. The guidelines are focussed at immersive environments, though some desktop-based stuff has found its place in the guidelines too. -------------------- Guidelines SPEED -Place system control at the right place / I have subdevided "place" in body-centered, environment-centered and device-centered to communicate spatial reference frames for placement - this seems useful to me. Basically, I think one should avoid that the user has to find the system control interface (and is often unable to do that) or that he/she has to re-orient the interface to control it (or change his/her viewpoint) -Possibly constrain DOF's / Old guideline, basically coming from guidelines applicable to selection -Adapt size of system control elements to technical characteristics of the environment / my collegue started using shoe-boxes here to show our users how big a button usually should be in our environment - our users often designed system control interfaces with far too small buttons which were hard to select, due to tracker noise. EASY TO LEARN -Don't overdo amount of elements / what I have seen here in our environment is that when too many interface elements (ie. buttons, sliders, and so on) are placed, it often takes too long for the user to oversee all elements, next too the fact that buttons easily become too small - seven elements (plus or minus 2) seemed to work well in our environment. The same might apply for gestures - I have never seen gestural interfaces which used more than 10 or so gestures (did someone do see a working one?) The only exception I have seen was a huge widget in a cave, with at least 25 buttons, placed on a side of the CAVE - due to the available "screen estate" they could easily make a huge widget was was overseeable too. (one other exception which might pop up is "sign language".. this has far more than 10 gestures, of course..) -Structure your system control interface(s) / devide system control over different interfaces (case sensitive): so, use object-specific system control interfaces and general system control interfaces for basic commands. Do not use submenus, in our env. it at least takes a user far too long to scroll through all menus to find the function, even if the ordering of the elements is somewhat clear. -Use familiar metaphors /in about every system control interface our users made, the ones which used icons which were based on traditional 2DUI menus performed much better than the ones which used fancy, sometimes even animated icons using new metaphors. One exception was a menu in our env. based on kids toys metaphor (animated icons) - it was soo simplistic that everyone got it. i suppose the "magic" people will have something against this guideline KEEP THE USER FOCUSSED AT THE TASK -Match system control to task / same guideline actually as the previous one: use case-sensitive menus and place the system control interface at the right place - avoid that the user looks away from the task he/she is currently performing. Proprioception might sometimes be a good cue (ie. connected to place of system control!), as Mine has shown with his hand held widgets: the user is still focussed at the task and at the same time performing commands. GIVE USEFUL FEEDBACK AND APPLY STRONG AFFORDANCE -Structure your system control by form and color /an oldie.. -Let the user know when a command has been initiated / we had remarkable results in our environment with respect to this point by using different stylus appearances: when a user would have selected a command, the form of the stylus would change, sometimes including some animation - the user always knew when he/she had selected which command/function. -Make use of strengths of input and output devices for affordance / match system control to characteristics of the devices you use - this might be the most obvious in case of props. BE "SCREEN EFFECTIVE" -Don't occlude the field of attention of the user / It seems obvious that when a user is manipulation an object, it greatly disturbes the flow of action when a huge widget occludes this object. Sometimes transparant menus might come to hand here, like for example the Virtual Pallette of Coquillart and Wesche. ------------------------- end! Okay, that is it..... Looking forward to comments!! -Ernst ernst kruijff (M.A.) teaching and research scientist ____________________________________________ .................bauhaus-universitaet weimar .....................faculty of architecture chair caad and architecture [prof.dr.donath] ............................d - 99421 weimar .............fon/fax: +49 (0)3643 584282 /02 .........email: kruijff@archit.uni-weimar.de ......url: http://www.uni-weimar.de/~kruijff ............................guest researcher .........Virtual Environments Group (IMK.VE) ............................GMD St. Augustin