This post, about the demo of “Thermo” at the Adobe MAX keynote yesterday, has captured my imagination. It is a tool for making it simpler to create web applications in Adobe Flex, to the point where you can do it without touching any code. So far, so much yawn – there are plenty of companies out there creating what are generally termed “mashup” editors – Yahoo! Pipes, Google Mashup Editor and Teqlo, for instance. Thermo is, to me at least, different; it is described as splitting the design of a user interface away from tying that interface to the programmed logic. Simply from a product design point-of-view, this is vitally important, as it puts the user and their interface at the start and the centre of the design process, something which my colleague Phil Whitehouse has been writing about here and here. But Thermo also recognises and supports different skillbases. For the “mashup editors” I mentioned, their problem is in the name – generally, they want to help novices pull together mashups with little or no programming, but this is just not interesting. There are only so many times you can re-combine RSS feeds and Google Maps before you really go off the whole business. I have yet to see a really compelling reason to use these tools to build my own applications, rather than just take what someone else has built. And because these tools focus on the building, they are not optimized for running the mashup, which means I’d probably be better off getting a php/perl/python-savvy friend to code it for me.

Back on these skillbases that Thermo supports, they have explicitly decided to support both user interface designers, as well as allowing programmers to come in and pull the threads together underneath the UI. In creating a single environment for that all to take place, they are able to push the skillsets closer to each other, where there exists a natural grey area.

This goes right back to my statement at the start that I am an advocate of the less-technical programmer. I am careful to avoid the phrase “non-programmer” here, because I don’t believe that pursuing the goal where granny knocks up the custom applications she needs is at all a reasonable goal. There are huge numbers of people who won’t ever create applications, but are perfectly happy to use and/or pay for other people’s applications. Plus, the popular idea that everyone wants a service customised to their own needs does not mean that they need to go right back to the construction of their application to accomplish this. The group of people that I’m much more interested in helping are the large numbers of people with a very smeared and ill-defined set of web development skills, anything from having an idea, creating a user interface or making digital graphics, through to editing HTML and JavaScript, even if it means they are putting someone else’s code down in notepad and cargo-culting that. This is why Thermo appeals most to me – it is going to allow the people who have the drive to create exciting web applications do so when they cannot today, and not pussyfoot around trying to persuade my mother to mash up her shopping list with the cost of groceries across local supermarkets.

Having said all that, I should point out Paul Downey sitting in FOWA2007 has just twittered this:

#FOWA Adobe AIR and Microsoft Sliverfish have a strong presence here. Rich Applications are NOT the Web Repeat after me LOCKIN LOCKIN LOCKIN

I’m starting with a view of the Internet as a series of sexy services that we might want to mash together. But there’s a problem with this, which is that we can’t get them to talk directly to one another, so setting up mashups without some sort of intermediary is tricky or not possible in a lot of circumstances. I illustrate this with the example of Twitter – whilst it is a useful gateway from the mobile world into the web, you can’t specify arbitrary behaviour with the data it collects.

The usual solution to this is how mashups are typically written – someone writes some PHP, Ruby, JavaScript, XSLT, Perl, Python, etc. to collect the data and mash it up. That’s ok, but what if we can’t program? That’s where the idea of encapsulating some of these behaviours in “blocks” comes in. We assemble these like lego bricks to do what we want. This is not a ground-breaking idea – there are a lot of companies trying to make this easy for people: Microsoft PopFly, Teqlo, Yahoo! Pipes, OpenKapow, Proto, MashMaker from Intel, WebWidgetry, IBM QEDWiki… These services move a step away from having to write a mashup yourself, but they present another series of problems: for instance, what if I want control over my lego bricks, what if I want conditional execution and branching? The simplification doesn’t reach far enough for this customisation to happen if you’re not a programmer, if it lets you at all. Furthermore, what do we do if we want to create an interaction with services that are not a part of the Internet, what if I want to interact with my desktop, my cooker or my USB fan?

