The actual last post

Testing Session Observations and Qualitative Feedback

Looking at the users answers to survey question 5: Please finish this sentence, I accidentally turned the dial the wrong way when...

It is clear that users are running into this problem when the first begin opening a lock rather than when they have to change directions during the unlocking process. One user also remarked that most traditional locks will turn clockwise first where as the digital prototype turns anti-clockwise to begin. Again this could be another area for improvement in the future when experimenting with different control schemes.

Feedback from survey question again suffered from the ambiguity of 'visual feedback' without specifying either the turn indicator or the password progress system. Regardless users thoughts on the entirety of the right panel were largely encouraging. Indicating that the confirmation of password points was essential and am important supplement to the audio system. Users also pointed out that the arrow was not helpful initially as they were unaware it responded to the arrow key they needed to press. Suggestions for a call to action or tutorial system were again made and this will look to be implemented in future prototypes.

Observations

Based on my observations of the testers, on average most users opened two locks. One when they were completing their assigned task of testing the reset function and once afterwards when they had time to play before moving on. After the open of the initial lock using the reset method, most users were able to open the second lock in under 30 seconds.

It was also clear from observations that as users became more comfortable with the control system they moved from a simple tap system of pushing the key in once to the holding method to make the lock dial rotate more quickly. One user even discovered that she could open a lock simply by spinning in one direction to the correct number, resetting, hitting that point and then changing direction. Using this method they were able to open locks very easily and quickly, however, this was unintentional and may need to changed slightly to ensure users are skill relying on precision rather than brute force to open locks.

Finally most users interacted with the reset button six times or more as they ran through the initial task and the opening of additional locks. It seems clear from this testing session that the stability changes made to the code were successful and both the reset and new lock buttons are functioning correctly.

Its the Final Countdown

Quantitative Testing Session Results

Another testing session bites the dust and its time to look at the results of the latest iteration. In this post I will look at the survey results and how the relate to the goals for this prototype and breakdown the responses from my five victims. This will be looked at the quantitative data recorded with a separate entry for session observations and quantitative results.

Of the testers 4/5 had prior experience with the Street Survivor prototypes which was important for testing the effectiveness of the visual feedback relative to the physical method used in prototype two. Of the four that had previous experience 75% said that they found that the locks were easier to open with this prototype.

Interesting though a significant number of users still had trouble rotating the dial in the correct direction, despite the visual feedback.

Results for Question 3.

This trouble was also reflected in question four with most two users reporting they had repeated troubles. Rotating the dial in the wrong direction more than five times.

Results for Question 4

This is an interesting development as again it seems that users are focusing their attention entirely on rotating the lock rather than the supplementary information provided. Even a result of 3-4 times could be considered a failure for smooth operation of the controls. From this result further refinements would be to invert the control scheme or alternatively rebuilt a high quality physical system.

Despite their troubles users still reported that the visual aids were helpful to their playing of the game.

Results for Question 8

Again this seems counter intuitive, but in hindsight an important design flaw may be behind this result. Both the password progress system and the visual indicator were classified as 'visual feedback' systems in both the survey and testing session wording. These will need to be separated in future testing sessions and potentially even having the code modified to include only one of the features.

Results for Question 7

The results from question seven make it clear that the password progress box was helpful in improving users experience and may have been the primary reason for users finding the locks less difficult to unlock. Overall the difficulty seems to have stabilized to an adequate level where it is sufficiently challenging as the results from question six suggest.

Results for Question 6

From these results it seems clear that the added features have not lead to an improvement in users ability to rotate the dial in the correct direction. Further work will need to be done in this space to ensure that future builds are more usable. It also shows that the locks are easier to open and potentially reduces the reward felt by users when opening a lock.

Interactive Prototype 3 Facilitator Script

Welcome to this testing session and thank you for participating and providing us with your feedback today. I will be here to observe the testing and will be taking notes but feel free to ask me at any time for clarifications if you have any questions.

I just want to run you quickly through the testing process today firstly. We are testing the Visual Feedback elements of the Street Survivor game.

