Design Systems and UI in a Bi-directional World

Hey, what's up, React Summit. My name is Matt Sikathian, and I'm here to talk about user interfaces in a bidirectional web. But first, some quick things about me. I'm a Canadian front-end developer living in Berlin. I started as a designer, launched my own product portfolio with my partner, Fiona. I spent six intense years at Shopify, and over the last two years, I've been working at DeepL on the design system team.

And for anyone who might not know of DeepL, it is a language AI platform that cut its teeth as a best-in-class translation machine, well-known in Europe for capturing nuanced and human-sounding translations, leaving it to be the preferred choice by most. And I have to say that DeepL was an indispensable app when Fiona and I moved to Germany as non-German speakers. And it continues to be essential for our survival here. And this was a big reason why I wanted to work there.

One of my first projects at DeepL was transforming our UIs to support right-to-left layouts as we prepared to add Arabic to the platform of already 30 supported languages. And that's what qualifies me to speak here today. I'll take you through why supporting right-to-left matters, our strategic approach, and the key learnings you can apply if you find yourself supporting right-to-left layouts or Arabic in your own design and development practice. You can find these slides and all of the resources I'll be mentioning at buy.dai.ui.com, buy.directional.ui.com. I'm hoping this becomes an ongoing and open resource to complement this talk. So with that, let's get started with the why.

Why bother supporting right-to-left at all? Well, these numbers should speak for themselves. 313 million people speak Arabic as their first language. I have 10 million Hebrew speakers and 130 million Persian speakers. And you're looking at over 400 million people who read and write for right-to-left every single day. The market opportunity is pretty clear. Yet despite this massive audience, it's a fact that right-to-left support is consistently broken on the web. If you know what to look for, you'll spot errors everywhere, even on sites run by Microsoft and Google.

And look, I get it. This work is genuinely hard and we've been conditioned to think of right-to-left as an afterthought. But that doesn't make it acceptable. I highly recommend watching Rami Ismail's video on this topic. He articulates just how bad these errors can feel to native speakers. He also mentions notarabic.com, which catalogs countless examples of botched Arabic script in major motion pictures, on billboards, in video games, everywhere. It's a funny and eye-opening talk. And these are exactly the kinds of problems that we set out to avoid at DeepL.

Arabic was one of the most requested languages on our platform. And this project would open us up to users in 22 new countries and serve markets that were largely underserved by quality translations. Before starting, we did extensive research to understand the mental model of right-to-left interfaces. And if we were going to invest in this, we were going to do it right. So let's get specific. What are we actually doing when we talk about right-to-left support? You can basically think of it as mirroring a layout. Visually, imagine looking at your hands and flipping everything from your left hand over to your right hand. Or, think of it like holding a mirror up to the website.

Or, think of it like holding a mirror up to the website. This makes our UI aligned with deeply ingrained cognitive patterns created by the lifelong reading habits of our users. They naturally and automatically scan, organize, and process information from right to left. Even if this information is only visual and non-linguistic. This isn't about the language specifically, but the single quality that it is structurally bound to be read in the opposite horizontal direction.

Forcing someone who has spent their life consistently reading, writing, and therefore thinking from right to left into a left-to-right UI requires them to work against a conflicting mental bias. And this is going to feel very weird and unnatural. You can compare this to Japanese, which can be read horizontally even if traditionally read vertically. Over time, horizontal Japanese text became dominant on the web alongside vertical text for other content mediums. In this case, the language was flexible enough to adapt and a dominant directional cognitive bias among native Japanese speakers never formed.

It is worth mentioning, however, that there is a movement in Japan to promote vertical text usage on the web. And the new CSS writing-mode property is actively used for this purpose. With this property, we can change the block flow of specific elements to vertical, where before you'd need to transform and rotate the text. Now it's a one-liner, simple, and semantic. This is a good example of the technology adapting to the encoding of different languages. And it will be interesting to see if it has any future UI implications, but either way, it's a very cool new CSS feature to play with.

But back to Arabic. And before we dive deeper, I want to make an important distinction. What we discussed so far, mirroring layouts and reversing the flow of the document, applies to all right-to-left languages, Arabic, Hebrew, Persian, and others. But what I'm about to cover next is specific to the qualities of Arabic script, since that's what we are implementing in the DeepLUIs. Though some of the considerations might still apply to other languages as well.

