It's only a few days until 2025. That means one thing: it is time for my yearly tradition of reviewing… some of my year. I'll cover work, conferences, reading, writing and music.

This will inevitably sound cheesy, but I am once again genuinely grateful for the opportunities I got… there were fun projects at work, I got to see some of my dearest artists live and I got to share knowledge and opinions at events among some of my favourite peers. At the same time, the last few months have, honestly, been intense, and I am looking forward to take a few breaks in January.

I also can't not mention politics. I saw a number of sad elections results. I saw people chose to vote, basically, against other people. It was heartbreaking to see people vote against women, against trans people, against people who crossed borders, and also against the odds for humans to inhabit this planet… and some major tech leaders chose to embrace, encourage or cheerlead that. Booh.

Some say one should focus on things one can impact. I'm not always good at that, but I'll do it now, by sharing a bit more about my year in terms of projects, conferences, reading and listening.

Projects

I spent most of my time on two projects for the Dutch government: NL Design System and the digital accessibility (standards) team at Logius.

At NL Design System, I got to organise another Design Systems Week, and worked on accessibility testing, guidance for forms and WCAG (both in Dutch), communication strategy, events and our website. At Logius, I worked on growing our participation in international standards discussions, specifically accessibility standards like WCAG and EN 301 539, at W3C and ETSI. It's been really cool to get back into familiar groups and join new ones (like the TC and JTB; yes I learned new abbreviations why).

Next year I'm increasing my time for standards at Logius, which, sadly, also means I'm leaving the NL Design System team.

From February, I'll have some availability for new projects, too: ~2 days/week to work on accessibility, frontend and/or design systems, do get in touch if you can use help.

Conferences

It's been a very busy and very fun year in conferences (I recommend going to conferences, for all reasons Sophie outlines in her post You should go to conferences).

Some talks I liked:

• The art of reflection by Imran Afzal at All Day Hey
• Feminism in programming language design (start at 20:50) by Felienne Hermans at Joy of Coding
• The many lives of a notification by Sarah Highley at Accessibility Toronto

I loved speaking at a number of them, too. I got to meet new people in the industry and hang out with friends. Even if it is nerve wracking at times, it gives me a lot of energy.

Creativity, art and AI

In October, I presented a new talk called Creativity cannot be computed at Beyond Tellerrand in Berlin. I talked about what's great about arts and creativity, in the context of our industry's tendency to leave stuff to computers. I love computers and art both, but we've got to prioritise. Some of this has been in my head for the last decade, and I loved to hear how it resonated with people in conversations after (maybe partially because I can't seem to shut up about it, sorry to all affected). I plan to write more about art and AI on my blog, but you can already read along with the slides or watch the video.

Acccessibility

Another new talk was Built-in accessibility: blessing or curse, which combined some of my earlier talks on tooling, browsers and CMSes with what I learned about design systems at NL Design System, all to uncover a general theme: that building in accessibility is not a one size fits all solution, but when done right, can be a sound part of your accessibility strategy. I gave this talk at A11y Club Amsterdam and at Accessibility Toronto.

Popovers

Earlier in the year, I did the most northern iteration of my popover talk (video) at All Day Hey in Leeds. I was very happy how it turned out and it was great to visit this city and this event that I had heard so many good things about.

My shortest talks were at Joy of Coding in my home town of Rotterdam, where I spent 5 minutes rambling about software and accessibility, and Mozilla's performance.sync() meetup in Amsterdam, where I talked about Open UI and reducing bundle size.

In the next year, I'd like to talk about web sustainability more, and continue to cover accessibility, design systems and AI/art.

Reading

I read some books this year, two of my favourites were:

• Character limit: how Elon Musk destroyed Twitter; a lot of the shocking facts in this book were public knowledge already, but Ryan Mac and Kate Conger did a wonderful job telling how the events unfolded, the details make one fear a world in which Elon Musk has any influence.
• Against technoableism: : seeing people with disabilities as an “inspiration” or needy of technological “fixes” is problematic, this book explains why.

These blog posts from others are among favourites this year:

• Coming Home by Mandy Brown
• Generative AI is for the idea guys by Rach Smith
• The Dilemmas You'll Face When Creating a Component Library by Andrico Karoulla
• We have a content quality problem, not a content quantity problem by Cory Dransfeldt

