Tags: graph



Variable fonts

We have a tradition here at Clearleft of having the occasional lunchtime braindump. They’re somewhat sporadic, but it’s always a good day when there’s a “brown bag” gathering.

When Google’s AMP format came out and I had done some investigating, I led a brown bag playback on that. Recently Mark did one on Fractal so that everyone knew how work on that was progressing.

Today Richard gave us a quick brown bag talk on variable web fonts. He talked us through how these will work on the web and in operating systems. We got a good explanation of how these fonts would get designed—the type designer designs the “extreme” edges of size, weight, or whatever, and then the file format itself can extrapolate all the in-between stages. So, in theory, one single font file can hold hundreds, thousands, or hundreds of thousands of potential variations. It feels like switching from bitmap images to SVG—there’s suddenly much greater flexibility.

A variable font is a single font file that behaves like multiple fonts.

There were a couple of interesting tidbits that Rich pointed out…

While this is a new file format, there isn’t going to be a new file extension. These will be .ttf files, and so by extension, they can be .woff and .woff2 files too.

This isn’t some proposed theoretical standard: an unprecedented amount of co-operation has gone into the creation of this format. Adobe, Apple, Google, and Microsoft have all contributed. Agreement is the hardest part of any standards process. Once that’s taken care of, the technical solution follows quickly. So you can expect this to land very quickly and widely.

This technology is landing in web browsers before it lands in operating systems. It’s already available in the Safari Technology Preview. That means that for a while, the very best on-screen typography will be delivered not in eBook readers, but in web browsers. So if you want to deliver the absolute best reading experience, look to the web.

And here’s the part that I found fascinating…

We can currently use numbers for the font-weight property in CSS. Those number values increment in hundreds: 100, 200, 300, etc. Now with variable fonts, we can start using integers: 321, 417, 183, etc. How fortuitous that we have 99 free slots between our current set of values!

Well, that’s no accident. The reason why the numbers were originally specced in increments of 100 back in 1996 was precisely so that some future sci-fi technology could make use of the ranges in between. That’s some future-friendly thinking! And as Håkon wrote:

One of the reasons we chose to use three-digit numbers was to support intermediate values in the future. And the future is now :)

Needless to say, variable fonts will be covered in Richard’s forthcoming book.

The typography of a web book

I’m a sucker for classic old-style serif typefaces: Caslon, Baskerville, Bembo, Garamond …I love ‘em. That’s probably why I’ve always found the typesetting in Edward Tufte’s books so appealing—he always uses a combination of Bembo for body copy and Gill Sans for headings.

Earlier this year I stumbled on a screen version of Bembo used for Tufte’s digital releases called ET Book. Best of all, it’s open source:

ET Book is a Bembo-like font for the computer designed by Dmitry Krasny, Bonnie Scranton, and Edward Tufte. It is free and open-source.

When I was styling Resilient Web Design, I knew that the choice of typeface would be one of the most important decisions I would make. Remembering that open source ET Book font, I plugged it in to see how it looked. I liked what I saw. I found it particularly appealing when it’s full black on full white at a nice big size (with lower contrast or sizes, it starts to get a bit fuzzy).

I love, love, love the old-style numerals of ET Book. But I was disappointed to see that ligatures didn’t seem to be coming through (even when I had enabled them in CSS). I mentioned this to Rich and of course he couldn’t resist doing a bit of typographic sleuthing. It turns out that the ligature glyphs are there in the source files but the files needed a little tweaking to enable them. Because the files are open source, Rich was able to tweak away to his heart’s content. I then took the tweaked open type files and ran them through Font Squirrel to generate WOFF and WOFF2 files. I’ve put them on Github.

For this book, I decided that the measure would be the priority. I settled on a measure of around 55 to 60 characters—about 10 or 11 words per line. I used a max-width of 27em combined with Mike’s brilliant fluid type technique to maintain a consistent measure.

It looks great on small-screen devices and tablets. On large screens, the font size starts to get really, really big. Personally, I like that. Lots of other people like it too. But some people really don’t like it. I should probably add a font-resizing widget for those who find the font size too shocking on luxuriously large screens. In the meantime, their only recourse is to fork the CSS to make their own version of the book with more familiar font sizes.

The visceral reaction a few people have expressed to the font size reminds me of the flak Jeffrey received when he redesigned his personal site a few years back:

Many people who’ve visited this site since the redesign have commented on the big type. It’s hard to miss. After all, words are practically the only feature I haven’t removed. Some of the people say they love it. Others are undecided. Many are still processing. A few say they hate it and suggest I’ve lost my mind.

I wonder how the people who complained then are feeling now, a few years on, in a world with Medium in it? Jeffrey’s redesign doesn’t look so extreme any more.

Resilient Web Design will be on the web for a very, very, very long time. I’m curious to see if its type size will still look shockingly large in years to come.

Hamburger, hamburger, hamburger

Andy’s been playing Devils Advocate again, defending the much-maligned hamburger button. Weirdly though, I think I’ve seen more blog posts, tweets, and presentations defending this supposed underdog than I’ve seen knocking it.

