Physically Alternative

Dreaming Up Physical interactions for Email, Twitter and SuperMario

This was (and still is) one of the most challenging in class exercises so far. I spent most of the time in class staring at my page trying to figure out what was wrong with the current interactions and why they should be changed or how they could be changed in a way that might actually improve the experience. Needless to say there was not a great depth of interactions that ended up in my exercise book. So I am going to follow the instructions from start to finish and hopefully by breaking it down I can come up with five different interactions.

Email

Elements and Controls of Application

To get some inspiration I firstly pulled up Thunderbird and had a look at the interface to figure out exactly what I use (or dont use) it for.

My Boring Emails

The controls of the application itself were fairly simple. Mouse clicks and key presses with the occasional right click or drag being useful or required in some situations.

The elements and actions were more complex. There was the obvious, get message, send message, reply, forward, delete, archive, junk. But then there was also chat and address book functions which I did not really know about. Then there was also the tagging system the staring system the folder system.

Thinking about these I was able to come up with a few different interactions.

1. I noticed that my folders were all pretty useless and not very well maintained and I had a lot of old junk. The idea would be to have a small physical filing cabinet next to the PC set up which would have the draw open further and further for each email that was just sitting in the inbox without being filed.
2. The second idea came about from the inevitable spam that come through my emails. A simple digital click with a smiley face. The face would be happy when you had more non-junk mail and sad when you received a lot of junk or bills (no one likes bills) maybe even a shocked face for when an email from a new sender arrived.
3. Thinking about tagging, it always seems like more effort than its worth. Lots of clicking and sorting and clicking and sorting. This idea would have a projection of your inbox onto a tablet and allow you to use different colored highlighters to tag and sort your emails by coloring them.
4. I am not sure how well this idea would work and perhaps it is better suited to twitter but I will leave it here. The idea is having a old vintage scale with the two measuring cups, one would represent emails coming in the other emails coming out. The scale would adjust as you send and receive emails.
5. My last idea is similar to the first Idea and is the one I came up with in the lecture which was to have a small postbox setup where emails would be printed on post-it notes with the title and sender.

Twitter

Elements and Controls

While I am aware of twitter, how it works, and even have an account. I would not say that I have any real understanding of the twitter space and what it is all about. But just looking at the landing page I can see I can tweet, retweet, follow, tag, and favorite.

1. The first thing I thought of was a collection of Hashtag stamps which could be stamped onto a tablet or screen to add the hashtag.
2. The other idea I had was some sort of token or avatar which you could place onto something or someone to start following them on twitter. Kind of like a QRCode  type thing but creepier.
3. A retweet bird call whistle which would retweet the tweet you were currently looking at.
4. A set of clouds showing the top trending topics, tapping one of the clouds would read the tweet out to you.
5. Tag budget charm. For people who use excessive hashtags. At the start of the day you can allocate an amount of tags you can use. Every time you tag your number of available tags counts down on your charm until you can no longer hashtag.

SuperMario Brothers

Elements and Controls

The classic platforming game. Left,right,up,down, A, B. 

1. First idea is a power glove type system which becomes activated when you get the FireFlower power up. You must then make a certain action to shoot fireballs. 
2. Next idea is a classic Mario pipe (the ones you can go down) as the controller. The pipe can spin left or right to more in the direction and you can press it down to jump.
3. A miniature flag pole is placed beside your computer. At the end of every level you need to raise the physical flag before you can jump to the flag in the game and complete the level.
4. In keeping with the literal adaptations. A controller which is a plunger (because hes a plumber of course). Plunger works like a normal joystick but you can plunge it to make him jump.
5. AR projection of the game where you use your hands to control directions and flick up to make Mario jump.

Exercise Reflection

I feel like the challenge with this exercise was thinking outside of the box. Perhaps I am just too familiar with keyboard and mouse and they are my preferred control system. But I really struggled to come up with ideas that felt interesting and were not just representing the game or an aspect of the concept in a different way. While I think there are always interesting ways to represent data, I had not considered as much changing the way I interacted with applications I use regularly.

