Tags: dconstruct06



Saturday, February 24th, 2007

The diversity division

After the Future of Web Apps 2006 conference in San Francisco, a post by Chris Messina lamenting the lack of women in the line-up prompted heated debate and high emotions.

The Future of Web Apps 2007 conference just wrapped up in London and Jason Kottke has reignited the debate. What’s changed since the last time? Not much.

Tempers are still getting frayed and the discourse is generally pretty unhelpful.

Let me say from the start that I do think there is a problem with having so many conferences with such unbalanced line-ups and I firmly believe that a lot of the responsibility lies with the organisers to change things. That said, I also understand just how hard it is to put on any kind of conference at all.

To the people accusing conference organisers of being some kind of cabalistic old boy’s network: you’re really not helping. You’ll catch more flies with honey than vinegar.

To the people organising conferences who throw up their hands and say “it’s not our job, we’re just reflecting the sad reality”: you’re being equally unhelpful.

So, all of you: try walking a mile in the other person’s shoes. That way, if you still don’t agree, you’ll be a mile away from the other person and you’ve made off with their shoes.

Eric came out with a provacative post that’s just aching to be quoted out of context:

So, here it is: as a conference organizer, I don’t care about diversity.

I admire and respect Eric but I think in this instance that he is wrong. We’ll just have to agree to disagree.

Eric makes the very persuasive argument that to put on a successful conference, the line-up needs to be filled with well-known, established speakers. (This prompted the obvious question from a few people in the comments; just how does one become well-known or established? As Jen says, Eric, it is becoming a circle jerk.)

Success doesn’t just mean financial success, though I readily admit that the economics of organising a conference are fiendish. A successful conference is about more than just getting bums on seats.

Yes, if you fill a line-up with “A-listers” then you’ll sell all your tickets and the attendees will learn from the best and everyone will be happy… in the short term. In the long term, it’s unsustainable. It leads to a closed loop, a neverending cycle of the same names talking about the same subjects. Diversity isn’t just a means to an end (that end being a better conference), it is in and of itself, A Good Thing.

Conferences, especially well-established conferences (and I would put An Event Apart into that category) can and should take some chances. Yes, it’s risky. No, you can’t guarantee ticket sales. But it will be a better conference if the line-up has some wild cards.

I firmly believe that conferences shouldn’t simply be mirrors for the Web business, reflecting whatever is current and accepted. A good conference can act as a force on the industry. Conference organisers have a great opportunity here and I think it’s a shame to see it wasted.

Alright… enough talking about conference organisers as if they were some kind of separate caste of people. It’s time to point the finger at myself.

My company, Clearleft, organises the dConstruct conference in Brighton every year. It’s really Andy’s baby but he very kindly asks for my opinions in putting the conference together. I personally feel very strongly that this year’s dConstruct needs to change from last year’s homogenous line-up (I’m pretty sure Andy agrees).

Even if we sell every ticket, even if everybody blogs about having a great time, if the line-up consists of a bunch of white male speakers (“A-list” or otherwise), I will consider the conference a failure.

But what to do? The perceived wisdom is that there are simply far more kick-ass men speakers than women. I don’t believe that’s true. I think there are far more visible men in our industry, but with just a bit effort it’s entirely possible to find a wealth of women speakers who can truthfully be described as well and truly kick-ass.

I’m not sure if I’m supposed to blog about this, but for months now, we at Clearleft have had a BaseCamp project set up with the specific intention of finding new blood for dConstruct. We’ve invited people from outside our circle of expertise and interests and asked them to suggest speakers. The idea is to deliberately introduce diversity, to stir things up a bit and ultimately, to put together the most kick-ass line-up of speakers we can.

Is this tokenism? Absolutely not. I fully concur with Eric when he says:

What’s important is technical expertise, speaking skills, professional stature, brand appropriateness, and marketability.

But I don’t believe that this attitude conflicts in any way with the desire to increase diversity. It’s entirely possible to put together a superb line-up of diverse speakers.

Don’t believe me? Take a look at Web Directions North (or South for that matter), one of the best, most stimulating conferences I’ve ever attended. They didn’t make a big deal about the mixture of topics and presenters, they just put together the best line-up they could.

I’m not saying it’s easy. I know for a fact that it’s a lot of hard work. But it’s achievable; Web Directions is a testament to that.

I’m also going to have to agree to disagree with Tantek, another person I admire and respect greatly. He is of the opinion the kind of thing I’m suggesting would indeed fall under the category of tokenism:

Why is it that gender (and less often race, nay, skin-color, see below) are the only physical characteristics that lots of otherwise smart people appear to chime in support for diversity of?

Where are all the green-eyed folks? Where are all the folks with facial tattoos? Where are all the redheads? Where are the speakers with non-ear facial piercings?

Actually, I would agree with Tantek if I were talking about diversity of sexes, but I’m not. I’m talking about diversity of gender. There’s a difference. Sex means male or female. Gender means masculine or feminine.

I fully agree that a speaker’s sex makes about as much difference as their eye-colour or hairstyle but a speaker’s gender can and does affect their outlook and experience. As someone who has a (primarily) masculine gender, I know that I can learn a lot more from being in a mixed masculine/feminine environment. That’s one of the reasons why I’m glad my band isn’t an all-male affair.

I’m not just arguing semantics here. I’m trying to point out why I think Tantek’s argument is reducto ad absurdum. Gender isn’t like eye-colour. Introducing more gender diversity into a conference is productive in the same way as introducing someone with a background in product design or some other non-Web field that can offer a new perspective on our industry (this isn’t just an off-hand comparison).

I hope I’ve made my point clear. Let me reiterate that I can see both sides of this debate but I do come down firmly on the side of increasing diversity. I just hope that I can work towards this goal in a constructive way.

Frankly, I find Jason Kottke’s reductionist statistical approach to be counter-productive. It’s not just about numbers, Jason. I’m also not so sure that Anil’s abrasive style is particularly constructive but his clever riposte to the Future of Web Apps line-up is illuminating.

I do feel bad for Ryan. He always seems to bear the brunt of the blame even though plenty of other conferences are equally lacking in diversity.

However… I do take issue with Ryan’s attempt to wash his hands by pointing out just how many of the speaker slots were bought by sponsors. I’m sorry, but selling time slots to the highest bidder is no way to put a conference together. I’m well aware of the economic realities of putting on a conference and I know that selling slots to sponsors is established practice in certain circles but it won’t cut it with the geek crowd.

Again, Web Directions North managed to get this just right by allowing companies to sponsor speakers. So the speakers were all chosen for their expertise, knowledge and perhaps even diversity, and then Adobe or Microsoft were given the opportunity to introduce the speakers. It sure beats product pitches.

I want to finish with an observation on this whole issue of gender diversity at Web conferences.

This debate isn’t going to go away. It looks like it’s going to flare up every few months. Clearly, plenty of bloggers—who are also probably the target audience for a lot of these conferences—really care about this issue and want to see some changes. Yet every time the issue is raised, conference organisers fall back on the argument that they need to fill the auditorium and that the best way of doing that is to give people the same “A-list” speakers that have always worked in the past. In other words, give the people what they want.

Well, we want diversity.

It’s kind of like the whole brouhaha with Adobe and their crappy new icons. The majority of Adobe’s potential customers disliked the icons and wrote good, well-reasoned blog posts explaining why. As Aral so excellently noted, Adobe deliberately chose to ignore this wealth of valuable feedback. I see conferences falling into the same trap. The very fact that this debate is taking place (and continues to take place ever more frequently) should be sending a message that this is an important issue that needs to be addressed.

