Archive: April, 2015

Charlotte and I came up with a fun exercise today to help a client’s dev team to think of patterns at the granular level—something that had been proving difficult to get across.

We print out page designs, hand them some scissors, and get them to cut up the pages into their smallest components. Mix them all up so you can’t even tell which components came from which pages.

Then—after grouping duplicate patterns together—everyone takes a component and codes it up in HTML and CSS. As soon as you’re finished with one pattern, grab another.

Rinse and repeat.

I ate well today. We celebrated Boxman’s birthday with lunch at the Yeoman, a most excellent purveyor of pub food.

Then this evening, Jessica and I went on a double date with Richard and Wendy to the magnificent 64 Degrees. It was a special evening of English food and English wines, in collaboration with local wine guru Henry Butler.

The food was wonderful: oysters, tuna with apples, whelk croquettes, turbot sashimi with fermented butternut squash, asparagus, sea trout cooked like we were in yakitori alley, and thin slices of beetroot with yoghurt for dessert. All accompanied by fine English wines.

It started when Jessica relayed something that happened when she was on a cultural walking tour of Sofia two weekends ago. The tour guide asked “Does anyone know who invented the computer?”

Alan Turing? Charles Babbage?

The tour guided pointed to a statue and said, “John Atanasoff.”

I had never heard of him. So of course I looked him up. That led me down the most incredible rabbit hole as I uncovered a courtroom drama filled with invalidated patents and mountains of court records.

Why had I never heard about this? It was eclipsed by a bigger legal drama: Watergate.

I get home from a day in London, working on-site with a client. I’ve spent the day trying to crack a tricky responsive navigation issue, still hammering away at it on the train back to Brighton.

Once I’m home I crack open a beer—an Arundel pale ale. Jessica is making a fantastic meal of basque chicken (while simultaneously making some chicken stock). We sit down to eat this wonderful dish accompanied by a green salad and a bottle of Rhone wine.

I’m happy.

While we’re tucking in, we listen to an episode of Melvyn Bragg’s In Our Time all about cryptography.

Happiness turns to bliss.

It’s less than two months now until Responsive Day Out 3: The Final Breakpoint. Fortunately there are still some tickets available so if you haven’t got yours yet, it’s not too late. Remember: it’s cheap as chips—just £80+VAT for a day jam-packed with knowledge bombs from twelve(!) fantastic speakers. You’d be crazy to miss it.

If you’ve already got your ticket, you might be wondering what awaits you. Well, if you’ve been to either of the previous days out, you’ll know what to expect: a medley of topics covering all areas of responsive design, from process and workflow through to visual design and code.

The day will be broken up into four segments. Each segment will feature three thematically-related 20 minute talks, back to back. Then those three speakers will join me for a joint chat, where we can take questions from the audience. Check out the videos from the first Responsive Day Out to get feel for the pace or have a listen to the podcast recordings from previous years.

Here’s my rough plan for the four segments this year…

1. The day will start with some big picture thinking around workflows. There’ll be an emphasis on accessibility—something that can’t just be tagged on to the end of a project. There’s also be a case study of one of the hottest topics in the web designers’ workflow today; style guides and pattern libraries. And importantly, we want to make sure that the role of creativity isn’t forgotten in our new responsive world.
2. The second segment will be like a mini conference on front-end technologies. There’ll be some deep diving into the latest in CSS techniques, including flexbox, as well as that thorny topic of responsive images. It’s hard to believe, but that’s a topic that hasn’t been covered in previous Responsive Days Out. Time to change that.
3. After lunch, we’ll start to look beyond today and to the future of responsive design. That’ll begin with a segment on cutting-edge browser technologies. You can expect to be wowed with demos of the latest browser APIs and get your head around the much-hyped world of web components. We won’t shy away from asking how the web can compete with native experiences, like making our sites work offline.
4. Finally, we’ll end the day—and indeed, the conference series—by taking a high level view of what the future might bring. There’ll be an examination of the skill sets that designers and developers should equip themselves with, and we’ll look beyond the screen to a future of new inputs and outputs.

So the day will have a bell-curved shape to it, starting out with a relatively high-level view, swooping down in the middle to get really stuck in with the technologies of today, before ascending at the end to look into the future.

