<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://wiki.cas.mcmaster.ca/skins/common/feed.css?207"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://wiki.cas.mcmaster.ca/index.php?feed=atom&amp;target=Moyj5&amp;title=Special%3AContributions</id>
		<title>Computing and Software Wiki - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://wiki.cas.mcmaster.ca/index.php?feed=atom&amp;target=Moyj5&amp;title=Special%3AContributions"/>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Special:Contributions/Moyj5"/>
		<updated>2026-05-14T11:55:26Z</updated>
		<subtitle>From Computing and Software Wiki</subtitle>
		<generator>MediaWiki 1.15.1</generator>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T18:50:37Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Disadvantages */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
=== The Need for User Input ===&lt;br /&gt;
&lt;br /&gt;
The objectives of the end users should be of paramount importance to software developers, as the the mere existance of a developers software is the accomplish the end users said objectives. As such, user objectives should be ascertained and analyzed in the earliest part of the software development cycle. With this approach, developers can maximize the conciseness of their software while simultaneously providing more users with more function. Early user input will help bring focus to the project, however users must be kept abreast of further modifications and additions throughout the rest of the software development cycle. This way users can be assured that features do not digress from their original intentions and developers can remain focused on the desired feature set as the project inevitably evolves.&lt;br /&gt;
&lt;br /&gt;
=== Methods of Focus ===&lt;br /&gt;
&lt;br /&gt;
==== End User Input ====&lt;br /&gt;
&lt;br /&gt;
Users as a collective are a complex entity, however focus should remain on their explicit needs in order to deliver effective software. Specifically, the people who will physically use the product should be the ones that are consulted, not a &amp;quot;proxy&amp;quot; user meant to represent the user base as a whole. A &amp;quot;proxy&amp;quot; user could be defined as a licensee who distributes software across a system but does not use it, and/or a person who manages users of the software. Their feedback rarely contains information relevant to end user experience since they do not use the software themselves, even though they might be paying for it or distributing it. &lt;br /&gt;
&lt;br /&gt;
==== User Behaviour Modelling ====&lt;br /&gt;
&lt;br /&gt;
While the features provided by a piece of software are important, how users interact with these features should be modelled. When designing a project, the circumstances of the user should be analyzed and modelled in order to provide an interface appropriate to the level of comprehension of the end users. Things such as users' work environment, their behaviour characteristics, and the nature of the users' work itself should be analyzed and considered when making design decisions; such decisions should be run by users to assure effective progress.&lt;br /&gt;
&lt;br /&gt;
==== Systematic Information Gathering and Analysis ====&lt;br /&gt;
&lt;br /&gt;
Consistancy is a desired attribute in a software system, and such an approach should be taken during the development stage in order to assure it. When aquiring user input, developers need to take extra care to ensure that the method of extraction is as consistant as possible. This way, comparisons between user input can be directly made, either quantatively or qualitively. This will avoid ambiguity in the analysis and implementation of user feedback.&lt;br /&gt;
&lt;br /&gt;
=== Usability Experts ===&lt;br /&gt;
&lt;br /&gt;
Experts in the field of usability are important people in the user-centred development cycle. They significantly ease the formalization of developer-client communication, and can provide usability training on several tiers of the development heirarchy. Usability experts can work with designers, providing feedback as development happens; they can also interact with end users in ways that disambiguate their needs, resulting in feedback that is more helpful for developers and designers. This allows team members to remain focused on their particular areas of expertise, preventing inaccurate or redundant usability information or modifications from accruing.&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test having its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
'''User Survey.'''  A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data.&lt;br /&gt;
&lt;br /&gt;
'''Performance-based.'''  Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
'''Think-aloud protocol.'''  Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
'''Co-discovery Learning.'''  Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
* Developers and users possess different models&lt;br /&gt;
* Developer’s Intuitions are not always correct&lt;br /&gt;
* There is no average user&lt;br /&gt;
* It’s impossible to predict usability from appearance&lt;br /&gt;
* Design Standards and guidelines are not sufficient&lt;br /&gt;
* Informal feedback is inadequate&lt;br /&gt;
* Products build in pieces almost always have system-level inconsistencies&lt;br /&gt;
* Problems found late are more difficult and expensive to fix&lt;br /&gt;
* Problems fixed during development mean reduced support costs later&lt;br /&gt;
* Advantages over a competitive product can be achieved&lt;br /&gt;
&lt;br /&gt;
This is not an exhaustive list of reasons to test, but are key ones that Galitz mentions and are certainly relevant in interface design and usability (Galitz 1997, p.592-593).&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the development team can use a method called iterative design. This method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback from a prototype of the interface, correct usability issues raised by them by creating a new prototype, then start a new iteration. Thus, this is a summary of what an iteration should be:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: Each iteration brings improvements to the whole project by solving usability issues. This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback. Thus, usability issues will be corrected easily. These feedbacks can also be used for the development of future projects.&lt;br /&gt;
&lt;br /&gt;
Websites are a good example of iterative method usage: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum to improve it. For software development, it is different as it is impossible to propose an unfinished or unadapted product to the customer. The iterative design method is used to perfect the design before the software release along the development period, especially during testing phases.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method.&lt;br /&gt;
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on future projects&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical as expensive in software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs without spending a lot of time and money.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]&lt;br /&gt;
&lt;br /&gt;
* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]&lt;br /&gt;
&lt;br /&gt;
* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]&lt;br /&gt;
&lt;br /&gt;
* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]&lt;br /&gt;
&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
&lt;br /&gt;
* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;br /&gt;
&lt;br /&gt;
* (Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Computer Publishing.&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T18:49:52Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Benefits */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
=== The Need for User Input ===&lt;br /&gt;
&lt;br /&gt;
The objectives of the end users should be of paramount importance to software developers, as the the mere existance of a developers software is the accomplish the end users said objectives. As such, user objectives should be ascertained and analyzed in the earliest part of the software development cycle. With this approach, developers can maximize the conciseness of their software while simultaneously providing more users with more function. Early user input will help bring focus to the project, however users must be kept abreast of further modifications and additions throughout the rest of the software development cycle. This way users can be assured that features do not digress from their original intentions and developers can remain focused on the desired feature set as the project inevitably evolves.&lt;br /&gt;
&lt;br /&gt;
=== Methods of Focus ===&lt;br /&gt;
&lt;br /&gt;
==== End User Input ====&lt;br /&gt;
&lt;br /&gt;
Users as a collective are a complex entity, however focus should remain on their explicit needs in order to deliver effective software. Specifically, the people who will physically use the product should be the ones that are consulted, not a &amp;quot;proxy&amp;quot; user meant to represent the user base as a whole. A &amp;quot;proxy&amp;quot; user could be defined as a licensee who distributes software across a system but does not use it, and/or a person who manages users of the software. Their feedback rarely contains information relevant to end user experience since they do not use the software themselves, even though they might be paying for it or distributing it. &lt;br /&gt;
&lt;br /&gt;
==== User Behaviour Modelling ====&lt;br /&gt;
&lt;br /&gt;
While the features provided by a piece of software are important, how users interact with these features should be modelled. When designing a project, the circumstances of the user should be analyzed and modelled in order to provide an interface appropriate to the level of comprehension of the end users. Things such as users' work environment, their behaviour characteristics, and the nature of the users' work itself should be analyzed and considered when making design decisions; such decisions should be run by users to assure effective progress.&lt;br /&gt;
&lt;br /&gt;
==== Systematic Information Gathering and Analysis ====&lt;br /&gt;
&lt;br /&gt;
Consistancy is a desired attribute in a software system, and such an approach should be taken during the development stage in order to assure it. When aquiring user input, developers need to take extra care to ensure that the method of extraction is as consistant as possible. This way, comparisons between user input can be directly made, either quantatively or qualitively. This will avoid ambiguity in the analysis and implementation of user feedback.&lt;br /&gt;
&lt;br /&gt;
=== Usability Experts ===&lt;br /&gt;
&lt;br /&gt;
Experts in the field of usability are important people in the user-centred development cycle. They significantly ease the formalization of developer-client communication, and can provide usability training on several tiers of the development heirarchy. Usability experts can work with designers, providing feedback as development happens; they can also interact with end users in ways that disambiguate their needs, resulting in feedback that is more helpful for developers and designers. This allows team members to remain focused on their particular areas of expertise, preventing inaccurate or redundant usability information or modifications from accruing.&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test having its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
'''User Survey.'''  A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data.&lt;br /&gt;
&lt;br /&gt;
'''Performance-based.'''  Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
'''Think-aloud protocol.'''  Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
'''Co-discovery Learning.'''  Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
* Developers and users possess different models&lt;br /&gt;
* Developer’s Intuitions are not always correct&lt;br /&gt;
* There is no average user&lt;br /&gt;
* It’s impossible to predict usability from appearance&lt;br /&gt;
* Design Standards and guidelines are not sufficient&lt;br /&gt;
* Informal feedback is inadequate&lt;br /&gt;
* Products build in pieces almost always have system-level inconsistencies&lt;br /&gt;
* Problems found late are more difficult and expensive to fix&lt;br /&gt;
* Problems fixed during development mean reduced support costs later&lt;br /&gt;
* Advantages over a competitive product can be achieved&lt;br /&gt;
&lt;br /&gt;
This is not an exhaustive list of reasons to test, but are key ones that Galitz mentions and are certainly relevant in interface design and usability (Galitz 1997, p.592-593).&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the development team can use a method called iterative design. This method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback from a prototype of the interface, correct usability issues raised by them by creating a new prototype, then start a new iteration. Thus, this is a summary of what an iteration should be:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: Each iteration brings improvements to the whole project by solving usability issues. This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback. Thus, usability issues will be corrected easily. These feedbacks can also be used for the development of future projects.&lt;br /&gt;
&lt;br /&gt;
Websites are a good example of iterative method usage: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum to improve it. For software development, it is different as it is impossible to propose an unfinished or unadapted product to the customer. The iterative design method is used to perfect the design before the software release along the development period, especially during testing phases.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method.&lt;br /&gt;
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on future projects&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical and expensive for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]&lt;br /&gt;
&lt;br /&gt;
* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]&lt;br /&gt;
&lt;br /&gt;
* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]&lt;br /&gt;
&lt;br /&gt;
* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]&lt;br /&gt;
&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
&lt;br /&gt;
* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;br /&gt;
&lt;br /&gt;
* (Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Computer Publishing.&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T18:47:30Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
=== The Need for User Input ===&lt;br /&gt;
&lt;br /&gt;
The objectives of the end users should be of paramount importance to software developers, as the the mere existance of a developers software is the accomplish the end users said objectives. As such, user objectives should be ascertained and analyzed in the earliest part of the software development cycle. With this approach, developers can maximize the conciseness of their software while simultaneously providing more users with more function. Early user input will help bring focus to the project, however users must be kept abreast of further modifications and additions throughout the rest of the software development cycle. This way users can be assured that features do not digress from their original intentions and developers can remain focused on the desired feature set as the project inevitably evolves.&lt;br /&gt;
&lt;br /&gt;
=== Methods of Focus ===&lt;br /&gt;
&lt;br /&gt;
==== End User Input ====&lt;br /&gt;
&lt;br /&gt;
Users as a collective are a complex entity, however focus should remain on their explicit needs in order to deliver effective software. Specifically, the people who will physically use the product should be the ones that are consulted, not a &amp;quot;proxy&amp;quot; user meant to represent the user base as a whole. A &amp;quot;proxy&amp;quot; user could be defined as a licensee who distributes software across a system but does not use it, and/or a person who manages users of the software. Their feedback rarely contains information relevant to end user experience since they do not use the software themselves, even though they might be paying for it or distributing it. &lt;br /&gt;
&lt;br /&gt;
==== User Behaviour Modelling ====&lt;br /&gt;
&lt;br /&gt;
While the features provided by a piece of software are important, how users interact with these features should be modelled. When designing a project, the circumstances of the user should be analyzed and modelled in order to provide an interface appropriate to the level of comprehension of the end users. Things such as users' work environment, their behaviour characteristics, and the nature of the users' work itself should be analyzed and considered when making design decisions; such decisions should be run by users to assure effective progress.&lt;br /&gt;
&lt;br /&gt;
==== Systematic Information Gathering and Analysis ====&lt;br /&gt;
&lt;br /&gt;
Consistancy is a desired attribute in a software system, and such an approach should be taken during the development stage in order to assure it. When aquiring user input, developers need to take extra care to ensure that the method of extraction is as consistant as possible. This way, comparisons between user input can be directly made, either quantatively or qualitively. This will avoid ambiguity in the analysis and implementation of user feedback.&lt;br /&gt;
&lt;br /&gt;
=== Usability Experts ===&lt;br /&gt;
&lt;br /&gt;
Experts in the field of usability are important people in the user-centred development cycle. They significantly ease the formalization of developer-client communication, and can provide usability training on several tiers of the development heirarchy. Usability experts can work with designers, providing feedback as development happens; they can also interact with end users in ways that disambiguate their needs, resulting in feedback that is more helpful for developers and designers. This allows team members to remain focused on their particular areas of expertise, preventing inaccurate or redundant usability information or modifications from accruing.&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test having its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
'''User Survey.'''  A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data.&lt;br /&gt;
&lt;br /&gt;
'''Performance-based.'''  Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
'''Think-aloud protocol.'''  Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
'''Co-discovery Learning.'''  Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
* Developers and users possess different models&lt;br /&gt;
* Developer’s Intuitions are not always correct&lt;br /&gt;
* There is no average user&lt;br /&gt;
* It’s impossible to predict usability from appearance&lt;br /&gt;
* Design Standards and guidelines are not sufficient&lt;br /&gt;
* Informal feedback is inadequate&lt;br /&gt;
* Products build in pieces almost always have system-level inconsistencies&lt;br /&gt;
* Problems found late are more difficult and expensive to fix&lt;br /&gt;
* Problems fixed during development mean reduced support costs later&lt;br /&gt;
* Advantages over a competitive product can be achieved&lt;br /&gt;
&lt;br /&gt;
This is not an exhaustive list of reasons to test, but are key ones that Galitz mentions and are certainly relevant in interface design and usability (Galitz 1997, p.592-593).&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the development team can use a method called iterative design. This method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback from a prototype of the interface, correct usability issues raised by them by creating a new prototype, then start a new iteration. Thus, this is a summary of what an iteration should be:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: Each iteration brings improvements to the whole project by solving usability issues. This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback. Thus, usability issues will be corrected easily. These feedbacks can also be used for the development of future projects.&lt;br /&gt;
&lt;br /&gt;
Websites are a good example of iterative method usage: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum to improve it. For software development, it is different as it is impossible to propose an unfinished or unadapted product to the customer. The iterative design method is used to perfect the design before the software release along the development period, especially during testing phases.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method&lt;br /&gt;
* Most of the usability issues will be solved&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on the next user interface&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical and expensive for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]&lt;br /&gt;
&lt;br /&gt;
[http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]&lt;br /&gt;
&lt;br /&gt;
[http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]&lt;br /&gt;
&lt;br /&gt;
[http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
&lt;br /&gt;
[http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/User:Skip</id>
		<title>User:Skip</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/User:Skip"/>
				<updated>2009-11-23T18:41:21Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Topics: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Human Computer Interaction =&lt;br /&gt;
&lt;br /&gt;
=='''This is the projects main page for cs4hc3 and se4f03''' -- ''HCI / CHI'' Courses.==&lt;br /&gt;
&lt;br /&gt;
===Objectives===&lt;br /&gt;
&lt;br /&gt;
===Logistics===&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    During the middle of term the class will be divided into about 12 (n) groups, each of whom will negotiate amongst&lt;br /&gt;
    themselves a topic of concentration from the list below with at least three ranked by selected priority.&lt;br /&gt;
    At an early designated lecture, each group will be linked to a topic of their choice in a first-come/first-served&lt;br /&gt;
    basis -- only one group per project.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    Group members should all have their associated member email addresses and use these to generate a wiki in one of the&lt;br /&gt;
    groups member names.  Note that ALL changes made to a wiki are logged by IP address of the machine, as well as time&lt;br /&gt;
    and date.  By law Derek Lipiec MUST always be running an audit trail system which essentially operates as a key logger&lt;br /&gt;
    in that if any vandalism is done electronically, he can determine who is logged on, from where as well as what was typed.&lt;br /&gt;
    This is a warning that anyone modifying a group's wiki who is NOT a member of that group will be caught and risk a zero&lt;br /&gt;
    grade for this assignment exists.  Therefore &amp;quot;play safe&amp;quot; and do not fool around.  (wfsp)&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    Just after several weeks of class duration, a created wiki from each group will be completed&lt;br /&gt;
    and marked.  As soon as scheduled, these dates will be posted in the ELM calendar for this course.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    Part of this mark will be composed of 12 other rankings (by three groups of four members each as listed below)&lt;br /&gt;
    from &amp;lt;b&amp;gt;each&amp;lt;/b&amp;gt; of the other group members, &amp;lt;b&amp;gt;done individually&amp;lt;/b&amp;gt;, who will rank and provide one sentence&lt;br /&gt;
    of what is best and one sentence of what is worst about the subject wiki under consideration.  This is done&lt;br /&gt;
    through sending Dr.Poehlman an email with the three marks and single sentences for like and dislike reasons.&lt;br /&gt;
    The ranking for each wiki will be compiled by the instructor and posted anonymously for class consideration&lt;br /&gt;
    and discussion near the end of term.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Topics:===&lt;br /&gt;
Reference -- adapted from ACM (Association for Computing Machinery -- but people can join, too!) http://wiki.acm.org/cs2001/index.php?title=HUMAN-COMPUTER_INTERACTION&lt;br /&gt;
&amp;lt;OL&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Motivation:''' Why the study of how people interact with technology is vital for the development of most usable and acceptable systems. [[Motivations for the Studying of HCI]] (Taken by Group 10 -- wfsp/15nov09@14:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Contexts for HCI:''' mobile devices, consumer devices, business applications, web, business applications, collaboration systems, games, etc. [[Contexts for HCI]] (Taken by Group 8 -- wfsp/05nov09@14:00)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''[[Process_for_User-centered_Development]]:''' early focus on users, empirical testing, iterative design. (Specified for Group 11 -- wfsp/15nov09@14:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Different measures for evaluation:''' utility, efficiency, learnability, user satisfaction. (Taken by Group 5 -- wfsp/10nov09@13:00)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Models that inform human-computer interaction (HCI) design:''' attention, perception and recognition, movement, and cognition.&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Social issues influencing HCI design and use:''' culture, communication, and organizations. (Taken by Group 3 -- wfsp/13nov09@15:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Accommodating human diversity:''' including universal design and accessibility and designing for multiple cultural and linguistic contexts. (Taken by Group 9 -- wfsp/12nov09@13:30)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The most '''common''' interface '''design mistakes'''. (Taken by Group 1 -- wfsp/04nov09@17:00)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''[[User Interface Standards]]'''. (Taken by Group 6 -- wfsp/05nov09@19:30)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The '''five interaction styles''' as espoused by [[B.Scheidermann]]. (Taken by Group 7 -- wfsp/04nov09@17:30)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The '''Object-Action''' (or visa-versa) '''model''' and its applications. [[The Object-Action (or_visa-versa) model and its applications]](Specified for Group 2 -- wfsp/15nov09@14:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The '''direct manipulation method''' and its importance to CHI. [[Direct Manipulation]] (Taken by Group 4 -- wfsp/06nov09@09:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
&amp;lt;/OL&amp;gt;&lt;br /&gt;
&amp;lt;h4&amp;gt;&lt;br /&gt;
  Marking Duties for Each Group:&lt;br /&gt;
&amp;lt;/h4&amp;gt;&lt;br /&gt;
&amp;lt;table  border=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;th&amp;gt;&lt;br /&gt;
      &amp;lt;u&amp;gt;Group   Mark1   Mark2   Mark3&amp;lt;/u&amp;gt;&lt;br /&gt;
    &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      1   Group 2  Group 3  Group 4&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      2   Group 3  Group 4  Group 5&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      3   Group 4  Group 5  Group 6&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      4   Group 5  Group 6  Group 7&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      5   Group 6  Group 7  Group 8&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      6   Group 7  Group 8  Group 9&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      7   Group 8  Group 9  Group 10&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      8   Group 9  Group 10 Group 11&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      9   Group 10 Group 11 Group 01&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      10  Group 11 Group 01 Group 02&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      11  Group 01 Group 02 Group 03&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
=='''This is the VRML assignment main page for cs4hc3 and se4f03''' &amp;lt;br&amp;gt; -- ''HCI / CHI'' Courses.==&lt;br /&gt;
NOTE:  This is NOT required for the 2009-2010 version of this course.&lt;br /&gt;
===Some Important References:===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;UL&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    The Custom Courseware for this course has an Appendix section for VRML beginners so this is a good place to begin studying if you are not familiar with the Virtual Reality Modelling Language.  We will be using this to create 3-D interfaces for 3-D worlds, just to get some practice in thinking in more than two dimensions.  Although VRML has been around for more than a decade, it is still found as the 3-D layer in MPEG4, has been updated and in a standard in the W3C world known as X3D, which is just VRML with &amp;lt;elements&amp;gt; instead of reserved keywords.  If you know VRML, you know X3D.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    To begin our study of the Virtual Reality Modeling Language (VRML), we need to get setup to view the VRML code (which is in pure ASCII, as is Javascript, etc.)  To create VRML, use any ASCII editor that you like best.  I use Crimson Editor which has a built-in context sensitive markup that understands VRML, so it is easy to distinguish comments from verbs and nouns, etc.&lt;br /&gt;
Go to http://sourceforge.net/projects/emeraldeditor/files/ where Emerald Editor (the newest version of the Crimson editor) can be downloaded freely.  To interpret VRML code (nested in HTML code) you need a plug-in.  The best that I have found is called Cortona from Parallel Graphics at http://www.cortona3d.com/cortona/ .  It works best with Apple Safari Browser version 4 from http://www.apple.com/safari/download/ .  All of this information is at the end of the course web site section on VRML at http://www.cas.mcmaster.ca/~se4d03/demo.html#VRML headed with the title &amp;quot;Recommended Client Applications&amp;quot;.  By the way, Parallel Graphics has an editor called VRMLPad that is not free but can be downloaded as a trial version, which may help the beginner as it provides a thumbnail sketch at the margin right when it recognizes any VRML code shape primitives -- interesting thing to see work.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    As far as web references go, the best place to start is on the course web site: &amp;lt;br&amp;gt; --&lt;br /&gt;
    http://www.cas.mcmaster.ca/~se4d03/demo.html#VRML &lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;ol&amp;gt;&lt;br /&gt;
    &amp;lt;li&amp;gt;&lt;br /&gt;
      Once here you can take the tutorial, done by a senior thesis student Polo Cerone several year's ago.&lt;br /&gt;
      It can be taken on-line or downloaded and worked through locally -- either is equivalent.&lt;br /&gt;
    &amp;lt;/li&amp;gt;&lt;br /&gt;
    &amp;lt;li&amp;gt;&lt;br /&gt;
      Once the tutorial is taken, there are many example VRML code snippets that can be viewed with whatever browser plug-in that you have installed.  Pay particular attention to the graduated examples that show how one specifically goes about creating an interface in VRML that controls objects in the main scene graph.  This is located back near the beginning of the VRML section titled &amp;quot;Graduated VRML2 Interface Examples&amp;quot;.&lt;br /&gt;
    &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;/ol&amp;gt;&lt;br /&gt;
&amp;lt;/UL&amp;gt;&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/User:Skip</id>
		<title>User:Skip</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/User:Skip"/>
				<updated>2009-11-23T18:39:46Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Topics: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Human Computer Interaction =&lt;br /&gt;
&lt;br /&gt;
=='''This is the projects main page for cs4hc3 and se4f03''' -- ''HCI / CHI'' Courses.==&lt;br /&gt;
&lt;br /&gt;
===Objectives===&lt;br /&gt;
&lt;br /&gt;
===Logistics===&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    During the middle of term the class will be divided into about 12 (n) groups, each of whom will negotiate amongst&lt;br /&gt;
    themselves a topic of concentration from the list below with at least three ranked by selected priority.&lt;br /&gt;
    At an early designated lecture, each group will be linked to a topic of their choice in a first-come/first-served&lt;br /&gt;
    basis -- only one group per project.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    Group members should all have their associated member email addresses and use these to generate a wiki in one of the&lt;br /&gt;
    groups member names.  Note that ALL changes made to a wiki are logged by IP address of the machine, as well as time&lt;br /&gt;
    and date.  By law Derek Lipiec MUST always be running an audit trail system which essentially operates as a key logger&lt;br /&gt;
    in that if any vandalism is done electronically, he can determine who is logged on, from where as well as what was typed.&lt;br /&gt;
    This is a warning that anyone modifying a group's wiki who is NOT a member of that group will be caught and risk a zero&lt;br /&gt;
    grade for this assignment exists.  Therefore &amp;quot;play safe&amp;quot; and do not fool around.  (wfsp)&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    Just after several weeks of class duration, a created wiki from each group will be completed&lt;br /&gt;
    and marked.  As soon as scheduled, these dates will be posted in the ELM calendar for this course.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    Part of this mark will be composed of 12 other rankings (by three groups of four members each as listed below)&lt;br /&gt;
    from &amp;lt;b&amp;gt;each&amp;lt;/b&amp;gt; of the other group members, &amp;lt;b&amp;gt;done individually&amp;lt;/b&amp;gt;, who will rank and provide one sentence&lt;br /&gt;
    of what is best and one sentence of what is worst about the subject wiki under consideration.  This is done&lt;br /&gt;
    through sending Dr.Poehlman an email with the three marks and single sentences for like and dislike reasons.&lt;br /&gt;
    The ranking for each wiki will be compiled by the instructor and posted anonymously for class consideration&lt;br /&gt;
    and discussion near the end of term.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Topics:===&lt;br /&gt;
Reference -- adapted from ACM (Association for Computing Machinery -- but people can join, too!) http://wiki.acm.org/cs2001/index.php?title=HUMAN-COMPUTER_INTERACTION&lt;br /&gt;
&amp;lt;OL&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Motivation:''' Why the study of how people interact with technology is vital for the development of most usable and acceptable systems. [[Motivations for the Studying of HCI]] (Taken by Group 10 -- wfsp/15nov09@14:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Contexts for HCI:''' mobile devices, consumer devices, business applications, web, business applications, collaboration systems, games, etc. [[Contexts for HCI]] (Taken by Group 8 -- wfsp/05nov09@14:00)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''[[Process_for_User-centered_Development Process for user-centered development]]:''' early focus on users, empirical testing, iterative design. (Specified for Group 11 -- wfsp/15nov09@14:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Different measures for evaluation:''' utility, efficiency, learnability, user satisfaction. (Taken by Group 5 -- wfsp/10nov09@13:00)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Models that inform human-computer interaction (HCI) design:''' attention, perception and recognition, movement, and cognition.&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Social issues influencing HCI design and use:''' culture, communication, and organizations. (Taken by Group 3 -- wfsp/13nov09@15:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''Accommodating human diversity:''' including universal design and accessibility and designing for multiple cultural and linguistic contexts. (Taken by Group 9 -- wfsp/12nov09@13:30)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The most '''common''' interface '''design mistakes'''. (Taken by Group 1 -- wfsp/04nov09@17:00)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; '''[[User Interface Standards]]'''. (Taken by Group 6 -- wfsp/05nov09@19:30)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The '''five interaction styles''' as espoused by [[B.Scheidermann]]. (Taken by Group 7 -- wfsp/04nov09@17:30)&amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The '''Object-Action''' (or visa-versa) '''model''' and its applications. [[The Object-Action (or_visa-versa) model and its applications]](Specified for Group 2 -- wfsp/15nov09@14:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
  &amp;lt;Li&amp;gt; The '''direct manipulation method''' and its importance to CHI. [[Direct Manipulation]] (Taken by Group 4 -- wfsp/06nov09@09:30) &amp;lt;/Li&amp;gt;&lt;br /&gt;
&amp;lt;/OL&amp;gt;&lt;br /&gt;
&amp;lt;h4&amp;gt;&lt;br /&gt;
  Marking Duties for Each Group:&lt;br /&gt;
&amp;lt;/h4&amp;gt;&lt;br /&gt;
&amp;lt;table  border=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;th&amp;gt;&lt;br /&gt;
      &amp;lt;u&amp;gt;Group   Mark1   Mark2   Mark3&amp;lt;/u&amp;gt;&lt;br /&gt;
    &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      1   Group 2  Group 3  Group 4&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      2   Group 3  Group 4  Group 5&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      3   Group 4  Group 5  Group 6&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      4   Group 5  Group 6  Group 7&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      5   Group 6  Group 7  Group 8&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      6   Group 7  Group 8  Group 9&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      7   Group 8  Group 9  Group 10&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      8   Group 9  Group 10 Group 11&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      9   Group 10 Group 11 Group 01&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      10  Group 11 Group 01 Group 02&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
  &amp;lt;tr&amp;gt;&lt;br /&gt;
    &amp;lt;td&amp;gt;&lt;br /&gt;
      11  Group 01 Group 02 Group 03&lt;br /&gt;
    &amp;lt;/td&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
=='''This is the VRML assignment main page for cs4hc3 and se4f03''' &amp;lt;br&amp;gt; -- ''HCI / CHI'' Courses.==&lt;br /&gt;
NOTE:  This is NOT required for the 2009-2010 version of this course.&lt;br /&gt;
===Some Important References:===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;UL&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    The Custom Courseware for this course has an Appendix section for VRML beginners so this is a good place to begin studying if you are not familiar with the Virtual Reality Modelling Language.  We will be using this to create 3-D interfaces for 3-D worlds, just to get some practice in thinking in more than two dimensions.  Although VRML has been around for more than a decade, it is still found as the 3-D layer in MPEG4, has been updated and in a standard in the W3C world known as X3D, which is just VRML with &amp;lt;elements&amp;gt; instead of reserved keywords.  If you know VRML, you know X3D.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    To begin our study of the Virtual Reality Modeling Language (VRML), we need to get setup to view the VRML code (which is in pure ASCII, as is Javascript, etc.)  To create VRML, use any ASCII editor that you like best.  I use Crimson Editor which has a built-in context sensitive markup that understands VRML, so it is easy to distinguish comments from verbs and nouns, etc.&lt;br /&gt;
Go to http://sourceforge.net/projects/emeraldeditor/files/ where Emerald Editor (the newest version of the Crimson editor) can be downloaded freely.  To interpret VRML code (nested in HTML code) you need a plug-in.  The best that I have found is called Cortona from Parallel Graphics at http://www.cortona3d.com/cortona/ .  It works best with Apple Safari Browser version 4 from http://www.apple.com/safari/download/ .  All of this information is at the end of the course web site section on VRML at http://www.cas.mcmaster.ca/~se4d03/demo.html#VRML headed with the title &amp;quot;Recommended Client Applications&amp;quot;.  By the way, Parallel Graphics has an editor called VRMLPad that is not free but can be downloaded as a trial version, which may help the beginner as it provides a thumbnail sketch at the margin right when it recognizes any VRML code shape primitives -- interesting thing to see work.&lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;li&amp;gt;&lt;br /&gt;
    As far as web references go, the best place to start is on the course web site: &amp;lt;br&amp;gt; --&lt;br /&gt;
    http://www.cas.mcmaster.ca/~se4d03/demo.html#VRML &lt;br /&gt;
  &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;ol&amp;gt;&lt;br /&gt;
    &amp;lt;li&amp;gt;&lt;br /&gt;
      Once here you can take the tutorial, done by a senior thesis student Polo Cerone several year's ago.&lt;br /&gt;
      It can be taken on-line or downloaded and worked through locally -- either is equivalent.&lt;br /&gt;
    &amp;lt;/li&amp;gt;&lt;br /&gt;
    &amp;lt;li&amp;gt;&lt;br /&gt;
      Once the tutorial is taken, there are many example VRML code snippets that can be viewed with whatever browser plug-in that you have installed.  Pay particular attention to the graduated examples that show how one specifically goes about creating an interface in VRML that controls objects in the main scene graph.  This is located back near the beginning of the VRML section titled &amp;quot;Graduated VRML2 Interface Examples&amp;quot;.&lt;br /&gt;
    &amp;lt;/li&amp;gt;&lt;br /&gt;
  &amp;lt;/ol&amp;gt;&lt;br /&gt;
&amp;lt;/UL&amp;gt;&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T07:19:13Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test has its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data. &lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
==== Co-discovery Learning ====&lt;br /&gt;
&lt;br /&gt;
Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the iterative design method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback about current interface, correct usability issues, then start a new iteration. Five steps compose an iteration:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: Each iteration brings improvements to whole project. This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method&lt;br /&gt;
* Most of the usability issues will be solved&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on the next user interface&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical and expensive for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
&lt;br /&gt;
[http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T07:15:44Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test has its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data. &lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
==== Co-discovery Learning ====&lt;br /&gt;
&lt;br /&gt;
Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the iterative design method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback about current interface, correct usability issues, then start a new iteration. Five steps compose an iteration:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: Each iteration brings improvements to whole project. This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method&lt;br /&gt;
* Most of the usability issues will be solved&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on the next user interface&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical and expensive for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
&lt;br /&gt;
[http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T05:45:42Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test has its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data. &lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
==== Co-discovery Learning ====&lt;br /&gt;
&lt;br /&gt;
Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the iterative design method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback about current interface, correct usability issues, then start a new iteration. Five steps compose an iteration:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method&lt;br /&gt;
* Most of the usability issues will be solved&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on the next user interface&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical and expensive for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
&lt;br /&gt;
[http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T03:45:01Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test has its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data. &lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
==== Co-discovery Learning ====&lt;br /&gt;
&lt;br /&gt;
Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the iterative design method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback about current interface, correct usability issues, then start a new iteration. Five steps compose an iteration:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
It explains why it fits totally with User Interface development and design. The development of a good user interface is mostly the result of a good understanding of its users needs and behaviour. As it's hard for a user interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on users feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
&lt;br /&gt;
Advantages related to iterative design are numerous.&lt;br /&gt;
&lt;br /&gt;
* Inconsistencies around application design are detected earlier than with a traditional development method&lt;br /&gt;
* Most of the usability issues will be solved&lt;br /&gt;
* Better understanding of users needs&lt;br /&gt;
* Testing phase is easier to plan as the testing team will proceed by iterations&lt;br /&gt;
* Better knowledge about the current project status: good visibility of the project advancements&lt;br /&gt;
* Keep an history of mistakes done in the past to do better on the next user interface&lt;br /&gt;
&lt;br /&gt;
=== Disadvantages ===&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost if you exaggerate the number of iterations. Indeed, each iteration takes a lot of time and time is critical and expensive for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
[http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T03:37:13Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test has its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data. &lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
==== Co-discovery Learning ====&lt;br /&gt;
&lt;br /&gt;
Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the iterative design method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback about current interface, correct usability issues, then start a new iteration. Five steps compose an iteration:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
That is why it fits totally with User Interface development. The development of a good User Interface is mostly associated to a good understanding of future user's needs and behaviour. As it's hard for a User Interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on user's feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost. Indeed, each iteration takes a lot of time and time is critical for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;br /&gt;
[http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T03:36:46Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantified, which focus primarily on user feedback from interaction with the product.  These tests are mainly based on user interaction with the interface as opposed to non-user based tests.  Some non-user based tests are expert review, compliance reviews, heuristic evaluations, and cognitive walkthroughs.  These tests are based on the review of an ‘expert’ or check to see if usability of the product satisfy a checklist or group of well-known principles, such as Shneiderman’s 8 golden rules or Norman’s 4 principles of usability among others.  The main concern of non-user based tests is that users are not actually giving feedback about the interface, instead it is the ‘experts’ who are giving feedback who claim to know what users will accept, which of course is not always the case.  Whereas, user-based testing could include user surveys, performance-based, think-aloud protocol, or co-discovery learning, with each test has its pros and cons.  &lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
A user survey will have the user use a prototype and then fill out a survey based on their experience.  In this case, the answers the user provides will be restricted to what they are allowed to choose as answers, which allow for quick gathering of data.  It can be said that user surveys are easy to conduct remotely, but relies heavily self-reported data. &lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
Performance-based tests will have the user complete a specific task using a prototype of the interface.  The data gathered will be based on the user experience of performing the given task with the prototype.   This type of test is good for comparative evaluations, but is not a complete picture of usability and could be misleading. &lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
Think-aloud protocol consists of having the user say what is on their mind while they are using the interface and trying to accomplish a task.  The idea is to discover the thought processes involved in using the interface.  This method can capture the user’s understanding, but cannot be used to evaluate performance, because of its disruptive nature.  &lt;br /&gt;
&lt;br /&gt;
==== Co-discovery Learning ====&lt;br /&gt;
&lt;br /&gt;
Co-discovery learning is a modified version of think-aloud, in the sense that the user will still think-aloud, but will be working with another person to accomplish a task, with the aim being to allow the user to more naturally verbalize their thoughts.  It is more revealing, but potentially more difficult to conduct.&lt;br /&gt;
&lt;br /&gt;
=== Purpose of Testing ===&lt;br /&gt;
&lt;br /&gt;
=== Key Reasons to Test ===&lt;br /&gt;
&lt;br /&gt;
=== Analyze and Retest ===&lt;br /&gt;
&lt;br /&gt;
=== Limitations ===&lt;br /&gt;
&lt;br /&gt;
Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations.  Rubin and Chisnell, point out that testing is always an artificial situation in the sense that the very act of conducting a study can itself affect the results.  Test results do not prove that a product works, in that it is not a guarantee, but only a probability that results were not due to chance.  Participants are rarely fully representative of the target population.  Testing is not always the best technique to use, since at different stages it may be unnecessary to bring in many participants to reveal the obvious.  Testing is just that, a test, which only accounts for hours of use.  Even with these limitations Rubin and Chisnell(Handbook of Usability Testing, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
When designing a user interface, it is almost impossible to obtain an interface without any usability issues in a single attempt. To solve this problem, the iterative design method is applied in the development of a new product (typically a software with a user interface). It consists of developing it by a succession of iterations. Iterations are used to improve the current interface by collecting users feedback about current interface, correct usability issues, then start a new iteration. Five steps compose an iteration:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
&lt;br /&gt;
Iterative design is about refinement: This method puts quality in the centre of the development process. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future users needs. &lt;br /&gt;
&lt;br /&gt;
That is why it fits totally with User Interface development. The development of a good User Interface is mostly associated to a good understanding of future user's needs and behaviour. As it's hard for a User Interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on user's feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost. Indeed, each iteration takes a lot of time and time is critical for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed. Jakob Nielsen has realized experiences about the number of iterations that should be performed by a user interface designer. According to his opinion, developers should realize three iterations to obtain an interface adapted to users needs.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T01:39:46Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
==== Co-discovery ====&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
The iterative design method is a method applied in the development of a new product (typically a software). It consists of developing by a succession of iterations. Five steps compose this method:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
* Repeat steps 2 to 4 until you get the desired result&lt;br /&gt;
&lt;br /&gt;
This method puts quality at the centre of the development path. Indeed, by refining step by step the design, you obtain a product totally in appropriateness to its future user's needs. &lt;br /&gt;
&lt;br /&gt;
That is why it fits totally with User Interface development. The development of a good User Interface is mostly associated to a good understanding of future user's needs and behaviour. As it's hard for a User Interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on user's feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost. Indeed, each iteration takes a lot of time and time is critical for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T01:38:05Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
==== Co-discovery ====&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
The iterative design method is a method applied in the development of a new product (typically a software). It consists of developing by a succession of iterations. Five steps compose this method:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
* Repeat steps 2 to 4 until you get the desired result&lt;br /&gt;
&lt;br /&gt;
This method puts quality at the centre of the development path. Indeed, by refining step by step the design, you obtain a product approved by its future users. &lt;br /&gt;
&lt;br /&gt;
That is why it fits totally with User Interface development. The development of a good User Interface is mostly associated to a good understanding of future user's needs and behaviour. As it's hard for a User Interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on user's feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost. Indeed, each iteration takes a lot of time and time is critical for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
[http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T01:37:27Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
=== User-based Tests ===&lt;br /&gt;
&lt;br /&gt;
==== User Survey ====&lt;br /&gt;
&lt;br /&gt;
==== Performance-based ====&lt;br /&gt;
&lt;br /&gt;
==== Think-aloud protocol ====&lt;br /&gt;
&lt;br /&gt;
==== Co-discovery ====&lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
The iterative design method is a method applied in the development of a new product (typically a software). It consists of developing by a succession of iterations. Five steps compose this method:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
* Repeat steps 2 to 4 until you get the desired result&lt;br /&gt;
&lt;br /&gt;
This method puts quality at the centre of the development path. Indeed, by refining step by step the design, you obtain a product approved by its future users. &lt;br /&gt;
&lt;br /&gt;
That is why it fits totally with User Interface development. The development of a good User Interface is mostly associated to a good understanding of future user's needs and behaviour. As it's hard for a User Interface designer to get a perfect understanding of them, the iterative design method allows him to base his work on user's feedback and improve his product based on their point of view. Thus, usability issues will be corrected easily.&lt;br /&gt;
&lt;br /&gt;
Websites always use this method: Web masters generally propose a new website design and collect user's feedback by email or with a dedicated topic on the website forum. For software development, it is different as it is impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release during the testing period.&lt;br /&gt;
&lt;br /&gt;
One of the problem of iterative design is its cost. Indeed, each iteration takes a lot of time and time is critical for software development. It will avoid patching the software in the future but can become really expensive if too many iterations are performed.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development</id>
		<title>Process for User-centered Development</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Process_for_User-centered_Development"/>
				<updated>2009-11-23T01:29:11Z</updated>
		
		<summary type="html">&lt;p&gt;Moyj5:&amp;#32;/* Iterative Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Write introduction here.&lt;br /&gt;
&lt;br /&gt;
== Early Focus on Users ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Empirical Testing ==&lt;br /&gt;
&lt;br /&gt;
'''Some user-based testing'''&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
== Iterative Design ==&lt;br /&gt;
&lt;br /&gt;
The iterative design method is applied in the development of a new product (typically a software). It consists of developing by a succession of iterations. Five steps compose this method:&lt;br /&gt;
&lt;br /&gt;
* Prepare a prototype design of the product&lt;br /&gt;
* Present this design to a set of potential users&lt;br /&gt;
* Collect problems noticed by users&lt;br /&gt;
* Refine design based on users point of view&lt;br /&gt;
* Repeat steps 2 to 4 until you get a desired result&lt;br /&gt;
&lt;br /&gt;
This method puts quality at the centre of the development path. Indeed, by refining step by step the design, you obtain a product approved by its future users. That's the main reason why it fits totally with User Interface development. As it's hard for a User Interface designer to get a perfect understanding of user's needs and behaviour, it allows him to base his work on user's feedback and improve his product based on their point of view.&lt;br /&gt;
&lt;br /&gt;
Websites use this method a lot: Web masters generally propose an interface and collect user's feedback by email or with a dedicated topic on the website forum and correct mistakes. For software development, it is different as it's impossible to propose an unfinished product to the customer. The iterative design method is used to perfect the design before the software release.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;/div&gt;</summary>
		<author><name>Moyj5</name></author>	</entry>

	</feed>