Archive: April, 2012

In the final part of his series on responsive design in .net magazine, Paul talks about testing:

The key thing to remember here is that any testing is better than no testing. Build up a test suite as large as you can afford, and find opportunities to test on other devices whenever you can.

I agree wholeheartedly and I think that any kind of testing with real devices should be encouraged. I find it disheartening when somebody blogs or tweets about testing on a particular device, only to be rebuffed with sentiments like “it isn’t enough.” It’s true—it isn’t enough …but it’s never enough. And the fact that a developer is doing any testing at all is a good thing.

There are some good resources out there to help you get started in putting together a collection of test devices.

• Testing for dummies is a great blog devoted specifically to testing responsive designs on mobile devices.
• Luke gathered a number of links to device arsenals on this Bagcheck post.
• Stephanie wrote about strategies for choosing test devices.

Actually, you should probably just read everything on Stephanie’s site: it’s all thoughtful and useful. In her post on the value of 1000 Androids she wrote:

The dirty little secret is that the more you test—the more accurately you will determine when it’s ok not to.

That’s crucial. I think there’s a common misunderstanding that testing on many different devices means developing for many different devices. Nothing could be further from the truth. Just as in the world of the desktop, we shouldn’t be developing for any specific devices or browsers. That’s why we develop with standards.

In fact I’ve found that one of the greatest benefits of testing on as many different platforms as possible is that it stops me from straying down the path of device-specific development. When I come across a problem in my testing, my reaction isn’t to think “how can I fix this problem on this particular device?”, which would probably involve throwing more code at it. Instead I think “how can I avoid this problem?” The particular device may have highlighted the issue, but there’s almost always a more fundamental problem to be tackled …and it’s very rarely tackled by throwing more code at it.

I wish I had more devices to test on …even if it might increase the risk of me getting reported to the police. At the same time, I realise that it’s a pretty crumby and expensive situation for developers, particularly freelancers. As Paul wrote:

Not only does it present a potential barrier to entry for anyone wanting to build responsive websites, but it encourages the purchase of yet more devices and gadgets.

I’ve been keeping my costs down by shopping in dodgy second-hand electronics shops that sell devices that have fallen off the back of a lorry. Most of them sell phones with a classification of A, B, or C. If something is labelled A, it is mint condition. If something is labelled C, there might be something wrong with it or you might not get all the cables or the box. But for my purposes, that’s absolutely fine. If anything, I’m usually hunting for outdated devices with older versions of operating systems.

So far I’ve got:

• An HTC thingy running Windows Phone 7.5,
• Another HTC thingy running Android 2.3.4,
• A little Samsung running Android 2.2,
• A Blackberry 9800 (Torch, right?),
• A Blackberry Playbook,
• A Kindle,
• An iPod running iOS 3.1.3,
• An iPad running iOS 5.something,
• And I’ve got my own iPhone 4 and Kindle Touch.

I don’t know about you, but my eyes glaze over when it comes to phone models and operating system numbers, especially when they just end up sounding like condoms. Luckily we’ve got people like PPK to help us figure out the smartphone browser landscape.

You’ll notice plenty of glaring omissions in my paltry list—there’s nary a Nokia device to be found—but I aim to plug those gaps as soon as I can.

In the meantime I’ve been setting up a desk at the Clearleft office for these devices so that they can stay charged up and within reach.

We’ve always had an open-door policy here, so if you want to pop around, use our WiFi, and test on our devices, you’re more than welcome. Give me some advance warning on Twitter and I can put the kettle on for a cup of tea. We’re at 28 Kensington Street, Suite 2.

Think of it as a quick’n’dirty, much smaller-scale version of Mobile Portland’s Device Lab.

I got some great comments on my post about conditionally loading content.

Just to recap, I was looking for a way of detecting from JavaScript whether media queries have been executed in CSS without duplicating my breakpoints. That bit is important: I’m not looking for MatchMedia, which involves making media queries in JavaScript. Instead I’m looking for some otherwise-useless CSS property that I can use to pass information to JavaScript.

Tantek initially suggested using good ol’ voice-family, which he has used for hacks in the past. But, alas, that unsupported property isn’t readable from JavaScript.

Then Tantek suggested that, whatever property I end up using, I could apply it to an element that’s never rendered: meta or perhaps head. I like that idea.

A number of people suggested using font-family, citing Foresight.js as prior art. I tried combining that idea with Tantek’s suggestion of using an invisible element:

@media screen and (min-width: 45em) {
    head {
        font-family: widescreen;
    }
}

Then I can read that in JavaScript:

window.getComputedStyle(document.head,null).getPropertyValue('font-family')

It works! …except in Opera. Where every other browser returns whatever string has been provided in the font-family declaration, Opera returns the font that ends up actually getting used (Times New Roman by default).

I guess I could just wait a little while for Opera to copy whatever Webkit browsers do. (Ooh! Controversial!)

Back to the drawing board.

Stephanie suggested using z-index. I wouldn’t to do that in the body of my document for fear of screwing up any complex positioning I’ve got going on, but I could apply that idea to the head or a meta element:

@media screen and (min-width: 45em) {
    head {
        z-index: 2;
    }
}

Alas, that doesn’t seem to work in Webkit; I just get back a value of auto. Curses! It works fine if it’s applied to an element in the body but like I said, I’d rather not screw around with the z-indexing of page elements. Ironically, it works fine in Opera

A number of people suggested using generated content! “But how’s that supposed to work?” I thought. “I won’t be able to reference the generated DOM node from my JavaScript, will I?”

It turns out that I’m an idiot. That second argument in the getComputedStyle method, which I always just blindly set to null, is there precisely so that you can access pseudo-elements like generated content.

Dave McDermid, Aaron T. Grogg, Colin Olan, Elwin Schmitz, Emil, and Andy Rossi arrived at the solution roundabout the same time.

Here’s Andy’s write-up and code. His version uses transition events to fire the getComputedStyle check: probably overkill for what I want to do, but very smart thinking.

Here’s Emil’s code. I was initially worried about putting unnecessary generated content into the DOM but the display:none he includes should make sure that it’s never seen (or read by screenreaders).

I could just generate the content on the body element:

@media all and (min-width: 45em) {
    body:after {
        content: 'widescreen';
        display: none;
    }
}

It isn’t visible, but it is readable from JavaScript:

var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');

And with that, I can choose whether or not to load some secondary content into the page depending on the value returned:

if (size == 'widescreen') {
    // Load some more content.
}

Nice!

As to whether it’s an improvement over what I’m currently doing (testing for whether columns are floated or not) …probably. It certainly seems to maintain a nice separation between style and behaviour while at the same time allowing a variable in CSS to be read in JavaScript.

Thanks to everyone who responded. Much appreciated.

Update: If you’re finding that some browsers are including the quotes in the returned :after value, try changing if (size == 'widescreen') to if (size.indexOf("widescreen") !=-1). Thanks to multiple people who pointed this out.

.net Magazine is running a series of articles on their site right now as part of their responsive week. There’s some great stuff in there: Paul is writing a series of articles—one a day—going step-by-step through the design and development of a responsive site, and Wilto has written a great summation of the state of responsive images.

There’s also an interview with Ethan in which he answers some reader-submitted questions. The final question is somewhat leading:

What devices (smartphones/tablets) and breakpoints do you typically develop and test with?

Ethan rightly responds:

Well, I’m a big, big believer of matching breakpoints to the design, not to individual devices. If we’re after more future-proof responsive designs, we should stop thinking in terms of ‘320px’, ‘480px’, ‘768px’, or whatever – the web’s so much more flexible than that, and those pixels are a snapshot of the web as we know it today. Instead, we should focus on breakpoints tailored to the design we’re working on.

He’s right. If we’re truly taking a Content First approach then we need to “Start designing from the content out, rather than the canvas in.”

If we begin with some specific canvases (devices), they’re always going to be arbitrary. There are so many different screen sizes and ratios out there that it doesn’t make sense to favour a handful of them out of tradition. 320, 480, 640 …those numbers aren’t any more special than any other screen widths.

But I now realise that I have been also been guilty of strengthening the hallowed status of those particular pixel widths. When I post screenshots to Flickr or include screenshots in presentations I automatically do what the Media Queries site does: I take snapshots at “traditional” widths like 320, 480, 640, 800, and 1024 pixels.

Physician, heal thyself.

So I’ve started taking screenshots at different widths. For the screenshots I posted of the new dConstruct site, I took a series of screenshots from 200 to 1200 pixels in increments of 100.

But really I should be illustrating the responsive nature of the design by taking screenshots at truly arbitrary widths: 173, 184, 398, 467, 543, 678, 832 …the sheer randomness of those kinds of numbers would better reflect the diversity of screen sizes out there.

