Computing and Software Wiki - User contributions [en]

Process for User-centered Development

2009-11-23T20:48:04Z

Adamssw: This space for rent.

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

Users have complex and diverse needs and wants. Focus in interface design should remain on the people who will actually use the product as part of their work. A ''proxy'' user meant to represent the user base should not be used. A proxy user could easily include groups who have an interest in the software project, but do not actually use it. Examples of these people include systems administrators or managers who only need a minimal interaction with the system.
Their input rarely contains information relevant to end user experience since they do not have a first hand perspective, even though they might be paying for or distributing the software.

==== User Behaviour Modelling ====

The features provided by a piece of software are important to the customer, and how users interact with these features is important to the design of the interface. It should be modeled as closely as possible on the user's actual work environment, their behavior characteristics and the nature of the user's work.

Appropriate models that take these factors into account will provide interface designers with a framework that will allow for intelligent interface prototypes to be constructed. These prototypes can be quickly tested by real users and further refinements will quickly lead to an effective design.

==== Systematic Information Gathering and Analysis ====

Consistency is a desirable attribute in a software design, and a systematic approach should be taken during development to encourage 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.

=== Usability Experts ===

Experts in the field of usability are important contributors to 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 hierarchy. Usability experts work with designers, providing feedback as development occurs; they also interact with end users in ways that disambiguate their needs, resulting in feedback that is more useful 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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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. Non-user based tests are ''expert review, compliance reviews, heuristic evaluations,'' and ''cognitive walk-throughs''. These tests are based on the review of an ‘expert’ and check if the usability of the product satisfies certain criteria based on well-known principles. Examples of the criteria include Shneiderman’s 8 golden rules or Norman’s 4 principles of usability, but could include legal requirements for example. User-based testing can include surveys, performance metric evaluations, think-aloud protocol, or co-discovery learning among others. Centers such as IBM's User Centered Design Center in Markham, Ontario attempt to formalize this process to derive empirical rules of software interface design.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing serves two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s intuitions are not always correct
* There is no average user
* It is impossible to predict usability from appearance
* Design standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products built in pieces almost always have system-level inconsistencies
* Problems found late in the development cycle are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

While not an exhaustive list to justify testing, it highlights the key points made by Galitz. (Galitz 1997, p.592-593).

=== Analyze and Retest ===
The testing process should be cyclic. Once the first test has been performed, it is important to analyze the data and establish benchmarks for further testing. Fixing old problems produces new problems. Once problems have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. When the prototype is ready, it must be tested to gather more data, adjusting benchmarks and the prototype until involved parties are satisfied. This is a main component of iterative design and makes user centered design much simpler to incorporate.

=== Limitations ===