So first, Arabic is a cursive script. Letters need to connect to each other and have different forms depending on the position in the word. This connectivity breaks if letter spacing is anything other than zero. So step one is don't use letter spacing. It's going to make the text illegible. We also need to treat Arabic words as unbreakable units. You can't break words with hyphens across multiple lines like you can in English. So step two, don't override word break or perhaps better, is to set it to auto-phrase, which provides additional improvements for all different languages.

Next, Arabic text is generally more compact in English because connected words like and are often just a single letter attached to the following word. Though, its rigid structure doesn't always mean it's going to take up less space overall. Sometimes you need to add min-width to buttons and other elements to accommodate this difference. And numbers, somewhat confusingly, are always written left to right. And while there are Hindi numerals, Arabic numerals are more widely used, so a phone number will appear the same as it does in English. Arabic is a taller language, so when it comes to line height, decreasing the line height can cause diacritics, which are the accents and dots that appear below and above characters, to overlap or get cut off.

In general, you'll need to increase the line height by at least 25% to give these adequate vertical space. There's a similar issue with text underlines, where an underline can interrupt letter forms in ways that make them difficult to read. This happens in English too, but unlike in English where we can still make out the word, in Arabic it can cover critical visual information. You can solve this with text direction, skip, ink, all, but browsers are also converging on this as the default.

A few character differences also exist in punctuation, which was a modern addition to Arabic, where commas point up instead of down and question marks are flipped. We needed to accommodate this by choosing a different font. At Depot, we used Noto, which is a really common choice for Arabic text. So that was the crash course of Arabic, enough to know the UI consequences and helpful context as we get into the next sections.

So the most important thing is to set the direction and language, dir and lang attributes on the HTML. The dir will inform the browser of the document flow. The default, ltr, meaning left to right, will need to be explicitly set to rtl, right to left. There's an auto option too, which allows you to leave it up to the browser to parse the characters and use a best guess of the directionality, but generally this is not recommended. You can see the browser does a lot of work for us. Text and elements rearrange themselves automatically and for free. The default text alignment changed to rt, same goes for form elements such as inputs, text areas and checkboxes and selects.

And finally, inline, flex and grid flows will flip according to page direction. All of this happens because when the dir attribute was first incorporated into HTML 4.0 back in the late 90s when we had versions of HTML, it came with a design philosophy that the layout direction was considered a content property, not a presentational concern. So while you can achieve the same effects with the direction property in CSS, we never use this at DeepL because it's generally not recommended.

The idea is that this information should remain in the markup, not the stop sheet. This gets more complicated at DeepL because we deal with mixed content on the page. A user might be using the application in one language while translating text into a language with the opposite direction. There are at least 4 different states, UI in English translating to Arabic, UI in English translating from Arabic, UI in Arabic translating to other languages and the opposite. So we relied on the global direction attribute as much as possible, but since this attribute can be set on any subset of markup in the HTML document, we can override it in our interface to accommodate these different states.

This reinforces the idea that text direction isn't just a style sheet preference. It's baked into the fundamental structure of the writing systems we are displaying at any given time and is right in the Unicode characters. Our goal was to allow developers to write direction agnostic styles that automatically adapt based on the nearest dir attribute. So, how do we do that? Well, for starters, floats, absolute, fixed positions, margin, and padding all need to be rewritten using direction agnostic properties. These declarations were not originally designed with bi-directionality in mind, and used physical values, left, right, top, and bottom, rather than logical values, start, end, inline, and block.

If you've been writing CSS since the Zen Garden, it can take time to unwind and reprogram the muscle memory of writing left and right and instead writing start and end. But luckily, most properties follow this pattern. Left becomes start, right becomes end. And when you need to distinguish top and bottom, you specify inline start and inline end versus block start and block end. I won't waste time talking too much about browser support, since everyone is different and increasingly modern, but you can always use physical properties first as fallbacks, then logical properties for progressive enhancement.

Another tip here is that this principle of using logical CSS should extend to your CSS naming convention. In the example, rather than naming sidebar-left, we use sidebar-start. Finally, in the cases where we wanted to target a direction specifically, such as icons, which we will get into later, use the dir pseudo-selector to target elements based on their text direction. Let's quickly look at some example components to see how they become direction agnostic. Buttons with icons are straightforward. The icon position flips to the opposite side. Same goes for toast, pills, and so forth. The text and icons flip to maintain the expected visual flow.

