Tags: format



Cerf rocks

After I wrote about digital preservation and the need to save everything, not just the so-called “important” stuff, Jason wrote a lovely piece with his own thoughts on the matter:

In order to write a history, you need evidence of what happened. When we talk about preserving the stuff we make on the web, it isn’t because we think a Facebook status update, or those GeoCities sites have such significance now. It’s because we can’t know.

In a timely coincidence, Vint Cerf also spoke about the importance of digital preservation:

When you think about the quantity of documentation from our daily lives that is captured in digital form, like our interactions by email, people’s tweets, and all of the world wide web, it’s clear that we stand to lose an awful lot of our history.

He warns of the dangers of rapidly-obsoleting file formats:

We are nonchalantly throwing all of our data into what could become an information black hole without realising it. We digitise things because we think we will preserve them, but what we don’t understand is that unless we take other steps, those digital versions may not be any better, and may even be worse, than the artefacts that we digitised.

It was a little weird that the Guardian headline refers to Vint Cerf as “Google boss”. On the BBC he’s labelled as “Google’s Vint Cerf”. Considering he’s one of the creators of the internet itself, it’s a bit like referring to Neil Armstrong as a NASA employee.

I have to say, I just love listening to him talk. He’s so smooth. I’m sure that the character of The Architect from The Matrix Reloaded is modelled on him.

Vint Cerf knows a thing or two about long-term thinking when it comes to data formats. He has written many RFCs for the IETF (my favourite being RFC 2468). Back in 1969, he wrote RFC 20, proposing the ASCII format for network interchange. If you’ve ever used the keypress event in JavaScript and wondered why, for example, the number 13 corresponds to a carriage return, this is where all those numbers come from.

Last month, over 45 years after the RFC’s original publication, it became an official standard.

So when Vint Cerf warns about the dangers of digitising into file formats that could become unreadable, I think we should pay attention to him.

Celebrating CSS

Cascading Style Sheets turned 20 years old this week. Happy birthtime, CeeSusS!

Bruce interviewed Håkon about the creation of CSS, and it makes for fascinating reading. If you want to dig even deeper, here’s Håkon’s 1994 thesis comparing competing approaches to style sheets.

CSS gets a tough rap. I remember talking to Douglas Crockford about CSS. I’ll paraphrase his stance as “Kill it with fire!” To be fair, he was mostly talking about the lack of a decent layout system in CSS—something that’s only really getting remedied now.

Most of the flak directed at CSS comes from smart programmers, decrying its lack of power. As a declarative language, it lacks even the most basic features of even the simplest procedural language. How are serious programmers supposed to write their serious programmes with such a primitive feature set?

But I think this mindset misses out a crucial facet of understanding CSS: it’s not about us. By us, I mean professional web developers. And when I say it’s not about us, I mean it’s not only about us.

The web is for everyone. That doesn’t just mean that it’s for everyone to use—the web is for everyone to create. That means that the core building blocks of the web need to be learnable by everyone, not just programmers.

I get nervous when I see web browsers gaining powerful features that can only be accessed via a JavaScript API. Geolocation is one example: it doesn’t have any declarative equivalent to its JavaScript implementation. Counter-examples would be video and audio: you can use the JavaScript API to get exactly the behaviour you want, if you’ve got that level of knowledge …or you can use the video and audio elements if you’re okay with letting web browsers handle the complexity of display and playback.

I think that CSS hits a nice sweet spot, balancing learnability and power. I love the fact that every bit of CSS ever written comes down to the same basic pattern:

selector {
    property: value;

That’s it!

How amazing is it that one simple pattern can scale to encompass a whole wide world of visual design variety?

Think about the revolution that CSS has gone through in recent years: OOCSS, SMACSS, BEM …these are fundamentally new ways of approaching front-end development, and yet none of these approaches required any changes to be made to the CSS specification. The power and flexibility was already available within its simple selector-property-value pattern.

Mind you, that modularity was compromised when we got things like named animations; a pattern that breaks out of the encapsulation model of CSS. Variables in CSS also break out of the modularity pattern.

Personally, I don’t think there’s any reason to have variables in the CSS language; it’s enough to have them in pre-processing tools. Variables add enormous value for developers, and no value at all for end users. As long as developers can use variables—and they can, with Sass and LESS—I don’t think we need to further complicate CSS.

Bert Bos wrote an exhaustive list of design principles for web standards. There’s some crossover with Tim Berners-Lee’s principles of design, with ideas such as modularity and robustness. Personally, I think that Bert and Håkon did a pretty damn good job of balancing principles like learnability, extensibility, longevity, interoperability and a host of other factors while still producing something powerful enough to scale for the whole web.

There’s one important phrase I want to highlight in the abstract of the 20 year old CSS proposal:

The proposed scheme provides a simple mapping between HTML elements and presentation hints.


Every line of CSS you write is a suggestion. You are not dictating how the HTML should be rendered; you are suggesting how the HTML should be rendered. I find that to be a very liberating and empowering idea.

My only regret is that—twenty years on from the birth of CSS—web browsers are killing the very idea of user stylesheets. Along with “view source”, this feature really drove home the idea that professional web developers are not the only ones who have a say in what gets rendered in web browsers …and that the web truly is for everyone.


Aral and his trusty sidekick Victor have taken up residency for a while at the Clearleft office in Middle Street while they work on their very exciting project. It’s nice having them around.

I got chatting to Aral about a markup pattern that’s become fairly prevalent since the rise of Github: linking to the source code for a website or project. You know, like when you see “fork me on Github” links.

We were talking about how it would be nice to have some machine-readable way of explicitly marking up those kind of links, whether they’re in the head of the document, or visible in the body. Sounds like a job for the rel attribute, I thought.

The rel attribute describes the relationship of the current document to the linked document. You can use it on the link element (in the head of your document) and the a element (in the body). The example that everyone is familiar with is rel=”stylesheet” when linking off to a CSS file—the linked document has the relationship of being a stylesheet for the current document.

The rel attribute could theoretically take a space-separated list of any values, just like the class attribute. In practice, there’s much more value in having everyone agree on which rel values should be used.

There used to be a page on the WHATWG site for listing rel values, but it tended to stagnate. So now the official registry for rel values is on the microformats wiki. That’s where you can see which values are recommended for use today and you can also brainstorm new ideas.

The benefit of having one centralised for this is that you can see if someone else has had the same idea as you. Then you can come to agreement on which value to use, so that everyone’s using the same vocabulary instead of just making stuff up.

It doesn’t look like there’s an existing value for the use case of linking to a document’s (or a project’s) source code so I’ve proposed rel=”source”.

Now I should document some use cases of people linking their site to its source code. It might be that wikis qualify as another use case: every “edit” button points to the source of the document in wiki markup.

If you have any thoughts on this pattern, or examples to add, please feel free to add them.

Defining the damn thang

Chris recently documented the results from his survey which asked:

Is it useful to distinguish between “web apps” and “web sites”?

His conclusion:

There is just nothing but questions, exemptions, and gray area.

This is something I wrote about a while back:

Like obscenity and brunch, web apps can be described but not defined.

The results of Chris’s poll are telling. The majority of people believe there is a difference between sites and apps …but nobody can agree on what it is. The comments make for interesting reading too. The more people chime in an attempt to define exactly what a “web app” is, the more it proves the point that the the term “web app” isn’t a useful word (in the sense that useful words should have an agreed-upon meaning).

Tyler Sticka makes a good point:

By this definition, web apps are just a subset of websites.

I like that. It avoids the false dichotomy that a product is either a site or an app.

But although it seems that the term “web app” can’t be defined, there are a lot of really smart people who still think it has some value.

I think Cennydd is right. I think the differences exist …but I also think we’re looking for those differences at the wrong scale. Rather than describing an entire product as either a website or an web app, I think it makes much more sense to distinguish between patterns.

Let’s take those two modifiers—behavioural and informational. But let’s apply them at the pattern level.

The “get stuff” sites that Jake describes will have a lot of informational patterns: how best to present a flow of text for reading, for example. Typography, contrast, whitespace; all of those attributes are important for an informational pattern.

The “do stuff” sites will probably have a lot of behavioural patterns: entering information or performing an action. Feedback, animation, speed; these are some of the possible attributes of a behavioural pattern.

But just about every product out there on the web contains a combination of both types of pattern. Like I said:

Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

Now you could make an arbitrary decision that any product with more than 50% informational patterns is a website, and any product with more than 50% behavioural patterns is a web app, but I don’t think that’s very useful.

Take a look at Brad’s collection of responsive patterns. Some of them are clearly informational (tables, images, etc.), while some of them are much more behavioural (carousels, notifications, etc.). But Brad doesn’t divide his collection into two, saying “Here are the patterns for websites” and “Here are the patterns for web apps.” That would be a dumb way to divide up his patterns, and I think it’s an equally dumb way to divide up the whole web.

What I’m getting at here is that, rather than trying to answer the question “what is a web app, anyway?”, I think it’s far more important to answer the other question I posed:


Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think by making the distinction at the pattern level, that question starts to become a bit easier to answer. One possible answer is to do with the different skills involved.

For example, I know plenty of designers who are really, really good at informational patterns—they can lay out content in a beautiful, clear way. But they are less skilled when it comes to thinking through all the permutations involved in behavioural patterns—the “arrow of time” that’s part of so much interaction design. And vice-versa: a skilled interaction designer isn’t necessarily the best at old-skill knowledge of type, margins, and hierarchy. But both skillsets will be required on an almost every project on the web.

So I do believe there is value in distinguishing between behaviour and information …but I don’t believe there is value in trying to shoehorn entire products into just one of those categories. Making the distinction at the pattern level, though? That I can get behind.


Incidentally, some of the respondents to Chris’s poll shared my feeling that the term “web app” was often used from a marketing perspective to make something sound more important and superior:

Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

Approaching things from the patterns perspective, I wonder if those same feelings of inferiority and superiority are driving the recent crop of behavioural patterns for informational content: parallaxy, snowfally, animation patterns are being applied on top of traditional informational patterns like hierarchy, measure, and art direction. I’m not sure that the juxtaposition is working that well. Taking the single interaction involved in long-form informational patterns (that interaction would be scrolling) and then using it as a trigger for all kinds of behavioural patterns feels …uncanny.

Parsing webmentions

Thanks to everyone who helped me test webmentions that I hacked together at Indie Web Camp last weekend.

Let me explain what web mentions are all about…

Basically, it’s an equivalent to pingback. Let’s say I write something here on adactio.com. Suppose that prompts you to write something in response on your own site. A web mention is a way for you to let me know that your response exists.

If you look in the head of any of my journal posts, you’ll see this link element:

<link rel="webmention" href="http://adactio.com/webmention.php" />

That’s my web mention endpoint: http://adactio.com/webmention.php …it’s kind of like a webhook: a URL that’s intended to be hit by machines rather than people. So when you publish your response to my post, you ping that URL with a POST request that sends two parameters:

  1. target: the URL of my post and
  2. source: the URL of your response.

Ideally your own CMS or blogging system would take care of doing the pinging, but until that’s more widely implemented, I’m providing this form at the end of each of my posts:

Either way, once you ping my web mention endpoint—discoverable through that link rel="webmention"—with those two parameters, I just need to confirm that your post does indeed contain a link to my post—by making a cURL request and parsing your source—and then I return a server response of 202 (Accepted).

Here’s the code for a minimum viable web mention in PHP.

That’s as far as I got at Indie Web Camp but it was enough for me to start collecting responses to posts.

Webmentions as links

The next step is to do something with the responses. After all, I’ve already got the source of each response from those cURL requests.

Barnaby has a written a nice straightforward microformats parser in PHP. I’m using that to check the cURLed source for any responses that have been marked up using h-entry. That’s one of the microformats 2 vocabularies—a much simpler way of writing structured content with microformats.

Aaron, Amber, and Barnaby all sent responses that were marked up with h-entry so now their responses appear in full.

Webmentions as comments

So there you have it. Comments are now open on every journal post on adactio.com …the only catch is that you have to write the comment on your own site. And if you want the content of your post to appear here (instead of just a link) then update your blog post template to include a handful of h-entry classes.

Feel free to use this post as a test. Mark up your blog with h-entry, write a post that links to this URL, and enter the URL of your post in the form below.

Battle for the planet of the APIs

Back in 2006, I gave a talk at dConstruct called The Joy Of API. It basically involved me geeking out for 45 minutes about how much fun you could have with APIs. This was the era of the mashup—taking data from different sources and scrunching them together to make something new and interesting. It was a good time to be a geek.

Anil Dash did an excellent job of describing that time period in his post The Web We Lost. It’s well worth a read—and his talk at The Berkman Istitute is well worth a listen. He described what the situation was like with APIs:

Five years ago, if you wanted to show content from one site or app on your own site or app, you could use a simple, documented format to do so, without requiring a business-development deal or contractual agreement between the sites. Thus, user experiences weren’t subject to the vagaries of the political battles between different companies, but instead were consistently based on the extensible architecture of the web itself.

Times have changed. These days, instead of seeing themselves as part of a wider web, online services see themselves as standalone entities.

So what happened?

Facebook happened.

I don’t mean that Facebook is the root of all evil. If anything, Facebook—a service that started out being based on exclusivity—has become more open over time. That’s the cause of many of its scandals; the mismatch in mental models that Facebook users have built up about how their data will be used versus Facebook’s plans to make that data more available.

No, I’m talking about Facebook as a role model; the template upon which new startups shape themselves.

In the web’s early days, AOL offered an alternative. “You don’t need that wild, chaotic lawless web”, it proclaimed. “We’ve got everything you need right here within our walled garden.”

Of course it didn’t work out for AOL. That proposition just didn’t scale, just like Yahoo’s initial model of maintaining a directory of websites just didn’t scale. The web grew so fast (and was so damn interesting) that no single company could possibly hope to compete with it. So companies stopped trying to compete with it. Instead they, quite rightly, saw themselves as being part of the web. That meant that they didn’t try to do everything. Instead, you built a service that did one thing really well—sharing photos, managing links, blogging—and if you needed to provide your users with some extra functionality, you used the best service available for that, usually through someone else’s API …just as you provided your API to them.

Then Facebook began to grow and grow. I remember the first time someone was showing me Facebook—it was Tantek of all people—I remember asking “But what is it for?” After all, Flickr was for photos, Delicious was for links, Dopplr was for travel. Facebook was for …everything …and nothing.

I just didn’t get it. It seemed crazy that a social network could grow so big just by offering …well, a big social network.

But it did grow. And grow. And grow. And suddenly the AOL business model didn’t seem so crazy anymore. It seemed ahead of its time.

Once Facebook had proven that it was possible to be the one-stop-shop for your user’s every need, that became the model to emulate. Startups stopped seeing themselves as just one part of a bigger web. Now they wanted to be the only service that their users would ever need …just like Facebook.

Seen from that perspective, the open flow of information via APIs—allowing data to flow porously between services—no longer seemed like such a good idea.

Not only have APIs been shut down—see, for example, Google’s shutdown of their Social Graph API—but even the simplest forms of representing structured data have been slashed and burned.

Twitter and Flickr used to markup their user profile pages with microformats. Your profile page would be marked up with hCard and if you had a link back to your own site, it include a rel=”me” attribute. Not any more.

Then there’s RSS.

During the Q&A of that 2006 dConstruct talk, somebody asked me about where they should start with providing an API; what’s the baseline? I pointed out that if they were already providing RSS feeds, they already had a kind of simple, read-only API.

Because there’s a standardised format—a list of items, each with a timestamp, a title, a description (maybe), and a link—once you can parse one RSS feed, you can parse them all. It’s kind of remarkable how many mashups can be created simply by using RSS. I remember at the first London Hackday, one of my favourite mashups simply took an RSS feed of the weather forecast for London and combined it with the RSS feed of upcoming ISS flypasts. The result: a Twitter bot that only tweeted when the International Space Station was overhead and the sky was clear. Brilliant!

Back then, anywhere you found a web page that listed a series of items, you’d expect to find a corresponding RSS feed: blog posts, uploaded photos, status updates, anything really.

That has changed.

Twitter used to provide an RSS feed that corresponded to my HTML timeline. Then they changed the URL of the RSS feed to make it part of the API (and therefore subject to the terms of use of the API). Then they removed RSS feeds entirely.

On the Salter Cane site, I want to display our band’s latest tweets. I used to be able to do that by just grabbing the corresponding RSS feed. Now I’d have to use the API, which is a lot more complex, involving all sorts of authentication gubbins. Even then, according to the terms of use, I wouldn’t be able to display my tweets the way I want to. Yes, how I want to display my own data on my own site is now dictated by Twitter.

Thanks to Jo Brodie I found an alternative service called Twitter RSS that gives me the RSS feed I need, ‘though it’s probably only a matter of time before that gets shuts down by Twitter.

Jo’s feelings about Twitter’s anti-RSS policy mirror my own:

I feel a pang of disappointment at the fact that it was really quite easy to use if you knew little about coding, and now it might be a bit harder to do what you easily did before.

That’s the thing. It’s not like RSS is a great format—it isn’t. But it’s just good enough and just versatile enough to enable non-programmers to make something cool. In that respect, it’s kind of like HTML.

The official line from Twitter is that RSS is “infrequently used today.” That’s the same justification that Google has given for shutting down Google Reader. It reminds of the joke about the shopkeeper responding to a request for something with “Oh, we don’t stock that—there’s no call for it. It’s funny though, you’re the fifth person to ask today.”

RSS is used a lot …but much of the usage is invisible:

RSS is plumbing. It’s used all over the place but you don’t notice it.

That’s from Brent Simmons, who penned a love letter to RSS:

If you subscribe to any podcasts, you use RSS. Flipboard and Twitter are RSS readers, even if it’s not obvious and they do other things besides.

He points out the many strengths of RSS, including its decentralisation:

It’s anti-monopolist. By design it creates a level playing field.

How foolish of us, therefore, that we ended up using Google Reader exclusively to power all our RSS consumption. We took something that was inherently decentralised and we locked it up into one provider. And now that provider is going to screw us over.

I hope we won’t make that mistake again. Because, believe me, RSS is far from dead just because Google and Twitter are threatened by it.

In a post called The True Web, Robin Sloan reiterates the strength of RSS:

It will dip and diminish, but will RSS ever go away? Nah. One of RSS’s weaknesses in its early days—its chaotic decentralized weirdness—has become, in its dotage, a surprising strength. RSS doesn’t route through a single leviathan’s servers. It lacks a kill switch.

I can understand why that power could be seen as a threat if what you are trying to do is force your users to consume their own data only the way that you see fit (and all in the name of “user experience”, I’m sure).

Returning to Anil’s description of the web we lost:

We get a generation of entrepreneurs encouraged to make more narrow-minded, web-hostile products like these because it continues to make a small number of wealthy people even more wealthy, instead of letting lots of people build innovative new opportunities for themselves on top of the web itself.

I think that the presence or absence of an RSS feed (whether I actually use it or not) is a good litmus test for how a service treats my data.

It might be that RSS is the canary in the coal mine for my data on the web.

If those services don’t trust me enough to give me an RSS feed, why should I trust them with my data?

Figuring out

A recent simplequiz over on HTML5 Doctor threw up some interesting semantic issues. Although the figure element wasn’t the main focus of the article, a lot of the comments were concerned with how it could and should be used.

This is a subject that has been covered before on HTML5 Doctor. It turns out that we may have been too restrictive in our use of the element, mistaking some descriptive text in the spec for proscriptive instruction:

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

Steve and Bruce have been campaigning on the HTML mailing list to get the wording updated and clarified.

Meanwhile, in an unrelated semantic question, there was another HTML5 Doctor article a while back about quoting and citing with blockquote and its ilk.

The two questions come together beautifully in a blog post on the newly-redesigned A List Apart documenting this pattern for associating quotations and authorship:

 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>

Although, unsurprisingly, I still take issue with the decision in HTML5 not to allow the cite element to apply to people. As I’ve said before we don’t have to accept this restriction:

Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.

In which case, we get this nice little pattern combining figure, blockquote, cite, and the hCard microformat, like this:

 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption class="vcard"><cite class="fn">Sherlock Holmes</cite>, <cite>Sign of Four</cite></figcaption>

Or like this:

 <blockquote>Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.</blockquote>
 <figcaption class="vcard"><cite class="fn">Jeremy Keith</cite>, <a href="http://24ways.org/2009/incite-a-riot/"><cite>Incite A Riot</cite></a></figcaption>


I went out to The Albert the other night to see Twilight Hotel play. There were really good, so after the show I bought their CD, When The Wolves Go Blind.

It was only when I got home that I realised that I had no device that could play Compact Discs. I play all my music on my iPod or iPhone connected to a speaker dock. And my computer is a Macbook Air …no disc drive. So I had to bring the CD into work with me, stick into my iMac and rip the songs from there.

It’s funny how format (or storage medium) obsolescence creeps up on you like that. I wonder how long it will be until I’m not using any kind of magnetic medium at all.

Facing the future

There is much hand-wringing in the media about the impending death of journalism, usually blamed on the rise of the web or more specifically bloggers. I’m sympathetic to their plight, but sometimes journalists are their own worst enemy, especially when they publish badly-researched articles that fuel moral panic with little regard for facts (if you’ve ever been in a newspaper article yourself, you’ll know that you’re lucky if they manage to spell your name right).

Exhibit A: an article published in The Guardian called How I became a Foursquare cyberstalker. Actually, the article isn’t nearly as bad as the comments, which take ignorance and narrow-mindedness to a new level.

Fortunately Ben is on hand to set the record straight. He wrote Concerning Foursquare and communicating privacy. Far from being a lesser form of writing, this blog post is more accurate than the article it is referencing, helping to balance the situation with a different perspective …and a nice big dollop of facts and research. Ben is actually quite kind to The Guardian article but, in my opinion, his own piece is more interesting and thoughtful.

Exhibit B: an article by Jeffrey Rosen in The New York Times called The Web Means the End of Forgetting. That’s a bold title. It’s also completely unsupported by the contents of the article. The article contains anecdotes about people getting into trouble about something they put on the web, and—even though the consequences for that action played out in the present—he talks about the permanent memory bank of the Web and writes:

The fact that the Internet never seems to forget is threatening, at an almost existential level, our ability to control our identities.

Bollocks. Or, to use the terminology of Wikipedia, citation needed.

Scott Rosenberg provides the necessary slapdown, asking Does the Web remember too much — or too little?:

Rosen presents his premise — that information once posted to the Web is permanent and indelible — as a given. But it’s highly debatable. In the near future, we are, I’d argue, far more likely to find ourselves trying to cope with the opposite problem: the Web “forgets” far too easily.

Exactly! I get irate whenever I hear the truism that the web never forgets presented without any supporting data. It’s right up there with eskimos have fifty words for snow and people in the middle ages thought that the world was flat. These falsehoods are irritating at best. At worst, as is the case with the myth of the never-forgetting web, the lie is downright dangerous. As Rosenberg puts it:

I’m a lot less worried about the Web that never forgets than I am about the Web that can’t remember.

That’s a real problem. And yet there’s no moral panic about the very real threat that, once digitised, our culture could be in more danger of being destroyed. I guess that story doesn’t sell papers.

This problem has a number of thorns. At the most basic level, there’s the issue of . I love the fact that the web makes it so easy for people to publish anything they want. I love that anybody else can easily link to what has been published. I hope that the people doing the publishing consider the commitment they are making by putting a linkable resource on the web.

As I’ve said before, a big part of this problem lies with the DNS system:

Domain names aren’t bought, they are rented. Nobody owns domain names, except ICANN.

I’m not saying that we should ditch domain names. But there’s something fundamentally flawed about a system that thinks about domain names in time periods as short as a year or two.

Then there’s the fact that so much of our data is entrusted to third-party sites. There’s no guarantee that those third-party sites give a rat’s ass about the long-term future of our data. Quite the opposite. The callous destruction of Geocities by Yahoo is a testament to how little our hopes and dreams mean to a company concerned with the bottom line.

We can host our own data but that isn’t quite as easy as it should be. And even with the best of intentions, it’s possible to have the canonical copies wiped from the web by accident. I’m very happy to see services like Vaultpress come on the scene:

Your WordPress site or blog is your connection to the world. But hosting issues, server errors, and hackers can wipe out in seconds what took years to build. VaultPress is here to protect what’s most important to you.

The Internet Archive is also doing a great job but Brewster Kahle shouldn’t have to shoulder the entire burden. Dave Winer has written about the idea of future-safe archives:

We need one or more institutions that can manage electronic trusts over very long periods of time.

The institutions need to be long-lived and have the technical know-how to manage static archives. The organizations should need the service themselves, so they would be likely to advance the art over time. And the cost should be minimized, so that the most people could do it.

The Library of Congress has its Digital Preservation effort. Dan Gillmor reports on the recent three-day gathering of the institution’s partners:

It’s what my technology friends call a non-trivial task, for all kinds of technical, social and legal reasons. But it’s about as important for our future as anything I can imagine. We are creating vast amounts of information, and a lot of it is not just worth preserving but downright essential to save.

There’s an even longer-term problem with digital preservation. The very formats that we use to store our most treasured memories can become obsolete over time. This goes to the very heart of why standards such as HTML—the format I’m betting on—are so important.

Mark Pilgrim wrote about the problem of format obsolescence back in 2006. I found his experiences echoed more recently by Paul Glister, author of the superb Centauri Dreams, one of my favourite websites. He usually concerns himself with challenges on an even longer timescale, like the construction of a feasible means of interstellar travel but he gives a welcome long zoom perspective on digital preservation in Burying the Digital Genome, pointing to a project called PLANETS: Preservation and Long-term Access Through Networked Services.

Their plan involves the storage, not just of data, but of data formats such as JPEG and PDF: the equivalent of a Rosetta stone for our current age. A box containing format-decoding documentation has been buried in a bunker under the Swiss Alps. That’s a good start.

David Eagleman recently gave a talk for The Long Now Foundation entitled Six Easy Steps to Avert the Collapse of Civilization. Step two is Don’t lose things:

As proved by the destruction of the Alexandria Library and of the literature of Mayans and Minoans, “knowledge is hard won but easily lost.”

Long Now: Six Easy Steps to Avert the Collapse of Civilization on Huffduffer

I’m worried that we’re spending less and less time thinking about the long-term future of our data, our culture, and ultimately, our civilisation. Currently we are preoccupied with the real-time web: Twitter, Foursquare, Facebook …all services concerned with what’s happening right here, right now. The Long Now Foundation and Tau Zero Foundation offer a much-needed sense of perspective.

As with that other great challenge of our time—the alteration of our biosphere through climate change—the first step to confronting the destruction of our collective digital knowledge must be to think in terms greater than the local and the present.

Making Workshops for the Web

The latest Clearleft offering is Workshops for the Web. It made sense to move our workshop offerings out of the Clearleft site—where they were kind of distracting from the main message of the company—and give them their own home, just like our other events, dConstruct and UX London.

As well as the range of workshops that can be booked privately at any time, there’s a schedule of upcoming public workshops for 2010:

  1. CSS3 Wizardry on January 29th,
  2. Copywriting for the Web on March 5th,
  3. HTML5 for Web Designers on April 23rd,
  4. UX Fundamentals on June 11th and
  5. Usability Testing on July 16th.

The next workshop, CSS3 Wizardry with Rich and Nat, promises to be packed full of cutting-edge front-end techniques. Book a place if you want to have CSS3 kung-fu injected into your brainstem.

Visual Design

I’m pretty pleased with how the site turned out. When I began designing it initially, I thought I would give it a sort of Russian constructivist feeling: the title Workshops for the Web made me think of an international workers movement. I started researching political propaganda posters, beginning with the book Revolutionary Tides.

Revolutionary Tides

There’s also some fantastic propaganda material in The National Archives (and I just love the modern twist of World War Three propaganda posters). I found a treasure trove of images of American working life in the Flickr Commons collection from The Library of Congress. I started gathering these sources together and distilling some of the common components such as bold colours and diagonal lines.

Workers of the web: unite!

This was when Jon was working as an intern at Clearleft. I enlisted his help in brainstorming some ideas and he came up with some great stuff—like using Soviet space-race imagery—and we played around with proof-of-concept ideas for creating diagonal backgrounds using CSS3 transforms.

But it never really came together for me. Much as I loved the Russian constructivist propaganda angle, I ditched it and started from scratch.


I scribbled down a page description diagram describing what the site needed to communicate in order of importance:

  1. The name of the site.
  2. A positioning statement.
  3. The next workshop.
  4. Other upcoming workshops.
  5. A list of all workshops available.
  6. A way of getting in touch.

The hierarchy for an individual workshop page looked pretty similar:

  1. The title of the workshop.
  2. The date of the workshop.
  3. The location of the workshop.
  4. The price of the workshop.
  5. Details of the workshop.

It was clear that the page needed to quickly answer some basic questions: what? where? how much?

I started marking up the answers to those questions from top to bottom. That’s when it started to come together. Working with markup and CSS in the browser felt more productive than any of the sketching I had done in Photoshop. I started really sweating the typography …to the extent that I decided that even the logotype should be created with “live” text rather than an image.


From the start, I knew that I wanted the site to be a self-describing example of the technologies taught in the workshops. The site is built in HTML5, making good use of the new structural elements and the powerful outline algorithm. Marking up an events site with the hCalendar microformat was a no-brainer. There are hCards a-plenty too.

CSS3 nth-child selectors came in very handy and media queries are, quite simply, the bee’s knees when it comes to building a flexible site: just a few declarations allowed me to make sure the liquid layout could be optimised for different ranges of viewport size.

Workshops for the Web homepage Workshops for the Web homepage

Given the audience of the site, I could be fairly certain that Internet Explorer 6 wouldn’t be much of a hindrance. As it turns out, everything looks more or less okay even in that crappy browser. It looks different, of course, but then do websites need to look exactly the same in every browser?

Right before launch, Paul took a shot at tweaking the visual design, adding a bit more contrast and separation on the homepage with some horizontal banding. That’s a visual element that I had been subconsciously avoiding, probably because it’s already used on some of our other sites, but once it was added, it helped to emphasise the next upcoming workshop—the main purpose of the homepage.

Just because the site is live now doesn’t mean that I’ll stop working on it. I’d like to keep tweaking and evolving it. Maybe I’ll finally figure out a way of incorporating some elements of those great propaganda posters.



It’s been a busy week for microformats.

Google announced that it was following in the footsteps of in indexing microformats and RDFa to display in search results. For now, it’s a subset of microformats— and —on a subset of websites, including the newly microformated Yelp. The list of approved sites will increase over time so if you’re already publishing structured contact and review information, let Google know about it.

But the other new announcement is equally important. After a lot of hard work, the is ready for use.

The what now? I hear you ask. Well, if you’ve been feeling hampered by the combination of the and design patterns, the value class pattern offers a few alternatives.

To my mind, that’s one of the greatest strengths of the value class pattern: it doesn’t offer one alternative, it allows authors to choose how they want to mark up their content. I think that’s one of the reasons why datetime values have proven to be such a sticking point up ‘till now. Concerns about semantics and accessibility really come down to the fact that, as an author, you had very little choice in how you could mark up a datetime value.

You could either present the datetime between the opening and closing tags of whatever element you were using:

<span class="dtstart">

…or you could put the value in the title attribute of the abbr element:

<abbr class="dtstart" title="2009-06-05T20:00:00">
 Friday, June 5th at 8pm

Those were your only options.

But now, with the value class pattern, all of the following are possible:

<span class="dtstart">
 <abbr class="value" title="2009-06-05">
  Friday, June 5th
 <abbr class="value" title="20:00">

<span class="dtstart">
 <span class="value-title" title="2009-06-05T20:00:00">
  Friday, June 5th at 8pm

<span class="dtstart">
 <span class="value-title" title="2009-06-05">
  Friday, June 5th
 <span class="value-title" title="20:00">

<span class="dtstart">
 <span class="value-title" title="2009-06-05T20:00:00"> </span>
 Friday, June 5th at 8pm

Personally, I’ll probably use the first example. I like the idea of splitting up the date and time portions of a datetime value. I think there’s a big difference between putting a date string into the title attribute of an abbr element and putting a datetime string in there. In the past, when I argued that having an ISO date value in an abbreviation was semantic, accessible and internationalised, Mike Davies rightly accused me of using a strawman—the issue wasn’t about dates, it was about datetimes. That’s why I created the page on the microformats wiki; to disambiguate it as a subset of the larger .

Now, others might think that even using dates in combination with the abbr design pattern is semantically dodgy. That’s fine. They now have some other options they can use, thanks to the value-title subset of the value class pattern. Me? I don’t see myself using that. I’m especially not keen on the option to use an empty element. But I’m perfectly happy for other authors to go ahead and use that option. When it comes to writing, there are often no right or wrong answers, just personal preferences. That’s true whether it’s English, HTML, or any other language. As long as you use correct syntax and grammar, the details are up to you. You can choose semicolons or em-dashes when you’re writing English. You can choose abbr or value-title when you’re writing microformats.

The wiki page for the value class pattern doesn’t just list the options available to authors. It also explains them. That’s just as important. Head over there and read the document. I think you’ll agree that it’s an excellent example of clear, methodical writing.

The microformats wiki needs more pages like that. One of the biggest challenges facing microformats isn’t any particular technical problem; it’s trying to explain to willing HTML authors how to get up and running with microformats. Given Google’s recent announcement, there’ll probably be even more eager authors showing up, looking to sprinkle some extra semantics into their markup. We’ll be hanging out in the IRC channel, ready to answer any questions people might have, but I wish the wiki were laid out in a more self-explanatory way.

In the face of that challenge, the page for the value class pattern leads by example. Ben and Tantek have done a fantastic job. And it wouldn’t have been possible without the help and support of Bruce, James and Derek, those magnanimous giants of the accessibility community who offered help, support and data.

Small world, loosely joined

I’m in Seattle. Dopplr tells me that Bobbie is showing up in Seattle on the last day of my visit. I send Bobbie a direct message on Twitter. He tells me the name of the hotel he’ll be staying at.

I use Google Maps to find the exact address. All addresses on Google Maps are marked up with . I press the in my bookmarks bar to download the converted vcard into my address book. Thanks to , my updated address book is soon in the cloud online. My gets the updated information within moments.

I go to the address. I meet Bobbie. We have coffee. We have a chat.

The World Wide Web is a beautiful piece of social software.

Machine-tagging Huffduffer some more

After I wrote about the hoops I had to jump through to get Amazon’s API to output JSON (via XSLT), Tom detailed a way of avoiding JSON by using XML-RPC. That’s very kind of him but the truth is that:

  1. I like dealing with JSON and
  2. the XSL transformation is done by Amazon, not me; that wouldn’t be the case if I used XML-RPC.

Anyway, having successfully created a Huffduffer-Amazon bridge using machine tags, I thought I’d do a little more hacking. Instead of restricting the mashup love to Amazon, I figured that Last.fm would be the perfect place to pull in information for anything tagged with the music namespace.

Last.fm has quite a full-featured API and yes, it can output JSON. To start with, I’m using the artist.getInfo method for anything tagged with music:artist=..., music:singer=... or music:band=.... Here are some examples:

I’m pulling a summary of the artist’s bio, a list of similar artists and a picture of the artist in question. For maximum effect, view in Safari, the browser with the finest implementation of .

Nice as Last.fm’s API is, it’s not without its quirks. Like most APIs, the methods are divided into those that require (anything of a sensitive nature) and those that don’t (publicly available information). The method user.getInfo requires authentication. Yet, every piece of information returned by that method is available on the public profile.

So when I wanted to find a Last.fm user’s profile picture—having figured out through when someone on Huffduffer has a Last.fm account—it made far more sense for me to use to parse the microformatted public URL than to use the API method.

Just over two years ago, Drew delivered a superb presentation called In some situations, the answer is definitely “Yes.”

Update: It all ties together, as Julian explains on Twitter:

@adactio ha, I went to Drew’s presentation you mentioned on your blog; it made me add microformats to Last.fm in the first place :D


I’m up in London for . I arrive late to find Aaron Straup Cope in full flow. I saw Aaron at XTech two years ago talking about the idea of . Here we are today having a whole event devoted to it. His talk today sets the scene nicely, packed full of ideas.

Tom Taylor has an awesome analogue mashup. He bought a cheap little till printer, the small dinky kind that is used for printing off shop receipts. As he put it, If A4 is a blog, this is Twitter. He has hooked it up to an arduino board which connects to his computer which is connected to the internet. That’s the hardware side of the things. The software side of things is pretty simple. Every day at 8:00am, a programme pulls in data from various places: appointments from his calendar, the movements of his fellow travellers on Dopplr, and (of course). This gets output to a queue and a few seconds later, that gets output—via the arduino board—to the till printer. Tom now has a small slip of paper with all the little reminders he might need for the day. It is, as I said, awesome. I want one.

Till printer + arduino + laptop

Alexandra Deschamps-Sonsino is talking about making stuff with paper. But enough talk. Let’s actually make stuff. We are all seated around a table covered with paper, pens, scissors, tape, stanley knives and other tools. We have fifteen minutes to make either a piece of furniture, a building or an object we love. I don’t know what to build so I look up at the ceiling and start trying to build a scale model of it. It was fun.

Chris Heathcote loves guidebooks. Venice for Pleasure is the ur-guidebook, beautifully written. Wallpaper do guide books for people who live a clichéd designer lifestyle and take taxis everywhere. In Japan they have the concept of mooks: magazine books. They aren’t replaced every month; a new one comes out every month but you can buy the previous mooks too. Guidebooks are getting smaller which is a good thing. Chris tends to rip things out of his guidebooks—they tend to be for one-time use. He does the same with maps. Like Aaron said, you don’t want to be the tourist with the big map. Moleskine make notebooks with maps and tracing paper. And of course now, thanks to the papernet, you can make your own foldable maps, turkish or otherwise.

Nick O’Leary is talking about graphs. He wants to represent them with paper rather than simply on paper. He came up with some code that generates an image including lines showing where to fold and cut. Print it out, cut it and fold it and voila!, 3D graphs. He holds up an example. It’s beautiful. He wants to make a pop-up book of statistics. Absolutely bloody brilliant! This is data porn and paper porn rolled into one. Aaron asks if Nick has thought about applying this idea to creating topographical maps which, let’s face it, would be really, really handy for somewhere like San Francisco.

Nick's creation

We break for lunch and a bunch of us gravitate towards a bar called Camino, the only place in the vicinity that shares its name with a web browser. Some of the people I know, some I don’t. The conversation turns to code and hacking. I start to mention one of my favourite hacks at HackDay, Above London. Turns out that the person sitting next to me is Paul Mison, one of the Above London hackers and also creator of the machine tag browser that I blogged about.

After lunch, Sascha Pohflepp talks about Export to World. This looks familiar. Ah yes, I remember this being presented as the dinner entertainment during Reboot last year. He’s been taking objects out of Second Life and modelling them in the real world.

Now everyone gathers around a laptop for a demo from Durrell Bishop and Tom Hulbert from Luckybite. They have a printed book based on their music collection. Each page of the book contains an image—usually an album cover—and a barcode. If you scan the barcode from a page in the book, the corresponding music will play on your computer (or your phone). The book is the UI. The wireless barcode reader is where the magic happens. If these guys can make a cheap version of this reader, it will fantastic …for all us. Right now the only expensive bit is the reading head but the price could come down as low as a dollar or two. Sign me up!

James Wheare now gives a quick demo. He’s making a daily physical lifestream. Overnight, it pulls in blog entries, Flickr pictures and twitter messages from his friends and in the morning, he prints out a foldable A4 page. He can fold this down into a little booklet to take with him when he leaves the house.

Lifestream booklet

Karsten Schmidt begins by talking about print on demand. He shows beautiful computer-generated algorithm-driven book covers from Faber Finds. He then shows the most gorgeous unique identifiers I’ve ever seen. These are printed on to postcards for the end of year show at the London College of Fashion—one per student. These cards are machine readable at interactive tables. But what about generating machine-readable identifiers without using a machine? Right now you still need a computer and a printer. What if you could use origami instead? If you think about it, that’s what’s going on with Edward James Olmos’s unicorn in Bladerunner. Take a piece of paper, configure it in a certain way; now it contains a machine-readable message.

At this stage, my mind is well and truly blown and we aren’t even finished yet. Sawa Tanaka is now going to show some of her work. Here’s a book called Spot Nocturnal Animals which is all white in the daylight but once it gets dark, you can shine a UV light on the paper to expose animal tracks and information. The Egg Book uses thermochromic ink. When you warm it up—Sawa blows on the page at this point—baby birds are revealed. Here’s the missing piece of the papernet puzzle: edibility. Sawa has made edible prints on rice paper: English breakfast, fish’n’chips, soba …this is making me hungry. She has also created a beautiful box of pictures of Hiroshima with pictures from 1945 burnt onto pictures from 2007. Every one of her projects is wonderful.

Sawa Tanaka

Next up is Beeker Northam who speaks about photographing paper. She doesn’t like throwing away books. She photographs her books. There’s something about photographing them that’s different to scanning them. She’d like to have some kind of web-based way for people to share those bits of books that have had an emotional impact on them but she hasn’t found it yet. There are book sharing sites out there but they all take a library-based approach.

I’m up next. I feel bad because, not only do I not have a demo or prototype to show, I don’t even have any slides. All I have is an idea. And ideas are a dime a dozen. It’s following through that counts. But still …I’m using PaperCamp as a real-world LazyWeb; running an idea up the flagpole; opening the kimono; attempting a landing on the Hudson.

I had this idea a while back of doing a location-based audio service. I heard about a site that offered user-generated audio guides for museums. Download the MP3, stick it on your iPod, go to the museum and press play. I thought it would be good to do the same thing for any kind of location. For example, I could walk around Brighton recording my thoughts about the architecture or talking about the best restaurants, and then I could upload that audio file and geotag it so that somebody else can later retrace my steps and hear my words. The problem I’ve found with this idea is the lack of good recording devices. We have ubiquitous listening devices—iPods—but the ubiquitous devices we talk into—mobile phones—aren’t the right fit for this, I fear.

So the idea of location-based shared audio languished on the back burner. Then I saw Aaron speaking at XTech about the papernet and I begin to think that words on paper might be a better medium than words in headphones. Paper is compact, durable and portable. Then Moleskine came out with their city guides and that’s when I joined the dots: what I want is a guide book that grows over time. It could work something like Book Crossing, with people passing the notebooks along to the next person visiting a place. To begin with, the notebooks are sparse, containing only maps but then they get filled with notes, stories, tips and recommendations.

It strikes me that the internet is superb for communication and collaboration over distance: Wikipedia, Flickr, blogs …physical distance collapses completely. Meanwhile, the physical world has an emotional immediacy and tactile feel that can’t be captured online. I’d like to bridge those worlds using guidebooks as the glue: physical objects in the real world that benefit from the collaborative environment of the internet. I’m not sure if Moleskine city guides are necessarily the best vessels. That would limit the potential places to just those cities that have guidebooks. A print-on-demand book containing maps from OpenStreetMap, photos from Flickr places and text from Wikipedia could make for an equally good starting point as long as the physical dimensions are notebook-like.

That’s my idea. I can foresee some serendipitous side-effects growing out of this infrastructure—games and treasure hunts, perhaps—but I can also imagine some challenges—like co-ordinating the physical shipping of the books from person to person (maybe drop-off points are a better idea). Then there’s the fact that all this information that’s being accumulated is stuck in a physical object that isn’t machine-readable without some scanning and OCR—it seems a shame that the information can’t easily flow back from the real world onto the internet.

I’m done pitching my idea and ask what people think. Aaron says he wants to help me build this. Yay! He also says that my worries about getting the information from book to internet shouldn’t be too much of a cause for concern. I agree: it’s certainly not a show-stopper. Alex likes the idea of the time-sensitive nature of recording thoughts about a place; the places that you visited when you were in a relationship, for example, will be coloured by how you felt in that relationship. I hadn’t thought about that, but yes, these notebooks could be vessels for messages from your past self to your present or future self. Denise reckons that this might not even be a technological undertaking at all: she mentions a notebook of sketches that was simply passed from designer to designer, filling up over time. I think that’s largely true but there’s also great potential in the social aspect of sharing the books: I’m going to want notebooks that have previously been used by people I know or whose opinion I trust. But yes, fundamentally all I’m proposing is a web-based admin system for co-ordinating the sharing.

With that, I’m done. I hand the floor over to Matt Ward who closes the event with his thoughts about everything he’s seen today. Keywords are augmentation, materiality and craft-bioinformatic-origami-unicorns.

The other Matt finishes by thanking us all for coming and turning a drunken conversation in the pub into something that will keep him thinking for all of 2009. Hear, hear! Thank you, Mr. Jones, for organising this inspiring gathering.

Hacking Huffduffer with Last.fm

The took place in London yesterday. Much nerdy fun was had by all and some very cool hacks were produced.

Nigel made a neat USB-powered arduino-driven ambient signifier à la availibot that lights up when one of your friends is listening to music. Matt made Songcolours which takes your recently listened-to music, passes the songs through LyricWiki, extracts words that are colours, passes them through the Google chart API and generates a sentence of cut up lyrics (Hannah’s was the best: love drunk home fuck good night). The winning hack, Staff Wars, is a Last.fm-powered quiz that allows people to battle for control of the office stereo—something that could prove very useful at Clearleft.

I knew I’d never be able to compete with the l33t hax0rs in attendance, so I cobbled together a very quick little hack to enhance Huffduffer. I hacked it together fairly quickly which gave me some time to hang out with Hannah in the tragically hip environs of Shoreditch. My hack has one interesting distinguishing feature: it doesn’t make use of the API. Instead, it uses two simpler technologies: microformats and .

  1. Microformats. User profiles on Last.fm are marked up with . If a URL is provided, the user profile also makes use of the most powerful value of : rel="me". If that URL also links back to the Last.fm profile with rel="me"—even if in a roundabout way—that reciprocal link will be picked by Google’s Social Graph API. I’m already making use of that API on Huffduffer to display links to other profiles under the heading Elsewhere. So if someone provides a URL when they sign up to Huffduffer and they’re linking to their social network profiles, I can find out if they use Last.fm and what their username is. The URL structure of user profiles is consistent: http://www.last.fm/user/USERNAME.
  2. RSS. Last.fm provides users with a list of recommended free MP3s. This list is also provided as RSS. More specifically, the RSS feed is a podcast. After all, a podcast is nothing more than an RSS feed that uses enclosures. The URL structure of these podcasts is consistent: http://ws.audioscrobbler.com/2.0/user/USERNAME/podcast.rss.

So if, thanks to magic of XFN, I can figure out someone’s Last.fm username, it’s a simple matter to pull in their recommended music podcast. I’m pulling in the latest three recommended MP3s and displaying them on Huffduffer user profiles under the heading Last.fm recommends. You can see it in action on my Huffduffer profile or the profiles of any other good social citizens like Richard, Tom or Brian.

This isn’t the first little Huffduffer hack I’ve built on top of the Social Graph API. If a Huffduffer user has a Flickr account, their Flickr profile picture is displayed on their Huffduffer profile. When I get some time, I need to expand this little hack to also check for Twitter profiles and grab the profile picture from there as a fallback.

None of these little enhancements are essential features but I like the idea of rewarding people on Huffduffer for their activity on other sites. Ideally I’d like to have Huffduffer’s recommendation engine being partially driven by relationships on third-party sites. So your user profile might suggest something like, You should listen to this because so-and-so huffduffed it; you know one another on Twitter, Flickr, Last.fm…

hCard Wizard

The microformats meetup in San Francisco after An Event Apart had quite a turnout. The gathering was spoiled only by Jenn getting her purse stolen. Two evenings earlier, Noel had been robbed at gunpoint. San Francisco wasn’t exactly showing its best side.

Still, the microformats meetup was a pleasant get-together. Matthew Levine pulled out his laptop and gave me a demo of the Lazy Web in action…

On the first day of An Event Apart, I twittered a reminder that my liveblogging posts were filled with hCards. Christian asked how I added the hCards and I replied that, while I just add them by hand, some kind of “wizard” for adding simple hCards to any textarea would be very welcome.

Less than 48 hours later, Matthew had whipped up exactly what I asked for. It’s a bookmarklet. Drag it to your bookmarks bar and click on it whenever you want to add a simple hCard. It uses JavaScript to create a faux window with a form where you are prompted to enter given name and family name. You can also add a middle name and a URL.

This is just a small subset of all the properties available in hCard so it isn’t suitable for detailed hCards. If you’re creating the markup for a contact page, for example, you’d be better off with the hCard-o-matic. But this little bookmarklet easily hits 80% of the use cases for adding hCards within body text (like in a blog post, for example).

This is a first release and there will inevitably be improvements. The ability to add XFN values would be a real boon. Still… that’s really impressive work for something that was knocked together so quickly.

If you want to use the bookmarklet (regardless of what blogging engine or CMS you use), drag this to your bookmarks bar:

hCard Wizard

Open Tech 2008

Open Tech was fun. It was like a more structured version of BarCamp: the schedule was planned in advance and there was a nominal entrance fee of £5 but apart from that, it was pretty much OpenCamp. Most of the talks were twenty minutes long, grouped into hour-long thematically linked trilogies.

Things kicked off with a three way attack by Kim Plowright, Simon Wardley and Matt Webb. I particularly enjoyed Matt’s stroll down the memory lane of the birth of cybernetics. Alas, the fact that I stayed to enjoy this history lesson meant that I missed David Hayes’s introduction to Edenbee. But I did stick around for the next set of environment-related talks including a demo of the Wattson from DIY Kyoto and the always-excellent Gavin Starks of AMEE fame.

After a pub lunch spent being entertained by Ewan Spence’s thoroughly researched plan for a muppet remake of Star Wars, I made it back in time for a well-connected burst of talks from Simon, Gavin and Paul. Simon pimped OpenID. Gavin delivered a healthy dose of perspective from the h’internet. Paul ranted about the technologies depicted in his wonderful illustration entitled The Web is Agreement.

I made sure to catch the state of the nation address from Open Street Map. It was, as expected, inspiring. It’s quite amazing how far the project has come since the last Open Tech in 2005. Hearing about the wealth of data available gave me the kick up the arse to update the dConstruct location page to use Open Street Map tiles. It turned out to be a simple process involving the addition of just a few more lines of JavaScript.

My talk at Open Tech was a reprise of my XTech presentation, Creating Portable Social Networks With Microformats although the title on the schedule was Publishing With Microformats. I figured that the Open Tech audience would be fairly advanced so I decided against my original plan of doing an introductory level talk. The social network portability angle also tied in with quite a few other talks on the day.

I shared my slot with Jeni Tennison who gave a hands-on look at RDFa at the London Gazette. The two talks complemented each other well… just like microformats and RDFa. As Jeni said, microformats are great for doing the easy stuff—the low-hanging fruit—and deliberately avoid more complex data structures: they hit 80% of the use cases with 20% of the effort. RDFa, on the other hand, can handle greater complexity but with a higher learning curve. RDFa covers the other 20% of use cases but with 80% effort. Jeni’s case study was the perfect example. Whereas as I had been showing the simple patterns of user profiles and relationships on social networks (easily encoded with and ), she was dealing with a very specific data set that required its own ontology.

I was chatting with Dan at the start of Open Tech about this relationship. We’re both pretty fed up with the technologies being set up as somehow being rivals. Personally, I’m very happy that RDFa covers the kind of data structures that microformats doesn’t touch. When someone comes to the microformats community with an idea for a complex data format, it’s handy to have another technology to point them to. If you’re dealing with simple, common structures that have aggregate benefit like contact details, events and reviews, microformats are the perfect fit. But if you’re dealing with more complex structures—and I’m thinking here about museum collections, libraries and laboratories—chances are that some flavour of is going to be more suitable.

Jeni and I briefly discussed whether we should set up our talks as a kind of mock battle. But that kind of rivalry, even when it’s done in a jokey fashion, is unnecessary and frankly, more than a little bit dispiriting. It’s more constructive to talk about real-world use cases. On that basis, I think our Open Tech presentations hit the right note.

Open Tech schedule

I’ll be heading up to the University of London tomorrow for Open Tech 2008. The last Open Tech was in 2005 which was, by all accounts, a legendary affair—it led directly to the creation of the ORG.

I’ll be speaking about microformats, probably reworking some of the things I was talking about at XTech. It looks like there’ll be quite a lot of discussion around social networks, portability and privacy so I’m going to concentrate on XFN and hCard. Speaking of which, be sure to read Ben’s excellent article on Digital Web and then check out David’s superb implementation of the Social Graph API: what a productive pair of flatmates!

I put together an hCalendar schedule for Open Tech so if you’re going along, you might want to subscribe. I recommend subscribing over downloading as the schedule is likely to change. I’ll do my best to update the hCalendar document accordingly. Depending on the WiFi situation and how knackered I am after the early start from Brighton, I may try to do some liveblogging.

XTech 2008

I enjoyed being back in Ireland. Jessica and I arrived into Dublin last Saturday but went straight from the airport to the train station so that we could spend the weekend in seeing family and friends. Said town was somewhat overwhelmed by the arrival of .

We were back in Dublin in plenty of time for the start of this year’s XTech conference. A good time was had by the übergeeks gathered in the salubrious surroundings of a newly-opened hotel in the heart of Ireland’s capital. This was my third XTech and it had much the same feel as the previous two I’ve attended: very techy but nice and cosy. In some ways it resembles a BarCamp (but with a heftier price tag). The talks are held in fairly intimate rooms that lend themselves well to participation and discussion.

I didn’t try to attend every talk — an impossible task anyway given the triple-track nature of the schedule — but I did my damndest to liveblog the talks I did attend:

  1. Opening Keynote by David Recordon.
  2. Using socially-authored content to provide new routes through existing content archives by Rob Lee.
  3. Browsers on the Move: The Year in Review, the Year Ahead by Michael Smith.
  4. Building the Real-time Web by Matt Biddulph, Seth Fitzsimmons, Rabble and Ralph Meijer.
  5. AMEE — The World’s Energy Meter by Gavin Starks.
  6. Ni Hao, Monde: Connecting Communities Across Cultural and Linguistic Boundaries by Simon Batistoni.
  7. Data Portability For Whom? by Gavin Bell.
  8. Why You Should Have a Web Site by Steven Pemberton.
  9. Orangutans, Oxen and Ogham Stones by Sean McGrath.

There were a number of emergent themes around social networks and portability. There was plenty of SemWeb stuff which finally seems to be moving from the theoretical to the practical. And once again the importance of XMPP, first impressed upon me at the Social Graph Foo Camp, was once again made clear.

Amongst all these high-level technical talks, I gave a presentation that was ludicrously simple and simplistic: Creating Portable Social Networks with Microformats. To be honest, I could have delivered the talk in 60 seconds: Add rel="me" to these links, add rel="contact" to those links, and that’s it. If you’re interested, you can download a PDF of the presentation including notes.

I made an attempt to record my talk using Audio Hijack. It seems to have worked okay so I’ll set about getting that audio file transcribed. The audio includes an unusual gap at around the four minute mark, just as I was hitting my stride. This was the point when Aral came into the room and very gravely told me that he needed me to come out into the corridor for an important message. I feared the worst. I was almost relieved when I was confronted by a group of geeks who proceeded to break into song. You can guess what the song was.

Ian caught the whole thing on video. Why does this keep happening to me?

Sand E. Eggo

I’m in San Diego for Jared’s Web App Summit. It’s my first time here and I find myself quite won over by the city’s charm. It’s a shiny sparkly kind of place.

The conference kicked off with a day of workshops. I should have tried to gatecrash Luke or Indy’s sessions but with the weather being so nice, I bunked off with Derek, Keith and Cindy to venture across the water from Coronado to explore the city. With no plan in mind, we found our path took us to the USS Midway, now a floating museum. We spent the rest of the afternoon geeking out over planes and naval equipment.

I got my talk about Ajax design challenges out of the way yesterday. It seemed to go pretty well. It might have been a little bit too techy for some of the audience here but I’ve received some very nice comments from a lot of people. As usual, the presentation is licensed under a Creative Commons attribution license. Feel free to download the slides but the usual caveat applies: the slides don’t make all that much sense in isolation.

With that out of the way, I was able to relax and enjoy the rest of the day. The highlight for me was listening to Bill Scott talk about interaction anti-patterns. I found myself nodding vigourously in agreement with his research and recommendations. But I must join in the clamour of voices calling for Bill to put this stuff online somewhere. I would love to have a URL I could point to next time I’m arguing against adding borked behaviour to a web app.

The conference continues today. Jason Fried kicked off the day’s talks and Keith and Derek will be in the spotlight later on (it’s always convenient when Derek is on the same bill as me because I can fob off all the Ajax accessibility issues on him).

Before making the long journey back to the UK I’ve got a social event I’m looking forward to attending. There’s a microformats dinner tonightTantek is in town too for a CSS Working Group meetup. Come along to Gateway to India at 9520 Black Mountain Road if you’re in San Diego. We can combine a vegetarian Indian buffet with semantic geekery.