Archive: February, 2011

The travelling time is underway. I’m in Denmark right now, leading an HTML5 workshop at NoMA, the Nordic Multimedia Academy, and thanks to some excellent questions from the students, it’s all going smoothly.

Last week I was in Belgium for the Phare conference, which also went smoothly. I enjoyed giving my presentation and I really enjoyed the excellent hospitality of the Ghentians.

While I was in Belgium, the occasion of my fortieth birthday arrived with a sense of long-foreseen inevitability. I spent it in Bruges.

Four zero. The big four oh. Two squared times ten. The answer to life, the universe and everything minus two.

The photons that were reflected from Earth at the time of my birth are arriving at GJ 1214 b. Or, to put in another way, the light that left GJ 1214 at the moment of my birth is entering our solar system, perhaps even reaching the retinas of human beings somewhere on this planet who happen to be looking into just the right part of the sky at just the right time.

The secret to a good war movie is not in the depiction of battle, but in the depiction of the preparation for battle. Whether the fight will be for Agincourt, Rourke’s Drift, Helm’s Deep or Hoth, it’s the build-up that draws you in and makes you care about the outcome of the upcoming struggle.

That’s what 2011 has felt like for me so far. I’m about to embark on a series of presentations and workshops in far-flung locations, and I’ve spent the first seven weeks of the year donning my armour and sharpening my rhetorical sword (so to speak). I’ll be talking about HTML5, responsive design, cultural preservation and one web; subjects that are firmly connected in my mind.

It all kicks off in Belgium. I’ll be taking a train that will go under the sea to get me to Ghent, location of the Phare conference. There I’ll be giving a talk called All Our Yesterdays.

This will be non-technical talk, and I’ve been given carte blanche to get as high-falutin’ and pretentious as I like …though I don’t think it’ll be on quite the same level as my magnum opus from dConstruct 2008, The System Of The World.

Having spent the past month researching and preparing this talk, I’m looking forward to delivering it to a captive audience. I submitted the talk for consideration to South by Southwest also, but it was rejected so the presentation in Ghent will be a one-off. The SXSW rejection may have been because I didn’t whore myself out on Twitter asking for votes, or it may have been because I didn’t title the talk All Our Yesterdays: Ten Ways to Market Your Social Media App Through Digital Preservation.

Talking about the digital memory hole and the fragility of URLs is a permanently-relevant topic, but it seems particularly pertinent given the recent moves by the BBC. But I don’t want to just focus on what’s happening right now—I want to offer a long-zoom perspective on the web’s potential as a long-term storage medium.

To that end, I’ve put my money where my mouth is—$50 worth so far—and placed the following prediction on the Long Bets website:

The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.

If you have faith in the Long Now foundation’s commitment to its URLs, you can challenge my prediction. We shall then agree the terms of the bet. Then, on February 22nd 2022, the charity nominated by the winner will receive the winnings. The minimum bet is $200.

If I win, it will be a pyrrhic victory, confirming my pessimistic assessment.

If I lose, my faith in the potential longevity of URLs will be somewhat restored.

Depending on whether you see the glass as half full or half empty, this means I’m either entering a win/win or lose/lose situation.

Care to place a wager?

Ian Hunter at the BBC has written a follow-up post to his initial announcement of the plans to axe 172 websites. The post is intended to clarify and reassure. It certainly clarifies, but it is anything but reassuring.

He clarifies that, yes, these websites will be taken offline. But, he reassures us, they will be stored …offline. Not on the web. Without URLs. Basically, they’ll be put in a hole in the ground. But it’s okay; it’s a hole in the ground operated by the BBC, so that’s alright then.

The most important question in all of this is why the sites are being removed at all. As I said, the BBC’s online mothballing policy has—up till now—been superb. Well, now we have an answer. Here it is:

But there still may come a time when people interested in the site are better served by careful offline storage.