Testing the Testing

In this weeks lecture we looked at how to create effective testing sessions and ensure that we ask effective questions which will provide useful feedback. By evaluating our previous user testing questions from our video prototype.

From the initial look at my questions, I do not think I feel into any of the major traps (although some questions could be a little more specific) but there are still some areas for improvement. Some questions could have been reworded while others were qualitative where being quantitative may have been a better option. Each question is explored in detail below.

Q1: The Game inspirations were easily identifiable

Likert Scale from Strongly Disagree to Strongly Agree. This question was qualitative in nature looking to see if users remembered the two games mentioned in the video. This could have been re-phrased and been done with checkboxes instead to make this into a more quantitative measure. Showing that users got the 2 inspirations would have been more valuable than their perception of how hard it was to identify them. Even if they agreed they were easy to identify this question does not capture if they identified them correctly.

Q2: The purpose of the game was difficult to understand

Likert Scale from Strongly Disagree to Strongly Agree. While this question is also qualitative it may have been more effective as a quantitative measure. Also purpose could have been rephrased as goal, as some users may not see a purpose to games, where as the goal or objective of the game may have been more applicable. 

Q3: The game controls were clearly explained

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. The control system contains multiple elements it may have been better to separate this question into smaller parts (I guess maybe somewhat compound) 

Q4: The controls provide an interesting method of interaction

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. Need to rephrase interesting if looking to specifically test for uniqueness of interaction. Different users may find different systems interesting.

Q5: How would you improve this game?

Open Text answer field question, capturing qualitative information. While the question could be a little bit more specific, from looking at the feedback it is clear that this questions needed a better outline on how to answer it.

Q6: The Video footage was poorly produced

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. Could be a littlle bit more specific, or alternatively follow up with a open text question if they disagreed.

Q7: The Video sound was clear and understandable

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. COMPOUND, need to be over two different questions.

Q8: How would you improve this Video Prototype?

Open Text answer field question, capturing qualitative information. Again more indication could have been given on how the questions was to be answered. E.g write a short sentence indicating how would you improve....

Q9: The Testing method was well explained

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. What the testing method was could have been better explained in this question. So that users better understood which aspect was being critiqued.

Q10: The Survey was too short

Likert Scale from Strongly Disagree to Strongly Agree. Another qualitative question. Could have been quantitative with a simple yes or no answer.

More Code Planning and RESULTS

I had another more in depth look at the CRC card concept after the lecture and followed the process a little more thoroughly for the classes that will be specifically important to completion of prototype 1.

CRC part 2

I found that by using the Class HAS format made it a slightly easier way for me to understand what was happening and which parts were static and which were dynamic. This also lead me to see that by physically looking at the lock it did not have any points on it. The points were on the dial and so I Needed another class for that.

CRC part 2

Again looking more in depth I figured I would need some sort of reset functionality which would reset both the dial and the lock (set progress to 0/n). This could take the form of a button which would need its own class to display on the stage. This is something I will need to flesh out more. The sound class was fairly simple as sound contains the sound bytes as well as an x y position.

CRC part 2

Breaking down what each of the class objects CAN do. Again I found this a really good way to conceptually get my head around what I wanted each thing to do and the practical limitations I might hit when trying to code. After playing with my combination lock for a few minutes it dawned on me that the lock cannot spin and that the dial (lock face) was a separate entity that spun.

CRC part 2

CRC part 2

These last two extensions of the CRC cards I found very helpful overall is solidifying my approach to my code. Logically thinking through which elements of the game need to TALK TO each other and what information they need (or listen for) helped to make sure they were correctly compartmentalized and that I had an actual understanding of what they needed to be doing to work together in the prototype.

Getting Flashy