Music

Three albums that came out in 2024 that I liked:

• Odyssey by Nubya Garcia (jazz saxophone with orchestral arrangements, vocals and more).
• Lives Outgrown by Beth Gibbons (of Portishead fame, it grew on me).
• Drop 7 by Little Simz (hip hop, it feels more free and experimental than her previous work).
• IJsland by Abel & Sef (Dutch punk hip hop that I loved almost instantly).

In live music, it was a good year… I stayed on top of who's touring and ticket acquisition, and managed to see many faves. Most liked: IJSLAND, Massive Attack and Robert Glasper. I also made a point of going to see stuff when traveling, a tradition I hope to keep, though it gets expensive when traveling outside of Europe and its subsidised cultural venues.

In music making: I am picking up playing piano again and have joined a choir, which has been on of my best decisions, it is so much fun. As usual, I should have listened to a friend's advice earlier.

Writing

With 10 posts in total, I didn't write as much on this blog in 2024. I don't know which were most read, but these got some good feedback:

• On popover accessibility: what the browser does and doesn't do (co-written with Scott O'Hara)
• “AI” and accessible front-end components: is the nuance generatable?

Cities

Outside The Netherlands, I spent time in Duisburg, Berlin, Taipei, Tainan, Kaohsiung, Brighton, Antwerp, Paris, Leeds, London, Bad Schandau, Brussels, Los Angeles, Toronto, Liverpool, Vienna.

Self study

I did a bunch of self-study:

• Josh Comeau's The Joy of React. It was indeed joyful, and the most down to earth overview of React I've seen so far.
• the IAAP certification exams. I'm now a CPWA, which is both WAS and CPACC. I have more to say about this, maybe some other time or 1:1.
• I worked with Melinda on specific parts of my public speaking, I would absolutely recommend her to anyone looking to learn.

Wrapping up

I wanted to write up some resolutions for the next year, but I ran out of time. I guess I'll leave it, as a resolution itself, for the next year. If you're reading this, I wish you all the best for the new year!

---

Originally posted as What I got up to in 2024 on Hidde's blog.

Reply via email

Generative AI features have a large climate impact and water consumption. We can weigh that impact against those features' benefits, but what if they are left unused? If lots of people don't in fact use the thing? That seems like lots of avoidable waste. Which matters, we're in a climate emergency and we're dangerously far from that 1.5 degrees target.

I know, we all want people to use features we build, but it is safe to assume they often don't. For my business, I use a lot of very beautiful self service portals that I only ever log in to, to download a PDF that my accountant needs. The beautifully considered UI, fancy spinners and clever copywriting are there, but if I'm honest, I mostly ignore them (sorry).

Is that ok? A button in your app that your user doesn't press, wastes little energy. But if your app automatically generates summaries, captions or suggestions, and the user didn't want or use that functionality, a lot of energy and water was wasted. While serving no purpose. It's that combo of waste and purposelessness that we should avoid at all times.

Wait, that's absurd, you say. Does this really happen? Yeah, I come across it all the time, and it's not just because I'm somewhat of a luddite myself.

Features I didn't use

Some examples of AI features that ran on my behalf just in the past week, but that I didn't use:

• Loom's transcripts and automated titles and descriptions. They show up almost instantly after upload. I always remove them, they fail to get the point across, which I want to do pointedly to save colleagues reviewing a video time.
• Parabol's automated summary of team retrospectives: it emailed us key points, some incorrect. While we had written them down correctly already.
• Notion's AI assistance that shows up whenever you press ‘Space’. Ok, granted, it only runs once you've actually typed a prompt, but it's a good example for this post, as it's one of those I hear many people want to turn off, and you can only do that “on Enterprise“, according to this Reddit topic dedicated to turning that feature off.

Of course, these features are not redundant if users benefit from them. But let's be real, oftentimes users didn't want to generate anything. It happened anyway, and was unsolicited. They will probably discard of the output. In those cases, the energy-intensive feature was redundant. And that's an issue, as we don't have redundant energy.

