Deconstructing d.Construct

I got down to Brighton bright and early for d.Construct Clear:left's grassroots web 2.0 conference. After being ushered in by Richard Rutter through the side door along with a couple of other early birds I sat down and booted up my powerbook to check my mail on the free Wi-Fi. At that moment osX told me that my home network was unavailable and that I could log on to "open_connection". After I ok'd it I was on the internet, this is the sort of thing that sets apple apart from the rest - simplicity itself.

The following overview of the first four talks is based on my recollections and the notes that were made by everyone who took part in the SubEthaEdit collaborative note-taking sessions. A full copy of the SubEthaEdit notes is available here and I link to it at relevant points throughout this post.

What is Web 2.0 - Andy Budd - View notes

Andy Budd was first on with his talk about 'What is Web 2.0'. Andy was defining Web 2.0 as being more than just an application that makes use of AJAX, instead he was stating that the following are some of the following attributes are typical of something that could be described as Web 2.0

Openness of data - the ability for the user to be able to input and extract their own data
Available to all user-agents/devices
Easy to use. Great user interface
Desktop performance on the web
Social features
Genuinely
Applications that solve old problems with new thinking and ideas.
Use of AJAX should degrade gracfully so that the application still works when javascript not available.

During his talk Andy took a lookwith a look a several application he thought were good examples of what Web 2.0 is all about.

Although there are plenty of people out there who have been dismissive of Web 2.0 as just another buzzword Andy's thoughts were that Web 2.0 was a necessary term that grouped together features and technologies to describe the future of the web. Andy touched on the fact that anyone using javascript to enhance an application needed to do so by making the applcation useable and accessible from the start and that this wasn't something that could feasibly be added on afterwards.

DOM Scripting and Ajax - Stuart Langridge - View notes

Stuart Langridge, author of the highly recommended Sitepoint book;Dhtml Utopia. Stuart started by saying using unobtrusive javascript we as web developers could enhance the end result for the user. Javascript used to be about unicorns following your cursor whereas now it's role could be seen as a powerful means to add functionality to an application.

Stuart stressed that use of javascript needed to only exist in the "behaviour layer" and that adding javascript to a page should only require script tag and a source attribute. Stuart suggested "If you need any more than that the you're probably doing it wrong". In other words events should not be dropped into your markup nor should you put javascript in the href.

Stuart made a good point that accessibilty and usability should not be left out as you rush to market with your amazing web 2.0 application, in addition a site should still work without javascript. Gmail is a bad example of web 2.0 as google created two separate applications. This approach is unecessary as by hooking in events and hijacking links (hijax) a working application can have the client-side enhancements dropped in.

Stuart rounded his talk by saying that by standing on the shoulders of giants (existing developments) we are able to take the web forward and make it better. Web 2.0 is about evolution not revolution.

Ajax and the Flickr API - Simon Willison - View notes

The biggest thing I got from Simon Willison's talk about Flickr is that Flickr is an application built around an API rather than an API built on top of an application. As Simon mentioned Flickr is the largest user of it's own API.

As users might be worried about submitting data to a small start-up flickr started by creating an API for users to build tools around. This lead to innovative "Flickr as the platform" applications

Flickr's API uses the following technologies:

In the REST - Representational State Transfer architectural style. Which is largely academic but refers to the way in which information is accessed via URLs.

Flickr's API has many public methods of which some require authentication (naturally for deletions user information etc) some of these methods return different data based on whether you are authenticated or not. Flickr's API has a browser available at http://www.flickr.com/services/APIwhich allows the developer to play with the API online without having to worry about setting up function calls.

Simon described flickr's use of their public API as akin to "eating their own dog food" this is to say that if the API was to break then Flickr itself would break too. Hence they are very focussed on maintaining the API in good health.

During questions Simon was asked what kind of server side technology was in use. Simon replied that they make heavy use of PHP and MySQL and interestingly that Yahoo even hired PHP creator Rasmus Lerdorf to help them out.

Backstage BBC - Ben Metcalfe - View notes

Ben started his talk by describing what backstage.bbc.co.uk is. In essence the BBC wanted to connect with the community to allow re-use of the BBC's content in an official and licensed (non-commercial) capacity. The BBC's reasons for doing this were that they wanted to encourage community interacation and innovation whilst continuing a drive to be seen as "open". Backstage is also seen as a way to identify and showcase talent as well as allow the Beeb to be a public service for the 21st century.

Backstage offers developers access to feeds and data sources including listings, travel information, message boards and more data as it is added so that it can be utilised in new and interesting ways. Remixing of information with other internet services is actively encouraged. As a example Ben showed a site that remixed travel camera data with the google maps API.

The end result benifits the creators of backstage applications to showcase their work whilst retaining the rights as long as their implentations are strictly non-commercial. In addition the BBC want to work with the producers of successful prototypes and help them take their applications to the next level. Ulitmately this may result in some of this work being implemented back into the organisation to benefit the users of bbc.co.uk.

Ben took us through MightyV.com a backstage competition winner. Ben said that MightyV.com is a good example of how to use AJAX well. MightyV.com basically is a Web 2.0 front-end to the BBC's tv listings information complete with mouseovers and RSS feeds. The developer's prize was a rackmount server.

Som of the issues that the BBC faces in bringing about the backstage project are to do with rights management as the BBC doesn't own all of it's own data. In addition there is alot of data that doesn't reside inside a CMS and is therefore not in a database. However gradually old content is being added from the BBC's vast archives and rights holders are beginning to see the benefits of alternative business models.

Ben finished up his talk with a look at the BBC Programme Catalogue which is an application still in development which gives access to the BBC archives. Utilising Ruby on Rails and using REST architecture The BBC Programme Catalogue is likely to launch in early 2006 as an experimental means to access the BBC back catalogue kind of like an IMDB for the BBC's content.

Other d.Construct resources

I am only covering the first four talks at d.Construct as these are most relevant to me and to be honest I need to listen to Cory Doctorow's talk on the podcast to be able to totally assimilate the information! For further coverage please check out the following sites.

Thanks to Andy and Richard and all of the speakers for an excellent conference. Unfortunately I wasn't able to hang around into the evening as I had been coming down with a nasty stomach bug all day. So I steamed it home after one pint and went straight to bed. Thanks to the SubEthaEdit sessions I ended up dreaming about collaborative note-taking until 10 o'clock the next moring. Great :-).