On the latest episode of the Java Posse podcast Roundup '10 - Design vs Engineering, Joe Nuxoll - co-host and passionate UI designer who's worked for both Sun and Apple (and nobody can argue Apple know a thing or two about great UI design) - opens the podcast by saying:
"At least in my opinion, it's one of the core tenets of good UI design is that your internal data structure is not directly reflected in your UI. So you have to consider the use cases in your design flow, and you consider the best way, most efficient way to store the data and organize it in your back-end design - but the two of those should not be one-to-one mappings at all. Usually they're not"
Metawidget couldn't agree more.
Indeed, it's one of the main reasons we feel the Naked Objects approach to UI generation is impractical: really great UIs have a user-oriented model of the application space that is tailored to the user's way of seeing the world, and which does not necessarily match any internal domain model.
But let's be clear: this user-oriented model, although an abstraction of the underlying code, will have some kind of programmed representation. And you will need to map your UI widgets to that representation - be it a collection of lightweight POJOs, or some kind of XML definition, or something as simple as a Map. This representation may even be a mixture of UI-only classes and actual domain classes. For example, you may use an actual domain class 'Employee' but introduce a UI-only class 'EmployeeSearch' for an employee search screen.
So while Metawidget does advocate removing the boilerplate code and error-prone tedium of using visual tools (like Matisse - sorry Tor) or UI languages (like Facelets) to duplicate UI definitions between back-end code and widgets, it does not advocate mapping directly to your domain model. It leaves that decision completely in your hands, by providing a rich array of plugins for different back-end architectures (POJOs, Scala objects, Struts XML files, etc) and a straightforward mechanism to add your own.
Of course Joe, being passionate about his pixels, would also be pleased to hear Metawidget does this without hiding or restricting your existing UI framework. So you still use your preferred tools to get the exact look your users require, only now you can automate a lot of the drudgery. Building great UIs is both art and science. Metawidget does not attempt to address the art, it only automates the science. That is to say, it only tries to help the creation of those areas of UI design that are already rigidly defined - it does not overlap with those areas involving subjectivity, creativity or aesthetics. This may come as a blow to Dick Wall!
Finally I could mention that since Metawidget does all this at runtime, without any static code generation, your UIs automatically update in sync with changes to your back-end classes - saving you time and removing many categories of bugs. But since Joe long ago stopped wanting to do any coding, that discussion would probably put him to sleep :)
P.S. In case it's not obvious from some of the above jibes, I am a huge fan and long-time-listener-but-first-time-blogger of the podcast. Thanks for all the hard work guys!