Although empirical testing can solve many design problems, it has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 only accounts for hours of use, subtle or unusual problems may not be revealed in this environment. Even with these limitations, Rubin and Chisnell (Handbook of Usability Testing 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

In the design of a user interface, it is not possible to obtain an interface free from 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 new products in general, and can be applied to software easily. Iterations are used to improve the interface by collecting user feedback from a prototype of the interface. Usability issues raised can be corrected in the creation of a new prototype, which is then evaluated.

The steps in an iteration should be:
* Prepare a prototype design
* Present this design to a set of potential users
* Collect potential problems, as reported by users
* Refine design based on user input

Iterative design is purely about refinement; each iteration brings improvements to the whole project by solving usability issues. This method puts user assessed quality at the centre of the development process.

Development of a good user interface is the result of understanding user's needs and behavior. It is hard for an interface designer to obtain a perfect understanding of user's goals and the iterative design method allows them to base their work on user feedback. Thus, usability issues will be minimized.

=== Benefits ===

Some advantages of iterative design are:
* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most usability issues will be solved: less post release patches and upgrades
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations
* Better knowledge about the current project status: good visibility of the project advancements
* Provides a history of mistakes made to help with future projects

=== Disadvantages ===

One of the problem of iterative design is it's cost, if you exaggerate the number of iterations. Indeed, each iteration can be time consuming, and time management is critical in software development. 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 excessively spending a lot of time and money.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T20:47:02Z

Adamssw: hey look it's not 4 yet. I should save it anyways, just incase the power goes out.

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

Users have complex and diverse needs and wants. Focus in interface design should remain on the people who will actually use the product as part of their work. A ''proxy'' user meant to represent the user base should not be used. A proxy user could easily include groups who have an interest in the software project, but do not actually use it. Examples of these people include systems administrators or managers who only need a minimal interaction with the system.
Their input rarely contains information relevant to end user experience since they do not have a first hand perspective, even though they might be paying for or distributing the software.

==== User Behaviour Modelling ====

The features provided by a piece of software are important to the customer, and how users interact with these features is important to the design of the interface. It should be modeled as closely as possible on the user's actual work environment, their behavior characteristics and the nature of the user's work.

Appropriate models that take these factors into account will provide interface designers with a framework that will allow for intelligent interface prototypes to be constructed. These prototypes can be quickly tested by real users and further refinements will quickly lead to an effective design.

==== Systematic Information Gathering and Analysis ====

Consistency is a desirable attribute in a software design, and a systematic approach should be taken during development to encourage 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.

=== Usability Experts ===

Experts in the field of usability are important contributors to 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 hierarchy. Usability experts work with designers, providing feedback as development occurs; they also interact with end users in ways that disambiguate their needs, resulting in feedback that is more useful 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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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. Non-user based tests are ''expert review, compliance reviews, heuristic evaluations,'' and ''cognitive walk-throughs''. These tests are based on the review of an ‘expert’ and check if the usability of the product satisfies certain criteria based on well-known principles. Examples of the criteria include Shneiderman’s 8 golden rules or Norman’s 4 principles of usability, but could include legal requirements for example. User-based testing can include surveys, performance metric evaluations, think-aloud protocol, or co-discovery learning among others. Centers such as IBM's User Centered Design Center in Markham, Ontario attempt to formalize this process to derive empirical rules of software interface design.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing serves two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s intuitions are not always correct
* There is no average user
* It is impossible to predict usability from appearance
* Design standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products built in pieces almost always have system-level inconsistencies
* Problems found late in the development cycle are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

While not an exhaustive list to justify testing, it highlights the key points made by Galitz. (Galitz 1997, p.592-593).

=== Analyze and Retest ===
The testing process should be cyclic. Once the first test has been performed, it is important to analyze the data and establish benchmarks for further testing. Fixing old problems produces new problems. Once problems have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. When the prototype is ready, it must be tested to gather more data, adjusting benchmarks and the prototype until involved parties are satisfied. This is a main component of iterative design and makes user centered design much simpler to incorporate.

=== Limitations ===

Although empirical testing can solve many design problems, it has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 only accounts for hours of use, subtle or unusual problems may not be revealed in this environment. Even with these limitations, Rubin and Chisnell (Handbook of Usability Testing 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

In the design of a user interface, it is not possible to obtain an interface free from 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 new products in general, and can be applied to software easily. Iterations are used to improve the interface by collecting user feedback from a prototype of the interface. Usability issues raised can be corrected in the creation of a new prototype, which is then evaluated.

The steps in an iteration should be:
* Prepare a prototype design
* Present this design to a set of potential users
* Collect potential problems, as reported by users
* Refine design based on user input

Iterative design is purely about refinement; each iteration brings improvements to the whole project by solving usability issues. This method puts user assessed quality at the centre of the development process.

Development of a good user interface is the result of understanding user's needs and behavior. It is hard for an interface designer to obtain a perfect understanding of user's goals and the iterative design method allows them to base their work on user feedback. Thus, usability issues will be minimized.

=== Benefits ===

Some advantages of iterative design are:
* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most usability issues will be solved: less post release patches and upgrades
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations
* Better knowledge about the current project status: good visibility of the project advancements
* Provides a history of mistakes made to help with future projects

=== Disadvantages ===

One of the problem of iterative design is it's cost, if you exaggerate the number of iterations. Indeed, each iteration can be time consuming, and time management is critical in software development. 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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T20:35:15Z

Adamssw: frequently saving your work prevents losses due to malfunction and reduces excess frustration

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

Users have complex and diverse needs and wants. Focus in interface design should remain on the people who will actually use the product as part of their work. A ''proxy'' user meant to represent the user base should not be used. A proxy user could easily include groups who have an interest in the software project, but do not actually use it. Examples of these people include systems administrators or managers who only need a minimal interaction with the system.
Their input rarely contains information relevant to end user experience since they do not have a first hand perspective, even though they might be paying for or distributing the software.

==== User Behaviour Modelling ====

The features provided by a piece of software are important to the customer, and how users interact with these features is important to the design of the interface. It should be modeled as closely as possible on the user's actual work environment, their behavior characteristics and the nature of the user's work.

Appropriate models that take these factors into account will provide interface designers with a framework that will allow for intelligent interface prototypes to be constructed. These prototypes can be quickly tested by real users and further refinements will quickly lead to an effective design.

==== Systematic Information Gathering and Analysis ====

Consistency is a desirable attribute in a software design, and a systematic approach should be taken during development to encourage 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.

=== Usability Experts ===

Experts in the field of usability are important contributors to 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 hierarchy. Usability experts work with designers, providing feedback as development occurs; they also interact with end users in ways that disambiguate their needs, resulting in feedback that is more useful 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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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. Non-user based tests are ''expert review, compliance reviews, heuristic evaluations,'' and ''cognitive walk-throughs''. These tests are based on the review of an ‘expert’ and check if the usability of the product satisfies certain criteria based on well-known principles. Examples of the criteria include Shneiderman’s 8 golden rules or Norman’s 4 principles of usability, but could include legal requirements for example. User-based testing can include surveys, performance metric evaluations, think-aloud protocol, or co-discovery learning among others. Centers such as IBM's User Centered Design Center in Markham, Ontario attempt to formalize this process to derive empirical rules of software interface design.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing serves two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s intuitions are not always correct
* There is no average user
* It is impossible to predict usability from appearance
* Design standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products built in pieces almost always have system-level inconsistencies
* Problems found late in the development cycle are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

While not an exhaustive list to justify testing, it highlights the key points made by Galitz. (Galitz 1997, p.592-593).

=== Analyze and Retest ===
The testing process should be cyclic. Once the first test has been performed, it is important to analyze the data and establish benchmarks for further testing. Fixing old problems produces new problems. Once problems have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. When the prototype is ready, it must be tested to gather more data, adjusting benchmarks and the prototype until involved parties are satisfied. This is a main component of iterative design and makes user centered design much simpler to incorporate.

=== Limitations ===

Although empirical testing can solve many design problems, it has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 only accounts for hours of use, subtle or unusual problems may not be revealed in this environment. Even with these limitations, Rubin and Chisnell (Handbook of Usability Testing 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

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:

* Prepare a prototype design of the product
* Present this design to a set of potential users
* Collect problems noticed by users
* Refine design based on users point of view

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.

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.

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.

=== Benefits ===

Advantages related to iterative design are numerous.

* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.
* Better knowledge about the current project status: good visibility of the project advancements
* Keep an history of mistakes done in the past to do better on future projects

=== Disadvantages ===

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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T20:25:02Z

Adamssw: fixed spelling erors, editing continued

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

Users have complex and diverse needs and wants. Focus in interface design should remain on the people who will actually use the product as part of their work. A ''proxy'' user meant to represent the user base should not be used. A proxy user could easily include groups who have an interest in the software project, but do not actually use it. Examples of these people include systems administrators or managers who only need a minimal interaction with the system.
Their input rarely contains information relevant to end user experience since they do not have a first hand perspective, even though they might be paying for or distributing the software.

==== User Behaviour Modelling ====

The features provided by a piece of software are important to the customer, and how users interact with these features is important to the design of the interface. It should be modeled as closely as possible on the user's actual work environment, their behavior characteristics and the nature of the user's work.

Appropriate models that take these factors into account will provide interface designers with a framework that will allow for intelligent interface prototypes to be constructed. These prototypes can be quickly tested by real users and further refinements will quickly lead to an effective design.

==== Systematic Information Gathering and Analysis ====

Consistency is a desirable attribute in a software design, and a systematic approach should be taken during development to encourage 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.

=== Usability Experts ===

Experts in the field of usability are important contributors to 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 hierarchy. Usability experts work with designers, providing feedback as development occurs; they also interact with end users in ways that disambiguate their needs, resulting in feedback that is more useful 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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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. Non-user based tests are ''expert review, compliance reviews, heuristic evaluations,'' and ''cognitive walk-throughs''. These tests are based on the review of an ‘expert’ and check if the usability of the product satisfies certain criteria based on well-known principles. Examples of the criteria include Shneiderman’s 8 golden rules or Norman’s 4 principles of usability, but could include legal requirements for example. User-based testing can include surveys, performance metric evaluations, think-aloud protocol, or co-discovery learning among others. Centers such as IBM's User Centered Design Center in Markham, Ontario attempt to formalize this process to derive empirical rules of software interface design.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing is believed to serve two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s Intuitions are not always correct
* There is no average user
* It’s impossible to predict usability from appearance
* Design Standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products build in pieces almost always have system-level inconsistencies
* Problems found late are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

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).

=== Analyze and Retest ===
Once the first test has been done, it is now important to analyze the data and establish benchmarks for further testing. Problems will be discovered and once they have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. Once the prototype is ready, another test can be done to gather more data and once again adjust benchmarks and the prototype until designers are satisfied. This is a main component of iterative design.

=== Limitations ===

Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

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:

* Prepare a prototype design of the product
* Present this design to a set of potential users
* Collect problems noticed by users
* Refine design based on users point of view

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.

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.

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.

=== Benefits ===

Advantages related to iterative design are numerous.

* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.
* Better knowledge about the current project status: good visibility of the project advancements
* Keep an history of mistakes done in the past to do better on future projects

=== Disadvantages ===

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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T20:13:01Z

Adamssw: edited user behaviour modelling

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

Users have complex and diverse needs and wants. Focus in interface design should remain on the people who will actually use the product as part of their work. A ''proxy'' user meant to represent the user base should not be used. A proxy user could easily include groups who have an interest in the software project, but do not actually use it. Examples of these people include systems administrators or managers who only need a minimal interaction with the system.
Their input rarely contains information relevant to end user experience since they do not have a first hand perspective, even though they might be paying for or distributing the software.

==== User Behaviour Modelling ====

The features provided by a piece of software are important to the customer, and how users interact with these features is important to the design of the interface. It should be modeled as closely as possible on the user's actual work environment, their behavior characteristics and the nature of the user's work.

Appropriate models that take these factors into account will provide interface designers with a framework that will allow for intelligent interface prototypes to be constructed. These prototypes can be quickly tested by real users and further refinements will quickly lead to an effective design.

==== Systematic Information Gathering and Analysis ====

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.

=== Usability Experts ===

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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing is believed to serve two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s Intuitions are not always correct
* There is no average user
* It’s impossible to predict usability from appearance
* Design Standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products build in pieces almost always have system-level inconsistencies
* Problems found late are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

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).

=== Analyze and Retest ===
Once the first test has been done, it is now important to analyze the data and establish benchmarks for further testing. Problems will be discovered and once they have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. Once the prototype is ready, another test can be done to gather more data and once again adjust benchmarks and the prototype until designers are satisfied. This is a main component of iterative design.

=== Limitations ===

Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

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:

* Prepare a prototype design of the product
* Present this design to a set of potential users
* Collect problems noticed by users
* Refine design based on users point of view

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.

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.

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.

=== Benefits ===

Advantages related to iterative design are numerous.

* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.
* Better knowledge about the current project status: good visibility of the project advancements
* Keep an history of mistakes done in the past to do better on future projects

=== Disadvantages ===

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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T20:06:14Z

Adamssw: edited methods of focus/end user input section

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

Users have complex and diverse needs and wants. Focus in interface design should remain on the people who will actually use the product as part of their work. A ''proxy'' user meant to represent the user base should not be used. A proxy user could easily include groups who have an interest in the software project, but do not actually use it. Examples of these people include systems administrators or managers who only need a minimal interaction with the system.
Their input rarely contains information relevant to end user experience since they do not have a first hand perspective, even though they might be paying for or distributing the software.

==== User Behaviour Modelling ====

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.

==== Systematic Information Gathering and Analysis ====

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.

=== Usability Experts ===

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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing is believed to serve two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s Intuitions are not always correct
* There is no average user
* It’s impossible to predict usability from appearance
* Design Standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products build in pieces almost always have system-level inconsistencies
* Problems found late are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

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).