If libraries are the modular abstractions of traditional programming, with an associated environment to run in and be called from, what is the analogous environment when our libraries are these lego bricks?

There is much talk of the web as a platform, and I’m interested to see how far this idea goes. How much can we decouple programming from the IDE’s and runtimes that we’re used to, and create a new model for working in the cloud?

“Easy!” I can hear you shout. However, Osmosoft.com is a TiddlyWiki and I have had to learn how to write plugins and macros for it. I’m on the brink of either deciding that TiddlyWiki is quite an amazing tool for writing web applications, or finding something quite fundamentally flawed that is going to throw my dreams of a simple mashup IDE down the toilet… more on that as we go on.

I decided to use WidgetBox‘s handy Blidget tool to turn my J by JayFresh into a little widget, with a scrolling sidebar and everything. From there, after getting some help from Jeremy about how TiddlyWiki lets you use javascript to dynamically build tiddlers as you open them, I wrote a macro that takes one parameter – the ID of your blidget – and renders it in the tiddler.

The usage of the macro is:

BlidgetMacro "URL of blidget"

I’ve attached the source as it’s a little lengthy.

Location-based services (LBS) are clearly broken down into the spam-type services that you might encounter walking past a Starbucks and the social-type services that might connect you with your friends when you’re nearby. My view is that the widespread use of LBS is going to be encouraged because Starbucks wants to spam me – and, actually, if that involves 50% off my coffee, I’m going to let them. There are too many issues around LBS that involve me knowing where my friends are (and vice-versa) for that to take off until we have become used to our location being published as just another bit of data that we give away about ourselves.

I was going to give a rundown of the TeleAtlas presentation, but it wasn’t really very interesting. Highlights are that we’re going to see a lot more 3D mapping and on-location photography, and that according to ComScore, 27% of Internet users are getting their kicks out of mapping sites.

Much more engaging was the panel debate. I’ve tried to present a summarised transcription below, but when we got onto privacy issues, the number of floor comments was rather overwhelming… goes to show what an important subject it is.

The most impressive demo that I saw was by widr. I’m really excited by what they’ve come up with. Essentially, they are creating a database of the location of wireless networks by driving around and through user-contributions. You download a little application and it scans for nearby networks and then just asks you where you are. The genius is that this works indoors, it works on laptops, and it is cheap because it doesn’t involve mobile network operators. They’ll be launching soon, so keep an eye out.

Panel Chair: Philip Sheldrake (MD @ OnOneMap) Panel members: Rik Temmink (EMEA Segment Marketing @ TeleAtlas), Ed Parsons (Geospatial Tech @ Google), Danny Bull (Co-founder @ myneighbourhoods), Ed Freyfogle (Nestoria), John Robinson (SMSCard), John Abbott (widr)

Q. What was the watershed moment when you realised LBS were important?
A. Ed P: Google maps… Lots of valuable data is still locked up…
John R: Sufficient quality of screens on mobiles and speed of WAP. A big challenge is in deciding on a standard way of pushing someone onto a mobile website.
Danny: API’s have been invaluable; RSS too.

Q. In Asia, there are a lot of phones but they are not all as high-tech – for instance they don’t have hi-res screens. Where do emerging markets fit in with LBS?
A. Ed P: There are other ways of getting a location-based service e.g. through voice.
John A: Dodgeball takes an SMS approach to social networking.

Q. What’s the big opportunity 3 years from now?
A. Ed P: access to more information… the Google maps API came about when someone hacked their app, now API’s are central to everything they do. Other people need to unlock their data with API’s.
John R: price-points are falling for commercially available data-sets, such as the electoral roll – there is a lot of information out there and it is becoming more realistic to get hold of it.

Q. Is there a wikipedia for location?
A. (floor) Yes – OpenStreetMap.org – user-contributed location data, active in UK & Europe at the moment

Q. (to floor) Would you publish your presence?
A. (floor) Wouldn’t want spam
(floor) I would to my friends – it’s analogous to a social network
(floor) I want to choose what I show
(floor) You don’t have a choice!

