Xp User Interface Pitfalls

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.