Tags: work

1064

sparkline

Tuesday, September 20th, 2022

Accessibility is systemic

I keep thinking about this blog post I linked to last week by Jacob Kaplan-Moss. It’s called Quality Is Systemic:

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

I think he’s on to something. I also think this applies to design just as much as development. Maybe more so. In design, there’s maybe too much emphasis placed on the talent and skill of individual designers and not enough emphasis placed on creating and nurturing a healthy environment where anyone can contribute to the design process.

Jacob also ties this into hiring:

Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.

I couldn’t agree more! It just one of the reasons why the smart long-term strategy can be to concentrate on nurturing junior designers and developers rather than head-hunting rockstars.

As an aside, if you think that the process of nurturing junior designers and developers is trickier now that we’re working remotely, I highly recommend reading Mandy’s post, Official myths:

Supporting junior staff is work. It’s work whether you’re in an office some or all of the time, and it’s work if Slack is the only office you know. Hauling staff back to the office doesn’t make supporting junior staff easier or even more likely.

Hiring highly experienced designers and developers makes total sense, at least in the short term. But I think the better long-term solution—as outlined by Jacob—is to create (and care for) a system where even inexperienced practitioners will be able to do good work by having the support and access to knowledge that they need.

I was thinking about this last week when Irina very kindly agreed to present a lunch’n’learn for Clearleft all about inclusive design.

She answered a question that had been at the front of my mind: what’s the difference between inclusive design and accessibility?

The way Irina put it, accessibility is focused on implementation. To make a website accessible, you need people with the necessary skills, knowledge and experience.

But inclusive design is about the process and the system that leads to that implementation.

To use that cliché of the double diamond, maybe inclusive design is about “building the right thing” and accessibility is about “building the thing right.”

Or to put it another way, maybe accessibility is about outputs, whereas inclusive design is about inputs. You need both, but maybe we put too much emphasis on the outputs and not enough emphasis on the inputs.

This is what made me think of Jacob’s assertion that quality is systemic.

Imagine someone who’s an expert at accessibility: they know all the details of WCAG and ARIA. Now put that person into an organisation that doesn’t prioritise accessibility. They’re going to have a hard time and they probably won’t be able to be very effective despite all their skills.

Now imagine an organisation that priorities inclusivity. Even if their staff don’t (yet) have the skills and knowledge of an accessibility expert, just having the processes and priorities in place from the start will make it easier for everyone to contribute to a more accessible experience.

It’s possible to make something accessible in the absence of a system that prioritises inclusive design but it will be hard work. Whereas making sure inclusive design is prioritised at an organisational level makes it much more likely that the outputs will be accessible.

Wednesday, September 14th, 2022

Quality Is Systemic - Jacob Kaplan-Moss

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

This talks about development, but I believe it applies equally—if not more—to design.

And this is very insightful:

Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.

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.

Thursday, September 8th, 2022

as days pass by — Farmbound, or how I built an app in 2022

Stuart writes up the process up making a mobile game as a web app—not a native app. The Wordle effect reverberates.

It’s a web app. Works for everyone. And I thought it would be useful to explain why it is, why I think that’s the way to do things, and some of the interesting parts of building an app for everyone to play which is delivered over the web rather than via app stores and downloads.

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.

Tuesday, August 23rd, 2022

Work ethics

If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.

The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).

This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.

Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.

If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.

Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).

They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.

I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.

But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.

We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.

I’d rather spend my time pursuing the opposite: the least work for the most people.

Monday, August 22nd, 2022

The web is a harsh manager - daverupert.com

Dave laments the increasing number of complex jobs involved in front-end (or “full-stack”) development.

But whereas I would just leave at that, Dave does something constructive and points to a potential solution—a corresponding increase of more thinsliced full-time roles like design engineering, front-end ops, and CSS engineering.

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.

Tuesday, August 16th, 2022

The Real Novelty of the ARPANET

Setting the scene:

The Washington Hilton stands near the top of a small rise about a mile and a half northeast of the National Mall. Its two white-painted modern facades sweep out in broad semicircles like the wings of a bird. The New York Times, reporting on the hotel’s completion in 1965, remarked that the building looks “like a sea gull perched on a hilltop nest.”

The hotel hides its most famous feature below ground. Underneath the driveway roundabout is an enormous ovoid event space known as the International Ballroom, which was for many years the largest pillar-less ballroom in DC. In 1967, the Doors played a concert there. In 1968, Jimi Hendrix also played a concert there. In 1972, a somewhat more sedate act took over the ballroom to put on the inaugural International Conference on Computing Communication, where a promising research project known as the ARPANET was demonstrated publicly for the first time.

