Archive: April, 2014

When I was talking about Huffduffer, I mentioned that I don’t have any analytics set up for the site:

To be honest, I’m okay with that—one of the perks of having a personal project is that only metric that really matters is your own satisfaction.

For a while, I did have Google Analytics set up on The Session. But I started to feel a bit uncomfortable about willingly opening up a wormhole between my site and the Google mothership. It bothered me that Adblock Plus would show that one ad had been blocked on the site. There are no ads on the site, but the presence of the Google Analytics code was providing valuable information to Google—and its advertiser customer base—so I can understand why it gets flagged up like any other unwanted tracking.

Theoretically, users have a way of opting out of this kind of tracking by switching on the Do Not Track header (if it isn’t switched on by default). Looking at the default JavaScript code that Google provides for setting up Google Analytics, I don’t see any mention of navigator.doNotTrack.

Now, it may well be that Google sniffs for that header (and abandons any tracking) when its server is pinged via the analytics code, but there’s no way to tell from this side of the Googleplex. I certainly don’t see any mention of it in the JavaScript that gets inserted into our web pages.

I was wondering whether it makes sense to explictly check for the doNotTrack header before opening up that connection to google-analytics.com via a generated script element.

So if the current code looks like:

<script>
// generate a script element
// point it to google-analytics.com
</script>

Would it make sense to wrap it with some kind of test for navigator.doNotTrack:

<script>
if (!navigator.doNotTrack || navigator.doNotTrack != 'yes') {
// generate a script element
// point it to google-analytics.com
}
</script>

For the love of mercy, don’t actually use that code—it’s completely untested and probably causes more harm than good. But you can see the idea that I’m trying to get at, right? Google Analytics most definitely counts as tracking so it seems like the ideal use-case for Do Not Track.

It raises a few questions:

1. Is anyone doing this already? It might well be that the answer is “no”, not because of any reluctance to respect user preferences but because the doNotTrack spec is very much in flux.
2. Would you consider doing this?
3. If you were to do this, could you foresee getting pushback from within your own company?

I had a nice Skype chat with Stan Alcorn yesterday all about Huffduffer, online sharing of audio, and all things podcasty and radioish. I’m sure I must have talked his ear off.

Stan was asking about numbers for Huffduffer’s user base and activity. I have to admit that I’ve got zero analytics running on the site. To be honest, I’m okay with that—one of the perks of having a personal project is that only metric that really matters is your own satisfaction. But I told Stan I’d run some quick database queries to get some feeling for Huffduffer’s usage patterns. Here’s what I found…

There are 5,862 people signed up to Huffduffer.

About 150,919 items have been huffduffed. But those aren’t unique files. The total number of distinct files that have been huffduffed is 5,972. That means that, on average, an audio file is huffduffed around 26 times. And the average user has huffduffed around 30 items. But neither of those distributions would be evenly distributed; they’d be power-law distributions rather than bell curves. For example, the most popular file was huffduffed 329 times.

Looking at the amount of items huffduffed each year, there’s a pleasing upward trend.

1st year	7,382
2nd year	19,080
3rd year	23,403
4th year	31,808
5th year	41,514

I was pleasantly surprised by this. I would’ve assumed that Huffduffer usage would be more of a steady-state affair, but it looks like the site is getting used a bit more with each passing year (the site is currently in its sixth(!) year).

Not that any of that really matters. I built Huffduffer to scratch my own itch. I huffduff an average of 411 audio files each year. So even if nobody else used Huffduffer, it would still provide plenty of value to me.

Like I was saying to Stan, the biggest strength and the biggest weakness of audio—as opposed to text or video—is that you can listen to it while your doing other things. For some people, car journeys are the perfect podcast time. For others, it might be doing the dishes or train journeys. For me, it’s the walk to and from work each day—it takes about 35 minutes each way, and I catch up on my Huffduffer feed during that time.

Jessica and I will often listen to some spoken word audio in the background during dinner—usually something quite radio-y like Radiolab, or NPR stories. Yesterday, we were catching up with Aleks’s BBC documentary series, The Digital Human. It was the episode about voice.

Imagine my surprise when I heard the voice of Stan Alcorn. What a co-inky-dink!

I’ve been puttin together the website for this year’s dConstruct and I reckon it’s in a decent enough shape to ship, so without further ado, I present to you…

dConstruct 2014 — Living With The Network

Here’s what you need to know:

1. dConstruct 2014 takes place on September 5th in the Brighton Dome.
2. Tickets will cost £150+VAT.
3. Tickets go on sale at 11am on May 19th.
4. It will be bloody brilliant.

To clarify that last point, it will be bloody brilliant because of the people who will be speaking. Like, ooh, I don’t know …Warren Fucking Ellis!

Mandy Brown!, Aaron Straup Cope!, Clare Reddington!, Tom Scott!, Leila Johnston!, Brian Suda!…

I’m ludicrously excited about the line-up for this year’s event, and what’s on the website isn’t even the full roster; there’s more to come. But I can’t contain my excitement any longer and I just have to share this with everyone.

Now, you may not recognise every name on the line-up. Heck, you may not recognise any the names on the line-up. But if you were at dConstruct last year (or the year before) than I hope I’ve earned your trust. And trust me, this is going to be a fantastic day.

So put Monday, May 19th in your calendar so you can grab your ticket when they go on sale (don’t worry—there’s plenty to go around). And put Friday, September 5th in your calendar and I’ll see in the Brighton Dome for the event of the year.^*

^*Not hyperbole