Take this presentation from Smashing Conference. It begins with a stirring call to arms. Designers of the web—cast off your old ways, dismiss your clichés, try new things, and discard lazy solutions! “Yes!”, I thought to myself, “this is a fantastic message.” But then the second half of the talk switches into a defence of the laziest, most clichéd, least thought-through old tropes of interface designs: carousels, parallax scrolling and inevitably, the hamburger icon.

But let’s not get into a binary argument of “good” vs. “bad” when it comes to using the hamburger icon. I think the question is more subtle than that. There are three issues that need to be addressed if we’re going to evaluate the effectiveness of using the hamburger icon:

  1. representation,
  2. usage, and
  3. clarity.


An icon is a gateway to either some content or a specific action. The icon should provide a clear representation of the content or action that it leads to. Sometimes “clear” doesn’t have to literally mean that it’s representative: we use icons all the time that don’t actually represent the associated content or action (a 3.5 inch diskette for “save”, a house for the home page of a website, etc.). Cultural factors play a large part here. Unless the icon is a very literal pictorial representation, it’s unlikely that any icon can be considered truly universal.

If a hamburger icon is used as the gateway to a list of items, then it’s fairly representative. It’s a bit more abstract than an actual list of menu items stacked one on top of the other, but if you squint just right, you can see how “three stacked horizontal lines” could represent “a number of stacked menu items.”

If, on the other hand, a hamburger icon is used as the gateway to, say, a grid of options, then it isn’t representative at all. A miniaturised grid—looking like a window—would be a more representative option.

So in trying to answer the question “Does the hamburger icon succeed at being representative?”, the answer—as ever—is “it depends.” If it’s used as a scaled-down version of the thing its representing, it works. If it’s used as a catch-all icon to represent “a bunch of stuff” (as is all too common these days), then it works less well.

Which brings us to…


Much of the criticism of the hamburger icon isn’t actually about the icon itself, it’s about how it’s used. Too many designers are using it as an opportunity to de-clutter their interface by putting everything behind the icon. This succeeds in de-cluttering the interface in the same way that a child putting all their messy crap in the cupboard succeeds in cleaning their room.

It’s a tricky situation though. On small screens especially, there just isn’t room to display all possible actions. But the solution is not to display none instead. The solution is to prioritise. Which actions need to be visible? Which actions can afford to be squirrelled away behind an icon? A designer is supposed to answer those questions (using research, testing, good taste, experience, or whatever other tools are at their disposal).

All too often, the hamburger icon is used as an excuse to shirk that work. It’s treated as a “get out of jail free” card for designing small-screen interfaces.

To be clear: this usage—or misusage—has nothing to do with the actual icon itself. The fact that the icon is three stacked lines is fairly irrelevant on this point. The reason why the three stacked lines are so often used is that there’s a belief that this icon will be commonly understood.

That brings us to last and most important point:


By far the most important factor in whether an icon—any icon—will be understood is whether or not it is labelled. A hamburger icon labelled with a word like “menu” or “more” or “options” is going to be far more effective than an unlabelled icon.

Don’t believe me? Good! Do some testing.

In my experience, 80-90% of the benefit of usability testing is in the area of labelling. And one of the lowest hanging fruit is the realisation that “Oh yeah, we should probably label that icon that we assumed would be universally understood.”

Andy mentions the “play” and “pause” symbols as an example of icons that are so well understood that they can stand by themselves. That’s not necessarily true.

I think there are two good rules of thumb when it comes to using icons:

  1. If in doubt, label it.
  2. If not in doubt, you probably should be—test your assumptions.


Now that we’ve established the three criteria for evaluating an icon’s effectiveness, let’s see how the hamburger icon stacks up (if you’ll pardon the pun):

  1. Representation: It depends. Is it representing a stacked list of menu items? If so, good. If not, reconsider.
  2. Usage: it depends. Is it being used as an excuse to throw literally all your navigation behind it? If so, reconsider. Prioritise. Decide what needs to be visible, and what can be tucked away.
  3. Clarity: it depends. Is the icon labelled? If so, good. If not, less good.

So there you go. The answer to the question “Is the hamburger icon good or bad?” is a resounding and clear “It depends.”

Full Meaning Ampersand

In the space of one week, Brighton played host to three excellent conferences:

  1. FF Conf on Friday, November 6th,
  2. Meaning on Thursday, November 12th, and
  3. Ampersand on Friday, November 13th.

I made it to two of the three—alas, I couldn’t make it to Meaning this year because it clashed with Richard’s superb workshop on Responsive Web Typography.

FF Conf and Ampersand were both superb. Despite having very different subject matter, the two events have a lot in common. They’re both affordable, one-day, single-track, focused gatherings.

Both events really benefit from having a mastermind overseeing the line-up: Remy in the case of FF Conf, and Richard in the case of Ampersand. That really paid off. Both events were superbly curated, with a diverse mix of speakers and topics.

It was really interesting to see both conferences break out of the boundary of what happens inside web browsers. At FF Conf, we were treated to talks on linguistics and inclusivity. At Ampersand, we enjoyed talks on physiology and culture. But of course we also had the really deep dives into the minutest details of JavaScript, SVG, typography, and layout.