Of course what I should really be doing is posting pictures of the website on actual devices.

I think our collective obsession with trying to nail down “common” breakpoints has led to a fundamental misunderstanding about the nature of responsive design: it’s not about what happens at the breakpoints—it’s about what happens between the breakpoints.

I think Jeffrey demonstrated this misunderstanding when he wrote about devices and breakpoints:

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

I was surprised that he suggested the long-term solution would be a shake-out of screen widths resulting in a de-facto standardisation:

But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

I don’t think that will happen. If anything, I think we will see even more diversity in screen sizes and ratios.

But more importantly, I don’t think it’s desirable to have a “standard” handful of screen widths, any more than it’s desirable to have a single rendering engine in every browser (yes, I know some developers actually wish for that: they know not what they do).

I agree with Stephanie: diversity is not a bug …it’s an opportunity.

Bevan did a great job on the dConstruct website. I tried to help him out along the way, which mostly involved me doing a swoop’n’poop code review every now and then.

I was particularly concerned about performance so I suggested base-64 encoding background images wherever possible and squeezing inline images through ImageOptim. I also spotted an opportunity to do a bit of conditional loading.

Apart from the home page, just about every other page on the site features a fairly hefty image in the header …if you view it in a wide enough browser window. If you’re visiting with a narrow viewport, an image like this would just interfere with the linearised layout and be an annoying thing to scroll past.

So instead of putting the image in the markup, I put a data-img attribute on the body element:

<body data-img="/img/conference.png">

Then in a JavaScript file that’s executed after the DOM has loaded, I check to see if the we’re dealing with a wide-screen viewport or not. Now, the way I’m doing this is to check to see if the header is linearised or if it’s being floated at all—if it’s being floated, that means the layout styles within my media queries are being executed, ergo this is a wide-screen view, and so I inject the image into the header.

I could’ve just put the image in the markup and used display: none in the CSS to hide it on narrow screens but:

1. that won’t work for small-screen devices that don’t support media queries, and
2. the image would still be downloaded by everyone even if it isn’t displayed (a big performance no-no).

I’m doing something similar with videos.

If you look at a speaker page you’ll see that in the descriptions I’ve written, I link to a video of the speaker at a previous conference. So that content is available to everyone—it’s just a click away. On large viewports, I decided to pull in that content and display it in the page, kind of like I’m doing with the image in the header.

This time, instead of adding a data- attribute to the body, I’ve put in a div (with a class of “embed” and a data-src attribute) at the point in the document where I want to the video to potentially show up:

<div class="embed" data-src="//www.youtube.com/embed/-2ZTmuX3cog"></div>

There are multiple video providers—YouTube, Vimeo, Blip—but their embed codes all work in much the same way: an iframe with a src attribute. That src attribute is what I’ve put in the data-src attribute of the embed div.

<div class="embed" data-src="//player.vimeo.com/video/33692624"></div>

Once again, I use JavaScript after the DOM has loaded to see if the wide-screen media queries are being applied. This time I’m testing to see if the parent of the embed div is being floated at all. If it is, we must be viewing a widescreen layout rather than the linearised content. In that case, I generate the iframe and insert it into the div:

(function(win){
    var doc=win.document;
    if (doc.getElementsByClassName && win.getComputedStyle) {
        var embed = doc.getElementsByClassName('embed')[0];
        if (embed) {
            var floating = win.getComputedStyle(embed.parentNode,null).getPropertyValue('float');
            if (floating != 'none') {
                var src = embed.getAttribute('data-src');
                embed.innerHTML = '<iframe src="'+src+'" width="320" height="180" frameborder="0"></iframe>';
            }
        }
    }
})(this);

In my CSS, I’m then using Thierry Koblentz’s excellent technique for creating intrinsic ratios for video to make sure the video scales nicely within its flexible container. The initial video proportion of 320x180 is maintained as a percentage: 180/320 = 0.5625 = 56.25%:

.embed {
    position: relative;
    padding-bottom: 56.25%;
    height: 0;
}
.embed iframe {
    position: absolute;
    top:  0;
    left: 0;
    width: 100%;
    height: 100%;
}

The conditional loading is working fine for the header images and the embedded videos, but I still feel a bit weird about testing for the presence of floating.

