INFR 4350 - iMind Usability Testing

For the final project in the HCI class, our group had to create iMind. iMind is essentially a project where we explore whether or not a brainwave interface can be used to interface with an artistic experience. This is an interesting project for me because I have never done anything like this before.

We used the Neurosky Mindwave for the project and had it hooked up to our Unity project. We ended up with having a roulette of images and depending on what the user's "meditation" and "attention" values are. When the user blinks, the roulette would spin and display a new image.

An angel image displayed in the system.

We were required to do some usability testing for the project, so this past week we conducted those. The first thing we did was draft up a questionnaire for the participants. There were three parts of the questionnaire: demographics, pre-test and post-test.

Demographics gives us some general information about the participant's background which is useful for interpreting the results of the data. The pre-test and post-test have similar questions, and are designed to see whether or not the iMind system changed them in any way. The post-test also allows the participant to give us feedback on the system.

A screenshot of the post-test.

For each participant, we left them alone while they completed the demographics and pre-test section. This is because we did not want to influence them in any way. Once they completed it, they invited the researcher back in to help them get started with iMind.

The user was then told to go through iMind for as long as they wish, and that they can stop whenever they want. It was interesting seeing the way people went through the system and how they reacted. Some people were more expressive whereas others just sat there silently.

Aaron going through the system.

Afterwards, we left them alone while they did the post-test. The data that we compiled was pretty interesting because we saw that overall the participants felt a positive increase in their emotional state after going through the system. This is good because this is what we were aiming for. If on the other hand we didn't get that result, we would've had to rework the system to ensure that it made people feel good.

Another thing that I thought that was interesting was that for some people the blinking mechanic didn't work. This is because everyone's head is different, so the headset might not have been able to track them. For those that didn't have it working perfectly, they said that was the weakest part of the system. On the other hand, the people who had a good experience with it said it was their favourite part.

Mirza doing some initial testing and data collection.

Overall the feedback on the system was pretty good. I'm pretty excited to present it and to show it to the class.

INFR 4350 - Informal Game Testing

For my Demo Reel course I'm taking now, one of the assignments is called "Open Project" where every student can choose their own project to work on. The product of this assignment will be marked and can also be included in your demo reel.

Since I consider myself a game designer and programmer, I decided to make a simple mobile game for this assignment. I've had the idea for a long time, but I never got around to working on it. The game is tentatively called "Shoot to Ten" and it is based off of a Flash prototype I made back in second year.

I'm still very uncreative when it comes to names.

The version I'm working on now is being made in Unity and takes the core aspects of Carrot Cakes and expands on them. Essentially, you have this ball that you can shoot around by dragging it. There are also numbered tiles on the board that you have to activate in order from one to ten.

It's a very simple concept and I got the core mechanics of it working in about a week or so. My first iteration of the game had you aim the ball by rotating this arrow around the ball and then pressing a "charge" button to charge up your power bar. The more power you have, the further it shot.

I was (and still am) using a lot of temporary assets, so the play button was the charge button.

We had to show Derek our progress on our game and he gave me some feedback on the game. One of the things he told me I should do was to just drag the ball to shoot it instead of having to constantly adjust the direction arrow and press the charge button. I really liked that idea because I wasn't a big fan of the charge button.

So I reworked the mechanics of the game and made it so you dragged the ball instead. It worked out a lot better since it felt more natural and easier to control. It also allowed me to reduce the clutter on the board, which overall simplified the game.

Yea, I totally just took the existing level and tacked the arrow and button on it for the previous screenshot.

Then one day I was working on it in the lab and people were wondering what I was working on, so I showed them. Then it hit me that I had enough of the game done that they could actually do a quick and dirty playtest for me, so I got a few of my friends to play it.

The results were actually pretty surprising because people actually thought the game was pretty cool and fun. I'm not really sure why I thought it was surprising because that's obviously what I was aiming for, but it was nice to hear that the game actually worked even in such a primitive state.

I added particles for the most recent addition to give the player more feedback.

I got a lot of good feedback during the informal playtests that I had. For example, I had some pretty good ideas on what special tiles I could implement for the future. I also had some good feedback on the usability of the game. For example, one of the comments I kept hearing about was that I should make it so you can drag past certain things that you currently can't.

Overall, the ideas and feedback I've been getting from having external play my game has been pretty good. I've gotten a lot of good ideas on how to improve the game, and I've been working on getting a lot of it implemented. The game would definitely not be as fun if I didn't have anyone else to look at it.

My initial levels were also way too hard, which was really obvious to me once people started playing them.