Videos will be available from FF Conf, and audio will be available from Ampersand. Be sure to check them out once they’re released.

Marcy Sutton FFConf 2015 Playing to be different marks with Marcin

100 words 056

I did not take any photographs today. There was a moment when I thought about it. Standing in the back garden, looking up through the leaves and branches of an overhanging tree, I almost reached for my phone.

The sky was a rich clear cerulean blue. The leaves of the tree were a deep maroon colour. The sunlight shining through the leaves showed a branching system of vein-like lines.

If I had taken a photograph, I probably would’ve pointed the camera lens straight up, filling most of the frame with pure blue, and the purple leaves encroaching into the picture.

100 words 052

There was a Clearleft outing to Bletchley Park today. I can’t believe I hadn’t been before. It was nerdvana—crypto, history, and science combined in one very English location.

Alan Turing’s work at Station X is rightly lauded, but I can’t help feeling a bit uncomfortable with the way we make heroes of those who work in the shadows. After the war, England’s fictional hero was James Bond, the creation of former Bletchley worker Ian Fleming. And now we have GCHQ spying on its own citizens.

Righteousness in the past doesn’t earn a country a free pass for the future.

100 words 043

It wasn’t that long ago I mentioned a new book about learning HTML and CSS from scratch, published online for free. Well, now there’s another one. This time the subject is typography on the web.

It’s called Professional Web Typography by Donny Truong. It’s a fairly quick read but it squeezes in plenty of handy practical advice with chapters on delivering web fonts, selecting body text, setting type in the browser, choosing headings, picking type for UI, seeing typographic details, and practicing typography.

Needless to say, the book is itself very nicely typeset. And you can pay what you want.

Billboards and Novels by Jon Tan

Jon is at An Event Apart in Atlanta to talk about Billboards and Novels. That means: impact vs. immersion.

Who in the audience has ever had to explain layout and design decisions? And who has struggled to do that? Jon has. That’s why he wants to talk about the differences between designing for impact—to grab attention—and immersion—to get out of the way and allow for absorbing involvement.

Jon examines the difference between interruption and disruption. You want to grab attention, but the tone has to be right. This is how good advertising works. So sometimes impact is a good thing, but not if you’re trying to read.

The web is reading.

Understanding how people read is a core skill for anyone designing and developing for the web. First, you must understand language. There’s a great book by Robert Bringhurst called What Is Reading For?, the summation of a symposium. Paraphrasing Eric Gill, he says that words are neither things, nor pictures of things; they are gestures.

Words as gestures …there are #vss (very short stories) on Twitter that manage to create entire backstories in your mind using the gestures of words.

A study has shown that aesthetics does not affect perceived usability, but it does have an effect on post-use perceived aesthetics. Even though a “designed” and “undesigned” thing might work equally well, our memory the the designed thing is more positive.

Good typography and poor typography appear to have no affect on reading comprehension. This was tested with a New Yorker article that was typeset well, and the same article typeset badly. The people who had the nicely typeset article underestimated how long it had taken them to read it. Objectively it had taken just as long as reading the poorly-typeset version, but because it was more pleasing, it put them in a good mood.

Good typography induces a good mood. And if you are in a good mood, you perform tasks better …and you will think that the tasks took less time. Time flies when you’re having fun.

What about type on screens?

  • David Berlow describes the web as “crude media.”
  • Jonathan Hoefler describes how he produces fonts differently for different media: the idea (behind the typeface) gives rise to a variety of forms.
  • Matthew Carter designed Bell Centennial to work at one size in one environment: the crappy paper of the telephone book. He left gaps in the letterforms for the ink to spread into.
  • The Siri typeface was redrawn anew as SiriCore specifically for the screen.

When Jon is evaluating typefaces, he is aware that some fonts are more optimised for the screen than others. He tests the smallest text first, in the most adverse environment: a really old HP machine running Windows XP. He also looks at language support, and features and variants like lining numerals: what are the mechanics of the font?

We take quiet delight in the smallest details of a typeface.

Legibility is so important. Kevin Larson analysed how we read. We take a snapshot of a bunch of letters, and our brains rearrange them into a word. We read by skipping along lines in “saccades” with pauses or “fixations” that allow us to understand a group of letters before reading on.

Jon tells the story of how Seb was fooled by a spoof Twitter account for the London Olympics. The account name was London20l2 (with a letter L), not London2012 (with the letter one). Depending on the typeface, that difference can be very hard to spot. Here’s a handy string:

agh! iIl1 o0

Stick that into Fontdeck and you’ll get a good idea of the mechanics of the font you’re looking at. You’re looking out for ambiguities that would interrupt the reader.

The same goes for typesetting: use the right quotes and apostrophes; not primes. Use ligatures when they help. But some ligatures are just showing off and they interrupt your reading. Typesetting should help reading, not interrupt or disrupt.

You can use text-rendering: optimizeLegibility but test it. You can use hyphens: auto but test it. You can add a non-breaking space before the last two words in a paragraph to prevent orphans. It will improve the mood.