• So the Direction indicator and the Password progress display

For this testing session there will be three phases. We are currently in the first phase, now then there will be some tasks with the digital prototype and finally a survey at the end.

Before we start phase two so that you can familiarize yourself with the way a combination lock is supported to work and how to open one I have brought one along a for you.

When you are ready we will move into Phase 2 and get started with the digital prototype. Where we have a few tasks for you to complete.

1.  Spin the digital lock dial to the first password point, once the visual feedback presents. Reset the lock.
2.  Spin the digital lock dial to the first password point through to the second point. Again once feedback presents. Reset the lock.
3. Attempt to open the lock by moving through all three password points.
4. Generate a new lock and follow steps 1-3.
5. Users are given 3 minutes to open as many locks as possible.

- Following this will be a short survey for you to fill out privately and the observation of the session will cease.

INSTRUCTIONS FOR PHYSICAL LOCK

- Click this around a few times until you are familiar with the feel of it.

INSTURCTIONS FOR DIGITAL LOCK

- If at any point you make a full rotation of the lock without hearing any audio feedback or seeing any visual feedback, please reset the system and advise myself as a bug has occurred.

- The reset button will reset your progress on the current lock password. While the new lock button will generate a new lock with a new password.

Observations:

      Number of digital locks opened.
Time spent per digital lock.
Number of times controller turned in the wrong direction, when starting a lock.
User control patterns (slow click or fast spin)
Number of times reset lock button is pressed.

Survey Time Sadness

Survey Results

Despite what the title suggest this is not another doom and gloom post ^.^

Responses from the survey data were largely positive. With encouraging feedback about the concept and the viability of the physical lock mechanic. With one user stating that "I still like the idea, and the game mechanics is fine". This adds to the continued belief that the core concept is strong and the resulting game mash-up is both interesting and fun. Test suitability of a physical lock style controller was one goals of the session.

Responses to survey question three also revealed important information about the difficulty of understanding the controller interaction. With the majority of testers having a clear understanding of how the lock should function in the game context.

Q3 Result

However, the results from question four were largely unexpected given the technical issues faced during the prototyping session.

0 Representing unsure 5 Representing Completely Sure.

I feel like this result was heavily influenced by way users focused their attention on the screen rather than the physical controller. This was observed during the testing sessions and the survey responses to question 5 corroborate the evidence.

From these findings it is clear that the physical lock does not need to accurately represent the lock on the screen. There is no need for the physical lock to have the same number of points it just needs to ensure it has the same feedback. 

Q5 Results

Also encouraging was the result from question 6 which showed that the prototype provided acceptable levels of tactile feedback. Testing the feedback of the controller was one of the major goals of the testing session.

Where 1 is completely dissimilar and 5 is completely similar

However the biggest finding coming out of the session was that the actual controller was physically difficult to rotate. My obsession with making something that was sturdy backfired as the lock would only rotate with a significant amount of force. This may have been due to the fact people thought they would break the prototype but it is something that will be looked into for the next iteration.

Other tester frustrations and pain points included:

• Changing directions
• Lack of sensitivity
• Points missed
• Points skipped 
• Level of audio feedback (Too quiet)

TLDR Testing Session Goals and Outcomes Recap:

Testing Goal: Is a physical combination lock style controller suitable for the game?
Outcome: Yes, though the prototype needs to be refined

Testing Goal: Does the prototype provide an intuitive control system?
Outcome: Yes, the control scheme is easily understandable

Testing Goal: Does the physical controller dial accurately represent the digital lock dial?
Testing Goal:  By how many points to the two dials differ?
Outcome: Unimportant, users spend majority of time looking at screen to show lock position.

Testing Goal: Does the physical lock provide enough tactile feedback when moving from point to point?
Testing Goal: Does the physical lock accurately represent a real lock?
Outcome: Yes and yes. If anything it provides too much feedback and requires too much force to use.

Testing Goal:  Does the physical lock make the game more or less difficult?
Outcome: Unclear, at this stage the current prototype is more difficult due to the force required to rotate. But the actual control system could be harder or easier than keyboard.

Testing Goal: Can the prototype complete a testing session without repair?
Outcome: Definitely not in its current state.

Testing Goal:  How many locks can the prototype open without issue?
Outcome: Zero

Lock Life - Testing Session

The day of the testing session started with great promise. A bright sunny day, a pleasant bus ride. Simple set up. No strange looks from others.

Babys first bus ride

Then it was time to get serious and get into the testing. From the outset it became obvious that there was not going to be a lock successfully opened. Running a testing session and observing the users soon turned into holding parts of the prototype together, explaining bugs, and making running repairs in an attempt to reach the mythical five tester mark. Which I managed to achieve with video evidence to prove it!

User Test 1.

User Test 2.

User Test 3.

User Test 4.

User Test 5.

Despite the issues with the prototype, I received and observed positive feedback on the prototype when it WAS working. When the wheel was turning correctly there was definite feedback, the on screen lock was turning as intended. The major sticking point throughout the testing session was changing of directions, when the lock needed to move from anti-clockwise rotation to clockwise rotation.

Upon inspection it was found that the pointer was continually getting stuck on nails and just sticking into them rather than sliding past them when a change of direction was made. This problem meant that my observations were largely pointless as a grand total of 0 locks were opened with all participants taking the full five minutes (or until they got frustrated) to attempt a single lock.

Additionally the dial face on the controller came loose in one of the user session which meant that it was not accurately representing the points underneath it. And the lock got stuck on a point so many times I lost count.

Hopefully its not so doom and gloom when we hit the survey results.

PS: Shout out to all my testers ^.^ thank you so much for your feedback and perseverance.

Time for HardHats

After my initials constructions I was sufficiently satisfied that my current design and set up would work at full scale. So it was time to get out the saw, and cut some MDF.

Thanks Saw Horses

Having some Density issues, with the large nails

Cant go back now.

Good Thing it fits

The base to mount the wheel onto

After spending the best part of the morning with a saw in one hand and a hammer in the other it was time for the moment of truth. Fastening the lazy Susan hardware, I only bought one of these so it was the point of no return from here on.

We have life!

IT FITS!

Time to test

With the wheel on and correctly rotating, I thought the hard part was behind me. Little did I realize that I needed a way to fix the pointer to the base, which would still allow it to rotate so it would pass through each point. BUT, not have it rotate too far that it might miss some of the points or fail changing direction.

The Twin Foam Duct-tape house

Nails with foam reinforcement

The initial set up with foam would work for a small period of time, providing enough force to keep the pointer hard up against the wheel to make sure it would contact all the points. This problem was exemplified by the fact some points were alot further in due to nails on all sorts of angles. The final solution was to have two nails either side of the pointer (As they were stronger and would hold it in place longer) to ensure contact with every point.

Finally it was time to box it up and make it look pretty (thorough testing would have to wait. Many fingers were crossed)

Cozy Foam Home

Always good to have a spare Beer Carton

Before the Facelift

Paint Shed

Final Test

So there it is, a little black box of hopes and dreams. Ready for its time to shine at the testing session.

MidSemester Break(ing) My Prototype

MidSemester break provided a great opportunity to actually go outside and hunt around for materials that would be more suitable to create my prototype out of. After multiple trips to Bunnings and an emergency visit to Big W for a compass set (like high-school all over again) I was ready to get into construction.

Have to make sure you get enough nails. The lazy Susan assembly was the essential part

MDF and Foamcore. Test with one build with the other.

The break also gave me some time to research how I would build it, rather than just blindly rushing into it. I had a quick (in hindsight probably too quick) look at WikiHow and U-Createcrafts tutorials for creating prize spinners. Which heavily inspired my final design.

Then It was time to get building, then testing. Then building a little bit more, then testing a lot more. Then back to building... you get the idea.

Make sure your earthed!

A Quick Test. Would the nails wired together both be earthed?

