I can give you a concrete example of where exactly reflecting the data structure is not the best approach.
The system I work on allows users to request video tapes to be pulled from a library and delivered to an editing room. Two of the pieces of data we collect are the date they need to start working on the tape, and the date they expect to be finished with it. The original UI had 2 date fields. It worked, but it was awkward, because having to put in the second date felt like extra work to the users, since they thought of the job as having a start date, and a duration (usually 1 or 2 days). They were much happier when we switched the second date field to a duration drop down, and let the app compute the end date. K On Jun 17, 5:11 am, 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.
