I thought I'd do a blog post about common objections and preconceptions to UI Generation and how
Metawidget tries to address them:
Code Generation Sucks!The Preconception
Static code generation is notorious for generating reams of poorly written, poorly documented and poorly tested code. It's very impressive to be able to click a few buttons and suddenly have a runnable project appear, but less impressive when you realize you have to
understand and maintain that code for the rest of your application's life.
And, generally speaking, the
re-generation story is not a good one: if you make anything more than a trivial change to the generated code, you can't expect the static code generator to help you much further.
Metawidget's Approach
Metawidget doesn't generate any static code. It's a purely runtime-based approach. In a similar way to how
JPA generates SQL on-the-fly rather than, say,
pre-building lots of stored procedures, Metawidget inspects
objects (not classes) and dynamically creates UI wigets at runtime.
Generated UIs Suck!The Preconception
Most of the usability aspects of an application's front-end are not stored anywhere in its back-end architecture. So if you try and generate a UI purely from the back-end, you invariably end up with something that looks very generic. For example, perhaps you'll generate a 'UI screen per business class', with Create, Retrieve, Update and Delete (CRUD) functionality for each:
This is simply not how most users want their UIs to look.
Metawidget's Approach
Metawidget does not try and generate your entire UI. It focuses purely on being 'another widget in your toolbox'. It'll render the inside of a form for you (because the field names, and types, and constraints really are stored in the back-end), but it'll leave everything
around the form - including appearance, navigation and usability - firmly in your hands.
By not trying to generate too much, Metawidget becomes more useful to more projects.
Won't work for me - I have a specialized back-end architecture!The Preconception
Given the massive number of different frameworks out there, everything from validation engines to persistence layers to BPM, every project ends up having a subtly different architecture. This architecture is based on choices made by the development team as to what suits their needs best.
Any UI generator that tries to dictate your back-end architecture is unlikely to be a good fit.
Metawidget's Approach
Metawidget does not try to dictate your back-end architecture. It comes with plug-ins for many different kinds of existing technologies, and makes it easy to mix them together or add your own.
Won't work for me - I have specialized widget libraries!The Preconception
Given the massive number of UI frameworks out there, many projects will choose different UI toolkits. And some projects will even choose multiple - say if you're targeting both Web and mobile platforms.
Any UI generator that tries to dictate your UI framework is unlikely to be a good fit.
Metawidget's Approach
Metawidget does not try to dictate your front-end architecture. It comes with plug-ins for many different kinds of existing UI frameworks (including third-party widget libraries), and makes it easy to mix them together or add your own.
I've been asked for presentation material to help those wanting to promote Metawidget within their organisation, say at a Brown Bag Lunch. The material includes speaker notes and is available in two forms, including an OpenOffice version you can edit to your needs:
For me, as I approach the end of any given day's programming, I am usually in one of two frames of mind:
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:
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!
I was recently asked on the Metawidget forum whether we could have a @UiFacesComponentProperties annotation, so that you could fine-tune certain properties of a JSF component from within your business object.
Version 0.95 of Metawidget, the model driven user interface tool, is now available. This release includes the following enhancements:
