Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

Design System Studio

Important:  API version 1 components cannot be styled by configuring a design system in the Design System Studio, they must be styled using themes.

Visual styles for pages in Nintex Apps's v2 API are handled via design systems, which are edited in the Design System Studio (DSS) workspace.

A design system is a file containing the variables and style variants that compose overarching style rules for all visual elements. The DSS is accessed by configuring an individual design system, so the first step to styling an application is to create a design system that will contain the app's custom style rules.

You can access your Nintex Apps instance's design systems by clicking Design systems in the top navigation bar.

From the Design Systems screen

Access the following options on the Design Systems screen.

  1. Click Create to create a new design system. The dialog box lets you create either a Design System or Themes.

    • Select Create under For v2 pages

  2. Customize the design system:

    • Name: Give the design system a distinct name.
    • Clone styles from: Select a design system to serve as the base for the new system.

    Note:  Nintex Apps's base design system, Ink, is selected by default.

  1. Click Create.

  1. Click the dots-vertical more options menu next to Create.

  2. Click Import.

  3. The dialog box lets you upload a .sktheme file (for v1), a .designsystem file (for v2), or a zip file.

    • Select Upload to search for and select the file.

  4. Click Open.

The uploaded design system file displays in the list.

  1. Click the dots-vertical more options menu next to Create.

  2. Click Set Defaults, then customize:

    • Default design system: Sets a previously-created design system as the default for all v2 pages. Select from the dropdown menu.
    • Default theme: Sets a previously-created theme system as the default for all v1 pages. Select from the dropdown menu.
    • Default Page Designer theme: Sets the theme for the Page Designer, irrespective of API version. Select from the dropdown menu.

  3. Click Save.

From the dots-vertical more options menu

Access the following options from the the dots-vertical more options menu on an individual design system.

  1. Double click the design system you wish to configure.

    or

  2. Click the dots-vertical more options menu on the design system you wish to configure.

  3. Click Compose.

Note:  It's also possible to open and configure a page's selected design system from the page's properties, clicking View beside the selected Design system value.

  1. In the dots-vertical more options menu on the design system you wish to download, click Download as File.

Nintex Apps downloads a JSON file containing the design systems information.

  1. In the dots-vertical more options menu on the design system you wish to designate as the default, click Set as default.

In the list, Nintex Apps adds the default label to the design system.

  1. In the dots-vertical more options menu on the design system you wish to clone, click Clone.
  2. Customize the design system with a distinct name.

Note:  The name of the design system you are cloning from is indicated by default, appended with _Clone.

  1. Click Create.

To make a design system inactive in the Page Designer, so builders cannot select it:

  1. In the dots-vertical more options menu on the design system you wish to hide, click Hide in Page Designer.

In the list, the design system is grayed out and tagged as hidden. When builders select a design system for a page, the hidden design system does not appear in the selectable dropdown.

  1. In the dots-vertical more options menu next to the design system you with to delete, then click Delete.
  2. Click Yes, delete design system to confirm the deletion.

Design System Concepts

Design systems are made up of two elements: variables (saved values for design properties) and style variants (saved style configurations for individual components and subcomponents, which typically use variables for most of their properties).

Variables

When an app builder adds any component to their page in the Page Designer, the component uses a set of default Nintex Apps styles—called variables.

Similar to CSS style rules, variables are global style declarations (separated by categories), based on the general purpose of the variable (Color, Typography, etc.). Variables are used, along with component-specific property configurations, to create component style variants.

Every component uses a different combination of variables depending on the component's function and purpose, so not every variable will be used in a component.

Component styles are customized in the DSS to either:

  • Change the default style variables
  • Create new style variables

Once a variable is created, it can then be applied to a component style variant.

Style variants in components and subcomponents

Components are made up of components and subcomponents, and both are all listed under the Components header.