Meanwhile, most major tech companies announced they are letting go of their net-zero goals. Some have bought nuclear power plants to cater for their energy needs (see Microsoft's plans with the Three Mile Island plant). This confirms to me that we don't have abundant energy. Maybe one day, but not today.

An ethical web

Is this ethical? The W3C's Ethical Web Principles have a specific principle that applies here: 2.9 The web is an environmentally sustainable platform.

It suggests new technologies should not harm the environment:

We will endeavor not to do further harm to the environment when we introduce new technologies to the web (…)

and recognises people who benefit are not always those who are harmed:

and keep in mind that people most affected by the environmental consequences of new technologies may not be those who benefit from the features introduced.

If a feature is useful for some, but indirectly causes the energy or water bills to go up for others, we're breaking this Ethical Web Principle.

Conclusion

So, I'm just a guy sitting behind a keyboard, begging anyone including generative AI features: only put them to work when users indicate they want that to happen. That's also going to turn out cheaper when OpenAI increase their rates, which is likely as investors are going to want returns. Why not consider leaving out that new LLM-powered feature in the first place: not everything needs to be “artificially intelligent”, sometimes a bunch of if statements make a killer feature (dude, that's so paternalistic and you're oversimplifying the realities of software engineering, you say… yeah, sorry, I'm trying to react to the overcomplexification that also happens).

Do you have other examples of software that forced LLM generated content on you? Let me know and I'll add them to the post.

Further reading

• Thinking about using AI? Here’s what you can and (probably) can’t change about its environmental impact by the Green Web Foundation
• AI’s Growing Carbon Footprint (cites data centres account for 2.5-3.7% of global greenhouse gas emissions, exceeding aviation)
• We’re getting a better idea of AI’s true carbon footprint
• Is generative AI bad for the environment? A computer scientist explains the carbon footprint of ChatGPT and its cousins

---

Originally posted as Turn off AI features by default (to reduce their climate impact) on Hidde's blog.

Reply via email

Taking the train for work travel can cost more time than going by car or plane. But it's one of the most energy efficient ways to travel, and I get this weird productivity boost from them.

Note that you can absolutely also chill out, read, sleep or listen to music on trains. I like that too, sometimes. But this post is about when I use train time to work. In Europe.

Enjoy the benefits

As mentioned in the intro, a major reason for my traveling by train is the low environmental impact (relatively, and apart from not traveling). I travel a lot for work, so my impact is relatively high, especially when I don't manage to avoid planes. Despite doubts about effectiveness of compensation, I do compensate in various ways, but it still doesn't feel great, avoiding is ideal.

Trains also offer a productivity boost. If you're forced to be in a seat, on a connection too unstable to take work calls, this presents an opportunity. An opportunity to get things done (no I am not for hire as a productivity coach).

gitI don't know what it is about trains, but I really find the time flies when I have something specific to write, code, or design. Trains have proven themselves as great offices to me. I don't know if I can convince my bookkeeper that train tickets are in fact office rental costs, but do you see how they can feel like that?

There are some more benefits to trains:

• good views. Depending on your route and time of travel, there's always plenty to see outside. Sunrise and sunset are particularly nice.
• arrival in central locations. European train stations are usually close to where the fun happens.
• less checks. Within Schengen, international trains usually don't have border checks or luggage checks, so there's a lot less hassle and queuing, you can show up and go.

Embrace the caveats

Things can go wrong, too. Like with any kind of travel.

Delays

If your international train has stopovers, delays can be a headache. Especially between train companies. Plan for stopover time and consider flexible tickets for onward journeys. And stay calm: it happens. Also, in Europe, you have lots of rights re train delays and will have travelled partially for free when delays happen.

Data

Large parts of Europe don't have stable mobile data, especially outside cities. Or, depending on your plan, you don't get a great connection roaming. Have some of your work available offline so that poor connection doesn't interrupt you. Know which web apps to trust (the progressively enhanced parts of GitHub are the best).

Power

Not all power outlets will work, so I follow the ‘ABC’ rule: Always be charging when you have the opportunity, so that batteries are full and ready to go when you don't.

In conclusion

Trains are nice, and their benefits outweigh the caveats, especially if you anticipate those in advance. I'm curious if people have found other benefits or caveats regarding taking the train for work. What's exciting you or holding you back? Feel feel to reply by email or via Mastodon or Bluesky.

---

Originally posted as Trains are offices on Hidde's blog.

Reply via email

Yesterday, I was at State of the Browser in London. It was great to catch up with friends and make new ones, and the talks were once again very well curated. In this post, I'll share some notes from the day and the takeaways that stood out to me the most.

The Barbican tube station

Think about funding the web ecosystem

Stephanie Stimac kicked us off with a brilliant talk on how to fund the critical infrastructure that is the web ecosystem. We couldn't browse the web without browsers, and they wouldn't exist without engines, that are hard to make, and to fund. In the current model, browsers get large amounts of money from search deals. For instance, in 2021, Google paid almost 20 billion (not a typo) to Apple to make its search engine the default (but a US federal judge ruled that such payments unlawfully limit competition). It's a lot of money, but as that money goes primarily to the browser companies, not the engines, and may go away if search deals are deemed illegal, we need to think about new ways to fund browser engines, Stephanie urged us. They could include donation based systems, tax breaks or a Web Levy. For more context, see Stephanie's slides and in the comments of w3c/breakouts-day-2024#20.

Participate in accessibility standards

Next up was fashion designer and web accessibility advocate Steve Faulkner. He shared some of his own web standards stories and gave practical tips around how to participate. Without naming (many) names, Steve very accurately explained some of the different types you'll find in standards meetings: there are well-meaning, argumentative, axe to grind, practical, clueless, old school, helpful, true-believing, revisionist and lurking type of people. There are a number of ways people do participate: you can file issues (like in w3c/wcag), comment on issues, file PRs, comment on PRs, join a Community Group or join a Working Group. Only for that very last one, you actually need to represent a W3C Member. What you do need to do, Steve warned, is to know when you don't know. It's fine to just listen before having strong opinions. Now, starting to participate can be hard and/or daunting, so to anyone reading this: feel free to slide in my DM/email, we can (always) use more perspectives.

Different types

Advocate for the open web

Stuart Langridge shared the story of how he and others at Open Web Advocacy ended up talking to regulators about anti-competitive behaviour in our industry, including the fact that iOS doesn't allow for other browsers than Safari. Their work has had an enormous impact, as it helped regulators understand the nitty gritty details of what they were regulators. “The web is ours”, Stuart said and anyone who believes the same can join and help out at Open Web Advocacy, or do their own advocacy for an open web. Amen to that!

Make impact

Gayle Ngozi shared how the non-profit Code your Future works with refugees and disadvantaged people to get skills in software engineering to close the gap between them and the job market, specifically in the tech industry. She said we can all make impact by contributing stuff like laptops, time by teaching and/or opportunities by working together to launch new tech careers.

Make little web components

Personal website innovator David Darnes finally explained the inner workings of that cool button on his site that announces his name spoken by different people every time you press it. He didn't cover why it has a bias towards his father's recording, but it was very interesting nonetheless. There's one component that upgrades the standard <audio> element to be a fancy button, another that randomises the source used and one more that makes the playing state available as an attribute so that it can be used in styles. Are Web Components just for little bits? No, Dave showed that it's also used in fairly complex applications he worked on, including at Nordhealth, that has both Nuxt and Django apps using the same components. The technology, Dave said, works so well because is versatile and forgiving.

Make standards open

Katie Fenn is a huge Daft Punk fan, so she used her talk slot to play their “Around the world” with web technologies: the WebMIDI and WebAudio APIs specifically. MIDI is a technology and technical standard specced in the 80s that allows you to pass messages and information between musical instruments, like notes and special effects. Because it was, just like the W3C's web standards, completely open and royalty-free, it's changed music production forever, especially electronic music: yay open standards. You should watch this talk when it comes out. I can't wait to go play with the MIDI-enabled devices in my home.

Synthesisers!

Automate more of assistive technology support testing

Lola Odelola showed how web standards work happens by using the ARIA-AT program (and ghost detection 👻) as an example. Many developers will be familiar with the ARIA Authoring Practices Guide. I am very happy for this to exist, but also see gaps in user testing (do real users actually; understand how to use the patterns?) and AT testing (do the patterns work in AT and is that consistent?). ARIA-AT, Lola showed, addresses the latter, and does so really well: there is a Selenium-like protocol called AT Driver to automatically test how the ARIA patterns work in different assistive technologies, with lots of reports as a result. Loved hearing Lola talk about this important project, that I hope can be built out further.

Use fluid scales

Richard Ruttter showed us how to use fluid scales for typography and spacing, I feel inspired to go and try that out on this website when I get a chance. See also what I wrote about that talk at Patterns Day.

Summing up

It was a lovely day, with great talks and conversations. One of the recurring themes was how much extreme capitalism affects the ecosystem we all clearly share a love for, we learned about various concrete ways in which this is at play. At the same time, we shouldn't forget to focus on what is valuable in and of itself: making music, fun buttons and UIs that include everyone. Priorities matter!

---

Originally posted as The open web, MIDI and assistive tech: State of the Browser 2024 on Hidde's blog.

Reply via email

It's not easy to build very good UI components. A global effort to try and find the best qualities of components would be a great opportunity to improve components everywhere.

Aren't design systems ultimately a quest to collect the best UI practices across an organisation? Or across multiple organisations, or for anyone in general. This kind of work brings excellent opportunities to improve quality across some scope, organisationally or more widely. And if we do that, why not try and aim for the widest possible scope and go global? In A Global Design System, Brad Frost suggests this:

let’s redirect that rallying cry outside of any individual organizations’ walls and apply it to the world at large.

I can only agree with that. With so many design systems out there, it makes a lot of sense to look at the commonalities between them.

As Brad mentions, we've been doing this at Open UI. The goal of this group is to make it easier for developers to build and style UI controls on the web, by improving the web technologies and standards that they are built with. So far, this lead to features like popover (in Baseline today) and styleable selects (in active development).

How a global design system might work

Brad suggested in his post that we could work towards “common library containing common UI components”, with code and designs and documentation. In his follow up, Greg Whitworth suggests to create a test suite. I like how concrete these ideas are, and I am sure they will help tonnes of developers make better components. But what if we look at this idea more a more abstract way?

There are clearly teams who just want to use concrete components, as-is. But in my work and conversations, I hear demand for something else: to have a way to validate what is good. A lot of teams want to build their own components and systems. Or they have to, because of their organisation's specific constraints.

Finding qualities

To me, it seems a lot of developers want acceptance criteria and holistic guidance, rather than built components. There's a lot of example components already, why not try and collect what's already built and seek consensus about what qualities components need?

I'm thinking things like:

• this is how an autocomplete-y combobox should convey new results were filtered
• this is the most user friendly keyboard behavior for switching between tabs
• this type of buttons needs an active verb as the name

This is information that is relatively hard to find, especially for more rare components, and especially in a format that developers can trust to base their decision making on.

In my ideal world, a global design system isn't primarily concerned with making a set of components. Instead, it would focus on finding the best qualities of components. What are the qualities they must have, in order to be solid, accessible, internationalisable, privacy-friendly, secure component?

Benefits

With this approach, these qualities can become checks for everyone who wants to make these components themselves. And at the same time, they can be checks for everyone who wants to quality-assure or accessibility-assess websites that use these patterns. (Plus, folks could still build an example library of components that adhere to the qualities; but I think there are always going to be multiple ways).

Defining qualities rather than concrete components also helps with another problem we've seen at Open UI a lot: that there are many ways that lead to Rome. For example, there are many ways to build a tab. With qualities, we would avoid the search for the true one way to do something. Instead, we could deem multiple implementations of tabs “ok”. The Org X tab is cool, the Org Y is wildly different, but it is also cool, the Org Z tab is… hm, not great, because it lacks a, b and c.

Lastly, it would help with the myth of the accessible component. There is only so much we can build in, there will always be acccessibility considerations that depend on usage (see my talk on built-in accessibility). Both how you use of the component and the context you use it in determine whether the experience is accessible or not. There's no “use this component and your thing will be accessible“. Paraphrasing Scott O'Hara: a component is accessible until you use it somewhere.

What global comparisons unlock

Aren't we lucky that we're now in a phase of design systems that there are a lot to compare between? Comparing different design systems can unlock a number of things, but these are some things I find particularly interesting:

• finding components based on real use cases: if we look at components that already exist, we know someone had a use for them
• finding the best names: naming things is hard, and bringing many design systems together bubbles up which names resonate best with people (see the component matrix and component.gallery)
• getting closer to ‘accessible patterns’: there are lots of things that can make a given pattern more or less accessible; if we bring together patterns from many places, we can document more use cases, more ways people (end users) might use this pattern (accessibility is largely about how people use the web), and more aspects their accessibility specialists have talked about

Each of these is, in its own way, a benefit of including diverse perspectives. Which is what the W3C has been doing for almost (this year!) 30 years.

A national global design system

Brian Kardell shared his idea for moving components through stages. In it, he says:

[a component] would undergo wide review and get some kind of 'verification stamps' for each kind (a11y, i18n, etc).

He suggests folks submit components, that then get reviewed, which will lead to a catalog of components that have been checked and for which everyone can publicly see how many of the checks they meet.

I liked a lot about this proposal and feel it will be fruitful to primarily focus on checks. I also noticed some similarities to what we're doing at NL Design System, a project I'm involved in for the Dutch government, so I wanted to end this post with describing a bit about our process.

At NL Design System, different governmental organisations collaborate on defining the best components, patterns and guidelines. The core team, that I'm a part of, facilitates this collaboration. It may end up being a kind of national global design system, a standard for building good digital government services.

Relay Model

So how do we work? Each organisation in our community has their own design system. In principle, they use a shared architecture, build components that meet their own needs and open source them under the same license. Components that seem suitable for standardisation are put on a track that we call “Relay Model” (see also this excellent presentation on the Relay Model (Dutch, English subtitles available) by my colleague Yolijn van der Kolk).

In relay racing competitions, runners take a baton and hand it over to the next person. With our Relay Model for components, different people can take a component to different stages.

(Note: there are patterns and guidelines too, but here I'll focus on components specifically.)

In this process, components (their “blueprint”, eg “Button”) can have one of four statuses:

• “Help Wanted“: there is agreement on the rationale for the component, organisation(s) that need this can build it.
• “Community”: the component exists in one or more organisations, meets a set of acceptance criteria and uses the shared architecture. Each organisation can build it with the bells and whistles they need.
• “Candidate”: the component meets more acceptance criteria, including strict accessibility and usability tests, and is deemed ready to become the standard, we solicit real-life feedback in a request for comments period. It is stripped of elements that are too organisation-specific.
• “Hall of Fame”: the component is stable, not controversial, and has “guarantees” around reusability, accessibility, usability and stability. This is where a “button” becomes “nl-button”.

There's also two more informal statuses: components that are likely to have just the one use case for one organisation, one-offs, are deemed “Snowflake”, and components that are unlikely to result in accessible, user-friendly components are deemed “Discouraged”.

During any time, components can exist in multiple organisations, so City X, Government Agency Y and Province Z could all have a Button that meet their needs. The “Hall of Fame” Button is the common denominator version of it, where we've tried to remove all the org-specific stuff and stick with features that multiple organisations need. User research is an essential part of all this and we encourage organisations to share theirs as open source Markdown.

Benefits we see include:

• legitimacy: based on the needs of specific organisations and their use cases
• credibility: the components aren't the result of one person or team's opinions; a combination of wide feedback, user research and collaboration are essential in the journey; “blessing a component” is a largely shared responsibility
• open approval process: the criteria and process for moving to the next stage are open (see the GitHub project board for Help Wanted), anyone can steward a component to the next stage, then pass on they if they wanted to
• living standard: teams should always be able to innovate. If they need an extra component or variation, they can always make it available as “Community” even when a similar component already exists in the current “Hall of Fame” standard

We're currently stewarding components through the first stages, and don't have a “Hall of Fame” yet. But the process already demonstrates value today, for everyone involved: teams are using one another's components and are benefiting from each other's perspectives, accessibility knowledge and user research.

Summing up

In conclusion: I think there's a lot of value in trying to find which qualities make for very good components, using a standardisation-like process that involves a broad range of stakeholders and avoids blessing-by-a-few. In my ideal world, this can bring us to a place where web developers can get more confidence in how to make their components very good. Recent conversations within Open UI make me hopeful we'll get closer to that.

---

Originally posted as Comparing design systems to find the best qualities on Hidde's blog.

Reply via email