Q. (to floor) Would you publish your presence if it lowered your tariff?
A. *laughs*

Q. Anything you want to get off your chest?
A. Ed P: User expectation has gone through the roof!
(floor – Tony FIsh) Why do you think so?
(floor – Simon Grice) It’s Google’s fault…
*laughs*
Ed P: That’s nice… really Google is just democratizing what has been around for 10 years
John R: Broadband adoption has been central to this

Q. Do you have problems with regulation?
Ed P: This is a hard topic. Google is talking to the European Council about this. It’s much less of a concern in the US.

Q. (floor – Simon Grice) Would you give your location data to your partner?
A. *laughs*
(floor) it is important that I am getting some value in exchance for my location
(floor – Simon Grice) texting is so popular because of its geographical anonymity

Q. What is the most innovative service you’ve seen that takes advantage of location data?
A. Ed P: I want one that wakes me up just before my train station!
Ed F: I think it’s “Doppler” – put in your location for when you are going on a journey and it tells you which of your friends are there
(floor – Simon Grice) sorting out lift-sharing?
(floor) we’ll see handset mashup innovation when it is easy and cheap to get into operators
(floor) NavSpy.com is an application that monitors mobiles on the web

Q. Any last remarks?
A. (floor – Robin Howard, BT) LBS says where your phone, not where you are…
*laughs*
Ed P: Location is only important when it is; use the off switch if it’s not

Just to recap, I think that mashups need to be able to function without your involvement and respond to stimuli. I believe that to make mashups truly useful, by unhooking them from their creators’ apron-strings so to speak, we will need a service that will let me specify inputs to watch for changes and behaviours to take in response. I’ve done some searching and not come up with anything yet.

Simon and I sat down today and built a prototype. It takes a single input (such as an RSS feed), watches it and executes a single behaviour (try calling a URL – don’t forget the http://) when there is a change. I think HTTP calls are the building blocks here, as I’m focussing on RESTful web services.

The extension of this would be to make it run server-side via a cron job or something, and attach a database so anyone can add in pairs of inputs and behaviours. This service would give your mashup the ability to work without you clicking “run”.

The link below will take you to a page where you can try it out and grab the source code too.

http://yourproblemshared.com/JonL/

Bugs posted here please!

1. Automatically publish my Google notes to my blog
2. Add entries to an online database when I twitter a certain command
3. Set up email or sms alerts for when I don’t have my RSS reader/netvibes open

I’m looking at this to determine a few different things: how they are enabling application building under the surface, what their target audience is and how much they let developers get under the skin.

The big question is how are they doing all this – according to a recent Teqlo blog post, it’s all XML schemas defining a widget’s data structure, and there is a reference to XSLT, which I guess they use to combine the widgets.

The process of building applications involves pulling pre-defined widgets on to a canvas and then defining interactions between the widgets, based on the data “microformats” that each widget can support (these are not equivalent to the microformats.org microformats, although Teqlo hope theirs can be a “superset” of the latter… complicated?). For instance, I can set my LinkedIn search widget to add a “person” microformat to my Teqlo Call list widget, which will only receive “person” microformats.

So far, so good. The builder layout could be improved, as the canvas quite often gets cluttered. The interface is built in OpenLaszlo, so there is plenty of scope to easily make the whole process run more smoothly. The application I built didn’t work though and I got an ugly javascript error when I tried to run it. Notwithstanding this bug, the process was pretty painless.

Teqlo are clearly aiming their product at non-technical users, at least to begin with. As I mentioned, they are planning to allow developers to program their own widgets in the future. I think they would be well advised to let developers get in there asap. This is a criticism I have about Yahoo! Pipes as well. It’s all well and good to allow people to build applications easily, but you want the development community to embrace and use the framework that underlies the building blocks, otherwise the service will go down the road of Ning very rapidly (while people used the pre-built apps, building new apps using their framework never really caught on).