Michael Jouravlev on 18/07/05 20:52, wrote:
On 7/18/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
While the business domain is normally modelled using OO techniques, the
view or user interface should be modelled using human behaviour analysis
techniques that produce the best interface for users to get their work
done efficiently, reflecting their mental model of what is going on.
...
If you do [the business/UI shortcut] everywhere, you run the risk
of forcing your users to learn the business domain OO model
which might be a huge leap away from their own mental model.
While I may agree that business model may differ from UI model, I
cannot agree with the idea that they *should* be different. The first
principle of OOP is that program objects reflect actual life objects.
Department, employee, order, order items, etc. These are things that
people work with, and these should be modeled by domain model.
For example, we have department and employees. Or an order and order
items. I think everyone would model it as Order-1:M-Item. What does a
user work with? Same order and order items. What does a user expect to
see? An order and items, corresponding to it.
Of course, there are reference tables/objects, there are additional
tables to ensure M:M relationship, there is a lot of plumbing behind.
But a user does not work with plubming objects, unless it is a
combobox with options.
For example, Outlook Express. We have Folders with typed items like
emails or news or forums. For each forum item there is a list of
messages. For messages there is view preferences, sort order, and
such. So, Folders and messages are definetely business objects. View
preferences... that depends, but considering that OE's data model is
specifically built for user interaction, view preferences can be
stored along with each forum/message list as business object.
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 :(
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