A good example of interruption is the Ampersand 2012 website. There’s a span on the letter that should receive a flourish. But you can also use expert subsets. You can use Opentype features. There are common and discretionary ligatures. Implement them wisely. Use discretionary ligatures when you want to draw attention, like in a headline.

Scantastic readability. We wander around the page or screen in the same way as we read with saccades: our eyes jump around the place. Our scan path is a roughly Z-shaped pattern. You can design for this scan path: deliberately interrupt …but not disrupt. Jon uses the squint test when he is designing, to see what jumps out and interrupts.

Measure (line-length) is really important. Long lines tire us out. Bringhurst mentioned 45-75 character measures. But the measure is also bound to the prose: the content might be very short and snappy.

Contrast can give you careful, deliberate interruptions. Position, density, size …these are all tools we can use to interrupt without disrupting. The I Love Typography article on The Origins of ABC is a beautiful example of this. Compare it to the disruption of faddish parallax sites.

But there are no rules, just good decisions.

It’s all so emotional. Sometimes there are no words. Think of the masterful storytelling of the first twenty minutes of Wall-E.

We react incredibly quickly to faces. We can see and recognise a human face in 40 milliseconds, before we even consciously process that we’ve seen a face.

When we try to write about music, the result can be some really purple prose.

We have an emotional reaction to faces, colour, music …and type.

Jon demonstrates the effect on us that a friendly typeface has compared to a harsh typeface …even though the friendly typeface is used for the Malay word for “hate” and the harsh typeface is used for the Malay word for “love.” Our amygdala is reacting directly. It’s a physiological, visceral reaction we have before we even understand what we’re looking at.

Fonts are wayfinding apps for emotions. There’s a difference between designing places and designing postcards of places.

The Milwaukee Police News website is very impactful …but there’s no immersion. It doesn’t communicate beyond the initial reaction.

Places are defined by type and form: New York, London, Paris. A website for Barcelona or Brooklyn should reflect the flavour of those places.

All these things combine: impact, immersion, contrast, colour, type. We can affect people’s experiences. We can put them in a better mood.

Type shapes our experience. It paints pictures that echo in our memory long after we’ve left.

Eric Spiekermann said:

Details in typefaces are not to be seen, but felt.

Those details have to work in the greater context (of colour, contrast, layout).

Bruce Lee said:

Don’t think; feel.

Long time

A few years back, I was on a road trip in the States with my friend Dan. We drove through Maryland and Virginia to the sites of American Civil War battles—Gettysburg, Antietam. I was reading Tom Standage’s magnificent book The Victorian Internet at the time. When I was done with the book, I passed it on to Dan. He loved it. A few years later, he sent me a gift: a glass telegraph insulator.

Glass telegraph insulator from New York

Last week I received another gift from Dan: a telegraph key.

Telegraph key

It’s lovely. If my knowledge of basic electronics were better, I’d hook it up to an Arduino and tweet with it.

Dan came over to the UK for a visit last month. We had a lovely time wandering around Brighton and London together. At one point, we popped into the National Portrait Gallery. There was one painting he really wanted to see: the portrait of Samuel Pepys.


“Were you reading the online Pepys diary?”, I asked.

“Oh, yes!”, he said.

“I know the guy who did that!”

The “guy who did that” is, of course, the brilliant Phil Gyford.

Phil came down to Brighton and gave a Skillswap talk all about the ten-year long project.

The diary of Samuel Pepys: Telling a complex story online on Huffduffer

Now Phil has restarted the diary. He wrote a really great piece about what it’s like overhauling a site that has been online for a decade. Given that I spent a lot of my time last year overhauling The Session (which has been online in some form or another since the late nineties), I can relate to his perspective on trying to choose long-term technologies:

Looking ahead, how will I feel about this Django backend in ten years’ time? I’ve no idea what the state of the platform will be in a decade.

I was thinking about switching The Session over to Django, but I decided against it in the end. I figured that the pain involved in trying to retrofit an existing site (as opposed to starting a brand new project) would be too much. So the site is still written in the very uncool LAMP stack: Linux, Apache, MySQL, and PHP.

Mind you, Marco Arment makes the point in his Webstock talk that there’s a real value to using tried and tested “boring” technologies.

One area where I’ve found myself becoming increasingly wary over time is the use of third-party APIs. I say that with a heavy heart—back at dConstruct 2006 I was talking all about The Joy of API. But Yahoo, Google, Twitter …they’ve all deprecated or backtracked on their offerings to developers.

Anyway, this is something that has been on my mind a lot lately: evaluating technologies and services in terms of their long-term benefit instead of just their short-term hit. It’s something that we need to think about more as developers, and it’s certainly something that we need to think about more as users.

Compared with genuinely long-term projects like the 10,000 year Clock of the Long Now making something long-lasting on the web shouldn’t be all that challenging. The real challenge is acknowledging that this is even an issue. As Phil puts it:

I don’t know how much individuals and companies habitually think about this. Is it possible to plan for how your online service will work over the next ten years, never mind longer?

