Jeremy Keith's Blog, page 71

Expectations

I noticed something interesting recently about how I browse the web.

It used to be that I would notice if a site were responsive. Or, before responsive web design was a thing, I would notice if a site was built with a fluid layout. It was worthy of remark, because it was exceptional���the default was fixed-width layouts.

But now, that has flipped completely around. Now I notice if a site isn���t responsive. It feels ���broken. It���s like coming across an embedded map that isn���t a slippy map. My expectations have reversed.

That���s kind of amazing. If you had told me ten years ago that liquid layouts and media queries would become standard practice on the web, I would���ve found it very hard to believe. I spent the first decade of this century ranting in the wilderness about how the web was a flexible medium, but I felt like the laughable guy on the street corner with an apocalyptic sandwich board. Well, who���s laughing now���

Anyway, I think it���s worth stepping back every now and then and taking stock of how far we���ve come. Mind you, in terms of web performance, the trend has unfortunately been in the wrong direction���big, bloated websites have become the norm. We need to change that.

Now, maybe it���s because I���ve been somewhat obsessed with service workers lately, but I���ve started to notice my expectations around offline behaviour changing recently too. It���s not that I���m surprised when I can���t revisit an article without an internet connection, but I do feel disappointed���like an opportunity has been missed.

I really notice it when I come across little self-contained browser-based games like

Constellations,
Cub���n’Pup, and
Battleship Solitaire.

Those games are great! I particularly love Battleship Solitaire���it has a zen-like addictive quality to it. If I load it up in a browser tab, I can then safely go offline because the whole game is delivered in the initial download. But if I try to navigate to the game while I���m offline, I���m out of luck. That���s a shame. This snack-sized casual games feel like the perfect use-case for working offline (or, even if there is an internet connection, they could still be speedily served up from a cache).

I know that my expectations about offline behaviour aren���t shared by most people. The idea of visiting a site even when there���s no internet connection doesn���t feel normal ���yet.

But perhaps that expectation will change. It���s happened before.

(And if you want to be ready when those expectations change, I���ve written a Going Offline for you.)

AMPstinction

I’ve come to believe that the goal of any good framework should be to make itself unnecessary.

Brian said it explicitly of his PhoneGap project:

The ultimate purpose of PhoneGap is to cease to exist.

That makes total sense, especially if your code is a polyfill���those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.

But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.

jQuery is the classic example of this. There’s very little reason to use jQuery these days because you can accomplish so much with browser-native JavaScript. But the reason why you can accomplish so much without jQuery is because of jQuery. I don’t think we would have querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.

The same process is almost certain to occur with React���it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.

When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:

As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask ���Why can���t our regular pages be this fast?��� By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.

Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.

Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:

In fact, AMP���s evolution has made it a viable solution to build entire websites.

On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories���something else that Google are keen to change).

But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.

If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.

Which, by the way, brings me to one of the most pernicious ideas around Google AMP���positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.

It’s the classic logical fallacy:

Performance! Something must be done!
AMP is something.
Now something has been done.

By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.

I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.

I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.

Document

A little while back, I showed Paul what I was working on with The��G��si��wka��Story. I value his opinion and I really like the Bradshaw’s Guide project that he’s been working on. We’re both in complete agreement with Russell Davies’ call for an internet of unmonetisable enthusiasms. Call them side projects if you like, but for me, these are the things that the World Wide Web excels at.

These unomentisable enthusiasms/side projects are what got me hooked on the web in the first place. Fray.com���back when it was a website for personal stories���was what really made the web click for me. I had seen brochure sites, I had seen e-commerce sites, but it was seeing something built purely for the love of it that caused that lightbulb moment for me.

I told Paul about another site I remembered from that time (we’re talking about the mid-to-late nineties here). It was called Private Art. It was the work of one family, the children of Private Art Pranger who served in World War Two and wrote letters from the front. Without any expectations, I did a quick search, and amazingly, the site is still up!

Yes, it’s got tiled background images, and the framesetted content is in a pop-up window, but it works. The site hasn’t been updated for fifteen years but it works perfectly in a web browser today. That’s kind of amazing. We really shouldn’t take the longevity of our materials for granted. Could you imagine trying to open a word processing document from the late nineties on your computer today? You’d have a bad time.

