Barcamp Los Angeles 3 Wrap-Up

Joe stopped-by for a few hours on Saturday and taped his business card to our sponsor logo, reminding attendees that we are, indeed, hiring :)

Sunday morning started with a lavish breakfast, and Heather giving a very interesting demo of ooVoo, with a colleague of hers travelling through Hong Kong, telling us all about his exciting Tuxedo Travels adventures.

After having spent time in the morning putting together some sample demo code, I gave the 10:30am presentation on "DWR, XHTML, JS ...". The first question I asked of the audience was whether anyone had ever heard of "Internet Brands", and much to my surprise, a few hands actually rose.

While we're best-known for CarsDirect.com, we also operate many exciting destinations such as Wikitravel, World66.com, SlowTrav.com for travelers interested in less "touristy" experiences, Loan.com which provides education, advocacy and a vibrant marketplace for consumers seeking Ethical Lenders, DoitYourself.com for home improvement and home repairs, RealEstateABC and its best-of-breed Home Valuation tool, WikiCars.org for all things automotive, autos.com for car research.

I had a Firefox window opened with tabs for all these sites, and after quickly flipping thru them, I went on to our latest project: the complete redesign, rebuild, re-architecture of CarsDirect.com's Used Cars Marketplace, and the challenges associated with developing an advanced, dynamic User Interface, while keeping it maintainable.

The audience asked very pertinent questions about some of the issues and challenges we're still addressing, such as the ability to bookmark various searches as we refine results, and our current inability to get any SEO juice out of the search results page. Many expressed interest in being able to "subscribe" to vehicle searches via RSS. Doug had actually implemented this feature, but we still need to surface it and fix a few cosmetic issues. But if you're curious, here's a feed for Used Cars in Hermosa Beach, CA, with a power convertible top, and manual transmission.

We've got ... a few ideas for RSS, and possibly more advanced feeds, allowing for more exciting applications ... and not just ones built by us.

Beyond user interface, attendees realizing that each click on the results page triggered an asynchronous call, were curious to know how we returned data so fast. When i joined this project, Doug and his team had already built a proof of concept they called "wireframe" that truly showcased this "instant satisfaction" we get from interacting with the interface. It felt ... impressive, leading to a major "Neo-watches-Morpheus-jump-to-the-next-building ... Wow" moment when he explained how they'd architected the app to make this 1) possible, and most importantly 2) scaleable.

But I digress. The rest of the presentation covered the sample code I'd put-together, showing how we can use "cloned templates with mapped data fields" to facilitate the process of injecting data contained in JavaScript Objects into a document, enabling you to keep the Markup away from the Scripting. So-far we still have management's approval to release this framework into a library, but we do need to find time to re-factor a few things.

After the presentation, I got to meet, chat, and reconnect with a number of interesting people:

Jason Fields from fellow IdeaLab company Snap.com was passing around stickers and reminding us about their very cool "Snap Preview Anywhere™" feature.

Chris Gagne showed me Student of Fortune, and later-on gave a talk on leveraging Open-Source concepts to solve real-world problems.

Zach Greenberger told me all about Valuewiki.com. It's a very interesting concept: They're providing a community-driven securities research site. Being a Wiki, user-contributed content can, to some extent, "self-correct" itself, resulting in much-higher quality information than what you might find on a typical "stock message board" such as Yahoo Finance. They also run "Free the Market" blog, with insightful posts covering the Wiki and Business Worlds. Their PayPerPost.com interview with Dan Rua even got slashdotted yesterday!

Belkin, a fellow sponsor, showed-off a preview of their very cool "Networked USB Hub", to be priced around $120 if I remember correctly. I would have bought one right-away had it been 1) available for sale, 2) had a Mac OS X driver ready. It turns out they're a couple of months away from releasing it, and they do have a Mac OS X driver ready, they just need to get it out of the "beta" stage.

Crystal Williams demoed practical applications of Microformats to a packed audience.

Karl Roth gave us a presentation on his Solar Illumination system, to cost-effectively bring sunlight into just about any building, to complement existing electric lighting with dramatic energy savings during daylight hours. This cost-effective solution would pay for itself in under 2 years in energy savings alone, not taking into account extra revenue resulting from increased productivity from dramatically improved working conditions.

Working with DWR

Update 6/26/2007: See also Working with DWR on the IBDOM site.

Update 5/15/2007: Meet IBDOM, our enabling framework.

Direct Web Remoting (DWR) is one of a few nifty enabling frameworks to build more interactive web applications with less pain.

Unlike most other frameworks, DWR doesn't so-much focus on User Interface. Instead, it focuses on enabling developers to expose business logic written in Java to web browser calls, through a Servlet Container such as Tomcat, Jetty or Resin.

It provides a layer that serializes data returned by a Java Method, into JavaScript JSON-esque objects, retrieved over XmlHttpRequests, and passed into JavaScript call-back functions for client-side processing.

