DEV Community: Vojtěch Vidra

Product adoption tools suck so me and my homies built Flows

Vojtěch Vidra — Wed, 03 Dec 2025 10:28:29 +0000

If you’ve ever tried building onboarding or product adoption with Appcues, Chameleon, Userflow, WalkMe, or Usetiful, you’ve probably hit the same two problems:

Everything is rendered with JavaScript overlays
Customization is a nightmare

A little backstory:

When I was choosing an onboarding tool for my previous project, nothing matched what I needed. So I had to build my own. With help from IntroJS I built onboarding solution that I needed: Tooltips, Modals, custom CSS, waiting for interactions, and saving the state into the database. It worked… but it took way more time than it should have, and any change required a redeploy.

This made me realize: there’s no product-adoption tool made for developers and designers.. So me and my friends started building Flows with a simple philosophy:

Optional built-in components that get the basics right
Or use it headless - bring your own components
SDK for React and JS (supports Vue, Angular, Svelte or any other JS framework)
Support for floating and inline elements
Make changes without redeploying
Fast, lightweight, and predictable
Fair PAYG pricing with free tier

Now back to the issues and how we’re solving them:

1. Rendering

Most tools inject UI with JavaScript and target elements using selectors. This limits them to floating UI (tooltips, popups, dialogs). The ones that offer “inline” elements do it with brittle selectors, layout shift, and generic blocks that never really match your product.

Flows fixes this with a simple “portal” component that renders the elements directly where you need, with an optional placeholder to avoid layout shift. And floating components are supported as well.

2. Customization

Good design language isn’t optional anymore, it’s need for people to find your product interesting. That’s why customizing brand colors doesn’t cut it and spending development time on the whole CSS rewrite isn’t smart.

With Flows you can use your own components. Import them into Flows SDK, define the props in our editor and use them in the workflows. Anyone editing the content has clear visibility into the structure of each component and what each field is used for.

I’d love any feedback since we’re just getting it out there, thanks!

Color formats on the Web

Vojtěch Vidra — Tue, 20 Dec 2022 08:15:02 +0000

In the world of digital design, color plays a crucial role in creating visually appealing and effective websites and applications. One important aspect of using color on the web is understanding the different color formats available and how to use them effectively. In this blog post, we will explore the different color formats used on the web and discuss when and how to use each one. Whether you are a web designer, developer, or just interested in the technical aspects of color on the web, this post will provide a useful overview of the topic.

The difference between color space and color model

Before we dive deep into the world of colors, it's important to establish some key terms. In this article, we'll be discussing color models and color spaces. These two concepts are often used interchangeably, but they are not the same thing.

A color model is a mathematical system for representing colors in a way that is independent of any specific physical medium. For example, RGB, HSL, and CMYK are all color models.

On the other hand, a color space is a specific set of colors that can be reproduced on a particular medium, such as a computer screen or printer. It maps the color descriptions provided by a color model to actual, reproducible colors. For instance, sRGB and AdobeRGB are two different color spaces that both use the RGB color model, but the exact same RGB value (such as rgb(87, 60, 250)) may look slightly different in each color space.

Hex

Color space: sRGB

Hexadecimal notation is a widely used method for representing RGB colors on the web. Despite its popularity, it has limitations due to the constraints of the sRGB color space. Until support for LCH/LAB color space becomes more widespread, hexadecimal notation will remain the most commonly used method. One of the main advantages of hexadecimal notation is its compactness, which can help keep your CSS files short and concise.

Hex supports alpha channel

Did you know that hexadecimal notation can be written in a 4- or 8-character format to include an alpha channel? For example, #FF000088 and #F008 both represent red with 53% opacity. When it comes to browser support for this format, the news is good: aside from IE11, most modern browsers support it. You can check the details on caniuse.com

RGB

Color space: sRGB

RGB notation is similar to hexadecimal notation, with the main difference being that the channel values are easier to read. For example, understanding what #39 means is a bit more complicated than R 147. RGB notation is not used as often as hexadecimal notation, but it can be useful in certain situations, such as when creating a linear gradient or working with more complex color schemes. In general, the specific color values used by designers and developers are less important than the final product, which is why hexadecimal notation is more commonly used.

HSL

Color space: sRGB

Although the HSL color model uses the sRGB color space, it has fewer available colors than RGB or hexadecimal notation. This is because 360 x 100 x 100 equals 3.6 million, which is much smaller than the 16.8 million colors available in the RGB model. This limitation can be overcome by using decimal points in your HSL definitions, but this is not a widely used practice.

One major advantage of HSL is that it is much easier to read and understand than hexadecimal or RGB notation. This is why it is the most commonly used color model for selecting colors for the web. However, we have written a blog post explaining why LCH color space is a better option for color selection.

Overall, the HSL color space is a great choice for color wheels and color science because of its user-friendliness. If you want to try it out, check out our color wheel tool We think you'll like it!

HWB

Color space: sRGB

HWB is similar to HSL, in that it is more user-friendly than RGB. However, we have not seen HWB used on the web. This makes sense because when selecting colors in RGB, HSL is often used as an intermediary step before converting the colors to hexadecimal notation. Therefore, there may not be a need for HWB in the typical web development workflow.

LCH & LAB

Color space: CIE Lab

CIE Lab is one of the largest color spaces in this list, it is even a bit larger than Display P3. It was designed to model human color perception, which means that the lightness values are consistent across all hues. This makes the color space more predictable and consistent than other alternatives. If you are interested in learning more about CIE Lab, we have written a detailed article about it.

When it comes to color models, there are two options: LAB and LCH. On the web, LCH is a better choice because it is more intuitive and easier to use while LAB is better suited for scientific purposes.

If you were to ask us which color format is the best, we would recommend LCH. Unfortunately, not all recent browsers support LCH, so it cannot be used as is. However, you can use this color space to create better color palettes. At Atmos, we have designed a tool that allows anyone to take advantage of LCH on the web. Check it out!

Display P3

Color space: Display P3

Color model and color space in and of itself. Display P3 is a color space developed by Apple to expand the range of colors available on computer screens. It covers 26% more of the visible light spectrum than sRGB, bringing a wider range of colors to the display. Display P3 was first implemented in the Safari web browser and, at the time of writing, is still the only browser that supports it.

Rec.2020

Color space: Rec.2020

Rec.2020, also known as BT.2020, is not currently supported on the web. However, it is mentioned a few times in the CSS Color Module Level 4, so it is possible that it will be supported in the future. This color space is larger than Display P3, covering 75% of the visible light spectrum. Whether it will eventually get supported or not, it would be great if developers had a way to use wide color gamuts on the web, and the inclusion of rec.2020 in CSS Color Module Level 4 is a step in that direction.

Other wide gamut color spaces

Adobe RGB, ProPhoto, Rec.2020, Rec.709, and other color spaces are supported on the web in some form, but not directly in CSS properties. There is a detailed article about using wide-gamut images on the web that you may find interesting. Other color spaces may be visible in videos on YouTube or Netflix, but this does not count as direct support on the web. Despite this, it is interesting to know that these color spaces are being used in other contexts.

Conclusion

Although LCH is the best color format for the web, it is not yet supported by all browsers. Therefore, we need continue to use the sRGB color space, either with the 6-character hexadecimal format for solid colors or the 8-character format for transparent colors. Until LCH support becomes more widespread, sRGB will remain the most commonly used color space on the web.

Theming made easy with React and Styled Components

Vojtěch Vidra — Wed, 16 Feb 2022 06:35:08 +0000

Working with colors and creating a theme tends to get messy because colors are spread everywhere. We'll learn how to avoid common issues and organize colors better. In this article, you will learn:

How to create a theme with Styled Components
How to create Dark mode for a web app
How to never duplicate colors in code
How to take advantage of TypeScript to improve DX

We've used this approach to create Dark mode for our app Atmos. We can iterate on our color palette and change it in seconds, by sticking to these practices. Furthermore, anyone can jump into the code, thanks to the aligned naming convention of colors in design and code.

Without further ado, let's jump right in!

Using variables

Don't use colors directly. Always put them in a variable. CSS variables are better than SASS or JS variables, even if we're building a JS app with styled-components. We will show you later in the article why.

