FoWA show report - the talks

For references to sites mentioned below, visit

Over the last couple days I've been at the Future of Web Apps expo, held in Excel, London. This proved to be an extremely interesting and rewarding experience, if exhausting.

The show was structured as multiple tracks alongside an expo floor of (probably) about 20 stands. I spent most of my time in the 'Developer' track talks, in a room with a capacity of about 1200. The speakers I saw were universally of high quality and were generally world-class 'names' or experts in their field.

One thing that was striking in the talks (and in many of the stalls, I think I spoke to about 90% of them) was the strength of certain common threads:

- Interoperability & APIs
- Identity & privacy
- XaaS (Xtuff as a service)
- Taking the web offline

The core philosophy of the modern web has been described as "Small pieces, loosely coupled". In fact, the size of the pieces seems comparatively unimportant, but the coupling or interoperability is critical - web sites and services can no longer operate as islands.

For most people, the web serves primarly as a platform for interpersonal contact - not merely in the form of email, but in the newer technologies of blogging and instant messaging (and their hybrids of microblogging and moblogging) and in community sites such as facebook.

Supporting this, the assertion was also made that every site should have a community element - something that gives people a sense of belonging, a reason to stick around, and a personal investment in the site or product. Otherwise sites can be little more than posters on the wall, providing sterile information and nothing more. Even the 'online office tools' (such as Google Documents and Calendar, Zoho and Slideshare) which might seem to provide a counterpart to this assertion exist not merely as an alternative to desktop apps, but primarily to share documents and collaborate in their creation. This is taken a level further by direct collaboration apps such as Huddle, Webex, Thinkfold and yuuguu.

The primary goal then of these contact and community applications is information sharing. The critical question for each application is then what information to share with whom. An added level of complexity is then found in the problem of identifying user without requiring them to have a login on each individual site.

For example, when it comes to IM, a user may have an account on Skype, Yahoo! IM, Gtalk, ICQ, Jabber, AIM, Pownce, Jaiku, MSN messenger, Gadu-Gadu, MySpace IM, Groupwise, and Zephyr, to name but a sample of the more focussed IM products. Then you can add SMS, Email, Twitter, Pathable, Second Life in-world messaging, MySay, and internal messaging systems on any number of non-interoperable websites - without even getting into various forms of blogging which are often used as a group notification system.

(It may be appropriate here to stop and explain microblogging and moblogging. Microblogging consists of systems that are designed not for screeds of content such as this, but for short, transient messages which may be low-content, low value and/or have a limited lifetime of relevance. Moblogging is any form of blogging from a mobile, but tends to mainly be, due to device limitations, microblogging).

One solution to part of this is that provided by meecard or {mental blank here} - services which combine many of (but rarely all) of your IMs and/or IM identities in one place. Another is desktop clients such as Adium or Trillian which support (with greater or lesser tolerance by system operators) multiple IM protocols. However, these systems are essentially a domain-specific hack and do not solve the multiple password / multiple identity issue.

The management of inter-system message transmission can be provided by common APIs or micorformat data interactions, but this rapidly runs into the larger problem of multiple identity and remote authorisation. As ever, there are numerous (non-interoperable) solutions including openID, Oauth, BBAuth (from Yahoo) and Google Account Authorisation, which generally serve to remove the multiple password problem by asking one (central) web site to confirm a site vistor's identity; the user will generally then have to be logged into that central site.

The problem of authorisation is distinct from identity but often closely coupled; for the moment it is probably enough to define it as 'enabling one system to understand from another whether the user of the first system wishes to allow a user of the second system to access or modify information related to the first user, by means of identifying the second user in some way meaningful to the first system and then mapping permissions onto that second user'. Which is admittedly one hell of a mouthful, but far simpler than sinking into the minutiae.

One of the most evident cases where remote authorisation is critical lies with geolocation apps such as Plazes, Dopplr and Yahoo!s FireEagle (and possibly twitter). These serve to integrate a person's current location as a factor in service provision to provide services such as 'find a local shop' or 'find nearby friends'. Sharing with the world, for example, the fact that you've just travelled from your home to an airport, is unsafe. These data can easily be used for criminal purposes, so it is critical to be able to use a trusted location broker service which can then identify who you want to share this information with.

Leaving aside the identity issue, geodata also provides a clear use-case for cross-site data gathering, colloquially known as 'mashups'. Imagine you've an account with the FireEagle location brokerage service, and you want a map to the local non-corporate coffee house. This is generally one of those over-excited future predictions that never seem to come true, but it is actually now possible in certain situations. The method might be as follows:

Your cellphone notifies FireEagle directly of the cell ID it has just entered. Plazes corroborates this with the registered location of an open wireless network it has just passed through. You ask your mashup server for the route; it then authenticates with FireEagle for permission to know your location, possibly converting to a postcode via a third party. This data is then exchanged with a site such as delocator, which provides the locations of possible destinations. The source and destination data can then be sent to, for example, google maps, which then returns a graphical representation of your route to your smartphone.

As a possible extension, Plazes also notices that one of your friends is near to one of the cafes, by authenticating your identity and theirs, and then verifying that you each allow the other to know your position; it then informs you of this to help you make your choice. For extra points, it allows you to invite all your friends in a mile radius to join you.

This is clearly a complex operation, and relies on a number of other companies proving information and services far better and more cheaply than you could do yourself, and therefore involves much use of Xaas - Stuff as a Service, where Stuff may be authentication, identity ownership, information, location, or the hosting or software used by all parties involved. Delocator probably don't run and host their own servers. Plazes don't go out and make maps. Yahoo! didn't write the webservers they use. Each party in the pattern uses the others, and some not considered, as services, to make use of their expertise and economies of scale.

The remaining factor is that of 'taking the web offline'. With current technology, the above web app/mashup will only work while the smartphone's browser is connected to the web - once the user goes offline, even past searches and information will be lost. Two (at least) new technologies can tackle this, by allowing the service to work (albeit without new data) while the device cannot connect to the network, by providing local data storage and processing. A more evident application of this would be a webmail client which continues to work with downloaded emails while disconnected, allowing the user to read and reply to all existing mails, and can synchronise incoming and outgoing messages once the connection is returned. These technologies are Google Gears, which works inside the browser to provide local processing and storage, and adobe AIR, which allows html/css/js bundles to run as stand-alone apps.
Posted by parsingphase, 2007-10-05 13:01

Anonymous user



Contact Richard