Category Archives: VR

ATD decompression and the synergy of presence

Going to my first Agile Testing Days event was possibly the best career-based experience I’ve had. I met a wonderful array of people, and found it incredibly welcoming. I can be socially awkward, especially in crowded situations like that, but the atmosphere and warmth from everyone there made it easy for me. Big love to the 4am people, you know who you are 😉

There have been no lack of ideas that have come from the conversations taking place, the questions I was asked during my talk, and realisations I’ve had since I’ve been back home.

There was a curious idea that I realised after being back home. At an event like Agile Testing Days you are present with many other testers, you’ve read their blogs and watched their talks. You know their ideas, but because you’re sharing a social space with them; it feels like their ideas are more present in your thoughts. But this is something I only realised in retrospect. It came to me when I was thinking about a question I was asked about paired testing in VR.

I immediately answered that paired testing was a great model to use for VR Testing, then I went on to mention mobbing, and how that could work well too. Now I know about Maaret Pyhäjärvi‘s work on mobbing. I’ve also thought about it in passing as a good model to try for VR Testing. In that moment when I answered the question, the fact I had seen Maaret around the conference and said hi, meant that the idea was more present in my head. Then during Maaret’s talk I was inspired to start formalising those ideas into a workable model.

I love the organic way things like this happen. It all stems from those simple interactions and just being in the same place as so many inspirational people.

Advertisements

Bucharest and why Q&A is the best

I recently gave a keynote for the IM World conference in Bucharest. Firstly, I want to say thanks to the organisers. It was a wonderfully organised event. Anyone organising a conference needs to take note from how they treat their speakers. They have organised a diverse event with a great range of speakers and subjects.

I had been looking forward to the talk before the event, a great opportunity to connect with an audience and chat about my experiences over the last few years. Although there was one part of that I was looking forward to the most, the Q&A session.

Now I know some speakers dread that part of their talk. I know of some speakers that purposefully make their talk longer so there isn’t any time left for Q&A. To those speakers, I say I understand but you are missing a trick.

The Q&A section is understandably daunting from one POV. You’re on stage and are at the mercy of your audience. They can ask you absolutely anything, things that you know could reveal areas of ignorance. You’re scared that you won’t be able to maintain this image of being all-knowing about your chosen subject. I completely understand this mindset, but I am going to tell you why you’re wrong.

First off, you’re not all-knowing!

I don’t care who you are, absolutely none of us are all-knowing.

Accept it and revel in the fact!

Not being all-knowing is a good thing. It means it’s fine to not know something, it means you can answer a question by saying I don’t know. It means you can answer a question by saying,

‘I hadn’t thought about that, but thank you, that’s a great question for me to investigate.’

I knew before my Q&A session that I would be asked questions about things I had never thought about. But I also knew that anyone who asked me questions would be aiding me. When you can think of your audience’s questions as an aid rather than an hindrance, that’s when you can level-up!

Instead of fearing the questions, you realise that they give you material. From the questions I was asked after my last talk, I’ve gained 3 topics for blog articles. I made no effort to get that material, I was already doing my talk so that’s a bonus to me.

The above can also be tied into classic Sociology, where researchers realised that using a qualitative approach to research bears answers to questions that the researcher would never have thought to ask.

Being open to what people say instead of fearing it will benefit you in ways you haven’t even thought of yet. It will even get you steps closer to being all-knowing, not that you’ll ever get there but it’s worth a go right 😉

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.

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