What's interesting about this approach is that what goes over the wire is little more than just "data", versus "markup + data" ... Which doesn't matter if you're only dynamically updating a small portion of an HTML document. But if you're retrieving, say 30 listings, each of which has many fields you need to represent in a table with 7 columns, the Markup required to draw each row really starts adding-up.

Say that in Java-land, we have a SearchManager class, that has a method called "getListings(int zipcode)", that returns a collection of Listing objects. Pretending this method is "static", we could call it from another Java class as such:

listingsCollection = SearchManager.getListings(myZip);

The DWR framework exposes this very class to JavaScript, as well as all of its public methods, so calling this method from JavaScript looks very similar. But when calling it from JavaScript, we always must pass a reference to a JavaScript call-back method: it will receive the output of the method call as a parameter.

SearchManager.getListings(90254,displayListings);

Where displayListings is defined as a simple JavaScript function as such:

function displayListings(theListings) {
...
}

The question now becomes ... "what happens inside of function displayListings(theListings)" ?

The function receives a JavaScript Array, whose members are Objects whose properties match those defined back in Java in a Listing bean. We need to loop thru the Array, and for each member, update the HTML in the document, to render that listing:

listingsTable = document.getElementById("listingsTable");
for (i=0; i < theListings.length;i++) {
currentListing = theListings[i];
listingsTable.innerHTML += "" + currentListing.id + "" + currentListing.title + "
...repeat 5 more times for each column ;
}

...

ew.

.innerHTML is very simple to use, but it facilitates the mix of Markup inside scripting and that has a few disadvantages: Since it's possible to pass any string to .innerHTML, it's very possible to generate broken markup, and when broken enough, it could even crash some old version of Safari, sweet! -- not.

Further, having markup live inside JavaScript, makes it more tedious to rethink and tweak the user interface, or simply troubleshoot presentation issues. Which means more work.

Last, .innerHTML isn't part of the DOM specification, or any other spec for that matter. But all browsers do support it.

Instead of using .innerHTML, one could stick to pure DOM methods to update the listingsTable, such as:

loop ...
theRow = listingsTable.appendChild(document.createElement("tr")); theCell = theRow.appendChild(document.createElement("td"));theText = theCell.appendChild(document.createTextNode(listing.id));...repeat 6 more times for column in the row
end loop

... Sticking to DOM methods pretty-much prevents us from injecting horribly broken HTML.

But this gets very tedious, fast, and we're still building Markup inside JavaScript, leading to ... more work.

...ew.

We were looking to easily "Map JavaScript objects to HTML Elements". Imagine having reusable "templates" in your HTML document, made of any number of elements inside of which you placed "data:somePropertyName" placeholder values:

<tr class="resultRowTemplate">
 <td>
 <a href="data:vehicleDetailUrl">data:listingTagLine</a>
 </td>
 <td>
 $<span>data:price</span>
 </td>
 <td>
 <span>data:mileage</span>
 </td>
 <td>
 <span>data:distanceFromDealer</span>
 </td>
</tr>

This template was mapped to a JavaScript object with the following fields:

listing.vehicleDetailUrl
listing.tagLine
listing.price
listing.mileage
listing.distanceFromDealer

Achieving this set-up thoroughly increased the fun of working with DWR, and beyond DWR, ought to be highly useful in any situation where developers are faced with injecting JavaScript Object data into HTML documents.

We're looking to gauge interest from fellow JS/AJaX/DWR developers (Yes, YOU!), in our releasing some enabling libraries within an open-source context. Our current code is in need of serious re-factoring before any sort of public consumption. If you come across this entry, please voice your thoughts in comments. Some of us will be at BarCamp Los Angeles 3, hoping to do a little demo, code reviews about this and a few other things.

Also: We're looking for a User Interface Engineer to help out with existing similar projects, and many cooler "things" coming down the pipe.

Harnessing Transparency

Power or Ease of Use, Power and Ease of Use, being feature-rich or simple, being feature-rich *and* simple. A few of many questions it's safe to assume Jonathan Ive and his team ask many times over with each product Apple brings to market.

Thankfully though, we're not Apple ... We're not "quite" out to tackle profound industrial design challenges.

Unlike hardware designed in utmost secrecy, manufactured and shipped to millions of homes, with only one shot at getting things right, we get to build products in the far more flexible, transparent world of Web Applications.

With tonight's release and this post, Doug's clearly out to harness this flexibility and transparency.

Unleashing a new application unto an established user base is an unnervingly exciting rush, riddled with disconcerting lows and euphoric highs, adapting to some challenges we did not expect, carefully preserving preexisting business requirements while paving the road for new opportunities.

As developers we can never know enough. On one hand we face a healthy backlog of "Phase 2" issues we want to tackle, on the other hand we face this nagging suspicion that we have not yet begun to understand what does, indeed, need to be tackled.

So we reach out.

See also: Seeking the Zen of buying used cars.