I interpret Joe's comments as it being a warning sign if a UI slavishly follows the backend data-structure without taking steps to define abstractions. Most UI's are mere projections, cutting across an otherwise normalized hierachy. Most everything we do can be modeled as a bi-directional graph, with the top-level root defined by on the user story to be handled.
It's an interesting topic for sure, one that I struggle a lot with in GWT where you are forced to take hard decisions between a heavyweight unified model on the client (MVC/MVP with appropriate lookup logic and renderers) vs. a lightweight constant-pulling-projections approach. /Casper On Jun 17, 2:11 pm, Wildam Martin <[email protected]> wrote: > It was mentioned in the last roundup, that if you look at the UI and > immediately get an idea about the datastructure then it is bad design. > > I thought of that but cannot find that necessarily true. I think in a > clear and clean piece of anything things should be as obvious as > possible. > > Example of a bad design: In my car I have a warning lamp for the DPF > (emission filter) and it can blink or be on continuously. Many people > got very confused about it because a) it is not obvious what it means > have it blinking and what it means when it is on (example for bad UI > design itself) and b) as it is not obvious for the driver how the DPF > works unless he is interested in digging into the details, it is not > obvious how to act in the right manner to avoid the problem allbefore > and to solve a problem when it starts to occur (example for > non-obvious architecture). > > You could argument, that a driver gets trained not only about traffic > rules but also about technical vehicle details. This is true but > technology develops further and so do a lot of other realms. Of course > by working on your task you should know what you want to do, but even > the things that are done automatically for you should be done or > communicated in a way that reflects what is really happening. In > software it is important also because when the user calls support > because of a problem it should be more intuitive for the Admin to > analyse the situation, I would say. For the admin it is more clear if > the architecture is intuitive when coming from the user's perspective. > > So what is wrong with it, when the architecture or database structure > is obvious when looking at the UI? > > Best regards. > -- > Martin Wildam -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
