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!
5 comments:
Hi Richard,
Just to keep you updated on the latest thoughts from the NO community - we also do agree that there is a need in some cases for objects that are user-centric rather than directly being domain-centric.... in my book, I call these "process objects".
Basically they are part of the solution space rather than the problem space. Typically they are not persisted, but held in memory for the duration of the conversation flow. A shopping cart is of course the most obvious example.
What's been missing from the NO viewers to date though is the ability to tailor the view for these solution space/process objects. The latest viewers we are working on address this though. On the Java side I've been working on an Apache Wicket viewer that is very customizable (wicketobjects.sourceforge.net), while on the .NET side there is a very similar idea for ASP.NET/MVC.
I suppose the thing I'd emphasise though is that NO allows these solution space process objects to be layered on after the problem space domain objects are sorted out. That's in contrast with pretty much every other framework that require you to build the solution space stuff first.
I also think of this as a little like database denormalization. The problem space domain objects are the normalized model; we then denormalize (ie duplicate certain features) into the solution space for optimization. But we don't denormalize unless we need to.
Cheers
Dan
PS: long time fan too of JavaPosse... very cool.
Dan,
Many thanks for the update.
I'm sorry I always seem to be bashing Naked Objects! It's unfair because mainly what I'm criticising is the original Naked Objects 'approach' as defined by Pawson in his 2004 thesis.
But of course there are multiple implementations of this approach such as OpenXava, JMatter and your own which is also called (unfortunately, because it's confusing) Naked Objects.
When it comes to your Naked Objects implementation, I'm impressed by how active you are and the work you're doing. I wonder if this is being reflected anywhere in corresponding updates to the 'approach'? Are there any academic papers or journal articles related to new NO ideas? Would you like to collaborate on such a paper? Some of my recent academic papers are here.
Regards,
Richard.
Hi Richard,
I don't take the NO bashing it personally... trust me, we get worse. And it's true, in any case, that we've softened to some extent since the hardline approach as espoused in the thesis.
Re: developments etc; right now I'm floating the idea about seeing if we can get Naked Objects into the Apache incubator, also combining my sister projects and (you'll be in favour of this) changing its name. That's because the framework, although still the first implementation of the NO pattern, now takes in stuff from DDD and from the hexagonal architecture.
So, my energies right now are on that. If Apache won't take us, then we'll probably still try to find a way to combine the codebases, and then try to match the excellent job that you do with MetaWidget in terms of positioning it among all the other stuff that's out there.
Cheers
Dan
Thanks for the shout-out Richard! We are very glad folks like yourself are finding value in our diatribes!
As for your specific points (without delving into metawidgets, which I have no direct experience with) - I do think it is tough to have an algorithm design a good UI, unless you've done the UI design in the form of creating an abstraction above your data objects to represent the UI specifically. That is pretty common in service API design: you build the best possible low-level service for optimum relational granularity, then you build a service layer on top of that (with it's own caching) to represent the higher-level calls from the UI. All of this assumes that you have done the footwork to know what higher level calls you need, thus you've likely at least thought about the presentation.
Even after all of that - I still think the best UI comes from totally ignoring the underlying data structures and just concentrating on what the user is trying to accomplish. That's when you make big leaps in usability that you never would have thought of otherwise.
Again, thanks for listening! Get your butt out to the Roundup and join the conversation!
- Joe
Joe,
Thanks for replying!
A big focus of Metawidget is that UI generation, whilst potentially a huge productivity boost to the developer, should not in any way impact usability from the user's perspective. I'm finding insights into the minds of UI designers are a great way to understand some of those usability requirements.
So yes, your diatribes are very valuable :)
Richard
Post a Comment