Year end

So, the end of 2019 looms. It’s been a good year in general for me, with continued employment (always a bonus) and important family events happening. I got to visit “our” village in France again for the first time in several years, this time entirely by train.

Looking back on this blog, however, I’m not so happy. I thought it was about this time last year I decided to (try) to go full IndieWeb, but was slightly shocked to see it was January 2018. Where have the last 2 years gone?

Likewise my decision last May to strip this site back to just HTML and ‘design in the open’ resulted in just one thing: someone contacting me to ask if the site was broken. You’ll see there’s a bit more colour and layout implemented now, but a long way to go. And my skills – or rather, lack of skill – as a designer is painfully obvious.

So here’s to 2020. May I find more time to spend on this site, blogging about the many things I’ve been learning. Because, I have to admit it, I really miss the old days when I would blog more.

Designing in the open

It’s been a while since I last redesigned (or should I say, realigned) this site. Six years, in fact. My regular visitor, if they are still regular, will have noticed that this site has been somewhat broked for a week or so.

I’m not sure what I did, but I clearly mangled something. Anyway, it’s an excuse to realign.

This time I have some simple requirements for myself:

  1. Mobile first. The reality is that most browsing is done on a mobile device of some kind, so I want to primarily cater to those constraints. That means mobile-first CSS, Service Workers, small images only where necessary etc etc.
  2. Performance second. Closely related to the mobile thing, good performance is a must. I’m aiming for sub-second render times. I also want to use no JavaScript. This is a content site, why would I need it?
  3. More emphasis on the IndieWeb. I’ve started doing this, by pulling in my tweets. But I want to go much further down that road.

And I’m doing all this in the open, live on the site. I may fail completely, in which case it will be a public humiliation. But maybe it will force me to get on with it!

A Sprinkling of JavaScript

Over the last few months there has been a surge of prominent web people – designers, developers, thinkers – questioning the current obsession with complex “web app” style frameworks. Perhaps this was prompted by Jeffrey Zeldman’s ‘The Cult of the Complex’ article from June 2018, or perhaps this is a natural reaction from people who deeply understand the web.

The ‘backendification of front-end development’ is causing a lot of different questions to be asked. From Bridget questioning the usage of a JavaScript framework to Michelle building a dependency-free site. There are designers learning about semantic HTML and calls to consider limiting JavaScript usage. And reminders to developers that you probably don’t need a single-page application.

The theme perhaps culminates in this instant-classic article by Jeremy Wagner on A List Apart: Responsible JavaScript. This pared-down approach is closely aligned with accessibility – it’s about using the most suitable technology for the job.

Which brings me on to horses. But first, web apps.

What is a ‘web app’? Wikipedia helpfully has a definition – of sorts. But there’s a certain amount of bet-hedging:

The general distinction between a dynamic web page of any kind and a “web application” is unclear.

https://en.wikipedia.org/wiki/Web_application

Which chimes with my experience when I ask peers for a definition. They all but cry “You just need to feel the difference, man!”

After all, it’s not like we’ve not had interactivity in web pages before the advent of the current crop of JavaScript frameworks. Gmail, considered by many the poster-boy for a modern web app, was launched this very day in 2004. Fifteen years ago!

Single horse in a mountain field

So, horses. Back when the early automobile engineers were putting together the first cars, there was a clear distinction between the mode of transport widely used before – the horse – and what they were building. There was no confusion, no perplexed on-lookers asking “is that a horse, or an automobile?” There was a world of difference between the ‘old’ and the ‘new’.

1907 Franklin Model D roadster automobile

A world of difference, but still much the same. The problem that horses and automobiles were solving was, essentially, the same: getting people from point A to point B. But the mechanism – the technology – used to achieve that goal was entirely different.

Not so with ‘web apps’. The technology is pretty much the same as before: HTML, CSS and JavaScript. The application of that technology has a few extra bells and whistles, and there are newer browser APIs we can take advantage of – Service Workers being a prime example. But, essentially, what we build for the web hasn’t changed all that much.

