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.
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
.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.
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 Devil’s 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:
- usage, and
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.
@andybudd Adding the word “menu” next to it goes a long way, and would help with teaching aspect to help it become more familiar in time.— Paul Annett (@PaulAnnett) January 16, 2016
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.
@andybudd FWIW, I know some people in their 60s who couldn’t tell you what the two line pause icon would do on a web video player.— Paul Annett (@PaulAnnett) January 16, 2016
I think there are two good rules of thumb when it comes to using icons:
- If in doubt, label it.
- 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):
- Representation: It depends. Is it representing a stacked list of menu items? If so, good. If not, reconsider.
- 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.
- 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:
- FF Conf on Friday, November 6th,
- Meaning on Thursday, November 12th, and
- 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.
Videos will be available from FF Conf, and audio will be available from Ampersand. Be sure to check them out once they’re released.
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
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.
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.
Last week I received another gift from Dan: a 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.
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.
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.
I like sparklines a lot. Tufte describes a sparkline as:
…a small intense, simple, word-sized graphic with typographic resolution.
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
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.
canvas element with the dimensions you want for the sparkline, then pass the ID of that element (along with your dataset) into the
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.
Update: Ask and thou shalt receive. Check out this fantastic lightweight SVG solution from Stuart—bloody brilliant!
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..— displays. The guys over at Filament group have labelled this Compressive Images. Nice.
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
::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!
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.
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).
My last Mirror Project shot was taken at South by Southwest in 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.
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.
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.
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…
What a crock of shit.
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.
My friend @substitute suggested replacing every technobabble instance of “cloud” with “the Moon” and it’s changed my life— Pinboard (@Pinboard) January 6, 2012
Death to the cloud! Long live the New Flesh of servers, routers, wires and cables.
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
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.
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.
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.
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:
- One lucky attendee will receive a gorgeous lesson plan print from those lovely chaps at Ligature, Loop & Stem.
- Every attendee will receive $20 worth of fonts from Fontdeck.
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.
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 Baskerville.
While I was in there messing around with the CSS, I took the opportunity to tweak the small screen rendering.
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
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
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"> <![endif]-->
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
audio content in a web page. Nice!
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:
- The Map Makers
- Mapping the Metropolis
- Motoring Maps
- Social Mapping
- The Lie of the Land
- World View
- Off The Map
- Whose Map is it Anyway?
- Digital Maps
- 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.