Walking past the round-the-block lines for the iPad 2 prompted me to reflect on the long-term educational significance of the tablet. The futurists who predicted the rise of mobile will most likely claim that these tablets fulfill their vision. Tech pundits insist that this new form-factor goes beyond superficial cosmetics and represents a transformation in computing. What should we make of the hype?

The 2011 Horizon Report predicts both mobile and ebook/ereader adoption within the next year:

"For more involved web browsing, reading, watching videos, or to use any of the tens of thousands of Internet productivity and lifestyle applications, the tablet provides just enough extra space to enable comfortable use over longer periods of time."

At CCNMTL we've begun exploring the deployment of applications on tablets. We recently launched two behavioral interventions that are being used in the field - MySmileBuddy and MedER. These applications are hybrids of data collection and multimedia educational material and are being administered by social workers making housecalls and researchers on-site in the pediatric emergency room.

While working on a Javascript interactive for the diaBeaters project, we stumbled across an interesting problem with jQuery UI draggables. To wit: if you have draggable items inside a div with overflow:hidden, they're stuck. You can't drag them out of the container -- the div just scrolls out to infinity. (Try it sometime, it's awful.)

Here's the original drag-and-drop setup. The game involves dragging magnets from a menu on the left-hand side onto a refrigerator on the right.

jQuery(".magnet").draggable({
  revert: 'invalid'
});

jQuery("#fridge").droppable({
  drop: function(event, ui) {
      jQuery(this).addClass('dropped');
  });

I see programmers as inherently helpful people. Given a 57-step flowchart describing the steps some poor soul has to execute manually, most programmers get a little gleam in their eye and set about providing a streamlined solution. Programmers truly love removing those inefficiencies. Meanwhile, the customer stops wrestling with a frustrating system and gets on with his job.

I recently had the opportunity to untangle a complicated little process knot. The technical details are applicable solely to the Columbia community, but I think the story is a reminder that a core engineering duty is to tackle real world inefficiencies.

One of the primary tenets of agile development is test first, test often. After working in a small XP shop doing mobile development, I came to believe strongly that quality code hinges on a test-driven approach.

Coders, impatient with paper specs and endless product meetings, often rush to their keyboards and push out half-baked, poorly implemented solutions that don't meet anyone's needs. Writing tests -- especially in a test-first approach -- provides time for thoughtful inquiry into an application's overall design and specific functionality. The coder can express herself in her own comfortable environment and language. The resulting tests become permanent artifacts, able to verify functionality as the application is enhanced and refactored.

And, in less altruistic, more self-serving terms: good tests mean good code, and good code makes the coder look good. Why wouldn't you want to write tests?

Still, I was a little apprehensive when asked to setup a test infrastructure for the Mondrian JavaScript components. (Mondrian is our snazzy new web-based, multimedia, annotation environment). I've tackled many server-side testing tasks, but have managed to circumvent the swampy land of JavaScript. JavaScript generally does not lend itself to testing. Most JavaScript code I've seen is poorly organized, fragmentary and tightly-bound to the browser. I've often lamented the lack of good JavaScript testing tools, but also was loathe to tackle the seemingly messy, difficult task.

I spent my weekend at HOPE, a hacker convention run by the good folks at 2600 Magazine. There were many interesting (and occasionally hilarious) talks on a variety of subjects, from the weirdest things you can send via the postal service to the basics of hacking DNA to a discussion of the GPS technology in NYC taxi cabs.

One of my favorites was called "Evil Interfaces: Violating the User". It was a taxonomy of manipulative UI methods that result from a situation where the goals of the designer are not the same as the goals of the user (for instance, they want you to pay attention to the advertising). The speaker, Gregory Conti, talked about how the most successful "attacks" result from an inversion of traditional UI design rules. So in some sense, it was a manual of "what not to do": distract the user from the content with motion or color, disguise non-content as content, add extra barriers between the user and the content he wants to see (interstitial ads), exploit user errors, set bad defaults, etc. However, it gave me some food for thought about our projects.