There may be a parallel universe where that sentence makes sense, but it would have to be one in which the English language is used very differently.

As an aside, the use of language in the “explanation” is quite fascinating. The post is filled with the kind of mealy-mouthed filler words intended to appease those of us who are concerned that this is a terrible mistake. For example, the phrase “we need to explore a range of options including offline storage” can be read as “the sites are going offline; live with it.”

That’s one of the most heartbreaking aspects of all of this: the way that it is being presented as a fait accompli: these sites are going to be ripped from the fabric of the network to be tossed into a single offline point of failure and there’s nothing that we—the license-payers—can do about it.

I know that there are many people within the BBC who do not share this vision. I’ve received some emails from people who worked on some of the sites scheduled for deletion and needless to say, they’re not happy. I was contacted by an archivist at the BBC, for whom this plan was unwelcome news that he first heard about here on adactio.com. The subsequent reaction was:

It was OK to put a videotape on a shelf, but putting web pages offline isn’t OK.

I hope that those within the BBC who disagree with the planned destruction will make their voices heard. For those of us outside the BBC, it isn’t clear how we can best voice our concerns. You could make a complaint to the BBC, though that seems to be intended more for complaints about programme content.

In the meantime, you can download all or some of the 172 sites and plop them elsewhere on the web. That’s not an ideal solution—ideally, the BBC shouldn’t be practicing a deliberate policy of link rot—but it allows us to prepare for the worst.

I hope that whoever at the BBC has responsibility for this decision will listen to reason. Failing that, I hope that we can get a genuine explanation as to why this is happening, because what’s currently being offered up simply doesn’t cut it. Perhaps the truth behind this decision lies not so much with the BBC, but with their technology partner, Siemens, who have a notorious track record for shafting the BBC, charging ludicrous amounts of money to execute the most trivial of technical changes.

If this decision is being taken for political reasons, I would hope that someone at the BBC would have the honesty to say so rather than simply churning out more mealy-mouthed blog posts devoid of any genuine explanation.

I remember when Google Maps first launched back in February 2005. As well as being enormous fun—I spent hours finding famous landmarks and places—it was a complete game-changer. The “slippy maps” style of interaction felt weird, then delightful and then just …right.

Things move fast on the web. It didn’t take long for us to get used to slippy maps. Before too long, we came to expect them. These days, if I see a map in a web page, I expect to be able to drag and pan within it. If instead, when I click and and drag, I discover that the map is just a plain old-fashioned image, it feels …wrong.

Similarly, if I visit a web page that’s about an event, I expect to be able to use a bookmarklet or browser extension, or click a link to add it my calendar by converting the page’s hCalendar. If instead it turns out that the page isn’t using microformats, it’s like discovering that what looked like a house on the outside is actually just a facade with nothing behind it. It feels …wrong.

Increasingly, I’m getting that feeling whenever I visit a website that doesn’t respond to the size and capabilities of my browser. If I get handed a crawlbar, I try to understand the reason for it but more often than not, it’s simply a sign that the website has been built by someone with a non-web, print-based, fixed-canvas mentality. It feels …wrong.

That’s why I can relate to what Andy says:

Today, anything that’s fixed and unresponsive isn’t web design, it’s something else. If you don’t embrace the inherent fluidity of the web, you’re not a web designer, you’re something else.

Web design is responsive design, Responsive Web Design is web design, done right.

Web designers and developers have become very comfortable in approaching the web from one context: the so-called “desktop” environment (just as they got very comfortable a few years back designing for a stagnant, slow-moving browser landscape). This complacency has led to lazy and sloppy thinking; assuming that any content can be served up in a 960 pixel wide container; assuming that using plenty of large images isn’t a problem because bandwidth has improved over time.

I’m glad that the increasing diversity of devices—together with the ascendancy of so-called “mobile”—is forcing designers and developers to move beyond their fixed-width comfort zone.

