Jeremy Keith's Blog, page 139

The last show of the year

I flew out to San Francisco last week for An Event Apart. This was the final event (apart) of the year so it was something of a bittersweet affair. This year the line-up for AEA was—with some minor modifications—consistent from city to city:

Seattle
Boston
Atlanta
Minneapolis
Washington DC
San Francisco

It was like a travelling roadshow, a carnival of web geekery. Next year's AEA line-up will be very different from city to city, showcasing lots of new speakers, so last week's San Francisco gig felt like the last concert of a tour before the band breaks up.

Well, we went out with a bang. It was a great conference. But then, every AEA this year has been pretty great (see my account from Boston, for example). I saw so many great presentations and met so many lovely people.

With An Event Apart San Francisco falling in December, I was able to extend my travel time into a Christmas-time trip to Jessica's family in Arizona …but not before spending a week in San Francisco.

I love that town. Admittedly that might be because there's so many people I know that live there but it's just a fun place to be a tourist. Coffee at Four Barrel, a Mission burrito, coffee at Blue Bottle, pizza in North Beach, beers at Toronado, wine-tasting in Napa—and all of it culminating in a once-in-a-lifetime trip to The French Laundry.

I put together a Map Tale of my trip, which turned out to be a great way of jotting down my experiences at the end of each day (or at the start of the next day if the day's exertions proved too much).

Tagged with
aneventapart
conference
aea
sanfrancisco
travel

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 psychogeography.

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.

Tagged with
maptales
stories
location
geo
psychogeography
maps
cartography

The forgotten house

The Never Forgotten House is a beautifully-written piece with a central premise that is utterly, utterly flawed. Once again the truism that "the internet never forgets" is presented as though it needed no verification.

Someday soon, the internet will fulfill its promise as a time machine. It will provide images for every space and moment so we can fact check our memories. Flickr and Facebook albums will only accumulate.

Citation needed. Badly.

Read the article. Enjoy it. But question its unquestioningness. It made me sad for exactly the opposite reasons that the author intended.

Every essential moment of a child's life is documented if he was born in the West. With digital album after album for every birthday, every Christmas, he will never struggle to remember what his childhood home looked like.

I wish that were true.

Tagged with
memory
digital
preservation

Clean conditional loading

It's December. That means it's time for the geek advent calendars to get revved up again:

PHP Advent 2011,
Adfont Calendar 2011 and
24 Ways 2011.

For every day until Christmas eve, you can find a new tasty geek treat on each of those sites.

Today's treat on 24 Ways is a little something I penned called Conditional Loading for Responsive Designs. It expands on the technique I'm using on Huffduffer to conditionally load inessential content into a sidebar with Ajax when the layout is wide enough to accommodate it:

In that example, the Ajax only kicks in if the viewport is wider than 640 pixels. Assuming I've got a media query that also kicks in at 640 pixels, everything's hunky-dory.

But …it doesn't feel very DRY to have that 640 pixel breakpoint repeated in two places: once in the CSS and once in the JavaScript. It feels even ickier if I'm using ems for my media query breakpoints (as I often do) while using pixels in JavaScript.

At my recent responsive enhancement workshop in Düsseldorf, Andreas Nebiker pointed out an elegant solution: instead of testing for the viewport width in JavaScript, why not check for a style change that would have been executed within a media query instead?

So, say for example I've got some CSS like this:

@media screen and (min-width: 640px) {
[role="complementary"] {
width: 30%;
float: right;
}
}

Then in my JavaScript I could test to see if that element has the wide-screen layout or not:

var sidebar = document.querySelector('[role="complementary"]'),
floating = window.getComputedStyle(sidebar,null).getPropertyValue('float');
if (floating == 'right') {
// Use Ajax to retrieve content here.
}

Or something like that. The breakpoint is only specified once so if I ever change it from 640 pixels to something else (like 40 ems) then I only have to make that change in one place. Feel free to grab the example and play around with it.

By the way, you'll notice that in the original 24 Ways article and also in this updated example, I'm only testing the layout on page load; not on page resize. It would be fairly easy to add in an onResize test as well but I'm increasingly coming to the conclusion that—apart from the legitimate use case of orientation change on tablets—the only people resizing their browser windows after the page loads are web designers testing responsive designs. Still, it would be nice to see some more data on this hypothesis.

Tagged with
responsive
javascript
css
conditional
loading
ajax
24ways

Hackfarming Map Tales

I had a good productive Responsive Enhancement workshop in Düsseldorf and Marc was an excellent host. But alas, I couldn't stick around for the rest of the Beyond Tellerrand conference which was, by all accounts, excellent.

I made my way back to the UK post-haste and started playing rail parkour to get across the country to Herefordshire. There lies The Colloquy—the rural but very comfy location for Clearleft's week of hacking in the countryside.

Casing out the joint

We called it Hackfarm. The idea was pretty straightforward. For one week we would sequester ourselves in a farmhouse (admittedly it was a farmhouse with a jacuzzi), decide on A Thing to build and then …build it.

Max and Mike graciously agreed to join us with their considerable dev talents. Jessica also joined us, rising to the considerable challenge of catering for a dozen people.

Planning the heist

We didn't know what we were going to build, 'though some people had some ideas. We spent the first evening listening to those ideas, discussing them and voting on them until we came to an agreement and decided what the project would be. The next morning, Hackfarm began in earnest.

Part of Hackfarm's raison d'être was to try out some new things. In that spirit, Andy introduced to the Kanban method and we gave it a whirl.

Everyone got involved in the design process, splitting into ad-hoc groups to figure out personas, generate user stories and sketch interface ideas. It was equal parts hard work and really good fun.

The caper

As the ideas solidified, we shifted to our laptops, firing up graphics programmes and text editors, ready to get down to some building. Again, collaboration was the key. Developers and designers sat down together, pushing pixels and cranking out code.

By the end of the week we had a working website.

The reveal

It's called Map Tales. It's a tool to help people tell stories illustrated with maps.

Now there are plenty of map-based narratives out there on the web but many of them suffer from what Schuyler Erle calls red dot fever: a bunch of points shown on a map all at once. One of the design principles that emerged early on at Hackfarm was that the map was secondary to narrative. When you're reading a story in a book, you don't know where the next chapter will take you.

Compare this Google Maps narrative with the corresponding Map Tale.

It's a simple narrative device but it adapts well to stories of all sizes. Rich put together a Mediterranean-spanning Map Tale for The Odyssey while I documented the tale of recreating shots from The Matrix in their filming locations in downtown Sydney.

The site went live on the last full day of Hackfarm but we've kept it quiet 'till now while we sorted out some of the rough edges. I've been tweaking the small screen styles a bit while Andy has been working like crazy to finesse the tale creation process.

I know I'm biased but I really, really like Map Tales. I like that it allows anyone to tell a story and then share it or embed it on their own website. I like that doesn't require any kind of sign-up or log-in process (you get a secret URL for every tale you create that allows you to go back and edit it). I like that it isn't trying to be another social network.

And I really, really, really like the people who made this. I count myself very fortunate indeed to work with such a great group of smart and talented friends.

Tagged with
hackfarm
maptales
hacking
clearleft

Pattern primer

I'm on a workshopping roll. Fresh from running my Responsive Enhancement workshop in Belfast, I'm now heading to Düsseldorf for Beyond Tellerand where I'll be running the workshop on Sunday (and if you can't make it, don't forget that you can book the workshop for your own workplace too).

As part of the process of building a responsive site from the content out rather than the canvas in, I talk about beginning with the individual components divorced from any layout context. Or, as Mark puts it, "start with the bits."

That's the way I've been starting most of my projects lately: beginning with the atomic units of content and styling them first before even thinking about layout. This ensures that those styles are extremely robust—because they don't depend on any particular context, they can be safely dropped into an part of a part.

I've been calling this initial collection of markup snippets a pattern primer. To help create the pattern primer, I've written a little bit of PHP to automatically generate a page of patterns from a folder of HTML snippets.

In my workshop I keep promising to put that script on Github. I finally got around to doing that and you can find it at github.com/adactio/Pattern-Primer.

Take a look at an example pattern primer to get an idea of what a handy deliverable this can be if you're handing off to other developers. It also acts like a page of unit tests for CSS—whenever you've been messing around in the stylesheet you can refresh the page to quickly check to see if anything looks screwed up.

Grab the code; improve upon it; share your changes.

Tagged with
markup
html
php
script
patterns
primer
github
code

Play me off

One of the fun fringe events at Build in Belfast was The Standardistas' Open Book Exam:

Unlike the typical quiz, the Open Book Exam demands the use of iPhones, iPads, Androids—even Zunes—to avail of the internet's wealth of knowledge, required to answer many of the formidable questions.

Team Clearleft came joint third. Initially it was joint fourth but an obstreperous Andy Budd challenged the scoring.

Now one of the principles of this unusual pub quiz was that cheating was encouraged. Hence the encouragement to use internet-enabled devices to get to Google and Wikipedia as quickly as the network would allow. In that spirit, Andy suggested a strategy of "running interference."

So while others on the team were taking information from the web, I created a Wikipedia account to add misinformation to the web.

Again, let me stress, this was entirely Andy's idea.

The town of Clover, South Carolina ceased being twinned Larne and became twinned with Belfast instead.

The world's largest roller coaster become 465 feet tall instead of its previous 456 feet (requiring a corresponding change to a list page).

But the moment I changed the entry for Keyboard Cat to alter its real name from "Fatso" to "Freddy" …BAM! Instant revert.

You can mess with geography. You can mess with measurements. But you do. Not. Mess. With. Keyboard Cat.

For some good clean Wikipedia fun, you can always try wiki racing:

To Wikirace, first select a page off the top of your head. Using "Random page" works well, as well as the featured article of the day. This will be your beginning page. Next choose a destination page. Generally, this destination page is something very unrelated to the beginning page. For example, going from apple to orange would not be challenging, as you would simply start at the apple page, click a wikilink to fruit and then proceed to orange. A race from Jesus Christ to Subway (restaurant) would be more of a challenge, however. For a true test of skill, attempt Roman Colosseum to Orthographic projection.

Then there's the simple pleasure of getting to Philosophy:

Some Wikipedia readers have observed that clicking on the first link in the main text of a Wikipedia article, and then repeating the process for subsequent articles, usually eventually gets you to the Philosophy article.

Seriously. Try it.

Tagged with
wikipedia
buildconf
gaming
quiz

Speaking, not hacking

I spent last week in Belfast for the Build conference, so I did.

The fun kicked off with a workshop on responsive enhancement which was a lot of fun. Toby has written a report of the day outlining all of the elements that came together for a successful workshop.

The day of the conference itself was filled with inspiring, uplifting talks full of positive energy …except for mine. My talk—All Our Yesterdays—had an underlying sense of anger, especially when I spoke about the destruction of Geocities. If you heard the talk and you'd like to explore some of the resources I mentioned, here's a grab-bag of links:

Stock and Flow by Robin Sloan.
Archive Fever by Matt Ogle.
This Place Is Not A Place Of Honor on Damn Interesting.
The 10,000 Year Clock by The Long Now Foundation.
Carl Sagan And Ann Druyan's Ultimate Mix Tape by Radiolab.
Small Pieces, Loosely Joined by David Weinberger.
Lest We Forget or Why I chose the World Wide Web as a repository for archival material by Simon Pockley.
Cool URIs Don't Change by Tim Berners-Lee.
"The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years." on Long Bets.
Game Web 2.Over? by Meg Pickard.
Link Rot by Connor O'Brien.
Ugly and neglected fragments by Phil Gyford.
Yahoo!locaust by Jason Scott.
Goodbye Pownce, Hello Six Apart on the Pownce blog.
Why you should have a website: it's the law! by Steven Pemberton.
The Domesday Project by the BBC.
Preservation and Long-term Access through Networked Services by the Open Planets Foundation.
Swiss Fort Knox.
Validation by Owen Briggs.
[whatwg] several messages about HTML5 by Ian Hickson.
Accelerando by Charles Stross.
Microsoft and FairUse4WM by Bruce Schneier.
Forever by Mandy Brown.

I thought I had delivered the talk reasonably well only to discover that my American friends in the audience misinterpreted my quote from Tim Berners-Lee as "Cool your eyes don't change."

Still, it was wonderfully surreal to be introduced by Jesse Thorn.

My appearance at Build was an eleventh hour affair. Ethan was originally set to speak but he had to cancel. Andy asked me to step in. At first I didn't think it would be possible. Last Thursday—the day of the conference—was the day I was supposed to fly to San Francisco for Science Hack Day. Luckily I was able to change my flight.

That's why I was up at the crack of dawn the day after Build to catch an early-morning flight to Heathrow where I would have to dash from the lowest to the highest numbered terminal to get on my transatlantic hackrocket.

So you can imagine how my heart sank as I sat in the departure lounge of Belfast International Airport listening to the announcement of a delay to the first flight. First it was one hour. Then two.

When I did finally make it to Heathrow, there was no chance of making the flight to San Francisco. I was hoping that perhaps it too had been delayed by the foggy weather conditions but no, it took off right on time. Without me.

As my flight from Belfast was a completely separate booking rather than a connecting flight, I couldn't get on a later flight unless I paid the full fare. So I simply accepted my fate.

C'est la vie, c'est it is.

It looks like Science Hack Day San Francisco—to the surprise of absolutely no-one—was a superb event. There's a write-up on the open.NASA blog outlining some of the amazing hacks, including the cute (and responsive) Space Ipsum and the freakishly brilliant synesthesia mask: syneseizure.

Tagged with
buildconf
conference
belfast
workshop
sciencehackday
event
speaking

Pursuing semantic value

Divya Manian, one of the super-smart web warriors behind HTML5 Boilerplate, has published an article on Smashing Magazine called Our Pointless Pursuit Of Semantic Value.

I'm afraid I have to agree with Patrick's comment when he says that the abrasive title, the confrontational tone and strawman arguments at the start of the article make it hard to get to the real message.

But if you can get past the blustery tone and get to the kernel of the article, it's a fairly straightforward message: don't get too hung up on semantics to the detriment of other important facets of web development. Divya clarifies this in a comment:

Amen, this is the message the article gets to. Not semantics are useless but its not worth worrying over minute detail on.

The specific example of divs and sectioning content is troublesome though. There is a difference between a div and a section or article (or aside or nav). I don't just mean the semantic difference (a div conveys no meaning about the contained content whereas a section element is specifically for enclosing thematically-related content). There are also practical differences.

A section element will have an effect on the generated outline for a document (a div will not). The new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots (as other people mentioned in the comments) but it already has practical effects today in some browsers in their default styling.

Download the HTML document I've thrown up at https://gist.github.com/1360458 and open it in the latest version of Safari, Chrome or Firefox. You'll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element (thanks to -moz-any and -webkit-any CSS declarations in the browser's default stylesheets).

So that's one illustration of the practical difference between div and section.

Now with that said, I somewhat concur with the conclusion of "when in doubt, just use a div". I see far too many documents where every div has been swapped out for a section or an article or a nav or an aside. But my reason for coming to that conclusion is the polar opposite of Divya's reasoning. Whereas Divya is saying there is effectively no difference between using a div and using sectioning content, the opposite is the case: it makes a big difference to the document's outline. So if you use a section or article or aside or nav without realising the consequences, the results could be much worse than if you had simply used a div.

I also agree that there's a balance to be struck in the native semantics of HTML. In many ways its power comes from the fact that it is a limited—but universally understood by browsers—set of semantics. If we had an element for every possible type of content, the language would be useless. Personally, I'm not convinced that we need a section element and an article element: the semantics of those two elements are so close as to be practically identical.

And that's the reason why right now is exactly the time for web developers to be thinking about semantics. The specification is still being put together and our collective voice matters. If we want to have well-considered semantic elements in the language, we need to take the time to consider the effects of every new element that could potentially be used to structure our content.

So I will continue to stop and think when it comes to choosing elements and class names just as much as I would sweat the details of visual design or the punctation in my copy or the coding style of my JavaScript.

Tagged with
semantics
html5
standards
development
markup
language
html

Responsible responsive images

I'm in Belfast right now for this year's Build conference, so I am. I spent yesterday leading a workshop on responsive enhancement—the marriage of responsive design with progressive enhancement; a content-first approach to web design.

I spent a chunk of time in the afternoon going over the thorny challenges of responsive images. Jason has been doing a great job of rounding up all the options available to you when it comes to implementing responsive images:

Responsive IMGs, Part 1,
Responsive IMGs, Part 2—an in-depth look at techniques,
Responsive IMGs, Part 3—the future of the img element.

Personally, I have two golden rules in mind when it comes to choosing a responsive image technique for a particular project:

The small image should be default.
Don't load images twice (in other words, don't load the small images and the larger images).

That first guideline simply stems from the mobile-first approach: instead of thinking of the desktop experience as the default, I'm assuming that people are using small screen, narrow bandwidth devices until proven otherwise.

Assuming a small-screen device by default, the problem is now how to swap out the small images for larger images on wider viewports …without downloading both images.

I like Mark's simplified version of Scott's original responsive image technique and I also like Andy's contextual responsive images technique. They all share a common starting point: setting a cookie with JavaScript before any images have started loading. Then the cookie can be read on the server side to send the appropriate image (and remember, because the default is to assume a smaller screen, if JavaScript isn't available the browser is given the safer fallback of small images).

