Qrowd

Having founded Cooqy in December 2005, choosing to use the letter “Q” again for my next startup seemed to be preordained. (Hopefully having the “Q” at the start of the word will prevent confusion with the letter “G”.) Cooqy was a self-imposed project to get myself familiar with Web 2.0 RIA technologies like OpenLaszlo, AJAX, and DHTML. The availability of the eBay API and a sure-fire monetization approach (Commission Junction revenue) made Cooqy a no-brainer in terms of building something new (a Web 2.0 RIA user interface for eBay) that would have an instant revenue model. Still, Cooqy was never meant to be a primary bread winner, if for no other reason than b/c an affiliate business model is precarious. It’s too easy and tempting for the Mothership to steal away the good ideas from their Affiliates. Sure enough, eBay eventually got into the widget game themselves with eBay To Go, which replicate much of the functionality of Cooqy’s widgets.

The germination for Qrowd actually began in December 2006 as a wall-less MySpace or Ning, that would use widgets as the basis for providing social networking features on any web site or web page. A little bit of code was developed, but I never could get passionate about the concept. That idea was eventually shelved as I worked on many consulting projects in the springtime.

Come late May, I was taking a break from consulting to start anew on Qrowd again. Around the same time, I had come across Yahoo! Pipes and Microsoft’s Popfly, both of which left an impression on me. I quickly wrote a “Qrowd Manifesto” document that described how to improve upon these new tools, then launched into full-scale development in June.

So what is Qrowd? Without sharing all the details, Qrowd is:

1. A user interface like Yahoo! Pipes for wiring together components, that will be geared for non-technical people.

2. An open-ended component builder, for technical people to contribute new components into the system. Components may optionally be shared with others. Components are developed with Javascript (or more correctly, ECMAScript) using a provided API. A visual WYSIWYG designer is planned for later that will emit LZX code, for building visual components.

3. Components are of three basic types: data input, data processing, and data output. Data input components suck in data from the web and convert it as may be needed into a common XML format for processing by the data processing components. Data output components may be visual or non-visual. Visual components can render themselves as either DHTML or Flash runtimes.

4. A meta-data engine that can process the wired component assemblies and execute the assembly either in the browser or on the server. Assembly output can be in many forms. On the server, output may be in the form of RSS, JSON, or e-mail. Assemblies running in the browser will be visual DHTML or Flash widgets.

[The purpose and utility of Qrowd is a topic deep enough for a separate, forthcoming post.]

Qrowd is being developed with OpenLaszlo 4.x, which provides support for DHTML and Flash runtimes. The recently released OpenLaszlo 4.03 has some problems with Internet Explorer DHTML support, so this has caused me to postpone further development on Qrowd until OpenLaszlo v4.1 gets closer to being released, which I hope will be around October. Still, OpenLaszlo’s DHTML support has come a long way since I wrote this post. I’ll share my recent experiences with nightly builds of OpenLaszlo in a forthcoming post. It’s not ready for general-purpose “prime time” just yet, but the promise of greatness is evident.

As of today, the Qrowd wiring editor UI for #1 above is more or less complete and runs in both DHTML and Flash. A simple API for #2 above has also been developed, and a rough prototype of a visual designer has been made. A few sample components for #3 above have been made…just enough to test the system. The heart of the system, the meta-data engine for #4 above, is maybe about 75% complete.

One of the hardest challenges in building Qrowd thus far was to find a way to run the meta-data engine on the server for generating RSS and other server-side output. The meta-data engine is implemented as an ECMAScript routine in a Laszlo LZX library, so I needed a way to run a Laszlo-generated DHTML program on the server. Fortunately, I stumbled upon the Crosscheck browser simulator, which is a fabulous piece of open-source software. Crosscheck emulates Mozilla and IE browsers, to facilitate cross-browser software testing. I took the Crosscheck software and augmented it with a live XMLHttpRequest implementation, making Crosscheck able to perform live network data operations for Mozilla emulation. Now, I am able to execute the Qrowd DHTML meta-data engine within Crosscheck with live network requests on the server. More information about this technique is available in this forum thread. Since OpenLaszlo uses the Dojo toolkit for its DHTML implementation, anyone needing to execute a AJAX/DHTML routine in Javascript on the server using live data requests should be able to follow the same technique.

As always, in building something new there is a “if I build it, will they come?” angst in wondering if I am expending my energies in the most productive manner. Creative people go through long periods of dark brooding, followed by short bursts of incredibly productive bliss. At least that’s how I am. While waiting for OpenLaszlo v4.1 to get farther along, I’ll be working on several consulting projects that by themselves are a lot of fun and challenging. While I would rather be working on Qrowd fulltime, it’s also nice being able to put some greenbacks in your wallet.