Here we have a search input, with an icon at the end. You need padding on both sides, but more on the end to prevent text from sliding underneath the icon. This is where the padding inline end value applies to both directions, where padding right wouldn't. Switches flip too. The toggle moves to the opposite side to maintain consistency with checkboxes. Tables, breadcrumbs, and tabs all flip their entire structure. Per tables, columns flow right to left, with the first column appearing on the right. Breadcrumbs and tabs follow the same pattern. Progress indicators represent temporal sequences, which will flip with the mental model. Something like a usage plan indicator would be misunderstood. And any multi-step process will start with the first step on the right and the last step on the left. We covered a lot of issues with logical CSS, but in our React code, we had to make some additional refinements.

We covered a lot of issues with logical CSS, but in our React code, we had to make some additional refinements. This included renaming props to follow the logical properties of CSS, such as an anchor point of an arrow indicator, and handling various edge cases in dropdowns, tooltips, etc. where the positioning, alignment, and even the animation direction needed to be considered. We handled this with a context value and a hook in our design system provider. This gives us a lever for fine-tuning right-to-left support in our React components.

So, we talked about language, we talked about styles, and we talked about components. Now let's discuss the larger ecosystem and processes that made this launch successful. The first thing we did was write a simple styling plugin with an autofix function that converts all the physical CSS properties to their logical counterparts. We already had an internal styling library, so this was an easy addition to a tool that was already embedded in everyone's IDE and codebase. The main default application, however, uses tailwind, so we couldn't rely on styling alone, but created an ESLint rule that does the same thing but changes inline CSS and tailwind classes.

At the time, though, this provided major side benefits. It gave us an opportunity to educate the team by customizing the experience right in their IDE, rather than changing everything in one fell swoop. As I mentioned earlier, this is a mental model shift, and we felt it was important to carry that understanding and empathy throughout the work, continually reinforcing the fact that we, as designers and developers at DeepL, are building for all users. We published these out of a monorepo of UI-related tools, libraries, and configurations, and actually spent more time at this level than building components for the design system.

We published these out of a monorepo of UI-related tools, libraries, and configurations, and actually spent more time at this level than building components for the design system. We've always felt it's important to meet users where they are and build good tooling and automation to support them. The design system team is just me and my pal Misha, two guys, so we need to be resourceful and focus our work on this connective layer between visual components, design tokens, and the people, and less on any of these things individually.

You could call us the glue or fabric, but I like thinking of our design system as the mycelium that connects all of our products, and we are the maintainers of this ecosystem. This not always visible layer that is needed for all of these elements to survive and communicate. So we can't talk about right to left without talking about icons. Certain icons need to mirror, and knowing when can be tricky. The fundamental principle is to separate directional UI icons from universal symbols.

Navigation elements mirror because their semantic meaning depends on the content flow direction. In left-to-right interfaces, back points left because content flows from left to right. In right-to-left interfaces, back points right because content flows from right to left. This button's meaning remains, go to previous content, while its visual direction adapts. This applies to any flow of movement or progress, but somewhat confusingly, a play button, which is also kinda like an arrow, doesn't flip. And that's because it represents the physical tape mechanism which moves left to right regardless of the text direction.

That's just how tapes work. This made our already messy icon implementation even more confusing. We had a huge mix of SVG files, different React libraries, and inconsistent icon sets, and now developers not only had to know which to use, but which icons flip and which don't. So thinking about this ecosystem thing again, we took the opportunity to do some overhauling.

We moved all of our icons to a single Figma file where they could be annotated with a directional property, usually by the designer adding the icon, indicating whether or not they flip in right-to-left. Having this central configuration right next to the artwork made the flipping confusion a lot easier to grasp. We then have a build tool that uses the Figma API to fetch all the SVGs from this file, combine that data into an SVG sprite that we cache in the markup of our web interface. This also lets us modify artwork as needed and keep all icons, custom or not, in one place that designers manage as Figma symbols, keeping our designs and their development always in sync.

For developers, they just need to know the icon name, the flipping mechanism, CSS, accessibility, all that is swept under the rug and handled automatically by a shared web component. There is a way to override the direction if context requires it, though this is used sparingly because of how specific we can be with icons. What's cool is that with all the icons as data and directionality built in, we unlocked a whole chain of automation. When designers add a new icon to Figma, our build tool automatically generates TypeScript definitions, updates documentation, runs visual regression tests in both directions, and when the iOS, Windows, and Android teams heard we were doing this, we simply added another step in the process to generate a platform-specific set for each of them.