Tags: a

12250

sparkline

Thursday, November 21st, 2019

Rams

I’ve made a few trips to Germany recently. I was in Berlin last week for the always-excellent Beyond Tellerrand. Marc did a terrific job of curating an entertaining and thought-provoking line-up of speakers. He also made sure that those speakers—myself included—were very well taken care of.

I was also in Frankfurt last month. It was for an event, but for once, it wasn’t an event that involved me in any way. Jessica was there for the Frankfurt Book Fair. I was tagging along for the ride.

While Jessica was out at the sprawling exhibition hall on the edge of town, I was exploring downtown Frankfurt. One lunch time, I found myself wandering around the town’s charming indoor market hall.

While I was perusing the sausages on display, I noticed an older gentleman also inspecting the meat wares. He looked familiar. That’s when the part of my brain responsible for facial recognition said “That’s Dieter Rams.” A more rational part of my brain said “It can’t be!”, but it seemed that my pattern matching was indeed correct.

As he began to walk away, the more impulsive part of my brain shouted “Say something!”, and before my calmer nature could intervene, I was opening my mouth to speak.

I think I would’ve been tongue-tied enough introducing myself to someone of Dieter Rams’s legendary stature, but it was compounded by having to do it in a second language.

Entschulding Sie!”, I said (“Excuse me”). “Sind Sie Dieter Rams?” (“Are you Dieter Rams?”)

“Ja, bin ich”, he said (“Yes, I am”).

At this point, my brain realised that it had nothing further planned and it left me to my own devices. I stumbled through a sentence saying something about what a pleasure it was to see him. I might have even said something stupid along the lines of “I’m a web designer!”

Anyway, he smiled politely as I made an idiot of myself, and then I said goodbye, reiterating that it was a real treat for me to meet him.

After I walked outside, I began questioning reality. Did that really just happen? It felt utterly surreal.

Of course afterwards I thought of all the things I could’ve said. L’esprit de l’escalier. Or as the Germans put it, Treppenwitz.

I could’ve told him that I collect design principles, of which his are probably the most well-known.

I could’ve told him about the time that Clearleft went on a field trip to the Design Museum in London to see an exhibition of his work, and how annoyed I was by the signs saying “Do Not Touch” …in front of household objects that were literally designed to be touched!

I could’ve told him how much I enjoyed the documentary that Gary Hustwit made about him.

But I didn’t say any of those things. I just spouted some inanity, like the starstruck fanboy I am.

There’ll be a lunchtime showing of the Rams documentary at An Event Apart in San Francisco, where I’ll be speaking in a few weeks. Now I wonder if rewatching it is just going to make me cringe as I’m reminded of my encounter in Frankfurt.

But I’m still glad I said something.

Request with Intent: Caching Strategies in the Age of PWAs – A List Apart

Aaron outlines some sensible strategies for serving up images, including using the Cache API from your service worker script.

A Non-Business Case for Supporting Old Browsers « Texte | ovl – code & design

Supporting Internet Explorer 11 doesn’t mean you need to give it the same experience as a modern browser:

Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.

And to be honest, there is no reason to not enable this everywhere. Same for form submissions. Make it boring. Make it solid. And sprinkle delight on it.

Good Enough | Max Böck - Frontend Web Developer

I know the anxiety of sharing something with the world. I know there is a pressure to match the quality we see elsewhere on the web. But maybe we should stop trying to live up to somebody else’s standards and focus on just getting stuff out there instead. Maybe our “imperfect” things are already helpful to someone. Maybe this shouldn’t be so hard.

Surveillance giants: How the business model of Google and Facebook threatens human rights | Amnesty International

Amnesty International have released a PDF report on the out-of-control surveillance perpetrated by Google and Facebook:

Google and Facebook’s platforms come at a systemic cost. The companies’ surveillance-based business model forces people to make a Faustian bargain, whereby they are only able to enjoy their human rights online by submitting to a system predicated on human rights abuse. Firstly, an assault on the right to privacy on an unprecedented scale, and then a series of knock-on effects that pose a serious risk to a range of other rights, from freedom of expression and opinion, to freedom of thought and the right to non-discrimination.

However…

This page on the Amnesty International website has six tracking scripts. Also, consent to accept tracking cookies is assumed (check dev tools). It looks like you can reject marketing cookies, but I tried that without any success.

The stone PDF has been thrown from a very badly-performing glass house.

Frank Chimero Redesign Blog: The Popeye Moment

Frank is redesigning in the open. Watch this space:

By writing about it, it may help both of us. I can further develop my methods by navigating the friction of explaining them. I’ve been looking for a way to clarify and share my thoughts about typography and layout on screens, and this seems like a good chance to do so. And you? Well, perhaps the site can offer a clearly explained way of working that’s worth considering. That seems to be a rare thing on the web these days.

Replying to

I would say Falcor from Neverending Story, the big flying dog.

I would say Falcor from Neverending Story, the big flying dog.

Wednesday, November 20th, 2019

Build your own React

This is a fascinating way to present a code tutorial! It reminds of Tim’s Tutorial Markdown that I linked to a while back (which in turn reminds me of Bret Victor’s work).

2019 End-of-Year Thoughts Archives | CSS-Tricks

I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.

There are optimistic hopeful thoughts from Sam and from Ire:

Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.

And I like this zinger from Geoff:

HTML, CSS, and JavaScript: it’s still the best cocktail in town.

Then there are more cautious prognostications from Dave and from Robin:

The true beauty of web design is that you can pick up HTML, CSS, and the basics of JavaScript within a dedicated week or two. But over the past year, I’ve come to the conclusion that building a truly great website doesn’t require much skill and it certainly doesn’t require years to figure out how to perform the coding equivalent of a backflip.

What you need to build a great website is restraint.

Tuesday, November 19th, 2019

Mental models

I’ve found that the older I get, the less I care about looking stupid. This is remarkably freeing. I no longer have any hesitancy about raising my hand in a meeting to ask “What’s that acronym you just mentioned?” This sometimes has the added benefit of clarifying something for others in the room who might have been to shy to ask.

I remember a few years back being really confused about npm. Fortunately, someone who was working at npm at the time came to Brighton for FFConf, so I asked them to explain it to me.

As I understood it, npm was intended to be used for managing packages of code for Node. Wasn’t it actually called “Node Package Manager” at one point, or did I imagine that?

Anyway, the mental model I had of npm was: npm is to Node as PEAR is to PHP. A central repository of open source code projects that you could easily add to your codebase …for your server-side code.

But then I saw people talking about using npm to manage client-side JavaScript. That really confused me. That’s why I was asking for clarification.

It turns out that my confusion was somewhat warranted. The npm project had indeed started life as a repo for server-side code but had since expanded to encompass client-side code too.

I understand how it happened, but it confirmed a worrying trend I had noticed. Developers were writing front-end code as though it were back-end code.

On the one hand, that makes total sense when you consider that the code is literally in the same programming language: JavaScript.

On the other hand, it makes no sense at all! If your code’s run-time is on the server, then the size of the codebase doesn’t matter that much. Whether it’s hundreds or thousands of lines of code, the execution happens more or less independentally of the network. But that’s not how front-end development works. Every byte matters. The more code you write that needs to be executed on the user’s device, the worse the experience is for that user. You need to limit how much you’re using the network. That means leaning on what the browser gives you by default (that’s your run-time environment) and keeping your code as lean as possible.

Dave echoes my concerns in his end-of-the-year piece called The Kind of Development I Like:

I now think about npm and wonder if it’s somewhat responsible for some of the pain points of modern web development today. Fact is, npm is a server-side technology that we’ve co-opted on the client and I think we’re feeling those repercussions in the browser.

