when you constructed your NEEDS ANALYSIS, you were setting your project up for evaluation [assignment 3]
KEEP all of your DOCUMENTATION carefully – this will be an aspect of assignment 4
stuff to cover:
- documentation [ass 4]
- low-fi TO hi-fi – the table model for iterative project methodologies
- HCI – user evaluation techniques
- subjective evaluation techniques – fun or no fun?
- participant and performance interactives – welcome to the war!
from last week:
| Finding measurable characteristics for the user experience criteria is even harder, though. How do you measure satisfaction, fun, motivation or aesthetics? What is entertaining to one person may be boring to another; these kinds of criteria are subjective and so cannot be measured objectively
[Löwgren, J. (2002). How far beyond human-computer interaction is interaction design? ] |
prototype driven development: Reducing risk by embracing change and finding the fun earlier. This technique focuses on reducing overall design risk. [lost garden]
time to EMBRACE FAILURE – during the early stages!
homer demonstrates how things can go wrong if there has been no prototyping and no audience evaluation [wmv]
and dilbert shows how a prototype can work just as it is in low-fi
before we start: documentation
the timelines, schedules etc you produced for assignment 2 will form an important basis for assignment FOUR:
| Assignment 4 Aims:
You will produce a detailed report on this semester's activities. Project description: Reflective journal Critical incident analysis [KIB210 week one document - look for full details under assessment later] |
you should be COLLATING this documentation as you go from NOW
if you don't have one already, i recommend a BLOG – you could even use QUT's student e-portfolio space
[furious steals]don't end up drowning in paper![brazil]
a return to assignment 3 – further development phase
| Aims: Engaging the user in the development process.
Further development of your prototype. Project description: User feedback Develop a method by which they will interact with your prototype, including a suitable method for recording their interaction. Collate, present and discuss their interaction. Prototyping |
prototyping is a long process:
from BC to 2000AD – don't expect to produce a finished work!
DO expect to produce an evaluated prototype as an aspect of ITERATIVE DESIGN PROCESS
gameinnovation.org – a taxonomy of developments
more on [further] prototyping: moving from very low- fi to a bit higher fi
| from assignment 3 prototype component criteria: [doc]
All of the design modifications are successfully incorporated into the prototype. Few if any bugs present, functionality is complete |
notice the expectation is NOT a completed interactve but rather an IN-DEPTH exploration of functionality [sans bugs!]
bug free in this context would imply that the poor old evaluator does not need to have the miracle explained …
User test of a low-fidelity paper prototype of a website

User test of a high-fidelity paper prototype of a homepage

[from nielsen norman group training video stills]
oh … where to start!!
ingredients:
- low-fi prototype
- audience
decision one: audience definition – users, reader-viewer-listeners – participants – performers [?]
decision two: which mechanics to test? eg which mechanics hold the interactive up?
start with the documentation: – evaluation data MUST BE FORMALISED

- do you need ETHICAL CLEARANCE [example] [QUT ethics docs]
- prepare a BETA questionnaire – start with an introduction – overview
- do you need audience statistics – demographics etc [check your needs analysis - you probably predicted this]
have you ever written a survey before: check out survey design

| in iterative design, the GOALS [what you want to learn about] should FOCUS on ASPECTS // functionality
Q: what do you want to learn? |
developing prototypes: FOCUS on functional ASPECTS
another cooking metaphor: the table model or two levels of prototyping – basically, this describes what types of capabilities are implemented in a prototype:

J. Nielsen distinguishes two levels of prototyping according to the level of interaction provided by the prototype [Nielsen 93]:
- The horizontal prototype is actually only the man-machine interface (MMI). It could even be a sketch on paper.
- The vertical prototype implements some of the functionalities of the application allowing to more interaction

