When consumers or business people use an application, the UI ought to reflect the way those users think about the task at hand. In a complex application there may be lots of tables and associations that help the developers maintain state correctly, but which are just a bunch of noise to the user and can even omit relevant details that the user needs to know.
Earlier, Kevin Flanagan gave a great example of a very small change in UI data representation that relieves a lot of effort for users without any need to change the underlying database schema. I've seen even more dramatic differences between the UI and the DB schema which can help users make sense of what would otherwise be a very challenging set of data points to juggle and decipher. A helpful UI can sometimes even serve to help explain all the relationships between tables for developers new to a project. 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.