It turns out that the most important innovation of the ARPANET isn’t obvious in hindsight:

So what I’m trying to drive home here is that there is an important distinction between statement A, “the ARPANET connected people in different locations via computers for the first time,” and statement B, “the ARPANET connected computer systems to each other for the first time.” That might seem like splitting hairs, but statement A elides some illuminating history in a way that statement B does not.

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.

Wednesday, August 3rd, 2022

It’s Time to Build a Progressive Web App. Here’s How – The New Stack

Much as I appreciate the optimism of this evaluation, I don’t hold out much hope that people’s expectations are going to change any time soon:

Indeed, when given a choice, users will opt for the [native] app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.

Nonetheless, this is a level-headed look at what a progressive web app is, mercifully free of hand-waving:

  • App is served through HTTPS.
  • App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
  • App has a registered service worker with a fetch event handler. (More on this later too.)

Tuesday, August 2nd, 2022

Design Engineer / Front-end Developer | Clearleft

Are you a web dev that’s into progressive enhancement, accessibility, design systems, and all that good stuff?

You should come and work with me at Clearleft.

Monday, July 18th, 2022

Fundamentals matter | Go Make Things

I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.

But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:

Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?

That’s not an issue of time. It’s an issue of fundamentals.

I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.

This, basically:

Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.

Tuesday, July 12th, 2022

I don’t care how you web dev; I just need more better web apps – Baldur Bjarnason

The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).

An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.

I’ve experienced this. And I think this observation is even more true when it comes to recruitment.

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.

Tuesday, June 28th, 2022

UX FOMO

Today is the first day of UX London 2022 …and I’m not there. Stoopid Covid.

I’m still testing positive although I’m almost certainly near the end of my infection. But I don’t want to take any chances. Much as I hate to miss out on UX London, I would hate passing this on even more. So my isolation continues.

Chris jumped in at the last minute to do the hosting duties—thanks, Chris!

From the buzz I’m seeing on Twitter, it sounds like everything is going just great without me, which is great to see. Still, I’m experiencing plenty of FOMO—even more than the usual levels of FOMO I’d have when there’s a great conference happening that I’m not at.

To be honest, nearly all of my work on UX London was completed before the event. My number one task was putting the line-up together, and I have to say, I think I nailed it.

If I were there to host the event, it would mostly be for selfish reasons. I’d get a real kick out of introducing each one of the superb speakers. I’d probably get very tedious, repeatedly saying “Oh, you’re going to love this next one!” followed by “Wasn’t that great‽”

But UX London isn’t about me. It’s about the inspiring talks and practical workshops.

I wish I were there to experience it in person but I can still bask in the glow of a job well done, hearing how much people are enjoying the event.

Monday, June 20th, 2022

AddyOsmani.com - Software Engineering - The Soft Parts

Write about what you learn. It pushes you to understand topics better. Sometimes the gaps in your knowledge only become clear when you try explaining things to others. It’s OK if no one reads what you write. You get a lot out of just doing it for you.

Lots of good advice from Addy:

Saying no is better than overcommitting.

The cost of convenience — surma.dev

I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.

Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:

Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.

This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:

If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.

Tuesday, June 7th, 2022

Am I on the IndieWeb Yet? | Miriam Eric Suzanne

Miriam has a wishlist for scaling up the indie web approach:

What I would like to see is a tool that helps bring the entire system together in one place. Somewhere that non-technical people can:

  • build their own site, with support for feeds/mentions
  • see what feeds are available on other sites, and subscribe to them
  • easily respond to other sites, and see the resulting threads

(Oh, and by linking to this post, this should show up as a bookmark—I’m also testing Miriam’s webmention setup.)

Sunday, June 5th, 2022

The Cello and the Nightingales: How the World’s First Fake News United Humanity in Our First Collective Experience of Empathy for Nature – The Marginalian

Decades before fiber optic cable spanned the bottom of the ocean to link continents, the airborne voice of a spring songbird did.

Mario Popova writes of an interspecies broadcast:

Those were the early days of broadcasting and recorded music, when the technology was both too primitive and too expensive to make the joy of music as ambient as air; the days before we made our Faustian deal with the technocrats who made music cheap and musicians poor so that we could stream it anytime anywhere with no recompense or thought of the souls from which the stream pours.