Horizontal prototypes are appropriate for understanding relationships across a broad system and for showing the range of abilities of a system.
Vertical prototypes are most appropriate when a certain complex feature of a system is poorly-understood and needs to be explored, e.g. as a proof-of-concept
.[usability first]
notice: the horizontal – vertical model is actually designed for a TRADITIONAL project methodology – in an iterative innovative project, it probably won't stand up!
methods of evaluation
There are a variety of approaches to usability evaluation that you may choose to take.
The methodologies can be divided into two broad categories:
- those that gather data from actual users and
- those that can be applied without actual users present.
[usability first glossary]
usabillity first: methods table
notice how all of these established methods assume a USER interactive
Usability and context
Usability is not a quality that exists in any real or absolute sense. Perhaps it can be best summed up as being a general quality of the appropriateness to a purpose of any particular artefact. This notion is neatly summed up by Terry Pratchett in his novel "Moving Pictures": "
'Well, at least he keeps himself fit,' said the Archchancellor nastily. 'Not like the rest of you fellows. I went into the Uncommon Room this morning and it was full of chaps snoring!'
'That would be the senior masters, Master,' said the Bursar. 'I would say they are supremely fit, myself.'
'Fit? The Dean looks like a man who's swallered a bed!'
'Ah, but Master,' said the Bursar, smiling indulgently, 'the word "fit", as I understand it, means "appropriate to a purpose", and I would say that the body of the Dean is supremely appropriate to the purpose of sitting around all day and eating big heavy meals.' The Dean permitted himself a little smile. " [Pratchett, 1990]
[john brooke - SUS - a quick and dirty scale]
SO: always CHOOSE your evaluation group appropriately to your prototype goal!
[the hunting of the snark from equator]
prototype testing for users
try the CSUQ – computer system usability questionnaire

users – the interface is designed to be invisible in order for the user to enact the TASK
a principle is 'ask and observe' – lots of usability questionnaires [usability.net]
further development [?]
- [piano]
- [piano and music]
- [piano game]
| notice how each one of these iterations of the concept takes a specific FUNCTIONALITY and explores it …
this is ITERATIVE methodology – a waterfall would examine stages in prototype development |
piano – develops the VISUALS a little and makes key functionality more adult

piano and music ENHANCES this specific functionality by showing the musical notation

the piano game explores the potential of the MIMICRY function

simon says – turning the mimicry function into a TOY by introducing CHALLENGE

evaluating participant interactives
this development of the keyboard mechanics offers a simple challenge function [remember and follow the sequence]
the [user] interactive has become a TOY or [passive] participant interactive
why passive – no meaningful action or agency but basic engagement via challenge
HOW TO EVALUATE THIS ?
WHAT exactly is being evaluated:
- usability – use usability questionnaire
- fun factor
time for some SUBJECTIVE EVALUATION – subjective evaluation asks the user – player how they FEEL

Needs and Pleasures
Design is a way to ask questions. Design research, when it occurs through the practice of design itself, is a way to ask larger questions beyond the limited scope of a particular design problem.
When design research is integrated into the design process, new and unexpected questions emerge directly from the act of design.
[eric zimmerman - iterative design]
evaluating and documenting FUN factors:
- ask!!
- give the person some options – would you play again?
- observe – video
- video – cued recall: record the participation and ask the player questions with the video as aide memoire
Test; analyze; refine. And repeat ……
Because the experience of a viewer/user/player/etc cannot ever be completely predicted, in an iterative process design decisions are based on the experience of the prototype in progress.
The prototype is tested, revisions are made, and the project is tested once more.
In this way, the project develops through an ongoing dialogue between the designers, the design, and the testing audience.
[eric zimmerman - iterative design]
adding more participant mechanics
piano maestro – single and two player
be the piano meastro! play against the computer [single player] or against your friends, rock out to the music of the masters of the keyboard from history, challenge all comers!
inspiration – rocking out to iron man [wmv]
| notice: this design takes us into physical manipulation – how big should the piano be? |
evaluation
good gameplay has become the ulitimate goal pursued by anyone who wishes to remain in the business of game design [HCI & Game Design By Zhan Ye]

the ye brothers argue that there are two distinct aspects to the concept of good gameplay
- playability – this involves all the classic USABILITY checks and guidelines
- FUN [challenge, entertainment] – this is the subjective data collected from PLAYTESTING
play turns out to be a very problematic concept: the ambiguity of play by brian sutton-smith
| oh no, MORE prototyping!
you will almost certainly NEED to prototype and TEST your survey – evaluation methodology DOES your evaluation method answer the questions you are asking? homer offers an example [wmv] |
but it aint as problematic as NARRATIVE …..
viewer [listener] – reader audience prototype development and evaluation
remember the viewer [listener] – reader category [?]
VIEWERS: are people who seek entertainment. They want to be surprised, seduced, led along a path. their goal is the journey, not the end result.
READERS: those who seek the same kind of interaction they get from a novel or a film – narrative experience
253 a novel for the Internet about London Underground in seven cars and a crash
idea one: piano in the wood – a musical literary work …
idea two: play the narrative


the concept here is based on the actual life of 'frere jacque' – set in the 11C, the reader can explore the tale of mystery and intrigue in any order but following the notes of the song will lead them thru' on a direct path
similar works: Milorad Pavic – Landscape Painted With Tea, Italo Calvino – If On A Winter's Night, A Traveller…
| define: hypertext |
evaluation
usability … a return to point and click indeed BUT here, the pleasure is the experience [of reading, comprehending the plot - unpacking the mystery]
i can see it as the new da vinci code
subjective:
this is NARRATIVE interaction – can narrative be seen as a performing art?
some say even LINEAR READING is interactive – in the sense that to understand the text, the reader suspends disbelief and becomes involved in the story – reader response theory – there are many variants on this theory:
reader response – various positions
![]() |
the problem in evaluating READING as an interactive event is that you have to get inside the reader's head
some of lecture three explored these possibilities |
BUT ::::::::
NON-LINEAR READING – welcome to ERGODIC texts
This phenomenon I call ergodic, using a term appropriated from physics that derives from the Greek words ergon and hodos, meaning "work" and "path." In ergodic literature, nontrivial effort is required to allow the reader to traverse the text.
If ergodic literature is to make sense as a concept, there must also be nonergodic literature, where the effort to traverse the text is trivial, with no extranoematic responsibilities placed on the reader except (for example) eye movement and the periodic or arbitrary turning of pages. [espen aarseth - cybertext]
computer games can be interpreted as ergodic texts: play zork online [from infocom adventures]
the argument is that NON-TRIVIAL EFFORT provides AGENCY and therfore defies NARRATIVE
games exist in a formal/algorithmic domain, stories in a domain of interpretation, and this means that games resist the evocative themes of stories, because they cannot be formalised.
[jesper juul 2000]
in this view, the AGENCY is the thing – the narrative is secondary to the ACTIVITY
WELCOME TO THE WAR
evaluation – from this perspective is a simple matter of discovering whether or not the LUDOS [gameplay mechanics] are EFFECTIVE
BUT …….
there remains the embedded narrative issue … the manner in which gameplay and FUN is constructed by the manner in which the participant is EMOTIONEERED
adding emotion …
physical space – we have you surrounded exploited physical design space to create the claustrophobia of the original fort

genevieve moved from still images to physical embodiment
the fully participant work DOOM3 calls on cinematic techniques of film noire and constructs emotion via lighting – or lack of it
doom3 trailer [wmv] and the effects: [wmv]
AUDIO is of course THE most powerful emotioneering medium

trailer for ghost recon 3 [wmv]
try this [wmv]
what about this: [wmv]
and this: [wmv]
and the original [wmv]
| another battle front?
of course, CINEMA – a supposed non-interactive media exploits such emotioneering techniques all the time what happens to the concept of interactivity when EMOTIONAL response is included ????? what about that suspension of disbelief and theatre?? |
evaluating : user and subjective data
things you should be doing:
- start by re-examining your low – fi prototype – which functionality will you explore into a hi-fi iteration?
- work on the chosen aspect
- design your evaluation methodology – TEST IT
- then test new vertical prototype with actual people
- ensure your data is collected systematically
- breathe – review and REPEAT
evaluaton – design – iteration cycle

we will cover other methods of evaluation and user study in subsequent lectures but a word of advice:
if you haven't had fun making it, it is really very likely that it won't be fun to play [anonymous]



