Tags: is



Wednesday, May 18th, 2022


Glenn Davis of Project Cool’s Cool Site Of The Day from waaaay back in the day is writing his online memoirs.

Depending on when you got online, this will either bring back a lot of memories or sound like something from a different century (which technically it is).

Thursday, May 12th, 2022

Changing with the times · Chris Burnell

I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.

Wednesday, May 11th, 2022

Reinventing W3C Governance

To be honest, I’m not all that convinced by Robin’s arguments here about overhauling the governance model at the World Wide Web Consortium (partly because the way he describes the current model sounds pretty okay to me). But I’m very interested in what he has to say in the broader philosophical sense about using values to solve problems:

A value is worth something if it’s there to help you when the rubber hits the road and starts hydroplaning. Sure, you’ll need a handful of high-level lofty values as reminders, if only because there’s always a vocal guy (it’s always a guy) who thinks it’s just outrageous to put people before profits. But mostly you want Values You Can Use.

That might be the best description I’ve come across yet for design principles: values you can use.

When we say that engineering is about trade-offs, we’re saying that engineers solve their hardest problems using values (which they call “heuristics” because everyone’s entitled to be fancy some). In implementing a system, you might need to decide between an option that provides people with the best experience, another that delivers the greatest value to the shareholders, and yet a third one that makes the control centre blinkenlights dance in the prettiest way.

Tuesday, May 10th, 2022

Agile design principles

I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?

If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.

I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s wonderfully practical!

I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And there’s this excellent explanation which could just as well apply to the priorty of constituencies:

That is, while there is value in the items on the right, we value the items on the left more.

Yes! That’s the spirit!

Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).

Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.

Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.

Friday, May 6th, 2022

wrong side of write

An opinionated blog about writing. I’ve subscribed in my feed reader.

Thursday, May 5th, 2022

Notes from a gopher:// site - daverupert.com

The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern: selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.

Why blog? – Chuck Grimmett

Platforms come and go. Buy a domain and set up a permanent space on the web where others to find you and link back to. I have no idea what I put on Myspace back in the day, but everything I’ve published on this site since 2008 is still accessible and the links still work.

A personal website is a digital homestead that you can improve, tinker with, and live in for years to come. It is a home for your thoughts, musings, opinions, trials, and happenings, built in a way that suits you.

I like this little prompt:

What do you wish you had found via Google today but didn’t? Write that.

Tuesday, May 3rd, 2022


A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:

If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.

Recently Jonathan Aldrich posted a thread about the same bug. He included a link to my blog post. He also said:

Thanks so much for your post, this was a truly pernicious problem!

That warms the cockles of my heart. It’s very gratifying to know that documenting the bug (and the fix) helped someone out. Or, as I put it:

Yay for bugblogging!

Forgive the Germanic compound word, but in this case I think it fits.

Bugblogging doesn’t need to involve a solution. Just documenting a bug is a good thing to do. Recently I documented a bug with progressive web apps on iOS. Before that I documented a bug in Facebook Container for Firefox. When I documented some weird behaviour with the Web Share API in Safari on iOS, I wasn’t even sure it was a bug but Tess was pretty sure it was and filed a proper bug report.

I’ve benefited from other people bugblogging. Phil Nash wrote Service workers: beware Safari’s range request. That was exactly what I needed to solve a problem I’d been having. And then that post about Phil solving my problem helped Peter Rukavina solve a similar issue so he wrote Phil Nash and Jeremy Keith Save the Safari Video Playback Day.

Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.

There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.

Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:

All three are very handy tips. Thanks, Eric! Thanks, Rich! Thanks, Stephanie!

City of Women London

City of Women encourages Londoners to take a second glance at places we might once have taken for granted by reimagining the iconic Underground map.

I love everything about this …except that there’s no Rosalind Franklin station.

Sunday, May 1st, 2022

Emily F. Gorcenski: Angelheaded Hipsters Burning for the Ancient Heavenly Connection

Twitter is a chatroom, and the problem that Twitter really solved was the discoverability problem. The internet is a big place, and it is shockingly hard to otherwise find people whose thoughts you want to read more of, whether those thoughts are tweets, articles, or research papers. The thing is, I’m not really sure that Twitter ever realized that this is the problem they solved, that this is where their core value lies. Twitter kept experimenting with algorithms and site layouts and Moments and other features to try to foist more discoverability onto the users without realizing that their users were discovering with the platform quite adeptly already. Twitter kept trying to amplify the signal without understanding that what users needed was better tools to cut down the noise.

Twitter, like many technology companies, fell into the classical trap by thinking that they, the technologists, were the innovators. Technologists today are almost never innovators, but rather plumbers who build pipelines to move ideas in the form of data back and forth with varying efficacy. Users are innovators, and its users that made Twitter unique.

Increasing the surface area of blogging

RSS is kind of an invisible technology. People call RSS dead because you can’t see it. There’s no feed, no login, no analytics. RSS feels subsurface.

But I believe we’re living in a golden age of RSS. Blogging is booming. My feed reader has 280 feeds in it.

RSS - Chris Coyier

How is all this social? It’s just slow social. If you want to respond to me, publish something linking to what I said. If I want to respond to you, I publish something linking to what you wrote. Old school. Good school. It’s high-effort, but I think the required effort is a positive thing for a social network. Forces you to think more.

Saturday, April 30th, 2022

The Technium: 103 Bits of Advice I Wish I Had Known

