We are a user experience design and software development firm
Hire us to design your site, build your application, serve billions of users and solve real problems.

Ajax pros, especially in the Rails world, often know the Prototype and Scriptaculous JavaScript libraries inside and out. When faced with the prospect of writing on top of the competing jQuery framework, they may quickly stumble upon seemingly missing features.
The culprit? jQuery's less-is-more approach, in which advanced or specialized features come via plugins instead of the core library. The greater reliance on single-purpose plugins gives jQuery a lean footprint and a vibrant ecosystem, but they come at a cost. You often must rope in several plugins to accomplish things Prototype and Scriptaculous can do out of the box.
If you want to encourage your team to step out of the Prototaculous mindset, it helps to have a readymade list of plugins that approximate those libraries' core features. At this point jQuery and Prototype approach feature parity, but once Scriptaculous is in the mix, jQuery relies on multiple plugins to keep up with the Joneses. Here's a quick stab at how to trick out jQuery:
Topics: Javascript, Javascript Libraries, jQuery, Prototype, Scriptaculous
Many times open source projects are mute -- they have insufficient documentation. Good technical blogs can function as a sort of ad-hoc documentation. That's what I've tried to do, most recently with my series of posts on GWT and OpenSocial. Vinay, over at Web Technology I/O, often does the same. He's got a great post about Ray Cromwell's GwtQuery (JQuery-like syntax in GWT) and how to make it work.
I've been tinkering with this tool as well and am going to do my own writeup, but thought I'd give you all the heads up. BTW, according to Vinay, the compiled GWT JavaScript for GwtQuery clocks in at 712 bytes!! So much for GWT bloat.
I've been pairing with my colleague Noel Rappin on a cool Rails project lately, which has helped me turn a bunch of conceptual knowledge into real-world experience. I'm writing Ruby code, doing things the Rails way, and hewing faithfully to test-driven development.
I'm also returning to Prototype for my JavaScript needs after almost 15 months of daily jQuery use. The framework has matured nicely while I've been away. One surprise popped up today, however: Prototype 1.6 lacks the ability to simulate native browser events. jQuery offers this in the form of jQuery.trigger, which can simulate both native and custom events. But Prototype's Element#fire supports only namespaced custom events. (Read this mailing-list thread for more analysis.)
I did a couple hours of digging around today - including a trip to Scripteka - and haven't really found a canned, cross-browser solution to this issue. I'm looking for something that offers jQuery's native event firing in a tidy little Prototype extension. Anyone know of such a tool?
Topics: Javascript, jQuery, Prototype, rails, ruby
Now that I've got a few Ruby on Rails projects under my belt, I finally feel qualified to comment on Rails front-end coding conventions. As a UI specialist coming to Rails from the JSP world, I find a lot of room for improvement in the RoR approach to view-layer code. I love working on the non-view aspects of RoR projects, but I find I've got to do tons of cleanup at the ERB layer. Expect to see some open-source components from Pathfinder to help ease this pain. In the meantime, let me articulate my pain points:
If I'm filling a front-end role on a Rails project, most of the files I need are in /app/views and /public. I dig that. Likewise, I appreciate the underscore naming conventions for partials. However, I wish /layouts weren't just another subdirectory of /app/views. Layouts are inherently different from standard view templates. A better hierarchy within /app/views would help drive this home. Likewise, I wish partials and full templates each had their own directory within a specific controller's view folder. That would help keep directories manageable on big projects. The /public directory, on the other hand, offers just the right amount of organization.
This piece of news has brought about great cheer in the Web Developers community. jQuery has been fast gaining reputation in the world of web-development as a light-weight, flexible and easy-to-use Javascript library. Integration of jQuery with Microsoft's development platform should provide web developers with new capabilities and opportunities.
This is very smart move by Microsoft given the fact they have always hesitated to incorporate open-source technologies into their products. It is planning to ship jQuery with the ASP .NET MVC very soon. Integration with Visual Studio is something that is going to happen later. There are plans to enable intellisense support for jQuery in Visual Studio which would be really cool I think.
Some of the high-points of jQuery integration with ASP .NET could be :
image-source : www.webmonkey.com
I have posted a few links below that discuss more about what the MS-jQuery marriage means for the web development community and how it can make life easier for developers out there.
http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx
In last week's post, I introduced the linked multiselect widget I was asked to implement on a tight deadline for an unexpected project assignment. I showed some demo code in action and discussed the user experience issues that shaped my requirements. This week, I'll walk through the actual code - or at least my first pass at it.
Like a lot of developers who should know better, I sometimes shirk the technical design phase on quick projects, then regret it later. The code I handed off for this project got the job done, but it wasn't very DRY or elegant. Luckily, I've continued to refine it into something I'm not ashamed to blog about. Next week, I'll show off the final, refactored code and try to draw some conclusions about the entire experience. But first - the original, unrefactored code:
Topics: Ajax, Design Patterns, Javascript, jQuery
Last week I spent a couple of days lashing together a UI widget for a project that needed a little Ajax assistance. As always, I looked for an opportunity to learn something along the way, so I got signoff on using jQuery and some plugins I hadn't previously employed.
The result? A down-and-dirty mini-project that let me test drive Color Animations, jqModal and Low Pro for jQuery while employing tried-and-true solutions such as jQuery Templates and Live Query. What's more, the requirements for the widget itself left room for some careful consideration of user experience design.
In the end, I built a client-side demo in just a few days and handed it off to the project lead for integration with a complex back end. Now I'm free to refine my deadline-constrained code into something a little more OO and share the results.
This week, I'll talk about the project's complex usability requirements and Pathfinder's user-centered solution to those requirements. Next week, I'll walk you through our first pass at building custom code, roping in open-source libraries and making it all work together on a tight deadline. Finally, I'll walk you through the refactoring process so you can see the final, properly factored and reusable version.
Topics: Ajax, Javascript, jQuery, Low Pro, OOP

