DEV Community: Sylvain Hamann

GPT is my new BFF (Backend for Frontends)

Sylvain Hamann — Tue, 28 Mar 2023 19:58:44 +0000

As a front-end developer I encountered several types of backend during my career (e.g. GraphQL). They were written with different languages (e.g. Rails or PHP). I don't consider myself as a fullstack developer, I always prefer focusing on crafting the UI.

I saw people asking Chat GPT to answer with a JSON formatted response:

This is clearly an example of BFF (Backend for Frontends) pattern.
It means we could now create a lot of projects without having to worry about having a dedicated backend or database!

This is exactly what I did with Daily Kanji. It will prompt GPT to return a random Japanese Kanji and its translation as a JSON. A scheduled GitHub action (similar to a CRON job) will create a new video everyday thanks to Remotion, a React framework to programmatically render videos. The video will then be published on Instagram.

With this kind of setup you don't really need to worry about your OpenAI API usage since it will only run once a day. During development you should rely on a JSON mock so you don't need to query OpenAI each time. With all my local tests an production runs I did not even reach $1.

Instead of generating daily videos you could have some sort of daily quiz similar to Wordle. Your only limit is your imagination!
With frameworks such as Astro you can generate a new static build each day based on data generated by GPT. The data would again be only fetched once at build time via a scheduled deploy. If for any reason the request failed or the data does not have the expected shape then you could cancel / retry the job.

Something that would require further explorations: how to make sure each JSON is unique? For now I am using a little trick where I ask GPT to the the current timestamp as a seed, it seems to work!

Use CSS to pass an element through your letters

Sylvain Hamann — Thu, 02 Feb 2023 03:43:02 +0000

A while ago I created an animation to celebrate The Legend of Zelda: A Link to the Past anniversary. My main goal was to practice Three.js. But I had to find a way to recreate the logo effect where the sword goes through the "Z" with CSS.

You can have a look at my implementation made with React. I also wanted to share a pure HTML/CSS version to show it's easy to make:

The idea is to create the illusion by duplicating each letter and superposing them via an absolute position. Then with the magic of clip-path you can hide letter parts. The result would look like this (hover the word to see the animation):

More details:

My letters are wrapped in a span with a pseudo ::after element used to duplicate the letter;
The letters parent h1 is a flex layout in order to remove white spaces;
The text remains accessible (screen readers will ignore duplicated letters) and selectable (pseudo element won't be copied).

How to test your web app accessibility?

Sylvain Hamann — Tue, 21 Jun 2022 22:49:39 +0000

In this post I will share tips from my previous experiences in order to test the accessibility of your web application or website.

What's accessibility?

In my own words I would say that the goal of accessibility (often abbreviated to a11y) is to make sure that anyone on any medium can use your web application or website. A lot of us browse the web on a computer with a keyboard and a mouse or via a mobile device with a touchscreen. Some people might use a keyboard exclusively or others assistive technologies such as screen readers (by the way mobiles have screen readers too!). We have to make sure that our user interface is usable in all those cases.

If you seek for a deeper explanation about a11y, I suggest you to read this MDN doc.

Pull request review

When someone opens a pull request affecting the user interface, I expect to be able to try their changes locally or on some sort of staging instance. I won't just review the code, I will also test the app in multiple scenarios e.g. different browsers with several screen resolutions. But don't be biased by your own habits. All users might not consume the Web like you do. E.g. People don't all have a powerful MacBook Pro with a giant external monitor and high speed internet. That's why it's important to write down some testing practices that each reviewer should go through before approving any PR. For example it could say "test the changes with a combo of mouse and keyboard, keyboard only, screen reader only, touch screen, disable motions etc..". This might seem long but automatic tests or tools won't catch every flaws in your UX and it's better to avoid accumulating too many issues.

Tools to audit a web page

There are several tools that will help you to detect a11y problems:

Chrome users might already know the Lighthouse tab in their dev tools. It can generate an accessibility report.
However I prefer the axe DevTools extension because it's much faster to run. It highlights the nodes concerned by each issue and shares great tips to fix them. For example it will detect color contrast issues, images with no alt text, invalid HTML semantic...
Chrome DevTools can also help to fix contrast ratios or visualize the accessibility tree.
You might know Browserstack that lets you do cross browser testing on desktop & mobile with real browsers. Let me introduce you Assistiv Labs that will let you use real assistive technologies from different OS. It's not just screen readers, you can try others technologies such as the Windows high contrast mode.

⚠️ Having a Lighthouse score of 100 or having zero issue in your axe report does not mean that your web app is fully accessible.

Automatic tests

DOM Testing

What ever the framework or library you use, at the end your user's browser will always render HTML. Using semantic tags such as main, header, footer are not only meant for SEO. Screen readers will rely on them in order to describe the current page to the user. Testing Library will help you to write automatic tests based on the DOM. The goal is to have tests that represent a real user flow instead of testing implementation details. It's compatible with most of popular libraries, frameworks and tools.
I recommend to always render the whole app / page and use API such as within if you want to test only one section of the UI. If a component is meant to be re-used across the apps (e.g. when creating a design system). Then I will also create a test suite juste for that component.

Let's see different examples based on real test I wrote in the past:

I contributed to a Single Page Application built with React. Since the browser would not reload after a page change I had to implement few logics to improve the accessibility:

focus the h1 of the new page;
render an aria-live region announcing the new page;

Tests would like this:

userEvent.click(screen.getByText('Page link'));
expect(screen.getByRole("heading", {name: 'Page title', level: 1 })).toHaveFocus();
expect(getByText("You navigated to Page title")).toHaveAttribute("aria-live", "polite");

With my team we had to build two different view modes for the same dataset. In order to do that we made two buttons using the aria-pressed attribute. We wrote tests that interacted with each button and asserted their "pressed state":

expect(screen.getByRole("button", { name: 'Table view', pressed: true })).toBeInTheDocument();
expect(screen.getByRole("button", { name: 'List view', pressed: false })).toBeInTheDocument();

You might be used to see mobile designs with a 🍔 icon to expand the navigation. For this you could write tests that assert that the icon has the correct alternative text and check that the aria-expanded, aria-controls and id attributes are present on the right nodes. Plus you can use the isInnacessible API to make sure that the mobile menu is correctly hidden but still present in the DOM. The mobile menu usually has a focus trap so I would use userEvent to press tab multiple times and make sure it loops correctly.

As you can see, when writing automatic tests you also have to remember that users don't only use just a mouse to interact with your UI. It's good to cover every scenarios to avoid any regression, especially those that you won't be able to see easily.

Visual tests

With tools such as Chromatic or Percy you could render a page after certain actions and make a snapshot of it in order to detect visual regressions. When building a design system you could have several snapshots of each component in different states such as the focus state make sure the focus style is not broken.
Chromatic depends on Storybook which also provides accessibility tests that could run in your CI too. This would help to automatically detect regressions without running axe devTools on every pages.
Visual tests can be very annoying if they are not stable so make sure to fix flaky tests when you detect them. A co worker found out that disabling CSS animations when running those tests helps a lot.

Ask real humans

If you can afford having real users to test your web app then please do it! This is not meant to replace any manual or automatic test you would do before shipping a PR. The purpose is to challenge all the assumptions and decisions you made during the design and development phases. I have seen many companies using tools such as inVision or Figma prototypes during those interviews. I guess that's great during the prototype / design phase but don't forget to test the real app with real users that rely on assistive technologies. After running those interviews or after a WCAG audit, any fix should come with an automatic test in order to prevent any regression in the future.

Team communication

This paragraph is not really about testing but I wanted to give one last advice as a conclusion. I think my biggest frustration as a frontend developer is to have "incomplete" designs that force me to improvise or do a lot of back and forth with the design team. In order to avoid that it's good to set your expectations with your design team before they send you their design, for example:

each image or icon should have an alternative text;
focus management: what should be the focus order? what element should be focused when revealing this section? etc...
each page should have a document title, a h1, each section should have a h2 etc...
what should be the alternative animation when reduce motion is on?

Building a design system will help a lot since designers could re-create each component in their Figma and the whole team would use the same vocabulary when talking about the UI. Documenting each component with best practices and listing DO and DON'T actions is also very helpful.

Happy testing!

Multi-Directional Navigation

Sylvain Hamann — Mon, 08 Jun 2020 20:21:26 +0000

tl;dr demo, repo

In my previous job, I had the opportunity to work on a web application for a video game company. This web app is embedded within AAA games on PlayStation 4, Xbox One and Nintendo Switch. I want to share what I've learned during this experience, especially how to manage the navigation.

UI for a TV Screen 📺

Most web developers are now used to develop responsive user interfaces for mobile, tablet and desktop computers. Your webpage should provide a user experience for people using a touch screen, a mouse, a keyboard, a screen reader...
In our case however, the app gets rendered on television screens! or on the Switch screen when being used in portable mode.
Gaming systems, even those supporting 4K resolutions, will render our web app in a 1080p resolution (1920x1080 pixels viewport). Other might render it in 720p (1280x720 pixels viewport). Each has their specificity, for instance, the Nintendo Switch reserves an area at the bottom of the screen to display their own footer.
To handle all those resolutions, we better work on an adaptive design. The content (such as the system logo) and its size will adapt to each system and its resolution. There is no reason to worry about unsupported resolutions here, simply because the user can't resize their viewport.
People use a gamepad to navigate in the app. The goal is to provide them an User Experience that is similar to the one they see in-game. So we don't want to display a mouse cursor or scroll bars, this might break their momentum and create frustration.

Here's a list of tips:

Display a legend somewhere to indicate which button can be pressed and what action do they trigger. For example, you want to tell them "by pressing this button you will go back".
Look at existing game menus and dashboards. You want to use all the space available in the viewport and have some "fixed" content (e.g. a menu, header, footer...). Viewport units, REM and CSS Grid help a lot! Some browsers might not support all those cool features, you can fallback to something else like flexbox.
Highlight which element is focused. If you use React in your project you might want to try styled-components. It lets you create components that have a dynamic style based on their props in a very smooth way.
The URL is your friend. You can tell the gaming system to hide it. So the user won't be able to modify its content. Use it to do conditional rendering and to pass information from the game to your app via query strings.
You can also use Node environment variables to create different builds to support different systems.
Not all your teammates have a dev kit to start a game and test your app. Deploying a private version usable from any computer via its keyboard and tools such as Storybook helps a lot.

Gamepad Navigation 🎮

The UI is made of focusable elements where the user can navigate in at least four directions: up, down, left and right.

Browsers don't support such navigation natively. You might have heard about web accessibility that lets you use tab and shift+tab to focus elements one by one. Accessibility best practices are a good source of inspiration. You might wonder, why not using the gamepad api? Fun fact, not all gaming system browsers support it. We instead ask the system to map each button as keyboard keys. The goal is to create a custom focus manager that will take care of:

inserting/updating/removing elements in a list;
programmatically focusing an element based on a direction.

In my demo which uses React, I opted for useReducer and the Context API. But the logic can be reused with any other state management solution, such as Redux. I won't go into the implementation details, here are the main takeaways:

Each focusable element is represented by an object containing a unique id, its position (top, bottom, left, right) and its depth. We can use Element.getBoundingClientRect() or pass our own custom values.
Imagine the depth like an equivalent of the z-index in CSS. It let us handle different layers of focusable elements, such as a modal.
We use a global event listener to listen to keyboard inputs. When matching one of the arrow keys we find the closest neighbour based on the current focused element and the current depth. My function to find the closest neighbour can be overriden. We could imagine different algorithms to find the next focused element depending on the current page.
Then it's up to you to create custom hooks and to have fun! E.g. in my app I am playing a "move" sound effect when the current focus id changes. Check this article if you want to useSound too!

Testing 🤖

Automated tests and continuous integration improve your confidence when shipping code.
It's very important to write unit tests for vital parts of your apps, like the pure functions that are used to find the closest neighbour. I like writing snapshot tests for my Styled Components which have dynamic styles. I also have a few integration tests made with React Testing Library.
But I believe that end-to-end tests are the best here because they are very natural to write and will cover all your business logic without needing to mock everything. That's why most of my hooks have no dedicated tests. For example here is a test made with Cypress that visits a page, opens a modal, navigates within it and then closes it.

Thanks for reading, let me know if you have questions!

Check the demo;
Browse the repo.

Merci Jean-Loup for proofreading. He was also one of my teammates!