From Just How Far Beyond HCI is Interaction Design:
by Jonas Löwgren
Published on 04/22/2002
First, interaction design is a design discipline, which means something other than the science-and-engineering perspectives of HCI.
A more well-grounded design approach would offer better ways of approaching the quality issue. Some useful starting points may be to view design as knowledge construction within a community of practice, to consider design-theoretical approaches to articulating the languages and meanings of products (so-called product semantics), and to consider product or use genres as knowledge-organizing systems.
Secondly, the notion of quality in interaction design is not well developed. Neither are the social structures needed to develop and sustain the notion. A HCI perspective is not the most appropriate starting point.
Every interaction involves feeling as well as intellect; aesthetic qualities reside in the overall interaction, which is determined above all by the functions, structures, social action spaces and temporal qualities (the dynamic gestalt) of the system.
Third, it makes sense to talk about aesthetic qualities of interaction, even though we lack an adequate language as yet to do so. But the language of HCI is not the best place to look for inspiration.
Reference
Löwgren, J. 2002. Just How Far Beyond HCI is Interaction Design. Boxes and Arrows. (accessed 4 May, 2006).http://www.boxesandarrows.com/view/just_how_far_beyond_hci_is_interaction_design_
Comment by Beefy — May 13, 2006 @ 9:56 am
From Lost Garden
The need for fundamental engine systems
This is costly, time consuming and gets in the way of the real task at hand: rapidly exploring a series of game mechanics.
Solution – Use an existing engine: My recommendation is to use off the shelf or preexisting engines that have most major systems in place. Ideally, you can work at a higher level by manipulating pre-existing blocks of functionality and focus on roughing out the game mechanics.
Having preexisting systems for handling simple physics, collision detection, player movement, path finding, and input device support can make your life much easier.
The misplaced urge to create sound architecture
Most prototype do not need to be overly robust architectures to test the basic game play. Therefore the completion of the further refinement of high-fidelity prototype is not a perfectionism. It is still part of a prototyping stage. As the author stated ‘it can be quite damaging to build a perfect framework.
Solution – Set strict time limits on architectural work.
The goal is to create a prototype that can be critiqued, trashed and thrown away. The goal is not to create a finished product. There is a time and a place for spending copious time on your architecture and the prototyping phase is not it. Depending on the personality of your team, this can be your biggest project management challenges.
This was implemented in the prototype development as the low-fidelity prototype was requirested by the client for initial submission before high-fidelity prototype is developed.
Importance of project momentum
A prototype becomes something more valuable when it is an enjoyable mini-game that shows great promise. At this point, people begin to get excited about the project. They’ll put in the extra time if needed and it becomes more difficult for the project to have its resources taken away. A project with momentum can go through a dozen iterations in a short period of time. A project without this momentum might hit two or three iterations in the same amount of time. Both projects can have killer game design ideas at their core, but poor execution of the prototyping phase will kill off the low momentum project before it even has a chance.
The flash game has an aim and motivation for users to engage as well as challenges for the game designer to develop.
Solution – Prototype early and prototype often: Focus on early results and do everything you can to keep the momentum going. Promote your early successes and outline the immediate short term steps you are taking towards success.
A roadmap with clearly defined, visible chunks of meaningful functionality can be a great help in organizing your work effort. By making each chunk of work small enough to easily build, you ensure that there is always a constant stream of interesting results coming from the prototyping project. Avoid long gaps between prototypes at all cost.
THREE functionalities of the flash game has been identified at the beginning of the prototyping process. These were kept in mind throughout the whole period of time. As a result, further, and more complicated refinements motivates the game developer to continue.
Locking in mechanics too early and reducing the scope of the game
If you focus on all sorts of little details and fix all these bugs at the initial process, then you will end up with a short trivial mini-game that is not fun to play.
Solution – Focus on the design on the big picture: A better tactic is to look at the game from the standpoint of its future potential.
* Can the player make meaningful decisions?
* Is the player getting the feedback they require to make good decisions?
* Are the major risk / reward schedules in place?
* What is the pacing of the experience?
* Is there enough meat here to hang the rest of the game on?
These higher level questions will reveal fundamental problems with your game play and point to additional systems that must be added. Often by thinking big and then paring the design down to its core elements, you’ll end up with a prototype that has the foundation for some major game play elements.
This aided in my decision making, by consulting existing games and incorporating several major features in the prototype. then further refinement to meet the concept needs, functionalities and mechanics.
Getting feedback from the wrong users
If seeking feedback from game developers who were involved in the low fi prototype , then the game will grow too difficult as th skill level of the people testing the game have gathered enough experience. The end result was the game IS enjoyable for expert game players but not for general public.
Solution – Gather new user feedback: The way around this is to use lots of ‘Kleenex Testers’ to balance the useful testing done by the development team. These are ‘throw away’ testers that try the game for the first time and then are never used again. Setting up such a system ensures that you are constantly having your expert opinion challenged by a fresh, unpolluted crop of new users.
Content heavy Games
Solution – Know when to prototype and when to start production: Prototyping still has a place in established, content heavy genres. I suspect the various weapons in Half Life 2 were heavily prototyped before they made it into the game. I’ll bet money that Blizzard spent ages testing the WoW combat system at very early stages in the project’s development. However, ultimately 99% of the work that will go into such games will be custom crafted content. When the conversation turns to custom content, it is time for the prototyping phase to hand over the reigns to the production team.
Prototypes can’t do everything. However, done correctly they can provide a strong foundation to build the rest of the game upon.
Conclusion
As long as you have great knowledge of game design, entry level programming and art skills are all you need to produce great games. However, game designers without access to programming talent is a windbag.
Reference
Redmond, D. Lost Garden: Common Game Prototyping Pitfalls.
(accessed 4 May, 2006).
http://lostgarden.com/2005/08/common-game-prototyping-pitfalls.html
Comment by Beefy — May 13, 2006 @ 10:48 am
DO expect to produce an evaluated prototype as an aspect of ITERATIVE DESIGN PROCESS
From Ilterative Design Process
Needs and Pleasures
Research design methodology – the iterative design process.
Iteration design is a design methodology based on a cyclic process of prototyping, testing, analyzing and refining a work in progress. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.
Test; analyze; refine. And repeat. Because the experience of a viewer/user/player/etc cannot ever be completely predicted, in an iterative process design decisions are based on the experience of the prototype in progress. The prototype is tested, revisions are made, and the project is tested once more. In this way, the project develops through an ongoing dialogue between the designers, the design, and the testing audience.
In the case of this assignment, iterative design means playtesting. Throughout the entire process of design and development, the game is played. The development team plays it. Clients play it. A organize groups of testers that match your target audience was invited to test it. We have acquired as many people as possible play the game. In each case, we observe them, ask them questions, then adjust the design and playtest again.
A more iterative design process will streamline development resources and result in a more robust and successful final product.
Assignment THREE documentation
During assignment 2, we initially worked with the clients to identify the project's values: the abstract principles that the prototype would embody. The list of values we created included designing for a borad audience of non-dancers; a low techicality barrier; a prototype that was easy to learn and play buy deep and complex; gameplay that was intrinsically social and something that was in line with the educational context.
These play values were the parameters for a series of brainstorming sessions, interspersed with group play of dancer and non-dancing students. Eventually, a concept emerged: young-adults being controlled by the shoe. While every product embodies some kind of dance steps, we were drawn towards modeling a dance step that we hadn't seen depicted previously in a game. Technology and production limitations meant that the game would be digitally based, although it could involve a basic movement for the physical prototype.
Once these basic formal and conceptual questions had begun to be mapped out, the shape of the initial prototype became clear. The very first versio of Dancing shoes was played with a pair of shoes and a model posing various dance moves on tiled floors. As with the digital prototype, a hand-full of basic actions the player could make was implemented in the flash game.
Designing a first prototype requires strategic thinking about how to most quickly implement a playable version that can begin to address the project's chief uncertanties in a meaningful way.
A short version of the game was developed in assignment 2. Therefore the final form will last much longer for each stage. The high fidelity prototype was about implementing interactivity, visual and audio aesthetics, and other aspects of the game.
While we tested gameplay via the short flash iteration, programming for the final version began in Flash, and the core game logic we had developed for the Dancing Shoes prototype was recycled into the Flash Actionscript with little alteration. Parallel to the game design, the graphic language of the game and chart were presented in screen layouts. These early drafts of the visuals (initially developed through Adobe Illustrator and Photoshop) were dropped into the Flash version of the game.
As soon as the Flash version was playable, the development team played it. And as our game grew more refined, the clients tested it. After the initial screening, our clients have invited a group of testers to play the game. All of this testing and feedback helped us refine the game logic, visual aesthetics, and interface. The biggest challenge turned out to be clearly articulating the relationship between player action and game outcome: because the results of every turn are interdependent on each player’s actions, early versions of the game felt frustratingly arbitrary. Only through many design revisions and dialogue with our testers did we manage to structure the results of each turn to unambiguously communicate what had happened that round and why.
When the high fidelity was completed, we launched the game to an invite-only beta-tester community that slowly grew in the weeks leading up to public release. Certain time slots were scheduled as official testing events. We made it very easy for the beta testers to contact us and email in bug reports.
In the case of Dancing Shoes, the testing and prototyping cycle of iterative design was successful because at each stage, we clarified exactly what we wanted to test and how. We used written questionnaires. We debriefed after each testing session. And we strategized about how each version of the game would incorporate the visual, audio, game design, and technical elements of the previous versions, while also laying a foundation for the final form of the experience.
Reference
Zimmerman, E. 2006. Ilterative Design.
(accessed 4 May, 2006).
http://www.gmlb.com/articles/iterativedesign.html
Comment by Beefy — May 13, 2006 @ 11:30 am
FIND DANCE.SWF AND FLA, THE ORIGINAL FILE OF DANCING SHOES BY JACK LEE.
Taxonomy = 分類法;分類學
Assignment 3
decision one: audience definition – users
decision two: 3 mechanics to test
1. Set timing acuracy as to when users should eliminate the keys
2. Moving Dance Partner back and forth like real-life situation
3. Step animation being portrayed in real-life scenario.
mechanics that hold the interactive up
start with the documentation: Survey questionnaires, using SUS survey theory by John Brooke.
*audience statistics – requires 5 non-dance users (aged 18~30) that are computer literate, 5 non-dance students (aged 18~30) that are not computer literate, 5 dance students (aged 18~30)computer literate, 5 dance students (aged 18~30) not computer literate
As identified in assignment 2, Needs Analysis.
INTERVIEWS
From :
Creative Research Systems. 2003. Survey Design, Questionnaire Design Tips. (accessed 4 May, 2006).
http://www.surveysystem.com/sdesign.htm
Personal Interviews
An interview is called personal when the Interviewer asks the questions face-to-face with the Interviewee. Personal interviews can take place in the home in front of the computer.
Advantages
* The ability to let the Interviewee see, feel and/or taste a product.
* The ability to find the target population. For example, you can find people who have seen a film much more easily outside a theater in which it is playing than by calling phone numbers at random.
* Longer interviews are sometimes tolerated. Particularly with in-home interviews that have been arranged in advance. People may be willing to talk longer face-to-face than to someone on the phone.
Disadvantages
* Personal interviews usually cost more per interview than other methods. This is particularly true of in-home interviews, where travel time is a major factor.
* Each mall has its own characteristics. It draws its clientele from a specific geographic area surrounding it, and its shop profile also influences the type of client. These characteristics may differ from the target population and create a non-representative sample.
Therefore there is a limited number of people that were asked to be interviewed in such a short time frame.
J. Nielsen
J. Nielsen distinguishes two levels of prototyping according to the level of interaction provided by the prototype [Nielsen 93]:
* The horizontal prototype is actually only the man-machine interface (MMI). It could even be a sketch on paper.
* The vertical prototype implements some of the functionalities of the application allowing to more interaction
Usability First
From:
Usability First.2005. Usibility glossary: horizontal and vertical prototypes. (accessed 6 May, 2006)
http://www.usabilityfirst.com/glossary/term_363.txl
Horizontal prototypes are appropriate for understanding relationships across a broad system and for showing the range of abilities of a system.
Vertical prototypes are most appropriate when a certain complex feature of a system is poorly-understood and needs to be explored, e.g. as a proof-of-concept
Methods of Evaluation
From:
Usability First. 2005. Methods. (accessed 6 May, 2006).
http://www.usabilityfirst.com/methods/index.txl
There are a variety of approaches to usability evaluation that you may choose to take.
The methodologies can be divided into two broad categories:
* those that gather data from actual users and
* those that can be applied without actual users present.
Your choice of method depends on:
* Cost of evaluation
* Appropriateness to project
* Time constraints
* Cost of implementation
* Cost of training new users
Getting Started
User Centred Design is an approach that supports the entire development process with user-centred activities, in order to create applications which are easy to use and are of added value to the intended users.
At the planning and development of the project during assignment 2, real users were invited to test the prototype early in the project and frequently thereafter.
The objectives, requirements, and constraints of the development project, context of use and user testing scenario and the how and when; usibility requirements and guidelines and resources were collected at the initial client (stakeholder) meeting as outlined in assignment 2.
The standards for the way your interface is going to look and feel, so that it presents a consistent picture to the user and doesn’t commit some of the more elementary mistakes. Take a look at existing guidelines.
Raise awareness about usability in the rest of the development team by engaging them in usability topics. Bring your manager into the discussions.
Start by using disposable prototypes to try out some ideas with people from your user group. Paper prototyping is an excellent way to involve end users in the early stages of design. As your ideas firm up with the help of your user groups, you’ll be starting to create more advanced prototypes which may contain portions of code that you can use for the final release.
stakeholder meeting
A stakeholder meeting is a strategic way to derive usability objectives from business objectives, and to gain commitment to usability. It also collects information about the purpose of the system and its overall context of use.
Analyse context of use
Collect and agree detailed information about:
* Who are the intended offsiteuser and what are their offsitetask? (Why will they use the system? What is their experience and expertise?)
* What are the offsitetechnical and offsiteenvironmental constraints? (What types of hardware will be used in what organisational, technical and physical environments?)
This information is an essential input to requirements and the planning of other usability methods. It may be collected at an early stage during planning and feasibility, or in more detail as part of the usability requirements.
* Ensure that all factors that relate to use of the system are identified before design work starts.
* Provide a basis for designing later usability tests
evaluating existing systems
Evaluation of an earlier version or competitor system to identify usability problems and to obtain baseline measures of usability.
* Identifies problems to be avoided in the design of the new system.
* Provides measures of effectiveness, efficiency and satisfaction which can be used as a baseline for the new system.
scenarios of use
Scenarios specify how users carry out their tasks in a specified context. They provide examples of usage as an input to design, and provide a basis for subsequent usability testing. They are user- and task-oriented use cases.
Benefits
* It encourages designers to consider the characteristics of the intended users, their tasks and their environment.
* Usability issues can be explored at a very early stage in the design process (before a commitment to code has been made).
* Scenarios can help identify usability targets and likely task completion times.
* The method promotes developer buy-in and encourages a user-centred design approach.
* Scenarios can also be used to generate contexts for evaluation studies.
* Only minimal resources are required to generate scenarios.
* The technique can be used by developers with little or no human factors expertise.
Method
An experienced moderator is recommended for the sessions in which the scenario is explored.
* Gather together the development team and other relevant stakeholders under the direction of an experienced facilitator.
* Identify intended users, their tasks and the general context. This information will provide the basis for the scenarios to be created by the development team.
* Functionally decompose user goals into the operations needed to achieve them.
* Consider which activities should be performed by the user and which by the computer.
* Create an outline of the users’ activities, goals and motivations for using the system being designed, and the tasks they will perform.
* To maintain design flexibility, scenarios should not specify what product features are used.
* Assign task time estimates and completion criteria as usability targets.
* The session can be videotaped for later review or transcribed for wider distribution.
* The results from scenario building sessions can be used to plan user-based evaluations.
requirements meeting
A workshop attended by users and developers who identify usability requirements that can be tested later in the development process.
* Highlights the importance of usability early in development
* Provides concrete objectives for usability
* Provides usability criteria that can be tested.
style guides
Style guides are used to provide a consistent look and feel. They should be defined as part of usability requirements and conformance should be monitored during development.
Benefits
* Style guides embody good practice in interface design.
* Following a style guide will increase the consistency between screens.
* Using a style guide can reduce the development time.
* Following general usability guidelines will improve the quality of the interface.
dianostic evaluation,
User based evaluation of a working system, where the primary objective is to identify usability problems.
Benefits
* Major usability problems are identified.
* An understanding is gained of why the user has difficulties with the system.
* Approximate measures can be obtained for the users’ effectiveness, efficiency and satisfaction.
subjective assessment
Summary
Subjective assessment tells the evaluator how the users feel about the software being tested. This is distinct from how efficiently or effectively they perform with the software. The usual method of assessment is to used a standardised opinion questionnaire to avoid criticisms of subjectivity.
Benefits
* In a discretionary use scenario, user satisfaction is most probably the largest single key factor which will influence the users’ decision whether or not to continue with the software (other key factors may include price, technology, and brand loyalty).
* In a mandatory use scenario, poor satisfaction leads to absenteeism, fast staff turnover, and unrelated complaints from the workforce.
* Subjective Assessment complements data from efficiency and effectiveness measures.
* Subjective assessment usually produces a list of satisfying and unsatisfying software features which is especially useful if testing is taking place during development.
Method
This method gives the evaluator information about how the users feel about using the software being evaluated. This should be distinguished from:
* how well they perform with the software (effectiveness)
* how efficiently they work with the software (efficiency)
It is customary to use a close-ended questionnaire if one is available, in order to produce quantitative data, otherwise the results of the activity can be vague and open to interpretation. At worst, a critical incidents type technique may be used.
Usibility Inspection:
A usability inspection is a review of a system based on a set of guidelines. The review is conducted by a group of experts who are deeply familiar with the concepts of usability in design. The experts focus on a list of areas in design that have been shown to be troublesome for users.
Usability guidelines are usually derived from studies in human-computer interaction, ergonomics, graphic design, information design, and cognitive psychology. Some areas that get evaluated are the language used in the system, the amount of recall required of the user at each step in a process, and how the system provides feedback to the user. In particular, issues such as clarity, consistency, navigation, and error minimization are analyzed. Once the problems are discovered, the experts make recommendations for resolving these issues.
User Testing
User testing is the mainstay method when it comes to finding usability problems. Nothing is more convincing than watching person after person encounter difficulties with the same part of a software or information system. The difficult areas that repeat themselves between multiple test participants reveal areas that should be studied and changed by the developers. User testing can often uncover very specific areas needing improvement, where focus groups and task analysis often find more general areas needing improvement.
A trained observer conducts user testing often with the assistance of software developers. People who are representative of the target audience are asked to perform representative tasks with the software. The observer writes a user testing report listing the problems and offering recommendations based on their findings.
Comment by Beefy — May 14, 2006 @ 4:50 am
For the comment above
Reference
Usibility net. Methods list. 2006. (accessed 6 May, 2006)
http://www.hostserver150.com/usabilit/tools/list.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INTRODUCTION
The Dancing Shoes
++++++++++++++++++++++++++++++++++++++++++++++
ambient = 周遭的;環繞的
pervasive = 普遍的
The Dancing Shoes is a dancing game designed to promote novel forms of playing and learning for teen adults, using a diversity of ambient and pervasive technologies. These kinds of interactive spaces to encourage aspects of playful learning.
The Dancing Shoes game involved groups of teen adults having to use the keyboard arrows as a means of movement to follow the instructions shown on the screen in a computer based context.
Dancing Shoes is an interactive device that engages user in musical environment. The purpose of the product is to educate and correct user’s dance steps by controlling user’s movements. The product is used for educational purposes, such as dance schools, interested participants, etc. The main focus of the product is to train user’s dance technique with continuous control.
The purpose of using flash is to demonstrate how the music and dance movements are synchronized. It provides a game interface, similar to Konami’s Dance Dance Revolution game, to interact and learn. The user will be able to interact with the flash game in a fun and entertaining environment. They will learn the dance steps through visual and audio aids in the flash game. There are four different types of dance styles to choose from in the low-fidelity prototype.
a) This screen is the main menu for the Dancing Shoes flash game. The user will begin by clicking on the Game Instruction link to the Game Instruction screen.
b) The user will be able to obtain game instructions and rules from this screen. Then the user can navigate back to the main menu from the BACK button.
c) After redirecting back to the first screen, the user then chooses a pair of shoes for that specific dance style.
d) Use the arrow keys on the keyboard to move your foot towards the direction as displayed on the screen as soon as it touches your dance partner. If you fail to do move the step on the right timing, you will lose 1 of 3 chances. Once you have lost all 3 chances, the game is over. Your aim is to match your steps with your dance partner by retaining the appropriate step movements. The step animation on the right-hand side will synchronize with the arrows; therefore you could observe the dance movements while learning the order of the steps in a fun and entertaining sound toy environment.
e) The user will be able to return to the Main Menu through the Return link down the bottom.
TRIALS AND ANALYSIS
engrossed = 全神貫注的,專心致志的
Our project team ran a number of trials with our client and beta-testers aging from 18-30 years, demonstrating that the young adults were able to become engrossed in playful learning.
Comment by Beefy — May 14, 2006 @ 5:10 am
FURTHER DEVELOPMENT
Each one of these iterations of the concept takes a specific FUNCTIONALITY and explores it. It is an iterative methodology – a waterfall would examine stages in prototype development.
EVALUATING PARTICIPANT INTERACTIVES
this development of the keyboard mechanics offers a simple challenge function [remember and follow the sequence]
the [user] interactive has become a TOY or [passive] participant interactive
why passive – no meaningful action or agency but basic engagement via challenge
EVALUATION
* usability – through SUS usability questionnaire
* fun factor – through personal interview
* refer to the methods – subjective evaluation asks the user how they FEEL.
USER = The task that is set for the user to look and achieve is to be educated on the dance steps through visal aids.
EVALUATING AND DOCUMENTING FUN FACTORS:
*ask if they would play again?
*observe through video, record the beta-testers.
TEST, ANALYZE, REFINE AND REPEAT
EVALUATION
good gameplay has become the ulitimate goal pursued by anyone who wishes to remain in the business of game design [HCI & Game Design By Zhan Ye]
the ye brothers argue that there are two distinct aspects to the concept of good gameplay
[REFERENCE]
Ye, Z. 2005. HCI and Game Design: From a Practicioner’s Point of View. ZhanYe & DingYe. (accessed 6 May, 2006)
http://www.ye-brothers.com/documents/HCIGAMEDESIGN.pdf
* playability – this involves all the classic USABILITY checks and guidelines
* FUN [challenge, entertainment] – this is the subjective data collected from PLAYTESTING
MUST DO’S
*prototype and test your survey – in the evaluation methodology
*does the evaluation method answer the questions you are asking? (refer back to the “Feedback Methodology” in the KIB210A3_Prototype.doc)
Comment by Beefy — May 14, 2006 @ 6:05 am
Flash Tutorial
http://www.actionscripts.org/tutorials/intermediate/Collision_Detection/index.shtml
Comment by Beefy — May 20, 2006 @ 9:57 am
http://www.google.com.au/search?q=usability+in+game+design&btnG=Search&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial
http://www-128.ibm.com/developerworks/library/us-cranky17.html?n-us-742
http://iat.ubalt.edu/courses/cosc324.101_SP06/COSC324-01.ppt
http://stcsig.org/usability/newsletter/0410-gamedocs.html
http://www.usernomics.com/news/user-interface-design-news.html
Comment by Beefy — May 29, 2006 @ 5:09 am