Writing back-end and writing front-end code require very different approaches, in my opinion. But those differences have been erased in “modern” JavaScript.

The Unix Philosophy encourages us to write small micro libraries that do one thing and do it well. The Node.js Ecosystem did this in spades. This works great on the server where importing a small file has a very small cost. On the client, however, this has enormous costs.

In a funny way, this situation reminds me of something I saw happening over twenty years ago. Print designers were starting to do web design. They had a wealth of experience and knowledge around colour theory, typography, hierarchy and contrast. That was all very valuable to bring to the world of the web. But the web also has fundamental differences to print design. In print, you can use as many typefaces as you want, whereas on the web, to this day, you need to be judicious in the range of fonts you use. But in print, you might have to limit your colour palette for cost reasons (depending on the printing process), whereas on the web, colours are basically free. And then there’s the biggest difference of all: working within known dimensions of a fixed page in print compared to working within the unknowable dimensions of flexible viewports on the web.

Fast forward to today and we’ve got a lot of Computer Science graduates moving into front-end development. They’re bringing with them a treasure trove of experience in writing robust scalable code. But web browsers aren’t like web servers. If your back-end code is getting so big that it’s starting to run noticably slowly, you can throw more computing power at it by scaling up your server. That’s not an option on the front-end where you don’t really have one run-time environment—your end users have their own run-time environment with its own constraints around computing power and network connectivity.

That’s a very, very challenging world to get your head around. The safer option is to stick to the mental model you’re familiar with, whether you’re a print designer or a Computer Science graduate. But that does a disservice to end users who are relying on you to deliver a good experience on the World Wide Web.

paulirish/lite-youtube-embed: A faster youtube embed.

A very handy web component from Paul—this works exactly like a regular YouTube embed, but is much more performant.

Modest JS Works | You were never sold on heavy-handed JavaScript approaches. Here’s a case for keeping your JS modest.

The fat JavaScript stacks-du-jour have a lot of appeal. They promise you to be able to do more with less. But what if I want to do less?

This is a terrific little (free!) online book all about modest JavaScript. The second part has practical code, but it’s the first part—all about the principles of staying lean—that really resonates with me.

Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.

The GitHub Archive Program will safely store every public GitHub repo for 1,000 years in the Arctic World Archive in Svalbard, Norway.

This is a fascinating project from Github, the Long Now Foundation, the Internet Archive, the Bodleian Library and others. All of the public code on Github on February 2nd, 2020 will be archived for 1000 years in a vault in Svalbard.

Mind you, given the amount of dependencies that most “modern” code projects rely on, I can’t foresee the code working after 1000 days.

Sunday, November 17th, 2019

2019-11-17 – florian.photo

These are great photos of the speakers at Beyond Tellerrand—great captures of Sharon, Cassie, and Charlotte.

The Web We’ve Made

Let us not overlook the fact that a semantic HTML web site is inherently accessible by default. When we bend the web to our will, we break that. So we have a responsibility to correct it. Sure the new technologies are neat, but the end result is usually garbage. This all requires some next-level narcissism that our goals and priorities as developers are far more important than that of the audience we’re theoretically building software to serve.

Firefox’s fight for the future of the web | Technology | The Guardian

A good overview of the unfair playing field of web browsers, dominated by the monopolistic practices by Google and Apple.

Mozilla is no longer fighting for market share of its browser: it is fighting for the future of the web.

A Web Developers New Working Week

I think these are great habit-forming ideas for any web designer or developer: a day without using your mouse; a day with your display set to grayscale; a day spent using a different web browser; a day with your internet connection throttled. I’m going to try these!

Responsible JavaScript: Part III – A List Apart

This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.

Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.

But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.

Picture 1 Picture 2 Picture 3

The Kubrickian interior of Tempelhof.

Picture 1 Picture 2 Picture 3

The Ballardian exterior of Tempelhof.