There’s still a lot of resistance, though. That’s why the idea of creating separate silos for “mobile” devices is initially so appealing. But that approach won’t scale: it’s just not practical to spend equal time and effort crafting different endpoints for iPhone, Android, Palm, Kindle, iPad, etc. The solution is to either reject part of your potential audience and concentrate only on a subset of users like, say, just iPhone users …or you can embrace responsive design. The first option is the cure that kills the patient. The second option might seem intimidating at first, but it’s going to become increasingly accepted. Inevitable, even.

Those who are currently rejecting responsive design point to the difficulties of making desktop-optimised sites work on small screens with potentially narrow bandwidth. They’re right. But the solution is not to create a separate site just for smaller screens. The solution is to fix the site so it isn’t optimised for just one environment.

The truth is that web designers and developers have been making device-specific websites for years; it’s just that the device in question was the desktop computer. But just about every point in the W3C’s Mobile Best Practices should be applied to all websites.

This new approach to designing and building websites reminds me of a similar sea-change a few years ago. The change from table-based layouts to CSS and semantic markup seemed far from inevitable at first. It met with a lot of resistance from designers and developers who had grown comfortable with their existing sets of skills. It took trailblazers like Doug, Mike, Dan and Dave to demonstrate the possibilities by launching the Wired redesign, the ESPN redesign, the Fast Company redesign and of course, the CSS Zen Garden.

As always, the innovation begins with personal projects. Take a look at the Media Queries website—a showcase for responsive designs and a handy place to find out how others are dealing with fluid grids and resizing images. The majority of the showcased sites are personal sites, demonstrating the possibilities of device-agnostic development.

I’m looking forward to seeing the first really big brand relaunch that embraces responsive design. After that, prepare for the floodgates to open.

If, by the way, you happen to work at a company that’s looking to abandon a desktop-specific web presence in favour of something that’s truly native to the web, get in touch with Clearleft. We’re excited about this approach to web design. It feels …right.

I don’t get up to London that often. Much as I like the place, the travel to and fro from Brighton can be exhausting, given the woeful state of the rail services on that line—just ask anybody who does the daily commute.

On Monday, I had an appointment in London. Rather than take the usual train to Victoria, it made more sense to take the London Bridge route. It must have been quite a while since I was last on that train because, as it pulled into London Bridge station, I was confronted with the impressive sight of a science fictional structure rising out of the city: the Shard.

From my subjective perspective, it came out of nowhere. The sense of having a large chunk of the future come crashing into my present was amplified by the soundscape; I was listening to the soundtrack from science-fiction film on a small, handheld touchscreen device with more storage than the combined hard drive space of all the computers I ever used up to just a few years ago. The last time I experienced this collision was on the train between Copenhagen and Malmö, listening to the soundtrack to Blade Runner, looking out at the colossal turbines of the offshore wind farm.

On my way back to Brighton, the experience was reversed. Heralded by the kind of doppler-stretched whistle that you only hear in old films, a steam engine raced by, hauling dining cars of elegantly-decked tables draped in white, a lamp on each one.

“The future is already here”, said William Gibson. “It’s just not very evenly distributed.” The past is still here too, equally unevenly-distributed.

The present is a lumpy place on the timeline.

I wrote a little while back about my feelings on hash-bang URLs:

I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness…

Fortunately, Mike Davies is more articulate than I. He’s written a detailed account of breaking the web with hash-bangs.

It would appear that hash-bang usage is on the rise, despite the fact that it was never intended as a long-term solution. Instead, the pattern (or anti-pattern) was intended as a last resort for crawling Ajax-obfuscated content:

So the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

Mike goes into detail on the Gawker outage that was a direct result of its “sites” being little more than single pages that require JavaScript to access anything.

I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.