It reminds me of the old joke. A guy walks into a shop and asks for some product or other. The shopkeeper says, “We don’t stock that. There’s no demand for it.” The shopkeeper then adds, “It’s funny: you’re the tenth person to ask for that today.”

Friday, October 6th, 2006

Melbourne calling

My time in Melbourne is almost at an end. Thanks to everyone who sent tips on places to go and things to see here. Most of my activities, as evidenced by my Flickr pics, have revolved around food. I must get around to writing it all up on Principia Gastronomica.

I took some time out from my culinary explorations to give a talk at the local Web Standards Group meetup. It was fun. I recycled my talk from d.Construct, The Joy of API. People seemed to enjoy it and there were a lot of great questions asked afterwards.

The audio from the talk at d.Construct is now available through the podcast. I’ve had the audio transcribed — using Casting Words — and I’ve posted the results here.

The Joy of API

A presentation I gave at dConstruct 2006 in Brighton.

OK. Yeah, I’m not going to be talking about big business benefits or you know business models or anything like that. This is going to be a much more sort of a personal look at APIs. I am not from Yahoo!, I’m not from Amazon. I’m not from a big company. I’m just a lone developer and I want to talk about my experiences. Specifically, I wanted to talk about the fun, the happiness that you get from APIs because you can get a lot of joy out of it and mostly though, I just want to talk about me. So that’s what I will be doing for the next 45 minutes.

So joy, where do we get joy from? Ignoring the obvious answers to that question, let’s focus specifically on technology and where does this joy in technology intersect and I am going to cast my mind back to the first time I remember getting joy out of technology. Does anybody else? Did anyone else have a ZX81? Yeah, OK, cool. 1K, 1K of memory was what you had to work with, with this. You had to be very creative. But it was a lot of fun. Everyone has done it 10 print, 20 goto 10. OK, we’ve all done it. It’s just fun. It’s fun playing around. Later on, we’ve all got our Spectrums and we started playing adventure games and stuff like that (Thorin sings of Gold).

Many years later I left computers aside. I sort of went off wandering, hitchhiking and busing across Europe for a while. Many years later I came across the Web and I didn’t get the Web at first till I came across this site Fray.com which was years ahead of its time. I was surfing around. I was looking at all these web sites and I was “I don’t get it”. I don’t get why the Web is big and I came across Fray.com and I got it because I had an emotional reaction. What it was, was stories. People were telling stories and the design was always driven by the story. Story drives design which is something I’ve held onto, until this day. Fray made me want to learn HTML and that was where I found joy, which was with HTML. This idea of marking stuff up with tags, I loved it. I really got into it and I decided I wanted to do this. I wanted to play around with this.

So at the time I was living in Germany and playing in a band, and we decided we should have one of these new fangled website things. So I said, “I’ll try it. I’ll do it. I want to get into this.” So I did. This is my very first website. I am bearing my soul in showing this. It’s not too bad. It’s not a Geocities page at least, right? But this is 1998, 1998 I built this so it is going back a ways. It was really good fun. I really enjoyed it and I picked up skills. So I was picking up some Photoshop skills, some HTML skills and I found that a lot of the skills I picked up were always on personal projects like this. I made my own website adactio.com. This was what it used to look at. It was full of DHTML stuff whizzing around. Remember in the 90s, the kind of stuff we got up to? This was the epitome of gratuitous effects. It was terrible really but I learned JavaScript for what it’s worth. At the time that sort of DHTML stuff wasn’t much fun to do. There wasn’t much fun to be had from DHTML but I was learning. I was learning new stuff by doing these personal projects.

And then I created this site and this is a community site built around Irish music and here it turned into a big site with all these tunes and albums and discussions. So my skill that I needed to learn here was database skills and I was learning PHP and MySQL, all this stuff. So I was having fun and picking up these new skills but there is a particular part to this site I want to draw your attention to, that’s down at the end of the navigation where it says shop. Because on this site you can through to the shop, there’s a search thing at the top and you search Amazon from this site, from the thesession.org. So I’ve typed in the name of a band. I get the results. I click through and I get to display all that information in my site, marked up the way I wanted, looking the way I wanted and that’s all possible because of Amazon’s API, exactly what Jeff was talking about earlier. So this was something I just wanted to mess around with. I knew that it would add value to my site. It was probably going to be some fun and it was relatively painless because of this documentation that Amazon provides. It provides pretty much everything you need to know. There is documentation but more importantly, there are examples, because that’s how I learn stuff. I looked at examples and I picked apart the code. I mean, view source, OK, that’s how I learned HTML. That’s how I learned JavaScript, CSS. Here’s what you need to do to put together a query to get some information in an XML file and that’s pretty cool. What’s interesting though is down at the bottom you’ll see that there is general request parameters and one of those is XSL. It’s one of the coolest things that Amazon’s web services allow you to do. They allow you to specify an XSL file then you can mash up the XML and XSL files and output it the way you want to do it.

Let me just show you that. Warning: code ahead. But it’s sort of pseudo-code and it’s not going to get very complex, it’s more just the idea of it. How do you use these web services — and really nitty gritty — how do you even start to use them? You need some kind of server-side language to do this. I was using PHP, so that’s what I’m using here. So first begin with the URL — the URL to the particular method on the Amazon web services. Start with a URL and you start adding all of these parameters to it, so my Amazon associates ID so I will make some money off of these sales. My API key. Most API’s make you sign up first — they give you a unique key and you have to use that in every request you make, so that’s mine: don’t use it. The important one in red there: I’m pointing to an XSL file. I’m saying don’t send me back raw XML. Before you send the result back to me run it thorough that XSL file. So I put all of those parameters onto the URL and finally I just spit out what’s left. So I’m using very simple PHP functions to do that.

Here’s what the Amazon web service would send back, roughly. This is a very simplified version. But it’s an XML file full of stuff, and some of this stuff in here is the information I want to get out. So there’s the name of the band, the name of the album and that’s what I want to get out and then I want to mark it up in markup. So, I run that through an XSLT file to do the transformation. XSL is an interesting one because you can see it’s tag based. It’s like XML. It’s a declarative language, but it’s also got sort of programmatic aspects to it because you can select things, you can do loops. It’s a strange mixture of programming and mark up. A lot of people have a love/hate relationship with it. It’s actually pretty powerful and it’s a good skill to have. And the nice thing is that you can mix it up with regular mark up. So I’m mixing it up with HTML. And it’s like a template language, it will insert the relevant data in there and the result is I get mark up with the empty spots filled in with the data I wanted and then I can display that on my site like that. And that was a lot of fun. That was actually joyful. I got a lot of fun out of doing that. And, you know, I make a bit of money when people click through, but that wasn’t really my reason for doing it.

This is all possible because of this idea called REST, which supposedly stands for Representational State Transfer. And it’s more an idea of how to build these services together. There’s a number of different sorts of thinking behind what make something restful, but basically what it comes down to is you have these resources that are uniquely addressable, usually through a URL. And it’s stateless. There is no keeping track of who is logged in and whose not. And if this kind of thing looks familiar — this idea of stateless, uniquely addressable resources — that’s because that’s the Web. That’s how the World Wide Web was built, using a RESTful method, methodology, really. It’s pretty easy, because once you get your head around that you realize all you do is put together a URL and grab that and there’s your information from a third party service.

The other idea, the sort of opposite to REST is something called SOAP, which is an acronym S.O.A.P. and I think we all know what that stands for. I’m not going to go into much detail about SOAP because it is far too complex, unnecessarily complex really. I have played around with SOAP. I had to because one of the other things I wanted to put on that site was Google search. I wanted people to be able to do everything from my site. I didn’t want them to have to go off to Google just to do a search. And you can use Google’s API to get searches on your own site, but it’s only SOAP, you have to use SOAP. And I’m not even going into the technical details. Basically, you have to create an XML file, send that off, then you get the XML file. Way too complex, not much joy to be had. It would be nice if Google would provide a RESTful interface. I did do it and, you know, I got this interface on my site and into Google’s search facility, which was nice, but not much fun.

