Guillaume Meigniez Blog

Typography tokens - Bonus

2026-07-13T00:00:00Z

I recently published a 2 parts blog post regarding the challenges inherent to building typography design tokens. During the research that led to these posts I wrote down surprising things and went down a few rabbit holes. Those did not make it into the original posts, so I'll talk about theme here.

Google Fonts

Google's advices regarding Google Fonts is that you should use their CDN and that they will not "use any information collected by Google Fonts to create profiles of end users or for targeted advertising". I have to say that, before looking into it, I thought that downloading the font via fonts.gstatic.com was lazy but fine. Now I believe that you should never impose that on your users for privacy reasons.

Google saying that the user information (IP, referrer, user agent) is not collected by Google Font does not mean that they don't collect it at all. It's unclear which services are used by Google to track users online, but it's pretty obvious that with the third party cookies restrictions, big actors look at other ways to track users such as fingerprinting.

For now the IP address is considered personal data as defined by GDPR, and downloading third party content on a website shares that data. As far as the fonts are concerned, it is always done without the user's consent (it wouldn't make sense to wait for a consent before displaying the expected font), and therefore is illegal. The Munich court ruling from 2022 is very interesting but does not seem to have set a precedent that would impact how websites download fonts.

Additionally (if I understand the situation correctly) the 2023 EU–US Data Privacy Framework seems to have created the confusion about whether or not that ruling would be the same today. Anyway, preventing websites from downloading fonts from third parties would be a problem for Data Protection Authorities who lack funding to enforce the law when it comes to consent on the internet.

That may be one of the reasons why the European Commission with the EU Digital Omnibus proposal is in the process of changing the meaning of "personal data" to define it as something "reasonably likely to be used to identify the natural person to whom the information relates". Who knows what "reasonably" means. Two fun facts to conclude this section:

IBM Carbon was actually making you download Google Fonts with Google CDN until version 10. Version 11 came out four years ago but some websites such as IBM's global login page still download IBM Plex from fonts.gstatic.com.
Even if you are careful to self-host fonts on your domain, some bot challenge pages download fonts from fonts.gstatic.com (for the 5 elements they need to display), which would leak your users personal data.

Figma & DTCG

I work on web apps and websites so I'm always surprised when Figma does something that doesn't exactly match what browser specs say. (I also worked on a fairly large design system for web & mobile, but the mobile part was React Native, thus the use of typography design tokens was pretty much equivalent to a web css-in-js setup.)

For example, I notice the gap when designers say "hug" and "fill" instead of "fit-content" and "max-content", "frame" for "div" or "constraints" for "position". Figma invents a new set of terminologies to match the already established ideas of what a "frame" or a "constraint" are in different platforms. This leads to passionate discussion when naming things for a design system.

At the same time, Figma does look a lot like it's made to match the properties of CSS. It feels like Figma is stuck in between being universal enough to match any prototyping practice, and being specific enough so that the web-focused users (probably most of them) have a seamless experience.

In that sense the Design Tokens Community Group faces the same dichotomy when building specs for design tokens which have to be both ubiquitous and compatible with unique web specificities.

For example one of the latest issues opened on their GitHub repository is asking why there's no support for em as a dimension token unit, while px and rem already exist. It's a valid question for someone trying to fit the DTCG specs with their web project. But also isn't it weird that the DTCG spec has a unit called "rem", which is a web convention thay may not make sense on other platforms?

I did not include anything about DTCG in my first two blog posts because its specs are not widely integrated across the design system tech tools yet. Maybe due to the dichotomy mentioned above. On a side note, DTCG does not indicate any way of building typography design tokens that take into account the @font-face rule pitfalls.

Font weight tokens

When researching the topic of web typography from the designer's point of view I noticed that there's a very common misunderstanding of the weight of fonts. Most designer oriented tutorials and content I came across confuse the weight scale of a font with the arbitrary static naming it was given by the font creators.

It becomes a problem when using a token for font weight thinking that it would work across font families. As if the glyphs in "Montserrat-Medium.ttf" would have the same thickness as "Helvetica-Md.ttf". As if the "Medium", "Rg", "black" or "DARK" that appear in font file names were a norm that matches a predictable thickness.

One of the points of my previous blog posts was to explain how those are completely arbitrary and how the @font-face rule must be the link between the numerical weight scale (from 100 to 1000) and the font file.

Many tutorials on how to build design tokens for typographies in Figma tell you to create primitive weight tokens such as "Medium", "Regular" etc. In which case the naming has to match the exact weight naming of the font file in Figma. Doing so would obviously break as soon as you change font families.

I believe that it's always a bad idea to name weight tokens that way. It only makes the designer's job easier when creating the token system. It seems to be much more robust to use the numerical scale.

Typography tokens are hard to get right - Part 2

2026-06-22T00:00:00Z

In part 1 we saw that most design systems don't consider how fonts work on the web when building their tokens system. Not thinking about the CSS @font-face rule leads to solely performative font-weight, font-family and font-style primitive tokens that cannot be automatically updated.

Now let's see what solutions existing design systems have opted for.

Static typography

Most design systems are created with one or two specific font families in mind. The fonts are core to the design of the system and are not supposed to ever be modified. It makes sense to do so: different fonts have different ways of filling the space on the page, and you need to build your colours, your animations and your spacings accordingly. A good example for that is IBM Carbon that uses their own historical typography tied to IBM's global design vision:

Our approach to the typographic system uses IBM Plex as its typeface. It has been carefully engineered with suitable scales, styles, and weights to help create clear hierarchies and organize information that guides users through IBM products or experiences.

When you use Carbon Design, you need to download their npm packages. In the README.md of @carbon/styles it's explained how you'll have to manually include the fonts you want to use in the code. Their tooling does the rest. But in the end, the family, width and style of fonts are not design tokens.

Other design systems have a frozen font-family but also expose typography tokens as if you could update them as easily as you change the shade of red-500. An example of that would be Skyscanner's Backpack design system with "Skyscanner Relative" and "Larken" custom fonts, typography tokens passed as-is to SCSS mixins and no @font-faces indications. These tokens are purely performative, and design system authors might not be aware of the extra step required to update their value.

System fonts

Several battle-tested design systems have opted for system fonts. Similarly to the static typographies above, they set a specific list of system fonts as the font-family. Examples of these can be found in Salesforce Lightning 2, Palantir's Blueprint or GitHub's Primer.

The advantage of this strategy is that the "system fonts" are expected to already be present on the vast majority of users' devices. Also, even if one of the system fonts is not available, or when setting various font-weight and font-style, the result has good chances to look like what you'd expect.

But your texts would look generic, and if you are trying to build a brand with a little more character the texts might look a little plain.

Most importantly the final look of your typography would not be set in stone. You can't predict what's available on the user's device, and might have to design your apps with multiple possible fonts in mind. If the user has one of the system fonts available, it will be used even if the font-style or font-weight do not exist for that specific font on the user's device. According to the W3C documentation, the user agent (browser) might (or not) adapt the characters to look like what it predicts you want:

For example, a user agent might:

synthesize a bold face by drawing a thin stroke around each glyph

[...]

synthesize an oblique face by geometrical shearing of each glyph

These synthetic fonts are the infamous faux-bold and faux-italic, and every browser is free to make them look however they want.

With system fonts you should be ready for the text to look very different between users.

Generated @font-face

