Ken Boucher wrote: > Ok. We have this GUI layer. It doesn't do anything, > because all that > stuff is down in the model. At this point, this is > so essential as to > almost be XP dogma by now. The GUI is hard to Unit > Test. It's hard to > Acceptance Test. We want it thin, so thin as to not > matter. > > Unfortunately, I kinda lied in the last patagraph. I > said it doesn't > do anything. That's not really true. If it's a > desktop app, it's > highlighting, cutting, pasting, moving stuff, and > either it's > complicated enough to drive your end user crazy or > you've hired some > really bright UI guys and could we please have their > names and home > phone numbers so we can hire them away from you. If > it's a web app, > it's trying to handle cross platform compatibility > with HTML, CSS, > and Javascript, and you still need the really bright > UI guys.
You have a boundary layer here between two different rates of change. (The "Humble Dialog Box" scheme.) The GUI skin can change a little too easily. The Logic Layer changes, in small fits and starts, decoupled from esthetic appearances. While everyone on a team has different roles and mindsets, the boundary layer in the code doesn't directly indicate a boundary layer in the team. It suggests, first and foremost, a boundary layer in the way feedback works. Instead of "the GUI guy", meaning a skript bunny who knows how to code-and-fix GUIs, ask for a "usability expert", and put them on the Customer Team side. > Now I firmly believe that agile is the right way to > do GUIs. But I > also belive one thing: It's A Different Kind Of > Agile* Here's an example why it truly is: The game programming industry is mired in a deadspot between code-and-fix heroism and waterfall these days. We extremos think we know the fix for that. However, if you take over a game team and make them iterate, and invite them to grow their engine via TDD, they will probably still lament the control over features that they felt waterfall was giving them. Slavishly applying the XP practices will not provide the holy grail: Reproducible results. The business goal of a game is playability. Nobody can test this, just as nobody can test usability. And a game project has an enormously wide potential playability space to wander in. Business applications, with WIMP interfaces, have a much smaller usability space. Less risk. > Now I can do some web GUI stuff. I used to do some > web design work. I > was never good, but I used to do some. And this is > where things stand > out. Because I know I was never good, it becomes > obvious to me that > our product, like many products, looks more like > Geocities than it > does Microsoft excel. This isn't to say it looks > bad. It looks like > Yahoo, and Yahoo is functional but definately not > elegant. In fact > what the ads sometimes do to the post display on > Yahoo is downright > fugly. Usability, and esthetics, must be continuously reviewed. (One Josh K. is working on a name for this, something like "continuous usability review".) > So I'm thinking about what a agile team that focused > on GUI screens > would look like. I think it would hire very > different people first of > all. And here we disagree. Thou shalt have 1 team. Unless if you mean something else. (Parenthetically, I suspect that all the grunt GUI work - the middle tier of programming - is what keeps getting outsourced.) > And that makes me think that someone else > should be definately > be doing the GUI. And I think they would be testing > different. > Wouldn't it be interesting if they mocked up the > entire model and > built some form of test suite that really beat > against all the things > we forget GUIs do? Tests for the GUI must emerge from within its code. Put another way, TDD for GUIs is a rough topic that everyone must collaborate on. And it's different from being "the usability guy". When such a GUI is under test, all its windows are "just another object". You never use screen scraping and capture-playback to drive such GUIs. However, you don't test esthetic details, and your tests must permit simple refactors that cause minor esthetic changes. Tests and usability have a tension here. To think outside the box, get the review you need from tests without using tests. http://www.c2.com/cgi/wiki?BroadbandFeedback ===== Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