Friday, June 19th—put that date in your diary. Registration is from 9-10am. There’ll be an hour and a half for lunch (and Street Diner will be on that day!) and everything will wrap up by 5:30pm. It’s going to be an action-packed day—bam! bam! bam!

If you don’t come along to the final Responsive Day Out, you’re going to regret it. So what are you waiting for?

I went spelunking down the caves of the web’s history today. I went digging through the original proposal that Tim Berners-Lee presented to his boss, the late Mike Sendall. I explored the design issues that were raised in the creation the World Wide Web. I rifled through the initial vocabulary of HTML. I watched a video from the web’s twentieth anniversary featuring Tim Berners-Lee, Robert Cailliau, and Jean-François Groff.

I was able to do all this because my computer was connected to the internet and I was running a piece of software that understood HTTP, URLs, and HTML’s A element.

Contrary to popular belief, web standards aren’t created by a shadowy cabal and then handed down to browser makers to implement. Quite the opposite. Browser makers come together in standards bodies and try to come to an agreement about how to collectively create and implement standards. That keeps them very busy. They don’t tend to get out very often, but when they do, the browser/standards makers have one message for developers: “We want to make your life better, so tell us what you want and that’s what we’ll work on!”

In practice, this turns out not to be the case.

Case in point: responsive images. For years, this was the number one feature that developers were crying out for. And yet, the standards bodies—and, therefore, browser makers—dragged their heels. First they denied that it was even a problem worth solving. Then they said it was simply too hard. Eventually, thanks to the herculean efforts of the Responsive Images Community Group, the browser makers finally began to work on what developers had been begging for.

Now that same community group is representing the majority of developers once again. Element queries—or container queries—have been top of the wish list of working devs for quite a while now. The response from browser makers is the same as it was for responsive images. They say it’s simply too hard.

Here’s a third example: web components. There are many moving parts to web components, but one of the most exciting to developers who care about accessibility and backwards-compatibility is the idea of extending existing elements:

It’s my opinion that, for as long as there is a dependence on JS for custom elements, we should extend existing elements when writing custom elements. It makes sense for developers, because new elements have access to properties and methods that have been defined and tested for many years; and it makes sense for users, as they have fallback in case of JS failure, and baked-in accessibility fundamentals.

So instead of having to create a whole new element from scratch like this:

<taco-button>Click me!</taco-button>

…you could piggy-back on an existing element like this:

<button is="taco-button">Click me!</button>

That way, you get the best of both worlds: the native semantics of button topped with all the enhancements you want to add with your taco-button custom element. Brilliant! Github is using this to extend the time element, for example.

I’m not wedded to the is syntax, but I do think it’s vital that there is some declarative mechanism to extend existing elements instead of creating every custom element from scratch each time.

Now it looks like that’s the bit of web components that isn’t going to make the cut. Why? Because browser makers say it’s simply too hard.

As Bruce points out, this is in direct conflict with the design principles that are supposed to be driving the creation and implementation of web standards.

It probably wouldn’t bother me so much except that browser makers still trot out the party line, “We want to hear what developers want!” Their actions demonstrate that this claim is somewhat hollow.

I don’t hold out much hope that we’ll get the ability to extend existing elements for web components. I think we can still find ways to piggy-back on existing semantics, but it’s going to take more work:

<taco-button><button>Click me!</button></taco-button>

That isn’t very elegant and I can foresee a lot of trickiness trying to sift the fallback content (the button tags) from the actual content (the “Click me!” text).

But I guess that’s what we’ll be stuck with. The alternative is simply too hard.

It was a busy week with lots of commuting up and down to London, so I’ve been looking forward to a weekend of unwinding.

Jessica and I like to spend our Saturday afternoons doing our shopping for the weekend, planning out some nice leisurely meals. Today we went down to the Open Market, a recently-renovated collection of stalls under one roof selling local produce and goods. The market is also home to an excellent Greek café, where we had lunch.

I guess it’s part of the gentrification of the London Road area. If this is gentrification, bring it on.

Charlotte came up with a nifty trick that combines two different techniques she’s been working with.

The first building block is the pattern of using checkboxes, labels, and the :checked pseudo-class to create progressive disclosure toggles without JavaScript. There’s just one caveat with that technique though—the item being toggled must appear after the trigger label in the source order of the markup.

