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:
Also available through the Documentation page. Feedback welcome!
Friday, June 25, 2010
Wednesday, June 23, 2010
The Peril of the Passionate Programmer
For me, as I approach the end of any given day's programming, I am usually in one of two frames of mind:
- "Man, I've been chasing this bug for hours. I've been down so many dead-ends. I'm really frustrated. But by now my head is really deep in the code, so I'm in the best mindset to figure it out if I just keep going. I don't want to end the day like this."
- "Wow, today has gone really great. I'm on a roll. I've got lots done and I'm excited. I'd love to just add this, and this, and this before I go. I don't want to end the day like this."
- "Today everything went about as well as expected. Nothing went really well, but nothing really badly either. I got done what I wanted to get done. Now's a good time to stop."
Sunday, June 6, 2010
Pleasing Joe Nuxoll
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!
"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!
Wednesday, June 2, 2010
Metawidget featured at JBoss World 2010
JBoss have announced that Metawidget will be showcased at a featured campground session at this year's JBoss World.
Pete Muir and myself will present a session where we'll discuss the pain of form development and what we can do about it:
- Why current approaches to form development (visual tools like Matisse; UI languages like Facelets; code generators like Naked Objects) are unsatisfactory
- How Metawidget enables you to use any combination of back-end technologies
- How Metawidget enables you to use any combination of front-end technologies, including different UI frameworks and mixing third-party widget libraries
- How Metawidget fits in with your existing UI design process, leveraging the full flexibility of your existing toolkit to create highly usable UIs
Subscribe to:
Posts (Atom)