Drag and drop is like those Nutty Bars snack things.
Allow me to explain.
I like Nutty Bars. But I never expect to like them. They are kind of funny looking, for one thing, what with that weird criss-cross pattern on the top, and the chocolate never quite covering the wafers. But when I get past that and actually eat one, it's actually kind of tasty.
Which brings me to drag and drop. Which I always expect is going to be an overwhelming pain in the neck (probably based on bad experiences using Java Swing). But whenever I manage to get over it and actually implement a web drag and drop, I'm always surprised at how easy it is using an Ajax framework.
jQuery is no exception.
Topics: Javascript, jQuery, Project Website, Ruby on Rails
Yesterday I discussed how to separate the jQuery plugin wheat from the chaff. Today, I offer a completely subjective and biased list of jQuery plugins to know and love.
Topics: Ajax, Javascript, jQuery, plugin
I opined recently that jQuery plugins can be more trouble than they're worth. That said, they're often indispensable. True, the worst plugins suffer from bloated code, confusing APIs and too many features. But the best provide instant black-box functionality with just a little configuration. The trick is figuring out which plugins are worth the effort and which ones aren't. Here are five tips for doing just that.
Topics: Ajax, Ajax libraries, Javascript, jQuery, plugin

This is something of a mix between what I've been doing on the http://www.pathf.com/blog/tag/project-website/ posts with my more typical "here's how you do something in Rails" post. I'm going to describe how to use jQuery to manage JavaScript and Ajax in a Rails application rather than Prototype and Scriptaculous.
The benefits of using jQuery on a Rails project seem to be:
There are a couple of costs, especially from a Rails application
assert_select_rjs and the lack of unit testing of jQuery behavior. As much as JavaScript development tools have improved, there are still gaps in testing browser-centric behavior.Topics: Javascript, jQuery, Project Website, Ruby on Rails
Part 3 of my colleague Brian Dillard's series on retrofitting your web site with Ajax is now up on the IBM Developerworks site.
In this installment, you'll tame unmanageable product-details pages by placing content inside a tabbed interface. You'll also keep product images under control by displaying them in an image carousel. You'll learn how to employ both techniques using simple Dynamic HTML (DHTML) or more complex Ajax code. Either way, you'll again use the principle of progressive enhancement to keep your pages accessible even when JavaScript isn't enabled. To accomplish all this, you'll use two additional jQuery plug-ins: jCarousel for image slideshows and jQuery UI Tabs for tabs.
You'll also want to look at parts 1 and 2.
Topics: Ajax Development, Announcement, jQuery
I recently asserted that open-source plugins are sometimes more trouble than they're worth. Nevertheless, I've found one unexpected benefit of jQuery's plugin mechanism: its ability to keep me focused on reusable components rather than one-off, procedural routines.
Because jQuery doesn't ship with any general-purpose way of simulating classical inheritance, it's easy to fall into the trap of writing procedural code with no eye toward re-use. When your first pass at solving a given problem often takes only a few lines of code, it seems like too much overhead to wrap those lines in any sort of object.
But then you decide to layer on some effects ... or there's a new requirement to retain state across sessions by calling on a cookies plugin ... or you end up with a new use case that would require a subclass of your existing code - if it had been written as a class in the first place. By this point it becomes obvious that your behavior layer is poorly organized, hard to maintain, and inexorably tied to a specific use case. That's when you roll up your shirtsleeves and start refactoring.
Topics: Ajax, Javascript, jQuery
After just three weeks of frantic work, my team today released the first public version of PlantCollections, a joint venture of the Chicago Botanic Garden and 29 academic and corporate partners.
Our app serves as the consumer-facing front end for a Google Base collection of plant specimen data compiled by scientists and gardeners all over the world. This project represents my first experience with Ruby on Rails and Pathfinder's first experience progressively enhancing a Rails app with jQuery. Although this is still little more than a prototype, with lots of additional functionality to come, we're pleased that this first release is already out in the wild. Go, agile, go!
To learn more about PlantCollections and our involvement in the project, check out the press release. Otherwise, just head straight to the application itself.
I've pimped a lot of jQuery plugins, both here and in my articles for IBM developerWorks. On each occasion, I've praised the plugin model for its ability to keep core libraries small while still offering a sanctioned way to share reusable components with the open-source community.
I'm not taking any of that back. But after a few weeks of rapidly iterating on user-interface features for a new client, I've come to a different conclusion: I'd rather spend time building my own custom UI component than wrangling my code to work with somebody else's plugin. When I write my own custom widgets and event handlers, I can accomplish the following:
Topics: Javascript, JavaScript frameworks, jQuery
Hire us to design your site, build your application, serve billions of users and solve real problems.