Enter the second building block: flexbox. With flexbox, we’re no longer at the mercy of the source order in our markup. By using flex-direction: column-reverse, the progressive disclosure trigger can be displayed after the item being toggled.

I’m working on a project with a team of developers who are trying out the BEM syntax for their class names. I’ve tried BEM before, but I’m not a huge fan of underscores (for no particularly good reason) so I tend to use a modified version that avoids those characters. Still, when it comes to coding style—tabs vs. spaces, camelCasing, underscores, hyphens, or whatever—my personal opinion takes a back seat to the group consensus. And on this project, the group has opted for proper BEM all the way, and I’m more than happy to go along with that.

When it comes to naming a modified version of a component in BEM, the syntax looks like this:

component--modifier

That raises a question about how you then deploy that class name in your HTML. You could just use the modified name:

<element class="component--modifier">

But then in your CSS you’d have to repeat all the style rules for .component selector inside your rule block for .component--modifier selector. SASS could you help out here, especially with its “extends” functionality, but the final CSS is still going to containing duplicated rules.

The alternative is to keep your CSS lean and modular, and write your HTML like this:

<element class="component component--modifier">

Now you’ve taken the duplication out of CSS and put into your markup. It looks a little weird. But, on balance, it’s probably the lesser of two evils.

It strikes me that this pattern of always having the base component class name appear anywhere you have a component--modifier class name is something that you could programmatically check for. It should be relatively straightforward to write a lint tool that looks in the value of every class attribute and, if it finds any instances of foo--bar, checks to make sure that foo is also in there.

Sounds like it could be a nice little task for Grunt or Gulp. Maybe somebody has already made it.

Mind you, it seems that most lint tools out there are focused very much on enforcing a coding style for CSS and JavaScript—not so much for HTML. I worry that this reflects the mindset of many front-end developers who view CSS and JavaScript as more important than markup …which is a bit odd considering that CSS and JavaScript are subservient to the HTML document that they’re styling and scripting.

We have a regular gathering at Clearleft every Thursday at 4pm. It’s our front-end pow-wow (there’s a corresponding “UX Laundromat” on Thursdays at 3pm, and every Friday at 4pm there’s a “Design …Thing”).

It’s basically like a design crit, but for code. People show what they’ve been working, whether it’s client work or personal projects. It leads to some great cross-pollination of ideas and solutions.

I wrap it up by going through links I’ve tagged with “frontend”.

Everyone’s welcome to come along, whether they’re a front-end developer or not. If any clients are in the office, they’re invited along too.

Spring is well and truly springing. The days are getting nice and long. The sky is often clear and blue. The temperature occasionally reaches levels conducive to T-shirt and shorts.

These are good days to be enjoyed by the sea in Brighton. Lately though, I’ve been spending quite a few of these days travelling to and from London on client work. But even then, trapped in a train travelling the vertical line of the compass, the view on the countryside outside can look downright glorious—luminously green fields filled with signs of newborn animal lives illuminated by the springtime sun.

The circle is now complete. The line-up for the third and final Responsive Day Out is all set.

I’ve been scheming behind the scenes to get one of my favourite speakers added to the roster, and now my dastardly scheme has paid off. I am absolutely thrilled to announce that Lyza Danger Gardner will be speaking at Responsive Day Out 3: The Final Breakpoint.

That means we’ve got a double-whammy from the trailblazers at Cloud Four with both Jason and Lyza speaking. With Jason diving deep into responsive images, that leaves Lyza free to zoom out and look at some of the big-picture implications of the work we do on the web.

To say that I’m excited to hear what she has to say would be an exercise in understatement. I am ridiculously excited about the whole day—seriously, in my emails to the speakers, I find myself using far more exclamation points than is healthy. Why, I might even have included an emoticon or two; that’s how psyched I am.

If you’ve already got your ticket for a Responsive Day Out, well done you. If you haven’t, what are you waiting for? Tickets are just £80+VAT—a bargain!

Get your ticket now and I’ll see in Brighton on June 19th for a most excellent day of design, development, UX, performance, process, and everything else responsive-related.

Andy Parker kindly deposited a couple of books on my desk recently. One was The Martian. I had already read that one, thanks to Tim Kadlec’s recommendation. The other was the much-hyped Ready Player One.

