The Dawn of the DIY Mashup
Joining a start-up has not exactly done wonders for the amount of blog posts I have time to write. Hopefully, that will improve. I have been working on trying to explain come up with a fast explanation of what Teqlo is. Tell me what you think:
What is Teqlo?
1. Teqlo makes widgets work together
2. Teqlo moves information between widgets.
3. Teqlo’s technology means that you can make useful applications by just combining a bunch of widgets
Jeff Nolan has recently posted a screen shot, that I’d like to share here.
The Teqlo application above way designed to help someone in sale identify sales leads, map out those contacts and then add those contacts to a call list. On the second tab, you can take the people from your “Call List” and start to schedule calls, even adding the events to your Google calendar.
Teqlo is going to have a whole notion of published applications, so if you heard about this app, or found it in the app directory, you could simply add it to your list of applications and start to use it. To build it from scratch is almost trivial. You start by dragging and dropping 5 widgets onto the screen: a people search widget, a LinkedIn search tool, a Dabble DB search tool, a map and a call list. To make them work together you set up some simple rules.
Playing in the Petri Dish Just Got Much Easier
Larry Dignan has an interesting article over at ZD/Net entitled Web 2.0’s legacy: The startup Petri dish
He says: “Roughly speaking Web 2.0 allows new companies to adopt readily available technologies, smush them together into some kind of hook”.
My question to Larry is this: What if it doesn’t take a company. What if mashup platform technology like Teqlo means that anyone “smush” web services into a useful application?
Personally, I think it only changes the nature of how companies with value added services go about exposing those services to the world. What counts is how many services you can integrate into, both upstream and downstream. In other words, what counts is how well you participate in the mesh of interconnected web services.
Rod - your 1,2,3 reads more like what Teqlo does rather than what it is.
An alternative: ‘Teqlo is a software services business whose sole aim is to help individuals innovate for themselves by removing the barriers to end-user assembly of useful applications from readily available software components.’
Hey Rod,
Very interesting matrix…I think the analysis is pretty much spot on.
With regards to Teqlo, how does one become a developer of Teqlets? Do they conform to a public standard? or are the proprietary to Teqlo?
I am kind of envisioning that a Teqlet is similar in nature to a JSR168 portlet? Am I close? Will you support JSON rather than XML for a data format?
Andy,
Thanks for the comment. Glad you liked the post.
Part of my job at Teqlo is to set up our 3rd party developer program. We are not there yet. The way that a teqlet communicates with a web service is all REST, so it is very open and easy to work with from the perspective of someone who has a service with an API that they want to extend into Teqlo.
When one Teqlet talks with another, it needs to expose information in a standard way, which is XML. That said, it should be easy for us to figure out a way to map JSON to XML. My guess is that the big issue for a teqlet developer will not be the data transportation protocol, but instead the issue of what schema to use. Teqlo is going to publish a whole bunch of micro schema. Where possible, we are going to make sure they can easily be mapped to the microformats and microformats.org using a simple XSLT.
I am afraid I do not know much about the JSR168 portlet, so I can’t comment properly.
Thanks for the questions.
Rod