Testing the MakeyMakey inputs for left and right.

With the first tests completed, I had established that nails would work, I would just need to wire them together, but once this was done the whole wheel could be used as the earth. Meaning that the user would not have to hold onto anything else to make the prototype work. Now it was time to include some more points on the circle.

Initial fail attempt. Which resulted in Compass purchase.

Woah Were Half Way There!

Better check it again to make sure it works at a larger scale.

This is where one of the first lessons came up, and one of the major problems which continued to plague the design process. Needing to ensure that the points on the wheel were not only evenly spaced but the correct with from the center. Working by hand this proved to be difficult as nails dont always do what you want them to when a hammer is viciously applied to them.

I then had a quick experiment with different types of pointers which would make contact with the wheel. Whether to put them internally or externally. How they would be controlled?

Large Central dial

CHAOS

Quick test of having multiple pointers

In the end because of the difficulties in ensuring a consistent distance of nails, I decided it would be easier to have the pointer on the outside of the wheel and have it work more like a wheel of fortune style wheel.

End of Construction Day 1.

If you build it they will come

So after getting used to the Makey Makey system and playing around a little bit with some initial ideas. I got further into paper prototyping in the hope of building something more to scale that would work.

Paper Prototyping

After some more work with paper I felt that my basic concept of the lock was going to work with the Makey Makey system. However, the issue that I kept hitting upon was the contact points and ensuring that they were triggering accurately.

Paper Prototyping

I had build a larger scale system with two points so that I could move my dial through the two gates and see what response would come from the digital prototype. Despite changing my code to listen for KEY_UP inputs rather than KEY_DOWN inputs I was still having issues with accuracy.

Paper Limits

While the Key down looks to see what the keyboard button is lifted before executing the block of code the issue that I kept running into was that the paper and materials I had been using were too flexible. They were not strong or rigid enough to ensure a smooth contact and disconnect. Rather they were making and breaking contact multiple times when moving through a gate. Resulting in the digital lock moving a minimum of two to three points when it should only have moved one.

Take two

Fast Forward a few days and it was time to try something more durable. I Found some wooden kebab skewers laying around at home and quickly took to hacking them up to try and create some kind of frame which would be able to hold my lock points. Unfortunately the construction process was longer than anticipated and with a presentation for another subject looming this was the limit of my progress for last week.

Now its time to enjoy the week off and really get stuck into construction phase.

Redesigning the Restaurant Experience

Experience Prototyping

This week we looked at experience prototyping. Which is essentially taking your prototype into its context of use and allow users to test it. It makes a great deal of sense and it is a nice way of bringing the design process loop back around. Start by placing yourself as a designer in the users context to empathize with them. Ideate and prototype (locking yourself in a tower optional) and then place your design artifact back into the context of your users. Failing this try as much as possible to simulate the context so that testers can have the same experience with your prototype as they would in the real world.

I peeked briefly at the IDEO paper about experience prototyping. Their definition of experience puts into perspective the sheer difficulty of designing a successful product, its not just about how the artifact works and how users interact with it, but a whole raft of dynamic elements which make up the experience.

Armed with this knowledge its time to jump into this weeks lecture exercise which was to look at the experience of a restaurant and come up with ways in which it could be improved with technology.

Exercise

Q1: What is the existing experience from different stakeholder POVs?

I am going to try and keep it brief because I feel like just this question could take a whole blog post. When you consider all the different types of restaurants, some have street dining which would make the general public a stakeholder (especially if there is smoking) and the restaurant managers and owners are another major stakeholder. For the sake of this post I will look at the three major players we defined in the lecture:

1. Customers (Diners)
2. Wait Staff
3. Chefs (Cook Staff)

In terms of the customer the service or experience they get from a restaurant is a transaction in which they are provided food and drinks for a price. Wait staff and waiters are the middle man between the customer and the chefs, they take the order information from the customer and provide it to the chefs. Chefs deal with the preparation of meals and the cleaning of the kitchens.  

Q2: What external/internal factors impact on the experience?

