Jun 13, 2020
Developers are your users too
This article first appeared in net magazine in April 2019
Like many people my age (late 30s) I learnt to build websites by viewing the source of sites that I thought looked good. It was this way that I discovered you could use tables to have a page laid out how you fancied, and framesets to persist elements of the page on screen whilst other parts scrolled. I found this form of learning by discovery stuck in my head a whole lot better than being taught by someone.
Thankfully these (tables for layout & framesets) old school, inaccessible, and of-their-time HTML techniques are long gone and the complexity and quality of the websites (or web applications) we build has increased drastically. What does remain though is the ability to view the source of the page you’re viewing.
We’ve seen a burgeoning amount of build tooling, a proliferation of new server-side languages (such as Rust and Go) and the encroachment of Javascript from client to server enabling isomorphic apps. This is all very exciting and I think we can all agree that more choice in ways of building interwebs there are, the better.
But have we gone too far, and lost sight of what has made the web great?
These newer capabilities and higher user expectations, augmented by supercharged evergreen browsers, can make you responsible for lower level tasks. A good example is managing the browser’s state. Previously this was all done for you. You clicked a link, you ended up on another page, you clicked the back button and you went back to that previous page. Now with pushState — or whatever your chosen framework abstracts it to (or tried to handle for you) — you can easily make a mess and have your site clunkily and unintuitively work like a 2000’s DVD menu. And people frequently make this mistake.
I’m not arguing for a return to a world without these massively well-built modern frameworks. They, along with build tooling that’s improved developer workflows, allow slick and useful webapps to be built faster. There is no need to smash the frames in the mills.
My argument is that whilst looking after your ‘normal’ users and groups with disabilities, as you should, it’s also useful to make the tech that’s publically viewable (HTML, CSS, some Javascript) as comprehensible as possible to developers — who are just another class of person using your stuff.
At its worst, and when misused, new technologies also remove the web builder from having to think about other factors that affect the user. It’s incredibly easy to add yet another fancy JavaScript library into the dependencies, but harder to see the effect on a user. The user who isn’t on your unmetered superfast office fibre in a first world country viewing your work on a MacBook Pro with an insane quantity of RAM.
Incoming cliche! With great power comes great responsibility.
The web is a unique open platform built on agreed standards — it’s not controlled by a single company. Content on the web is accessible, addressable, and predictable, which is arguably a few of the reasons why it’s so successful.
Despite being, by its very nature, accessible worldwide — our immature industry has significant problems attracting a diverse range of people to work in it. Needlessly obfuscating the output of our work raises the barrier of entry for newbies and ignores the beauty of the web.
It’s also about fun. Treating the web as “just another compile target” makes it harder for engaged developers to create user stylesheets, browser extensions or data scraping tools that extend what you’ve built. They may be doing this in ways and with tooling that you couldn’t possibly have anticipated — a brilliant way of finding new business, hiring people or just for fun.