With this approach, we don't have to repeat ourselves. If we need to change one or more of our colors, it's just much easier to change the value of a variable instead of going through all those files and replacing them one by one.

.button {
  background-color: #123456;
  /* ⛔️ Not good, prefer variables */

  background-color: var(--button-background);
  /* ✅ Much better, don't repeat yourself */
}

Using meaning

It's pretty common to use the same color for a couple of elements. Maybe the color of our primary text is the same as the background color of our primary button. Now imagine the text is too light and doesn't have enough contrast. We will need to change the color of the text while keeping the original color for our button. That is why it's better to name our variables by their use case rather than their relation to the palette. For example, it is better to name a color background rather than white, or button-background rather than primary-dark.

This approach is great when building a dark mode that requires two separate palettes (one for light and one for dark). At that point, naming colors by their use case is the only sensible option.

.button {
  background-color: var(--primary-dark);
  /* ⛔️ Not good, in dark mode, it's probably not dark anymore. */

  background-color: var(--button-background);
  /* ✅ Much better, consistent with dark mode */
}

Naming convention

A naming convention is a must-have for larger teams, but it makes sense even for smaller teams. It's like building Rest API without any documentation. In the example below, we can see inspect in Figma with the same color key [in square brackets] that we'll use in the React component next to it. Having the colors clearly named in Figma removes any questions about which colors to use, especially for new joiners.

Sticking to one color notation

When creating your theme, it's better to stick to one notation to avoid duplicate colors. There are a lot of options. Most of the time, colors are in hexadecimal format or RBGA when we need an alpha channel.

It's better to use hexadecimal numbers because it's more concise. It can also be written in 8 character format to add an alpha channel with great browser support. In our codebase, we leverage the fact that we can append the last two characters of the alpha channel to a 6 character HEX code and share the same HEX code for non-transparent and transparent colors.

.button {
  background-color: rgba(1, 2, 3, 0.5);
  /* ℹ️ Alpha channel in % format is nicer. */

  background-color: #12345678;
  /* ℹ️ This is shorter and more flexible. */
}

In the future, we could also use a wide gamut display-p3 or Lab color spaces. These can describe much more colors than RGB color space. Unfortunately, wide gamut colors are currently supported only in the latest Safari browser (early 2022).

Tip for converting percentages to HEX

We may need to convert percentages to hexadecimal notation. The following is a simple JS function that will make our life easier.

const percentToHex = (percent) => Math.round(percent * 255).toString(16);

// Example:
percentToHex(1); // Output: "FF"

Putting it all together

Let's take a look at how to create a theme for your application. Using this method, we created a dark mode for Atmos with ease. At the same time, we can iterate on our palette with little to no effort.

Building a theme

First off, we will need a color palette. We can use a ready-made palette like Material UI or leverage our guide on How to create the best UI color palette to create our own. We can also jump right into Atmos to generate one in a matter of minutes.

It could be tempting to take the color palette, turn it into a JS object, and call it a day. That would work (kinda), but there's a better way!

In the code snippet below, we have two objects, our color palette, and our theme. Notice each has its purpose.

const lightPalette = {
  primary: {
    300: '#A3A4FF',
    400: '#8884FF',
    500: '#6C5EFA',
    600: '#573CFA',
  },
};

const lightTheme = {
  primary: {
    text: lightPalette.primary[600],
    background: lightPalette.primary[500],
  },
};

Palette

The palette stores your colors. Typically, the palette has primary, neutral, success, and danger colors. It's important to note that the palette should be the only place where we store our colors. There could be some HEX codes in our SVG icons, but we can always overwrite those using colors from our theme. Other than that, you won't find a single HEX outside of the palette.

Theme

The theme gives meaning to our palette. For example background, text, text subtle, primary text, card background, icon, etc. As a rule of thumb, the theme is the only place, where the palette is used. If you need another color for your new component, don't use the palette directly, instead create a new item in your theme, and you're good to go. By sticking to this approach, the setup is very flexible and scalable.

Avoid flicker with CSS variables