As my Long Bet illustrates, I can be somewhat pessimistic about the longevity of our web creations:

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

But I really hope I lose that bet. Maybe I’ll suggest to Matt (my challenger on the bet) that we meet up on February 22nd, 2022 at the Long Now Salon. It doesn’t exist yet. But give it time.

Canvas sparklines

I like sparklines a lot. Tufte describes a sparkline as:

…a small intense, simple, word-sized graphic with typographic resolution.

Four years ago, I added sparklines to Huffduffer using Google’s chart API. That API comes in two flavours: a JavaScript API for client-side creation of graphs, and image charts for server-side rendering of charts as PNGs.

The image API is really useful: there’s no reliance on JavaScript, it works in every browser capable of displaying images, and it’s really flexible and customisable. Therefore it is, of course, being deprecated.

The death warrant for Google image charts sets the execution date for 2015. Time to start looking for an alternative.

I couldn’t find a direct equivalent to the functionality that Google provides i.e. generating the images dynamically on the server. There are, however, plenty of client-side alternatives, many of them using canvas.

Most of the implementations I found were a little heavy-handed for my taste: they either required jQuery or Processing or both. I just wanted a quick little script for generating sparklines from a dataset of numbers. So I wrote my own.

I’ve put my code up on Github as Canvas Sparkline.

Here’s the JavaScript. You create a canvas element with the dimensions you want for the sparkline, then pass the ID of that element (along with your dataset) into the sparkline function:

sparkline ('canvasID', [12, 18, 13, 12, 11, 15, 17, 20, 15, 12, 8, 7, 9, 11], true);

(that final Boolean value at the end just indicates whether you want a red dot at the end of the sparkline).

The script takes care of normalising the values, so it doesn’t matter how many numbers are in the dataset or whether the range of the numbers is in the tens, hundreds, thousands, or hundreds of thousands.

There’s plenty of room for improvement:

  • The colour of the sparkline is hardcoded (50% transparent black) but it could be passed in as a value.
  • All the values should probably be passed in as an array of options rather than individual parameters.

Feel free to fork, adapt, and improve.

The sparklines are working quite nicely, but I can’t help but feel that this isn’t the right tool for the job. Ideally, I’d like to keep using a server-side solution like Google’s image charts. But if I am going to use a client-side solution, I’m not sure that canvas is the right element. This should really be SVG: canvas is great for dynamic images and animations that need to update quite quickly, but sparklines are generally pretty static. If anyone fancies making a lightweight SVG solution for sparklines, that would be lovely.

In the meantime, you can see Canvas Sparkline in action on the member profiles at The Session, like here, here, here, or here.

Update: Ask and thou shalt receive. Check out this fantastic lightweight SVG solution from Stuart—bloody brilliant!

Iconic imagery

There’s been some fantastic collaborative work done recently on the tricky issue of responsive images. Witness the community group and its attendant website, complete with logo.

Meanwhile, there’s been some great research into dealing with high-DPI displays (which the world and its dog have decided to label “retina”). There’s the in-depth analysis by Daan Jobsis which looks at what you can get away with when it comes to compression and quality for “retina” displays: quite a lot, as it turns out.

In fact, you may well be able to double the dimensions of an image while simultaneously bringing down its quality and end up with an image that is smaller in file size than the original, while still looking great on high-DP..“retina” displays. The guys over at Filament group have labelled this Compressive Images. Nice.

I like that approach. No JavaScript polyfills. No lobbying of standards bodies.

I’m generally fan of solutions that look for ways of avoiding the problem in the first place. Hence my approach to image optimisation for all devices, widescreen or narrow.

Of course this whole issue of responsive (or compressive) images should really only apply to photographic imagery. If you’re dealing with “text as images” …don’t. Use web fonts. If you’re dealing with logos or icons, there are other options, like SVG.

Then there’s the combination of web fonts and iconography. Why not use a small web font containing just the icons you need?

I tried this recently, diligently following Josh’s excellent blog post detailing how to get icon shapes out of Fireworks, into a font editor, and then into an actual font. It works a treat, although I concur with Josh’s suggestion that the technique should really only be implemented using the ::before and ::after pseudo-elements in combination with base-64 encoding the font file. That means it won’t work in every single browser, but that’s the point: these icons should be an enhancement, not a requirement.

Having gone through the tortuous steps required to get my Mac all set up with the software required to follow Josh’s tutorial, I then spotted the note at the end of his article that pointed to Icomoon. That turns out to be a fantastic service. You can pick and choose from the icons provided or you can upload your own vector shapes. Then you can assign the unicode slots you want to use for the icons and you can get the resulting font file base-64 encoded. Very, very cool!

There’s a whole slew of icon-font services like that out there now: Pictos, Web Symbols, and Symbolset with its ingenious use of ligatures to allow for an accessible fallback.

Jenn is currently casting a critical eye over each of these service over on the Nerdary: part one, part two, and part three are all deserving of your time and attention.

Restoration mirror

Heather Champ just announced that the Mirror Project is being revived and it has brought back a flood of memories for me. Heather evocatively describes the origins of the Mirror Project from a time “when the web was younger, when home pages were what we made.”

