What I don't like about this approach is that it builds up a large "inventory" of un-implemented UI ideas, and the ideas were hatched without feedback from actual use. My experience is that it is valuable to directly link work on the "service layer" with work on an evolving GUI concept.
Kent Beck Three Rivers Institute > -----Original Message----- > From: Amir Kolsky [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 24, 2004 8:25 AM > To: [EMAIL PROTECTED] > Subject: RE: [XP] Should someone else be writing the GUI. > > Now, building Ui's is an art form. You need specialists that > will talk to the customers, hear their vision of the entire > product (as they understand it at that point in time), look > at the state of the art in equivalent products, look at > industry de-facto and de-jure standards and come up with > their "UI concept". This concept will include everything from > layout to interaction techniques to color schemes to the > different action paradigm (wizard vs classic vs...). > > You wan this done up front, because it takes a lot of time to > get it right. At the same time you are working on user > stories and building everything below the service layer. You > should also build a simulation / mock of the service layer so > the UI people can use it to ascertain that they call into the > service layer correctly. This simultaion can evolve over time > and can be tested continuously by configuring both your FIT > tests (which is one type of UI, assuming you use FIT), and > your temporary GUI (the one you're actually using to show > progress) to use the simulations. 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/
