Steven Yoo - VR Looking Inside

Context

VR Looking Inside is a suite of VR simulations for STEM learning in K12 classrooms. All of the simulations are designed with the intention to facilitate collaborative, constructivist learning experiences for small student groups. Allowing students to explore interactive, 3D models and simulations together provides them with the opportunity to make mistakes and come to a solution through their collaborative dialogue. My role included the screenshot feature in the simulation and assisted in the development of video games by testing and providing feedback on products during all stages of development.

Contribution

Photo/Screenshot Mode

Post-Processing Effects

Design Process

Users

First of all, we reassessed the different types of users that would be joining the experience and how they'd be using it:

Students: when in the same physical space, they will be the main users of the simulations and workbooks, collaborating with each other within the experience. They could also join as spectators using a computer or tablet from anywhere, and be part of the audience while the teacher is giving a lesson as an avatar virtually.
Teachers: when in the same physical space, they will be the ones setting up the environment and facilitating the experience. They could also join the experience to give a lesson virtually as an avatar, interacting with the simulations directly while explaining the concepts to the students who joined as spectators.

Design Considerations

Because VR had been around for a while when we started the project, most of the constraints and best practices related to the medium had widely been discussed by many researchers and designers in the community. Here are some of the main considerations we took into account when designing the simulations:

Camera and world movement: one of the main best practices we kept in mind when designing any feature in the simulations was that both the camera and the environment as a whole should not be moved, rotated or scaled under any condition; doing so could induce motion sickness and discomfort to users. Any transformation of the camera should happen naturally when the user moves the headset.
Viewing zones: when positioning the main elements of the simulation on the scene we kept them for most of the time within a horizontal field of view (FOV) of around 70°, and a vertical FOV of around 50° and below eye level. The only few times in which we are moving elements of the simulation higher than that level is to catch users attention in certain WOW moments.
Height range and arm length: something we had to be aware of when designing the simulations is that they would be used by middle school students as well as adults, which means that both height and arm length should be something to really consider when designing interactions and placing elements in the world.
Text readability: since every simulation depended on text at some point for certain information to be delivered to the users, it was important to make sure that the text was of the right size and at the right distance to be readable.
Body position: we tried to keep users' arms at a natural and comfortable position close to the body in a 90 degree angle for most of the time to avoid the so called problem of gorilla arms, in which users quickly get tired from having the arms extended for long periods of time.
Multiplayer experience: probably one of the most challenging constraints was that the simulations could be played either in single player mode or together collaborating with other people. This affected the both the design of the space and interactions to accommodate for all the different scenarios.

Prototype 2

After doing some testing sessions with our first prototype, we learned some valuable lessons:

The floating hand menu was not comfortable to use for long periods of time.
The current design of the simulation space wasn't compatible with the envisioned multiplayer mode, where users would spawn all around the center of the space.

To solve the issue with the center of the environment not being visible to all players around it, we decided to remove any element that didn't belong to the actual simulation and make the simulations as much symmetrical as possible, so they are equally visible from any perspective. At the same time, to be strategic about the team size and the areas of the scene we should focus on, I divided the environment into 3 areas:

Interactive area: this area would change its structure/arrangement completely based on the selected simulation. This was because each simulation would have different needs in terms of disposition of the elements and interactions. This area is right at the center of the scene and players would spawn around it.
Static area: this would be the area which sets the narrative that ties all simulations together. It should look like a futuristic lab with an open ceiling. It would be static and the same for all simulations (with the potential of having some assets specific to each simulation).
Sky area: the area outside the spaceship would set the mood for the current topic. Thinking about the potential of having more topics apart from cellular biology in the future, it would showcase the location where the futuristic lab has traveled: if the loaded topic is about studying the solar system, the sky will display the space; if the simulation is about studying cells, it would look like the inside of a cell.

This scene structure would allow us to focus on having the highest amount of detail and time spent in the interactive area, which is where the actual simulations would take place and the closest to the players. After that, the static area would also be pretty detailed but without spending as much time on it in comparison to the first area since it would be shared by all simulations. Finally, the sky area should be the area where we spend the less amount of time but would be the one that sets the mood in terms of lighting and overall feel for each topic.

User testing

The user testing for this project has been happening continuously and has allowed us to quickly iterate based on the feedback received. During the process, we got feedback from subject matter experts, teachers and other designers and developers from the NYU community not directly involved with the project.

Page updated

Google Sites

Report abuse