This week (with feature release 25.2.1) we will be releasing a change that is both big and small at the same time: we will stop using the Roboto, Roboto Condensed and Montserrat font families for WebUI and migrate to a font family known as Inter. These changes are part of our ongoing desire to keep WebUI's appearance up-to-date and to offer a better User Experience. They mark the start of a range of other changes, to the look-and-feel but also to how you can use WebUI, that should all achieve this same goal.

Inter comes with some advantages, for you as an end-user of WebUI:

• Using Inter for the entirety of the UI will result in a more consistent look, making WebUI a more balanced experience, also for app developers.

• Inter was designed to feel modern and has features to enhance and adapt readability depending on the font size and weight.

• Inter can be delivered to your browser from fewer and smaller files, resulting in the best possible page loading performance.

Despite all these large claims, we do try to make sure that these changes are not overly disruptive. Which probably means that, for this font change, your app will only look 'slightly different' and, depending on how susceptible you are to graphic changes, you'll probably appreciate how it just 'feels' better. Meaning we achieved our goal.

You could actually stop reading here, but you might feel better prepared for this change if you take note of the considerations below. Also, there are some things you might want to try to deal with certain issues that might arise.

Implementing Inter did allow (and necessitate) us to change and clean some parts of what some of you might consider critical layout, depending on how your app depends on it being 'in a certain way'. This is mostly true for any data or labels that you expect to be a very tight fit in whatever their container is.

A (non-exhaustive) list of the potentially impacted UI elements that you might want to check on:

• Charts: axis labels needs slightly more space, which can mean all kinds of things for the available chart plotting area and the plotted data.

• List Widget, Multi Select Widget and the Legend Widget: new white-space distribution for headers and items, meaning slightly more items will be visible within the same overall widget height.

• Workflow: workflow titles will display some more characters, but item (step) titles might be showing less.

• Table Widget, Scalar Widget: Cell content and header titles can end up being slightly bigger, especially numeric content. Clipping (resulting in the use of 'ellipsis') might occur if the content was set up to be a tight/exact fit.

• Status bar: depending on what you show, how wide the screen is and how deeply nested your page structure is (resulting in a long breadcrumb), the information in the status bar might run out of space earlier.

If any clipping occurs, slightly adjusting the column width (for either a table column or a grid layout) should suffice. However, overall available space remains very, very similar, so you shouldn't have to go over all these widths at all.

Also, for those of you who use custom stylesheets to achieve a different layout, to suppress certain elements, or to restyle other elements to look like others, you might want to know that:

• if you created any css rules that repeat or redefine the use of the 'old' font families Roboto/Montserrat, then these rules are likely to not show correctly anymore. Because they are no longer available and will fall back to unsuitable fonts like Times New Roman or worse. Solution: don't redefine styling that should be inherited from the context. And if you do, (re)use our available theming variables and apply the new values to those. Use font-family: var(--font_primary); to use the right font if needed. Or set a theming variable to override it locally. For example: .widget-container--button {--font_primary: "Comic Sans"; --font-size_primary: 24px;}.

• the widget headers use some new styling to achieve better alignment for variable font sizing (with the intention to support theming options better). Custom styling that depends on exact pixel sizes for alignment, or trying to hide headers by setting their height to 0, will probably no longer work out right. Solution: try not to nudge elements around and hide elements (and/or the correct containers) by using display:none.

Finally, if you run into issues you don't want to fix or can't address immediately, we have also built in a fallback mechanism (a feature toggle) that brings back _most_ of the previous font-families, sizing and styles:

ignore-font-update

Like any other feature toggle, you can incorporate it into a config file or use the browser URL to add it as a parameter. Please refer to the feature toggle documentation for background on the general usage and support.

This particular toggle is not a 100% complete fallback. Some styling changes will remain, but the most obvious font/size changes are undone. It is meant as a temporary alleviation of issues arising to the changes mentioned above.The toggle is not intended for permanent use: it works after applying the new fonts, meaning you might see a flash of the new fonts upon initial app/page load and it also draws upon the browser's resources, affecting page performance.Also note that the App Developer interface elements will always keep using the new font.

Overall we hope you experience the benefits of this 'small change' and of the changes that we plan to do afterward.If you have any feedback to share, please reach out here, or to User Support. We'd love to hear about it and, if needed, adapt to it!