Where I did get joy was when I started using Flickr. I love Flickr. I really like Flickr. I started using it when I came back from South by Southwest last year. Everybody was using Flickr and I decided I needed to check this out. I started taking pictures, putting them up there. I was reluctant at first because I already had image galleries on my own site and I didn’t really didn’t want a third party hosting my images, but they did such a good job I decided to go with them. Then I started exploring other services to host my stuff. So, Delicious for hosting bookmarks and then I started using Upcoming for keeping track of events and stuff like this. So a lot of my data started going outwards with other services providing the infrastructure. So I have my own website and all around that, all over the web there was all these bits of me. So, Amazon would have my wish list and Flickr is where I’m keeping my pictures. Del.icio.us, that’s where my bookmarks are and Upcoming, that’s where all of my events are. So, they’re all over the place, scattered over the web and I wanted to be able to draw them into that central location which was my own site and that was possible because of APIs. Flickr provides loads and loads of methods so that you can do just about anything. Del.icio.us also provides an API, a little trickier it must be said because it requires a secure authentication thing but you can still get all your bookmarks. Upcoming, you can also get events and stuff, again, not quite as friendly as Flickr’s but pretty powerful.

And here’s how they all pretty much work. Again, you begin with the URL. Now none of these are providing XSLT transformations, which is a bit of a shame and it would be nice if they did. So I have to parse them some other way. So I begin with a URL and in this case I decided to use PHP5’s DOM functions because I was familiar with the DOM already from client side DOM Scripting. So I load in the document and it turns into a DOM structure and then I can just go through it using the usual DOM methods that I am used to from JavaScript, you know, getElementsByTagName — that’s one of the nice things about the DOM, you get to recycle your knowledge — and then I can spit it out onto the screen however I want.

My original idea was I would bring this into my blog. I have a side bar down the side and I thought Oh just pull in, you know, what lots of other people are doing, a couple of Flickr pics and the next few events I will be going to on Upcoming and maybe a couple of Del.icio.us links but it grew and grew and grew into this sort of monster where I ended up creating a whole sub domain, Adactio Elsewhere to hold all of this stuff.

So I didn’t just put in my Flickr picks. I put in my Flickr pics, the last few Flickr pics from my contacts, also the list of all my contacts and you don’t just have to look at my pictures, you could click on anybody’s name and then you will see their pictures and their contact’s pictures which is one of the funnest things about Flickr is following these trails. Here are my pictures. This person’s a friend, here’s this person’s pictures, here’s the pictures of their friend and you end up going into through this whole network of pictures. Great fun.

Amazon, as well as doing a search that I was doing on the other site, I already had the code for that so I just threw it in there, also having my wish list here so I could have easy access to it. Delicious, pulling in the last links. Also being able to search my links straight from this one place and Upcoming, just grab the newest events. All on one page, all on an AJAXy sort of interface. That was something else I was learning about at the time. So pretty good fun.

Let’s see how they stacked up. Let’s rate the APIs of these various services.

I am going to rate them by the amount of power you get from them, documentation and just plain joy: that indefinable something. And so, first of all: the power. Flickr provides APIs for just about everything. I think the only thing you can’t do with the Flickr API is get the comments. You can get the number of comments on a photograph but you can’t get the actual comments on the photograph but pretty much everything else you can do yourself. You can create a one to one copy of Flickr almost just using their APIs and this is probably because they use the APIs themselves. They eat their own dog food.

Now Amazon is very powerful as well. Again, you can create an entire Amazon of your own pretty much and put a nicer interface on it, put nicer markup in there. [Laughter] At some point you do have to go out and go to the checkout process. You can’t quite go all the way through but pretty close.

Del.icio.us and Upcoming, yeah a little tricky, I’ve got to say. They make you jump through a lot of hoops. You can’t just grab all the information about an event, you have to grab the event id, then you have to grab the location id and then do different methods for each one of those to get the details. They make you jump through hoops, Del.icio.us, the thing that is kind of tricky, you have a lot of access to your own bookmarks but not so much access to other people’s. So there’s kind of limited room for mashups involving other people’s bookmarks there.

Documentation, let’s see how they did. Pretty good. Both Flickr and Amazon scored well. They have good online documentation on their sites but almost more importantly they have good communities. There’s mailing lists and of course there’s a Flickr group. A good place to go and discuss is the Flickr mailing list. The Flickr developers themselves hang out there so you can get answers pretty quickly from people who really know their stuff. Amazon, there’s a lot of documentation on the site. It’s improving all the time. It’s something they are putting a lot of effort into. Del.icio.us and Upcoming less so but you have to remember where they came from. They were small startups and they were only bought up by Yahoo! fairly recently. So basically a couple of guys in their bedroom doing each of those services so their documentation is understandably a little thinner on the ground.

So, let’s see, the final scores please. How did the APIs do? The winner there is Flickr for joy and it is partly down to the subject matter. There is just so much fun messing around with photographs. Amazon is good. Amazon came second but you are dealing with products and shopping and stuff like that and there is a lot of fun to be had there but there is just something sexier about photographs, I think, so Flickr has a bit an unfair advantage and the others did pretty well. So there’s the score card. Those are just four service. There are hundreds if not thousands more APIs out there. This site keeps track of all the different services that are out there being provided by all these providers, from the very big to the very small.

There are a lot of APIs out there and what this cornucopia of APIs creates is a parallel Web. Instead of being a Web of documents, it’s like a Web of data. The kind of data you get there is identity for one; my Flickr photographs, my Del.icio.us things, all of these things that are mine. The ultimate identity API would be where you can actually safely store user names, passwords, credit cards with a third party and have that trusted, but that’s still future talk but right now, my things. Events obviously, so upcoming for that, eventful, there are a whole bunch of services based around events. Relationships, that’s where all the social networking stuff comes into it. There’s a lot of social networking sites out there all built pretty much the same way. Most of them have APIs. And here’s one that I haven’t even touched on: location. Location is a really big one and location is kind of like I said Flickr was fun because of the subject matter. Location is really fun because of the subject matter.

Dealing with maps is an awful lot of fun. I remember the joy I had when Google Maps came out. Does anyone remember what it used to be like when you would have to try and browse a map and all you had was Mapquest? I mean these days if I come across a Mapquest image on a website, I try to drag it. I forget that’s it is just an image. I have become so used to Google Maps and all the great maps out there now, I expect to be able to pan around a map. I had so much fun with Google Maps when it came out, not doing anything useful just browsing the world, you know just looking at landmarks. It was very enjoyable.

And it wasn’t long before people started using Google Maps for their own purposes and this is something that gets pulled up again and again, the Chicagocrime.org where Adrian Holovaty mashed up crime statistics for Chicago with Google Maps so you can see which neighborhoods were the most dangerous. Here are the first degree murders in Chicago and you can figure out what neighborhoods you want to stay away from and everyone brings this up as a good example of a mash up. Why I am bringing it up of interest is that this was built before there was an API for Google maps. The interesting thing about Google maps is it’s not to do with sending XML from a server. It’s all JavaScript and with JavaScript, you can view source. Now they did obviously obfuscate everything and there were line breaks stripped out but if you have the time, you can go in and you can view source and you can figure out how Google is doing it and you can create your own mash up, which is exactly what happened here and this is probably what got the Google guys thinking, you know, people can do some pretty cool stuff if you release this API publicly, which they did. So that’s a good example.