Customer External

• Seating (Chairs, Stools, Standing, Booth Indoor, Outdoor)
• Environment (Temperature, weather, noise, other customers, time of day)
• Wait Staff (Attitude, attentiveness, service)

Customer Internal

• Appetite (Everything tastes better when your hungry)
• State of Rush or Relaxation
• Familiarity with restaurant (The place I always go because I know it is always good affects my perception)
• Level of Intoxication

Wait Staff External

• Management
• Other Waiters
• Customers
• Chefs
• Time of day

Wait Staff Internal

• Attitude 
• Enthusiasm for their job
• Stress level
• Level of competency (trainee or experienced)

Chef External

• Flow of customers
• Other Chefs
• Suppliers (for ingredients) 
• Kitchen layout
• Kitchen tools

Chef Internal

• Skills (Cooking abilities / specialties)
• Motivation
• Workload (stress level)

Q3: What aspects of the existing experience could be enhanced / augmented / supported with technology?

Almost every aspect of the experience could be redesigned. While it may be easier to focus on the external elements to augment to improve the experience it is more important to recognize the relationship between external factors and users internal states. While we may assume that customers hate to stand up and always want to be seated, this may destroy customers perception of the environment and have a negative impact on their experience. It is this subtle difference that may differentiate one bar from another or one bar from a lounge. 

Customer Experience

Transitions glass placed in the restaurant to minimize glare when sitting near windows and prevent sunburn when sitting for prolonged periods.

Wait Staff Experience

Coloured lights on customer tables which change colour depending on the waiter you are being served by, so that staff can keep track of the patrons they are serving. 

Chef Experience

Set up a social media account for each table in the restaurant then provide a live stream of the posts from customers for the chefs to see, so they can get immediate feedback.

Q4: How would introducing technology in to this context change the experience?

Customer Experience
If this change was implemented it could have huge impacts of the overall aesthetics of the restaurant itself. There might need to be extra lights added to ensure that the space was still adequately lit.

Wait Staff Experience
If this change was implemented it may make wait staff less attentive to other tables not of their own colour. While giving waiters direct ownership of a subset of customers may improve their service to those customers it could decrease their attentiveness to other customers and lead to an overall drop in service level.

Chef Experience
If this change was implemented it would change the dining experience for the customers as they might feed obligate to leave a review, or be influenced by the decisions of people who ate at the table prior to them.

What experience scenarios might you test with the technology?

Customer Experience

You might provide customers with sunglasses to wear while they are dining at a restaurant and have them interact as they normally would. You could observe the effects as well as interview them afterwards to find out how it affected their experience.

Wait Staff Experience

You could test this type of system with a low fidelity post it style process where waiters would leave their coloured post it on tables which they were serving. This could be a good way to test what position to place the lights and if wait staff behaviors differed between tables they 'owned' and did not own.

Chef Experience

This scenario experience could be simulated by having a small phone / tablet / screen set up in the kitchen with a chefs social media account up. Then people running the testing session could ask users to photograph or comment on their food and send it to the account.

Time to Evaluate

Final Survey Questions

The qualitative feedback section of my Survey contained only two questions:

• Finish this sentence. After opening the prototype lock i felt...
• Please write a short sentence describing your experience rotating the dial

I got much better feedback from these questions than I did on my original survey. I think by providing clearer instructions of what I type of feedback I was hoping to achieve I ended up with a much better result.

Question 1 Results

Responses for the first question were largely as I had hoped, evoking nostalgia, satisfaction and a sense of achievement and even vindication in users. This sense of accomplishment was exactly what I was setting out to achieve when designing the lock and what I was trying to capture with this question (its nice when things work out).

Answers to this question also brought up some further points for improvement, suggesting a change in unlocking sound to create a more outlaw style theme and to ensure the audio feedback would play as the person moved to the key point. Not as they landed on it, to avoid them from passing over it too many times and having to restart. 