Selecting a component in the DSS will display all the configuration properties associated with the selected item. Most configuration properties require the use of variables as values, while some use property-specific values. If a component has any component dependencies, they will be listed under the Nested Components tab found in the properties pane.

Even if global variables have been configured, the unique properties of components require the creation of variables (and style variant ) to use in the component. It's normal for a workflow in the DSS to include a lot of interplay between variable creation and component configuration.

Note:  To effectively style component elements—those components and subcomponents that comprise a specific component — go to the component/subcomponent's own style variant.

Working in the Design System Studio

When you edit a design system, you're in the Design System Studio. This workspace is made up of three primary areas:

  • The left panel is for navigation. Here you select whether you want to view Variables or Components. After choosing a tab, this panel lists the categories of variables or the types of components/subcomponents available to edit. Selecting a variable or component/subcomponent here updates the center area.
  • The center area displays the variables or style variants available to edit, reflecting whichever is selected in the left navigation pane. Clicking a variable or style variant will open its properties in the right panel.
  • The right panel is for setting properties for the selected variable or style variant, similar to the Properties pane in the Page Designer.

Above these three areas are Save and Cancel, as well as undo Undo and redo Redo.

Note:  The Design System Studio's undo-redo history is stored in browser memory. Because of this, it does not have a defined limit, and it persists as long as you don't navigate to a new page. It's even possible to save your changes, and then undo them to a state before the save, as long as you do not refresh the page.

Variables

  1. In the design system, click the Variables tab.

  2. Click the category to customize.

  3. Click Add.

  4. Configure the properties of the new variable.

    • Make adjustments as desired.

Once a variable is created, it is available to be used on any categorically-related property in all style variants. Color variables may be used in color properties, spacing variables in space properties, etc. Click the variant, then click its properties and locate the one to configure. Click the dropdown list for that property to see the available variables.

For example:

  1. In the Components accordion, select Button.
  2. Select the Default style variant.
  3. In the properties pane, click the menu under General > Background color.
  4. Select your custom variable.

Style variants for components and subcomponents

Preview With...:

Some components have a property called Preview With, which provides the option to view a customized component with common configurations available within the Page Designer. This property is key to understanding how custom styles will apply to an app in runtime.

Create style variants within DSS components

There are three ways to create new style variants for component elements:

Once the new variant is created, you can name and configure it. Configure new style variants by choosing between component-specific property options listed in the property panel. In some cases, you can also pass in Variables.

All variants are based on the component element's default variant, which is essentially a "base" variant. Creating a style variant establishes a new base variant that you, as a builder, can freely style and apply to app pages.

To add a new Style variant that can be used in the Page Designer:

  1. Select the component you'd like to style.
  2. Click Add.
  3. Give the new Style Variant a Name.
  4. Configure.

Note:  Newly created style variants can be cloned or have children.

Cloning a style variant makes a copy of the variant. This copy is a new base variant that starts with all the same property settings of the variant it was cloned from. The builder can then customize the newly cloned style variant.

While the cloned variant and the original variant (that it was cloned from) start as identical, they are _not linked_. Changes to the original _do not affect_ the clone, and changes to the clone _do not affect_ the original. They are independent of one another.

To clone a Style variant:

  1. Select the component you'd like to style.
  2. Within that component, select the style variant you want to clone from.
  3. From the dots-vertical more options menu, click Clone.
  4. Give the new Style Variant a Name.
  5. Configure.

Note:  Cloned style variants can themselves be cloned or be used to create child variants..

Creating a child from another style variant creates a relationship between the two. The child inherits properties from the parent. This means that when a property changes in the parent, that change ripples through to the child variant.

The one exception to this inheritance rule is for properties in the child that have already been overwritten (customized) in the child style variant. Changes to those properties in the parent do not ripple through: the customization in the child supersedes any changes in the parent.

For properties that are inheriting from the parent, the value indicated in that property is - - Inherit - -.

The design system indicates child variants with an icon and a tool tip noting which variant the child is inheriting from. This icon and tooltip also display in the property pane.