I'm pretty psyched to keep working on this game actually. I'm going to definitely keep having people test this game throughout the development process to get more feedback.

INFR 4350 - Console Controllers

So last week we only had one lecture because the second lecture of the week got cancelled because of the weather. It's not often that class gets cancelled, so that was a thing. The only lecture we had though was about interfaces, and a portion of it was on physical interfaces.

In terms of video games, the most obvious physical interface are the controllers. Throughout my life, I've owned the Super Nintendo, Nintendo 64, PlayStation 2, Wii and the PlayStation 3. Each of these have pretty different controllers, so I would like to spend this week's post on my thoughts on these controllers.

Sorry, XBox. (Wikipedia)

The Super Nintendo holds a special place in my heart, because I spent a lot of my childhood playing with it. There were some pretty sweet games on it too, like Super Mario RPG, Final Fantasy VI and Chrono Trigger. The controller was fairly basic. It was a simple design that wasn't anything special.

I actually liked how it was so simple. I found that it fit nicely with my hands, even when I played it again a few years ago. It was also fairly intuitive in the sense that there was one D-Pad so you could figure out how to move really easily.

It is also made of special Nintendo plastic, so it absorbs drops like a boss. (Wikipedia)

The Nintendo 64 was the very first system I could call my own. The SNES was my sisters', so it technically wasn't mine. But I remember going to Costco with my mom to pick up the N64, that was a good day. The N64 controller is pretty unique in design. It was a trident shape, which I honestly didn't really like.

It was awkward to hold sometimes, especially since the joystick was right in the middle, meaning that you had to stretch your thumb out to reach it. Also, the joystick itself was hard plastic with some ridges in it, so if you played for a long time it made your thumb hurt. I don't think they thought that through well enough when they designed it.

Like, are you supposed to have your left hand on the left prong or the middle one? (Wikipedia)

My most recent Nintendo console is the Wii. The Wii is interesting because it uses a completely different type of controller. If you just used the controller, you could wave it around like a wand, or hold it horizontal like a rectangular controller. You could even connect a nunchuk to it and made it feel like a traditional controller that also allowed you to swing your arms around.

Of all of the Nintendo controllers I've owned, I actually like the Wii one the most (as long as there is a nunchuk attached to it!). This is because it was super flexible. It was literally the most flexible since with the nunchuk you can hold it almost any way you want, so your arms don't have always be locked in that position. Plus the motion sensing capabilities it had made it a unique device to work with in general.

I don't understand people who don't play with the nunchuk. (Wikipedia)

Moving onto the Sony consoles, we have the PlayStation 2. I really like my PS2 because it also had some awesome games like Final Fantasy X, Kingdom Hearts, and so on. The controller was pretty good too. I've always been a fan of the Dualshock controllers.

The PS2 controller is good in my opinion because it feels nice. It's very smooth and just feels good. One thing though is that there are a lot of buttons on it. If the game you're playing doesn't map out their controls well enough, then it can cause some issues with trying to position your hands properly.

It's also wired, which makes it hard for me to lie on my couch and play. (Wikipedia)

Finally, we get to the PlayStation 3, which the Dualshock 3. In my opinion, the PS3 controller is better than the PS2 controller in every way because it's a straight upgrade. Literally everything good about the PS2 one was kept, and they just made it better. It's now wireless, and you can turn on your PS3 with the PS button like a real remote.

The only thing I'm not sure about is that I find that my fingers hurt after playing for a long time. But, I'm not sure if that's because of the controller or because my fingers are already damaged. Chances are, probably because they are already damaged.

My favourite. (Wikipedia)

I haven't had a chance to spend a lot of time with the PS4 controller yet since I don't own one. But from playing with it briefly, it seems really nice. I really like how Sony goes for the more iterative design process. Taking what works and making it better. Nintendo on the other hand just seems to go for new things every time.

In conclusion, I'm not a big fan of the XBox controllers.

INFR 4350 - Diegetic Interface Elements

One of the things I learned about last week was diegetic interface elements. That essentially means that instead of using traditional interface elements that kinda float in front of the game world like HUDs, an in-world alternative is used instead.

These elements are interesting because they challenge developers to think outside the box and come up with novel ways to present information to the player. In addition, it helps build immersion and makes the world seem more realistic. Previously, I never tried to do anything like this.

I'm all about the HUD.

This weekend, I participated in GDSoc Jam II, the second game jam hosted by GDSoc at my school. This game jam was unique because there was a focus on virtual reality and immersive technology. Students could choose from a variety of peripherals and devices to build their games with.

