Theming

Theming plays an important role in the Function of UI. From a biological standpoint Theming influences the model, design, skin and decoration of the body. For example, Initial skin color is part of our genetic code, but can also slightly change based on external factors such as exposure to sunlight or by emotional triggers. A chameleon has the ability to drastically change its skin color based on external factors or at will. It is no coincidence that Theming is often called "Skinning" among designers and developers.

A powerful and flexible Multi Layer and Multi Dimensional Theming Architecture can be implemented with three basic Theming Primitives:

• Theme Layers

• Theme Dimensions

• Theme Variables

The three Theming Primitives are then used to enable powerful Theming Features such as:

• Theme Variants

• Theme Inheritance

• Theme Switching

• Theme Morphing

Theming Primitives

Theme Layers

When we talk about Theming an application, we can decompose a Theme into four different layers of Theming activities:

• Model

• Design

• Skin

• Decorate

Model Layer

The Model Layer of a Theme allows for "modeling" a specific component. This layer enables polymorphic component variations that may both affect the component's rendering structure as well as it's styling. An extreme biological example in polymorphic animal states is how a caterpillar becomes a butterfly. The Model Layer is the first layer of a Theme and the only layer that has access to modify both the rendering AND styling of the component. All other Theming layers only affect the component 's styling. This layer can be implemented by defining a Model Variant for a specific component using a set of Model Parameters to enable parametric rendering of the component. Model Parameters are applied to the code and styles co-located with the component itself.

Design Layer

In biology a breed refers to a stock of animals within a particular species with distinctive characteristics. For example both dog breeds Maltese and Vizsla are dogs with distinctive characteristics, but they are both still dogs. In the same way the Design Layer of a Theme allows for "breeding" a specific component. The Design Layer is the second layer of a Theme and has no more access to the rendering ("modeling") of the component. It can only "breed" the component into a Design Variant of the rendered component. This layer is implemented by defining a Design Variant for a specific component using a set of CSS styles. Design styles should not be co-located with the component's implementation code. Design styles are located in the root theme folder.

Skin Layer

The Skin Layer is the third Theme layer. This layer defines the "skin" of the component. The components 's skin is themeable in multiple dimensions such as Tone, Typography, Spacial and Motion. Together these dimensions defines the "skin" of the component. Skin variables are located server side and is organized in an hierarchical structure:

• Theme

  • Skin

    • Skin Variant

      • Dimension

        • Dimension Variant

          • Variable

            • Value

Decorate Layer

The Decorate Layer is the fourth and final Theme Layer. This layer is the last layer where you can change, embellish, decorate or override stylistic effects by applying direct inline styles or CSS classes to the component. This is the final stage in

Multi-layer and Multi-dimensional Theming is implemented by allowing to model, design, skin and decorate your components.

Theme Dimensions

Multi Dimensional Theming can be implemented at each Theming Layer. But the most appropriate layer for multi dimensional Theming is the Skin Layer.

Dimensions and their themeable properties:

• Tone

  • font colors

  • background colors

  • branding colors

  • moods

• Typography

  • font families

  • font sizes

  • letter spacing

• Spacial

  • spacing

  • sizing

  • scannability

• Motion

  • animation character

  • transitions

  • engagement

Theme Variables

Theme variables are used as a Theming primitive to implement multi-dimensional Theming of UI components, to create global variable sets of theme properties and also to enable powerful Theming features such as Theme Switching and Theme Morphing. Theme variables are implemented at the Skin Layer and they live server side so that they are customizable by end-users.

Theming Features

Theme Switching

Theme Switching is the ability for an application to change its skin programmatically or by the preference of the user of that application. Theme Switching should not change the functionality or the structure of the UI, only its appearance. Theme Switching should be implemented in a mutual exclusive way. This means that only one theme / skin can be active at a time.

A default Theme declaration should be set in the DNA at the Document Component Level, because the Document Component lives at the top of the component hierarchy and there can only be rendered one instance of it at a time. This enables "chameleon-like" flexible and powerful DNA driven Document Level Theme Switching.

Theme Switching can also occur outside the DNA, for example by enabling User preference Theme Switching. This feature is implemented by globally replacing the current Theme Variable set with another one.

Theme Variants

Theme Variants allows for variations within a Theme. A Theme Variant is a named set of Theme Variables.

• Theme Switching uses a replacement-strategy to apply a new variables set, whereas Theme Variants uses an injection-strategy to apply a variable set.

• Theme Switching occurs at the Document Component Level, whereas Theme Variant injection occurs at the lower BIO Component Levels.

Theme Variant declarations should always be stored in the DNA in order to decouple the components from the Theme Switching logic.

The Theme Variant names should be very generic, whereas the Theme Switching names should be very specific. This is because the Theme Variant names will be reused throughout all Themes in order to keep all Theme Variable sets consistent and switchable.

Theme Inheritance

Most software engineers implement Theming by defining a consistent set of Theme Variables, which is a good practice. When working with multiple Themes however, multiple Theme Variable sets needs to be defined. It's very important that the Theme Variables are then kept consistent throughout all sets. This can be achieved using Theme Inheritance. That way our Components can be completely Theme Switching agnostic. BIO Components should not contain any Theme Switching logic.

Variable Inheritance

Theme Inheritance should be implemented to keep the Theme Variables consistent and to enhance the experience for the designer or developer (DX) that needs to configure all the Theme Variables sets. In order to support Theme Switching and Theme Variants, a two-level Theme Variables Object is required. The first level is the Theme level (to support Theme Switching) and the second level is the Theme Variant level (to support Theme Variant Injection)

An abstract "base" Theme contains all values that will be inherited by all other Themes. A non-abstract Theme can inherit the values of another non-abstract Theme or it can inherit the values of the abstract "base" Theme (in case the designer / developer likes to start with a clean slate)

Variant Inheritance

Variant Inheritance can be implemented at the BIO Component Hierarchy through the Global DNA. Theme Variants are inherited along the Component Tree and can be overridden at each level of the tree. This enables flexible and declarative Theming for all parts of the application UI.