Armed with this new found understanding and (over) confidence I dove into ActionScript and started to rustle together some code. At the end of the week I ended up with a very simple implementation of the lock and its first two attributes (along with comments for days). State and Password.

I manged to complete the implementation of a three key password for the lock system which would generate a random combination each time ;the script was run with each password ensuring combinations numbers were between 0 and 30 while maintaining a left right switch and a decent (yet random) spread.

Overall I am feeling pretty good for my progress thus far which I have made in only a single workshop session. With a full week before the prototype submission I am hoping that the rest of the code will be just a smooth to implement now that all the planning has been done.

Class Responsibility and Collaboration Cards

This weeks lecture was looking more at action script and helped to reinforce some programming concepts of ActionScript. I am glad that I have already done Python coding and JavaScript in the previous semester as this ActionScript work is helping to cement areas that I am already familiar with.

Its also nice that I did not work a lot in JQuery last semester as the ActionScript syntax is very similar to vanilla JavaScript, so I have yet to find myself struggling as I did when trying to learn Python and JavaScript simultaneously.

The main take away from this weeks lecture was the concept of  CRC cards to planning out our prototypes classes. Breaking down the individual elements of the prototype into what values they contain, what actions they take, and what other classes they need to interact with. This process has made me think a lot more about the design of my code and what parts can be recycled and what parts I can get away with hard coding.


From my initial time is the lecture I came up with the following classes:

In lecture Card

PLAYER:

Attributes

• y Position (Will only be moving left and right)
• x Position
• Inventory (To hold Treasure)
• This was something that I initially had overlooked. In my head you just get the treasure but I had not considered where it would be stored until doing this exercise

Abilities

• Move right (Considering a system where player cannot move back but will need to test)
• Add Item (Or take treasure)

Collaborators

• Screen (To know where to be)
• Lock (If locked cannot move past dumpster)
• Treasure (To pick it up ^.^)
• Dumpster? (Will it be enough to know about the lock and the treasure?)

In lecture card

LOCK:

Attributes

• Password (Numbers in an array)
• State (Locked or Unlocked)
• x Position
• y Position 
• Indicator (Some way of knowing which value on the dial is active)

Abilities

• Unlock
• Originally had spin left and right but have subsequently moved this to a new class called dial after further looking at the class cards.

Collaborators

• Dumpster
• Combo Panel (Help Panel?)
• Sound
• Stage
• Dial

In lecture Card

DUMPSTER:

Attributes

• Lock
• Contents
• x Position
• y Position

Abilities

• Open
• Empty? (Seems like a duplicate if player has take item)

Collaborators

• Player
• Lock
• Treasure

In Lecture Card

COMBINATION PANEL

The combination panel came about from the exercise as an idea of how to help communicate to the player what actions they needed to take to unlock a lock.

Attributes

• Lock Progress (How many off the password numbers have been hit)
• x Position
• y Position
• Turn Indicator (Which way to turn the lock next)

Abilities

• Display direction (Which way to turn)
• Display Number (eg 1/4 numbers hit)

Collaborators

• Lock
• Sound

In Class Card

SCORE

Another aspect of the game which I had previously not considered, how does the user know how much more money they need to collect or what their goal is.

Attributes

• Target (Money to be earned)
• Current
• Progress (Current % of target)
• x Position
• y Position

Abilities

• Update (Refresh score when loot is collected)

Collaborators

• Treasure (Maybe?)
• Player

In Class Card

SOUND

Attributes

• Volume
• Playstate (Playing, paused, off)
• Sound (The sound clip itself)

Abilities

• Play Sound

Collaborators

• Lock
• Combo Panel

In Class Card

TREASURE

Attributes

• Value
• Image

Abilities

• Obtain (Probably another duplication with players take item)
• Display (potentially some sort of animation also)

Collaborators

• Dumpster

Implied in most of these cards in the fact that they will need to collaborate with the stage and have both and X and Y position on the stage to display. I did some more refined work on the cards but it will have to wait for another post.