I have seem others that I really like and Eric Meyer did this one which is the High Yield Detonation Simulator [Laughter] after he had an argument one evening with somebody at dinner whether New Jersey would get blown off the map if New York got hit by a bomb. So you can put in a location and the amount of kilotons. [Laughter] So this is 100 kiloton bomb dropping on Brighton, dropping actually on the Corn Exchange. It’s OK. The university survives. That’s a nice one.

My absolute favorite mashup with Google Maps is this thing called Overplot where they’ve taken a blog… has anyone heard of Overheard in New York? It’s this blog where people submit little snippets of conversation they overheard on the street. They submit the little snippet but also submit where they heard it, corner of 5th and Broadway or whatever. Well this guy took the entire archive of that site by just going through the Google reader, RSS reader, mashed it up with the maps to create this map of New York with all the conversations mapped onto it. You can zoom in and you see all the conversations on each street corner and you can zoom in and you can start eavesdropping and you get the context. That’s the really great thing about maps. It’s one great thing to read, you know, that this [Laughter] occurred on the street corner. It’s another thing where you can actually see the surrounding area and you will love it. It’s a complete time sink. If you go to this site, be prepared to spend hours [Laughter], I mean hours, looking around. It’s great. That’s the great thing. Context. Context is something that maps do really well.

Something similar to this is something that Gawker did. They put together the Gawker Stalker because they used to have people call in celebrity sightings. “Hey, George Clooney is having lunch at this restaurant downtown.” Well they took all these sightings again and they mashed it up with location. George Clooney hates this site. He really doesn’t like it. So you can see celebrities being stalked all over the place and I decided I wanted to try messing around with this. I wanted to check out the APIs.

So I found an opportunity to mess with Google maps this year at South by Southwest. There was a lot of parties going on. I had gotten together all the parties, written them all up an HTML page, marked them all up and I wanted to mix it up with Google maps so that I could see how far apart these parties were and then I could decide which ones I can go to and which ones I can avoid. So you’d click on a particular place and say that’s where it is right there, right where the big beer logo is and you click on other places and decide well, that party is too far. You get a lot more context with maps. It’s really good fun.

This is an idea I recycled for d.Construct, same thing. I had all this information about places we can go grab some lunch, pubs that have free wi-fi and instead of just providing that in text form, mash it up with a map and then you can see how far away — there, that is how far away the best Japanese restaurant in Brighton is from the Corn Exchange — then you can make a decision based on that.

So like I said, it’s not XML this time. It is JavaScript and you do have to know some JavaScript. It was kind of fun. It was kind of fun and one of the interesting things, this was something Paul mentioned, Google were the first out the door with a mapping API. Yahoo! followed and they very wisely pretty much copied the Google Maps API. In fact, I decided to just to play around. I wanted to re-implement this but using Yahoo! Maps and all I had to do most of the time was to change the letter G to the letter Y and everything just worked. [Laughter] I ended up sticking with Google because this is how the Yahoo! equivalent [Laughter] appears [Laughter]. Yeah, not so much context, [applause] I’m not getting quite the information I need with all of that but I do not I’m not blaming Yahoo! because the mapping situation, as Paul pointed out and Simon, is very complicated, the data providers, it is very annoying which is why it would be great to get those guys out of the picture and we should be providing the data which is something that these guys are doing, OpenStreetMap.org. They are mapping the world from the ground up. Instead of this top down, data is coming from these mapping providers, these guys are going out there and they are mapping the streets and they are having a workshop tomorrow here is Brighton and we will try and map as much of Brighten as we can. It going to be a lot of fun and I recommend everyone come along. They have an API which is great. There is an associated project called Free the Post Code because the Royal Mail has a monopoly on post codes in this country and they charge for this data. But we all know our own post codes. If we can just say, here is my post code, here’s my location, latitude, longitude. If everybody did that, then we could have a free API for post codes which would be great. So, all this data is getting freed. There’s this web of data. People want that web of data to be free.

Parallel to this web of data, there is something else going on. There is the live Web. Data tends to be fairly static, you know Amazon products, Flickr pictures, they’re there, you can go to them anytime. There is a lot of stuff going on the Web now that’s just like drinking through the fire hose. There is just so much going on and mostly through the RSS is the best way of getting access to this stuff because it is so fast, you need some way of keeping track of it.

And the other way of making sense of it is tagging and a site that’s really done the best job of combining these two things together, keeping track of all these conversations, there are lots of sites doing this but Technorati is particularly interesting for keeping track of the live Web and one of the reasons why I find it interesting is the fact that it provides an API. Again, RESTful, you just point your code to the URL. Send it to parameters and you get back XML and you have to parse that XML.

So I decided to use the power of the live web on my own site. I started tagging my own posts a while back so you can see about my own posts and then I added in calls to the APIs for Del.icio.us to get my own links and to Technorati to see what other people are saying about the same tags and then display that in the same page. So this is first of all, who is linking to this site? That’s really useful. It’s like what you need your stats for but here I get it inline. Who is talking about what I’ve just blogged right now, this minute well I can get that information from Technorati and who is using the same tags? In a very meta move, this is who’s tagging with “tagging”. So I can keep track of all of that in one place. And it was good fun. The API is pretty straight forward for Technorati. Sadly, it’s pretty flaky. It must be said. Technorati could do with some new servers, I think, because it tends to drop a fair a bit. That’s just my own personal experience. Everything I am saying is my own personal experience. That was mine with the Technorati API, potentially fun, a little bit flaky, wouldn’t want to rely on it too much.

There is a problem with all of these APIs really, and it is the fact that you do need to know your stuff. It is kind of rocket science. You can’t just get started straight away. Most of all you need to know about XML. Apart from the Google Maps, and the Yahoo! Maps, those are the ones based around JavaScript, it all comes down to XML most of the time and you have to know your way around XML. There are ways of parsing XML like XSLT. That’s a good useful skill to have, like I said, particularly for the Amazon services. If you are going to use the maps you need to know your JavaScript. I mean they make it as painless as possible for you but you still need to know your stuff so you can understand what’s going on and most of the time, you need some server-side language to do the heavy lifting for you.

What that means is that mashing around with APIs and doing all this fun stuff is limited to kind of the alpha geeks, the people who know this stuff and like I said it’s good fun to play around with it but it’s a bit of a shame that everyone can’t join in the fun. Now some people are trying to change that. There are some services out there that are trying to bring APIs to the masses. There is a service called Ning with the idea being that you take existing mashups you clone it, you mess around with it, you do your own thing. I’m not sure how well this works really. I don’t think it is very clear describing how it works and who it is aimed at, but the idea is good, to free APIs up for everyone not just the geek developers.

Another interesting one is called Dapper where you point it at some pages. Let’s say there’s a site that doesn’t have an API, and you want to mess with that site’s data. Well you start surfing that site through that Dapper browser and you say, okay, this is a headline and that’s a description, okay, and on that page that’s a headline, that’s a description. And you show it a few pages and it sort of gets the idea. It says, Oh, okay, I see how this site is built, and then it can construct an API for you to use. Really, it’s like a very clever form of screen scraping. But, that’s what people are going to do anyway. If you don’t provide an API, if they really want the data, they’re going to get the data anyway by screen scraping. So that’s an interesting way of trying to open up every website to have APIs, but I don’t know how well that’s going to work.

