Dear Developer, go read “Dear Developer”

I’ve just finished reading through Charlie Owen’s converted-webpage-from-a-talk thing, Dear Developer. It’s funny, friendly and really captures the wonder of the web as a medium to work with. Without picking fights, it steers developers away from a lot of bad practices, and towards ones which are more empathetic, resilient and performant. In this post I share a few gems that stood out.

The web as a resilient technology

If you’ve developer with the web much over the last few years, you can’t help but notice a trend towards pages becoming brittle. I mean this in the sense that if there’s an error in the javascript, or a resource like a javascript file doesn’t load in time, the page is essentially unusable.

She shows a really nice example by using Firefox’s DOM inspector to take a page apart, and have it still work. Here’s the quote below, but the link to the section via hypothesis of the page is here and shows the video:

It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.

Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.

Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.

The pyramid of robustness

I really like the visual device, the Pyramid of Robustness she uses for this too

Pyramid of robustness
Pyramid of robustness

It’s a deft way of presenting the downsides of building assuming javascript is always working, and there being a fast enough connection to download all the resources on a page quickly:

The Pyramid of Robustness, upside down
The Pyramid of Robustness, upside down

There’s a really good visual gag here that made me guffaw in the silent section of the coworking space I was in when I read it first. I won’t spoil it for you.

Getting started with a11y and why it’s important.

There’s a nice part about getting started with accessibility or (a11y) to it’s friends, and how to do this easily on a mac.

You just hit command+f5 to start voice-over, and you can start navigating content the same way someone who is partially sighted, or blind would.

It also covers why it’s important. Accessibility is often mischaracterised as designing for blind people, and as a sighted person, it’s often thought of as the key reason (I’m guilty of this in this section myself).

It’s the right thing to do, but it’s also worth thinking about this in terms of a design being resilient – people can be temporarily disabled when they injure themselves or even when they’re just holding something in one arm, like a bag of shopping or a child. The persona Spectrum from Microsoft is a good example of this.

Screen Shot 2018-04-06 at 16.46.31
Microsoft’s Persona Spectrum for inclusive design

When it’s presented like this, it reframes a11y as not being a question of charity or guilt, but being one of pragmatism and professionalism.

Framing it like this in terms of positive, intrinsic motivation makes it feel more likely to be adopted.

There’s a nice quote from Theo Schlossnagle from Circonus that I feel captures this idea – he uses it in the context of hiring, but it’s stayed with me ever since I heard it:

I don’t want programmers, I want professionals.

If we want to call ourselves software engineers and act like we’re a grown-up profession, then we should hold ourselves to the standards engineers and other professions hold themselves to.

And that means to acknowledge the full range of contexts the products and services we create are used in.

Go take the time to read it

I’m when speaking to people who want to learn to code for the web, I think I’m going to point them to this as a thing to read for understanding why the web is magical.

If you haven’t read it yourself yet, I strongly recommend checking it out.

See? It’s even got a nice short url – go read it now.

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.