I read it while I was travelling to and from Bulgaria. It was the ideal travel companion—an airport novel for geeks. It’s not exactly the finest prose ever written, but it’s thoroughly enjoyable popcorn entertainment. It reads like fan fiction and I mean that in a good way. It’s like Scott Pilgrim crossed with Snowcrash. It certainly passed the time on some airplane rides.

It’s Monday. This Monday was an inverse of Friday.

Now I know that many people consider Mondays to be the inverse of Fridays in general—you know, the mood, the spirit of the day. But this particular Monday was literally the inverse of the previous Friday. On Friday I travelled from Brighton to Bulgaria. Today was the reverse. I began the day in a hotel room in Sofia and ended it safely ensconced back home in Brighton.

Car; plane; plane; car.

Once again there was a layover in Frankfurt—just enough time to enjoy some currywurst and pommes between flights.

The Thracians were one of the first peoples to settle in Bulgaria.

The Romans arrived in the first century.

Four centuries later, Bulgaria became part of the Byzantine empire.

From the fourteenth century onward, the country was part of the Ottoman empire.

That lasted until the end of the nineteenth century, when the country was liberated by Russia.

At this point for some reason, the Bulgarians thought they ought to have a monarchy.

That whole monarchy thing only lasted until the end of the second world war. Then they gave communism a whirl.

Finally they got with the democracy programme.

If it’s Saturday, it must be Sofia.

This morning I arrived at the conference venue and made my way to the stage. I plugged my laptop in at the podium and started doing the tech check mambo.

Once the right adaptor had been located, the screen was displaying in the right aspect ratio, my presenter notes were visible on my machine, and the clicker was working okay, I was almost ready to begin. I strapped the madonna mic onto my head (always uncomfortable for my large cranial girth), affixed the controller to my pocket, un-muted it, and started to speak.

Today was a travel day. It began in Brighton and ended in Bulgaria.

Jessica and I were up early to make the trip to Heathrow. From there we took a flight to Frankfurt, where we killed time waiting for our next flight. Despite having a three hour layover, we still ended up rushing to the gate—I blame the lack of signage and wayfinding in the airport.

From Frankfurt we flew to Sofia. With each leg of our journey, we set our clocks forward. Now we are two timezones away from where we started the day.

Tomorrow: Bulgaria Web Summit.

I often get asked what resources I’d recommend for someone totally new to making websites. There are surprisingly few tutorials out there aimed at the complete beginner. There’s Jon Duckett’s excellent—and beautiful—book. There’s the Codebar curriculum (which I keep meaning to edit and update; it’s all on Github).

Now there’s a new resource by Damian Wielgosik called How to Code in HTML5 and CSS3. Personally, I would drop the “5” and the “3”, but that’s a minor quibble; this is a great book. It manages to introduce concepts in a logical, understandable way.

And it’s free.

Summer burst into life today. The sun shone out of a clear bright blue sky, warming up the ground and the air below.

This weather suits Brighton. The town was positively preening. Admittedly the town centre was pretty much like any other town centre on a hot day, but if you went down to the seafront you’d have seen a beautiful sight. The water was so calm and placid, its surface broken only by the occasional paddle board or kayak.

Today was the perfect day to get a sandwich, hunker down on the beach’s pebbles and fight off feral seagulls.

Cennydd points to an article by Ev Williams about the pendulum swing between open and closed technology stacks, and how that pendulum doesn’t always swing back towards openness. Cennydd writes:

We often hear the idea that “open platforms always win in the end”. I’d like that: the implicit values of the web speak to my own. But I don’t see clear evidence of this inevitable supremacy, only beliefs and proclamations.

It’s true. I catch myself saying things like “I believe the open web will win out.” Statements like that worry my inner empiricist. Faith-based outlooks scare me, and rightly so. I like being able to back up my claims with data.

Only time will tell what data emerges about the eventual fate of the web, open or closed. But we can look to previous technologies and draw comparisons. That’s exactly what Tim Wu did in his book The Master Switch and Jonathan Zittrain did in The Future Of The Internet—And How To Stop It. Both make for uncomfortable reading because they challenge my belief. Wu points to radio and television as examples of systems that began as egalitarian decentralised tools that became locked down over time in ever-constricting cycles. Cennydd adds:

I’d argue this becomes something of a one-way valve: once systems become closed, profit potential tends to grow, and profit is a heavy entropy to reverse.

Of course there is always the possibility that this time is different. It may well be that fundamental architectural decisions in the design of the internet and the workings of the web mean that this particular technology has an inherent bias towards openness. There is some data to support this (and it’s an appealing thought), but again; only time will tell. For now it’s just one more supposition.

The real question—when confronted with uncomfortable ideas that challenge what you’d like to believe is true—is what do you do about it? Do you look for evidence to support your beliefs or do you discard your beliefs entirely? That second option looks like the most logical course of action, and it’s certainly one that I would endorse if there were proven facts to be acknowledged (like gravity, evolution, or vaccination). But I worry about mistaking an argument that is still being discussed for an argument that has already been decided.

When I wrote about the dangers of apparently self-evident truisms, I said:

These statements aren’t true. But they are repeated so often, as if they were truisms, that we run the risk of believing them and thus, fulfilling their promise.

That’s my fear. Only time will tell whether the closed or open forces will win the battle for the soul of the internet. But if we believe that centralised, proprietary, capitalistic forces are inherently unstoppable, then our belief will help make them so.

I hope that openness will prevail. Hope sounds like such a wishy-washy word, like “faith” or “belief”, but it carries with it a seed of resistance. Hope, faith, and belief all carry connotations of optimism, but where faith and belief sound passive, even downright complacent, hope carries the promise of action.

Margaret Atwood was asked about the futility of having hope in the face of climate change. She responded:

If we abandon hope, we’re cooked. If we rely on nothing but hope, we’re cooked. So I would say judicious hope is necessary.

Judicious hope. I like that. It feels like a good phrase to balance empiricism with optimism; data with faith.

The alternative is to give up. And if we give up too soon, we bring into being the very endgame we feared.

Cennydd finishes:

Ultimately, I vote for whichever technology most enriches humanity. If that’s the web, great. A closed OS? Sure, so long as it’s a fair value exchange, genuinely beneficial to company and user alike.

This is where we differ. Today’s fair value exchange is tomorrow’s monopoly, just as today’s revolutionary is tomorrow’s tyrant. I will fight against that future.

To side with whatever’s best for the end user sounds like an eminently sensible metric to judge a technology. But I’ve written before about where that mindset can lead us. I can easily imagine Asimov’s three laws of robotics rewritten to reflect the ethos of user-centred design, especially that first and most important principle:

A robot may not injure a human being or, through inaction, allow a human being to come to harm.

…rephrased as:

A product or interface may not injure a user or, through inaction, allow a user to come to harm.

Whether the technology driving the system behind that interface is open or closed doesn’t come into it. What matters is the interaction.

But in his later years Asimov revealed the zeroeth law, overriding even the first:

A robot may not harm humanity, or, by inaction, allow humanity to come to harm.

It may sound grandiose to apply this thinking to the trivial interfaces we’re building with today’s technologies, but I think it’s important to keep drilling down and asking uncomfortable questions (even if they challenge our beliefs).

That’s why I think openness matters. It isn’t enough to use whatever technology works right now to deliver the best user experience. If that short-time gain comes with a long-term price tag for our society, it’s not worth it.

I would much rather an imperfect open system to a perfect proprietary one.

I have hope in an open web …judicious hope.

Twenty minutes after SpaceX mission CRS-6 launched from Florida’s space coast, it passed over England.

Jessica and I were outside, hoping to catch a glimpse of it.

“There it is!” I cried, pointing at a bright fast moving light. In moments, we saw another bright dot, then another and another—the jettisoned solar panel covers travelling along the same trajectory.

Looking up from the surface of my home planet at this new orbital traveller, I was reminded of grainy black and white footage of crowds waving flags at the launch of ocean liners at the turn of the last century.

I spent the day in London. As my train arrived back in Brighton, it was enveloped in a chilly fog. The whole town was bedecked in an eerie seaside mist—not an uncommon Brighton phenomenon.

Fortunately the fog cleared by the time the ISS made its way across the sky this evening. It was a beautiful sight.

I was hoping to also look for a Dragon capsule on its resupply mission shortly afterwards. Alas, the launch was scrubbed. I got lucky with the weather; SpaceX, not so much.