So this web of data, as I said, we’ve got identity, events, relationships, and location. And right now, it’s JavaScript, especially for location, XML for everything else, and some server-side language. But there’s this wonderful movement where by all of these bits of data can be done very simply by anyone. For instance, identity, we have the hCard. Just, you know, a couple of class names and markup, and you’re essentially creating an API for your identity. Events, we have hCalendar. It maps events to some very simple class names. Relationships, XFN. Fairly simply way of doing it; you’d be surprised how far it scales. And location, we have geo coordinates. And if more people used all of these little formats, it’d be great. These are microformats, very basic, very simple, and it’s almost a way of turning the entire web into one giant API. You’ve seen it already on the backnetwork where we’re using the XFN relationship to join people up like this, and mashing it up with the live web through things like RSS and tagging, the very things that I mentioned, matched it up with relationships. And then you get some very interesting views, a relationship cloud of who knows who. So they work extremely well. They’re meant to be very simple but they scale up remarkably well.

And that’s the thing about microformats. I’ve gone on this journey from learning plain old HTML back in the day when I built that first website for my band, and then learned all those other technologies. I learned JavaScript, I learned PHP, and then MySQL, and then messed around with the APIs. And I did get a lot of fun with messing around with the APIs. But right now I have to say where I’m getting the most joy is from microformats because it has rekindled the joy of HTML, that original joy I got when I first went online. That is why I’ve organized a fairly impromptu microformats picnic because I want to talk about microformats a lot more. And I’m going to be done here in a few minutes. So out the back there’s a park. The weather looks pretty nice today. I’ve ordered some sandwiches, but I think you’re going to have to bring some food with you. Let’s all meet up in the park and we can talk about microformats because I’m very excited about them.

And now, I would like to hear your thoughts about other things that I’ve talked about here: APIs, mashups, anything like that. If you want any of the URLs that I’ve talked about today, I’ve put them all up online at this URL here: adactio.com/extras/joyofapi. You’ve been very gracious listening to me babble on about myself today, so thank you very much.


Okay, hands up for questions. Oh, we’ve got bingo! Oh great, okay. Should we give out the prize now or the prize later?

Audience: Later.

Jeremy Keith: Okay, hands up for questions. Surely somebody has a question. Oh, there on the side, there’s one. Oh sorry, there’s one over here. Hang on a second.

David Barrett: Sorry, Jeremy. You say that it’s a shame that the alpha geeks are the only people that can use these APIs. But can you think of an use case where someone who wasn’t a geek would even want to use these?

Jeremy Keith: Yeah. You’ve got a blog. You don’t need to be a geek to have a blog. You don’t need to be a geek to have a live journal account or to have a Typepad account or to have your own website or to have a website about you favorite pets. That’s what was the great thing about the web. That’s what made the web explode when it was first introduced was that anyone could do it. Now of course what that meant was that it was a pretty sloppy web. Browsers were very forgiving in the markup that they allowed people to use and tried to do the best job that they could do anyway. But because anybody could create a website once they knew a bit of HTML, the web exploded. And there’s no reason why those same people should be excluded from getting the benefits of things like maps and events and all this other data. So anybody, because you don’t need to be a geek to have a website, so you shouldn’t have to be a geek to use an API. That is the spirit of the original web really.

We had one over on the side here, I think.

Audience member: Yeah, this isn’t so much a question as just an interesting thing that’s come out of both your talk and Paul and Simon’s, which is the question earlier about what happens when this all goes away. You used your example of trying to float between Google and Yahoo Maps. This is another service that people might be interested out there which is nothing to do with me. It’s called Mapstraction. And it’s actually, so the trick actually is going, an API extracts out what an application does into a series of methods, and the trick is then to extract on top of that. So what Mapstraction does, it’s one library, it’s Javascript, you put it in a page, and you say I want a map of this place, with a pin, with a pop-up, and then one global variable sets, whether it’s from Google, Yahoo, Microsoft, or OpenStreetMap, the point being that then when Google charge for their maps, you just change one variable and you move over to a competitor. But the trick is, you can do that for almost anything else. You can make layers of extraction.

Jeremy Keith: Yes, it’ll be good to see more of these libraries of libraries, these meta-APIs that let you just switch between data providers at your call. But as Paul pointed out, that’s the great thing about a lot of these APIs. The first one to market gets to dictate the scene, and other APIs, if they want to compete, they had better follow the same sort of structure in their API or nobody’s going to use it. That’s the great thing.

One of the other things I want to mention about what if these services go away, what happens to my data and stuff, that’s actually one of the benefits of APIs, For instance, with Flickr, why should I trust Flickr with my photographs? Well, because of the API you know you’ll be able to get your photographs out any time you want. I’m not just talking about the alpha geeks who can code up something to get their data out. There’s third-party providers who will burn all your Flickr pics to DVD. You authorize them, you give them your Flickr user name, password, and they will do the burning for you using the API.

So APIs actually encourage trust. They say don’t worry, your data is safe with us, look, we’ve got an API, any time you want you’ll be able to take your data with you.

Another question? I think the first hand might have been down here, over here.

Paul Boag: Hi. You already mentioned that, on your own site, you’ve experienced some flakiness where things have gone down. Surely the more these APIs you include in them, the more calls you’re making to them, the more different services and different servers, and the more unstable you’re making your own site really, I mean are there ways around that to kind of mitigate that risk?

Jeremy Keith: Well, something like Mapstraction, like I was saying, if you had something that you could easily flick between providers to say, oh, Google Maps is being really flaky today, I’m switching over to Yahoo! Maps, the more providers there are, the more times you have that option, but also the way you build things. You don’t want to make these things mission critical, really I suppose, but it’s like Unix pipes. You have lots of these different sort of things going on at once.

But this idea of relying on other services isn’t anything new. Unless you’re hosting your site yourself, you’re probably relying on a third-party hosting provider. Your stats package is probably sitting off somewhere, you’re relying on some other third party for that. So this idea of relying on third parties for, sometimes, very mission-critical stuff, isn’t really new. Most of us rely on third parties for email, which is about as critical as it gets. This idea of trust and trusting data providers isn’t that new, really, it’s just taking it to the next level.

Patrick Lauke: Hi, Jeremy. Just on the flakiness of services, one thing that I’ve seen that I’ve been doing on my own site is, it’s sometimes a good idea to do some caching so that you don’t always try to hit the latest live data but just mitigating it by, I don’t know, if you can afford to have ten, 15 minute stale data, that kind of helps overcome kind of initial problems if the server just happens to be down or being kind of overly busy.

Jeremy Keith: Yes, that’s the savvy thing to do. I’m not tech-savvy enough to do that. Glenn, when he built the backnetwork, he is tech savvy, so he’s not calling Flickr every time, he’s set a polling time which, a few weeks ago, he was just polling Flickr once a day. As it comes up to d.Construct he’s polling more and more often, so as he gets closer to the live feed on the day of d.Construct, but yes, caching is generally a good idea. If I was smart I would do that more but I’m not really clever enough.

Jenifer Hanen: Thanks, Jeremy. I’ve heard that, no offense to him, Tantek speak on this at least three times over the last three and half years and you just summed up, especially the microformats, in a way that makes sense. Now can I request that the two of you speak together in the future so that way you will give the broad, good background and then he can give the detail?

Jeremy Keith: Well, we actually did at South By Southwest last year. Tantek talked about microformats and gave the whole background of them, and then he had a few of us come up and do implementations so Norm was there and he showed off Yahoo! Europe using hReviews and I went up and showed all the parties in Austin, because that was what I had used microformats for.

I started using microformats everywhere so a lot of those mashups you would have seen using Google Maps, the parties in Austin, the d.Construct location page, all of that’s marked up in microformats. I’d like to say that makes your web site a API straight away. The schedule for d.Construct, that was marked up in hCalendar. You would have seen a link in the sidebar to a third-party service which is hosted on Technorati, which will turn the hCalendar into an actual iCal that you can subscribe to, and then you can put that on your mobile phone. If the web page gets updated, the calendar will get updated as well. You get to take this data with you. You don’t have to duplicate the data. It’s just so easy to do; I’ve just started doing it automatically now. I want to try to turn as many of my websites as possible into APIs. The easiest way to do that is by providing microformats.

