On 7/18/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > Michael Jouravlev on 18/07/05 20:52, wrote: > > I am not convinced that UI should be *that* different from domain > > model. Do you have examples? > > I'm not sure that I can conjure up something convincing (being a techie > myself!) because you have to be fairly good at useability implementation > to be able to evangelise about it. However here goes with an example > from a project I worked on for a travel company (one of many examples). > > We were given UI mock-ups by the business analyst and one form was for > contact details, including 3 telephone numbers (office, fax & mobile) > each with 2 dropdowns (international dialling code and area dialling > code). The business analyst had worked closely with the Data Architect > without the benefit of an application designer. > > The dropdowns affected useability because each choice of international > dialling code forced a javascript event-driven page reload to fetch the > corresponding area code dropdown. When javascript was declared optional, > we then had to incorporate buttons to allow the user to call up the new > dropdown content. > > We started off having Hibernate disconnected DTOs nested right there in > the actionForm - the model was the address DTO, which had a child phone > number, which had a parent area code and a grandparent international > dialling code. > > In terms of /both/ useability /and/ implementation, it was a joke, yet > it had to appear in multiple places on the website. > > I wanted to change it to allow the user to type in the whole number in > one field and then to write a validation algorithm to establish the > international and area dialling codes, and then to redisplay the 3 > fields for edit, only if the algorithm failed. > > However the project was underfunded and I didn't get time :(
You call this a good UI? Man, this is horrible. I don't blame you, because you wanted to do the right thing, combining stuff together. The idiots who think that choosing from endless comboboxes is easier that to type a phone or a date or address directly, should be procecuted by prohibiting them to do UI design forever. I hate this design. Not as a developer, but as a user. Yuck. Anyway, even with this design nothing prevents to use actual BO in the session-scoped form, and to have three "transient" values outside the BO. BO does not know or care how the phone number is combined. When request is submitted, the actual phone is built from parts somewhere in validate() or in the Action class. Then this real phone is validated. If it is incorrect, page is redisplayed. The downside is that validation can detect that area code is wrong, but it cannot tell UI layer to correlate the error message to a particular combobox. On the other hand, the whole point of comboboxes was to prevent errors with area codes. With nested BO you would have detached address with real phones, and you would have (one "transient" "local phone" field and two comboboxes) * times three. It would still work. I guess, indexed properties could be used. I think, it is still better than copying properties. You have business rules right there, and there is no need to copy most of the properties. UI that you described is still close to domain model: location(s) and corresponding phone numbers (cell phone belongs to a virtual location with no physical address). Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