Though it may not seem like it at times, we’re actually in a pretty great position when it comes to front-end development on the web. As long as we use progressive enhancement, the front-end stack of HTML, CSS, and JavaScript is remarkably resilient. Remove JavaScript and some behavioural enhancements will no longer function, but everything will still be addressable and accessible. Remove CSS and your lovely visual design will evaporate, but your content will still be addressable and accessible. There aren’t many other platforms that can offer such a robust level of loose coupling.

This is no accident. The web stack is rooted in Postel’s law. If you serve an HTML document to a browser, and that document contains some tags or attributes that the browser doesn’t understand, the browser will simply ignore them and render the document as best it can. If you supply a style sheet that contains a selector or rule that the browser doesn’t recognise, it will simply pass it over and continue rendering.

In fact, the most brittle part of the stack is JavaScript. While it’s far looser and more forgiving than many other programming languages, it’s still a programming language and that means that a simple typo could potentially cause an entire script to fail in a browser.

That’s why I’m so surprised that any front-end engineer would knowingly choose to swap out a solid declarative foundation like HTML for a more brittle scripting language. Or, as Simon put it:

Gizmodo launches redesign, is no longer a website (try visiting with JS disabled): http://gizmodo.com/

Read Mike’s article, re-read this article on URL design and listen to what John Resig has to say in this interview .

Yesterday’s account of the BBC’s decision to cull 172 websites caused quite a stir on Twitter.

Most people were as saddened as I was, although Emma described my post as being “anti-BBC.” For the record, I’m a big fan of the BBC—hence my disappointment at this decision. And, also for the record, I believe anyone should be allowed to voice their criticism of an organisational decision without being labelled “anti” said organisation …just as anyone should be allowed to criticise a politician without being labelled unpatriotic.

It didn’t take long for people to start discussing an archiving effort, which was heartening. I started to think about the best way to coordinate such an effort; probably a wiki. As well as listing handy archiving tools, it could serve as a place for people to claim which sites they want to adopt, and point to their mirrors once they’re up and running. Marko already has a head start. Let’s do this!

But something didn’t feel quite right.

I reached out to Jason Scott for advice on coordinating an effort like this. He has plenty of experience. He’s currently trying to figure out how to save the more than 500,000 videos that Yahoo is going to delete on March 15th. He’s more than willing to chat, but he had some choice words about the British public’s relationship to the BBC:

This is the case of a government-funded media group deleting. In other words, this is something for The People, and by The People I mean The Media and the British and the rest to go HEY BBC STOP

He’s right.

Yes, we can and should mirror the content of those 172 sites—lots of copies keep stuff safe—but fundamentally what we want is to keep the fabric of the web intact. Cool URIs don’t change.

The BBC has always been an excellent citizen of the web. Their own policy on handling outdated content explains the situation beautifully:

We don’t want to delete pages which users may have bookmarked or linked to in other ways.

Moving a site to a different domain will save the content but it won’t preserve the inbound connections; the hyperlinks that weave the tapestry of the web together.

Don’t get me wrong: I love the Internet Archive. I think that Brewster Kahle is doing fantastic work. But let’s face it; once a site only exists in the archive, it is effectively no longer a part of the living web. Yet, whenever a site is threatened with closure, we invoke the Internet Archive as a panacea.

So, yes, let’s make and host copies of the 172 sites scheduled for termination, but let’s not get distracted from the main goal here. What we are fighting against is link rot.

I don’t want the BBC to take any particular action. Quite the opposite: I want them to continue with their existing policy. It will probably take more effort for them to remove the sites than to simply let them sit there. And let’s face it, it’s not like the bandwidth costs are going to be a factor for these sites.

Instead, many believe that the BBC’s decision is politically motivated: the need to be seen to “cut” top level directories, as though cutting content equated to cutting costs. I can’t comment on that. I just know how I feel about the decision:

I don’t want them to archive it. I just want them to leave it the fuck alone.

“What do we want?” “Inaction!”

“When do we want it?” “Continuously!”