Paul and Simon made a great job of selling the benefits of providing an API and of having an API if you are a company, but you have to convince people, as someone mentioned, to do this, to put the money and effort and, and it can be a lot of hassle. Microformats are a nice starting point. If you just convince people, and you don’t even have to tell them, just throw in a few class names. It’s as simple as that. Straight away, you’ve allowed access to your data.

That’s what Norm did at Yahoo! Europe; he just threw in a few class names on Yahoo! Local, I think it was, and suddenly there was thousands and thousands and thousands of hReviews, hCards and all sorts of stuff on the web. Anybody could go out there with a parser and use that data. It was essentially a brand new API the next morning. So, it’s a good way to start. APIs can be intimidating, and microformats are a nice sort of way of getting in the door of the API mentality, this idea of opening up my data.

We’ve got one way down in the front. Paul, down here in the second row.

Audience member: Hi there. I’m the editor of a big cultural website called the 24 Hour Museum. We’ve done RSS for four years now. It’s a fantastic part — it’s the bloodstream that makes everything work and join together. We’re really fascinated with APIs and web services, and we’ve got a fantastic live database, which is added to and kept live all the time by museums, galleries and heritage sites all over Britain. What worries me is if we are looking to build an API interface, if it takes a six months to put together, how long have we got of good, solid, reliable life working with that API interface and those standards before things move on again? This is what may be holding back the big cultural websites, government funders and this sort of stuff. This is what’s holding us back.

Jeremy Keith: Did everyone hear the question? How do you start building API? It could take six months, it’s what’s holding people back, it seems like such a complicated thing to do, and in six month’s time it might be out of date, then you have to go to the next version of the API.

I would say you already have an API because you’re providing RSS feeds. RSS is XML; it’s a RESTful interface onto your data. You probably have lists of things. If you can provide an RSS equivalent for everything on your site, that’s wonderful. A lot of sites do this already: Flickr, Upcoming, all of these sites.

Pretty much anything you can get in a list, you can get as an RSS feed: my latest pictures, latest pictures from my friends, my latest events, links with a certain tag. As well as being able to get that on the website or through the official API, which is more complex, there is always an RSS feed for this stuff because it’s generally pretty easy to put an RSS feed together. It’s always got the same structure, an item with a description, title and a URL, that’s the important bit.

Once you’ve got that, you already have an API because people can just grab that URL and parse it because it’s XML and do what they want with it. So, providing RSS is an API. If you also use microformats on the site and you already have listings — you can use hListings, hReviews, all these little bits of data — then if you don’t have the budget or the time to put into an API, that’s where you should start, just doing small stuff. It’s pretty simple. RSS is a great way to start because RSS is an API. It’s a restful interface onto data. So RSS, very cool stuff, Atom as well, I’m not going to get into a flame war.

Do we have time for another question? I think we do.

Suw Charman: Hi. Actually, it’s not a question; I hope you’ll forgive me. I was hoping to do a little Birds Of a Feather session for the Open Rights Group. Basically, if everyone wants to go grab and lunch, then we will also meet up in the park. Then maybe we can heckle your microformats.

Jeremy Keith: I think maybe a Jets versus the Sharks sort of situation will be good. We can face off with each other. That’s what we’ll do. So, Open Rights Group meeting in the park, and microformats meeting in the park as well. Right back there.

I’ve ordered some sandwiches; I hope they have shown up. They’re here? Great, sandwiches are here, but they’re micro sandwiches so they’re not going to go very far! You might want to grab some sushi down the road or some sandwiches from a nearby shop. I’ll head over to the park now and we’ll get things started. Thanks for the questions; great stuff!


Monday, September 18th, 2006

d.construct makes you 35% more friendly

Glenn has some interesting statistics from the d.Construct backnetwork.

Thursday, September 14th, 2006

Speaking at d.Construct

I like public speaking. I know that it strikes the fear of God into some people, but I get a kick out of it. As long as I’m speaking on a subject that I care about, there’s nothing I like more than addressing a captive audience.

I’ve done a fair bit of talking this year, with more on the way. Usually when I stand in front of a crowd, it’s to talk about DOM Scripting or Ajax. This year’s d.Construct was different. I had the opportunity to talk about APIs.

I have some experience with using a few APIs but I’m by no means an expert. Rather than attempt to give an in-depth technical overview of Web Services, I decided to share my personal experiences. It was the developer’s equivalent of showing off holiday snapshots.

I was kind of nervous about how it would go down. What I was doing was quite self-indulgent. But people seemed to like it. It’s funny, but as many a songwriter will tell you, the more personal you make something, the more universal its appeal.

Most people seemed to really enjoy the talk. That was probably helped by the fact that I kept it fairly short. After half an hour, I was done. That left plenty of time for questions and answers, which are always the best bit. There were some great questions from the audience that prompted even more babble from me.

I have to say, it was particularly pleasant to find myself speaking to an audience of over 300 people in Brighton. I felt proud to speak as a representative of my adopted town. With d.Construct, Andy has shown that it’s possible to put on a large, well-organised event outside London.

Here’s a page of links to sites I mentioned during my talk. I don’t think I’ll bother putting my slides online: they make absolutely no sense without the explanation to go with them.

My talk, along with all the others, was recorded by Drew, who did a fantastic job. They’ll popping up in the podcast before too long. I’m getting my talking transcribed through Casting Words and I’ll publish it once it’s ready.

Ian Forrester also managed to make a video of the whole thing. It’s weird being able to watch myself speaking. I use my hands almost as much as Simon does.

With the benefit of video playback, I can now say that I’m glad I wore my suit. In fact, I think what I really need is proper evening wear. Can’t you just seem me giving a presentation in a top hat and tails? I could even use a cane for pointing at the slides.

Sunday, September 10th, 2006


Reading through the post-d.Construct buzz, I see a number of recurring themes:

  1. The seats were too narrow.
  2. The badge incorporating the programme was ingenious.
  3. The Backnetwork rocked.

I’m certainly in agreement with that third point. Every conference should have an app like the Backnetwork.

I exchanged a couple of business cards over the weekend but really, it wasn’t something I needed to worry about. I knew I could just go into my network and download any vCards (via hCards) that I wanted.

It’s fun watching the Backnetwork fill up with Flickr pics, blog posts and reviews as attendees document their time at d.Construct. For my part, I’ve been updating my list of contacts to incorporate more people that I met over the weekend.

Thanks to the magic of XFN, here’s a microformatted incomplete list of the wonderful people I know from d.Construct, copied and pasted from my profile:

Fables of the dConstruction

What a weekend! d.Construct 2006 is over. It’s hard to believe after all the weeks and months spent preparing for a single day.

The night before the conference was spent wining and dining the speakers at one of my favourite restaurants. It’s a tough job but someone’s got to do it. I still had time to pop in for a quick drink at Heist. It seemed like everyone was having a good time, which was gratifying to see.

On the morning of the conference itself, I went along to the Corn Exchange early with Jessica; she kindly volunteered to help out on the day. We both pitched in with bag-filling duties. By the end, I was convinced of the merits of having a schwag-free conference next time.

Still, it seemed like people enjoyed their goody bags. The Yahoo! Answers water was probably the most practical thing in there.

The talks themselves went well, with very few technical hiccups. Nonetheless, I found it hard to completely relax and enjoy the presentations because I was so concerned about everyone else enjoying themselves.

It’s interesting reading blog posts about the different presentations. The reactions are quite varied. One person’s high point is another person’s low point. Mind you, I think just about everyone was in agreement that Jeffrey Veen was, as always, wonderful.