We have created a theme now we would like to use it. If you're using any CSS-in-JS tool, the most straightforward way is to pass the theme object into a Theme provider. That would work, but it has one major flaw you should consider if you're generating HTML during a build or request on the server, with frameworks like Next.js and Gatsby.

Consider this scenario: You build your app for production, and by default, it is in light mode. The user enters your app and has dark mode selected. Because you have baked your colors into the generated JS classes, all your classes have to regenerate into the dark mode. That results in a brief flicker of light mode before the app regenerates the classes.

CSS variables to the rescue. Since you can create CSS variables for both light and dark themes at the build phase. All you need to do is apply the correct theme when a user enters your app. Do this by reading the user's preferred theme and setting the corresponding class name to the html element. Because the CSS variables are still the same, your generated classes don't have to be regenerated.

Turning the theme into CSS variables

With our theme ready, we need to turn it into CSS variables. We will use a recursive function that turns each atomic value into a CSS variable with the name from its object keys. The string then can be assigned directly to :root.

const createCssVar = (items, prefix = '-'): string[] =>
  Object.entries(items).flatMap(([key, value]) => {
    const varName = `${prefix}-${key}`;
    if (typeof value === 'object')
      return createCssVar(value as ColorsItem, varName);
    return `${varName}:${value}`;
  });

export const createCssVars = (themeColors) =>
  createCssVar(colors).join(';');

// We're using lightTheme object from previous example
createCssVars(lightTheme)
// This will turn into:
css`
--primary-text: #573CFA;
--primary-background: #6C5EFA;
`

import { createGlobalStyle } from "styled-components";
const GlobalStyle = createGlobalStyle`
  :root {
    /* We assign variables to root element */
    ${createCssVars(lightTheme)}
  }
`

Tip for Dark mode

When building both light and dark modes, we will also need a way to assign the correct theme to the user based on their preferences. An easier option is to stick to the system settings, then all we need is this simple media query, and that's it.

But we may want to allow users to choose between light and dark modes within the app UI and save the preferences. We can achieve this by injecting a simple script right after <head>, reading the local storage, and setting the class name for light/dark mode on the HTML element. We could try to come up with something ourselves, or we can use this React hook that will do it for us.

Our awesome dark theme is almost ready. There's one last thing to do our scrollbars are probably still white. Not in Firefox, because Firefox uses system settings. To fix our scrollbars and also make them dark, there is a simple css property or meta html tag to tell the browser that the scrollbar should be dark.

Using CSS variables

We have created a palette, light, maybe even dark theme. Now it's time to use our CSS variables. We can use it directly by referencing its value with standard CSS syntax.

.link {
  color: var(--primary-text);
}

Or we can create a simple (type-safe) function to help us with this. A great benefit is that the function doesn't need the theme reference (unlike the Theme Provider approach). From the code snippet below, we can see that the function can be used anywhere.

// If you're using TypeScript, see tip below for ColorKey type
const color = (colorKey: ColorKey) => {
  const cssVar = colorKey.split('.').reduce((acc, key) => acc + '-' + key, '-');
  return `var(${cssVar})`;
};

const StyledButton = styled.button`
  background-color: ${color('primary.background')};
`;
const svgRender = <MySvg color={color('primary.icon')} />;

Tip for TypeScript

We can leverage TypeScript and create a type that will help us when referencing our colors. RecursiveKeyOf is a custom type that will take an object, chain its keys recursively, and create a string type joined by .. This may sound complicated, but we don't need to understand it to use it.

// lightPalette is reference of our theme from earlier
type ColorKey = RecursiveKeyOf<typeof lightTheme>;
// ColorKey is now union of colors from our theme.
// ColorKey is now basically this:
type ColorKey = 'primary.text' | 'primary.background';

In conclusion (TLDR)

Use variables, preferably CSS variables
Name colors by their usage rather than how they look
Create and stick to a naming convention
Stick to one color notation, HEX or RGB, it doesn't matter

If you've enjoyed this article, I'm sure you will find Atmos helpful. Whether you are just starting with a new color palette, or your current palette could use some tweaking, then you should give Atmos a shot! Hey, it's free 🚀