Yoav Weiss has been doing some research into preloaders, cookies and race conditions in browsers and found out that in some situations, it's possible that images will begin to download before the JavaScript in the head of the document has a chance to set the cookie. This means that in some cases, on first visiting a page, desktop browsers like IE9 might begin get the small images instead of the larger images, thereby violating the second rule (though, again, mobile browsers will always get the smaller images, never the larger images).

Yoav concludes:

Different browsers act differently with regard to which resources they download before/after the head scripts are done loading and running. Furthermore, that behavior is not defined in any spec, and may change with every new release. We cannot and should not count on it.

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That's why I was surprised by Jason's conclusion that device detection is the future-friendly img option.

Don't get me wrong: using a service like Sencha.io SRC (formerly TinySRC)—which relies on user-agent sniffing and a device library lookup—is a perfectly reasonable solution for responsive images …for now. But I wouldn't call it future friendly; quite the opposite. If anything, it might be the most present-friendly technique.

One issue with relying on user-agent sniffing is the danger of false positives: a tablet may get incorrectly identified as a mobile phone, a mobile browser may get incorrectly identified as a desktop browser and so on. But those are edge cases and they're actually few and far between …for now.

The bigger issue with relying on user-agent sniffing is that you are then entering into an arms race. You can't just plug in a device library and forget about it. The library must be constantly maintained and kept up to date. Given the almost-exponential expansion of the device and browser landscape, that's going to get harder and harder.

Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven't imagined yet—will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won't hold up. Today's onslaught of devices is already pushing them to the breaking point. They can't withstand what's ahead.

So while I consider user-agent sniffing to be an acceptable short-term solution, I don't think it can scale to the future onslaught—not to mention the tricky issue of the licensing landscape around device libraries.

There's another reason why I tend to steer clear of device libraries like WURFL and Device Atlas. When you consider the way that I'm approaching responsive images, those libraries are over-engineered. They contain a massive list of mobile user-agent strings that I'll never need. Remember, I'm taking a mobile-first approach and assuming a mobile browser by default. So if I'm going to overturn that assumption, all I need is a list of desktop user-agent strings. That's a much less ambitious undertaking. Such a library wouldn't need to kept updated quite as often as a mobile device listing.

Anybody fancy putting it together?

Tagged with
responsive
design
mobile
images
futurefriendly
ffly