One of the devices was the Oculus Rift. I've used it briefly before and thought it is a pretty cool device, so I wanted to work with it. For our game, we decided to keep it minimalistic and we thought that having a huge HUD would be distracting and disorienting to the player when using the Oculus, so we decided not to have a HUD.

Introducing BirdDock Mysteries, the game with a bird and a dock.

This ended up being somewhat challenging for us to develop gameplay around since we had no easy way to direct the player. We ended up deciding to make an exploration game that allowed the player to explore the game world the way they wanted. We still wanted a way to guide the player though, so we added a flying bird that flew around the level.

The bird is controlled by various triggers around the level. As the player reaches certain areas in the world, the bird flies off to a new location. There are no indicators that the player should follow, but we expect that natural curiosity will cause the player to end up heading towards the bird.

It eventually leads you to a special cave.

We also decided to forgo the traditional main menu games have. Instead, we decided to make the game title and credits diegetic as well. One of the first things the player sees when they start up the game is a billboard by the dock. This billboard has the name of our game on it, and on the other side the names of our team is scratched into it as well.

Overall, I learned a lot developing this game. It was a very different experience creating this game. Building a good interface is a key component to good HCI, so this was a cool learning opportunity for me too.

My preliminary prototype for the level and the expected path for the player.

Game jams are pretty fun. Hope to do more in the future.

INFR 4350 - Midterm Woes

So this week was the midterm for HCI. I tried to study during reading week but I got caught up in a bunch of stuff so I ended up not really studying too much for this exam. Regardless, I felt like I was ready anyways because a lot of the concepts were pretty straight forward.

There were a few things I weren't sure about though, those being the memorization type concepts. Now, I knew that it was completely possible that some of the lists and stuff would appear on the exam, but I made a decision not to try and memorize them. Reason being is because one of Nielson's heuristics was to "recognize and not recall" so I figured I was living the heuristic.

#YOINFR4350O (You only INFR 4350 once. Hopefully).

Naturally, it turns out that memorizing things would've been a good idea. Luckily, about two hours before the midterm I went to the lab to do some last minute studying and my friends we're going over some of the lists. I didn't study those so I didn't know them, but because of that I ended up memorizing a bunch of stuff.

One of the things we did was use acronyms to help us remember what they were. So one of them was FUNDUUE which stood for Functionality, Users, Non-Functionality, Data, Usability, User Experience and Environment. Another one was VFCMCA, or Visibility, Feedback, Constraints, Mapping, Consistency and Affordance.

FUNDUUE is practically fondue (Wikipedia).

So I had those memorized, but on the midterm it asked us what Norman's design principles were. So I was like: "who is this Norman guy" and just guessed by writing down the first acronym that popped up into my mind. That was FUNDUUE.

Obviously, the answered turned out to be VFCMCA. I think the reason why I thought of FUNDUUE first was because it sounded like fondue and that sounded awesome. Regardless, I found out afterwards that I got that entire question wrong and it made me sad.

Courtesy of Oliver.

But hey, now I know better. Anyways, this entire intro has led up to the bulk of this week's post. I'm going to go over Norman's design principles since I'm never going to forget this terrible mix up I had.

The first one, visibility, deals with making things stand out. If things stand out, then users will naturally notice them and be able to do what they we're meant to do. On the other hand, if things aren't visible, it will be hard for the user to determine what they were supposed to do.

For example, the "Next Level" button here isn't very visible. I should've highlighted it.

The second principle, feedback, deals with sending the user a response for every action they do. This is important because if the game doesn't react instantly to user input, it's possible that the user would have thought something went wrong. I find that this is especially true when things are loading, so a loading screen or indicator fixes this.

The next principle, constraints, deal with the restrictions the developer places on the user at the given moment. This could be as simple as confining the user into one location so that they must complete the current objective before moving on.

There might have been a more elegant way for me to do this.

Mapping is the next principle. That refers to the relationship between in game symbols and real world symbols. Essentially, things should be intuitive. Players should not have to think about what things are. Instead, they should know instantly because the developer used a standardized symbol that everyone knows.

The second C in the acronym is consistency, meaning that interfaces are consistent and should follow similar rules between different interfaces of the same game. Essentially, the user shouldn't have to relearn how to navigate through different interfaces. They should be able to do the exact same things but apply it in a different setting.

This game purposely break this principle to mess with the player (Impossible Quiz Wikia).

The final principle is affordance. When studying this, I kept thinking it was affordability, but that doesn't make sense since you don't need to buy this principle. Affordance deals with making things obvious for the player. For example, a button could be given a "button look" to make it look like it can be pressed.

Well, that's all of the design principles.