Perhaps tomorrow will bring better fortune. I’ll be looking to the sky.

Today was a nice quiet Sunday. I did my usual weekly tasks—doing database exports and backing my hard drive. I played some tunes on my bouzouki. I probably should’ve played more. I posted over a half dozen links, wrote two other entries in this journal, and just one note. I didn’t post any pictures today, but yesterday almost every one of my eleven notes had a photo.

I was going to finish the day by stepping outside to watch the ISS fly overhead but the clouds have conspired against me. So instead I finish by writing one hundred words.

On Jessica’s recommendation, I read a piece on the Guardian website called The eeriness of the English countryside:

Writers and artists have long been fascinated by the idea of an English eerie – ‘the skull beneath the skin of the countryside’. But for a new generation this has nothing to do with hokey supernaturalism – it’s a cultural and political response to contemporary crises and fears

I liked it a lot. One of the reasons I liked it was not just for the text of the writing, but the hypertext of the writing. Throughout the piece there are links off to other articles, books, and blogs. For me, this enriches the piece and it set me off down some rabbit holes of hyperlinks with fascinating follow-ups waiting at the other end.

Back in 2010, Scott Rosenberg wrote a series of three articles over the course of two months called In Defense of Hyperlinks:

1. Nick Carr, hypertext and delinkification,
2. Money changes everything, and
3. In links we trust.

They’re all well worth reading. The whole thing was kicked off with a well-rounded debunking of Nicholas Carr’s claim that hyperlinks harm text. Instead, Rosenberg finds that hyperlinks within a text embiggen the writing …providing they’re done well:

I see links as primarily additive and creative. Even if it took me a little longer to read the text-with-links, even if I had to work a bit harder to get through it, I’d come out the other side with more meat and more juice.

Links, you see, do so much more than just whisk us from one Web page to another. They are not just textual tunnel-hops or narrative chutes-and-ladders. Links, properly used, don’t just pile one “And now this!” upon another. They tell us, “This relates to this, which relates to that.”

The difference between a piece of writing being part of the web and a piece of writing being merely on the web is something I talked about a few years back in a presentation called Paranormal Interactivity at ‘round about the 15 minute mark:

Imagine if you were to take away all the regular text and only left the hyperlinks on Wikipedia, you could still get the gist, right? Every single link there is like a wormhole to another part of this “choose your own adventure” game that we’re playing every day on the web. I love that. I love the way that Wikipedia uses links.

That ability of the humble hyperlink to join concepts together lies at the heart of Tim Berners Lee’s World Wide Web …and Ted Nelson’s Project Xanudu, and Douglas Engelbart’s Dynamic Knowledge Environments, and Vannevar Bush’s idea of the Memex. All of those previous visions of a hyperlinked world were—in many ways—superior to the web. But the web shipped. It shipped with brittle, one-way linking, but it shipped. And now today anyone can create a connection between two ideas by linking to resources that represent those ideas. All you need is an HTML document that contains some A elements with href attributes, and a URL to act as that document’s address.

Like the one you’re accessing now.

Not only can I link to that article on the Guardian’s website, I can also pair it up with other related links, like Warren Ellis’s talk from dConstruct 2014:

Inventing the next twenty years, strategic foresight, fictional futurism and English rural magic: Warren Ellis attempts to convince you that they are all pretty much the same thing, and why it was very important that some people used to stalk around village hedgerows at night wearing iron goggles.

There is definitely the same feeling of “the eeriness of the English countryside” in Warren’s talk. If you haven’t listened to it yet, set aside some time. It is enticing and disquieting in equal measure …like many of the works linked to from the piece on the Guardian.

There’s another link I’d like to make, and it happens to be to another dConstruct speaker.

From that Guardian piece:

Yet state surveillance is no longer testified to in the landscape by giant edifices. Instead it is mostly carried out in by software programs running on computers housed in ordinary-looking government buildings, its sources and effects – like all eerie phenomena – glimpsed but never confronted.

James Bridle has been confronting just that. His recent series The Nor took him on a tour of a parallel, obfuscated English countryside. He returned with three pieces of hypertext:

1. All Cameras Are Police Cameras,
2. Living in the Electromagnetic Spectrum, and
3. Low Latency.