Also confirmed my initial thoughts that the lock controls were a little awkward and raised an important point about the reliance on audio. If this channel is unavailable or if there is significant background noise the game in its current state would be unplayable.

Question 2 Results

This is where most of testers vented their frustration while some testers remarked that the controls were smooth and that the game was fun, there was a lot feedback on how to improve the system. Again the main take away was that the audio clicks needed to play sooner to ensure users would not overshoot the lock points and subsequently have to restart.

Observation Results

Tester 1: Observations

• Tester starts with Physical lock 9:10am
• Unlocked in 1min 30secs
• User only took one attempt before moving onto digital lock
• Tester starts with Digital Lock 9:14am
• 4 Locks completed in the 5min time frame
• 1st lock took the longest to complete
• Subsequent locks were opened in around 30seconds
• "Damn it went past it again"
• More support for changing the audio timings
• User was very engaged with the prototype, there were signs of concentration
• User used the spin method on the first lock
• subsequent locks used the tap method

Tester 2: Observations

• Tester starts with Physical lock 9:27am
• Unlocked in 1min with no real issues
• Checked password between moves
• Again only one attempt before moving onto digital
• Tester starts with Digital lock 9:30am
• 8 Locks completed in the 5min time frame
• 1st lock too the longest
• 5th and 6th lock only 15 seconds for completion
• 7th and 8th took beetween 20-30 seconds
• Clear pattern of learning after the first two locks, from locks 3-6 seemed everything really clicked for the tester. (excuse the pun)
• Used tap method throughout the test

Tester 3: Observations

• Tester starts with Physical lock 9:41am
• Unlocked in 1min 20secs
• One attempt before moving onto digital lock
• Tester starts with Digital lock 9:43am
• 3 locks completed in 4mins
• 1st lock took 30seconds
• 2nd lock took 45seconds
• Used tap method

Tester 4: Observations

• Tester starts wtih Physical lock 9:49am
• Reading through password before attempting to fix the lock
• One attempt before moving onto digital lock
• Tester starts with Digital lock 9:51am
• 3 locks completed in 5min time frame
• Some technical issues 2nd lock only took 30seconds
• Used the tap method
• experimented with spin on the first lock

Tester 5: Observations

• Tester starts with Physical lock 10:54am
• Was unable to unlock and opted to move to digital version
• Tester starts with Digital lock 10:56am
• 5 locks unlocked in 5min time frame
• User had issues with directions and keyboard mapping
• Settled on the tap method of controlling
• used the spin method for the first lock

Tester 6: Observations

• Tester starts with Digital lock 11:17am
• 2 locks completed in the 5min time frame
• Lots of moaning and groaning
• User was explaining that they kept just missing the point or just going too far
• Used a combination of spin and tap methods

Evaluations

Based on the observations and survey results I am very happy with the difficulty level of my prototype. While it was reviewed and was observed to be quite difficult while learning the sense of achievement that was reported was what I was hoping for with this game concept. I will be keeping the combination lock system as it gives a real safe cracking theme and the current code promotes precision. 

From the observation and the feedback it is also clear that the lock code needs to be further tested to ensure that it is stable and working after resets. But also that the sound clips need to be moved to ensure that they play while moving to the point rather than once the correct point has actually been selected.

Overall I feel like this was a much more successful testing session and am looking forward to implementing these changes into the design while also building a physical controller.

IP1 Evaluation: Did I get what I wanted?

What did I want?

From my statement of delivery I was hoping to achieve several goals and answer multiple questions about my concept with this prototype iteration. The big thing I was hoping to find out was how users would interact with the prototype lock and whether they would spin the dial or rotate it slowly point by point. Additionally I wanted to explore:

• Difficulty of the locks
• Feedback and if audio was sufficient by itself to support the interaction
• Difficulty Vs Reward and users feelings after opening the lock

How I go what I wanted?

I used an online survey to capture testers feedback immediately after their experience with the prototype. I also made a conscious effort to move away from testers while they undertook the survey, I learnt from the previous session (as both a tester and testee) that survey responses will be biased if they are observed. So I endeavored to make the survey experience as anonymous as possible given the classroom context.

