We launched a developer preview release of our service last week, but as I wrote in my previous post about this it is clearly not consumer grade or even very productive at this point. What we came out with is a proof of concept release that is, in fully honesty, missing a very big piece of functionality.

In order for the web service components to communicate and pass data we had to build a, for lack of a better term, formula editor that was easy enough for newbies but sophisticated enough to enable meaningful interaction with the components. In fact, instead of formula editor a better name might be “interaction editor”.

This is not a trivial piece of development and truth be told we ended up scrapping the first two subsystems we wrote to enable this. The first was a lesson in usability because we approached it in a very linear and logical fashion, we developed a macro language that the user/assembler could use to describe the passing of data between components. It became clear pretty quickly that this approach was going nowhere fast despite the fact that it was the most reliable and simple way for us to build it.

The second version looked at the actions and reactions of components (more on that in a minute) and built a graph that articulated all the possible ways that the teqlets could interact with each other. This was an elegant way to present it but it had a major shortcoming, the complexity of the graph at the server level could quickly overwhelm our server capability. Strike two.

The most recent approach that we tried relied on a more restrained method of calculating possible teqlet interactions, much of which I can’t disclose because it represents some unique IP that fits hand-to-glove with our already issued patents for automated sequencing of components.

What I will describe is the very essential notion of actions and reactions that we rely upon. By way of example I will use the very well worn ebay/googlemap mashup scenario to illustrate this concept. Our Ebay search teqlet expresses some distinct actions as a byproduct of the core search capabilities that it encompasses, two very basic actions being “select” and “deselect” an item in a list of search results. The Google Map teqlet has capability for expressing actions, but more relevant to this example is the ability to react to other teqlets actions, in this case “add marker” or “remove marker”.

The strong data typing that is represented in the microformats attached to each teqlet is a cornerstone for the kind of data routing that we are enabling and is evident in the sequencing machinery that we have built. In this case the selection of an item in the Ebay search list causes the Google map to react by plotting a marker on the map, and in order for the geocoder to pass longitude and latitude for the map point it must have location data, which is neatly conveyed in the location field generated by the Ebay teqlet.

We’re pretty confident that our approach to enabling the communication of components is going to work well and satisfy a continuum of usability that spans casual users to the more experienced. Like much of what we are building there is little that we can look to as pre-existing solutions to model off of, in other words we often have to build it to test it only to find that it’s throwaway because of something not evident until we actually tested it. At any rate, we’ll have the revamped formula functionality in place and tested by middle of this week meaning our preview release will get a big shot in the arm in terms of user productivity.


Technorati Tags: