Tags: ip

1733

sparkline

Monday, September 26th, 2022

Malleable Systems Collective

Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.

This community catalogs and experiments with malleable software and systems that reset the balance of power via several essential principles…

I’ll be adding those principles to my collection.

Wednesday, September 21st, 2022

Will Serving Real HTML Content Make A Website Faster? Let’s Experiment! - WebPageTest Blog

Spoiler: the answer to the question in the title is a resounding “hell yeah!”

Scott brings receipts.

Monday, September 19th, 2022

Wednesday, September 14th, 2022

The self-fulfilling prophecy of React - Josh Collinsworth blog

Matcalfe’s Law in action:

Companies keep choosing React because they know there’s a massive pool of candidates who know it; candidates keep learning React because they know companies are hiring for it. It’s a self-sustaining cycle.

But the problem is:

React isn’t great at anything except being popular.

Sunday, September 11th, 2022

Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development

We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.

A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:

We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.

Thursday, September 8th, 2022

One day to dConstruct

Just one more sleep until dConstruct—squee!

Not that I anticipate getting much sleep. My sleepnessness will partly be like that of a child on the night before Christmas. But my sleepnessness will also inevitably be that of an adult neurotically worrying about trifling details.

In reality, everything is all set. Thanks to the stellar Clearleft events team, I don’t need to lose any sleep. But my stupid brain can’t help but run a conveyer belt of potential problems through my mind: what about dongles? Power? Timings? What if there’s an impromptu rail strike? A deluge? Other emergencies you can’t even imagine?

I try to ignore those pestering pointless questions and instead think about the fantastic talks we’re going to get. I’m genuinely excited about each and every speaker. I’m pretty sure that once the day begins, I’ll forget all my worries and bliss out to the mind-expanding presentations.

The day before a conference feels kind of like the build-up to a battle. All the strategic decisions have been made, everything is in place, and now there’s nothing to do but wait.

I’ve communicated (or maybe over-communicated) all the relevant details to the speakers. And one week ago I sent one final email to the attendees with details of the schedule and some suggestions for lunch.

I also included this request:

Could you do me a favour? Would you mind getting a hold of a Covid test sometime in the next week and taking a test a day or two before dConstruct? (And if you test positive, please don’t come to the event.)

If you can’t get hold of a test (I know it can be tricky), then could you please bring a mask to wear when inside the venue?

I think asking everyone to take a test is a reasonable request, and nobody has objected to it. I worry that it’s yet another form of hygiene theatre (like providing anti-bacterial handwash for an airborne virus). After all, the antigen tests are most effective when you’ve already got symptoms. Taking a test when you don’t have symptoms might well give a negative result, but it doesn’t necessarily mean you don’t have Covid. Still, it’s a little intervention that might catch an infection that otherwise would’ve spread further.

I’m assuming that everyone coming to dConstruct is vaccinated. Maybe that’s naive on my part, but I figure if you’re intelligent enough to get a dConstruct ticket, you’re intelligent enough to protect yourself and others. So we won’t be requesting proof of vaccination. I hope my naivety aligns with reality.

See, this is all one more thing for my brain to gnaw on when I should be thinking about what a fantastic day of talks I’ve got ahead of me. Roll on tomorrow!

Tuesday, September 6th, 2022

Why your website should work without Javascript. | endtimes.dev

The obvious answer to why you should build a website that doesn’t need js is… because some people don’t use js. But how many?!

Tuesday, August 30th, 2022

ADL Social Pattern Library | Anti hate by design

A collection of design patterns and principles for mitigating the presence and spread of online hate and harassment in social platforms.

Bring Focus to the First Form Field with an Error :: Aaron Gustafson

A handy little script from Aaron to improve the form validation experience.

Wednesday, August 24th, 2022

Lean Web Club

New from Mr. Vanilla JS himself, Chris Ferdinandi:

A learning space for people who hate the complexity of modern web development.

It’ll be $29 a month or $299 a year (giving you two months worth for free).

Thursday, August 18th, 2022

The impact of removing jQuery on our web performance - Inside GOV.UK

Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.

It may sound like 32 kb of JavaScript is nothing on today’s modern web with quick devices and fast broadband connections. But for a certain cohort of users, it makes a big difference to how they experience GOV.UK.

Wednesday, August 17th, 2022

A Matter of Principle

This is an oldie from Julie Zhou, but it’s a timeless message about the value of good (i.e. actually useful) design principles.

See also what she said on this podcast episode:

When push comes to shove and you have to make a trade off, how are you, in those moments, as a team or a company going to prioritize? What are you going to care about the most? Good values will be controversial in that respect because it’s something that another company might have made a different decision than you.

Thursday, August 11th, 2022

How and why we removed jQuery from GOV.UK - Inside GOV.UK

This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!

Removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance.

Monday, July 25th, 2022

Control

In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

  1. a button,
  2. a dropdown, and
  3. a datepicker.

In each case you could use native HTML elements:

  1. button,
  2. select, and
  3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.

Wednesday, July 20th, 2022

Open Lecture at CIID: “Keeping up with the Kardashevians” – Petafloptimism

A terrfic presentation from Matt Jones (with the best talk title ever). Pace layers, seamful design, solarpunk, and more.

Thursday, July 14th, 2022

Food Timeline: food history research service

The history of humanity in food and recipes.

The timeline of this website is equally impressive—it’s been going since 1999!

Tuesday, July 12th, 2022

Stop supporting Internet Explorer!

The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.

When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.

Monday, July 4th, 2022

WWC22 - Design Principles For The Web - YouTube

Here’s the video of the talk I gave in front of an enormous audience at the We Are Developers conference …using a backup slidedeck.

WWC22 - Design Principles For The Web

Thursday, June 30th, 2022

10 Years of Meteor

While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.

Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.

Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:

  1. Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.

Verdict: 👎

It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.

Wednesday, June 29th, 2022

How we think about browsers | The GitHub Blog

JavaScript doesn’t get executed on very old browsers when native syntax for new language features is encountered. However, thanks to GitHub being built following the principle of progressive enhancement, users of older browsers still get to interact with basic features of GitHub, while users with more capable browsers get a faster experience.

That’s the way to do it!

Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.

Read on for the nitty-gritty details…