I love being able to do this. I love being able to add strands to this world-wide web of ours. Not only can I say “this idea reminds me of another idea”, but I can point to both ideas. It’s up to you whether you follow those links.

In an article entitled The future of loneliness Olivia Laing writes about the promises and disappointments provided by the internet as a means of sharing and communicating. This isn’t particularly new ground and she readily acknowledges the work of Sherry Turkle in this area. The article is the vanguard of a forthcoming book called The Lonely City. I’m hopeful that the book won’t be just another baseless luddite reactionary moral panic as exemplified by the likes of Andrew Keen and Susan Greenfield.

But there’s one section of the article where Laing stops providing any data (or even anecdotal evidence) and presents a supposition as though it were unquestionably fact:

With this has come the slowly dawning realisation that our digital traces will long outlive us.

Citation needed.

I recently wrote a short list of three things that are not true, but are constantly presented as if they were beyond question:

1. Personal publishing is dead.
2. JavaScript is ubiquitous.
3. Privacy is dead.

But I didn’t include the most pernicious and widespread lie of all:

The internet never forgets.

This truism is so pervasive that it can be presented as a fait accompli, without any data to back it up. If you were to seek out the data to back up the claim, you would find that the opposite is true—the internet is in constant state of forgetting.

Laing writes:

Faced with the knowledge that nothing we say, no matter how trivial or silly, will ever be completely erased, we find it hard to take the risks that togetherness entails.

Really? Suppose I said my trivial and silly thing on Friendfeed. Everything that was ever posted to Friendfeed disappeared three days ago:

You will be able to view your posts, messages, and photos until April 9th. On April 9th, we’ll be shutting down FriendFeed and it will no longer be available.

What if I shared on Posterous? Or Vox (back when that domain name was a social network hosting 6 million URLs)? What about Pownce? Geocities?

These aren’t the exceptions—this is routine. And yet somehow, despite all the evidence to the contrary, we still keep a completely straight face and say “Be careful what you post online; it’ll be there forever!”

The problem here is a mismatch of expectations. We expect everything that we post online, no matter how trivial or silly, to remain forever. When instead it is callously destroyed, our expectation—which was fed by the “knowledge” that the internet never forgets—is turned upside down. That’s where the anger comes from; the mismatch between expected behaviour and the reality of this digital dark age.

Being frightened of an internet that never forgets is like being frightened of zombies or vampires. These things do indeed sound frightening, and there’s something within us that readily responds to them, but they bear no resemblance to reality.

If you want to imagine a truly frightening scenario, imagine an entire world in which people entrust their thoughts, their work, and pictures of their family to online services in the mistaken belief that the internet never forgets. Imagine the devastation when all of those trivial, silly, precious moments are wiped out. For some reason we have a hard time imagining that dystopia even though it has already played out time and time again.

I am far more frightened by an internet that never remembers than I am by an internet that never forgets.

And worst of all, by propagating the myth that the internet never forgets, we are encouraging people to focus in exactly the wrong area. Nobody worries about preserving what they put online. Why should they? They’re constantly being told that it will be there forever. The result is that their history is taken from them:

If we lose the past, we will live in an Orwellian world of the perpetual present, where anybody that controls what’s currently being put out there will be able to say what is true and what is not. This is a dreadful world. We don’t want to live in this world.

As I was making my way homeward through the North Laine last week I noticed that a building around the corner from The Skiff had changed somewhat. I saw kitchen equipment where previously no kitchen equipment had been.

Turns out it’s a new pop-up restaurant called Isaac At. It’s only open on Friday and Saturdays, and you have to book online ahead of time. “Why not?” I thought to myself, and booked a table for myself and Jessica.

We just got back and I’m happy to report that it was most excellent—five courses made from local ingredients, beautifully presented.

For a while there on Twitter yesterday, web people took some time to give props to other web people who have inspired them. #HonoringWebFolk was the hashy sack (or whatever that thing is called that the lawn kids use).

There are so many generous people I could mention: Veen, Zeldman, Champeon, Holzschlag, Çelik, Meyer…

But I want to give special mention to an unsung hero of the web: Dean Edwards, a JavaScript genius who created the mother of all polyfills—before polyfills were even a thing. Take a look through the annotated jQuery to see how large his influence looms.