I could use matchMedia instead but then I’d probably have to use a polyfill (another performance hit), and I’d still end up maintaining my breakpoints in two places: once in CSS, and again in JavaScript. Likewise, if I just used documentElement.clientWidth, I’d have to declare my breakpoints twice.

Paul Hayes wrote about this issue a while back:

We need a way of testing media query rules in JavaScript, and a way of generating events when a new rule matches.

He came up with the ingenious solution of using transitionEnd events that are fired by media queries. The resulting matchMedia polyfill he made is very clever, but probably overkill for what I’m trying to do—I don’t really need to check for resize events for what I’m doing.

What I really need is some kind of otherwise-useless CSS declaration just so that I can test for it in JavaScript. Suppose there were a CSS foo declaration that I could use inside a media query:

@media screen and (min-width: 45em) {
    body {
        foo: bar;
    }
}

…then in JavaScript I could test its value:

var foovalue = window.getComputedStyle(document.body,null).getPropertyValue('foo');
if (foovalue == 'bar') {
    // do something
}

Of course that won’t work because foo wouldn’t be recognised by the browser so it wouldn’t be available to interrogate in JavaScript.

Any ideas? Maybe something like zoom:1 ? If you can think of a suitable CSS property that could be used in this way, leave a comment.

Of course, now that I’m offering you a textarea to fill in with your comments, you’re probably just going to use it to tell me what’s wrong with the JavaScript I’ve written …those “comments” might mysteriously vanish.

I was up in the big smoke last week for UX London. It was excellent: a thoroughly superb line-up of smart speakers and lovely attendees. Kate did a great job of making sure everything ran smoothly.

But there’s no rest for the wicked. With UX London done, Clearleft is gearing up for the other two events we’ve got lined up: Ampersand in June—there are still some tickets available—and dConstruct in September.

We sneakily soft-launched the dConstruct website while we were manning the front desk at UX London. It was put together by our current intern, Bevan Stephens, and as you can see, he’s done a superb job. I offered some guidance on the mobile-first approach which he implemented beautifully.

I’ll write some more later about some of the specifics of the site, but for now, I just want to say: check out that line-up!

Usually Andy is responsible for putting together the roster of speakers but this year it was my turn. It was a lot of work and I have a renewed appreciation for the great job Andy has done every year in putting together a kick-ass conference. I’ve always felt that one of the strengths of dConstruct is the way the day is curated.

There’s a lot to live up to: seven years worth of fantastic talks. But I couldn’t be happier about the line-up we’ve got for dConstruct 2012:

One of my favourite writers, Lauren Beukes; local genius Seb Lee-Delisle; brilliant London lads Tom Armitage and Ben Hammersley; my hero Jason Scott; brain-the-size-of-a-planet Scott Jenson; my super-smart friends Ariel Waldman and Jenn Lukas; and, wait for it …James. Fucking. Burke.

Your reaction to that last one will either be “who?” or “OMGWTFBBQ!” depending on your age and/or penchant for the greatest popular science television shows ever broadcast.

I realise it’s a very self-indulgent line-up—I’ve basically put together my wish list of the smartest, funniest, most eloquent people I know, but it’s all in service of the theme for this year: Playing With The Future.

(Yeah, I came up with that one. Can you tell?)

Lest there be any misunderstanding about the kind of event dConstruct 2012 will be, I’ve written a few words about what to expect:

The presentations may not contain any practical tips you can take back to work on Monday morning but you will gain insights into the direction our digital technology is taking. You might just find yourself showing up at work on Monday morning with an altered perspective on the world.

Tickets go on sale at the end of May. They’ll be a very affordable £130 plus VAT.

Oh, and did I mention the workshops that will precede the day of the conference? Ethan Marcotte, Remy Sharp, Lyza Danger Gardner, and Jonathan Snook: Kick. Ass!

I am so ridiculously excited. I cannot wait until September!

I hope to see you there.

You never forget your first DMCA takedown notice. In my case it was the Perfect Pitch incident, in which an incompetent business was sending out automatic takedown notices to Google for any website that contained a combination of the words Burge Pitch Torrent. That situation, which affected The Session, was resolved with an apology from the offending party.

Now I’ve received my second DMCA takedown notice. Or rather, my hosting company has. This time it involves Huffduffer.

When I created Huffduffer, I thought about offering hosting for audio files. One of the reasons I decided not to is because of the potential legal pitfalls. As it stands, Huffduffer is pretty much entirely text—it just links to audio files elsewhere on the web. That’s basically what an RSS enclosure is: another form of hypertext.

