Mosaik

The ORF as the public broadcaster of Austria offers a range of digital products, providing access to local news and radio, live tv online, ethnic minority coverage, sports broadcasting, content made for kids, and more.

Across these products, this means lots of content, and a variety too: video, audio and text. And yet, from a branding and design perspective, wherever a user comes into contact with an ORF product, it should feel distinctly ORF.

These products also share components and patterns users are accustomed to, and maintaining separate but similar components wastes valuable resources. All put together, this created the need for more and more standardisation, which resulted in the creation of Mosaik in 2022.

I joined ORF in spring 2023, and from then on helped build Mosaik from a web-only component library for a single product into the multi-platform, multi-brand design system it is today.

One system, multiple brands

To accommodate the different ORF brands and products while still relying on the same system, it was clear we needed very robust theming. Every ORF product comes with its own identity, corresponding colours and shapes, its own use of typography, and so on. This meant that from the most basic color palette to the specific detail of a component, almost everything needed to be adjustable across themes. Custom shape on a component? No problem. Uppercase text on a button label, bust just for this specific product? Sure.

Tokens, tokens, tokens

To achieve this, we built a three-tier token architecture: primitive, role and component. Primitives contain the most basic building blocks such as color palettes. Roles form the semantic layer and structure the primitives into purpose-oriented tokens, such as background-primary, content-neutral or surface-base.

At this level, theming is introduced: a role token can reference a different primitive across themes. Next to color, role contains semantic tokens for typography, grid & layout, space, shape, blur, shadow and motion. The last tier, component, contains tokens for all components, which reference role tokens.

Not every aspect of a component has accompanying component token, sometimes a role token is applied directly to a component. However, components such as buttons, which we expect to be themed heavily, do have component tokens on all properties. A button can therefore reference background-primary in one theme, but background-secondary in another.

This has the advantage that each theme can be customised on many different levels, but also leads to a myriad of component tokens, which complicates maintenance considerably. However, we saw little alternative to this, as relying only on a primitive and semantic layer was clearly not flexible enough to encompass the different ORF brands, and would have hindered Mosaik to become the basis for all ORF digital products.

Token Pipeline

A token system built with Figma Variables does not do much on its own. Sure, it is neat and switching modes is impressive. But the real power comes with exporting and embedding these tokens into the actual frontend of each platform. By doing this, creating new themes or adjustments to existing ones become a design-only task, requiring hardly any work for development. The theme is built entirely in Figma by a designer, and once it is finished, a developer gets the most recent token version from the token repository fed via the Figma API, updates the version in the product, and violà, the product appears in its new look. For this to work, however, designers must work with discipline and consistency normally only expected from developers.

1. A standardised token syntax has to be found which all tokens have to follow
2. Any changes to the token set have to be announced, scheduled and documented
3. Token changes have to be classified into breaking and non-breaking changes
4. Changes in Mosaik Figma libraries have to happen in branches and merges coordinated with development

Native Platform Components

Both iOS and Android offer the possibility to customise their native components such as tool bars, sheets, tab bars etc. Since the app development teams at ORF currently do not have the resources to create their own custom app components, we decided to apply our theming approach to the already available platform components. This gives users of ORF Apps familiar components with expectable UX, while also allowing products adjusting them to their respective brand.

Words are not enough

Mosaik has its own set of icons. It was originally designed by Saffron Consultants, then got a visual overhaul from Johannes Ecker, and today is maintained and extended in-house by the design team. The icons are drawn natively within Figma as 32x32px in size, a 2px stroke-width and 2px safe-space around. Each icon exists in as outline and fill. however, some icons are the same in outline and fill, because making them differ made no sense or was not possible visually, or was just not needed. The export to code is semi-automatic via the Figma API, and prepares the icons into usable SVG and XML files for all Mosaik platforms. The export is done 3-4 times a year, when enough new icons were designed, and then are distributed via Mosaik into products.

Accessibility included

All Mosaik components and themes are designed to be accessible out of the box according to the European Accessibility Act EN 301 549. This includes color contrast, text sizes and scaling, keyboard and screenreader navigation, a11y labels for content, and so on. The role tier of the token architecture allows themes to be built around accessible color contrasts, since surfaces have corresponding content tokens, which are to be used in combination with each other. Should a contrast issue arise in a theme, the token pairing can be adjusted and will show with the next token set update. Typo sizes are standardised as role tokens across all themes, and are therefore accessible in all themes. For components, dedicated accessibility sections in Figma specify labels, focus order and tooltips, making it easy for developers build accessibly from the get-go.

Backbone of ORF publishing

Mosaik contains a template called “Story”, which was built to fulfil the text publishing needs for all sorts of ORF products. Wherever an article or similar gets published in the ORF universe, be it news story, a sports report or a long form article on culture, the Story template is supposed to handle it. This is a broad scope, and led to a whole range of components functioning as a Swiss Army knife for publishing: versatile, robust and reliably handling the various needs from journalists and editors at ORF. For now, it is used on songcontest.orf.at, fm4.orf.at and kids.orf.at, with more products to follow.