Cennydd’s latest piece in A List Apart is the beautifully written Letter to a Junior Designer.

I really like the way that Cennydd emphasises the importance of being able to explain the reasoning behind your design decisions:

If you haven’t already, sometime in your career you’ll meet an awkward sonofabitch who wants to know why every pixel is where you put it. You should be able to articulate an answer for that person—yes, for every pixel.

That reminds me of something I read fourteen(!) years ago that’s always stayed with me. In an interview in Digital Web magazine, Joshua Davis was asked “What would you say is beauty in design?” His answer:

Being able to justify every pixel.

Here’s a link to the direct quote …except that link probably won’t work for you. Not unless you’ve installed this Chrome extension.

What the hell am I talking about? Well, this is something that Kevin Marks has been working on following on from the recent W3C annotation workshop.

It’s called fragmentions and it builds on the work done by Eric and Simon. They proposed using CSS selectors as fragment identifiers. Kevin’s idea is to use the words within the text as anchor points (like an automatic Command+F):

To tell these apart from an id link, I suggest using a double hash - ## for the fragment, and then words that identify the text. For example:

http://epeus.blogspot.com/2003_02_01_archive.html##annotate+the+web

That link will work in your browser because of this script, which Kevin has added to his site. I may well add that script to this site too.

Fragmentions are a nice idea and—to bring it back to Cennydd’s point—nicely explained.

Many people are—quite rightly, in my opinion—upset about the prospect of DRM landing in the W3C HTML specification at the behest of media companies like Netflix and the MPAA.

This would mean that a web browser would have to include support for the plugin-like architecture of Encrypted Media Extensions if they want to claim standards compliance.

A common rebuttal to any concerns about this is that any such concerns are hypocritical. After all, we’re quite happy to use other technologies—Apple TV, Silverlight, etc.—that have DRM baked in.

I think that this rebuttal is a crock of shit.

It is precisely because other technologies are locked down that it’s important to keep the web open.

I own an Apple TV. I use it to watch Netflix. So I’m using DRM-encumbered technologies all the time. But I will fight tooth and nail to keep DRM out of web browsers. That’s not hypocrisy. That’s a quarantine measure.

Stuart summarises the current situation nicely:

From what I’ve seen, this is a discussion of pragmatism: given that DRM exists and movies use it and people want movies, is it a good idea to integrate DRM movie playback more tightly with the web?

His conclusion perfectly encapsulates why I watch Netflix on my Apple TV and I don’t want DRM on the web:

The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?

As an addendum, I heard a similar “you’re being a hypocrite” argument when I raised security concerns about EME at the last TAG meetup in London:

I tried to steer things away from the ethical questions and back to the technical side of things by voicing my concerns with the security model of EME. Reading the excellent description by Henri, sentences like this should give you the heebie-jeebies:

Neither the browser nor the JavaScript program understand the bytes.

Alex told me that my phone already runs code that I cannot inspect and does things that I have no control over. So hey, what does it matter if my web browser does the same thing, right?

I’m reminded of something that Anne wrote four years ago when a vulnerability was discovered that affected Flash, Java, and web browsers:

We have higher standards for browsers.

Flickr Commons is a wonderful thing. That’s why I’m concerned:

Y’know, I’m worried about what will happen to my own photos when Flickr inevitably goes down the tubes (there are still some good people there fighting the good fight, but they’re in the minority and they’re battling against the douchiest of Silicon Valley managerial types who have been brought in to increase “engagement” by stripping away everything that makes Flickr special) …but what really worries me is what’s going to happen to Flickr Commons. It’s an unbelievably important and valuable resource.

The Brooklyn Museum is taking pre-emptive measures:

As of today, we have left Flickr (including The Commons).

Unfortunately, they didn’t just leave their Flickr collection; they razed it to the ground. All those links, all those comments, and all those annotations have been wiped out.

They’ve moved their images over to Wikimedia Commons …for now. It turns out that they have a very cavalier attitude towards online storage (a worrying trait for a museum). They’re jumping out of the frying pan of Flickr and into the fire of Tumblr:

In the past few months, we’ve been testing Tumblr and it’s been a much better channel for this type of content.

Audio and video is being moved around to where the eyeballs and earholes currently are:

We have left iTunesU in favor of sharing content via YouTube and SoundCloud.

I find this quite disturbing. A museum should be exactly the kind of institution that should be taking a thoughtful, considered approach to how it stores content online. Digital preservation should be at the heart of its activities. Instead, it takes a back seat to chasing the fleeting thrill of “engagement.”

Leaving Flickr Commons could have been the perfect opportunity to invest in long-term self-hosting. Instead they’re abandoning the Titanic by hitching a ride on the Hindenberg.

There’ll be another Connections event this month, following on from the excellent inaugural humdinger. Save the date: Wednesday, April 23rd at 7pm in the delightful surroundings of 68 Middle Street.

There’s one obvious connection between the two speakers this time ‘round: their first names are homophones.

We’ve got Leigh Taylor of Medium and Gravita fame. He’ll be talking about this holacracy stuff that people have been banging on about lately, and what it takes to actually make a creative company work in a decentralised way.

We’ve also got Lee Bryant, an ol’ pal of mine from way back who recently launched POST*SHIFT. He too will be talking about flexible organisational structures.

Should be good brain-tickling fun. You can secure your place at the event now. It’s free. But the usual warning applies: if you can’t make it, be sure to cancel your ticket—if you book a place and then don’t show up, you will be persona non grata for any future Connections.

See you in two weeks time.