Steven Johnson has oft waxed lyrical on the benefits of keeping a spark file—the modern equivalent of a nineteenth century commonplace book.

I started keeping a spark file. But I was keeping it the late lamented Editorially so my experiment was cut short. This is far as I got…

The transatlantic telegraph cable :: the space elevator.

The web :: the patent that never was.

The Mechanical Turk as design fiction, influencing Babbage.

These are the ramblings of a madman. But I might be able to use some of this—I need to prepare a new talk for later this year.

There are certain attributes of design—or the design process—that are spoken as if they are unquestionably positive. The adjective “innovative” is one of them. But not all innovation is positive. It is possible to create innovative ways to do harm.

Likewise, the word “seamless” is used as though it were by definition a good thing. But hiding the seams in a system is a way of denying a user’s power and autonomy. The problem is that when something goes wrong—as Murphy’s Law dictates it must—the only recourse left is to turn it off and on again.

A Dao of Web Design by John Allsopp is a document that stands outside of time. It was a perfectly crafted message for its own era, and amazingly it’s even more relevant now, a full fathom fifteen years later.

We once took on the tropes of print design and tried to apply them to the web. I fear that today we run the risk of treating web development no different to other kinds of software development, ignoring the strengths of the web that John highlighted for us. Flexibility, ubiquity, and uncertainty: don’t fight them as bugs; embrace them as features.

An article in Wired highlights a key feature of the new Apple watch—to free us from the tyranny of the smartphone screen.

I’ve never set up email on my phone.

If I install an app on my phone, the first thing I do is switch off all notifications. That saves battery life and sanity.

The only time my phone is allowed to ask for my attention is for phone calls, SMS, or FaceTime (all rare occurrences). I initiate every other interaction—Twitter, Instagram, Foursquare, the web. My phone is a tool that I control, not the other way around.

I had a very early start yesterday. It was Anna and Cennydd’s big (and yet little) day. I needed to get to the registry office in Walthamstow by 10am which meant leaving Brighton before dawn. In my befuddled state, I forgot my phone.

I realised when I was in the taxi to the station. I readily admit that for a brief moment, I thought about asking the taxi driver to turn around so I could retrieve my camera, address book, city map, music collection, and web browser.

But I didn’t. And it was fine. I had a book to read.

I don’t sign NDAs. I’m not good with secrets. But I’ve been keeping a secret for a while now. It was difficult. But now the secret is out.

Earlier today Anna and Cennydd got married (that whole “housewarming party” thing was a clever cover story). It was a small but lovely civil ceremony first thing in the morning, followed by a pub lunch, and then a party at their house …a sort of “housewarming” if you will.

So if you’re keeping track, that’s been two weddings in two days …of two different former Clearleft interns. Just like unfeasibly specific buses.

We had a houseguest yesterday evening—Emil was back in Brighton. Emil was the first ever intern at Clearleft. He’s back in the country for Cennydd and Anna’s housewarming party tomorrow. Anna was also an intern at Clearleft; that’s where Anna and Cennydd first met.

Jon was also an intern at Clearleft. He enjoyed the experience so much that he ended up moving to Brighton. Good thing too: this is where he met Hannah, the love of his life. Today, Hannah and Jon got married. It was all rather lovely.

And now they’re off to San Sebastian on their honeymoon.

The time had come for Jeremy to leave Brighton. He was being called away to the far shores of the Pacific Northwest. What would have once been a sea voyage and overland trek lasting for weeks and months took him just nine hours in the belly of a flying machine. Having made landfall in Seattle he then had to stand in front of a room full of his peers at An Event Apart and speak to them about progressive enhancement. Jeremy tries to remain humble but as he stepped off that stage, two words went through his mind: “Nailed. It!”

• Nobody writes on their own website any more. People write on Twitter, Facebook, and Medium instead. Personal publishing is dead.
• You can’t build a complex interactive app on the web without requiring JavaScript. It’s fine if it doesn’t work without JavaScript. JavaScript is ubiquitous.
• Privacy is dead. The technologies exists to monitor your every movement and track all your communications so it is inevitable that our society will bend to this reality.

These statements aren’t true. But they are repeated so often, as if they were truisms, that we run the risk of believing them and thus, fulfilling their promise.