CS295J/Final contributions - Revision history

Adam Darlow: added temporal patterns sub-project

2009-05-13T15:42:18Z

added temporal patterns sub-project

← Older revision		Revision as of 15:42, 13 May 2009
Line 323:		Line 323:
	*Output		*Output
	*The output of this module is a simple ratio of (affordances perceived) / [(relevant affordances present) (time to complete task)] which provides a quantitative measure of the extent to which the interface is "natural" to use for a particular task.		*The output of this module is a simple ratio of (affordances perceived) / [(relevant affordances present) (time to complete task)] which provides a quantitative measure of the extent to which the interface is "natural" to use for a particular task.

			== Temporal Patterns in Interface Interpretation ==

			* Owner: [[User:Adam Darlow \| Adam Darlow]]

			'''Aims'''
			* Identify the interface factors that enable users to generate a causal theory of an application's behavior and whether that theory will be mechanistic or intentional.
			* Apply cognitive theory of event perception to identify the cues by which users segment events under each of the overarching theories.
			* Use the above knowledge to evaluate and improve the intuitiveness and discoverability of application interfaces.


			'''Contributions'''
			* Formulations of temporal interaction ''design patterns'' for use by interface designers. For example, a design pattern for rigid physical link would state that it is a mechanistic relation between two interface items whereby when one item is moved by the user, the other item makes exactly the same movements in synchrony. It would also state how much movement is sufficient to generate the impression of the rigid link.
			* Implementation and evaluation of the addition of temporal patterns to an existing interface for more intuitive and dicoverable interactions.
			* Implementation of an interface evaluation module that measures the presence and consistency of temporal patterns in an interface.

			'''Demonstration'''
			* We will demonstrate significant improvements to the memorability and discoverability of functions in existing interfaces by adding temporal patterns to the interface interactions. We will show that these patterns affect how users conceptualize the application and how they interact with it.
			* We will demonstrate that the corresponding evaluation module can determine when an interface is lacking in temporal patterns or has temporal patterns that are inconsistent in terms of a mechanistic or intentional conceptualization of the application.

			'''Dependencies'''
			* Video capture of user interfaces synchronized with traces of the user interactions.
			* The parallel evaluation framework proposed elsewhere in this proposal.

			'''Background and Related Work'''
			* Increased computational power allows us to go beyond metaphors from the real world and use realistic dynamic interactions to make interfaces more intuitive. The naive approach to this has been to simulate a complete physical environment <ref> [http://portal.acm.org/citation.cfm?id=1124772.1124965 Keepin’ It Real: Pushing the Desktop Metaphor with Physics, Piles and the Pen] </ref>. While effective at making functionality more intuitive and discoverable, this approach has only been applied to file organization and it isn't clear how it generalizes to applications in general.
			* Research in cognitive science suggests a more sophisitcated approach. People automatically develop high level conceptualizations of a display based on certain low-level patterns of temporal dynamics <ref>[http://vrl.cs.brown.edu/wiki/Scholl-2000-PCA Perceptual causality and animacy] </ref>. Different patterns of interaction among elements suggest different causal or intentional interpretations. People use these interpretations when predicting how the system will behave. Therefore, having temporal dynamics based on a coherent conceptualization can make functions more intuitive, memorable and discoverable.
			* System conceptualization also influences how events in that system are segregated <ref> [http://www.michaelwmorris.com/UsefulPapers/ZacksTversky2001.pdf Event Structure in Perception and Conception] </ref>. The user will make different generalizations from an interaction event depending on whether it is perceived as a single complex event or a series of simpler ones. This affects the user's ability to remember the interaction and to discover other possible interactions.

			'''Significance'''
			* To the best of my knowledge, no existing research has studied the general application of temporal dynamics from the real world to human-computer interface design beyond systems that simulate a physical environment. This approach aims to extend the advantages of simulated physical environments to other real world metaphors in interface design.
			* One goal of this project is to open up a new field of research in the use of realistic temporal interactions to harness users' existing intuitions. Simulated physical environments <ref> [http://portal.acm.org/citation.cfm?id=1124772.1124965 Keepin’ It Real: Pushing the Desktop Metaphor with Physics, Piles and the Pen] </ref> use rich temporal interactions, but are limited to isolated projects because of the overhead in designing the system and the focus on the desktop metaphor. Other real world metaphors are ubiquitous in interface design <ref> [http://portal.acm.org/citation.cfm?doid=1188816.1188820 The reification of metaphor as a design tool] </ref> but don't take advantage of users' sensitivity to temporal dynamics. Our research aims to demonstrate that temporal dynamics can be applied to many interfaces with different metaphors.
			* Another goal of the project is to better understand how different conceptualizations of an application lead users to interact with it in different ways. For example, when thinking of what a function would be called, a user with a mechanistic conceptualization of the interface might look for something denoting the process of the function, while a user with an intentional conceptualization might look for something denoting the end result of the function. If both interface designers and interface users think about interfaces in terms of these (and other) high level conceptualizations, this can lead to more consistent, intuitive and enjoyable interfaces. The idea of application conceptualization is wide open for research. As useful as it is, the distinction between mechanical and intentional is only the tip of the iceberg.

Jon Ericson at 17:19, 1 May 2009

2009-05-01T17:19:21Z

← Older revision		Revision as of 17:19, 1 May 2009
Line 269:		Line 269:

	'''Dependencies'''		'''Dependencies'''
	*Requires a formal description of the interface with graph nodes representing clickable interface elements and graph edges representing the physical (on-screen) distance between adjacent nodes. <span style="color: gray;">[Is this graph format you're suggesting part of the proposal, or is the "language" itself a dependency from literature? [[User:E J Kalafarski\|E J Kalafarski]] 15:22, 29 April 2009 (UTC)]		*Requires a formal description of the interface with graph nodes representing clickable interface elements and graph edges representing the physical (on-screen) distance between adjacent nodes. <span style="color: gray;">[Is this graph format you're suggesting part of the proposal, or is the "language" itself a dependency from literature? [[User:E J Kalafarski\|E J Kalafarski]] 15:22, 29 April 2009 (UTC)]</span> <span style="color: blue;">I think the graph structure is just a good way of representing something that will be derived from an algorithm that simply measures the distances between interface elements -- it's not something novel that we're developing.</span>

	'''Module Description'''		'''Module Description'''
Line 306:		Line 306:
	*Requires a method for capturing user traces that include formalized records of interface elements used for a particular, pre-specified task or set of tasks.		*Requires a method for capturing user traces that include formalized records of interface elements used for a particular, pre-specified task or set of tasks.
	*Providing suggestions/recommendations will require interaction with other modules that analyze the perceptual salience of interface elements.		*Providing suggestions/recommendations will require interaction with other modules that analyze the perceptual salience of interface elements.
	<span style="color: gray;">[Some kind of formalized list or arbitrary classification of affordances might be necessary to limit the scope of this contribution. [[User:E J Kalafarski\|E J Kalafarski]] 15:24, 29 April 2009 (UTC)]</span>		<span style="color: gray;">[Some kind of formalized list or arbitrary classification of affordances might be necessary to limit the scope of this contribution. [[User:E J Kalafarski\|E J Kalafarski]] 15:24, 29 April 2009 (UTC)]<span><span style="color: blue;">I'm not sure I understand the comment -- are you asking how affordances will be formalized?</span>

	'''Description of the Module'''		'''Description of the Module'''
Line 316:		Line 316:
	***The functions of those actions		***The functions of those actions
	***A particular task		***A particular task
	***User traces for that task <span style="color: gray;">[Could this module benefit from eye-tracking? - Steven]</span>		***User traces for that task <span style="color: gray;">[Could this module benefit from eye-tracking? - Steven]</span> <span style="color: blue;">Response: Absolutely, and it would also benefit from some measure of endogenous attention as well because determining whether someone perceived an affordance requires knowing where they were looking, what they were attending to, and whether or not they actually performed the afforded action.</span>

	*Processing		*Processing

Eric Sodomka: /* Parallel Framework for Evaluation Modules */

2009-05-01T16:53:22Z

Parallel Framework for Evaluation Modules

← Older revision		Revision as of 16:53, 1 May 2009
Line 212:		Line 212:

	* What exactly are the differences between this and EJ's earlier contribution? I think that if they are the same, this one is a bit more clear, IMHO. (Gideon)		* What exactly are the differences between this and EJ's earlier contribution? I think that if they are the same, this one is a bit more clear, IMHO. (Gideon)
	<span style="color: gray;">[I have a similar question to Gideon's. My hunch is that this defines a sort of "namespace" for the modules themselves, while the other contribution (the one you guys assigned to me) is more explicitly the aggregator of these outputs. Correct me if I'm wrong. But if that's the case, the two contributions might need to be validated similarly/together. [[User:E J Kalafarski\|E J Kalafarski]] 15:17, 29 April 2009 (UTC)]</span> <span style="color: blue;">[I ~~think~~ this pretty close to E.J.'s contribution, and that maybe they should be merged. E.J. covered some things that I didn't, such as a more detailed demonstration of how our framework is better than a human interface designer's evaluation, and his gave a demonstration of comparing recommendations, while I only covered evaluations.]</span>		<span style="color: gray;">[I have a similar question to Gideon's. My hunch is that this defines a sort of "namespace" for the modules themselves, while the other contribution (the one you guys assigned to me) is more explicitly the aggregator of these outputs. Correct me if I'm wrong. But if that's the case, the two contributions might need to be validated similarly/together. [[User:E J Kalafarski\|E J Kalafarski]] 15:17, 29 April 2009 (UTC)]</span> <span style="color: blue;">[I agree that this pretty close to E.J.'s contribution, and that maybe they should be merged. E.J. covered some things that I didn't, such as a more detailed demonstration of how our framework is better than a human interface designer's evaluation, and his gave a demonstration of comparing recommendations, while I only covered evaluations.]</span>
	* I feel like this structure's clarity may come at expense of specificity, I'd like to know more than that it's parallel. - Steven		* I feel like this structure's clarity may come at expense of specificity, I'd like to know more than that it's parallel. - Steven
	* Very thorough demonstration(s)! (Jon)		* Very thorough demonstration(s)! (Jon)

Eric Sodomka: /* Parallel Framework for Evaluation Modules */

2009-05-01T16:53:06Z

Parallel Framework for Evaluation Modules

← Older revision		Revision as of 16:53, 1 May 2009
Line 212:		Line 212:

	* What exactly are the differences between this and EJ's earlier contribution? I think that if they are the same, this one is a bit more clear, IMHO. (Gideon)		* What exactly are the differences between this and EJ's earlier contribution? I think that if they are the same, this one is a bit more clear, IMHO. (Gideon)
	<span style="color: gray;">[I have a similar question to Gideon's. My hunch is that this defines a sort of "namespace" for the modules themselves, while the other contribution (the one you guys assigned to me) is more explicitly the aggregator of these outputs. Correct me if I'm wrong. But if that's the case, the two contributions might need to be validated similarly/together. [[User:E J Kalafarski\|E J Kalafarski]] 15:17, 29 April 2009 (UTC)]</span>		<span style="color: gray;">[I have a similar question to Gideon's. My hunch is that this defines a sort of "namespace" for the modules themselves, while the other contribution (the one you guys assigned to me) is more explicitly the aggregator of these outputs. Correct me if I'm wrong. But if that's the case, the two contributions might need to be validated similarly/together. [[User:E J Kalafarski\|E J Kalafarski]] 15:17, 29 April 2009 (UTC)]</span> <span style="color: blue;">[I think this pretty close to E.J.'s contribution, and that maybe they should be merged. E.J. covered some things that I didn't, such as a more detailed demonstration of how our framework is better than a human interface designer's evaluation, and his gave a demonstration of comparing recommendations, while I only covered evaluations.]</span>
	* I feel like this structure's clarity may come at expense of specificity, I'd like to know more than that it's parallel. - Steven		* I feel like this structure's clarity may come at expense of specificity, I'd like to know more than that it's parallel. - Steven
	* Very thorough demonstration(s)! (Jon)		* Very thorough demonstration(s)! (Jon)

Ian Spector: /* Anti-Pattern Recognition & Resolution */

2009-05-01T16:42:30Z

Anti-Pattern Recognition & Resolution

← Older revision		Revision as of 16:42, 1 May 2009
Line 220:		Line 220:
	Owner: [[User:Ian Spector \| Ian Spector]]		Owner: [[User:Ian Spector \| Ian Spector]]

	''Interface design patterns are defined as reusable elements which provide solutions to common problems. For instance, we expect that an arrow in the top left corner of a window which points to the left, when clicked upon, will take the user to a previous screen. Furthermore, we expect that buttons in the top left corner of a window will in some way relate to navigation.		''Interface design patterns are defined as reusable elements which provide solutions to common problems. For instance, we expect that an arrow in the top left corner of a window which points to the left, when clicked upon, will take the user to a previous screen. Furthermore, we expect that buttons in the top left corner of a window will in some way relate to navigation. An anti-pattern is a design pattern which breaks standard design convention, creating more problems than it solves. An example of an anti-pattern would be if in place of the 'back' button on your web browser, there would be a 'view history' button.''

	An anti-pattern is a design pattern which breaks standard design convention, creating more problems than it solves. An example of an anti-pattern would be if in place of the 'back' button on your web browser, there would be a 'view history' button.''

	'''Aims:'''		'''Aims:'''

Ian Spector: /* Anti-Pattern Recognition & Resolution */

2009-05-01T16:42:14Z

Anti-Pattern Recognition & Resolution

← Older revision		Revision as of 16:42, 1 May 2009
Line 219:		Line 219:
	== Anti-Pattern Recognition & Resolution ==		== Anti-Pattern Recognition & Resolution ==
	Owner: [[User:Ian Spector \| Ian Spector]]		Owner: [[User:Ian Spector \| Ian Spector]]

			''Interface design patterns are defined as reusable elements which provide solutions to common problems. For instance, we expect that an arrow in the top left corner of a window which points to the left, when clicked upon, will take the user to a previous screen. Furthermore, we expect that buttons in the top left corner of a window will in some way relate to navigation.

			An anti-pattern is a design pattern which breaks standard design convention, creating more problems than it solves. An example of an anti-pattern would be if in place of the 'back' button on your web browser, there would be a 'view history' button.''

	'''Aims:'''		'''Aims:'''
Line 245:		Line 249:
	'''Outputs:'''		'''Outputs:'''
	* Identification of interface elements whose placement or function are contrary to the pattern library		* Identification of interface elements whose placement or function are contrary to the pattern library
	* Recommendations for alternative functionality or placement of such elements.		* Recommendations for alternative functionality or placement of such elements.



	== Sample Modules ==		== Sample Modules ==

Ian Spector at 16:41, 1 May 2009

2009-05-01T16:41:29Z

← Older revision		Revision as of 16:41, 1 May 2009
Line 216:		Line 216:
	* Very thorough demonstration(s)! (Jon)		* Very thorough demonstration(s)! (Jon)
	* I think that the contribution is much more clearly stated here -- I would argue for integrating them together. (Andrew)		* I think that the contribution is much more clearly stated here -- I would argue for integrating them together. (Andrew)

			== Anti-Pattern Recognition & Resolution ==
			Owner: [[User:Ian Spector \| Ian Spector]]

			'''Aims:'''
			* Develop a framework for analyzing an interface and recognizing violations of established patterns of possible interaction
			* Develop an algorithm to quantitatively rate the amount of anti-pattern violations
			* Integrate cognitive theory in providing suitable alternatives

			'''Contributions:'''
			* Creation of established patterns of interaction as determined by user studies
			* Creation of algorithm to detect match and library elements to interface elements

			'''Demonstration:'''
			* The viability of this module will be tested through providing it with a poorly designed interface.
			** The design would be analyzed and tested by: a usability expert, normal users, the module whereby each would have to eventually provide a value as to how much the interface exhibits anti-patterns.
			** Based on the results provided, we should expect to see the expert and module reports to be similar

			'''Dependencies:'''
			* Library of standard design patterns
			* Affordances module
			* Custom design pattern libraries (optional)

			'''Inputs:'''
			* Formal interface description
			* Tasks which can be performed within the interface

			'''Outputs:'''
			* Identification of interface elements whose placement or function are contrary to the pattern library
			* Recommendations for alternative functionality or placement of such elements.

Trevor O'Brien: /* Semantic-level Interaction Chunking */

2009-05-01T16:25:38Z

Semantic-level Interaction Chunking

← Older revision		Revision as of 16:25, 1 May 2009
Line 85:		Line 85:

	'''Demonstration'''		'''Demonstration'''
	* These techniques will be validated quantitatively with respect to efficiency and user error rate on a set of timed-tasks over a series of case studies. In addition, qualitative feedback on user satisfaction will be incorporated in the evaluation of our methods. <span style="color: gray;">[As above, how will this be validated quantitatively? Comparing two methodologies for manual chunking? What would these differing methodologies be? [[User:E J Kalafarski\|E J Kalafarski]] 15:06, 29 April 2009 (UTC)]</span>		* These techniques will be validated quantitatively with respect to efficiency and user error rate on a set of timed-tasks over a series of case studies. In addition, qualitative feedback on user satisfaction will be incorporated in the evaluation of our methods. <span style="color: gray;">[As above, how will this be validated quantitatively? Comparing two methodologies for manual chunking? What would these differing methodologies be? [[User:E J Kalafarski\|E J Kalafarski]] 15:06, 29 April 2009 (UTC)]</span> <span style="color: blue;">[I don't intend for these techniques to be performed manually. Application-specific rules for chunking will be created manually, most likely by the interface designer, but those rules will be applied automatically to filter low-level primitives and application-states into semantic-level interactions. The success of such methods could be evaluated by having automatically-generated semantic-level histories compared to those manually created by a user. Of course, there's no guarantee that what a user manually creates is any good, so I think it would be more effective to have a quantitative study of user performance in which timed-tasks are completed with and without the ability to review and revisit semantic-level histories. The test without any history at all would serve as a baseline, and then performance with histories created using different chunking rules would speak to the effectiveness of different strategies for chunking.]</span>


	'''Dependencies'''		'''Dependencies'''
	* Software framework for collecting user interactions.<span style="color: gray;">[I'd like to see this fleshed out in a theoretical manner. - Steven]</span>		* Software framework for collecting user interactions.<span style="color: gray;">[I'd like to see this fleshed out in a theoretical manner. - Steven]</span> <span style="color: blue;">[I believe the previous section speaks to this question, but perhaps not with enough detail. It seems appropriate to have this discussion in class.]</span>
	* Formal description of interface functionality.		* Formal description of interface functionality.
	* Description of data objects that can be manipulated through interaction.		* Description of data objects that can be manipulated through interaction.

	'''review'''		'''review'''
	* With what level of accuracy can this be performed. I like the idea, its worthy of a nice project in and of itself. (Gideon)		* With what level of accuracy can this be performed. I like the idea, its worthy of a nice project in and of itself. (Gideon) <span style="color: blue;">[This is a great question. It really depends on what's meant by accuracy. If the only level of semantics we want is that defined by the interface-designer, then it's not really an interesting question. As we begin to talk about semantics with respect to what the user ''perceives'' or what the user's ''intent'' might be, it becomes more interesting, and the term accuracy becomes more ambiguous. I suppose accuracy could be tested by having users verbally speak their intent as they use an interface, and compare their descriptions with the output of the system, but I think that might be a messy study. Interesting to think about.]</span>
	<span style="color: gray;">Can you include something about the broader impact of this contribution? (Jon)</span>		<span style="color: gray;">Can you include something about the broader impact of this contribution? (Jon)</span> <span style="color: blue;">[I think the broader impact here is offering interface designers tools to analyze interaction at a high enough level that they can begin to observe user's intent with an interface, and potentially infer overarching user-goals. If these tools prove effective, and could be implemented in real-time, there's a wealth of possibility in adaptive interfaces. In addition, the semantic-level interaction history construct has the potential to provide meaningful training data for machine-learning algorithms that could probabilistically model user-action and be used to offer suggested interactions.]</span>

	== Reconciling Usability Heuristics with Cognitive Theory ==		== Reconciling Usability Heuristics with Cognitive Theory ==

E J Kalafarski: /* Reconciling Usability Heuristics with Cognitive Theory */

2009-05-01T15:49:45Z

Reconciling Usability Heuristics with Cognitive Theory

← Older revision		Revision as of 15:49, 1 May 2009
Line 103:		Line 103:
	[David: I'm having trouble parsing this contribution. How do you weight a framework? Also, I'd like to have a little more sense of how this might fit into the bigger picture. The assignment didn't ask for that, but is there some way to provide some of that context?]		[David: I'm having trouble parsing this contribution. How do you weight a framework? Also, I'd like to have a little more sense of how this might fit into the bigger picture. The assignment didn't ask for that, but is there some way to provide some of that context?]
	<span style="color: gray;">[I agree that the wording is is a little confusing. The framework is not weighted, but rather it weights the different guidelines/principles. It might also be worth explaining how this is a useful contribution, e.g. does it allow for more accurate interface evaluation? -Eric]</span>		<span style="color: gray;">[I agree that the wording is is a little confusing. The framework is not weighted, but rather it weights the different guidelines/principles. It might also be worth explaining how this is a useful contribution, e.g. does it allow for more accurate interface evaluation? -Eric]</span>

			<span style="color: blue;">[Language cleaned up. While I still think it is important to give more "weight" to cognitive/heuristic principle pairs that agree more strongly than others and output more useful recommendations, I believe I've pitched it wrong and made it too prominent an attribute of this module. I've adjusted. [[User:E J Kalafarski\|E J Kalafarski]] 15:34, 1 May 2009 (UTC)]</span>

	'''Demonstration''': Three groups of experts anecdotally apply cognitive principles, heuristic usability principles, and a combination of the two.		'''Demonstration''': Three groups of experts anecdotally apply cognitive principles, heuristic usability principles, and a combination of the two.
Line 111:		Line 113:
	* Matrix can be improved incrementally by applying "weight" to each cell of the matrix, increasing its influence on final output recommendations, based on the measurable success of this study.		* Matrix can be improved incrementally by applying "weight" to each cell of the matrix, increasing its influence on final output recommendations, based on the measurable success of this study.

	<span style="color: gray;">[There is still the question of how these weights are determined. Is this the job of the third expert? Or is the third expert given these weights, and he just determines how to apply them? -Eric]</span>		<span style="color: gray;">[There is still the question of how these weights are determined. Is this the job of the third expert? Or is the third expert given these weights, and he just determines how to apply them? -Eric]</span> <span style="color: blue;">[Added more explanatory description of methodology as a bullet under Demo. [[User:E J Kalafarski\|E J Kalafarski]] 15:49, 1 May 2009 (UTC)]</span>

	'''Dependency''': A set of established cognitive principles, selected with an eye toward heuristic analogues.		'''Dependency''': A set of established cognitive principles, selected with an eye toward heuristic analogues.
Line 119:		Line 121:
	'''review'''		'''review'''

	* This seems like the 2d matrix? Is this implemented as a module? (Gideon)		* This seems like the 2d matrix? Is this implemented as a module? (Gideon) <span style="color: blue;">[Yes. [[User:E J Kalafarski\|E J Kalafarski]] 15:49, 1 May 2009 (UTC)]</span>
	* Gideon's comment brings up an important point - in what form will the weights be presented? - Steven
			* Gideon's comment brings up an important point - in what form will the weights be presented? - Steven <span style="color: blue;">[Values which contribute to the "influence" of each recommendation. [[User:E J Kalafarski\|E J Kalafarski]] 15:49, 1 May 2009 (UTC)]</span>
	* Could be more explicit about whether the experts are simulated agents or real people (Jon)		* Could be more explicit about whether the experts are simulated agents or real people (Jon)

	<span style="color: blue;">[Language cleaned up. While I still think it is important to give more "weight" to cognitive/heuristic principle pairs that agree more strongly than others, I believe I've pitched it wrong and made it too prominent an attribute of this module. I've adjusted. [[User:E J Kalafarski\|E J Kalafarski]] 15:34, 1 May 2009 (UTC)]</span>

	== Evaluation for Recommendation and Incremental Improvement ==		== Evaluation for Recommendation and Incremental Improvement ==

E J Kalafarski: /* Evaluation for Recommendation and Incremental Improvement */

2009-05-01T15:47:18Z

Evaluation for Recommendation and Incremental Improvement

← Older revision		Revision as of 15:47, 1 May 2009
Line 152:		Line 152:
	* <span style="color: gray;">[I think this is the same as my contribution, and that we should merge them together. You've covered some things that I didn't, such as a more detailed demonstration of how our framework is better than a human interface designer's evaluation. You also gave a demonstration of comparing recommendations, while I only covered evaluations. -Eric]</span>		* <span style="color: gray;">[I think this is the same as my contribution, and that we should merge them together. You've covered some things that I didn't, such as a more detailed demonstration of how our framework is better than a human interface designer's evaluation. You also gave a demonstration of comparing recommendations, while I only covered evaluations. -Eric]</span>
	* I think this contribution and mine (the CPM-GOMS improvement) will need to be reconciled into a single unit. - Steven		* I think this contribution and mine (the CPM-GOMS improvement) will need to be reconciled into a single unit. - Steven
			<span style="color: blue;">[Is it feasible to combine all three of these contributions? [[User:E J Kalafarski\|E J Kalafarski]] 15:47, 1 May 2009 (UTC)]</span>
	* Interesting to note that this could describe the overarching architecture but it depends upon components of the architecture to work. Would it depend on any other modules? (Jon) <span style="color: blue;">[Yes, several modules are listed as dependencies. [[User:E J Kalafarski\|E J Kalafarski]] 15:46, 1 May 2009 (UTC)]</span>		* Interesting to note that this could describe the overarching architecture but it depends upon components of the architecture to work. Would it depend on any other modules? (Jon) <span style="color: blue;">[Yes, several modules are listed as dependencies. [[User:E J Kalafarski\|E J Kalafarski]] 15:46, 1 May 2009 (UTC)]</span>