Category Archives: VR

The long quiet followed by a Hard Shake

So I’ve been quiet for quite a while. The blog article ideas have been mounting up, and I’ve not been writing them. A lot of the time I don’t actually enjoy the writing process. I don’t know if you’re meant to enjoy it, but I find it hard to sit down and write out the ideas that are piling up. I have a bit more free time at the moment, so I should be able to force myself to write some out. If anyone has ideas on how I enjoy the process more then I’d love to hear them.

Now onto actual testing stuffs.

A lot of us have heard of the testing technique galumphing which was originated by James Bach.

It’s a technique I used before I knew I used it; as is the case for many of us. We don’t know we necessarily do this thing, but when someone can explicitly describe the action in a way we can understand; that’s when we get the “oh yeah” moment. We’ve often galumphed our way through a site without realising we’re doing it. This is the value in someone like James. Someone that can find a descriptive term for something that was previously tacit knowledge.

What happes when galumphing doesn’t just desribe how you might click around a site, but it actively describes how you might traverse a VR application?

Well the best techniques are the ones that are still relevant to situations beyond which they’re written for. Did James actively think about VR testing when he wrote about galumphing?

Probably not, but he didn’t need to. He understood the concept of how unintended movements (physical or control-system based) will apply to a variety of situations.

Introducing the Hard Shake

So during my VR Testing I have been (concisouly and unconciously) carrying out
lots of galumphing. This has happened to the extent that I feel certain movements within that approach deserve to be named.

So for the first one of these techniques, I name the Hard Shake.

The naming of this happened quite naturally. A tester that I’d recruited talked about an issue they’d found in the app, and demonstrated the movement required to trigger this issue. I then asked whether he could recreate the issue without a Hard Shake.

This wasn’t a term I’d used before, but it instantly felt lke correct. It described a movement I’d carried out numerous times before; often used as a way to transition between steps. It can be used at any point however. It is very useful for uncovering performance issues, and unintended effects from gaze being shook in that fashion. Remember that this is something that can be used at anytime within the headset. I mentioned transitions, but even at times when the user may only be receiving information; it is useful to carry out and see the results.

So here we go, the Hard Shake. It seems simple. I’ve talked to other testers that have done this naturally without thinking. However, when we can explicitly talk about and name techniques; it gives us a platform on which other knowledge can be built. This is harder when the knowledge stays inside our heads and is exercised in a tacit manner.

Part of this issue is connected with how instinctual testers work. This is something I’ll cover in a future post.

Advertisements

Testing Room-scale VR

I tested the HTC Vive headset recently which opens up a whole new realm of possibilities. This obviously means more ways in which issues can manifest.

The HTC Vive is geared towards a Room-scale VR experience. The user will be generally stood up during use. This means more things need to be taken into account by the teams developing and testing these applications, which are mostly games at this point.

Now although Oculus Rift have stated that their headset is capable of Room-scale VR it is geared towards a sat-down experience. Understanding these distinct experiences is necessary before we can start to think about how we are to test them.

Sat down experiences take out the issue of a user bumping into their environment. It would still be possible in some particularly confined setups, but these are edge cases IMO (still not to be fully dismissed). Sat down experiences also take out the worry of becoming entangled in the headset cable and take out the possibility of a user tripping over.

Whilst all the above is true, sat down experiences also lose an element of immersion. Putting the HTC Vive headset on and experiencing the environment for the first time is an incredible feeling. Something as simple as kneeling down to pick an object up feels special. The controllers for the Vive also add to the experience, but they also provide another area for things to go wrong.

Applications being developed and tested for Room-scale VR have to take into account the variety of spaces people will have. Some developers have stated that you don’t need a huge amount of room to experience Room-scale VR. It is said you need enough room to stand up and stretch out in all directions. This video from the makers of Hover Junkers explains:

Whilst the makers of Hover Junkers have been very attentive to room size issues and the range of rooms users will have; we cannot assume everyone else will. We have to be aware that room size issues will come into play. Using boxes/crates to quickly change the test space you have is going to be necessary. It’s all well and good having the great test space you’ve setup in the office but how will that translate to the student dorm room?

Thinking about testing Room-scale VR leads me to think that we need a new heuristic to aid this testing.

An interesting discussion and more on simulator sickness

I’ve just watched this very interesting discussion on VR gaming here. I highly recommend watching it. There are a number of concepts discussed, one of which I want to raise here.

So according to Oculus Rift; Simulator Sickness is cumulative. Let that sink in for a minute…

