Visualising the wiki holes you fall down with Pilgrim

I just came across Pilgrim, an interesting web thing that converts pages inrto a more readable, ad-free version of their form self, but also visualises the links you click to get an map out where you end up going as you look through it.

I’m finding these tools, and ones like hypothesis, and Pockets’ recent experiments in highlighting text in their app interesting lately.

Not sure what I’ll do it, but who knows, maybe it’ll be useful to refer back to it in future.

How much CO2 does an office worker generate per year?

I just posted this to friends on Facebook, and it seems a good idea to share it here too, to help with my search:
Hello internet friends. Would a kind soul be able to help me out here?
I’m doing a recorded 20 minute talk in Feb about the environmental impact of building digital products for a free online conference,, and I’m looking for leads to work out a number I want to refer to in the talk.
I’m after a single number, for the average carbon footprint of a single office worker, working in an office, full time, including their commute, in terms of tonnes of CO2 per year.
I know commutes vary wildly, and that’s fine. For this, an average will suffice, as I’m not pretending this will be accurate, just a ballpark figure.
I think I’ll mainly be speaking to an audience based in the US, or Europe, based on last year’s viewer figures, so extra points if the number applies to those regions.
I know this figure won’t be precise, and I’m aware there are loads of factors that affect this anyway. To the nearest tonne is probably okay.
If it helps, please think of this as a number for all those other places that aren’t where you work. I appreciate your office might be super green and virtuous and you’d love to tell everyone about how much you recycle, and how you’re going to eco-heaven, and how everyone is else is terrible but for the purposes of this request I don’t think it will add to the conversation here.
Sorry about sounding grumpy in that last para. I’ll be super grateful and give you a shout out in the talk if you can find it.
Thanks y’all ❤

Recap – storing state in a browser for users

I’ve been working on some static sites recently, and I needed to show some content to someone, but allow it to be dismissed easily, and then stay dismissed. This is much a note to future me as anyone else, but hopefully it’ll be helpful to some other soul on the net.

Doing this with frameworks like django or rails

When I’m working with a full dynamic site, how you do this is usually hidden from you using a handy data structure in the language that your framework is written in.

For example, in django you often have a handy session object available, which works like a dictionary you can get and set data on. Let’s say you have a blog, and you want to set some state on the user, to mark that they’ve commented on on a post you’ve written.

In some view code handling a get request, you might set a value on the session like so:

request.session['has_commented'] = True

Then, later on you could check for this by calling get on the session object:

if request.session.get('has_commented', False):
        return HttpResponse("You've already commented.")

Python also has a native cookie library that does a similar job, of storing state on a client browser, and sparing you the gory details.

This is very handy, but when when you’re working with a static site, you don’t have the server there to wrap all of it in some tasty syntactic sugar.

If like me, you’ve had it abstracted away from you most of the time, it might be useful to know your options.

Your options if you need to do it yourself

If you want to keep data on the client

Right now, if you want to store state just on the client you have two popular options: local storage, and session storage. In both cases you use javascript to write values, with an api that looks a bit like so:

// Save data to sessionStorage
sessionStorage.setItem('key', 'value');

// Get saved data from sessionStorage
var data = sessionStorage.getItem('key');

The main difference between localstorage and session storage is that session storage is automatically expired at the when you close a tab. By comparison, local storage persists, so you can visit a page, set some data, close it, and assuming you haven’t set a super short expiry date, access it again the following day  from the same browser.

You can’t access this from a server though it never leaves the browser.

If you want to be able to access the data on the server

If you do want data to persist for more than one session, and you want to be able to read this information on the server side (like the example the django example above), then cookies are a better fit. They work at the HTTP level, so they’re really sent as extra headers when you send HTTP requests to a server somewhere. Mozilla’s docs are fantastic if you want to learn more about what’s really happening under the hood.

You might want to have a similar API to the session and local storage APIs, to keep them easy to remember, so you can use javasscript to set data on a user’s client browser like so:

// set a value as cookie
docCookies.setItem(name, value)

// get saved value from the cookies

If you want this, then you want to look at the nice cookies.js library, that wraps it up in some nice synatactic sugar, and save you remember esoteric invokations, just to set some basic data on a client.

Just remember, you can’t set much data with cookies compared local storage or session storage.

Obviously if you’re sending data back and forth between a browser and server, there are privacy implications and in the EU, you should to inform users how you’re using cookies, to get consent before you start tracking your users. Again the MDN docs are a good concise starting point, if you need a reminder.



Super hand tip – search your own tabs in Firefox

If you’re like me. You have too many tabs open. So many in fact that you might open the same tab multiple times because you forgot when you last opened it.

Firefox tab search is your friend

When using Firefox, there’s a hidden feature which I only found out about last week. You can restrict to search to your own open tabs. This avoids you opening the same site multiple times because

Try hitting cmd+L (or ctrl l on linux, I guess) as usual, to start entering a new url to visit.

But first add a percent symbol, add a space then start typing. Firefox will show a list open  tabs that match the text you’re typing:

Screen Shot 2018-01-08 at 21.36.30

Not bad eh?

One day every browser will have this.

Till then, it’s nice that firefox is free.

Update: it turns out there are even more nice things here. It turns out that there are a whole raft of different searches you can carry out with the mozilla awesome bar thing, to only search your favourites, only in your browsing history and so on. I found this out from Antony Ricaud’s tweet below after Simon picked up on my own tweet when I discovered this nifty little feature.


Book review: Time is Money – The business Value of Web Performance

Since discovering how significant the  energy impact of moving data over networks is for the Planet Friendly Web Guide, I’ve found myself reading more and more about web performance optimisation (WPO). Last week I ordered Tammy Evert’s book, Time is Money – the Business Value of Web Performance. It arrived on Saturday morning, and I had finished it by the afternoon. Here’s a quick review.

TLDR: I really like it. It’s a short book to give you ammo to help win arguments about web performance, in a language product managers and other people who don’t code will understand.

You might be able to explain what you would do if you had the time and budget to work on performance on a site or app you’re responsible for. This book help you explain why someone should allocate the time and budget to let you make it happen.

Longer version: I really like it. It does what a published book does well, compared to a blog post or website, which is provide a concise argument, in ways that hopefully won’t feel dated within months of being published, and save you sifting through the entire internet to find the information to arrive at the similar conclusion yourself.

How we perceive performance

It begins with a brief primer on why speed and responsiveness (in the HCI, not mobile friendly sense) feel intuitively right, and how regardless of technology, there are a few universal laws around how quickly an application ought to respond, to user input to allow them to feel productive and maintain a state of flow. When I say universal, it might as well be she references literature from as far back as 60’s,on human computer interaction.

Why a business would care about performance

The next section presents a useful way to think about speed, in ways that a business or project sponsor will otherwise be able to understand – if you’ve ever read about WPO, you’ll probably be familiar with the familiar quotes about speed increasing conversion rates in e-commerce. But Tammy presents few other ways to sell it, from benchmarking against competitors with various monitoring tools, to brand perception, where the people would respond to the same sites, with the same copy, and same design, but see the all of them as lower quality when when presented over a slower connection, to comparing the impact of slow sites of the impact of downtime on a business.

I had never thought of selling it in this way, but it’s a really elegant way to think about it – and it’s totally compatible with how we might reasonably think about risk in business.

You might think about risk in these terms:

risk = severity of consequences x likelihood of it happening

Some risks have severe consequences. Having a site go down for example, means it can’t raise donations, complete purchases, or find the information they need. It (hopefully) doesn’t happen very often, but because it’s so severe, we dedicate resources to avoiding downtime, like on-call rotas, building redundancy into our systems and so on.