The premise was simple: Take a picture of yourself in some reflective surface. That’s it. It seems so very straightforward in today’s age of ubiquitous photography and instant updates but there was a thoughtfulness that went into every picture posted. Keep hitting the “surprise me” link to see what I mean.

My first Mirror Project shot was taken eleven years ago. I have a few more in there. I used to blog about The Mirror Project every time one of my pictures was posted. I even used to have a little widget on this site to show a random Mirror Project shot.

My upstairs neighbours' flat, Brighton, England

Here’s a shot that Jeffrey took at the start of the millennium. That picture went on to have a life of its own as a book cover. It even spawned a meme.

Ugly Hallway

Back then, I never could’ve imagined in my wildest dreams that I would get to know Jeffrey Zeldman, much less call him my friend. Here I am, eleven years later, writing and speaking about web design with my hero from way back when. Crazy!

Within a year, the Mirror Project reached its 10000th picture (just look at those fresh-faced kids).

Sunday September 15, 4PM.

My last Mirror Project shot was taken at South by Southwest in 2005.

SxSW 2005

My first pictures on Flickr date from the same time—when the worst-kept secret at that South by Southwest was that Flickr was being bought by Yahoo. Online digital photography was changing.

The Mirror Project has been gone for six years. It warms my heart to see it return, its URLs restored, its images reflecting back.


After speaking at Go Beyond Pixels in St. John’s, I had some time to explore Newfoundland a little bit. Geri was kind enough to drive me to a place I really wanted to visit: the cable station at Heart’s Content.

Heart's Content Cable Station

I’ve wanted to visit Heart’s Content (and Porthcurno in Cornwall) ever since reading The Victorian Internet, a magnificent book by Tom Standage that conveys the truly world-changing nature of the telegraph. Heart’s Content plays a pivotal role in the story: the landing site of the transatlantic cable, spooled out by the Brunel-designed Great Eastern, the largest ship in the world at the time.

Recently I was sent an advance reading copy of Tubes by Andrew Blum. It makes a great companion piece to Standage’s book as Blum explores the geography of the internet:

For all the talk of the placelessness of our digital age, the Internet is as fixed in real, physical places as any railroad or telephone system ever was.

There’s an interview with Andrew Blum on PopTech, a review of Tubes on Brain Pickings, and I’ve huffduffed a recent talk by Andrew Blum in Philadelphia.

Andrew Blum | Tubes: A Journey to the Center of the Internet - Free Library Podcast on Huffduffer

Now there are more places I want to visit: the nexus points on TeleGeography’s Submarine Cable Map; the hubs of Hibernia Atlantic, whose about page reads like a viral marketing campaign for some soon-to-be-released near-future Hollywood cyberpunk thriller.

I’ve got the kind of travel bug described by Neal Stephenson in his classic 1996 Wired piece Mother Earth Mother Board:

In which the hacker tourist ventures forth across the wide and wondrous meatspace of three continents, acquainting himself with the customs and dialects of the exotic Manhole Villagers of Thailand, the U-Turn Tunnelers of the Nile Delta, the Cable Nomads of Lan tao Island, the Slack Control Wizards of Chelmsford, the Subterranean Ex-Telegraphers of Cornwall, and other previously unknown and unchronicled folk; also, biographical sketches of the two long-dead Supreme Ninja Hacker Mage Lords of global telecommunications, and other material pertaining to the business and technology of Undersea Fiber-Optic Cables, as well as an account of the laying of the longest wire on Earth, which should not be without interest to the readers of Wired.

Maybe one day I’ll get to visit the places being designed by Sheehan Partners, currently only inhabited by render ghosts on their website (which feels like it’s part of the same subversive viral marketing campaign as the Hibernia Atlantic site).

Perhaps I can find a reason to stop off in Ashburn, Virginia or The Dalles, Oregon, once infamous as the site of a cult-induced piece of lo-tech bioterrorism, now the site of Google’s Project 02. Not that there’s much chance of being allowed in, given Google’s condescending attitude when it comes to what they do with our data: “we know what’s best, don’t you trouble your little head about it.”

It’s that same attitude that lurks behind that most poisonous of bullshit marketing terms…

The cloud.

What a crock of shit.

The cloud is a lie

Whereas other bullshit marketing terms once had a defined meaning that has eroded over time due to repeated use and abuse—Ajax, Web 2.0, HTML5, UX—“the cloud” is a term that sets out to deceive from the outset, imbued with the same Lakoffian toxicity as “downsizing” or “friendly fire.” It is the internet equivalent of miasma theory.

Death to the cloud! Long live the New Flesh of servers, routers, wires and cables.


A few years back, Craig took some lovely pictures of four generations of sushi chefs:

The story goes something like: Jiro trained Shiro who ran off to Seattle, started one of the first sushi joints in the city, and trained Taiichi, who now runs his own sushi shop. Jiro also trained his son, who works at Sukiyabashi Jiro and (one assumes) plans to take over the business once his octogenarian father retires (which, according to Jiro, is when he dies).

I love the additional photos that Craig took of each chef making their nigiri-te (the hand motion they use when forming nigiri).