=== Analyze and Retest ===
Once the first test has been done, it is now important to analyze the data and establish benchmarks for further testing. Problems will be discovered and once they have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. Once the prototype is ready, another test can be done to gather more data and once again adjust benchmarks and the prototype until designers are satisfied. This is a main component of iterative design.

=== Limitations ===

Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

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:

* Prepare a prototype design of the product
* Present this design to a set of potential users
* Collect problems noticed by users
* Refine design based on users point of view

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.

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.

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.

=== Benefits ===

Advantages related to iterative design are numerous.

* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.
* Better knowledge about the current project status: good visibility of the project advancements
* Keep an history of mistakes done in the past to do better on future projects

=== Disadvantages ===

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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T19:58:51Z

Adamssw: created introduction

User centered development is a process in which the motivators ('''''end users''''') of a software project play a central role in the development decisions of the project. The end users will normally play a key role in interface design and provide a reliable testing group for evaluating functionality. This differs from traditional software design methods in which requirements are gathered early in the process and then software is built from completed requirements documents with minimal end user input. Correctness is determined by comparison to the requirements which may have been incorrect or incomplete.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

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 "proxy" user meant to represent the user base as a whole. A "proxy" 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.

==== User Behaviour Modelling ====

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.

==== Systematic Information Gathering and Analysis ====

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.

=== Usability Experts ===

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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing is believed to serve two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s Intuitions are not always correct
* There is no average user
* It’s impossible to predict usability from appearance
* Design Standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products build in pieces almost always have system-level inconsistencies
* Problems found late are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

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).

=== Analyze and Retest ===
Once the first test has been done, it is now important to analyze the data and establish benchmarks for further testing. Problems will be discovered and once they have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. Once the prototype is ready, another test can be done to gather more data and once again adjust benchmarks and the prototype until designers are satisfied. This is a main component of iterative design.

=== Limitations ===

Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

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:

* Prepare a prototype design of the product
* Present this design to a set of potential users
* Collect problems noticed by users
* Refine design based on users point of view

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.

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.

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.

=== Benefits ===

Advantages related to iterative design are numerous.

* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.
* Better knowledge about the current project status: good visibility of the project advancements
* Keep an history of mistakes done in the past to do better on future projects

=== Disadvantages ===

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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Process for User-centered Development

2009-11-23T19:51:33Z

Adamssw: edited need for user input section

Write introduction here.

== Early Focus on Users ==

=== The Need for User Input ===

The objectives of end users must be of paramount importance to software developers, as the purpose of developing software is to accomplish the end user's objectives. User objectives should be ascertained and analyzed in the earliest stages of the software development cycle. From this user-centered perspective, developers can maximize avoiding time wasting diversions that do not provide users with more desired functionality.

Early user input will bring focus to the project, and keeping users informed of modifications and additions throughout the software development cycle will help retain that focus. Users help developers keep to their original intentions and developers remain focused on the desired feature set. Problems that arise can be solved with the end user's awareness of the state of the project and more awareness of the impact of their decisions on functionality, budgets and timelines.

=== Methods of Focus ===

==== End User Input ====

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 "proxy" user meant to represent the user base as a whole. A "proxy" 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.

==== User Behaviour Modelling ====

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.

==== Systematic Information Gathering and Analysis ====

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.

=== Usability Experts ===

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.

== Empirical Testing ==

Empirical testing of the user-centered development consists mainly of usability testing with tests that can be quantitatively measured, 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.
=== User-based Tests ===

'''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.

'''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.

'''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.

'''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.