I also observed each tester who participated and took notes in about the following aspects:

• Number of times unlocking physical lock
• Time taken to unlock physical lock
• Method used to unlock digital lock
• Preference and Approaches to unlocking
• Number of digital locks opened in 5 minute period
• Time taken per lock

I was also going to observe the number of times the reset button was pressed but due to technical issues with the prototype this number would have been heavily inflated and so was not recorded.

Results

Survey Findings

The results from the first two questions were very encouraging with all testers responding yes to both questions as shown below:

Question 1 Results

Question 2 Results

This was a relief as one of my reflections from my first testing session was that I did not stick well enough to the testing process which effected the quality of feedback I received. This time I actually brought a script which I ran through with each tester and provided a full overview of the session. While this made the sessions run a little long (only 6 participants) I feel that I helped the overall quality of results.

The results from question three helped to further understand the audience.

Question 3 Results

From this results as the vast majority of users had a reasonable level of familiarity with combination lock systems, I have decided to stick with this method of controller for the physical prototype iteration. I was initially concerned that the control would not be intuitive but this result shows that it should be feasible.

Question 5 and 6 were designed to look at the interaction method of the lock and how well it mapped to the physical lock. 

Question 5 Results

This result will be explained more in the observation section, but it became clear that the digital lock should have had an inverted control system (right arrow increase lock number, left arrow decrease lock number) rather than a direct mapping of the interaction.

Question 6 Results

Despite the dial not rotating as the majority of users expected there was a clear trend that users believed that the both locks controlled in a similar manner and opened in a similar way. This was the goal of the prototype and helped to solidify the design choice between a free spinning lock and a discrete feedback lock. 

Questions 4 and 7 were designed to evaluate the difficulty of opening the locks and how well the two (physical, digital) mapped.

Question 4 Results

Question 7 Results

I was glad to see that these two graphs overlapped to a large extend with both locks representing a similar level of difficulty. I was surprised to find that the physical lock where you are given the password was so difficult and the digital lock was perceived as easier to unlock. In hindsight a question about how appropriate the difficulty level was, should have been added to the survey.

Question 10 sort of answers this question by asking how long the passwords should be.

Question 10 Result

It is interesting that while testers generally rated the lock as difficult the no one thought that the passwords should be made shorter. While the majority think the 3 key is correct i was surprised that others opted to increase the number as well. This is something that can be further developed in additional prototypes with lock difficulty scaling and password numbers increasing as levels are completed.

Question 8 and 9 were looking to see how effective the prototype was at providing feedback to users on how the unlocking process was progressing.

Question 8 Result

Question 9 Result

This result is somewhat confusing as I was expecting question 9 results to be worse than question 8 results if testers found the feedback mechanisms were lacking. Perhaps this was due to my explanations providing too much detail in the instructions of how the system worked to testers. I still think a secondary visual feedback channel will need to be added for the next prototype to help users through the unlocking process and let them know which direction they should be turning the dial.

This blog post is already over the TLDR status, so I will leave the final evaluation and the observation results for a separate post.

Makey Makeying it Work

This weeks workshop we started getting hands on with the Makey Makey and playing with physical inputs. It was definitely fun experience games like PacMan in a different way (multiplayer each player controlling a direction) was super fun.

After the session exercises we had some free time to play around with the Makey Makeys and try to get our interactive prototypes working. My hacked together paper set up is shown below.

Early Lock Prototypes

After this initial playing I can see that for the next few weeks I am going to need a lot of aluminium foil. The other thing that became obvious is that I am going to need a larger scale lock to make sure that I can get enough contact to rotate the lock correctly. My initial idea is to make a circle which has a number of tabs on it representing the points on the dial and some sort of top with an arm which will make contact with the tabs as it rotates.

Should this style of set up work I will hopefully only have to change my prototype code slightly so that it listens for KeyUP events rather than KeyDOWN events. So that when the arm stops making contact with a point the dial on screen rotates one point.