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:
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.
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?
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!
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 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!
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’.
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.
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.
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.
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’sDeveloping 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.
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.
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.
I’ve been building websites for a long time. Websites of all shapes and sizes, and sometimes for bricks and mortar businesses. My latest website is for a physical place, but this time – it’s MY place! Clara’s Den, a holiday apartment on an award-winning holiday village just south of Filey on the beautiful Yorkshire coast.