The undisputed Jedi master of these sushi chefs is Jiro Ono. He’s the subject of the forthcoming documentary Jiro Dreams of Sushi.

One week of Map Tales

It’s been just a week since Clearleft unveiled the Map Tales project that we built at Hackfarm and there have already been some great stories told with the site.

Paul documented his 2009 road trip to South by Southwest.

Alessio put together a photographic guide to his adopted home, showing the secrets of Barcelona.

Andy told two tales of two different trips: wine-tasting in California’s Dry Creek Valley and hanging with the hipsters in East London.

Fellow Brightonian Tom Prior has recreated the story of the famous Stirling Moss victory at the 1955 Mille Miglia, the legendary open-road endurance race in Northern Italy.

I love the simplicity of Oliver and Peter Walk to School that Peter Ruk has embedded on his site—beautifully simple .

I’ve made a map tale of the voyage of The Beagle with material fromAboutDarwin.com.

Meanwhile Anna is putting together the tale of the Terra Nova expedition to the South Pole because—get this—a relative of hers was part of Scott’s team!

There’s plenty of room for improvement with Map Tales. It would be nice to have customisation options at some point—colours, fonts, maybe even map tiles. Some narratives would probably work better with aerial imagery, for example. In fact, that’s something that Andy has been tirelessly tinkering with. To get a taste of how that looks, check out Britain From Above, the epic map tale of the 2008 BBC documentary series.


Remember when I said that the Ampersand conference was going to be great? Yeah, well, I wasn’t wrong. If anything, I underestimated how great it would be.

Tim Brown Vincent listens to Jason John Daggett Mark

Make a venn diagram of web nerds and type nerds; Ampersand was all about the intersection of those two circles. There was something special about having so many domain-specific nerds in one place at one time. It made for a very special atmosphere. It also helped that all the speakers were excellent. I particularly liked the fact that Ethan’s book was pimped in four different talks.

You can read more about the individual talks in an article over at Eye Magazine called Web typography comes of age at Brighton’s Ampersand conference.

All in all, it was an excellent day. The only bittersweet note came from the fact that it marked Sophie’s last day at Clearleft—she’s off to Lanyrd. But Sophie left us on a high note: she and Rich put together one hell of an event.



What with all the overseas travelling I’ve been doing lately, I’m quite looking forward to going to some conferences here in the UK. I’m definitely looking forward to Web Directions @media in London later this month and DIBI in Newcastle next month although there’s something about both events that troubles me: they’re both double-track conferences, splitting the talks into “design” and “development” categories.

Don’t get me wrong—I think the line-ups look great. But that’s just the problem. I know I’m going to have make some very hard choices when two excellent speakers are on at exactly the same time. It’s a guarantee that I’ll have strong feelings of FOMO.

Personally, I’d rather not have to make those decisions. That’s one of the reasons why I really like the single-track format of dConstruct and An Event Apart. I think that the playlist-like curated single-day line-up of events like Build and New Adventures In Web Design really contributes to their special atmosphere.

The single-track single-day format works especially well for tightly-focused conferences like the JavaScriptastic Full Frontal.

If you’re looking for a single-track, single-day conference devoted entirely to typography on the web, then you simply must get along to Ampersand right here in Brighton on June 17th.

Yes, I am biased: we at Clearleft are organising it, but if you’ve been to any of our other events—dConstruct or UX London—you know that we kick ass when it comes to crafting conferences.

To say that I’m excited about Ampersand would be an understatement. I mean, come on! A day of font geekery with speakers like Jon Tan, Tim Brown, David Berlow and Jonathan Hoefler …it’s going to be typography heaven! It’s also a good excuse for you to come on down to Brighton at the start of a Summer weekend …and you could stick around for the typography tour around town with Phil Baines the next day.

There are some other reasons you should register for Ampersand:

Oh, and if you’re a student …it’s half price. Not that the price is much of a limiting factor: a mere £125 is pretty excellent value for such a great line-up.

So book your place and we can get together for a beer—either at the pre-party or the after-party—and we can geek out about typography on the web together.

Tweaking Huffduffer

Because I was so busy, the two-year anniversary of Huffduffer passed unnoticed back in October. Two years! It’s hard to believe. It seems like just yesterday that I launched it. It’s been ticking along nicely for all that time and I’ve been tweaking it whenever I get the chance.

I recently added oEmbed support. I’m very impressed with the humble little format. It’s basically a unified API onto the multiple embed codes provided by so many websites. You request a URL from an endpoint such as https://huffduffer.com/oembed?url= and you get back a JSON (or XML) file with the details of the HTML you need to embed the content—video, photo, whatever. Something like https://huffduffer.com/oembed?url=https://huffduffer.com/adactio/32454

YouTube, Flickr, Vimeo and a whole host of other sites support oEmbed and the Embedly service provides easy access to all of them. Now Huffduffer is listed amongst the 160 oEmbed providers supported by Embedly. Maybe if I make the right ritual sacrifices, perhaps Huffduffer players might start showing up in New Twitter: it uses a combination of oEmbed and a whitelist to display third-party content in the side panel.