Linking is simply the act of pointing to a resource, and apart from a few extreme cases, it isn’t illegal.

Now it could be argued that pointing to an audio file on another site through a Flash player (or HTML5 audio element) is more like hotlinking with an img element than regular linking through an a element. The legal status of hotlinking isn’t quite as clear cut as plain ol’ linking, as explained on the Chilling Effects site:

When people complain about inline images, they are most often complaining about web pages that include graphics from external sources. The legal status of inlining images without permission has not been settled.

So the situation with inline audio is similarly murky.

Here’s the threatening email that was sent to the hosting company:

Notice of Copyright Infringement. {Our ref: [$#121809/228552]}

Sender: Robert Nichol
AudioGO Ltd
The Home of BBC Audiobooks
St James House, The Square, Lower Bristol Road
Bath
BA2 3BH
Phone number not available

Recipient: Rackspace Hosting

RE: Copyright Infringement.

This notice complies with the Digital Millennium Copyright Act (17 U.S.C. §512(c)(3))

I, Robert Nichol, swear under penalty of perjury that I am authorised to act on behalf of AudioGO Ltd, the owner(s) of the copyright or of an exclusive licence in the work(s) The Moving Finger by Agatha Christie BBC Audio.

It has come to my attention that the website huffduffer.com is engaged in the electronic distribution of copies of these works. It is my good faith belief that the use of these works in this manner is not authorised by the copyright owner, his agent or the law. This is in clear violation of United States, European Union, and International copyright law, and I now request that you expeditiously remove this material from huffduffer.com, or block or disable access to it, as required under both US and EU law.

The works are The Moving Finger by Agatha Christie BBC Audio.

The following URLs identify the infringing files and the means to locate them.

https://huffduffer.com/TimesPastOTR/68635 (IP: 67.192.7.4)

The information in this notice is accurate and I request that you expeditiously remove or block or disable access to all the infringing material or the entire site.

/Robert Nichol/
Robert Nichol

Wednesday April 18, 2012

Initially, my hosting company rebutted Robert Nichol’s claim but he’s not letting it go. He insists that the offending URL be removed or he will get the servers taken offline. So now I’ve been asked by my host to delete the relevant page on Huffduffer.

But the question of whether audio hotlinking counts as copyright infringement is a moot point in this case…

Go to the page in question. If you try to play the audio file, or click on the “download” link, you will find yourself at a 404 page. Whatever infringing material may have once been located at the end of the link is long gone …and yet AudioGO Ltd are still insisting that the Huffduffer page be removed!

Just to be clear about this, Robert Nichol is using the Digital Millennium Copyright Act—and claiming “good faith belief” while doing so—to have a site removed from the web that mentions the name of a work by his client, and yet that site not only doesn’t host any infringing material, it doesn’t even link to any infringing material!

It seems that, once again, the DMCA is being used in a scattergun approach like a machine-gun in the hands of a child. There could be serious repercussions for Robert Nichol in abusing a piece of legislation in this way.

If I were to remove the page in question, even though it just contains linkrot, it would set a dangerous precedent. It would mean that if someone else—like you, for instance—were to create a page that contains the text “Agatha Christie — The Moving Finger” while pointing to a dead link …well, your hosting company might find themselves slapped with a takedown notice.

In that situation, you wouldn’t be able to copy and paste this markup into your blog, Tumblr, Facebook, or Google+ page:

<a href="http://dc436.4shared.com/img/892695085/b3c907d3/dlink__2Fdownload_2FaKhc8m9b_3Ftsid_3D20120318-72646-b4a59ab0/preview.mp3">Agatha Christie — The Moving Finger</a>

Remember: that link does not point to any infringing material. It points to nothing but a 404 page. There’s absolutely no way that you could have your site taken offline for pointing to a file that doesn’t exist, right?

That would be crazy.

I went out to The Albert the other night to see Twilight Hotel play. There were really good, so after the show I bought their CD, When The Wolves Go Blind.

It was only when I got home that I realised that I had no device that could play Compact Discs. I play all my music on my iPod or iPhone connected to a speaker dock. And my computer is a Macbook Air …no disc drive. So I had to bring the CD into work with me, stick into my iMac and rip the songs from there.

It’s funny how format (or storage medium) obsolescence creeps up on you like that. I wonder how long it will be until I’m not using any kind of magnetic medium at all.