Cosmo Player 2.0 Design Process Research I started the project with a research group, and we evaluated academic work, competitors' browsers, and popular games to understand the current state of the art. Then we used a modified version of the existing Cosmo browser as a testbed, and implemented an early prototype of the navigation interface. An important part of the early iterations was making sure the movement control algorithms felt natural. We tested our prototype with both novice and expert 3D users, made refinements, and then plunged into development and more iterations. After our analysis of other browsers, research, and games, we came to the conclusion that good solutions to the problem of 3D navigation have to keep the following in mind: 3D Navigation should be designed with intimate knowledge of the environment. There is no such thing as good "general" 3D navigation. Use 3D only when it can provide something that's needed, not just because it's "cool". 3D works in games because navigation is the point of the game - getting better at navigating means that the user gets better at the game. When navigation isn't the main task at hand, 3D usually takes away from the experience. Product Requirements In spite of our knowledge of the above, we were designing a product for navigating in 3D on the web in 1996. We had to work within these restrictions: Most users had not navigated in 3D before, although there was a vocal subset of experts (3D gamers). Most users only had a mouse and keyboard. The browser had to conform to the VRML97 Specification. The VRML spec contained specific rules about the types of viewers that must be provided. VRML was a general 3D modeling/authoring language, and therefore the browser had no prior knowledge of the types of worlds and geometry that could be presented. Design This design had an interesting and frustrating difference from my previous projects: the usual methods of design communication and documentation didn't work very well. Flowcharts and schematics were absolutely no help in communicating the nuances of movement in the browser. In the end, the prototype became the specification, with a written text document backing it up. One useful analysis was to map all possible user actions onto the list of all available inputs. The resulting chart was our guide as we explored keyboard mappings, and debated the need for constraints on movements. Prototype We created an early prototype, with very primitive buttons and graphics, and tested it on both experts and novices. One of the best results from user testing was that it convinced us that we had to include the "crosshairs and rubber band line". This small x mark and single-pixel line to the cursor showed users the initial click point of their mouse, plus the distance that the cursor was dragged away from that point. I had initially been hesitant to include the crosshair because it was "on the glass" of the monitor, and not a part of the 3D world that the user was exploring. In fact, we had purposely left it out for the user tests. However, since all movement depends on how far and in what direction the mouse is dragged, giving users good feedback turned out to be even more important than maintaining their sense of immersion in the world. User testing also confirmed that the snap-to-level function was extremely useful when the user was looking up and down, and that the Undo Move button was indispensable. Graphic Design I worked with Construct Internet Design to choose an initial visual design direction, and to refine the interface to its current look. Users said that it looked like a cross between a car dashboard and a boom box, which was great because that was precisely the effect I was trying for. It looked "cool", which was important for a 3D browser. It looked familiar, which was important for the millions of novice users. And it evoked a sense of navigation, of going somewhere, which is exactly the function it served.          Click to see the progression of early visual designs Back to Cosmo Player main page