Video Feedback

OUTCOMES

Going into the testing session I set up my laptop with my video ready to play and google form open ready to receive feedback. I firstly explained to users that I was looking for feedback on both the concept and the controller system before prompting them to view the video. I advised testers that they could pause rewind and scrub through the video as they needed and ask questions for clarification.

Of the 6 users that observed my game there was only one that watched the video multiple times and asked questions for clarification. The majority of testers going straight through the video on the first run with no pause or rewind needed.

Aside from my personal observations there was also a survey which testers were asked to fill out after watching the video. The results from this survey are presented below. Please note when the bar is not visible it is because a score of 1 was received for the question.



The results are mostly positive with almost all users agreeing that they could easily understand the grounding of the concept. Likewise the majority understood the premise and purpose of the game, however there were two who agreed that the purpose was difficult to understand.



The results for question three and four are some of the most encouraging, with the majority of users strongly agreeing that the controls were not only understood from the video explanation but that the control method was actually interesting.



Questions five and six related to the actual quality of the prototype and the video production. Again the majority of scores are high (or low where question statement is reversed) suggesting that the prototype was of acceptable quality and was able to effectively communicate without serving as a distraction.



The final questions related to the testing process itself and the transparency of the method described in the statement of delivery. The results suggest that this is the area where most improvement could be made. Improving explanation to testers what exactly they should be testing will be imperative to retrieving relevant and useful feedback.

While there was a wide range of questions on the survey the purpose of the prototype was to communicate the concept and so feedback was sought specifically around this area. As well as on the appropriateness of the control system.

REFLECTION

I feel that the video format made for an effective media to communicate my concept to others. Again in hindsight I think that my video was about 30 seconds too long at 2 minutes. The rest of the video I am happy with, the voice over added to the theme of the video without being distracting. There was no feedback from testers that indicated it negatively affected their understanding of the concept. Also from the feedback it seems that the paper animations were appropriate and overall well received.

Overall I think the video prototype was a very useful step to take in the design process. Video was a good way to communicate across both visual and audio channels. The experiences of making this video has been helpful as I can see the importance of using simple audio and visuals to get the message across. You cannot just prattle on and on or the user will lose interest.

Finally I think that adhering to my testing protocol was the area that I need to most improve in. Making sure that I faithfully follow the process each time so that each user has the same experience will increase the overall effectiveness of my testing protocols. Hopefully this will result in more constructive feedback in future prototypes.

EFFECTIVENESS

For the purpose it was designed (to communicate my concept) the video was successful. The results showed that most users left with a good understanding of both the concept and the control system. However a recurring theme from the written feedback was that the elements of Operation were not clearly defined. This is due to the concept drawing more heavily on Street Fighter and not explicitly taking any gameplay from Operation (Only the tactile input system and idea of fine motor control). While I dont see this as a failure of my initial prototype it may be something to incorporate additional gameplay aspects in later prototypes of the game as it becomes more sophisticated.

Most of the feedback was around possible expansions to the game and deeper explanation of the current systems. After viewing other peoples videos, it can see that my method of describing the gameplay relied too heavily on audio, without enough visual support. However, as part of the interface prototype I will look to expand and show how the gameplay will look and feel.

CONSTRAINTS

Aside from my own skills in creating video content, there were a few constraints which impacted upon the video results. The limitation on how much video had to be actually filmed lead me to use the paper animation style. Additionally constraints in the testing environment meant that I was not able to gather as much feedback as I would have liked.

IMPLICATIONS

From the feedback received am I confident that my core concept is solid and can be used to create further prototypes. However, I will be conscious of the need to explain gameplay elements clearly and explain systems more clearly in further prototypes.

For future testing sessions I will ensure that I print a printed script for myself to follow to ensure that I am sticking to the testing protocol. Also I will consider shortening the length of the survey and changing the phrasing of the questions to ensure the testers are not getting confused or bored with the feedback system.