I made some tweaks to the front-end of Huffduffer recently too. For starters, you might notice that the body copy font size has been bumped up from fourteen pixels to sixteen. While fourteen pixels is perfectly fine for Helvetica or Georgia, it’s just that little bit too small for .

While I was in there messing around with the CSS, I took the opportunity to tweak the small screen rendering.

Huffduffer on iOS

For a start, I changed the way that the media queries are executed. Instead of beginning with the wide-screen “desktop” layout as the default and then undoing the widths and floats for smaller screens, I’m now using the same technique I’ve tried out here on adactio.com: begin with a linear layout-less flow and only add widths and floats within media query blocks. That way, mobile devices that don’t support media queries will still get the linearised view.

The elephant in the room is, once again, Internet Explorer (below version nine, anyway). While I can quite merrily say “screw ‘em” here on adactio.com, I need to make more of an effort for Huffduffer. So I split up my CSS into two files: a global.css file that contains all the typography and colour rules, and layout.css that contains a default wide-screen “desktop” view followed by media queries for narrower widths. This is how I’m calling both stylesheets:

<link rel="stylesheet" href="/css/global.css" media="all">
<link rel="stylesheet" href="/css/layout.css" media="all and (min-width: 30em)">
<!--[if lt IE 9]>
<link rel="stylesheet" href="/css/layout.css" media="all">

See how the layout.css file is being called twice? Once for browsers that support media queries (with a browser width wider than thirty ems) and again for Internet Explorer less than version nine.

Mobile devices that don’t support media queries or conditional comments will never load the layout.css file. Browsers that do support media queries, be they mobile or desktop, will only execute layout.css if the viewport is at least thirty ems wide. Legacy versions of Internet Explorer will always load layout.css because of the conditional comment. It’s entirely possible that Windows Mobile 7 will also load layout.css because the browser is currently using an IE7 codebase (Trident 3.1, to be precise). Screw ‘em …at least until Microsoft bring out an update.

The disadvantage of this technique is that my CSS is now split up into two separate files. I’d much rather keep HTTP requests to a minimum by having just one style sheet, but I think that, in this case, the reward in cross-browser compatibility is worth the expense of that extra hit.

While I was testing the changes, I noticed something interesting on my iPod Touch when I was at the Clearleft office, where we have the stereo connected to the WiFi network. The most recent iOS update allows you to stream directly from your device to your stereo or television. What I didn’t realise was that this is true of any media, including HTML5 video and audio content in a web page. Nice!

Huffduffer on iOS

Wait. They don’t love you like I love you.

There’s been a lot of map-related activity on the BBC recently. The series of documentaries called The Beauty of Maps was all too short.

Meanwhile, Radio 4 ran a ten-part series entitled On The Map. They would have disappeared down the Beeb’s memory hole but Brian did a little bit of digital preservation and passed them on to me. I’ve put them on Huffduffer. You can subscribe to a podcast of all ten episodes or listen to them individually:

  1. The Map Makers
  2. Mapping the Metropolis
  3. Motoring Maps
  4. Social Mapping
  5. The Lie of the Land
  6. World View
  7. Off The Map
  8. Whose Map is it Anyway?
  9. Digital Maps
  10. Maps of the Mind

If you’re in London any time before September 19th, be sure to check out the Magnificent Maps exhibition at The British Library. It’s free and it’s excellent.


Twitter doesn’t allow for much verbosity but sometimes it’s possible to squeeze some code into 140 characters or fewer. I particularly like Simon’s piece of JavaScript. Paste this into the address bar in Safari:

javascript:(function(){var d=0;setInterval(function()
'rotate('+ d +'deg)';d+=1},10)}());

Earlier today, I wrote:

Writing <abbr title="and">&amp;</abbr> in my markup and abbr[title='and'] { font-family: Baskerville; font-style: italic; } in my CSS.

This is something that Dan has written about in the past, citing Bringhurst; In heads and titles, use the best available ampersand. Dan suggested wrapping ampersands in a span with a class of “amp” but in a comment, I proposed using the abbr element:

<abbr title="and" class="amp">&amp;</abbr>

But really, you don’t even need the class because you can just use an attribute selector:

abbr[title='and'] {
 font-family: Baskerville, Palatino, "Book Antiqua", serif;
 font-style: italic;

But, asks Mat Marquis, what about a certain browser that can’t even handle the simplest of attribute selectors? Won’t IE666 still need a class attribute?

Well, it turns out that you can’t style the abbr element in the Browser of the Beast with or without a class attribute. That’s because Internet Explorer didn’t support the abbr element until version 8 (and yet people scoff at the 2022 date for two complete HTML5 implementations). If you want to slap some sense into earlier versions of IE, you can always use a smattering of DOM Scripting.

Bruce wonders:

Is there not some JS that can quietly add class=”and” when it sees an ampersand in a text node ?

Turns out that Ted has already written a script to do that.

If you want to be a real stickler, Erik Vorhes keeps his tongue firmly in cheek with this suggestion:

<abbr title="et" lang="la">&amp;</abbr>