A few people felt that Jeff Barr’s talk was a bit corporate for a grass-roots event like d.Construct. I can see their point. It’s his job to travel the world giving what are basically product demos. The redeeming factor is that he has some great products to demo.

Something else that detracted from the grass-rootsiness was the paucity of Q and A. Apart from my talk and Simon and Paul’s, none of the other speakers had time to take questions, which is a shame. Without the audience interaction through asking questions, presentations can feel quite one-sided and lecture-like. That’s just my opinion, of course, but it seems to be one shared by everyone I talked to.

All the speakers said that they would have loved to have taken questions. Well, here’s a hot tip: learn how to measure time. 45 minutes is a nice compact timeframe to fit in a good presentation and still have time to take questions (half an hour can feel rushed and an hour often drags). Not allowing time for questions feels like a bit of a wasted opportunity. Going over the allotted time is downright discourteous.

I’m probably being over-critical. Nothing ever goes quite like clockwork and for the most part, the d.Construct schedule went very smoothly. This was probably helped by Richard’s affable and admirable role as compère.

The WiFi was a bit flaky in the morning but that was all fixed by the afternoon. As Suw pointed out, there was a distinct lack of power outlets in the main auditorium. There were quite a few out back though.

The after-party at The Terraces was great fun. Needless to say, the free booze ran out pretty quickly. I never even got the chance to play crazy golf. But I still had a great time. It’s always great to catch up with old friends and meet new people in a geek-saturated crowd. There’s something quite tribal about a gang of Web geeks gathered in a bar.

I ended up back at Blanch House, drinking cocktails ‘till three in the morning and unwinding with some fellow delegates.

Saturday was spent lounging, relaxing, and generally taking it easy. I got up far too late to attend the OpenStreetMap workshop, which is a pity. I ended up wandering the seafront and going to the Lego shop with an ever-changing amorphous crowd of friends in tow.

By evening time, this friend-cloud coalesced into a big barbecue on the beach. When the grilling was done and the drinks were flowing, by the light of the setting sun and the rising moon, we formed a circle and played Werewolf.

Nothing can top Werewolf on the beach so we didn’t even try. Some people came back to my place for more liquid refreshment and a spot of Quake before drifting off to their separate corners of the physical world.

I was sad to see everyone go, but it was great to have them all gathered here in Brighton for the weekend.

Friday, September 8th, 2006

Simon and Paul

Simon and Paul have finished giving their presentation and very good it was too. They covered a lot of ground in a short time but they did it in a clear, easy to follow way.

As is now mandatory, the presentation was illustrated with Flickr pics including one of mine, which I wasn’t expecting.

he guys did a good job of showing how useful APIs are from inside a huge company and from the evangelism they were doing, I expect to see Hack Days starting at other companies soon.

The talk flowed nicely into my presentation where I talked about APIs from the viewpoint of someone on the outside looking in. That’s no accident, of course: we planned the schedule that way. I think it worked out well.

Thursday, September 7th, 2006

d.Construct travel news

If you’re planning to come down to d.Construct tomorrow morning on a train from London, you might want to rethink your travel plans:

A train drivers’ union will decide later whether to go ahead with a major strike which is set to cripple services across southern England.

There’s always the bus, though that takes considerably longer. Or you could just come down tonight and go to the pub.

Update: The strike has been called off! Praise Jeebus!

Tuesday, September 5th, 2006

d.Construct events

d.Construct is almost upon us. Everyone at Clearleft is excited and nervous in equal measure.

I wanted to give a quick heads up on some of the satellite events taking place around the conference.

If you haven’t heard yet, there will be pre-conference drinks on Thursday evening starting at 7pm at a place called Heist on West Street. We’ve hired out the downstairs room which should accommodate one hundred eager geeks.

It’s worth sticking around the day after d.Construct too. The guys from OpenStreetMap have put together a mapping workshop. It begins at ten in the morning and will probably go on until four in the afternoon on Saturday. The central hub will be the offices of Brighton Web at 2 Brunswick Terrace in Hove. Most of the time you’ll be out and about purposefully striding the streets of Brighton with a GPS device in hand. GPS devices will be provided but if you have one, please bring it along.

It looks the weather is going to be quite nice on the day of d.Construct. It’s a sign. The gods of weather clearly want us pasty geeks to go outdoors. With that in mind, I’ve decided to host a microformats picnic during the lunchtime break: 12:452pm. The Pavilion Gardens are right next to the Corn Exchange. The park has got WiFi, though it may hard to see your laptop screen in the sunshine. This picnic is for everyone. If you’re just curious about microformats, please come along and ask any questions you want. If you’re already using microformats, let’s talk about that.

All these events are on Upcoming. I’ve also marked this up in hCalender so you can subscribe to the events and stick ‘em on your mobile phone, iPod or whatever.

Saturday, September 2nd, 2006

Live from Barcamp London

I’m at Barcamp London. It’s been a great day so far with lots of disparate talks nicely punctuated with plenty of food and drink.

For my part, I cheated and recycled my Hijax talk from XTech (I figured most people wouldn’t have seen it). It was fun.

I spent half of my time grabbing people for quick interviews for the d.Construct podcast. I’ve just published the episode so download the MP3 and get a taste of that Barcamp magic.

The mini-Mashupcamp is next on the agenda. After that, the sleeping bags come out.

I plan to do some more field recordings for the podcast tomorrow. And I really must take more pictures and post them to Flickr.

Saturday, August 26th, 2006

dConstructing the network

One of the sponsors of this year’s d.Construct is a local company called Madgex. Glenn Jones works there.

At the Clearleft office warming party, I chatted with Glenn about what form the sponsorship might take. Rather than go down the usual schwag-based route, Glenn was determined to do something useful, like build an app. He started telling me what he had in mind. The more he told me, the more excited I got.

Glenn has been working feverishly on the project and it’s now ready for unveiling. Ladies and gentlemen, I give you…

The d.Construct06 Backnetwork

You know the way that a backchannel develops at most conferences? IRC, iChat, and all that. Well, this is a backnetwork.

It’s a social network app, but a genuinely useful one. For a start, it’s all based around a single focal point: the d.Construct conference. Everyone using the backnetwork has something in common. They are all attendees of the conference. This network is closed to the outside world.

I’ve seen some other events attempt a kind of pre-conference network. The South by Southwest website last year had a section for maintaining a profile and connecting with other attendees. But these connections were very simple. As with most social network sites on the Web, either someone is your friend or you have no connection to them whatsoever. That isn’t a very accurate reflection of reality.

Instead of inventing some new proprietary schema for representing the connections between people, the d.Construct backnetwork uses XFN — XHTML Friends Network. The relationships represented in XFN map remarkably well to an event like this.

Here’s my profile. You can see all the people that I’ve connected with (friends, acquaintances, colleagues) and all the people who have a connected with me. Based on these connections, I even get a cloud of names with the sizes indicating the strength and reciprocity of that relationship.

But here’s the best bit. I can take this information with me. Instead of being yet another roach motel or data silo, the backnetwork actively encourages me take my data with me. There’s a pre-formatted XFN list that I can cut and paste into my own site. Or, if I want, there’s an OPML file of all the feeds from people in my network.

As with most social network sites, you have to go through the process of filling out your details before you can start using it. But here again, you are actively encouraged to then take this information with you. I can cut and paste my hCard or simply download a vCard via Brian Suda’s hCard converter on Technorati.

You can specify how you want sensitive data like emails and telephone numbers to be treated. You can make them public, you can not reveal them at all, or you can allow only your friends to view them.

There’s a lot of microformatted goodness throughout the backnetwork and constant encouragement not just to put data into the system, but also to take it away with you. The result is something that’s fun and useful before, during and after the conference.