Working on The G��si��wka Story helped to remind me of some of the things that made me fall in love with the web in the first place. What I wrote about it is equally true of Private Art:

When we talk about documents on the web, we usually use the word ���document��� as a noun. But working on��The��G��si��wka��Story, I came to think of the word ���document��� as a verb.

The World Wide Web is a medium that’s works for quick, short-term lightweight bits of fun and also for long-term, deeper, slower, thoughtful archives of our collective culture.

The web is a many-splendoured thing.

The G��si��wka Story

While I was in Warsaw for a conference last week, I sought out a commerative plaque in a residential neighbourhood. The English translation reads:

On 5th August 1944 ���Zo��ka�����the scouts��� battalion of the ���Rados��aw��� unit Armia Krajowa captured the German concentration camp ���G��si��wka��� and liberated 348 Jewish prisoners, citizens of various European countries, many of whom later fought and fell in the Warsaw Uprising.

I knew about the plaque���and the incredible events it commemorates���thanks to a piece of writing called The G��si��wka Story by Edward Kossoy, a relative of mine.

My ancestral lineage is an unusual mix. I’ve got generations of Irish on my mother’s side, and generations of Eastern European jews on my father’s side.

Edward wasn’t closely related to me. He was my grandfather’s cousin. My father’s father (from whom I got my middle name, Ivan) was driving ambulances in London during the war. Meanwhile his cousin Edward in Poland was trying desperately to get his family out. Separated from his wife and daughter, he was arrested by the Russians in Ukraine and sentenced to hard labour in a gulag. He survived. His wife and child were did not. They were murdered by the nazis during Operation��Harvest Festival.

Edward was a lawyer. He spent the rest of his life fighting for reparations for victims of the Holocaust. He represented tens of thousands of jews, Poles, and Roma. He lived in Tel Aviv, Munich, and finally Geneva. That was where he met the Polish war hero Wac��aw Micuta who first told him about what happened at G��si��wka. What he heard sounded implausible, but when he found G��si��wka survivors among his own clientelle, Edward was able to corrobarate Micuta’s story.

(Micuta, by the way, had much to discuss with Edward’s second wife Sonia. She fought in the Warsaw Ghetto uprising, escaping by being smuggled out in a suitcase.)

As well as being a lawyer, Edward was also an author. In 2004 he wrote The��G��si��wka��Story for the journal Yad Vashem Studies. I came across it in PDF form while I was searching for more details of Edward’s life and legacy. I was completely astonished by what I read���if it were a Hollywood film, you would think it too far-fetched to be true.

I decided to transfer the story into a more durable format. I’ve marked it up, styled it, and published it here:

gesiowka.adactio.com

The subheading of The��G��si��wka��Story is ���A Little Known Page of Jewish Fighting History.��� I certainly think it’s a piece of history that deserves to be more widely known. That’s why I’ve turned it into a web page.

When we talk about documents on the web, we usually use the word “document” as a noun. But working on The��G��si��wka��Story, I came to think of the word “document” as a verb. And I think the web is well-suited to documenting the stories and experiences of our forebears.

Edward died six years ago, just one year shy of a hundred. I never got to meet him in person, which is something I very much regret. But by taking his words and working with them while trying my best to treat them with respect, I’ve come to feel a bit closer to this great man.

This was a little labour of love for me. I hope I did his words justice. And I hope you’ll read The��G��si��wka��Story.

Frustration

I had some problems with my bouzouki recently. Now, I know my bouzouki pretty well. I can navigate the strings and frets to make music. But this was a problem with the pickup under the saddle of the bouzouki’s bridge. So it wasn’t so much a musical problem as it was an electronics problem. I know nothing about electronics.

I found it incredibly frustrating. Not only did I have no idea how to fix the problem, but I also had no idea of the scope of the problem. Would it take five minutes or five days? Who knows? Not me.

My solution to a problem like this is to pay someone else to fix it. Even then I have to go through the process of having the problem explained to me by someone who understands and cares about electronics much more than me. I nod my head and try my best to look like I’m taking it all in, even though the truth is I have no particular desire to get to grips with the inner workings of pickups���I just want to make some music.