While a slow site may not be as dramatic as a site going down, degrading performance to the point that people stop using it, or go to a competitor has similar effect – it stops making money, or letting people meet their needs. And worse, a slow site is not a one-off event – if it’s continually happening, then the cumulative effect of users abandoning tasks over a longer period can be greater than a more dramatic, but shorter period of downtime.

This section, introduced me to a catchy term, the performance poverty line – the slower site is, the more conversions tend to drop off, until, at around 6 seconds, they’re barely even happen compared to further up the scale.

If you don’t work in e-commerce, but if you work in an organisation where you have internal customers, the chapter following it shows how to think about it in terms of productivity gains, from sites working properly, or reduced bills on infrastructure.

The how of performance

I’ll say again – this is not a technical book, but the book does provide a good grounding on the principles of performance – the differences between latency and bandwidth, and how different parts of the infrastructure of the net affect performance, and what things like a content delivery network are and why they matter, and the different kinds of monitoring available these days  – synthetic and real user monitoring (RUM) performance measurement . This section is very accessible – if someone knows what HTML is, then they should be able to get through it easily, while still covering a lot of ground.

There’s some useful guidance on how you might target your performance efforts too, like which parts of a user journey tend to make the most sense to optimize first to see results.

The future of performance

The book rounds off with a few words about the future. There are a few new APIs in browsers to make measuring performance in terms that are more useful to us than simply tracking how long an entire page took to load, and it covers those, and there’s some further thoughts what where the function of tracking performance fits in an organisation.

Before I read this book, I hadn’t really heard of a role called a digital performance manager, and from what I read, it feels like a cross between a very focused product manager, and the kind of data scientist who gets their kicks from running analysis on the HTTP Archive with Big Query (as an aside, this sounds quite fun – I’d love to hear if this actually is your job).

Who should buy this book

It feels like there are two clear audiences for this book:

  1. People into WPO who want to know how to sell it to others.
  2. People the first group would like to sell it to

People into WPO who want to know how to sell it to others. If this is you and you’re working in a job where you want to start doing this, then it’ll probably cost you as much in billable time to read this review, go to amazon, read some more reviews and buy the book, as the book itself costs to buy, and start making a case at work. What are you waiting for?

The other audience, seems to be the people who the first group would want to give this book to – either because someone has given it to them to read, to understand what they’re continually going on about, or because they don’t code, but think there might be something in this performance thing. It feels like this is the real audience for the book, and the writing is light, and easy to read quickly for this reason.

If you don’t code as primary way of making money, but you work with developers, it’s a good complement to the following short books, for understanding other aspects of working on or managing a digital product:

  1. Erin Kissane’s Elements of Content Strategy, (for content strategy and UX)
  2. Jimmy Janlen’s Toolbox for the Agile Coach (for sharing and planning agile work better in co-located environments)
  3. Kathy Sierra’s Badass (making users feel productive and effective when using your products).

In case you forgot – I really like it.








Sporadic video recommendation # 3 – Yulia Startsev, on side effects, promise and generators in javascript

I’ve been trying to get back up to speed again with javascript recently, and with all the new features being added each year, I’m starting to like it much more than I did before. Try as I might, though I hadn’t really got my head around how to use generators, or when they might be useful.

After seeing this talk here by Yulia Startsev, it’s making a lot more sense – the talk gives some useful background on how the nicer new async/await syntactic sugar is made possible with generators and gives some nice background on how the new Firefox debugger is built and works.

It’s not short (45 minutes), but if like me, you’ve been feeling a bit shaky about some of the new Promise and generator synatx in newer javascript, it’s a worth a look.


This is not news but Mozilla’s Developer Docs site is fantastic

I recently was trying to debug why some snazzy passwordless sign-in flow wasn’t working on Firefox for me, when it worked just fine on Chrome, and investigation lead to me reading up on CORS (Cross Origin Resource Sharing), a way to share access to resources (like images, js files and so on) across domains.

I’m really impressed by the writing, and something I thought I knew, I came away learning loads more about.

Good stuff.