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

Today I was at the IAAP-EU event in Paris, where we spent a morning workshopping and clarifying parts of EN 301 549, the procurement standard that is used in the Web Accessibility Directive.

I managed to get a spot in the group that focused on 11.8, the part of EN 301 549 that focuses on authoring tools. In this post, I'll share some insights from that session.

This post was written, as always, in personal capacity. And sorry, I don't have an HTML link for EN 301 549 (there isn't one currently, but there is a PDF).

What actually are authoring tools?

When my job was to promote the use of ATAG, I used to say authoring tools are “tools that create web content”. In EN 301 549, they are defined more broadly, beyond web:

software that can be used to create or modify content

(from EN 301 549, chapter 3: Definition of terms, symbols and abbreviations)

In other words, this definition includes web content as well as non-web content. The EN defines “non-web content” as “not a web page, not embedded in any web pages or used in the rendering or functioning of the page”. Examples of such content includes PDFs, Word documents and EPUB files. There's also a W3C document specifically about accessibility of “non-web content”, WCAG2ICT (which is informative, not normative) .

EN 301 549's authoring tool definition is followed by three notes, that all demonstrate the extent to which these tools exist:

• authoring tools can have multiple users collaborating on content (this makes me think of tools like Sanity Studio or Google Docs where lots of people can edit content at the same time)
• authoring tools could be a collection of multiple applications. For instance, some content goes through multiple applications before end-users access it
• authoring tools could produce content that's used or modified later

In our group we quickly realised that there are indeed a lot of different authoring tools. The most obvious one is Content Management Systems (CMSes). Others that people mentioned are social media, online forums, video editing tools, WYSIWYG editors, and email clients. ATAG at a glance also mentions Learning Management Systems, blogs and wikis. It's a broad category, there are a lot of tools that can make (web) content.

The ATAG reference

ATAG, the Authoring Tool Accessibility Guidelines, is the standard that provides recommendations for both making authoring tools themselves accessible (part A), as well as the content they produce (part B). See my earlier post ATAG: the standard for content creation for an overview.

Conforming with EN 301 549 requires that all of our web pages meet all of WCAG (up to Level AA, see EN 301 549, clause 9.6). But it doesn't require ATAG. ATAG is merely mentioned as something that is worth reading for “those […] who want to go beyond [EN 301 549]” (in 11.8.0). In other words, there is no normative requirement to read it, let alone to apply it.

Still, some CMSes do. For instance, Drupal supports ATAG (part A and B) from version 8. Joomla, Wagtail and Craft CMS also have done a lot of work towards improving accessibility, see the W3C's List of authoring tools that support accessibility.

However, that doesn't mean ATAG isn't an incredibly useful standard for people who make and use authoring tools. In fact, it is. In 11.8.2 to 11.8.5, some ATAG requirements are explicitly added. These clauses are requirements, because they use “shall”, which in ETSI standards implies a “mandatory requirement” (say their drafting rules).

Note: that EN 301 549 requires these things, doesn't mean the law in European countries does. These laws often refer to specific parts of the EN, or refer to EN 301 549 specifically in relation to web content.

Note 2: clause 48 of the Web Accessibility Directive is interesting. It includes various points I'd love to see member states adopt:

• “EU member states should promote the use of authoring tools that allow better implementation of the accessibility requirements set out in this Directive”
• recommendation to “[publish] a list of compatible authoring tools” (as suggestions, so not requiring them specifically)
• recommendation to “fund their development”

11.8.2: “enable” and “guide”

Out of the authoring tool requirements, we talked most about 11.8.2. It says:

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.

The key words to me are enable and guide. My personal interpretation of what that means, and maybe partially what I want it to mean:

• enable: that tools have, for all types of content they can produce, functionality to create any necessary accessibility aspects for that type of content. For instance, if they let you add an image, they need to let you add a text alternative. There's a lot of grey area, because some very complex images might require linked descriptions that don't fit as alternative text. And what about types of content that the tool creator users aren't supposed to create? LinkedIn might say it only lets users create plain text with links, not headings. Is the fact that users will try and add faux bold text and whitespace instead of headings LinkedIn's fault or the user's?
• guide: that tools tell authors about accessibility issues and help them get it right. I would love for more authoring tools to do this (see also my pledge in Your CMS is an accessibility assistant). Let authoring tools guide authors to more accessible content, this should have a large multiplier with fewer barriers across the web as a result.

What I like about the “guide” part especially: it addresses problems where they surface first. It lets authors fix accessibility problems before they ship to production, if the authoring tool guides them.

Other requirements

We didn't get to the other clauses, but they are interesting too:

• preservation of accessibility information in transformation: a real example I dealt with: if you turn HTML into PDFs with PrinceXML, it's tricky to get it to take the text alternatives from your images and embed them correctly into the PDF.
• repair assistance: there are CMSes already that tell authors when they're about to choose a new colour that would cause contrast issues (like WordPress' editor). Again, this lets authors fix problems before they exist in the produced content. Drupal has a list of modules that may improve accessibility.
• templates: when templates are available, accessible ones should be available. Again, a focus on making accessible templates could have a huge multiplier effect, as they could be reused in many different places. WordPress has a list of accessibility themes

Summing up

It was fun to dive into one of the requirements specifically, and my hope is for two things. First, I'd find it useful for there to be more extended guidance on these clauses. They are fairly minimal and more concrete examples would help. Second, the testability could improve. What makes a template an accessible template (one that meets WCAG?), what sort of assistance is sufficient, and what sort of “guiding the author” is? And then my last open question would be: when does an authoring tool fall into or outside of the scope of the organisation trying to comply with EN 301 549? Is this when they use an authoring tool or only when they create one? To be continued!

---

Originally posted as On authoring tools in EN 301 549 on Hidde's blog.

Reply via email