Notes from the May 16, 2001 meeting of the BayAreaXpUsersGroup :

User Interface
	* Define UI not as the colors of buttons that many programmers talk about, but as the flow that a user goes through.  We're talking USABILITY.
	
	* Cooper says that iterative development does not work with UI Design.  He says that a user interface must be designed up front, and that allowing developers to refactor a UI leads to thrashing.
	
	* Feedback
		* is necessary for refactoring.  In XP there is a feedback loop between Customer and Developer.  However, if Customer and User are different, the feedback regarding UI is largely arbitrary, and not necessarily better.
			* How is this different from other times the User / Customer are different?
			
	* Metaphor
		* UI needs a clear UI Metaphor which may be DIFFERENT than that of the backend!!!!  This metaphor may be "yahoo", "amazon", or "checkbook".  Many projects ignore this metaphor - therefore, no common vision - therefore, bad refactoring
		
	* Patterns
		* We are not at the point at UI design that we are in software design.  Programmers share a common vocabulary of patterns for the latter.  However, these patterns either do not exist for UI, or most programmers do not know about them.  We didn't...
		
	* Testing
		* always back to UI Testing...  How do you test a UI.  Better yet, how do you test USABILITY on a UI.  AND, how do you automate it.  Without the tests, how do you refactor the UI with the confidence that you didn't just screw it's usability.  How do you DRIVE the UI through tests, and who knows about UI design....
		
			* software development responsibility is split among 2 groups, ________ and _______
				* developers and business, right?  development makes the decisions it knows how to make, business makes the decisions it knows how to make.  Who knows how to design UI?  Is XP lacking in answering this, or more accurate, is it misleading in not specifying this. 
			* you CAN test some things, tab order, menu depth, etc.
			

How do you design an Intranet's UI?
	* we didn't really come to any consensus as far as I could tell.  Possibilities :
		1. allow no freedom, every page / department must meet stringent ....
		1. allow each department total freedom
		1. (2), but require common xml interface
		1. wikki


How do you test an application, end to end, that has a lot of environment
	* if your application supports 20 databases, and runs on 10 platforms, and may have any permutation of 50 active plugins....
	
	* 20 databases
		* build thin access layer w/ minimal functionality over JDBC.  Use it w/ Test Suite to test each DB.  For end to end, don't mock, databases are hard to mock, just test w/ easy DB (cloudscape, etc).  This setup also allows for test hooks in the access layer.
			* note
				* build the alayer with everything the app uses, but no more.  test it completely
				
	* build tests into your app
		* don't make tests separate.  When the app starts up, let it's test suite run.  This will ensure that the app is in a good state, and give more descriptive errors.  This is of course subject to performance requirements, but is totally doable most of the time.  Test suite on server startup, free cycles, etc.

----
CategoryGroup CategoryXpUsersGroup