I’m not usually that keen on lists of pithy aphorisms but some of these really resonated…

  • If you stop to listen to a musician or street performer for more than a minute, you owe them a dollar.
  • Efficiency is highly overrated; Goofing off is highly underrated. Regularly scheduled sabbaths, sabbaticals, vacations, breaks, aimless walks and time off are essential for top performance of any kind. The best work ethic requires a good rest ethic.
  • The biggest lie we tell ourselves is “I dont need to write this down because I will remember it.”
  • Buy used books. They have the same words as the new ones. Also libraries.
  • You can be whatever you want, so be the person who ends meetings early.
  • It’s thrilling to be extremely polite to rude strangers.
Picture 1 Picture 2 Picture 3 Picture 4

Got a good haul of vintage sci-fi classics: Christopher Priest, Brian Aldiss, and Leigh Brackett.

Thursday, April 28th, 2022


I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:

I would love it if someone could explain why they avoid native browser features but use third-party code.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!

Charles Harries takes on my question in his post Libraries over browser features:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.

So again, it’s browser incompatibilities that made libraries attractive.

Jim Nielsen responds with the same message in his post Trusting Browsers:

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.

Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.

I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.

Charles again:

This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.

Jim is glass-half-full kind of guy:

I’m optimistic that trust in browser-native features and APIs is being restored.

He also points to a very sensible mindset when it comes to third-party libraries and frameworks:

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).

I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.

I like Jim’s proposed design princple:

Where available, default to browser-native features over third party code, abstractions, or idioms.

(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)

How to Imagine Climate Futures - Long Now

The best climate fiction can do more than spur us to action to save the world we have — it can help us conceptualize the worlds, both beautiful and dire, that may lie ahead. These stories can be maps to the future, tools for understanding the complex systems that intertwine with the changing climates to come.

Tuesday, April 26th, 2022

Speaking at CSS Day 2022

I’m very excited about speaking at CSS Day this year. My talk is called In And Out Of Style:

It’s an exciting time for CSS! It feels like new features are being added every day. And yet, through it all, CSS has managed to remain an accessible language for anyone making websites. Is this an inevitable part of the design of CSS? Or has CSS been formed by chance? Let’s take a look at the history—and some alternative histories—of the World Wide Web to better understand where we are today. And then, let’s cast our gaze to the future!

Technically, CSS Day won’t be the first outing for this talk but it will be the in-person debut. I had the chance to give the talk online last week at An Event Apart. Giving a talk online isn’t quite the same as speaking on stage, but I got enough feedback from the attendees that I’m feeling confident about giving the talk in Amsterdam. It went down well with the audience at An Event Apart.

If the description has you intrigued, come along to CSS Day to hear the talk in person. And if you like the subject matter, I’ve put together these links to go with the talk…

Blog posts


Proposals (email)

Papers (PDF)

People (Wikipedia)

Tuesday, April 19th, 2022

Upcoming events

I see that Russell is planning to bring back Interesting this year. This makes me happy. Just seeing the return of in-person gatherings—run safely—is giving me life.

I don’t think I’m alone in this. I think that lots of people are yearning for some in-person contact after two years of online events. The good news is that there are some excellent in-person web conferences on the horizon.

Beyond Tellerrand is back in Düsseldorf on May 2nd and 3rd. Marc ran some of the best online events during lockdown with his Stay Curious cafés, but there’s nothing beats the atmosphere of Beyond Tellerrand on its home turf.

If you can’t make it Düsseldorf—I probably can’t because I’m getting my passport renewed right now—there’s All Day Hey in Leeds on May 5th. Harry has put a terrific line-up together for this one-day, very affordable event.

June is shaping up to be a good month for events too. First of all, there’s CSS Day in Amsterdam on June 9th and 10th. I really, really like this event. I’m not just saying that because I’m speaking at this year’s CSS Day. I just love the way that the conference treats CSS with respect. If you self-identigy as a CSS person, then this is the opportunity to be with your people.

But again, if you can’t make it Amsterdam, never fear. The Pixel Pioneers conference returns to Bristol on June 10th. Another one-day event in the UK with a great line-up.

Finally, there’s the big one at the end of June. UX London runs from June 28th to June 30th:

Bringing the UX community back together

Yes, I’m biased because I’m curating the line-up but this is shaping up to be unmissable! It’s going to be so good to gather with our peers and get our brains filled by the finest of design minds.

Monday, April 18th, 2022

Shame. – Dirty Feed

Deleting your old thoughts may be giving your older self a kick they really don’t deserve. And the beauty of having an archive is that you don’t need to decide whether you were right or not. Your views, with a date attached, can stand as a reflection of a specific moment in time.

Reconciling every past view you’ve ever had with how you feel now isn’t required. It sounds exhausting, frankly.

Thursday, April 14th, 2022

A Web Renaissance

Thanks to the mistrust of big tech, the creation of better tools for developers, and the weird and wonderful creativity of ordinary people, we’re seeing an incredibly unlikely comeback: the web is thriving again.

Smart analysis from Anil, though I’m not sure I’d agree with his emphasis on tools and frameworks—it’s the technology built into browsers that has really come along in leaps and bounds, allowing people to do more with less code.

But then there’s this:

So if we have the tech, then why hasn’t it happened already? The biggest thing that may be missing is just awareness of the modern web’s potential. Unlike the Facebooks and Googles of the world, the open, creative web doesn’t have a billion-dollar budget for promoting itself. Years of control from the tech titans has resulted in the conventional wisdom that somehow the web isn’t “enough”, that you have to tie yourself to proprietary platforms if you want to build a big brand or a big business.

True! Anil also points to an act of rebellion and resistance:

Get your own site going, though, and you’ll have a sustainable way of being in control of your own destiny online.