On Jun 18, 5:36 am, Wildam Martin <[email protected]> wrote: > On Fri, Jun 18, 2010 at 09:50, Joe Sondow <[email protected]> wrote: > > 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. > > Sure, looking into detail there might be a lot of differences between > DB/architecture and UI. > In reality when I was taking that rule of thumb into doubt, I was > thinking more general, such as if I have a DB with companies and > contacts, why should it then be wrong if I can see the company-contact > linkage also in the UI directly. > > I think that was my missunderstanding of that particular critic of > software design. The date and period sample given by Kevin was a > simple and good one and even you pointing out internal structures that > might be there for performance reasons but be presented in a different > manner to the user. > > I think I understand now. > > Thanks. > > -- > Martin Wildam
Not to steer the thread off-topic, but you know how everyone loooooves Apple for their genius UI ideas? Well, I have one better that no one seems to talk about much: Facebook. I'd venture to say they're currently enjoying their spot at the top of the hill primarily on merit, particularly when it comes to usability. And just look at how far their GUI is from their data structures -- all in the name of usability for a wide-ranging audience. One of the most useful things they put together -- not that they were the first to do it -- was a usable high-level aggregate view of many different kinds of data. Look at how one attaches video to a posting: by pasting a relevant youtube link, not (necessarily) clicking a designated Attach button. Look at how seamless is the transition between what we engineers traditionally think of as summary view and detail view. And so on. Moral of the story: sometimes (certainly not always), intuitive user experience and a stable, performant persistence solution do not produce the same "looking" designs. And it's fine, because that's where the job of the programmer lies. Sometimes I fear that one of the weaknesses of the Java enterprise world is the culture of frameworks, where people become obsessed with chasing the ultimate framework that will allow the programmer to just put a bunch of things together and upon editing 27 different XML files the app will just magically appear. Seems to be, 9 times out of 10, that approach yields just the kind of blind CRUD apps that scream "look, you dumb user, now you have to pay for your lack of application design forethought by becoming a data entry monkey, while I pat myself on the back for a job technically accomplished". We should strive for elegant design in all aspects of our projects. -- 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.