That feeling of frustration I get from having wiring issues with a musical instrument is the same feeling I get whenever something goes awry with my web server. I know just enough about servers to be dangerous. When something goes wrong, I feel very out of my depth, and again, I have no idea how long it will take the fix the problem: minutes, hours, days, or weeks.

I had a very bad day yesterday. I wanted to make a small change to the Clearleft website���one extra line of CSS. But the build process for the website is quite convoluted (and clever), automatically pulling in components from the site’s pattern library. Something somewhere in the pipeline went wrong���I still haven’t figured out what���and for a while there, the Clearleft website was down, thanks to me. (Luckily for me, Danielle saved the day …again. I’d be lost without her.)

I was feeling pretty down after that stressful day. I felt like an idiot for not knowing or understanding the wiring beneath the site.

But, on the other hand, considering I was only trying to edit a little bit of CSS, maybe the problem didn’t lie entirely with me.

There’s a principle underlying the architecture of the World Wide Web called The Rule of Least Power. It somewhat counterintuitively states that you should:

choose the least powerful language suitable for a given purpose.

Perhaps, given the relative simplicity of the task I was trying to accomplish, the plumbing was over-engineered. That complexity wouldn’t matter if I could circumvent it, but without the build process, there’s no way to change the markup, CSS, or JavaScript for the site.

Still, most of the time, the build process isn’t a hindrance, it’s a help: concatenation, minification, linting and all that good stuff. Most of my frustration when something in the wiring goes wrong is because of how it makes me feel …just like with the pickup in my bouzouki, or the server powering my website. It’s not just that I find this stuff hard, but that I also feel like it’s stuff I’m supposed to know, rather than stuff I want to know.

On that note…

Last week, Paul wrote about getting to grips with JavaScript. On the very same day, Brad wrote about his struggle to learn React.

I think it’s really, really, really great when people share their frustrations and struggles like this. It’s very reassuring for anyone else out there who’s feeling similarly frustrated who’s worried that the problem lies with them. Also, this kind of confessional feedback is absolute gold dust for anyone looking to write explanations or documentation for JavaScript or React while battling the curse of knowledge. As Paul says:

The challenge now is to remember the pain and anguish I endured, and bare that in mind when helping others find their own path through the knotted weeds of JavaScript.

HTTPS + service worker + web app manifest = progressive web app

I gave a quick talk at the Delta V conference in London last week called Any Site can be a Progressive Web App. I had ten minutes, but frankly I only needed enough time to say the title of the talk because, well, that was also the message.

There’s a common misconception that making a Progressive Web App means creating a Single Page App with an app-shell architecture. But the truth is that literally any website can benefit from the performance boost that results from the combination of HTTPS + Service Worker + Web App Manifest.

See how I define a progressive web app as being HTTPS + service worker + web app manifest? I’ve been doing that for a while. Here’s a post from last year called Progressing the web:

Literally any website can be a progressive web app:

switch over to HTTPS,
add��a JSON manifest file��with your��metacrap, and
add a service worker.

That last step can be tricky if you���re new to service workers, but it���s not unsurmountable. It���s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Later I wrote a post called What is a Progressive Web App? where I compared the definition to responsive web design.

Regardless of the specifics of the��name, what I like about Progressive Web Apps is that they have a clear��definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:

A fluid layout,
Fluid images, and
Media queries.

Likewise, Progressive Web Apps consist of:

HTTPS,
A service worker, and
A Web App Manifest.

There���s more you can do in addition to that (just as there���s plenty more you can do on a responsive site), but the core definition is nice and clear.

But here’s the thing. Outside of the confines of my own website, it’s hard to find that definition anywhere.

On Google’s developer site, their definition uses adjectives like “reliable”, “fast”, and “engaging”. Those are all great adjectives, but more useful to a salesperson than a developer.

Over on the Mozilla Developer Network, their section on progressive web apps states:

Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.��

Hmm …I’m not so sure about that comparison to native apps (and I’m a little disturbed that the URL structure is /Apps/Progressive). So let’s click through to the introduction:

PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features.

Okay. Specific technologies. That’s good to hear. But instead of then listing those specific technologies, we’re given another list of adjectives (discoverable, installable, linkable, etc.). Again, like Google’s chosen adjectives, they’re very nice and desirable, but not exactly useful to someone who wants to get started making a progressive web app. That’s why I like to cut to the chase and say:

You need to be running on HTTPS,
Then you can add a service worker,
And don’t forget to add a web app manifest file.

If you do that, you’ve got a progressive web app. Now, to be fair, there’a lot that I’m leaving out. Your site should be fast. Your site should be responsive (it is, after all, on the web). There’s not much point mucking about with service workers if you haven’t sorted out the basics first. But those three things���HTTPS + service worker + web app manifest���are specifically what distinguishes a progressive web app. You can���and should���have a reliable, fast, engaging website before turning it into a progressive web app.

Jason has been thinking about progressive web apps a lot lately (he should write a book or something), and he said to me:

I agree with you on the three things that comprise a PWA, but as far as I can tell, you���re the first to declare it as such.

I was quite surprised by that. I always assumed that I was repeating the three ingredients of a progressive web app, not defining them. But looking through all the docs out there, Jason might be right. It’s surprising because I assumed it was obvious why those three things comprise a progressive web app���it’s because they’re testable.

Lighthouse, PWA Builder, Sonarwhal and other tools that evaluate your site will measure its progressive web app score based on the three defining factors (HTTPS, service worker, web app manifest). Then there’s Android’s Add to Home Screen prompt. Here finally we get a concrete description of what your site needs to do to pass muster:

Includes a��web app manifest…
Served over��HTTPS��(required for service workers)
Has registered a��service worker��with a��fetch��event handler

(Although, as of this month, Chrome will no longer show the prompt automatically���you also have to write some JavaScript to handle the beforeinstallprompt�� event).

Anyway, if you’re looking to turn your website into a progressive web app, here’s what you need to do (assuming it’s already performant and responsive):

Switch over to HTTPS. Certbot can help you here.
Add a web app manifest.
Add a service worker to your site so that it responds even when there’s no network connection.

That last step might sound like an intimidating prospect, but help is at hand: I wrote Going Offline for exactly this situation.

Unworn Pleasures

I’ve made no secret of my admiration of Jocelyn Bell Burnell, and how Peter Saville’s iconic cover design for Joy Division’s Unknown Pleasures always reminds of her.

There are many, many memetic variations of that design.

I assumed that somebody somewhere at some time must have made a suitable tribute to the discover of those pulses, but I’ve never come across any Jocelyn-themed variation of the Joy Division album art.

So I made my own.

The test order I did just showed up, and it’s looking pretty nice (although be warned that the sizes run small���I ordered a large, and I probably should’ve gone for extra large). If your music/radio-astronomy Venn diagram overlaps like mine, then you too might enjoy being the proud bearer of this wearable tribute to Dame Jocelyn Bell Burnell.

Choosing tools for scaling design

Tools and processes are intertwined. A company or a department or an individual has a way of doing things���that���s the process. They also have software to carry out the process���those are the tools.

Ideally, they should be loosely coupled. You should be able to change your tools without necessarily changing your process. So swapping out, say, one framework or library for another shouldn���t involve fundamentally changing the way you work. Likewise, trying a new way of working shouldn���t require you to use unfamiliar tools.

When it comes to scaling design within organisations, the challenges are almost always around switching processes (well, really it���s about trying to change culture, but that starts with changing processes���any sufficiently advanced process is indistinguishable from culture). All too often, though, I see people getting hung up on the tools.

We need to get more efficient in how we deliver designs ���so let���s switch over to this particular design tool.

We should have a design system ���so let���s get everyone using this particular JavaScript framework.

I understand this desire to shortcut the work of figuring out processes and jump straight to production solutions. For one thing, it allows you to create an easy list of requirements when it comes to recruiting talent: ���Join our company���you must demonstrate experience and proficiency in this tool or that library.���

But when tools and processes become tightly coupled like this, there���s a real danger of stagnation. If a process can be defined as ���the way we do things around here���, that���s not something you want to tie to any particular tool or technology. Otherwise, before you know it, you���re in the frustrating situation of using outdated tools, but you can���t swap them out for newer or better-suited technologies without disrupting everyone���s work.

