Learning Curves

So I was reading the documentation for Spry and realizing that the folks on the Dreamweaver Team intentionally avoided making the form validation widgets similar to the onTap framework's form validation tools (like I mentioned before) because part of their design philosophy behind Spry involved not making people learn a new tag library. According to the documentation, this makes Spry easier to learn, because it means users will be relying on skills they already have with HTML, CSS and JavaScript.

Okay, sounds great!

Here's the catch. They're assuming that this:

<input type="text" name="myTextField" id="myTextFieldID" />

...

<script language="javascript">
   ...
   myText = Spry.Widget.ValidationTextField("myTextFieldID", "integer", { useCharacterMasking:true, minValue:"0"});
   ...
</script>

Is somehow easier to grasp and requires a smaller learning curve than this:

<input type="text" name="myTextField"
spry:validate="integer"
spry:useCharacterMasking="true"
spry:minValue="0" />

I don't know about you, but I find it hard to imagine how the eminently legible second example would be harder to grasp and have a bigger learning curve than the former, merely because the person implementing it already knows JavaScript. Aside from the fact that they've merely arbitrarily asserted that "it's easier to learn something in JavaScript than it is to learn essentially the same thing in XML", the example from actual Spry code actually involves at least one additional opportunity for confusion and one additional coupling point.

The additional opportunity for confusion is that the text input now requires an ID attribute which wasn't necessary if you used namespace attributes in the input element, because the XML version implies that the current XHTML node (the input element) is the item being validated (i.e. it's encapsulated).

The additional coupling point is that the javascript below has to know in advance (from the programmer) what type of input element is being validated. So now you've got to specify that this particular input element is a "textfield" in two places, plus you've got to make sure the textfield widget and CSS are loaded before you create the validator. Yay for high coupling! What happens if you comment out the script tag that loads the library? Well in the XML example, if it's architected properly, the only thing that happens is the page ignores the spry attributes. In the Spry example, you get javascript errors. Or perhaps more likely, if you comment out the input element in the XML example, you're done. If you comment out the input element in the Spry example, you're forced to separately comment out the line of JavaScript that creates its validation widget.

The XML example would also actually offer the opportunity for some interesting alternatives -- individual widgets could in theory be loaded via a WebService (or at least another server) instead of requiring that they be loaded inline from your own application. Attributes on the individual nodes could be modified to change the validation at run-time without having to dig into the guts of the validation widget, etc.

I'm being a bit scathing here I know. And I realize that the developers on the Dreamweaver team will probably not enjoy reading these comments (if they ever do). I'm just venting a few frustrations and trying to help people understand better design at the same time. The Dreamweaver team's objective of creating a system with very little learning curve is laudable. Their intent is admirable. Their execution however is far from achieving their stated goal. IMO in the present tense, spry = poor encapsulation + big learning curve...

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress