Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ns.uoregon.edu!milton!hlab From: Craig_Keithley.SERVICE_TOOLS@gateway.qm.apple.com (Craig Keithley) Newsgroups: sci.virtual-worlds Subject: Semi-virtual environments Message-ID: <1991Apr4.061847.18453@milton.u.washington.edu> Date: 4 Apr 91 02:00:47 GMT Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab) Organization: Human Interface Technology Lab, Univ. of Wash., Seattle. Lines: 70 Approved: cyberoid@milton.u.washington.edu Subject: Time:5:00 PM OFFICE MEMO Semi-virtual environments Date:4/3/91 >Regarding the question of implementing some aspects of virtual reality without using gloves and goggles. Would a simple (non-3D) screen be enough? I'd say yes. In fact, that's what I'm thinking of doing for *my* MacMud. While we're on that topic, here's a more detailed description of why I'm interested in VR/VW/VE (virtual-reality/worlds/environments). My interest in virtual environments is to increase my knowledge of: What is workable -and- What is desirable In the realm of "improving the user interface". Some GUI OS shell programs (like Windows 3.0, GEM, Mac OS, and X-something or other) apply very rudimentary virtual object and virtual behaviors to the computer system functions. The Mac might not be the best example, but I'll use it anyway. The system software has attributed a set of object behaviors according to the object type. Folders expand when double clicked. Files launch the related application when double clicked. Applications launch when double clicked. While the user's action is the same, the observed result is dependent on the system software (and the object type). Dragging a file, folder, or app to the trash will "delete" it. The Mac already has a limited ability to do something different with applications when you just click on them. The app's icon is stored as both a "released" and "depressed" state. Clicking on an app icon (not double clicking) will appear to temporarily modify the icon. Another humorous (and sexist) example of extending object behaviour is the Mac INIT known as "tits". Some third party programmer got a bit wierd. Installing this INIT changes a hard disk icon to a pair of tits. The fuller the hard disk, the bigger the breasts. In this case (as in almost all Mac examples), the system software has been extended to behave differently according to the object's attributes. My personal goal is to investigate the possibility of extending or moving the object behavior outside of the system software. And I'm interested in making this extension resonably consistent. While "object" scripts could be attached to all file folders, files, and applications, the previously described MUD problem of data base bloat, context switching between all scripts, etc., also appears here. These are the problems I want to learn how to solve. Its too early to tell if such an extension (to the Operating system & objects) is worth the trouble. And since we (Apple) try to pride ourselves on consistancy of object (systems & apps) behaviour, this would definately be a problem if we removed the responsibility for this from the OS. Our research has shown that while vast quantities of IBM PC users blame the app writers when something is hard to use or bombs, they blame Apple if the same problems appear when running on a Mac. Placing the object behavior *in* the object would probably make this worse... Craig Keithley keithley@apple.com disclaimer: My work has nothing to do with virtual-reality (or reality for that matter!) --