=== Purpose of Testing ===
Testing is believed to serve two main purposes. According to Galitz(Galitz 1997, p. 592):
*First, it establishes a communication bridge between developers and users. Through testing, the developer learns about the user’s goals, perceptions, questions and problems. Through testing, the user is exposed to the capabilities of the system early on, before design is solidified.
*Second, testing is used to evaluate a product. It can identify potential problems in design at a point in the development process where they can be more easily addressed. Testing also enables comparison of alternative versions of a design element, when a clear direction is not immediately evident. How well the interface and screens meets user needs and expectations can also be assessed.

The second purpose of testing mentions enabling a comparison of alternative versions of design. This is mainly what the empirical method is based on in user-centered design, the ability to gather and compare quantifiable data.

=== Key Reasons to Test ===
* Developers and users possess different models
* Developer’s Intuitions are not always correct
* There is no average user
* It’s impossible to predict usability from appearance
* Design Standards and guidelines are not sufficient
* Informal feedback is inadequate
* Products build in pieces almost always have system-level inconsistencies
* Problems found late are more difficult and expensive to fix
* Problems fixed during development mean reduced support costs later
* Advantages over a competitive product can be achieved

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).

=== Analyze and Retest ===
Once the first test has been done, it is now important to analyze the data and establish benchmarks for further testing. Problems will be discovered and once they have been resolved to the satisfaction of the designers, the prototype must be changed to reflect this resolution. Once the prototype is ready, another test can be done to gather more data and once again adjust benchmarks and the prototype until designers are satisfied. This is a main component of iterative design.

=== Limitations ===

Although it seems empirical testing can solve many design problems, it should be noted that testing has its limitations. Rubin and Chisnell (Handbook of Usability Testing 2008, p.25-26), 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 2008, pg. 26) also note that used correctly, testing will almost always bring to light potential problems, when done carefully and correctly.

== Iterative Design ==

=== Introduction ===

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:

* Prepare a prototype design of the product
* Present this design to a set of potential users
* Collect problems noticed by users
* Refine design based on users point of view

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.

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.

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.

=== Benefits ===

Advantages related to iterative design are numerous.

* Inconsistencies around application design are detected earlier than with a traditional development method.
* Most of the usability issues will be solved: we don't have to patch the application, we release directly a perfectly adapted product.
* Better understanding of users needs
* Testing phase is easier to plan as the testing team will proceed by iterations: iterative design fits perfectly with AGILE development methods.
* Better knowledge about the current project status: good visibility of the project advancements
* Keep an history of mistakes done in the past to do better on future projects

=== Disadvantages ===

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.

