'''''XpPitfalls'''''

	* '''Problem:''' UIs are hard to test.  

Solution: merciless model-view separation.  

Solution: mock objects.

[JimKingdon: Which object are you mocking?  If you are mocking the
model object in order to test the view, I've done some of that but the
mock objects can be a little cumbersome to deal with.  Often it is
better just to use a real (or in-memory) model object, together with a
relatively simple-minded way of assessing success (e.g. in a Web
application assert that HTML contains the string "A Touch of Honey"
having used that string only one place in your test data).]

Solution: Break your user interface into multiple classes and test
them separately.  For example, if your test code is confused by "Book"
showing up in navigation and also as a table heading, test the display
of navigation and the display of table code separately. -- JimKingdon



	* '''Problem:''' Often, UI designers' processes are holistic and not agile enough to gracefully accommodate a rapidly shifting set of features.  They work much better if they are given a large set of features up front.

Solution: design your interface per '''release''', not per iteration.  Just because
you implement the application one feature at a time doesn't mean you don't have 
any idea where you're going, and it definitely doesn't mean you are forced to churn 
the UI every iteration.
The Planning Game should produce a set of features covering many iterations. Give the
designers this more complete set of features (with the understanding that there may
be additions or deletions as time goes on) and let them work alongside the developers
to create a pleasant user experience.



	* '''Problem:''' UIs (like any external interface) cannot change as fluidly as internal code / interfaces.  Users expect consistency from version to version.

Solution: Release at the end of each iteration and make no more than
one major UI change per iteration. Alert the user to the change in a
"tip o' the day" feature. (I guess it's a "tip o' the iteration".) I
think anyone can deal with one major UI change per week.

Solution: inform the users of changes (verbally, release notes,
whatever works).  They aren't necessarily as hostile to change as they
appear to be if things are sprung on them and they don't understand
the new way of doing something. -- JimKingdon

Solution:  Use a UI framework which generates a usable default interface for every object.  NakedObjects describes one such implementation.


	* '''Problem:''' Sometimes the UI is done before the functionality is.  What should we do about the UI elements (widgets) that activate functions that aren't there yet?  Should we... 

	* Include them but allow them not to do anything?
	* Include them but disable them (gray them out)?
	* Remove them but leave space in the UI where they will someday go?
	* Remove them and "squeeze in" the UI around them, knowing we will soon have to "unsqueeze" when they are ready?
	* Include them but put another visual clue that they are non-functional or not fully functional?

Solution: Don't have enabled or disabled non-implemented
elements. Disabled (gray) items should mean that the feature is there
but you can't use it right now because of some state the application
is currently in.  Non-implemented features that for some reason have a
UI already should be drawn in red, have rough-looking icons,
non-anti-aliased (I guess that would be aliased) text, etc.

Idea So Crazy It Just Might Work: Perhaps have your UI objects linked
to the customer tests; if the tests fail, the UI elements are drawn in
red. If the tests pass, the UI elements are drawn
regularly. -- ErikHanson

Solution: Clarify where you are in the project.  Do you want a tool
which handles one small part of the job, and can be used for such in
production (this is great if feasible, but often isn't feasible)?  Is
the main function of the system for providing demos (in which case
top-level screens should generally look complete even if some of the
screens 2 or 3 levels in are rough or nonexistent)?  Or is the
Customer-as-part-of-developer-team the only one looking at it at this
stage (in which case it is probably better to omit all non-implemented
items)? -- JimKingdon

	* '''Problem:''' GUIs are hard to test, but we can see if they work right away, so we'll slack off

When the time comes to CaptureBugsWithTests, you need a test framework to hang the new test in. If the test framework does not exist yet, you have two bugs, and a hit to your velocity.

Start the GUI TestFirst, even if you eventually author most changes without bothering to test them.