In the 1960s and ’70s, it was common practice at the BBC to reuse video tapes. Old recordings were taped over with new shows. Some Doctor Who episodes have been lost forever. Jimi Hendrix’s unruly performance on Happening for Lulu would have also been lost if a music-loving engineer hadn’t sequestered the tapes away, preventing them from being over-written.

Except - a VT engineer called Bob Pratt, who really ought to get a medal, was in the habit of saving stuff he liked. Even then, the BBC policy of wiping practically everything was notorious amongst those who’d made it. Bob had the job of changing the heads on 2” VT machines. He’d be in at 0600 before everyone else and have two hours to sort the equipment before anyone else came in. Rock music was his passion, and knowing everything would soon disappear, would spend some of that time dubbing off the thing he liked onto junk tapes, which would disappear under the VT department floor.

To be fair to the BBC, the tape-wiping policy wasn’t entirely down to crazy internal politics—there were convoluted rights issues involving the actors’ union, Equity.

Those issues have since been cleared up. I’m sure the BBC has learned from the past. I’m sure they wouldn’t think of mindlessly throwing away content, when they have such an impressive archive.

And yet, when it comes to the web, the BBC is employing a slash-and-burn policy regarding online content. 172 websites are going to disappear down the memory hole.

Just to be clear, these sites aren’t going to be archived. They are going to be deleted from the web. Server space is the new magnetic tape.

This callous attitude appears to be based entirely on the fact that these sites occupy URLs in top-level directories—repeatedly referred to incorrectly as top level domains on the BBC internet blog—a space that the decision-makers at the BBC are obsessed with.

Instead of moving the sites to, say, bbc.co.uk/archive and employing a little bit of .htaccess redirection, the BBC (and their technology partner, Siemens) would rather just delete the lot.

Martin Belam is suitably flabbergasted by the vandalism of the BBC’s online history:

I’m really not sure who benefits from deleting the Politics 97 site from the BBC’s servers in 2011. It seems astonishing that for all the BBC’s resources, it may well be my blog posts from 5 years ago that provide a more accurate picture of the BBC’s early internet days than the Corporation does itself - and that it will have done so by choice.

Many of the 172 sites scheduled for deletion are currently labelled with a banner across the top indicating that the site hasn’t been updated for a while. There’s a link to a help page with the following questions and answers:

• Why don’t you just delete these pages when the programme has ended?

  Our view is that these pages often contain a lot of information about the programme or event which may be of interest in the future. We don’t want to delete pages which users may have bookmarked or linked to in other ways.

• When do you delete pages from bbc.co.uk?

  In general our policy is only to remove pages where the information provided has become so outdated that it may lead to actual harm or damage.

It’ll be interesting to see how those answers will be updated to reflect change in policy. Presumably, the new answers will read something along the lines of “Fuck ‘em.”

• The website commemorating the 200th anniversary of the abolition of the slave act,
• The website for the summer of British film,
• The website chronicling composers of the year,
• The website documenting wildlife explorers on location,
• The website of last year’s Electric Dreams, a programme all about the changes in technology over time…

Kiss them all goodbye. And perhaps most egregious of all, you can also kiss goodbye to WW2 People’s War:

The BBC asked the public to contribute their memories of World War Two to a website between June 2003 and January 2006. This archive of 47,000 stories and 15,000 images is the result.

I’m very saddened to see the BBC join the ranks of online services that don’t give a damn for posterity. That attitude might be understandable, if not forgivable, from a corporation like Yahoo or AOL, driven by short-term profits for shareholders, as summarised by Connor O’Brien in his superb piece on link rot:

We push our lives into the internet, expecting the web to function as a permanent and ever-expanding collective memory, only to discover the web exists only as a series of present moments, every one erasing the last. If your only photo album is Facebook, ask yourself: since when did a gratis web service ever demonstrate giving a flying fuck about holding onto the past?

I was naive enough to think that the BBC was above that kind of short-sighted approach. Looks like I was wrong.

Sad face.