Except it has, or so the framework-fanboys would have you believe. I’ve heard developers talk about the more traditional ways of building websites to be akin to riding a horse, while using a Single Page Application framework is like driving a sports car.

Red sports car on a racing track

I have bad news. A sports car works great in the circumstances for which it was designed. But take it out of its natural environment – take it off the track and onto a mountain pass, for example, and you’re in trouble. For harsh terrain you’ll need a horse, not a sports car.

Riders and horses on a mountain

You see, a horse might not be as quick on a flat race track. It might not have a heads-up 3D display to show you the turns ahead. It probably isn’t equipped with intelligent side impact protection systems. But you know what it does have? The ability to do the job in less-than-ideal conditions.

Because that is how the web is experienced by most people, most of the time. Poor bandwidth, slow latency, underpowered devices – these are the bumps, potholes and rocks in the road which will stop your JavaScript sports car in its tracks.

So, like the luminaries of the web I mentioned above, I add my voice to the growing cry: consider your JavaScript use carefully. You may not need as much of it as you think.

Open letter to Matt Mullenweg

Dear Matt,

I’ve been a long-time user of WordPress, clocking up well over a decade both publishing on and building plugins for it. I love it – and I even tried to get a job at Automattic (but that’s a story for another time).

Recently I’ve been really impressed with the work done around privacy, mostly prompted by GDPR. Well done for ensuring the considerable effort this required was made, and that privacy now has a much more prominent place in WordPress.

However, the trolling of privacy standards which I saw (online) at WPEU this week threatens to undermine a nascent and fragile respect of data privacy. I understand there are cultural differences between the EU and the US regarding personal data, but the WordPress community should – has to – be better than this, in the same way that we should be, and are being, better than to engage in other damaging activities (GamerGate culture, for example).

A possible immediate fall-out of these unhelpful comments was that, while 80 people were registered for Heather’s Developing for Privacy and Data Protection workshop, fewer than 35 showed up. We need *more* designers and developers to care about data protection, so anything that puts them off learning has the potential to be massively damaging to the privacy of thousands, possibly millions, of users their work will touch.

Heather has done amazing work in the UK and beyond for years, banging the drum that as a web industry we must professionalise to be taken seriously by users, legislators, and other industries. She was instrumental in the setting up of an industry body for the web in the UK. A commitment to privacy and data protection is a huge part of professionalising the web industry, in the same way that a commitment to safety is a huge part of a civil engineer’s attitude to their profession. It would be a huge shame to see WordPress further the “we got all your data, lolz suckas!” attitude shown by other big online players (looking at you, Facebook).

Please can you consider whether trolling comments like that help or hinder important work, while you continue to do a great job leading Automattic.

Kind regards, and thanks for all you’ve done for the web community.

Chris Taylor

IndieWeb

In a moment of madness – proved by the spelling mistake – I tweeted that 2018 would be the year I go full IndieWeb.

But what is it? Basically, IndieWeb is a movement of people who want to own their own data, not have it wholly controlled by corporations. So rather than posting updates to Big Corp Social Media Website, you’d post to your own site and syndicate out to other places. If the social media site goes down, goes bust, or goes evil, you still have all your content. After all, you wrote it – it should be yours.

The syndication part is possible thanks to various clever technical bits (Jeremy Keith has a great video explaning of the building blocks of IndieWeb). So you can still participate in social media sites, for example, but still own your own content.

It’s a “have your cake and eat it” situation. And I like cake.

I, over the course of this year I intend to become independent of Twitter, Pocket and GMail. That’s not to say I’ll stop using those services – I find them all valuable – but my data won’t be owned by them. Fortunately all my websites have their own self-hosted CMS systems (mainly WordPress) which makes the job a lot easier.

And who knows, I may find that this IndieWeb thing allows me to start syndicating to new places such as this Mastadon thing I keep hearing about. The choice will be, for the first time, all mine.