In the run-up to d.Construct, you can find out who else is coming. If you know any of the people, you can connect with them. There’s even a Google Maps mashup so you can see where people are coming from. You might even find people coming from the same town as you and make travel plans with them.

There’s an aggregator that pulls in any relevant blog posts written by attendees. You can subscribe to the aggregate feed or take away an OPML file with a list of all the sites.


The aggregator is going to be very handy during the conference as a way of following any liveblogging. There’s also a really nice photo page that pulls in Flickr pics and displays them in a lightbox.

There will even be an Ajax chat room opened up on the day.


Once the conference is over, you’ll probably want to revisit the attendee list. You will undoubtedly want to mark a lot of people as “met”. Heck, you may even make some friends. You’ll certainly have made lots of connections. And if you didn’t manage to exchange business cards, you can grab each other’s hCard or vCard instead.

There’ll probably be plenty of post-conference blog chatter to track through the backnetwork. If you want to add your own impressions of the panels, you can post straight to your blog or you can add a review through the backnetwork. You can fill out a form and submit your review. This is formatted in the hReview microformat so that, once again, you can take it with you. Just copy and paste the review into your own site. You can even specify a creative commons license while you’re at it.


The backnetwork is using microformats all over the place: XFN, hCard, hReview, rel-license and rel-tag. It’s quite remarkable how useful this turns out to be. It makes it so, so easy to take your data with you. Your contact details, relationships, and reviews are yours for the taking.

This is something you can see on a lesser scale on the d.Construct website. The list of speakers has been marked up with hCards. The schedule for the day is an hCalendar. There’s a link off to Brian Suda’s converter on Technorati so that you can subscribe to the calendar, put it on your iPod, your mobile phone, whatever you want. If there are any changes to the schedule, the page will be updated and the change will be reflected in the subscribed calendar. There’s no need to maintain a separate file like Michael had to do for Reboot or Jon did for @media.

If you’re coming to d.Construct, you should have already received an email with an activation code for the backnetwork. I suggest you use it. If haven’t received your activation code, you’d better let Andy and Richard know.

If you aren’t coming to d.Construct, you can still browse the backnetwork and track the blog posts, reviews and photos as they come in. You just won’t be able to add your own profile or define any relationships with the attendees.

If you want to know more about the technologies driving the backnetwork, check out the “about” page. In case you hadn’t noticed, I’m really excited about this application. I’m like a kid with a new toy and I’m loving it.

Thursday, August 24th, 2006


I’m enjoying the process of putting together the d.Construct 2006 podcast. It seems that other people are enjoying it too.

I wrapped up the latest episode with a call for feedback. I’ve added a link to Odeo on the podcast page so that you can record a message for the podcast.

I’m intrigued by the idea of using audio to leave feedback, add comments and ask questions. This is something that Tom played around with a while back. I like the context that’s added just by hearing a person’s voice. It’s like a gravatar times ten.

On Odeo, everyone knows you’re a dog.

Don’t be shy. Record a message, add some text if you want, and hit that big “send” button. If you’re coming to d.Construct, tell me your hopes and fears for the conference. If you can’t make it to d.Construct, make your presence felt by leaving your thoughts on APIs, mashups, Web 2.0, and anything else you feel like talking about.

If this little experiment works out, maybe I’ll end up using Odeo as a feedback channel for this journal. I have some other feedback and commenting ideas that I’d like to try out too. Watch this space.

Monday, July 24th, 2006

September is the coolest month

There’s going to be a spate of very cool events happening in September. Together, they span three continents.

The fun kicks off in Europe. As you probably already know, d.Construct 2006 will be taking place right here in Brighton on September 8. The conference is already sold out, but if you haven’t got a ticket, you can always put your name down on the standyby list.

If you are coming along, consider sticking around for a weekend of geekery. I’ve put together a list of restaurants, pubs, and hotels, all geo-encoded and mashed up with Google Maps. If you’re planning on staying over, you’ll probably want to book a room soon. It turns out the TUC Congress will be coming to town a few days after d.Construct.

Don’t forget that you can track the build-up to d.Construct 2006 by subscribing to the podcast.

If you’re in North America, then there’s something that might interest you in San Francisco. The Future of Web Apps summit from Carson Workshops will be taking place on the 13th and 14th of September. The last summit, held in London, was excellent. It was inexpensive, the WiFi worked, and the speakers were great. This time, the summit has been stretched to two days, but the price remains tasty and the line-up looks very good indeed.

One week later, the inaugural Webmaster Jam Session will be taking place in Dallas on the 21st and 22nd of September. While the Carson Workshops event will be looking at the big picture of developing web apps, this looks like a more nuts’n’bolts affair, detailing how to go about building and promoting websites.

But the event that has me most excited is taking place on the other side of the world.

Web Directions 2006 will be taking place in Syndey, Australia from the 26th to the 29nd of September. I’ve been asked to speak at the event, for which I am extremely honoured.

As well as giving two presentations at the conference proper, I’ll be giving a workshop on DOM Scripting and Ajax on the Tuesday beforehand. If you’re attending the conference, you get a discount to the workshop.

I’ve never been to Australia before. I’ve never even been south of the equator so this will be my first experience of the Southern hemisphere. I’m looking forward to it immensely. The fact the conference looks like it’s going to be amazing only adds to the thrill. I’m going to have to pull out all the stops to hold my own with speakers like Derek Featherstone, Kelly Goto, and Mollarkey.

If you live anywhere near Sydney (near being a relative term for Australia), Web Directions looks like it’s going to be unmissable. I look forward to seeing you there and, if you can make it along for the workshop too, all the better.

Thursday, July 13th, 2006

Podcasting d.Construct 2006

In case you haven’t heard, the d.Construct conference, which so rocked Brighton last year, is returning in 2006. It will take place in the Corn Exchange (right next to the dome) on the 8th of September.

It will be bigger. There were just 100 people at last year’s event. There will be 3.5 times as many this year. But it’s still going to a grassroots affair. By grassroots, I mean cheap and cheerful. The price of admission is just £75. Registration opens on the 18th of July. That’s next Tuesday. The clock is ticking.

If you’re in any doubt about attending, just check out the line-up for this year: Jeffrey Veen, Thomas Vander Wal, Derek Featherstone, Jeff Barr, and many more. Registration also qualifies you for entry to the after-party at the Terraces.

In the run-up to the conference, I’m going to be trying a little experiment. Most conferences these days offer a podcast of proceedings after the event — which we are also planning to do — but the decision was made at the Clearleft HQ to start podcasting beforehand.

Armed with headphones and a USB microphone, I’ve been getting to know the ins and outs of Garageband. The first tentative results are available for your listening pleasure. You can subscribe to the RSS feed from the podcast page of the conference website.

I listen to quite a lot of podcasts but I have to admit that there aren’t many that really stand out. Apart from time-shifted radio programmes like In Our Time or Mark Kermode’s film reviews, most podcasts tend to be rambling affairs with too much dead air and not enough editing (The Word Nerds being a notable exception).

Now, I’m not claiming that my podcast will be qualitatively better; it’s decidedly amateurish (it is a podcast, after all). But the episodes will be mercifully brief. Short, sharp shows are the order of the day.

At the very least, I hope it won’t be annoying to listen to. I’ve done my best to get consistent volume levels and audio quality but I’m very much a newbie at all this. Like I said, this is all an experiment and, depending on the feedback, the format may change completely.

On the subject of podcasts, point your pod at the @media feed. There’ll be a new presentation released every week. The audio for my talk, Using DOM Scripting to Plug the Holes in CSS is now available. I’ve posted a transcript of the presentation over in the articles section of this site, which you can also subscribe to as a podcast.