Doris Chen posted an screencast of jMaki in use (with Netbeans and Glassfish). It's unnecessary because a) jMaki isn't a good idea, b) the tooling looks cumbersome, and c) the end result looked really bad.
jMaki isn't a good idea because it's a taglib that tries to normalize the use of many javascript libraries by abstracting over them. In principle it reminds me of Apache's commons logging api, which is designed to abstract away the differences between Sun's logging API and log4j. This pattern of bad idea pervades the Java platform, unfortunately. Successful projects use succesful implementations, not just APIs. It's important to know Tomcat, not just the servlet APIs, and it's important to know log4j, not the commons API. And it's important to know jQuery and it's UI plugins, not jMaki. To do real work you're going to have to know the underlying JavaScript library anyway, so why bother with an abstraction that will just get in the way?
The Netbeans tooling looks rather cumbersome. I've been (re)reading Donald Norman's "The Design of Everyday Things" and was struck with how unruly Netbeans looked in the screancast. It's all the little things Doris has to do - find an obscure menu item to check that a plugin is installed, center the dialog box on her screen, search through a list of completely unrelated plugins to enable the one she wants, etc. Or when she drags a widget into the JSP and has to right-click and "format" the badly formatted text every time. Since when does dragging stuff create text? And why can't it format itself?
The final blow was that the end result looked (and sounded) like crap. The fish eye widget was layed out wrong, and the google map was too large and also layed out wrong. Putting sound in the page was just a bad idea - that's like adding blinking text. (Just because you can doesn't mean you should!)
Apologists would say (at least) that I'm nitpicking. At least the tools worked; and none of those things I mention are show stoppers, and any programmer who can't deal with a few tool quirks doesn't deserve his salary. And as for the end result looking bad, this was a programmer's demo, not a designer demo - it can all be fixed with some CSS edits later, done by a web designer.
My response is this: the tools work, but encourage errors. They encourage small errors of setup and use. But they encourage a much larger error: the tooling's "map" of the system is not that of the programmer's (or at least not this programmers). I fail to see what a JavaScript abstraction has to do with SVN, and yet these things are presented together in a dialog. I fail to see how a collection of text is a "widget" or why dragging would create text. And yes, I fail to see why I need a JavaScript abstraction in the first place that appears to do little more than substantially increase the complexity of my system.
I feel that IDE's are little more than glorified text-editors, and begin to fail when they themselves introduce abstractions. In a subtle way, the tooling begins to dictate the programmer's mental model of the design- and runtime of his system. In this case, it's nice that Netbeans can easily add a taglib to your web project. But it's not nice that this capability is expressed as a "plugin". It should be expressed as a macro or script: a macro that adds a jar or two there, a line of code to web.xml there, and adds some new JSP specific snippets (particularly taglib declaration and taglib instances). It may even remind you that you'll have to redeploy to get the effect. One concrete difference between a plugin and a script abstraction is that the Netbeans plugin method requires that you select the "plugin" on project creation.
The end result should look good because this kind of programming is all about the front-end. Widget positioning and sizing is not a trivial problem to be swept under the rug! Either jMaki or Netbeans needs to take better care to provide better defaults. And too, programmers are (hopefully) wary of these "slap it together" demos - everyone knows (or should know) that slapping stuff together is the easiest part of programming. It's fitting it all together professionally and solidly which takes time, effort and skill.
No comments:
Post a Comment