This has a number of connotations that both developers and testers will need to be aware of. It means very slight triggers will build up over the course of the game and could overwhelm the user. The general advice to users is that if you feel any type of sickness, then you should take off the headset and have a break. Now I know that bit of advice and would generally always follow it, but let’s paint a scenario.

User is playing a game in VR and there are some minor ways in which Simulator Sickness is being triggered. Maybe it’s to do with the way doors have to be opened, but a lot of users generally won’t react to a minor feeling of Simulator Sickness, especially if they’re engrossed in the action. If this is allowed to build up, then it could overwhelm the user and make them feel much sicker than if they’d encountered one thing that triggered Simulator Sickness very quickly.

I encountered my worst experience of Simulator Sickness when I allowed it to build up. I ignored it because I was having too much fun, silly I know but these are the things users do! If you’re immersed in an incredible experience then many people will delay pausing that experience to take a break. This is why it’s falls on the developers and testers to make experiences which minimise the potential.

Simulator Sickness is one aspect of the VR experience that we have to be aware of and account for, amongst many others that I will continue to talk about.

Questions for the new frontier

There are many exciting things about working on VR projects at the moment. The infancy of the technology coupled with the potential of applications is staggering to me. I love the conversations that get bounced around the office. Any conversation can yield questions that no-one on the planet knows definitive answers to (yet).

That is something which completely excites me.

So after checking out some different games in Oculus Rift recently; I gave myself a case of simulator sickness. Now if you’ve never experienced this; it’s similar to travel sickness but can come on suddenly without warning. It can also pass just as quickly for those of you who might be worried.

I was taking a walk around the office and a dev mentioned simulator sickness would be less of an issue; once I had built up a tolerance. Now I’m not sure building a tolerance as a tester is beneficial. It is easier to gauge the reaction of someone with a tolerance to VR systems, but not as easy to gauge the reaction of a new user if you already have a tolerance.

Then the magic conversation. We start thinking about how this tolerance works. Is this a tolerance which is fluid? Given enough time your tolerance could reduce to a lower level maybe? Or is this a situation where once you’ve walked through a gate; there is no turning back and returning to the way you previously were.

There are so many disciplines colliding here, and so many things to think about. I am hyped to see this all unfold as we find out more!

Immersion and presence – Why are they important?

Testing is about gaining knowledge. To understand how to test VR effectively; we need to understand VR. In my last post I referenced a paper by Daniel R. Mestre; in this post I will go into what I’ve learnt from this.

So how do immersion and presence work together in the VR experience?

Presence is defined as the sensation of being in the virtual environment

We can think of presence as being a psychological quality. It is our perception of existing inside the virtual environment, it is subjective.

Immersion is capable of producing a sensation of presence

(Ijsselsteijn & Riva,2003)

Let’s think about this connection. Presence is the subjective feeling of being within a virtual environment, and immersion provides a vehicle for this feeling.

“The term immersion thus stands for what the technology delivers from an objective point of view”

(Mestre, 2005)

The connection should be clearer now. Presence is a subjective term; which covers how a user feels about the virtual environment; from a psychological point of view. Immersion covers what the technology can objectively deliver; to give the user a strong feeling of presence within a virtual environment.

Now who is best placed to “measure” immersion levels?

Well obviously I’m going to say testers. We’ve been doing something like this for years, but calling it user experience. Now I’m not saying testing VR is just UX testing, but it is about taking some of those principles and applying it to VR.

We cannot fully control how present a user is within virtual environments, but we can control how immersive a virtual environment can be. If we create an experience which allows complete immersion, then a user is more likely to feel present there.

 


References from the paper “Immersion and Presence” by Daniel R Mestre

http://www.ism.univmed.fr/mestre/projects/virtual%20reality/Pres_2005.pdf

Presence vs. Immersion

This article was bought to my attention. It talks about the concepts of presence vs. immersion, how they relate and cover different aspects of the VR experience.

I’m going to dive into this over the next few days and see how this knowledge can help improve my testing approach.

I’ll be back next week with an article covering what I learn.

Don’t worry, it’s only minor – Bug severity in Oculus Rift testing

Bug severity always raises different opinions. We’ve all submitted a bug and seen it edited down to a lower severity. Severity ratings become a loose guide to the nature of a bug. They can be useful, but seeing the 1-5 rating does not relate enough information on its own.

x8cdw

There are bugs that are a lower priority to fix, but there are no minor bugs when testing in VR.

*ANY* bug can break immersion.

Our aim is to give users the most immersive and seamless experience possible.

A bug may be minor in nature, but its knock-on effects are never minor. A user may recover immersion quicker from a less critical bug but that does not make it minor.

Immersion is totally possible, but only if we make it the smooth experience it needs to be.