== References ==
* [http://xml.coverpages.org/NunoWisdomThesis.pdf Object Modelling for User Centered Development and User Interface Design: The Wisdom Approach]

* [http://www.mii.lt/files/InMaDra/5-User-Centered-Design.pdf User Centered Design and Development]

* [http://www.w3.org/WAI/redesign/ucd Notes on User Centered Design Process (UCD)]

* [http://www.sapdesignguild.org/resources/ucd_paper.asp User Centered Design]

* [http://en.wikipedia.org/wiki/Iterative_design Iterative Design (Wikipedia)]

* [http://www.useit.com/papers/iterative_design/ Iterative Design by Jakob Nielsen]

* Galitz, W (1997). ''The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques'', Wiley Publishing.

* Chisnell and Rubin (2008). ''Handbook of Usability Testing, Second Edition: How to Plan, Design, and Conduct Effective Tests'', Wiley Publishing.

* Hix and Hartson (1993). ''Developing User Interfaces: Ensuring Usability Through Product & Process'', Wiley Publishing.

Cell BE - A Network on a Chip

2009-04-13T03:34:37Z

Adamssw:

[[Image:Cell-Processor.jpg|thumb|750px|The Cell BE Microprocessor.]]
[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>].

The ''Cell Broadband Engine'' ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Cell BE Architecture ==
Information in this section is taken information distributed in the IBM Cell BE SDK and available from <nowiki>[2]</nowiki>.

The Cell BE is a [[http://en.wikipedia.org/wiki/SIMD SIMD]] architecture which operates as a network on a chip. The individual elements communicate with one another exclusively over a interconnect network which operates in a manner comparable to a [http://en.wikipedia.org/wiki/Token_ring_network token ring network]. The elements operate by sending device service requests and responses to one another.

[[Image:Cell-Architecture.jpg|thumb|750px|The Cell BE Microprocessor.]]
=== Processors ===
The Cell BE is comprised on 2 primary processor types; 1 Power PC Element and 8 Synergistic Processing Elements.

==== Power PC Element ====
The ''Power PC Element'' ('''PPE''') is a 64 bit processor responsible for running operating system functions. The PPE controls thread level parallelism, and acts as a controller for the ''Synergistic Processing Elements'' ('''SPE'''s). It supports vectorized single precision floating point operations, and IBM's quad-precision (long double) floating point format. The PPE is responsible for memory address translations between the SPEs and main memory.

==== Synergistic Processing Element ====
The ''Synergistic Processing Element'' ('''SPE''') is the main computational engine for the Cell BE. The SPE is highly optimized for floating point operations. The SPEs are capable of performing a single memory instruction and a single data operation every cycle. It is important to remember that the SPE cannot directly access main memory and must request data by a request through the PPE due to memory address translations. The SPE contains 256kB of local store memory where a '''copy''' of the data is kept. This local store is not accessible by elements other than the SPE it resides on. The implication of this configuration is that once sufficient data is queued, computation can begin in step with memory transfers. Although there is an initial penalty it is quickly overcome for computations on large data sets. It is also the programmer's responsibility to ensure data synchronization is handled appropriately. Each SPE may initiate up to 16 memory requests (inbound or outbound data movement) simultaneously.

=== Controllers ===
==== Element Interconnect Bus ====
The ''Element Interconnect Bus'' ('''EIB''') connects the various elements of the Cell BE to one another. It operates in a manner similar to a high bandwidth token ring network. Communication between elements is performed in packets of 16B, each element potentially receiving 1 packet each cycle.

==== Memory Interconnect Controller ====
The ''Memory Interconnect Controller'' ('''MIC''') interfaces directly with the main memory of the system. It receives memory access requests from the PPE and SPEs via the EIB and returns data to the processors in packets via the EIB.

==== Bus Interface Controller ====
The ''Bus Interface Controller'' ('''BIC''') is a configurable network interface. It is a Rambus FlexIO card that treats the EIB as a transport layer of a network. It has 2 physical interfaces to the EIB and maps those interfaces to a physical network connection. A common use of this interface is to pair with another Cell BE, thus creating a network of 2 PPEs and 16 SPEs. Memory address translation is handled by the BIC allowing processors on one physical chip to make a memory request to the MIC of the second physical chip. In super-computer systems, this interface is usually connected to a backbone which in turn manages clusters of Cell BEs.

== Network on a Chip ==
Traditional chip design (system on a chip) has focused on overcoming the [[http://en.wikipedia.org/wiki/Memory_wall#Memory_wall memory]], heat dissipation issues and other physical limitations. As multi-core approaches have gained in popularity, communication complexity has necessarily increased, occupying more of the available resources. Additionally power consumption versus performance is becoming increasingly important both for commercial and environmental reasons. Network on a chip is a design approach that attempts to avoid complicated communication scenarios by drawing on existing network structures and theories. One key feature of this simplification is that dedicated interconnect buses (such as a memory bus) are removed in favour of a generalized communication channel. Component designs are only restricted in that they must have an interface to the communication channel. Specific network topologies and protocols can be applied to particular chip designs with a well established knowledge of the advantages and limitations.
=== Single Cell BE Example ===
''Scenario:'' 1 PPE, 8 SPE configuration, operating system loaded and running on multiple threads on the PPE.

User program is started on a thread by the PPE.
The user program sets up initial values (stored in the PPE registers) which are then send to memory over the EIB.
The user program initializes threads to start computational programs on the SPEs. Note, there is no requirement that all SPEs run the same program.
I/O requests are sent over the EIB to the SPEs, transferring the executable code, which then begins to execute.
SPEs begin to make memory requests to the PPE, which are translated and retransmitted to the memory controller.
The MIC initiates a memory transfer to the requesting SPE.
The SPE begins computation on the received data.
If an SPE needs data that is on another SPE, a SPE to SPE memory transfer request can be initiated over the EIB.
If an SPE needs to send a mailbox message, an event signal or raise an interrupt on the PPE, it can initiate SPE->EIB->PPE messages.
As data completes, it can be transferred back to main memory from the SPE->EIB->PPE->EIB->MIC.

Clearly, the number of communication requests are quite high with 8 SPEs running in parallel. Traditional chip designs have excelled at creating pathways between components, here we would probably add pathways from memory to each SPE to facilitate movement. This would create a large number of pathways, especially when inter-SPE communications are allowed. By having a general channel this complication is removed. Also, suppose a single SPE is performing a low computational cost, data intensive operation. Suppose also that the other SPEs are either idle, or performing high computational cost, low data access operations. In the SOC design, many pathways are inactive. In the NOC design, the single SPE is able to take advantage of the extra bandwidth access.

=== Dual Cell BE Example ===
''Scenario:'' 2 Single Cell BE chips, communicating over the BIC on a common, problem with a large data set (such as a hydrodynamic simulation)
Assume that each of the Cell BE chips is operating in a manner described in the previous example.
An SPE on the first Cell chip issues a memory request for a block of memory connected to the second Cell chip via the EIB to the PPE on the first chip.
The PPE performs a memory address translation and recognizes it is a network resource, it then issues a network memory request PPE->EIB->BIC.
The request follows BIC1->BIC2->EIB->MIC to the second Cell chip. The data now returns via MIC->EIB->BIC2->BIC1->EIB->SPE.
It is possible for SPEs on one Cell in this configuration to make messages to the PPE or SPEs on the other Cell in a similar fashion.

Here we see that the architecture is scalable. The penalty associated with the communication BIC1->BIC2 has no impact on system performance as the BIC is faster than the EIB.

=== Cluster Configuration Example ===
''Scenario:'' Many Cell BE chips connected over an external backbone to one another via their respective BICs.

In this scenario, everything stated about the Dual Cell BE example applies. There is additional complexity and the backbone usually uses it's own processor to provide network address translations, or implement a higher level communication protocol. Additionally the backbone speed needs to be sufficient that requests from the extreme ends of the network continues to exceed the speed of the EIB.

This configuration is similar to the one that was used to create ''IBM<nowiki>'</nowiki>Roadrunner''. Roadrunner is listed in the #1 spot on the LINPACK [http://www.top500.org/lists/2008/11 TOP500] list, and the first to run with a sustained speed in excess of a petaflop<nowiki>[3]</nowiki>.

=== Network Security Implementation ===
The ''PlayStation 3'' ('''PS3''') was designed to use a Cell processor. The design reserves 2 SPEs as private; one is disabled to increase production yields and the other is reserved for the PS3 operating system. The decision to reserve a SPE for the operating system was largely for system security. In the PS2, users were able to create illegal copies of software and bypass the built in copy protection mechanisms by installing their own processor, a [[http://en.wikipedia.org/wiki/Mod_chip mod chip]]. The PS3's reserved security SPE can be seen as a network security device, that monitors the integrity of the system.

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

<nowiki>[2]</nowiki>http://www.research.ibm.com/people/m/mikeg/papers/2006_ieeemicro.pdf

<nowiki>[3]</nowiki>http://www.lanl.gov/roadrunner/
== See Also ==
[[http://en.wikipedia.org/wiki/Playstation_3#Hardware PlayStation 3]]

[[http://en.wikipedia.org/wiki/IBM_Roadrunner Roadrunner]]

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]
* [http://www.ibm.com/developerworks/power/cell/ IBM developerWorks Cell Broadband Engine Resource Center]
* [http://www.us.playstation.com/ PlayStation 3 Home]

----

--[[User:Adamssw|Adamssw]] 23:34, 12 April 2009 (EDT)

Cell BE - A Network on a Chip

2009-04-13T03:33:59Z

Adamssw:

Cell BE - A Network on a Chip

2009-04-13T03:27:37Z

Adamssw:

[[Image:Cell-Processor.jpg|thumb|750px|The Cell BE Microprocessor.]]
[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>].

The ''Cell Broadband Engine'' ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Cell BE Architecture ==
Information in this section is taken information distributed in the IBM Cell BE SDK and available from <nowiki>[2]</nowiki>.

The Cell BE is a [[http://en.wikipedia.org/wiki/SIMD SIMD]] architecture which operates as a network on a chip. The individual elements communicate with one another exclusively over a interconnect network which operates in a manner comparable to a [http://en.wikipedia.org/wiki/Token_ring_network token ring network]. The elements operate by sending device service requests and responses to one another.

[[Image:Cell-Architecture.jpg|thumb|750px|The Cell BE Microprocessor.]]
=== Processors ===
The Cell BE is comprised on 2 primary processor types; 1 Power PC Element and 8 Synergistic Processing Elements.

==== Power PC Element ====
The ''Power PC Element'' ('''PPE''') is a 64 bit processor responsible for running operating system functions. The PPE controls thread level parallelism, and acts as a controller for the ''Synergistic Processing Elements'' ('''SPE'''s). It supports vectorized single precision floating point operations, and IBM's quad-precision (long double) floating point format. The PPE is responsible for memory address translations between the SPEs and main memory.

==== Synergistic Processing Element ====
The ''Synergistic Processing Element'' ('''SPE''') is the main computational engine for the Cell BE. The SPE is highly optimized for floating point operations. The SPEs are capable of performing a single memory instruction and a single data operation every cycle. It is important to remember that the SPE cannot directly access main memory and must request data by a request through the PPE due to memory address translations. The SPE contains 256kB of local store memory where a '''copy''' of the data is kept. This local store is not accessible by elements other than the SPE it resides on. The implication of this configuration is that once sufficient data is queued, computation can begin in step with memory transfers. Although there is an initial penalty it is quickly overcome for computations on large data sets. It is also the programmer's responsibility to ensure data synchronization is handled appropriately. Each SPE may initiate up to 16 memory requests (inbound or outbound data movement) simultaneously.

=== Controllers ===
==== Element Interconnect Bus ====
The ''Element Interconnect Bus'' ('''EIB''') connects the various elements of the Cell BE to one another. It operates in a manner similar to a high bandwidth token ring network. Communication between elements is performed in packets of 16B, each element potentially receiving 1 packet each cycle.

==== Memory Interconnect Controller ====
The ''Memory Interconnect Controller'' ('''MIC''') interfaces directly with the main memory of the system. It receives memory access requests from the PPE and SPEs via the EIB and returns data to the processors in packets via the EIB.

==== Bus Interface Controller ====
The ''Bus Interface Controller'' ('''BIC''') is a configurable network interface. It is a Rambus FlexIO card that treats the EIB as a transport layer of a network. It has 2 physical interfaces to the EIB and maps those interfaces to a physical network connection. A common use of this interface is to pair with another Cell BE, thus creating a network of 2 PPEs and 16 SPEs. Memory address translation is handled by the BIC allowing processors on one physical chip to make a memory request to the MIC of the second physical chip. In super-computer systems, this interface is usually connected to a backbone which in turn manages clusters of Cell BEs.

== Network on a Chip ==
Traditional chip design (system on a chip) has focused on overcoming the [[http://en.wikipedia.org/wiki/Memory_wall#Memory_wall memory]], heat dissipation issues and other physical limitations. As multi-core approaches have gained in popularity, communication complexity has necessarily increased, occupying more of the available resources. Additionally power consumption versus performance is becoming increasingly important both for commercial and environmental reasons. Network on a chip is a design approach that attempts to avoid complicated communication scenarios by drawing on existing network structures and theories. One key feature of this simplification is that dedicated interconnect buses (such as a memory bus) are removed in favour of a generalized communication channel. Component designs are only restricted in that they must have an interface to the communication channel. Specific network topologies and protocols can be applied to particular chip designs with a well established knowledge of the advantages and limitations.
=== Single Cell BE Example ===
''Scenario:'' 1 PPE, 8 SPE configuration, operating system loaded and running on multiple threads on the PPE.

User program is started on a thread by the PPE.
The user program sets up initial values (stored in the PPE registers) which are then send to memory over the EIB.
The user program initializes threads to start computational programs on the SPEs. Note, there is no requirement that all SPEs run the same program.
I/O requests are sent over the EIB to the SPEs, transferring the executable code, which then begins to execute.
SPEs begin to make memory requests to the PPE, which are translated and retransmitted to the memory controller.
The MIC initiates a memory transfer to the requesting SPE.
The SPE begins computation on the received data.
If an SPE needs data that is on another SPE, a SPE to SPE memory transfer request can be initiated over the EIB.
If an SPE needs to send a mailbox message, an event signal or raise an interrupt on the PPE, it can initiate SPE->EIB->PPE messages.
As data completes, it can be transferred back to main memory from the SPE->EIB->PPE->EIB->MIC.

Clearly, the number of communication requests are quite high with 8 SPEs running in parallel. Traditional chip designs have excelled at creating pathways between components, here we would probably add pathways from memory to each SPE to facilitate movement. This would create a large number of pathways, especially when inter-SPE communications are allowed. By having a general channel this complication is removed. Also, suppose a single SPE is performing a low computational cost, data intensive operation. Suppose also that the other SPEs are either idle, or performing high computational cost, low data access operations. In the SOC design, many pathways are inactive. In the NOC design, the single SPE is able to take advantage of the extra bandwidth access.

=== Dual Cell BE Example ===
''Scenario:'' 2 Single Cell BE chips, communicating over the BIC on a common, problem with a large data set (such as a hydrodynamic simulation)
Assume that each of the Cell BE chips is operating in a manner described in the previous example.
An SPE on the first Cell chip issues a memory request for a block of memory connected to the second Cell chip via the EIB to the PPE on the first chip.
The PPE performs a memory address translation and recognizes it is a network resource, it then issues a network memory request PPE->EIB->BIC.
The request follows BIC1->BIC2->EIB->MIC to the second Cell chip. The data now returns via MIC->EIB->BIC2->BIC1->EIB->SPE.
It is possible for SPEs on one Cell in this configuration to make messages to the PPE or SPEs on the other Cell in a similar fashion.

Here we see that the architecture is scalable. The penalty associated with the communication BIC1->BIC2 has no impact on system performance as the BIC is faster than the EIB.

=== Cluster Configuration Example ===
''Scenario:'' Many Cell BE chips connected over an external backbone to one another via their respective BICs.

In this scenario, everything stated about the Dual Cell BE example applies. There is additional complexity and the backbone usually uses it's own processor to provide network address translations, or implement a higher level communication protocol. Additionally the backbone speed needs to be sufficient that requests from the extreme ends of the network continues to exceed the speed of the EIB.

=== Network Security Implementation ===
The ''PlayStation 3'' ('''PS3''') was designed to use a Cell processor. The design reserves 2 SPEs as private; one is disabled to increase production yields and the other is reserved for the PS3 operating system. The decision to reserve a SPE for the operating system was largely for system security. In the PS2, users were able to create illegal copies of software and bypass the built in copy protection mechanisms by installing their own processor, a [[http://en.wikipedia.org/wiki/Mod_chip mod chip]]. The PS3's reserved security SPE can be seen as a network security device, that monitors the integrity of the system.

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

<nowiki>[2]</nowiki>http://www.research.ibm.com/people/m/mikeg/papers/2006_ieeemicro.pdf

== See Also ==
[[http://en.wikipedia.org/wiki/Playstation_3#Hardware PlayStation 3]]

[[http://en.wikipedia.org/wiki/IBM_Roadrunner Roadrunner]]

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]
* [http://www.ibm.com/developerworks/power/cell/ IBM developerWorks Cell Broadband Engine Resource Center]
* [http://www.us.playstation.com/ PlayStation 3 Home]

----

--[[User:Adamssw|Adamssw]] 23:27, 12 April 2009 (EDT)

Cell BE - A Network on a Chip

2009-04-13T03:25:30Z

Adamssw:

[[Image:Cell-Processor.jpg|thumb|750px|The Cell BE Microprocessor.]]
[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>].

The ''Cell Broadband Engine'' ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Cell BE Architecture ==
Information in this section is taken information distributed in the IBM Cell BE SDK and available from <nowiki>[2]</nowiki>.

The Cell BE is a [[http://en.wikipedia.org/wiki/SIMD SIMD]] architecture which operates as a network on a chip. The individual elements communicate with one another exclusively over a interconnect network which operates in a manner comparable to a [http://en.wikipedia.org/wiki/Token_ring_network token ring network]. The elements operate by sending device service requests and responses to one another.

[[Image:Cell-Architecture.jpg|thumb|750px|The Cell BE Microprocessor.]]
=== Processors ===
The Cell BE is comprised on 2 primary processor types; 1 Power PC Element and 8 Synergistic Processing Elements.

==== Power PC Element ====
The ''Power PC Element'' ('''PPE''') is a 64 bit processor responsible for running operating system functions. The PPE controls thread level parallelism, and acts as a controller for the ''Synergistic Processing Elements'' ('''SPE'''s). It supports vectorized single precision floating point operations, and IBM's quad-precision (long double) floating point format. The PPE is responsible for memory address translations between the SPEs and main memory.

==== Synergistic Processing Element ====
The ''Synergistic Processing Element'' ('''SPE''') is the main computational engine for the Cell BE. The SPE is highly optimized for floating point operations. The SPEs are capable of performing a single memory instruction and a single data operation every cycle. It is important to remember that the SPE cannot directly access main memory and must request data by a request through the PPE due to memory address translations. The SPE contains 256kB of local store memory where a '''copy''' of the data is kept. This local store is not accessible by elements other than the SPE it resides on. The implication of this configuration is that once sufficient data is queued, computation can begin in step with memory transfers. Although there is an initial penalty it is quickly overcome for computations on large data sets. It is also the programmer's responsibility to ensure data synchronization is handled appropriately. Each SPE may initiate up to 16 memory requests (inbound or outbound data movement) simultaneously.

=== Controllers ===
==== Element Interconnect Bus ====
The ''Element Interconnect Bus'' ('''EIB''') connects the various elements of the Cell BE to one another. It operates in a manner similar to a high bandwidth token ring network. Communication between elements is performed in packets of 16B, each element potentially receiving 1 packet each cycle.

==== Memory Interconnect Controller ====
The ''Memory Interconnect Controller'' ('''MIC''') interfaces directly with the main memory of the system. It receives memory access requests from the PPE and SPEs via the EIB and returns data to the processors in packets via the EIB.

==== Bus Interface Controller ====
The ''Bus Interface Controller'' ('''BIC''') is a configurable network interface. It is a Rambus FlexIO card that treats the EIB as a transport layer of a network. It has 2 physical interfaces to the EIB and maps those interfaces to a physical network connection. A common use of this interface is to pair with another Cell BE, thus creating a network of 2 PPEs and 16 SPEs. Memory address translation is handled by the BIC allowing processors on one physical chip to make a memory request to the MIC of the second physical chip. In super-computer systems, this interface is usually connected to a backbone which in turn manages clusters of Cell BEs.

== Network on a Chip ==
Traditional chip design (system on a chip) has focused on overcoming the [[http://en.wikipedia.org/wiki/Memory_wall#Memory_wall memory]], heat dissipation issues and other physical limitations. As multi-core approaches have gained in popularity, communication complexity has necessarily increased, occupying more of the available resources. Additionally power consumption versus performance is becoming increasingly important both for commercial and environmental reasons. Network on a chip is a design approach that attempts to avoid complicated communication scenarios by drawing on existing network structures and theories. One key feature of this simplification is that dedicated interconnect buses (such as a memory bus) are removed in favour of a generalized communication channel. Component designs are only restricted in that they must have an interface to the communication channel. Specific network topologies and protocols can be applied to particular chip designs with a well established knowledge of the advantages and limitations.
=== Single Cell BE Example ===
''Scenario:'' 1 PPE, 8 SPE configuration, operating system loaded and running on multiple threads on the PPE.

User program is started on a thread by the PPE.
The user program sets up initial values (stored in the PPE registers) which are then send to memory over the EIB.
The user program initializes threads to start computational programs on the SPEs. Note, there is no requirement that all SPEs run the same program.
I/O requests are sent over the EIB to the SPEs, transferring the executable code, which then begins to execute.
SPEs begin to make memory requests to the PPE, which are translated and retransmitted to the memory controller.
The MIC initiates a memory transfer to the requesting SPE.
The SPE begins computation on the received data.
If an SPE needs data that is on another SPE, a SPE to SPE memory transfer request can be initiated over the EIB.
If an SPE needs to send a mailbox message, an event signal or raise an interrupt on the PPE, it can initiate SPE->EIB->PPE messages.
As data completes, it can be transferred back to main memory from the SPE->EIB->PPE->EIB->MIC.

Clearly, the number of communication requests are quite high with 8 SPEs running in parallel. Traditional chip designs have excelled at creating pathways between components, here we would probably add pathways from memory to each SPE to facilitate movement. This would create a large number of pathways, especially when inter-SPE communications are allowed. By having a general channel this complication is removed. Also, suppose a single SPE is performing a low computational cost, data intensive operation. Suppose also that the other SPEs are either idle, or performing high computational cost, low data access operations. In the SOC design, many pathways are inactive. In the NOC design, the single SPE is able to take advantage of the extra bandwidth access.

=== Dual Cell BE Example ===
''Scenario:'' 2 Single Cell BE chips, communicating over the BIC on a common, problem with a large data set (such as a hydrodynamic simulation)
Assume that each of the Cell BE chips is operating in a manner described in the previous example.
An SPE on the first Cell chip issues a memory request for a block of memory connected to the second Cell chip via the EIB to the PPE on the first chip.
The PPE performs a memory address translation and recognizes it is a network resource, it then issues a network memory request PPE->EIB->BIC.
The request follows BIC1->BIC2->EIB->MIC to the second Cell chip. The data now returns via MIC->EIB->BIC2->BIC1->EIB->SPE.
It is possible for SPEs on one Cell in this configuration to make messages to the PPE or SPEs on the other Cell in a similar fashion.

Here we see that the architecture is scalable. The penalty associated with the communication BIC1->BIC2 has no impact on system performance as the BIC is faster than the EIB.

=== Cluster Configuration Example ===
''Scenario:'' Many Cell BE chips connected over an external backbone to one another via their respective BICs.

In this scenario, everything stated about the Dual Cell BE example applies. There is additional complexity and the backbone usually uses it's own processor to provide network address translations, or implement a higher level communication protocol. Additionally the backbone speed needs to be sufficient that requests from the extreme ends of the network continues to exceed the speed of the EIB.

=== Network Security Implementation ===
The ''PlayStation 3'' ('''PS3''') was designed to use a Cell processor. The design reserves 2 SPEs as private; one is disabled to increase production yields and the other is reserved for the PS3 operating system. The decision to reserve a SPE for the operating system was largely for system security. In the PS2, users were able to create illegal copies of software and bypass the built in copy protection mechanisms by installing their own processor, a [[http://en.wikipedia.org/wiki/Mod_chip mod chip]]. The PS3's reserved security SPE can be seen as a network security device, that monitors the integrity of the system.

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

<nowiki>[2]</nowiki>http://www.research.ibm.com/people/m/mikeg/papers/2006_ieeemicro.pdf

== See Also ==
[[http://en.wikipedia.org/wiki/Playstation_3#Hardware PlayStation 3]]

[[http://en.wikipedia.org/wiki/IBM_Roadrunner Roadrunner]]

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]
* [http://www.ibm.com/developerworks/power/cell/ IBM developerWorks Cell Broadband Engine Resource Center]

--[[User:Adamssw|Adamssw]] 19:36, 12 April 2009 (EDT)

Cell BE - A Network on a Chip

2009-04-13T02:08:56Z

Adamssw:

Cell BE - A Network on a Chip

2009-04-13T02:05:16Z

Adamssw:

Cell BE - A Network on a Chip

2009-04-13T01:38:10Z

Adamssw:

Cell BE - A Network on a Chip

2009-04-13T00:45:25Z

Adamssw:

Talk:Cell BE - A Network on a Chip

2009-04-13T00:30:09Z

Adamssw: Explanation of omission of technical details

--[[User:Adamssw|Adamssw]] 20:30, 12 April 2009 (EDT) Many technical details of the Cell BE were omitted because they did not clarify the idea of network on a chip

Cell BE - A Network on a Chip

2009-04-13T00:27:28Z

Adamssw: /* Processors */

Cell BE - A Network on a Chip

2009-04-12T23:36:51Z

Adamssw:

Cell BE - A Network on a Chip

2009-04-12T23:30:05Z

Adamssw:

[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>]

. The ''Cell Broadband Engine'' ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Hardware Layout ==

== Component Interaction ==

== Scalability ==
=== Roadrunner ===

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

== See Also ==

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]

--[[User:adamssw|adamssw]] 11:18 AM, 11 April 2009 (EDT)

Cell BE - A Network on a Chip

2009-04-12T23:28:16Z

Adamssw:

[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>]. The [http://en.wikipedia.org/wiki/Cell_(microprocessor) ''Cell Broadband Engine''] ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Hardware Layout ==
[[Image:ipn Cell-Processor.jpg|thumb|750px|The Cell BE Microprocessor]]

== Component Interaction ==

== Scalability ==
=== Roadrunner ===

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

== See Also ==

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]

--[[User:adamssw|adamssw]] 11:18 AM, 11 April 2009 (EDT)

File:Cell-Architecture.jpg

2009-04-12T23:27:13Z

Adamssw: This file is an original creation based on information from IBM's Cell Broadband Engine Interconnect and Memory Interface, 2005 retrieved from http://www.hotchips.org/archives/hc17/2_Mon/HC17.S1/HC17.S1T2.pdf

This file is an original creation based on information from IBM's Cell Broadband Engine Interconnect and Memory Interface, 2005 retrieved from http://www.hotchips.org/archives/hc17/2_Mon/HC17.S1/HC17.S1T2.pdf

Cell BE - A Network on a Chip

2009-04-12T22:27:50Z

Adamssw:

[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>]. The [http://en.wikipedia.org/wiki/Cell_(microprocessor) ''Cell Broadband Engine''] ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Hardware Layout ==
[[Image:Cell-Processor.jpg|thumb|750px|The Cell BE Microprocessor]]

== Component Interaction ==

== Scalability ==
=== Roadrunner ===

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

== See Also ==

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]

--[[User:adamssw|adamssw]] 11:18 AM, 11 April 2009 (EDT)

File:Cell-Processor.jpg

2009-04-12T22:26:40Z

Adamssw: A public domain image obtained from Wikipedia Commons

A public domain image obtained from Wikipedia Commons

Cell BE - A Network on a Chip

2009-04-12T22:26:04Z

Adamssw:

[http://en.wikipedia.org/wiki/Network_On_Chip ''Network on a chip''] ('''NOC''') is a paradigm in the design of parallel hardware architecture. It differs from [http://en.wikipedia.org/wiki/System-on-a-chip ''System on a chip''] ('''SOC''') by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics[http://en.wikipedia.org/wiki/Network_On_Chip <nowiki>[1]</nowiki>]. The [http://en.wikipedia.org/wiki/Cell_(microprocessor) ''Cell Broadband Engine''] ('''Cell BE''') is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Hardware Layout ==
[[Image:ipn Cell-Processor.jpg|thumb|750px|The Cell BE Microprocessor]]

== Component Interaction ==

== Scalability ==
=== Roadrunner ===

== References ==
<nowiki>[1]</nowiki>http://en.wikipedia.org/wiki/Network_On_Chip

== See Also ==

== External Links ==
* [http://en.wikipedia.org/wiki/System-on-a-chip System on a Chip Wikipedia Article]

--[[User:adamssw|adamssw]] 11:18 AM, 11 April 2009 (EDT)

Cell BE - A Network on a Chip

2009-04-12T20:19:57Z

Adamssw: digi sig

Network on a chip is a paradigm in the design of parallel hardware architecture. It differs from System on a chip (SOC) by featuring generic communication channels between processor elements instead of specialized buses to simplify chip design. Network on a chip systems have the ability to have processing elements operating on different data elements simultaneously without special framework. These characteristics allow better energy-performance characteristics. The Cell Broadband Engine (Cell BE) is a network on a chip design in production by Sony, Toshiba and IBM (STI). The Cell BE demonstrates these characteristics in a high performance, scalable production architecture.

== Hardware Layout ==

== Component Interaction ==

== Scalability ==

== References ==

== See Also ==

== External Links ==

--[[User:adamssw|adamssw]] 11:18 AM, 11 April 2009 (EDT)

Cell BE - A Network on a Chip

2009-04-12T20:18:23Z

Adamssw: establish basic layout

Cell BE

2009-04-06T00:09:49Z

Adamssw: Cell BE moved to Cell BE - A Network on a Chip: Clarify focus of page

#REDIRECT [[Cell BE - A Network on a Chip]]

Cell BE - A Network on a Chip

2009-04-06T00:09:49Z

Adamssw: Cell BE moved to Cell BE - A Network on a Chip: Clarify focus of page

placeholder text

Cell BE - A Network on a Chip

2009-04-05T22:44:51Z

Adamssw: page creation

placeholder text