This is technical debt (although it applies just as much to design). You���re paying a penalty in the present because of a decision that somebody made in the past. The problem isn���t so much with the decision itself, but with the longevity of its effects.

I think it���s important to remember what a tool is: it���s a piece of technology that enables you to work faster or better. You should enjoy using your tools, but you shouldn���t be utterly dependent on any particular one. Otherwise, the tail starts wagging the dog���you are now in service to the tool, instead of the other way around.

Treat your tools like cattle, not pets. Don���t get too attached to any one technology to the detriment of missing out on others.

Mind you, if you constantly tried every single new tool or technology out there, you���d never settle on anything���I���m pretty sure that three new JavaScript frameworks have been released since you started reading this paragraph.

The tools you choose at any particular time should be suited to what you���re trying to accomplish at that time. In other words, you���ve got to figure out what you���re trying to accomplish first (the vision), then figure out how you���re going to accomplish it (the process), and only then figure out which tools are the best fit. If you jump straight to choosing tools, you could end up trying to tighten a screw with a hammer.

Alas, I���ve seen plenty of consultants who conflate strategy with tooling. They���re brought in to solve process problems and, surprise, surprise, the solution always seems to involve purchasing the software that their company sells. I���ve been guilty of this myself: I see an organisation struggling to systemise their design patterns, and I think ���Oh, they should use Fractal!��� ���but that���s jumping the gun. They might be better served with something simpler, or something more complex (I mean, Fractal is very, very flexible but it���s still just one option���there are plenty of other pattern library tools out there).

Once you separate out the tools from the process, there���s an added benefit. Making the right technology choice is no longer a life-or-death decision. You can suck it and see. Try out the technology and see if it works. If it���s working, great! Carry on using it. If it���s not working, that���s okay too. Try something different.

I realise I���m oversimplifying things, but I honestly believe that the real challenge is not choosing the right tools, but figuring out the right process for your team.

Google Duplicitous

I can’t recall the last time I was so creeped out by a technology as I am by Google Duplex���the AI that can make reservations over the phone by pretending to be a human.

I’m not sure what’s disturbing me more: the technology itself, or the excited reaction of tech bros who can’t wait to try it.

Thing is …when these people talk about being excited to try it, I’m pretty sure they are only thinking of trying it as a caller, not a callee. They aren’t imagining that they could possibly be one of the people on the other end of one of those calls.

The visionaries of technology���Douglas Engelbart, J.C.R Licklider���have always recognised the potential for computers to augment humanity, to be bicycles for the mind. I think they would be horrified to see the increasing trend of using humans to augment computers.

Alternative analytics

Contrary to the current consensual hallucination, there are alternatives to Google Analytics.

I haven’t tried Open Web Analytics. It looks a bit geeky, but the nice thing about it is that you can set it up to work with JavaScript or PHP (sort of like Mint, which I miss).

Also on the geeky end, there’s GoAccess which provides an interface onto your server logs. You can view the data in a browser or on the command line. I gave this a go on adactio.com and it all worked just fine.

Matomo was previously called Piwik, and it’s the closest to Google Analytics. Chris Ruppel wrote about using it as a drop-in replacement. I gave it a go on adactio.com and it did indeed collect analytics very nicely …but then I deleted it, because it still felt creepy to have any kind of analytics script at all (neither Huffduffer or The Session have any analytics tracking either).

Fathom isn’t out yet, but it looks interesting:

It will track users on a website, the key actions they are taking, and give you a non-nerdy breakdown of their journey. It���ll do so with user-centric rights and privacy, and without selling, sharing or giving away the data you collect.

I don’t think any of these alternatives offer quite the same ease-of-use that you’d get from Google Analytics. But I also don’t think that should be your highest priority. There’s a fundamental difference between doing your own analytics (self-hosted), and outsourcing the job to Google who can then track your site’s visitors across domains.

I was hoping that GDPR would put the squeeze on third-party tracking, but it looks like Google have found a way out. By declaring themselves a data controller (but not a data processor), they pass can pass the buck to the data processors to obtain consent.

If you have Google Analytics on your site, that’s you, that is.