If the design system has a token for the font-family (i.e. you're supposed to be able to change the family), we saw that you have to update the @font-face every time it changes to adapt which font file each text setting points to. This can technically be done automatically by generating the CSS @font-face every time the project is built.

In part 1 we had this example:

@font-face {
  font-family: Proxima Nova;
  font-weight: 400;
  font-style: italic;
  src: url(/static-assets/font/ProximaNova-RegIt-webfont.woff2) format("woff2");
}

So we'd want the font face rule depend on the tokens like this:

@font-face {
  font-family: var(--body-italic-font-family);
  font-weight: var(--body-italic-font-weight);
  font-style: var(--body-italic-font-style);
  src: url(var(--body-italic-font-src)) format(var(--body-italic-font-format));
}

With two new tokens: one for the URL at which the new font file can be found, and a format token for the type of font file.

There are still two issues:

CSS variables are not supported inside @font-face rules, so there needs to be a CSS pre-processor such as Sass or a specific build step that does it.
Having the URL as a tokens means that you have to know that the file exists at a specific location (and will stay there). And if that location is your server, you'll still need to upload the new font file to it.

IBM Carbon does a version of this, but their use case is a little different, because they already have a restricted set of fonts, they can pick the right one and set its (local) location inside an auto-generated font-face on build.

Another example of that is the US Web Design System that generates @font-face on build based on a set of design tokens. However, just like IBM Carbon, USWDS specifies a set of font families that are shipped with the design system itself.

For both of these design systems you could still set an URL for your custom fonts requirements.

On a side note, using font sources from Google Fonts is convenient, but is not a good idea, especially in the EU. You would condemn all your users to ping a Google server every time they open a web page using your design tokens, which (most probably) helps tracking their behaviour. In 2022 a Court in Munich ruled the practice of sharing a user's IP with a US server through the download of a Google font unlawful.

Variable fonts

Last but not least, variable fonts can be a piece of the solution. If your priority is to be able to update font-weight and font-style whenever you want, they might be your best shot.

With variable fonts, you only have one or two font files. That single file can produce a set of glyphs for any variation of font weight and style. Which means you only have one @font-face rule that sets the link between the font name and its file:

@font-face {
  font-family: "MyVariableFontName";
  src: url("path/to/font/file/my-variable-font.woff2")
    format("woff2-variations");
}

Now whatever the value of your --body-italic-font-weight and --body-italic-font-style are, there is a predictable glyph displayed on screen. That's very convenient. And until recently Figma made it hard to work with variable fonts, but since recently you can have a variable font weight that is a number value bound to a Figma Variable. Which makes the token integration seamless.

It however does not solve the issue of updating the font-family. Also using variable fonts or not is still up for debate since they might raise concerns regarding the file sizes or their support. If you need to support older versions of browser (or if you're working with platforms other than the web) that would not support variable fonts, you might need to have fallback fonts that would be static anyways.

Examples of design systems using variable fonts with a token for font-weight are Atlassian ADS or Shopify's Polaris React.

We can see from these different strategies that there is no magic trick making typography tokens easy. You'll have to make compromise on your design system tokens exhaustivity (hey it's not a bad thing to be opinionated!). Technical solutions can exist, but are so much more expensive than their benefit in flexibility that no one has built them yet.

Stay tuned for the bonus part of this tokens series. I'll discuss some unexpected things and rabbit holes I ended up researching along the writing of these posts.

Typography tokens are hard to get right - Part 1

2026-06-09T00:00:00Z

Let's say you are a designer or a developer maintaining a design system for the web. The system is ideally integrated end-to-end between your design tool (e.g. Figma variables) and the code (e.g. CSS variables). Updating the variable value in Figma automatically changes its value in the code, and the modification propagates to the end user.

Have you ever tried updating your typography tokens? Chances are that for some of them you can't change their values that easily, and you might not realise it until it breaks your design system users' websites.

The goal of this series of blog posts is to show why it may be the case and what solutions exist to make it right.

Unlike colour tokens (that are quite straightforward to set up) typography tokens might not behave as you think if you are not aware of how fonts work on the web.

But let's start from the beginning, what do typography tokens usually look like?

Typography tokens

If you are using Figma, you have "typography styles" each having a few typography parameters mapped to Figma variables. You probably have something resembling the following typography variables setup: fontFamily, fontWeight, fontSize, lineHeight, fontStyle and maybe letterSpacing.

In the code, it looks the same. If you open Dev Mode on Figma, or if you look at the apps CSS you'll see that the CSS styles match your token names. Here is an example of how these tokens would be used in CSS:

.text {
  font-family: var(--body-italic-font-family);
  font-weight: var(--body-italic-font-weight);
  font-style: var(--body-italic-font-style);
}

Easy, it makes sense, one CSS property = one token = one typography style parameter.

If you tried updating the value of the font weight of one of your typography styles (let's say bodyItalic.fontWeight) in Figma, it would update and be applied instantly in the Figma workspace. However when the change propagates to the code, it would most certainly not have the expected result. And it boils down to the way fonts work on the web.

Web fonts

When you open a web page, your browser has to download a font file associated with the text that you want to display on screen. You can see that by opening your browser inspector's "Network" tab and by filtering on "Font":

In the example above there are multiple files downloaded just for the Proxima Nova font: "Reg" (Regular), "RegIt" (Regular Italic), "SBold", "Bold", "ExtraBold".

This happens because each font file only contains one specific combination of font family, weight and font style, i.e. ProximaNova-RegIt-webfont.woff2 is the one file that contains all the glyphs of the Proxima Nova font family, with the regular weight and the italic style. If for example one piece of text is not italic, the browser needs to download a whole new file for that font family, that weight and the font-style.

So the browser knows thanks to CSS that it needs "Proxima Nova", in weight 400 and in style italic, but how does it link that requirement to the ProximaNova-RegIt-webfont.woff2?

Well this is the piece that many design system teams miss. This matching between font files and CSS typography styles is done through a CSS font-face @-rule. If you look in the css files loaded by your browser when you open a web page, you'll also find somewhere something like:

@font-face {
  font-family: Proxima Nova;
  src: url(/static-assets/font/ProximaNova-RegIt-webfont.woff2) format("woff2");
  font-weight: 400;
  font-style: italic;
}

This is a @font-face. Whenever the browser finds a text that must be displayed using "Proxima Nova", with a weight of 400 and a style of italic, it looks at the font-face rule in CSS, and deduces that the character glyphs to use are to be found at /static-assets/font/ProximaNova-RegIt-webfont.woff2. Then the font file is downloaded and used to display the characters.

The catch is that the @font-face is most of the time hard-coded by developers, and only contains the already existing combination of family, weight and style.

When you update your bodyItalic.fontWeight token from 400 to 500, the browser sees a text node with the following styles:

.text {
	font-family: var(--body-italic-font-family); // "Proxima Nova"
	font-weight: var(--body-italic-font-weight); // Previously 400 now 500
	font-style: var(--body-italic-font-style); // "italic"
}

It looks up the @font-face for that combination. That matching rule does not exist because font-face setup is not dynamically reacting to the typography tokens. The browser tries to display something that looks like what you wanted but you don't get the expected result. What you eventually get displayed is hard to predict, and might break readability in some contexts. The browser could choose to swap your font for a fallback, or to change the weight of your snippet to match one of the existing combinations in the font-face, or even to perform a font synthesis.

On a side note, updating the font size, the line height or the letter spacing should not be a problem since these parameters are not dependent on the font file being loaded.

In the end, the token pipeline breaks silently. Everything looked fine on Figma, the modification seemed benign, and it only broke at the last step when you, the designer, see the typography issue on the website.

The perfect solution to this problem does not seem to exist yet. It's not that easy to make the @font-face dynamically react to the token change because you would need to dynamically specify a location for a font file (among other things).

Some popular design systems have come up with (mostly partial) solutions to this. Following or not their example will depend on the specifications of your own design systems.

In part 2 I'll compare the pros and cons of popular design system approaches.

8 steps to better accessibility

2026-02-23T00:00:00Z

For 2 years, I was working at a French publicly funded company building software for tens of thousands of teachers and culture professionals, and for millions of French teenagers. As a front-end developer interested in the matter of web accessibility, I organised accessibility audits, then did follow-ups and corrections, I participated in accessibility planning and in choosing new tools, and I helped setup a new design system.

Inspired by Joel on software, and reflecting on that intense experience, I built a set of 8 accessibility questions to ask in order to evaluate a company's capacity at developing accessible software. Those questions have simple yes or no answers, yet they're not always easy things to do. I believe that they encapsulate what I witnessed in the last few years.

Answering "yes" to less than 6/8 of those means your company might not release accessible software anytime soon.

1. Do you have an accessibility bugs database?

Is there a document where all known accessibility issues of the product are listed? Not everyone reads accessibility audit reports (if they exist), and not everyone tests the app on a regular basis. There needs to be a document for teams to know what fix could be integrated in their development process. A single source of truth that might just be a notion table or an excel spreadsheet that's kept up to date and that's easily consultable by product teams.

2. Do you fix known accessibility issues before building new features?

When a team is working on a new feature, do they fix the known accessibility issues related to that feature's scope first? If you answered "yes" to question 1, you do have a database of known issues. Is that source of information consulted before building a new feature? For example if the team was adding a section to a form on a page that's not responsive, would that page be made responsive at the same time? Another way to frame the question is: "Is there an effort to reduce the accessibility debt?".

3. Do you have a monitored accessibility feedback channel?

Ultimately you're doing accessibility for the users. When a user is unable to do an action, they will likely want to tell you about it. There needs to be an easy way to send a message from the app to the accessibility team (or to the team in charge of that part of the app). If you are using a third party assistant (such as a chatbot), you need to make sure that its UI is also fully accessible. You should at least have a dedicated email address to which people can report accessibility problems. Finding that communication channel should be possible in a reasonable number of clicks from anywhere in the app. And most importantly, there needs to be someone on the other end of that channel that reads the complaints.

4. Do you consider diverse experiences while testing?

The "R" in the accessibility P.O.U.R. principles stands for "Robust". It means that your product should account for a wide diversity of usages. It's impossible to predict what combination of hardware & software will be used to access your website. Therefore, you need to have as much diversity as possible as early as possible in the creation process. Do you test the software with disabled people? Do you test the website on different operating systems, on different browsers, with different devices? It's common for modern teams to be using only MacBooks with chromium based browsers, which is only the setup of 2% of screen reader users.

5. Can everyone in your product teams use basic assistive technologies and audit tools?

Can your designers, developers, QAs and product managers go through a page with a screen reader? Can they tell if a colour contrast is high enough? Can they read the automated tests results of tools such as axe-core, headingsmap or lighthouse? Can they open the dev console on their browser? Everyone who thinks about the user experience should at least be able to spot the critical issues that would block a user. Everyone has to learn how to test for accessibility at some point. That's why accessibility testing trainings are essential. And those trainings need to be adapted to different types of jobs.

6. Is there someone with a dedicated budget that is in charge of the accessibility strategy?

You need someone whose job it is to organise the accessibility strategy: plan the trainings, organise the documentation, manage the issues database, keep a roadmap up to date, talk to the leadership about accessibility status, organise user tests and audits. That person absolutely needs to have a seat at the table. If the accessibility evangelist of the company doesn't have a dedicated budget, managers will say that "yes accessibility is the priority of the company" and then allocate no money to it.

7. Do product teams have easy access to accessibility resources that they understand?

Accessibility documentation can be intimidating if not carefully crafted. A designer does not need the same documentation as a developer. Ideally there should be a variety of accessibility documentation so that everyone can find the information with the right level of context. There could also be an accessibility specialist available to answer accessibility questions as new features are being built.

8. Do the teams use accessible building blocks?

Is there a design system (internal or external)? It's necessary (yet not sufficient) that the building blocks of an app are accessible by design. And has that system been audited for accessibility? If there's a UI kit, do the components of that kit have accessibility unit tests? And does the ci include automated visual testing for basic blocks? Is that new select with autocomplete library that was recently installed compliant with WCAG? (probably not)

Chess, chess, chess

2026-01-08T00:00:00Z

I started playing chess on chess.com in 2013. I used to play video games on my computer but after graduating from high school I said goodbye to my digital friends and uninstalled Steam. I was playing what felt like a lot (on average 3 to 4 hours a day), and I was about to move to Paris to begin the classes préparatoires: a two-year intensive Maths and Physics program that prepares students for the French engineering contests.

Unlike the engineering school I later joined, the classes prépa are an extremely old school environment where nothing is digital: blackboards, mandatory fountain pen with black ink, and overhead projectors, but no computer. I was very busy learning about Fourier, Lagrangen Gauss and diagonalizable matrices and had no spare time to played video games. My only distraction was watching YouTube during study breaks.

Still, I was later reintroduced to the game of chess as an adult by the video game influencer Hutch (before his political Twitch career). I was also fascinated by the blitz commentary by Chess Network who has been making videos since 2007. One day I realized I could open a new tab and immediately be playing for 10 minutes against someone else in the world, and I've been playing most days ever since. (Honorable mention to chessbrah who made me feel that playing chess was actually fun and cool)

Playing chess online is very special. Thanks to the Elo ranking system, you are always playing someone who's approximately the same level as you. Playing chess when I was 600 Elo is the same feeling as playing chess at 2000 Elo: it's the same excitement, the same disconnection from time and reality, and the same frustration when losing. Every game is a battle that you fight for the dopamine hit of winning (maybe). But losing a few times in a row makes the rest of your day miserable. So is it worth playing? What's the point in spending thousands of hours doing it if the downside of losing overcomes the joy of winning? (besides learning to recognize flags) (at least, does recognizing the absurdity of it make me more free?)

I don't have answers yet, I just keep playing because it's the default thing my brain wants to do on my computer when I'm not working. I might as well document the journey and set some goals.

I never felt like learning chess theory but for Christmas I got a chess book "1. d4 The Catalan" by Boris Avrukh. In 2026 I'll try to dedicate time to practicing theory. Reaching 2000 Elo in Rapid on chess.com in 2025 felt like an accomplishment. This year I'd like to get closer to 2000 Elo in Blitz. Happy new year!

Frontend virtualization, performances vs accessibility

2025-12-28T00:00:00Z

I recently subscribed to Frontend Masters and started watching some of their online courses. I've been following the "expert" path and am pretty happy with the quality of the content for now. However, one of the courses I initially subscribed to left me puzzled.

The course is called "Frontend System Design". It was released in 2024 and focuses on Observer APIs, networking, optimization, and virtualization. It ends with a mock system design interview that is especially interesting in how it dissects a part of the frontend hiring process that is rarely documented. During that interview exercise, the teacher reuses what's been learned during the course and designs an infinite scrolling card feed with virtualization.

During the final Q&A session, he mentions how that method of virtualization is inaccessible, and briefly explains why. It annoyed me a little that the one course I was looking forward to as the pinnacle of frontend systems knowledge would knowingly ignore the accessibility of the solution. It's just a mock interview and it does not represent the state of the industry, but it made me want to dive deeper into virtualization.

Inaccessibility of virtualization

Virtualization is an optimization technique for the rendering of very long lists of elements. To minimize the number of elements rendered, a virtualized list only displays what's visible inside the user's viewport. When the user scrolls down, items from the top of the list are reused to make new items appear below. The list is positioned in a new layer and CSS transforms are used to reduce the number of re-paint of the absolutely positioned elements.

The problematic word above is "visible". If only what's visible by scrolling is rendered, it means that you have no information and no interaction is possible with other items in the list.

Using a keyboard, elements other than the ones in the viewport are not reachable.
When navigating via headings or links, only a subset of the actual content is available.
Using screen readers, the count of items or the current position are wrong.

These are the first few things that I can think of, and I don't see obvious adjustments to fix them. There is a fundamental misunderstanding. Virtualization is an optimization of what we see on the screen, as if any other element of the render tree were a useless overload consuming memory. I have learned that considering accessibility when building an interface often translates to asking myself "does this still work without a screen and a mouse?".

State of the art

The most popular libraries react-window and react-virtualized were created to implement this pattern. I'm pretty sure they solve the problem incredibly well for many users.

But looking at accessibility issues on react-window's GitHub, there's one from last September that was opened because <li> tags were not direct children of <ul> tags. Another one from 2023 was closed as "not planned" because it points out that a focused element will lose focus when the user scrolls (because the whole item is deleted from the render tree).

On the react-virtualized GitHub page, accessibility issues are not addressed.

I couldn't find any blog post mentioning how virtualization raises accessibility concerns, while it seems to be a widely used solution. As of today, the two libraries mentioned are dependencies of respectively 2313 and 1667 other packages on npm, with a total of more than 3M downloads weekly.

Optimization is about compromise

Optimization is about compromise. But it's not performance vs accessibility unless developers and designers voluntarily lock all other dimensions to treat it as a binary trade-off.

The most accessible solution tends to be the one that uses the native power of the platform. This is because an accessible solution is one for which browsers and assistive technologies work well together and follow the underlying platform specs. Thus pursuing accessibility often means reducing performance costs.

Yet I've noticed that optimizing without caring about accessibility often leads to over-engineered solutions that end up worse for the user.

That's what I felt when watching the virtualization from the Frontend Masters course: I learned a lot during the course, but if an engineer in my team suggested that JS-intensive solution to fix a render performance bottleneck, I'd push back. Maybe a pagination would work? Also why is there so many elements in the DOM to begin with? I'm sure there is are discussions to have here.

Virtualization is the heavy yet easy solution. I get it. For an engineer, virtualization is satisfying to implement. And it's such a common pattern now that finding alternatives is frustrating as it's an attempt to get out of the accessibility vs performance opposition by going back to something simpler.

This negative sentiment of going back is the hard part. And it's one of the things we need to work on the most as senior frontend developers.

The articulation of design and engineering

2025-12-16T00:00:00Z

"Design Engineer" seems to be the most popular umbrella title right now for people working at the intersection of design and front-end development. However, it's hard to understand what it covers when reading job listings and blog posts. Everyone seems to define it by a different scope and a different skill list.

What is certain is that it's about bridging the gap between software development and design in the context of building digital products. Some talk about a great divide between the front-end of the front-end and the back-end of the back-end. Yet something feels wrong. If it were that simple, why can't we agree on a definition?

I worked for 4 years in a startup as a front-end engineer in charge of the front-end development and design, and then 2 years as a senior front-end engineer focused on accessibility and design systems. I can describe what articulating the design and engineering worlds together felt like, and what issues the role emerged from.

Design tools abstract away the web platform

Web browsers are a complex stack of technologies and a confusing stack of specs. Product designers have a lot on their plate already, it's materially impossible for them to have a deep understanding of the platform. The web has strengths and limits that are not obvious from browsing the web and by using tools such as Figma.

It's obviously not a skill issue, in order to co-create a high-quality product everyone needs to limit their area of expertise.

If Figma was as precise as HTML, CSS and Javascript in describing interfaces for the web, the tool would be the web itself. And it is normal that the design tools constitute a level of abstraction. The gap between what's designed and what's then built by the developer is wide enough that a structural misunderstanding exists between engineers and designers.

Are good product designers expected to know the difference between focus and focus-visible on interactive elements? Yes they might, but should they know that most browsers do not differentiate the two on input HTML tags? Or that a focus-within that is also a focus-visible should not be used because the CSS property :has is only supported by 91% of the company's users? Probably not.

Yet the designs are (mostly) created in Figma and then handed to the developer who has limited time to produce the implementation.

Front-end developers lack design context

The design being viewed as descending upon the front-end developer, the developer must implement it. What can be built takes precedence over what should be built. The responsibility for design choices is eventually borne unilaterally by designers.

Should this icon color be added to the app even though it doesn't match any pre-existing color? That dialog has a title that does not match the common pattern, is that a new design directive or a mistake from the designer? The developer lacks knowledge of design decisions, the new design system foundations or a new accessibility pattern. And challenging the design might delay the feature by a whole cycle.

At some point, someone with the technical expertise and a product-level understanding of the existing patterns must voice an opinion on the design. Someone who knows how UIs are built across that product.

The articulation

The argument here is that there is a gap in knowledge and understanding that cannot be filled without a new articulating role and vision. The tools and tech stack have become so complicated that no one covers both design and front-end development as 2 separate people would. It is not just "front-end of the front-end" that is needed here, because a global vision is required.

The role needed is of a front-end developer who has a good technical understanding of the product, who is able to collaborate with designers, to write documentation for different audiences and to navigate between teams.

The person in that role has two different approaches to the same problem. When the designers want a new pattern introduced, that person helps define it in a way that is compatible with the technical constraints. They can then implement those patterns and promote them to the engineering teams. They produce two different forms of documentation, because the reasons why a designer understands the importance of a guideline is not the same as for the developer.

Every company has a different approach based on their needs which can vary depending on the skills of their employees. There isn't one recipe, there isn't one divide. That's why so many job titles exist : Design Engineer, UX Engineer, UI Engineer, Design System Developer, Front-End of the Front-End, etc.

My experience made me realize the need for a role with a wider perspective. Someone who works across teams and operates in both design and engineering.

Inaccessibility first

2025-02-16T00:00:00Z

A non-negligible proportion of developers code with the help of generative AI. According to the 2024 stackoverflow study, 62% of them used AI in the development process during that year, and even more are planning on using it in 2025. That's a reality that should be questioned and challenged, of course, but that should also be analysed as a trend that is not on the way out.

I notice this at work when reviewing pull requests that have completely or partially been written with the help of a generative AI. As one of the developers responsible for ensuring the accessibility of the features deployed to production, I review a lot of the code that's pushed. I'm often surprised by the poor attention to accessible code, especially when it's a snippet that I suspect has been produced with a help of a language model. If we let the AIs code without careful reviews, we would very quickly have less inclusive user experiences.

An AI Assistant does not think, it does not reason nor does it hallucinate. It uses a model that projects text into a space where are identified the most probable following words that would constitute an answer. If you ask it to give a more friendly, more serious or more WCAG 2.2 compliant answer, it will transfer the answer along a vector, and generate another text that will probably be more aligned with what is expected.

The web being notoriously a widely inaccessible place, and the generative AI models being trained on it, generated HTML code is most likely inaccessible, thus inaccessible by design. According to webaim.org:

Across the one million home pages, 56,791,260 distinct accessibility errors were detected—an average of 56.8 errors per page. The number of detected errors increased notably (13.6%) since the 2023 analysis which found 50 errors/page.

As long as the web remains that way (and we are only talking about home pages, not even forms, videos, canvas or data visualisations), there is no way a LLM would provide accessible HTML code. And the situation tends to worsen with code being continuously generated and deployed to the internet.

I have no hope for generative AI to be a net positive for users in the future. I still wanted to see how severe the situation is, so I tried asking DeepSeek, Claude and ChatGPT to build HTML ans JS code for a multiple select form input. And see how far it is from making something accessible. I used the free versions of the models, thus I don't expect the best quality answers (although it should not be that far from it), but it still gives me a good representation of what developers are using.

I provided the following prompt to DeepSeek V3 (I also generated the prompt with a generative AI because that's the level of degeneracy prompt engineers (?) recommend to be at).

Write HTML and JavaScript code for a multiselect form element. When a user clicks a trigger button, a dropdown should open, allowing the user to select multiple countries from the following options: 'France', 'Italy', 'Spain', and 'Monaco'.

The model generated the following HTML snippet (along with a ton of javascript, css and explanations):

<div class="dropdown">
  <button onclick="toggleDropdown()">Select Countries</button>
  <div id="dropdownContent" class="dropdown-content">
    <label><input type="checkbox" value="France" /> France</label>
    <label><input type="checkbox" value="Italy" /> Italy</label>
    <label><input type="checkbox" value="Spain" /> Spain</label>
    <label><input type="checkbox" value="Monaco" /> Monaco</label>
  </div>
</div>

I'll be honest it looks better that what I expected. It at least did use appropriate semantic HTML tags! But that's all there is to say that's good about it. The keyboard inputs are off, the dropdown pattern is nonexistent, the opening and closing are not announced to assistive technologies, the dropdown closes when an item is checked etc.

It is really not good, and good luck debugging why, when you have this multiselect in a form and you press "Enter" while focused anywhere, the dropdown opens instead of submitting... (A button has the default type "submit", and pressing "Enter" triggers the first submit button within the form tag.)

"Hey but you should not expect it to work as is, it should help you get to a viable solution. Also good prompting would involve asking it for an accessible experience!"

If I'm using a generative AI to build an HTML component, I probably have limited knowledge of how to do it. And the chances that I would go deeper than the visual aspect and an acceptable mouse experience are low. But let's give DeepSeek another chance, maybe the secret sauce of a11y prompting is to ask explicitly that we want HTML that works for everyone. My guess is that we have to tell it exactly what to do, so much that writing the code yourself is faster.

Hey it seems that this code is not very accessible. I want to create a user experience that is as inclusive as possible. Do you think you could re-write the code but with that in mind ?

And I got this HTML snippet:

<div class="dropdown">
  <button
    id="dropdownButton"
    class="dropdown-button"
    aria-haspopup="true"
    aria-expanded="false"
    onclick="toggleDropdown()"
    onkeydown="handleButtonKeydown(event)"
  >
    Select Countries
  </button>
  <div
    id="dropdownContent"
    class="dropdown-content"
    role="menu"
    aria-labelledby="dropdownButton"
  >
    <label role="menuitemcheckbox" tabindex="0">
      <input
        type="checkbox"
        value="France"
        onchange="updateSelectedCountries()"
      />
      France
    </label>
    <label role="menuitemcheckbox" tabindex="0">
      <input
        type="checkbox"
        value="Italy"
        onchange="updateSelectedCountries()"
      />
      Italy
    </label>
    // [...]
  </div>
</div>

<p>
  Selected Countries: <span id="selectedCountries" aria-live="polite"></span>
</p>

Let's gooo, so many more attributes ! As a developer who doesn't know much about accessibility but who cares about providing an inclusive experience, I might stop there and consider that my job is done. Unfortunately, this HTML code is almost as bad as the initial snippet. It is a mess of patterns projected through attributes on those poor HTML tags.

As I am myself not a WCAG expert, I might not be able to explain all the intricacies of what patterns that code is going for. If I'm careless or pressured by time, I'm more inclined to trust what the chatbot generated.

What I am used to saying to junior frontend developers who tend to write a lot of code is that they should be able to explain every line they write. When creating a pull request, I recommend that they re-read every change and are ready to justify every change.

You can ask the AI to generate text explaining every piece of a line of code, but it will not question its own quality unless you force it to. You have to do the work yourself in the end, there is no escaping for reading the docs of what the role="menu" does, or for example I asked:

Can you explain this line in more details:
<label role="menuitemcheckbox" tabindex="0"> <input type="checkbox" value="Monaco" onchange="updateSelectedCountries()" /> Monaco </label>

DeepSeek answered with 100 lines of explanation of what every little piece does. It's crazy to have been trained on all of the docs that exist, being able to restitute them on the fly, but still consider that tabindex="0" on a label containing a checkbox input (that btw is the element bearing the onchange attribute) is any good. And I'm not mentioning that the misuse of roles menu and menuitemcheckbox.

I have asked the same questions to ChatGPT and Claude, and got same kind of results with and without accessibility encouragements. And I'll spare you the 200+ lines per chatbot of reasoning that lead nowhere.

It doesn't work and it cannot work, LLMs are made to restitute a well formed soup of all the things that seemed to be valuable code in the training sets. I even less believe now that coding assistance can do more than what automated accessibility testing already does.

It is so assertive though... It takes so much effort to convince stakeholders that real people should be spending time working on accessibility that I'm pretty sure LLMs will be the easy yet broken solution in the next few years. Good news: after the bubble bursts my job will still exist, bad news: user experience will suffer.

A Tool for Creating More Accessible Design Tokens

2024-12-08T00:00:00Z

Building an internal design system at my company is an exciting position as it pushes me to dig into the frontend and design decisions history as much as it frees space to reorganise parts of the apps.

Both frontend engineers and product designers work to bridge the gap between today's users needs and yesterday's users needs, and the design system is a powerful lever for achieving this.

At my company, the design system started with a set of design tokens. Crafting a cohesive system of tokens is challenging since it must be understood by everyone as clearly and quickly as possible. And each set of tokens comes with its own challenges. For instance when choosing colours for a product, considering the contrast ratio in-between text colours and background colours is essential.

Yesterday's user and today's share the need for an accessible experience. Measuring accessibility is tricky, and companies are often more interested in measuring the conformity to a norm. A number of guidelines can be considered : (Globally WCAG 2.2, and in my context the French guidelines RGAA (Référentiel Général d'Amélioration de l'Accessibilité) and the Luxembourgeois guidelines RAAM (Référentiel d’Accessibilité des Applications Mobiles)). These guidelines can be cryptic and asserting the conformity of the hundreds of criteria takes forever.

As far as colour contrast is concerned, each have its own way of assessing the accessibility of text over a background. The ratio itself is (for now, and as far as I know) aligned with WCAG 2.2 AA criteria, but the definition of "large text" varies.

To overcome the complexity of assessing the conformity of a set of colour design tokens to various accessibility guidelines, I built a design tokens contrast checker grid that is available here. This type of tool already exists, but they are very often inaccessible themselves and don't offer options for alternative validation methods. Also I don't know if there is a colour contrast grid trend right now but Dave Rupert just created a codepen contrast grid.

The options of the first version of my website are limited, but I plan on adding more tokens import options and more contrast checking mechanisms. A question has kept me up at night (at least one night, reading through github drama). WCAG 3 is being discussed, and I'd like to be up to date with the official contrast verification guidelines. Especially because it will likely include a new method of verification, and it will diverge from the French RGAA to which my company will still need to comply to.

In the WCAG docs another algorithm is mentioned : APCA. It's a promising method that takes into consideration the non-linearity of human perception when looking at colours. However some people raised concerns regarding the method, and other techniques might be under examination. Yet some people think that APCA it is going to be the WCAG 3 choice for sure. Although the last update in Eric Eggert's blog post about WCAG 3 states that according to the Accessibility Guidelines Working Group Co-Chair: "APCA is not in the current draft".

Adding that algorithm to the checker I built could be very useful, regardless of whether it's included in WCAG 3. But it seem impossible to officially implement an APCA tester without stating what the author wants. I'm not sure I understand the need for an integration compliance document for an algorithm that would be part of an official WCAG. To be continued..

3 lines for 3 dependencies

2024-08-15T00:00:00Z

At work this week we noticed that the package react-autosize-textarea of our React frontend app had dependencies that were not kept up to date. A quick look at the github repository showed that the last release was in 2018 and that it has been archived in March of this year. Which led us to look into why we needed that library 🤔.

The react-autosize-textarea library exports a React component named "TextArea" rendering a regular <textarea> HTML tag which height will resize based on its content so that a user will not have to scroll vertically within the input. It receives 3 props : the minimum height in rows, the maximum height in rows and a onResize callback.

Among the three dependencies of this package, there is "line-height" that gets the actual line-height of the text within the input and with which is computed the max height allowed. And another dependency named "autoresize" that actually does the work of computing the height of a <textarea> so that it matches the inner scrollHeight. Our react-autosize-textarea does not much besides being the React abstraction of the "autoresize" package.

After looking at what's done in autosize and the various articles on the web, we found a simple and accessible solution to replace the library.

On a side note, we excluded these solutions : computing the inner height with the number of "\n" occurrences does not work because of blocks of text that are displayed on multiple lines, and the contenteditable span solution doesn't work for us either because the French accessibility guidelines (RGAA: Référentiel Général d'Amélioration de l'Accessibilité) makes us build a UI that also works with CSS disabled (in which case the fake input cannot be identified as an input anymore).

Within our React TextArea component, we have a ref on the HTML input named "textAreaRef" and a rows prop that's passed to the input.

function updateTextAreaHeight() {
  if (textAreaRef.current) {
    //  Reset the textarea height to its initial value based on the 'rows' props before reading the scrollHeight
    //  so that the input is able to shrink back to its smallest height
    textAreaRef.current.style.height = `unset`;

    const scrollHeight = textAreaRef.current.scrollHeight;
    textAreaRef.current.style.height = `${scrollHeight}px`;
  }
}

We update the size of the input on init of the React component and whenever the value of the input changes. Inspired by what's done in the "autoresize" repository, we use the scrollHeight trick to know the actual height of the content. And we reset the height to unset and not 0 so that our rows props is still the minimum height. Now if we wanted a maximum we could simply compute the maximum height in pixels based on the line-height that's obtained by dividing the <textarea> height when its height is unset, knowing the minimum number of rows. Something like :

//  ...
const clientHeight = textAreaRef.current.clientHeight;
const maxHeight = (maxRows * clientHeight) / rows;

const scrollHeight = textAreaRef.current.scrollHeight;
textAreaRef.current.style.height = `${Math.min(scrollHeight, maxHeight)}px`;

That solution may not work for everyone, but the minimal React use case does not require any third party library, unless there's a need for a more robust browser compatibility. The solution we choose is not cutting-edge technology, then why did we choose to download that library in the first place ?

In an older codebase such as ours where most of the code was written by people that are not here anymore, it's hard to find precise answers. But I'm not surprised by the initial decision. As a frontend team we are fighting against wild libraries that have been installed in the last 6 years and that we have to maintain today.

I suspect that there are 3 different problems here :

Everyone is focused on their team's delivery and not enough people do the tedious work of monitoring and evaluating each dependency on a regular basis.
Many frontend developer think that installing a library is - most of the time - the best solution to their day-to-day delivery problem. I've had the same debate multiple times : beyond all security/bundle size questions, is installing a dependency more maintenance work or less maintenance work ?

I believe it is more maintenance most of the time. Every week we have dependabot failing at upgrading some library for reasons completely unrelated to the 3 lines of code that we actually depend on. While I have multiple examples in the codebase of homemade snippets that have never changed and that were chosen instead of a third party library. Because the 3 lines that we wrote ourselves match exactly what we need them for.

Now, there seem to be two reasons for people to prefer installing new dependencies : it is very satisfying. In the React ecosystem, it is especially easy to plug in a new library that brings a lot of value to the user immediately with limited costs (reading a few lines of documentation).

Also people have taken the gaussian meme of dependencies a little too seriously : as a junior developer, you start by installing all possible packages. Then you understand that making everything yourself offers more control i.e. customisation and optimisation. And eventually you realise that some harder things have already been solved and that you shouldn't reinvent the wheel every single time.

There is a nuance to the last stage : identifying what's hard enough, so that it is worth all the maintenance, security, accessibility and code size questions is subtle. For example, building a complex dropdown menu from scratch may not be worth it for accessibility reasons. Same goes for building your own highly customisable range picker if you have 1 week sprint to make it work.
The systematic need for React wrapper library is a little extreme. We probably shouldn't use them as much as we do because we all know enough how a React component lifecycle works to build our own. And when I see that react-autosize-textarea has 150 000 weekly downloads I'm puzzled.

We all try to be careful and to make the best decisions for the future of the codebase. The evaluation of existing packages and the discussion around the new dependencies should happen. And since we may be at a point in time where the well used React wrappers maintainers communities are progressively dying after 5 to 10 years of loyal services, let's be even more careful 👀.

Everything I missed

2024-05-20T00:00:00Z

Last time I worked on this website, I was confident I had built something clean, well designed and accessible. Returning to it after a year learning about accessibility, I realize I had made a few mistakes.

Making websites accessible is challenging. I work at a company that needs to comply with the RGAA (the French guidelines for web accessibility). It’s a set of rules inspired by WCAG, the latest version being equivalent to AA in terms of compliance. However it presents things a bit differently.

The French guidelines seem to give more room for interpretation. Last week in the RGAA mailing list exchanges someone asked if in a form (in French) with an email field, the label « E-mail » is clear enough, or if giving an explicit example is required. One would expect that there are enough email inputs out there to know the best practice for accessible labels. (After endless yet gripping discussions, consensus seems to lean toward the additional format example. One reason being that in French, there are a ton of ways to say « E-Mail »)

Thus, the habits I have regarding accessibility may not be the same as someone working with WCAG (and I'd love your feedback on that!). Here’s the things I had to fix to make this website more accessible.

Emoji

I had a bunch of emoji that were interpreted by assistive technology as words although they are decorative. If the interpreted text does not make sense, it's important to either add an outer span with alternative text or ignore the emoji with aria-hidden="true". I now even avoid using them to convey meaning because they don’t look the same based on context.

Links

Before my review, all the links would open in a new tab without any indication. Opening a link in a new tab should not be the default behavior. When I learned that target="_blank" would do just that, I started using it everywhere. But users should be able to choose how they want a link to open, and opening in a new tab can be disorienting for someone navigating with assistive technology.

I’m using hexo as a blog templating tool, and the build step sets all links as opening in a new tab. To fix that, I explicitly set all blog posts links to open in the current tab, and for the few links left opening in a new tab I added an icon next to the link with an accessible text describing the behavior.

I also had some links with the url as a name. Showing the full url as the name of a link will force the assistive technology to interpret all the characters. Thus I made sure links all have explicit names.

Text

I had my default font-size set to 16 pixels on both the html and body elements. I don't remember if I added that myself or if it was already in the CSS reset file I copy-pasted from somewhere, but it's not good! The default font-size of the website should not be set in pixels, otherwise changing the default font-size at the browser level will not have any effect on how the text is displayed.

Also I had my line height set to one time the size of the font. Line height should be greater than 1.5 times the font-size to make it easier to read.

Page

My blog post pages all had the same title as the home page. All pages should have explicit titles and the information they provide should start with the things most related to the current context. That way a person reading the title from another tab knows faster what's on the page.

I did add a lang="en" to my pages, but I forgot that some of my posts are in French... Therefore I set the lang attribute around the French text in my blog posts.

Alt text

Last but not least, over the years I've added collections of photos without considering alternative text for images. I had added the alt attribute but with meta information. Now all photos and images have a proper description of what's to be seen in them.

Now, I'm pretty confident I have a clean, well designed and accessible website. See you next year for a new set of fixes .

An interactive map for investigative journalism

2022-09-07T00:00:00Z

In the beginning of 2022, I have built for the Forbidden Stories platform their one year anniversary map of the Project Pegasus initial release. They wanted to make accessible the data related to the (sometimes potential) victims and (sometimes potential) clients of the Pegasus spyware.

The revelations being international and based on geographic data we built a web interactive world map. The experience is split in two distinct parts. First is the explanatory part with a scrollytelling identifying the events that occured during and after the revelations. And then an exploratory part where the user is given full access to the world map so that they find detailed description of every country’s involvement.

The map

In the context of an international investigative journalism project, every element of the map becomes important and not every question is easy to answer. Especially concerning the map itself.

As far as the map projection is concerned, I worked with d3-geo that offers many projection options. We eventually chose the Natural Earth Projection for how it eases the interactions with the map, and does have a convenient scale for the areas where the main Pegasus Project actions are happening.

Deciding upon which border to display is sensitive and the rules are unclear. We went for the most used borders in French mainstream media maps such as Le Monde ones. For the contention over West Sahara for example, Google Maps “solves” it by displaying different borders based on where you connect from.

The accessibility

I’ve had dedicated time to work on improving the accessibility. Accessibility in data visualisation can be tricky because developers are not used to doing it systematically. Many code examples for web dataviz libraries omit the accessible part.

On the internet, 1-2% of people navigate without having JS enabled (maybe even more when it comes to reading articles as users disable javascript to bypass paywalls). As the data of the app is only be accessible through the interactive map, giving a specific access to the information to these users is primordial. I created a separate website that doesn’t require javascript, and that displays the scrollytelling text, images of the map, and the list of links to all countries texts.

Navigation was another concern. Especially the scrollytelling that is not rare, but its use may not be obvious to all readers. I made sure it would be navigable through scrolling with mouse or arrows, TAB, and with buttons. The scrollytelling being displayed as an intro to the exploration of countries, I made sure it’s skippable and that the user can come back to it at any time.

I tested the app with VoiceOver to make sure it’s usable with at least one screen reader to eliminate the most serious mistakes. I know that VoiceOver is not the most used, and that all screen readers don’t work the same way. One of my regrets about this project was not having enough time before release to do it.

Spark AR filters with custom GLSL shaders

2022-01-01T00:00:00Z

SparkAR is Facebook's powerful and surprisingly accessible tool for creating 3D scenes that can be used as Facebook or Instagram filters. For about two years now, SparkAR's team added a SparkSL section to their documentation where they describe an underused tool of their software.

SparkSL for Spark Shader Language is a superset of GLSL 1.0. It's a programming language for shader files (.sca) that can be imported into a SparkAR scene to be applied as textures to objects materials.

If you don't know what GLSL or shaders are, I recommend reading The Book of Shaders. With them, you'll be able - for any material in your scenes - to make visual effects that you couldn't do with textures & the basic shader tools of the grid.

Especially since the size of an effect matters, and the files you’ll create will just be lines of codes and super light compared with actual textures.

We'll build a shader file (.sca) that we'll import into SparkAR and apply to a plane's material to make a very custom and very dynamic texture.

Creating a GLSL fragment shader

To create a fragment shader super easily, let's start by opening https://shdr.bkcore.com, an editor that puts you directly into the code.

Let’s say we want to create a fragment shader that adds a “tv noise” effect to the material. The initial code should look something like :

precision highp float;
uniform float time;
uniform vec2 resolution;
varying vec3 fPosition;
varying vec3 fNormal;

    void main() {
        gl_FragColor = vec4(fNormal, 1.0);
    }

And we’ll add a noise function that does the effect, remove what we don’t need, and add the effect to the normal vector :

precision highp float;
uniform float time;
varying vec3 fNormal;

    float tvNoise(vec2 p, float ta, float tb) {
        return fract(sin(p.x * ta + p.y * tb) * 5678.);
    }

    void main() {
        float t = time + 123.;
        float ta = t * .654321;
        float tb = t * (ta * .123456);
        float tvNoise = tvNoise(fNormal.xy, ta, tb);
        gl_FragColor = vec4(fNormal + vec3(tvNoise), 1.0);
    }

You should get something like this :

We can now save this code in a new file with the extension .frag, for example tvNoise.frag.

Making this shader SparkAR compatible

Now we would like to use this file inside SparkAR and get the same kind of effect on the camera for example. However, SparkAR can not really read .frag files directly, we’ll have to make it a .sca file that requires some changes as far as syntax is concerned.

First of all, to be able to retrieve the global variables such as the position of each fragment, and the time variable, we need to import the std util (see the docs):

#import <utils>

Then replace the corresponding variables in the main function :

vec4 main(vec3 camera) {
float t = std::getTime() _ 10.;
float ta = t _ .654321;
float tb = t _ (ta _ .123456);
float noise = tvNoise(fragment(std::getVertexTexCoord()).xy, ta, tb);
return vec4((noise + 0.4) \* camera, 1.);
}

I couldn’t find a clear documentation for all the SparkSL functions that can be used. I often rely on random codes examples in the rest of the docs that use them without explaining. For example, the only place I could find getVertexTexCoord was there.

The repo sparksl-shader-examples was even more useful than the docs.

Then the tvNoise.sca should look like this :

#import <utils>

    precision highp float;

    float tvNoise(vec2 p, float ta, float tb) {
        return fract(sin(p.x * ta + p.y * tb) * 5678.);
    }

    vec4 main(vec3 camera) {
        float t = std::getTime() * 10.;
        float ta = t * .654321;
        float tb = t * (ta * .123456);
        float noise = tvNoise(fragment(std::getVertexTexCoord()).xy, ta, tb);
        return vec4((noise + 0.4) * camera, 1.);
    }

I also have increased the time by multiplying it, and added the camera input that will be useful in SparkAR.

As I understand, the line precision highp float; is not a best practice, but useful especially on mobile phones to ensure that the shader will get enough ressources to be displayed correctly.

Using the .sca file in a SparkAR project

Now let’s create a new SparkAR project without using any template. What we’ll do is we will make a front panel that reproduces the camera image, but sends it through our shader. Thus we will be able to modify the image as we want.

For this particular tv noise example, it is not really necessary to do all that, but once you’re done setting it up, you will be able to make very custom effects to the camera view.

In the Scene panel, inside Focal Distance, you’ll create a new Canvas in which you’ll create a Rectangle. And you’ll give this rectangle 100 relative width and height.

In the Asset section, add a new file from your computer and select the .sca file you’ve just created. If everything works correctly you shouldn’t get any error in the console.

Then create a new Asset of type Material, and set its Shader Type to the shader file we’ve just imported by selecting Shader Asset.

Now select your rectangle in the Scene and give it the Material we’ve just created. You should see now a black plane fitting the camera in front of the image.

Then select the material, and click the small arrow next to the camera parameter. You should see the corresponding patch appear in the Patch Editor.

We’ll then make a texture asset of the camera by clicking on Texture Extraction in the camera info.

Finally select the texture, and create a patch out of it. In the patch editor, link the RGB output of the texture to the camera parameter of the material.

And you should see now the camera having a tv noise effect. This effect could have been done more simply without creating a separate panel, but now you can tweak the shaders params and see all the effects you can do with this setup.

SparkAR is well documented, unlike SparkSL. After hours of researching in the docs, I came up with this way to quickly make working shaders inside effects. But my understanding of shaders and spareAR are limited. If you know any more efficient way to do all this, please let me know 💝.

Groix 2021

2022-01-01T00:00:00Z

Pour la documentation de la collection André·e Lawrance *Beginner*, je suis allé le temps d'un week end avec 4 amis sur l'île de Groix en Bretagne. La plupart des photos des vêtements ont été faites avec un appareil numérique, mais j'avais aussi apporté un appareil argentique (Cannon AE-1) pour montrer l'envers du décors.

Finalement beaucoup des photos argentiques ont servi à la promotion visuelle sur Instagram @andre.elawrance.

Making bags for strawberry picking

2021-08-26T00:00:00Z

The goal is to make bags for André·e L. that are solid and convenient. Unlike those made for the first chapter, these should be waterproof, thick and not too big. Perfect for the city market or strawberry picking in the rain.

During summer, I went to Brittany and took a few pictures. I went to La Pointe Du Bill to shoot a sailing class, and to l'île d'Arz to get some hydrangeas pics. A collection of the pictures taken is available here. With those, I made large digital collages, and printed them on waterproof fabric. The print was made with Contrado which I tried ordering at for the first time. For the fabric I chose (Tissu imperméable respirant 155g/m²) the result is really worth the price.

I then cut the fabric, and sewed the bags along with a layer of a dark blue satin on the inside. The result is soft & strong & cute.

It's always hard to find the right fabric for a project. Even though I live down the street from the largest Parisian fabric shops, it's the discovery of a fabric that sparks the will to make a project, and rarely the other way around. And buying fabric online is quite scary and ends up more expensive. I'm glad it was actually pretty easy to print custom fabric, and I'm glad the result matches the expectations!

Brittany Summer 2021

2021-08-26T00:00:00Z

In the summer of 2021 I went to Brittany to see family. I took a few pictures of the landscapes near Séné.

A·EL-B Chapter 2

2021-07-29T00:00:00Z

In 2020 I started sewing again. I made my first jackets based on a pattern I drew from a second hand jacket I found at a Guerrida shop.

I've been willing for 2 years to make a sewing project with some kind of data visualization involved. Since I saw the Arte documentary "Fashion Geek", I follow and admire the work of Clara Daguin and Ying Gao. They both include elecronic devices in clothes to convey impressions, and to explore the interfaces between body and technology.

I've been making 2 jackets, 2 shorts and I'll try to make 2 hats and 2 bags. I want to use geospatial sensors attached to the clothes, and then use the data to produce sounds made of samples. The sound would be linked to the movement. For this I need to do a few things :

Find or draw appropriate patterns
Sew the clothes
Setup the sensors with a Raspberry Pi
Setup the server that saves the data
Build the interface that reads it
Write the algorithm that produces the sounds
Record the movement of the clothes and film it
Create a video with both sound generated and images

None of this points is finished yet, but I've started working on all of them.

To be continued...

🙋‍♂️

About this website

2021-07-29T00:00:00Z

Oops I did it again... Making this personal website again is probably a waste of time. But the previous version that I made a year ago was too much inaccessible. I would avoid opening it on my phone when my power level was too low, or the ReactJS + ThreeJS + unoptimized GLSL Shaders would kill it.

Thus it was painful to update any content. This time I tried a new exercise, instead of making something cool that barely works, I tried to make something boring that works everywhere for everyone. Even the fact that I've had this thinking is unoriginal as an (almost senior) front-end developer.

I need a space to document what I do as a front-end developer, as a creative data-visualization developer, and as a sewing amateur. For this, I was inspired by simple yet effective personal websites/blogs in the tech world.

I used hexo as the base for creating a blog-friendly website with my own custom template. Even tho the documentation could be clearer it does the job well and I enjoy building it.

But hexo plugins didn't offer what I was looking for as far as images management is concerned, besides a lazy-loading plugin (the problem being that loading images is what takes the most times). I tried building a S3 with a serverless image handler, like adults do. And I couldn't. It reassures me that I'm not strong enough mentally to be a back-end developer. I'm too much afraid that one of the 100 services set up doesn't have the right security or isn't adapted, and I'll end up paying 1000s of dollars for a small mistake.

I found out that Flickr allows you to store 1000 images for free in any resolution, and they automatically create tons of different resolutions for each images that can be retrieved with a simple param in the url 🎉 Which is all I asked for.

You can find the code for this blog here.

🙋‍♂️

Data Humanism - A case study

2019-05-14T00:00:00Z

Data humanism

Data is an imperfect abstraction of the world. We use blindly this interface as reality itself. This is obscurantism and data humanists are here to switch the light on.

The world is made of complicated mechanisms and interactions. Thus, the data capturing the world is also complex. But do we always consider this complexity when working with data ?

In Big Data projects, a piece of data is just one more line. The more lines there are, the more credible the dataset is. The line itself is no more than a drop in the ocean and does not represent anything anymore. It has no specific form, and gives us very little hook on reality. Data is a magic plasma which we feed to data visualization tools which then recommend us the best way of depicting it.

As far as data visualization is concerned, especially dashboards in which each widget answers a specific question and gives a limited amount of information, we hope to explain complex phenomena with generic questions and formatted answers.

Most of the time, data is just what we take from the world to answer our most valuable questions. We lose the sense of what data represents. Thus, its complexity in not considered.

Maybe using our digital tools to find answers to generic pre-existing questions is not the only way of behaving with data.

Let’s say I have an app which tracks how many kilometers I ran in the last month. I chose a bar chart to show the distance in km for each week of the month. It is a valid design which gives valid information. It answers the question : “How many kilometers did I run each week ?”. However, it’s only valid and nothing more, because it doesn’t try to mean anything else than what it shows. Maybe one bar in the visualization matches with hours of physical effort in various places with various people feeling various emotions.

Data humanists like Giorgia Lupi, who wrote a manifesto, say the bar chart is not the issue. The fault is ours, willing to show an inherently human piece of information without considering the human. To find the human in the dataset, they suggest ways to reincorporate empathy at different levels of the data handling.

Guidelines

Unlike the traditional approach in which questions are asked and answers are found, data should be contextualized. “Sneak context in. (always)” says Giorgia Lupi. The process of analyzing the data while thinking about its possible visual representations will hopefully reveal the substance of the context.

This is why we have to reclaim a personal approach to how data is captured, analyzed and displayed, proving that subjectivity and context play a big role in understanding even big events and social changes — especially when data is about people.

Manually collecting the data makes it more human. Generally, normal data engineers would find an available dataset that suits their needs. But by carefully making it on their own, they would not forget what data represents. Moreover, in trying to have a more humanist approach, there is no need for any specific set of data. In the case of the running app above, the goal is just to translate the experience of the runner into an abstracted visual form, thus no specific form of data is recommended.

Stefani Posavec suggests in her talk at Eyeo 2018 that the gathering of data can be a worthwhile activity in itself. And she rehabilitates what she calls anoraks providing very personal examples.

Then, the data analysis process can be partly done by diving into the dataset. Doing data visualization hand sketching at the same time may reveal the set’s underlying structures. With this way of mixed analysis and design, the usual data driven designs paradigm might be dodged.

Even after the data visualization design is done, the data analysis process is not over yet. The design’s purpose is to depict complex phenomena, therefore part of the analysis work should be left to the reader of the design. This is what people at Accurat call non-linear storytelling. The users are invited to pick their information and to make a story out of it.

A more human running app

I like running a lot. And when I discover a city, I try to find nice running tracks, both to exercise and to discover the places I visit. I sometimes use a running app that tracks my runs and sums it up into data visualization designs. Of course the running apps are mainly made for athletes who want to have reports about their performances, therefore the designs are non-humanistic. As I am not an athlete, and now that the data humanism rules are a little clearer to me, I have tried to design my own running reports.

The reports in the original running app gives three types of visualization design. First a bar chart giving the km ran in the last weeks, like mentioned above. Then a map, where the circuit is highlighted, with gradients from green to red depending of the speed. And finally line charts giving many other insights on the last run.

I am sensitive to colors as general impressions. When I think about the tracks I’m used to running through, I imagine a series of colors. In Paris, I imagine the beige of the buildings with the grey of the Seine and the intense blue sky.

For the data collection, I decided to go through my usual tracks on google street view, and to choose at each kilometers the color that strikes me the most.

Now my data is made of a series of circuits, and for each of them a series of colors.

Just like most people on earth, I rarely run without listening to music. And I also see the albums I listen to as shades. Therefore, for each one of my last 9 runs, I wrote down the music I listened to and gave it colors.

For each of these runs, I also gave three types of feedback. An environmental feedback, from 1/3 for a poor running environment at that time, to 3/3 for a great experience. A physical fulfillment feedback, 1/3 for physical hard times, and 3/3 for perfect conditions. End eventually a psychological feedback, often linked to the music I listened to.

I also added to my personal data various indicators like the length of the tracks or its difficulty.

Then, I had to find interesting ways to squeeze the data and to shape the design so that I could achieve a visualization that translates my running experience. I wanted to give a colorful feel for each of the runs.

The fact that I decided to make a (slightly) interactive website with the library d3.js is not insignificant. One of the themes of data humanism is that technology and data should drive as few decisions as possible. And displaying the unfixed result through a digital interactive medium (with a library meaning literally ‘data driven’) means that technology has given structure to the design.

However, in that case study, I used the JavaScript technology to enhance the storytelling by adding interactivity. A click on any color element related to a specific music opens a new tab with a YouTube video playing that music.

A click of the mouse, a tap with the thumb or the mouse going over an element are all dimensions added to the space of the stories that can be told through the design. And as a first attempt to data humanism design I hope that at least some running stories will be read through my experiment.