To create a child variant:

  1. Select the component you'd like to style.
  2. Within that component, select the style variant you want to create a child from. .. warning:: This cannot be another child variant.
  3. From the dots-vertical more options menu, click Create Child.
  4. Give the new Style Variant a Name.
  5. Configure.

Important:  Child variants cannot be cloned or be used to create child variants.

Delete a style variant

  1. Select the style variant to delete.
  2. From the dots-vertical menu, click delete Remove.

Applying a Design System to a Nintex Apps Page

  1. Create a design system in the DSS.

  2. Navigate to the Nintex Apps page that contains the component you want to style.

  3. Click on the Page header in the canvas.

  4. In the Properties pane, under Design system:

    • Select the name of the desired design system from the dropdown.

Important:  Selecting your design system on Page Properties is critical. If you skip this step, your style variants will not be loaded into the page.

Apply Style Variants to Nintex Apps Components

Style variants are applied within the Page Designer by clicking a component on the canvas and navigating to its Styles properties. Style variants, and other style properties, can then be adjusted:

  1. In the Properties pane, select the Styles tab.
  2. Select your style variant in the Style Variant dropdown.

Use Style Variants for Conditional Styling

Though style variants can be applied within the Page Designer at the component level, they are also used as parameters for conditional styling logic.

Conditional styling allows builders to define a set of criteria that, when met, will change the visual design of a component or component element by applying a new style variant.

For more about configuring style conditions, see the conditional styling documentation.

Naming

Once a new design system, variable, or variant is created, you can name it. Give each style element a name that provides context and makes the purpose of the element distinct from others in the same category.

For example: consider two Button style variants, one used only for Form submission, the other to refresh a Form component. Names like "Form button 1" and "Form Button 2" don't incorporate function, and aren't useful for providing context. Names that do incorporate function, like "Form Button - Submit" and "Form Button - Refresh" are clear and purposeful. Someone unfamiliar with the design system would immediately know where those variants should be used and what they're used for.

There are two main naming conventions, each with pros and cons.

The first convention bases a name around the function represented. Imagine you create a specific color variable for form submission buttons. Following functional name convention, this color could be named "Submission Button Primary Color."

Pros:

  • The Primary default color variable is already used in most components, so changing color globally is as simple as modifying the default primary color Nintex Apps provides.
  • This option allows for context cluing, and gives a new designer working in the design system immediate understanding of that variable's purpose.

Cons:

  • Naming by function doesn't give visual context. If a color variable is named "Submission Button" it's not clear what color that actually is, making it difficult to understand the style ramifications of selecting a variable within a property's dropdown list.

The second convention bases a name specifically on its stylistic identity. For example, a company uses the Verdana font as a primary body text. Their app builder makes a new typography variable for this font face; if using the style naming convention, this variable could be named "Verdana."

Pros:

  • Naming by style allows for a design-focused design system that acts as more of a literal style guide instead of a functional style guide.
  • Style naming also allows for context cluing of what that variable actually looks like. For example, in a drop down menu where you'd select a color for an element, the color variable will display as "Red" and not just "Primary."

Cons:

  • The Primary default color is used across all DSS components. Deleting it in favor of a variable that follows style naming convention requires the designer to update any component property that once pointed towards the Primary variable.
  • Using the style naming convention, there's more chance for functional inconsistency because it's harder to know what function the color represents.
  • Using naming by style, a variable named after its font face could be used in multiple components for multiple purposes, leading to usability and visual cueing issues. If there's not a system in place to keep track of variable purpose, stylistic cohesion could be impacted.

The Nintex Apps default DSS includes variables that use both conventions as examples. It's up to the app builder to choose which they'd like to follow. Designers can also try mixing conventions, providing function first, then adding style. For example, a button color used only for form submission could be called, Form Submission Button - Red. A font face used only for headings could be called, Headings Font - Arial Bold.