At first I also believed in letting the GUI evolve from the user's requests, and that is often the case that things work that way, however, a UI requires a consistent approach. It makes a lot of to "spike" the UI (in a proof of concept, or prototype) with some screens that will let your users see where all y'all are going (with the understanding that things may change as the requirements and interactions are better understood).
Now, where does the service layer fit in? I prefer to decouple the essense of the system from the mechanics of getting at the essence. If the users require some topology to be built (to take some current example), they may envision a way to do it - drag and drop from a pallete, a command language, menu items with dialogs, you name it. Whatever they envision to begin with - it is my job (as coach or developer, playing customer role) to help distill the essence of what they want to do - they have some structure, they want to augment the structure. This is what the service lauer will let them do. We make sure the story tests reflect that essence. Once the tests pass we know that whenever the service layer is accessed to augment the structure, the system will do it correctly. Now comes the question of *how* do you actually *do* the structure manipulation. And here come the UI people. Good, experienced, creative UI people will observe the state of the art, customer needs, customer's way of thinking, what the standards of the domain are (e.g., Windows or Mac or the industry), what the competition is doing, etc. Armed with that knowledge they will figure out how to tie everything together to a coherent whole. Now, naturally they may miss the first couple of times, but it won't matter, because the service layer infrastructure has nothing to do with how they choose to have the user access it. Moreover, we have successfully implemented multiple Uis based on the same service layer - including desktop, web, command line and automation interfaces... Now, I'm not saying that you can't evolve the UI in step with the SL. In fact, I can see cases where it's the correct way to proceed. What I am saying is that in many cases you will get a much better result by looking at the UI detached from the stories. Amir Kolsky XP& Software >-----Original Message----- >From: Kent Beck [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 27, 2004 11:08 PM >To: [EMAIL PROTECTED] >Subject: RE: [XP] Should someone else be writing the GUI. > > >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 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/
