Showing posts with label usability. Show all posts
Showing posts with label usability. Show all posts

Wednesday, 12 December 2007

213CR Studio 6 | Exploring Playability | Yahoo Pool

There are many ways to quantify playability in a game, and using certain frameworks astute

observations can be made upon the users in-game experience.

To do this decisions need to be made about what behavior indicates the experience.

The experiences in focus are listed below:

1 Flow

2 Easy Fun

3 Hard Fun

4 Serious Fun

5 People Fun


Csikszentmihalyi's Flow Theory:

"•Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one's skill set and abilities).

•Concentrating and focusing, a high degree of concentration on a limited field (a person engaged in the activity will have the opportunity to focus and to delve deeply into it).

•A loss of the feeling of self-consciousness, the merging of action and awareness.

•Distorted sense of time, one's subjective experience of time is altered.

•Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behaviour can be adjusted as needed).

•Balance between ability level and challenge (the activity is neither too easy nor too difficult).

•A sense of personal control over the situation or activity.

•The activity is intrinsically rewarding, so there is an effortlessness of action.

•People become absorbed in their activity, and focus of awareness is narrowed down to the activity itself, action awareness merging (Csikszentmihalyi, 1975. p.72)." - Lecture Notes - John Halloran


Flow itself can be explained to be when a player experiences enough stimulation and challenge to be enthralled and submerged within the game, but not challenged too highly that anxiety causes the player to want to terminate the gaming experience.

Yahoo Pool: Observations of test



One example of People fun that can be found when using Yahoo Pool is the in-game chat facility and game-advertising chat room. Much amusement can be sought after on the heavily populated Pool rooms socialising with the residents. I noticed this when observing my tester (my housemate) play.

The first time I noticed my housemate experiencing Easy fun was when she decided she wanted to know what happened if she tried to try controlling the snooker queue with her left (weaker) hand. This showed that she was curious to see whether it was possible, precisely the sort of Easy fun that is required to hold a players attention. Relating to Lazzarro's Model this fun was open ended and not to fulfill any objective of the game.


Hard Fun was first experienced when my housemate was snookered. She had to use the projection angles provided in game in order to attempt to rebound the whiteball off the cushion to hit her own ball. This was a challenge especially when combined with the 30 seconds shot time that was enforced in this match. This put greater emphasis on the emergency of the decision making, and almost pushed my housemate into the anxiety zone, with her stating "I cant do it! You do it!". However she persevered and enjoyed the tension resulting from the shot. This was also an example of Serious fun because it was the first time she had really taken advantage of the projection angles and therefore she learnt new practices and techniques. This mapping relating the experience percieved by the player and the task required to fulfill the objectives, relates to Csikszentmihalyi's Flow Theory in that it aqquires the correct balance between ability level and challenge (the activity is neither too easy nor too difficult).

The timer almost decieves people into feeling a false perception of time. A players subjective experience of time is altered by the fact that the shot timer is the only time displayed if the Applet is loaded full-screen. This shot counter starts at 30 seconds and counts down, with the player left to count minutes in halfs in their head. This meant that after fifteen or so minutes playing the game, my tester couldnt tell me whether she'd been playing for fifteen minutes or forty-five. This fulfills part of Csikszentmihalyi's Flow Theory.


This exercise has been useful in educating me as to the many ways of quantifying "fun". The different types are now clearly defined in my head, and this exercise will enable me to conduct usability evaluations and user testing sessions to a higher standard. I will know what to look for when analysing game testers experiences, and I will also hopefully be able to design a better game concept that has a near perfect flow balance, submerging the player deep into the game environment. After evaluation of the observations found during testing, I realised that if I was going to be able to fully document the user experience, I would have to capture video and audio of the user playing the game, to create pinpoint mappings between game events and occurance of one or other concept. I could then watch the video and analyse body movement and voiced opinions at my own speed.

An Alternative framework for assessing usability can be read in the link below. This focuses on how to assess usability for the disabled demographic:

http://www.paciellogroup.com/resources/whitepapers/WPAssessingUsability.html

Thursday, 11 October 2007

Creative Zen:Usability Testing Guide


Golden Rules of Design: Shneiderman

Creative Zen:M Media Player


Strive for consistency:
Ensure that the firmware on the media player stays consistent with its interface, terminology, and shortcuts. For example the media player would be much harder to use if the song selection menu was different when within the “Now Playing Interface”, than in the “Artist” list.

Enable frequent users to use shortcuts:
This means that advanced and experienced users are rewarded with having used the media player frequently enough to memorize certain macro’s and shortcuts. These are often established to transfer a “new user friendly” interface, to a far more advanced UI suitable for users wishing to cut down time taken to complete actions. One example of this that is very obvious on the Zen:M is the shortcut function added to the main control panel in the top left corner as can be seen in the picture above. The shortcut function is noted by the arrow sign.
Favourites and user assigned macros can also be much reward to advanced users. This allows the user to define what a certain button press does (macroing). These altered menus can be problematic however when clashes are made between the user assigned interface and the default UI firmware.



Offer Informative Feedback:
Feedback must be delivered quickly and in a concise fashion. Informing the user of the in’s and outs of errors and alerts would confuse most users, so error messages are key so that the user can get used to seeing certain messages and instantly know what action is required of them to resolve the issue. For example when the Media player runs out of battery, no error message is displayed (presumably because there isn’t enough power to display such a message). This can be very confusing and it can take up to half an hour for the media player to even indicate that it is charging when plugged into a mains adaptor. However during the majority of usage the error messages and display dialogues are concise and informative.

Design dialogs to yield closure:
Dialogs must conclude so that the user is advised as to what their instruction is, these methods of concluding the dialog are often represented by yes, no, stop abort or retry options given to the user.

Strive to prevent errors and help users to recover quickly from them:
Input errors are common place so even small
Validation and checking must be present throughout the system to try and ensure that when input errors have been made, users are alerted to them quickly, but not too disruptively so as to allow them to make amendments without noticing a delay for the error indication to be shown.

Allow undo:
Errors must be reversable to allow for human mistakes. Without an undo button the user may make mistakes, but theoretically no serious errors should be made as long as there are certain precautions made when doing potentially disastrous actions, i.e the fact that you have to press yes three times in order to delete a song.

Make users feel they are in control of a responsive system:
Resource-efficient approaches are needed to ensure that users arent struck with heavy waiting times and sluggish responses from the system. Users should be informed of progress at any wait, and information should be displayed regarding the cause of delays.

Reduce short-term memory load:
The everyday user does not want to be overloaded with information that a. may not be useful to the end user, and b. information that the end user will not understand. For example error messages are key to a user understanding what has occured during a problem. Long strings of code and sequences of numbers and letters will only confuse a user.