As far as Mac apps go…

I’ve been doubling my efforts to use QuickSilver, especially in terms of avoiding guis like iTunes and Finder. The book talks about the importance of not disrupting flow and train of thought. While I’ve read about how damaging this can be in Pragmatic Thinking & Learning, I never stopped to examine just how much they affect me in particular. I seem to have attention deficit like a madman. I start and stop tasks several times a minute at my worst. I’ve flirted with using apps like Think and WriteRoom (or the free JDarkRoom) to try avoiding distraction, neither have stuck very well. It seems I’m more inclined to manage my own time, but I still need to figure the best way to do so.

What has stuck as far as productivity already is Spaces, OS X’s built-in virtual desktop; Exposé, the likewise built-in window management tool; the aforementioned QuickSilver; JumpCut; j2 and assorted custom aliases in-shell. I’m a biggish user of TextMate’s macros, snippets and columnar/multiline editing, as well as the Git/SVN bundles.

Now I’m adding Text Expander to my list of must-have apps. I’d played with Typinator (a similar app) before, but it didn’t suit me. Text Expander absolutely does. Being able to customize not only your snippets but how and when they’ll trigger is great. I find myself adding new words while talking to friends on AIM. I’m up to almost 300 words now, hopefully I’ll plateau around 400 or so. Haven’t even used it for development work yet but it’s cutting back on time wasted typing in chats! Also check Doodim, an easier version of Think.app.

Can’t wait to see what apps, commands and ideas I discover going forward, reading the book and on my own!

Another app I’m interested in but haven’t used much yet is Path Finder, a Finder alternative with built-in terminal and lots more.

Anyone with ideas, app reviews or advice, please do contribute!

While nothing is perfect, Mojo has a lot of things going for it: consistency of API let’s users quickly ramp up to speed any time a new widget is added or simply learn more of the large existing set; a deep, thorough set of events for every widget allows you to hook behaviors on widgets at any point in their lifecycles; a growing list of services on the device means you have access to almost all the functionality you see Palm’s own apps exhibiting; and Prototype is quite powerful in its own right.

That last point is as good a place as any to dive in. Prototype is, like MooTools or Base, essentially a class system and set of utility functions. While libraries like jQuery focus solely on DOM, Prototype and its kin exist to facilitate extension of existing classes and the creation of new ones. It’s this presentation of the classical inheritance pattern that allows Prototype to shine. Prototype and similar libraries allow you to inherit from existing classes much more easily than with raw JavaScript.

Palm’s Mojo framework takes distinct advantage of this functionality by building a vast library of classes you can make use of: from the most important widget, list, to buttons, spinners and WebViews, Mojo has a lot of UI elements available for developers to take advantage of when building applications. In addition to the set of widgets available, Mojo presents most of its additional functionality through a unique twist on the MVC paradigm.

The view, of course, is represented in the DOM. Controllers manipulate the DOM as well as manage all the scenes and data management assistance for the closest thing to Ruby on rails is controllers. Assistants have various lifecycle phases such as setup activate, deactivate. You can hook into these phases and fire off whatever functionality you need. For instance, making a request of the GPS service. Once this on-device service has responded, you can make additional requests. For instance hitting a web service and passing in the GPS data as part of the parameters. In Mojo models are represented by the transient in memory objects connected to widgets. A model might contain, for instance, an array of elements which is used to populate the DOM in terms of the list widget. By updating the status of these structures in memory and then calling the modelChanged method widgets will automatically rearrange the DOM as needed.

Ares is an in-browser IDE (think Eclipse or Visual Studio in the browser!) that let’s you drag and drop to design scene layouts, hookup widgets, and assign initial model properties and attributes for these widgets. It also contains a full- fledged debugger (hooking into the emulator via Java applet) with breakpoints and interactive console a la Firebug. These tools are amazing, and sped up the development of Taxi Magic for webOS significantly. There’s even a standalone version of the debugger, which let’s you debug non-Ares projects!

This kind of advanced functionality is what Mojo is all about. I’ll be blogging about Palm, Mojo, the future of webOS (thank you, HP!), and my own experience with Mojo and Ares and related topics more soon.

I’m calling it JazzFusion.

It’s not well-organized yet, but the ideas are there, and it’s going to be very modular. You’ll be able to use JazzRecord or any other data component for handling the database, and view templating will also be easily extensible. The goal for views is to allow simple string-replacement templating with a few macros out of the gate (for calling helper methods, etc), as well as supporting Markdown through Showdown, which I discovered thanks to Ed Finkler, author of Spaz.

The controller methodology is very much inspired by Rails (like JazzRecord’s models), so anyone coming from a Rails background will feel right at home. It supports lazy loading of views and eager loading of controllers out of the gate, with minimal configuration hassle. Control routing will be handled by another modular piece, and documentation will be available on how to easily override the router and view renderer, and detailed docs on writing DRY controllers with features like before/after filters and the ability to render/redirect from one controller/action to other controllers and actions.

I’m playing with the idea now of building a Ruby-based set of generator tools for JazzFusion modeled after Rails’ script/generator tools.

More details to follow, and as soon as the library is in somewhat of a ready state the website/Google Group/Twitter/Github for it will be made available.

First of these was Google’s Ajax Libraries API. While worthless for when you need to be offline (as I ended up being, since the Borders where we met has no free wifi, and I am cheap/skint), it’s nice and easy to include scripts on your pages without needing to maintain the files yourself. Luckily I thought to download local copies and installed Google Docs offline shortly before leaving to meet with the dude.

The second interesting thing I picked up, I actually picked up after the meeting, as I both wanted to learn it and wanted to share with my friend. That something is How to Author a jQuery Plugin, which is what we’re going to look at today. We’ll be building a flexible drop-down navigation menu which will work with or without JavaScript thanks to CSS.

Here’s the working example: MultiNav

Previously, I discussed some of the fundamental ideas behind Gracefully Degrading Widgets, but let’s quickly delineate them again here:

• Focus on content above interactivity – if that means sacrificing the latter for the former, so be it
• Present most important content first – sometimes it is necessary to hide some content to maintain page layout, the most important still shows
• Write minimalist markup – this leads to fewer chances of screwing up and makes it easier on any consumers of your code
• Write stylesheets to hide interactive content by default, and override in your JavaScript

We’ll also be focusing on reusability and flexibility, and we’ll discover that part of this is covered by virtue of the fact we’re creating our widget as a jQuery plugin. jQuery plugins are automatically applicable to any selector style available in jQuery, and so our widget will immediately be available to instantiate among common classes of a page, or to elements with individually unique IDs. You can even apply multiple instances on the page at simultaneously. In addition to these flexible instantiation capabilities, we’ll be building the widget to take a number of options to use different effects, use different classes if the default class names are not appropriate or would conflict with existing names on the page, and so on.

On with the show already! First off let’s create some simple markup for our drop down menu and style it w/ CSS:

  <ul class="nav">
    <li><a href="#">Top Level</a>
      <ul>
        <li><a href="#">Submenus</a></li>
        <li><a href="#">Are Much</a></li>
        <li><a href="#">Less Prominent</a></li>
      </ul>
    </li>
    <li><a href="#">Menus Are</a></li>
    <li><a href="#">Most Noticeable</a>
      <ul>
        <li><a href="#">But Still</a></li>
        <li><a href="#">Quite Useful</a></li>
      </ul>
    </li>
  </ul>

Nice and simple!

  * { margin: 0; padding: 0;}
  .nav { margin: 50px;}
  .nav li { display: block; float: left; background-color: #ccccee; height: 50px; line-height: 2em; position: relative;}
  .nav li ul { display: none; position: absolute; top: 50px; left: 0;}
  .nav li a { display: block; text-decoration: none; padding: 10px;}
  .nav li a:hover { text-decoration: underline;}
  .nav li:hover ul {display: block; }
  .nav li ul li {display: block; float: left; width: 130px;}

Still simple!

Even with this alone, the example code will show simple hover-over submenus via CSS, in browsers that support it (all but IE6, I believe). This is where degradation comes into play. We want things to fail gracefully, so each of those top-level menus should be a link in and of itself, rather than slamming all the links into the submenus. This is a good failover.

So now that we’ve got simple menus, let’s add some action!

To animate a single submenu’s intro into the page, we might use code similar to the following:

  $(".nav:first > ul > li:first > ul").fadeIn();

Which uses an advanced CSS3 selector to grab the very first submenu (a ul element) of the first top-level menu item of the first nav. fadeIn() is a call to a nice pre-defined function of any element(s) returned by jQuery.

That’s all well and good, but what we really need to do is setup a hover effect to fade this menu in and out given the user’s interaction with it.

  $(".nav:first > li:first").hover(function(){
    $(this).children("ul").fadeIn();
    }, function(){
      $(this).children("ul").fadeOut();
  });

This sets up two anonymous functions to be triggered on mouseOver and on mouseOut. jQuery takes care of all of this. What’s important is understanding the selectors and the event assignment. We won’t go into detail about the selectors here, but definitely read the documentation and play with it. The hover function takes two parameters, each a function. The first will be run on mouseOver, and the second will be run on mouseOut.

So that’s a start. Our submenu is fading in and out. But what if you accidentally mouse off the submenu? The damned thing fades away instantly! To get around this limitation, we’ll use a handy built-in feature of JavaScript, setTimeout. This function takes as its parameters a function literal to be called after a specified number of milliseconds, followed by a timeout value in milliseconds. On mouseOver, we’ll set a class on the element, let’s call it “over”. On mouseOut, we’ll remove the class, and call setTimeout. After a specified amount of time, let’s say 500ms, we’ll check whether the class “over” is present on the top-level nav, and if it isn’t, we’ll fade it out. If it is (indicating the nav item has been hovered over again), we do nothing.

  $(".nav:first > li:first").hover(function(){
      $(this).addClass("over");
      $(this).children("ul").fadeIn();
    }, function(){
      var li = $(this);
      setTimeout(function() {
        if(!li.hasClass("over"))
          li.fadeOut();
      }, 500);
  });

This new code sets it up exactly as we’d like it for the first submenu content alone.

What we want to do is make this reusable, as much as possible, and also make it versatile. That’s where jQuery’s plugin system comes in.

jQuery plugins are like any other widget initializer code, only they automatically get to take advantage of jQuery’s fancy schmancy selector system. They should also be written using the function name jQuery rather than $, because jQuery optionally allows itself to be alternately aliased so that it can sit along side other libraries, which might also define a global function $. Both Prototype and MooTools do this, and still jQuery can run in combination with these libraries. If you were to use the $ function, you could likely be unintentionally calling the Prototype or MooTools selector function rather than jQuery’s.

Instructions on authoring jQuery plugins can be found on jQuery’s Web site. It all boils down to:

1. Respecting the “jQuery” function name over “$”
2. Defining your function as a property of jQuery.fn, and
3. Returning the jQuery object that it is called on. (this allows chaining calls, something near and dear to jQuery developers’ hearts)
4. To be incorporated as an official plugin, the plugin should be defined in a standalone file, named “jquery.[plugin name].js” where “[plugin name]” is your plugin’s name.

Let’s take a look at the next version of our code, the first as a plugin:

  jQuery.fn.nav = function() {
    return this.each(function() {
      var nav = jQuery(this);
      nav.find(" > li").hover(function() {
        jQuery(this).children("ul").fadeIn();
      }, function() {
        var li = jQuery(this);
        setTimeout(function() {
          if(li.hasClass("over"))
            li.fadeOut();
        }, 500)
      });
    });
  };

This is a very suitable, fine piece of code, and it’s even a plugin now. It’s even reusable, because it’s no longer tied to the “.nav” class. You can actually call it multiple times on a page, and using multiple selectors, and all will work just fine, independently:

• $(".nav").nav() works just like our old code, only now it’s a lot shorter.
• $("#topNav").nav() also works, only this is for a single unique element

However, it’s not very versatile beyond the selector bit. For that, we’ll need to introduce the concept of default options and overrides. jQuery provides a simple means of setting up default settings for a plugin that can be overridden in any call to it by passing in an options object. The options object concept is an echo of similar functionality in other programming languages: Ruby (via Hashes), Python (via named arguments) and other languages via similar constructs such as associative arrays. The idea behind it is that no one wants to have to memorize the order of parameters for a function, so don’t make them! Object literals allow you to specify their component properties in any order.

To obtain this functionality in jQuery, simply call jQuery.extend(), passing in an object literal for the default values, and the options object parameter from the plugin’s function. Through this, we can specify faster or slower fade effects, as well as change the actual effects called. This is the final version of our plugin, and the code is quite a bit longer.

  jQuery.fn.multinav = function(options) {
    var settings = jQuery.extend({
      effect: "fade",
      duration: 250
    }, options);
 
    var fade = {
      over: function(li) {
        jQuery(li).find("ul").fadeIn(settings.duration);
      },
      out: function(li) {
        jQuery(li).find("ul").fadeOut(settings.duration);
      }
    };
 
    var slide = {
      over: function(li) {
        jQuery(li).find("ul").slideDown(settings.duration);
      },
      out: function(li) {
        jQuery(li).find("ul").slideUp(settings.duration);
      }
    };
 
    var size = {
      over: function(li) {
        jQuery(li).find("ul").show(settings.duration);
      },
      out: function(li) {
        jQuery(li).find("ul").hide(settings.duration);
      }
    };
 
    var effect = {};
    switch(settings.effect) {
      case "slide":
        effect = slide;
        break;
      case "size":
        effect = size;
        break;
      case "fade":
      default:
        effect = fade;
        break;
    }
 
    // iterate over the elements obtained from the selector
    return this.each(function() {
      var nav = jQuery(this);
 
      nav.find(" > li > ul").hide();
 
      nav.find(" > li").hover(function() {
        jQuery(this).addClass("over");
        effect.over(this);
      }, function() {
        var li = jQuery(this).removeClass("over");
        setTimeout(function() {
          if(!li.hasClass("over"))
            effect.out(li);
        }, 500);
      });
    });
  };

Though this code is longer, it’s still quite legible. We’ve changed the plugin’s name to multinav to reflect it’s new, multi-functional nature The new benefit is that we are able to call on the plugin with alternate effects and timing, simply by passing in an object literal with alternate values from the defaults. Here are a few examples:

• $(".nav:first").multinav(); – this is the default behavior
• $(".nav:nth(1)").multinav({effect: "slide", duration: 100}); – this selects the second nav-classed element and performs a fast slideIn on hover
• $(".nav:last").multinav({effect: "size", duration: 1000}); – this selects the last nav-classed element and performs a slow size-in on hover

Using these ideas, you can build any number of plugins which, when handled correctly, can work alongside other libraries, can work under a variety of conditions and present different functionality based on the needs of the job at hand. Calling on a plugin is typically only one line of code. That’s a lot of power in one line. Not only that, but when using the practices of graceful degradation, your page will look and behave appropriately when interactivity is not possible in the browser.

Remember that any widget with interactive elements (form controls, ajax links, tabs, content which moves around or hides/reveals…) should either hide those interactive elements in the CSS and reveal in the JavaScript, or find a way to make use of the elements using the backend. This ensures the page does not contain any confusing, ineffectual controls which look as though they’ll bring about change on the page. In the case of ajax tabs, for instance, you have two choices: Hide the tabs altogether (certainly the easier route), or organize your content and backend technology so that the tabs work as static links to reload the page showing the appropriate (newly-clicked) tab content and hiding the other tabs. This is a bit more trouble, and if you can get away with showing only the most-important content in the first tab, I suggest taking that route.

Have fun writing gracefully-degrading jQuery plugins!

One thing RideCharge has used, but which I’ve only recently expressed interest in, is Watir. Watir is a cool testing toolkit that allows you to control and get feedback from various Web browsers using Ruby. You can use it, or variations of it, with IE (the original Watir was IE-only) Firefox, Safari, or even Flash using the various variations. I’ve only spent enough time with it to get it installed and tinker a bit, so this post only deals with real in-the-field experience. As such, I’ve only played with the FireWatir and SafariWatir variations.

One thing I’ve noticed already are some nuisances in SafariWatir and FireWatir, and perhaps Watir in general in some cases:

• SafariWatir’s goto method requires the protocol as part of the URL whereas FireWatir does not. This is a minor complaint.
• Links in SafariWatir appear to have no href or url property (among others), despite this table showing that they should.
• SafariWatir has no url to determine the current page.
• No support for CSS selectors that I’m aware. This could be brought in from one of at least two Ruby projects (Hpricot or Nokogiri). XPath is a bore.
• Confusingly it only selects the first matching element if multiple elements match. There’s no way to verify the # of elements, etc. Selecting a different matching element is accomplished through the :index parameter.
• Having a different “selector” method for almost every element type seems strange, but perhaps this is just bias from having used JavaScript selector engines so much.
• Having the browser “click” a link where JavaScript is supposed to intercept the click fails to trigger the JavaScript, or may simply have no effect (in one case in SafariWatir).
• No convenient “click the back button” method. This would be useful for testing state-saving in Ajax-focused applications where browser history is an issue.