xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (08/24/90)
Several recent articles have focused on the problems and possibilities of navigating (and assisting navigation) through a complex, many dimensioned/categoried data space/virtual reality. While agreeing with those who point out the difficulties, most of us have probably shared an experience that shows one way to make this work. If you have played the games called in the US Dungeon or Zork (commercial version), or the Crowther & Woods (sp?) Adventure game, you probably all did as I did: blundered about a while, realized the need for a map, made a map, used and expanded the map as more was learned, and then finally put the paper map aside as familiarity created an equivalently functioning internal map. Perhaps the unmet need in this paradigm in the discussion so far is that the virtual reality should include a convenient way for the user to create his/her own map; my first impulse would be simply an easily accessed freehand drawing area with tools for ovals, titles, arcs, and so on, panable and zoomable as needed. Thus, rather than solve the problem of making a navigation system suitable for all users, we make all users cartographers and let them teach themselves navigation, with only some primitive initial toolkit. After a while, studying the maps the users create, we can learn from them what (varied) ways of keeping ones directions straight are in use, and incorporate (the best of) them into our system's "autopilots" as time and user demand allow. A very wise cartographic support programmer manager of my acquaintance in Canada used this as his sole development criterion. Does this have wider applicability? I've always liked systems that stayed in a prototype stage "forever"; it is what most attracts me to Unix. Would this work for a virtual reality project as well? Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
schraudo%beowulf@ucsd.edu (Nici Schraudolph) (08/29/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Thus, rather than solve the problem of making >a navigation system suitable for all users, we >make all users cartographers and let them >teach themselves navigation, with only some >primitive initial toolkit. This can work out great if the initial toolkit, primitive or not, has enough potential power and flexibility (eg. Turing equivalency). A case in point are the robots that have been popping up on TinyMUDs (multi-user text-only VRs) - among other functions, they wander around building maps of their environment, enabling them to give the users directions to locations, objects and other users. Some user just had the idea, programmed the first one, and soon they became part of the inventory on any TinyMUD. However, this kind system development only works if there is a large number of interacting users, so that there are enough contributors to ensure a steady stream of improvements (as with the Unix world). >After a while, studying the maps the users >create, we can learn from them what (varied) >ways of keeping ones directions straight are >in use, and incorporate (the best of) them >into our system's "autopilots" as time and >user demand allow. >A very wise cartographic support programmer >manager of my acquaintance in Canada used >this as his sole development criterion. >Does this have wider applicability? Well, have you ever seen a campus on which the footpaths were where you needed them? Why don't they just build the buildings without connecting paths, wait a year, and then throw concrete slabs every- where where the grass is trampled down? Just wondering. -- Nicol N. Schraudolph, C-014 "Big Science, hallelujah. University of California, San Diego Big Science, yodellayheehoo." La Jolla, CA 92093-0114 - Laurie Anderson. nici%cs@ucsd.{edu,bitnet,ucsd}
brucec%phoebus.phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen) (08/30/90)
In article <1990Aug24.164049.5512@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > ... > > Perhaps the unmet need in this paradigm in the > discussion so far is that the virtual reality > should include a convenient way for the user > to create his/her own map; my first impulse > would be simply an easily accessed freehand > drawing area with tools for ovals, titles, > arcs, and so on, panable and zoomable as needed. > > Thus, rather than solve the problem of making > a navigation system suitable for all users, we > make all users cartographers and let them > teach themselves navigation, with only some > primitive initial toolkit. This is a useful idea, but it's not a complete solution for two reasons: 1) Most users really don't want to have to spend all their time mapping a system before they can use it. If they are given most of the maps they need, and can just pencil in some annotations and short-cuts they'll be happy. Users may not want to play zork, but get some work done, instead. As an analogy, you don't have to be a cartographer to be a navigator, and you don't have to be a great navigator to travel the freeway. 2) The complexity and high connectivity of a large data space will mean that freehand drawing tools won't be sufficient for the task. I'll bet that the tools will have to be customized for the characteristics of the space involved (you thought there was going to be only one cyberspace, eh? How many Unoids are there?). On the other hand, your suggestion may be a good way to develop the tools to give to the users. Just like out on the frontier: send out a scout to make a map. Send enough scouts, and get back enough maps, and you can print an atlas for all the less sophisiticated travelers who come later. > ... > I've always liked systems that stayed in > a prototype stage "forever"; it is what most > attracts me to Unix. Would this work for a > virtual reality project as well? There's a lovely paper which compares Unix to Zork in both cognitive and user motivational terms. Maybe you like Unix because it's an adventure game? Still, I just don't think Unix will succeed as a theme park (some small fraction of :-) -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077