Start using design tokens in your apps, and try dark theme in Jira Cloud

How the early access program for Jira Cloud will work

Our friends in the Jira team are sharing details of the early access program with the Jira Community — read the full announcement — including with subscribers to the dark theme feature request ticket. This early access program gives you time to update your apps, while putting the feature to the test so everyone can help us improve it.

You (and customers) will be able to opt-in via Jira labs in personal settings, then switch between light/dark themes (or opt-out again). Note that our new light theme also looks different to the current appearance, though it’s subtle in most places — that’s the new colors doing their thing to bring improved accessibility and usability.

Jira labs

We want to be upfront and manage expectations: your apps won’t automatically render in dark theme yet — they will always render in light theme to your customers at present. We want to acknowledge that this may be confusing for some customers in the meantime. We’re clearly explaining that this is a preview, that Marketplace Partners are working on migrating their apps, and that customers should expect the first apps to start supporting dark theme around the beta period. We’ll also be filing gaps and fixing bugs in Jira itself over the coming weeks and months.

Coming soon, you will be able to You can now specify that your app supports theming so it renders in light/dark theme depending on user preference. Also, we provide a backward-compatibility API that you will need to use to specify fallback colors in addition to design tokens. This way, customers will continue to see those fallback colors if they have not explicitly opted-in to Jira labs, ensuring no unexpected visual changes.

See “Detailed steps to update your apps to support theming“ below for more…

[part 2/5 — back to top]

1 Like

Learn all about design tokens and theming

We recently added new docs to atlassian.design about what’s changing. Check them out if you haven’t already:

Why use design tokens and how do they help you as Marketplace Partners specifically? In addition to enabling features like dark theme and improved accessibility, design tokens make it easy for you to design and build apps that match the parent Atlassian product, such as Jira — and do it once.

Colors in your app will mirror and react to the active theme of the parent product to appear closely integrated and provide a consistent, familiar experience for customers. But not only that, as we continually improve the Atlassian Design System and iterate on colors, you’ll easily benefit from them too.

[part 3/5 — back to top]

1 Like

New Figma libraries and plugin to help you design with tokens

The wait is over! Today, we’re launching new tools to help you easily and quickly adopt design tokens in Figma as well as in code:

  • New Figma libraries that represent what’s in the Atlassian Design System — we’re aiming for design-code parity, and we’ve re-built all components to support design tokens, in both light/dark themes
  • A bespoke Figma plugin to discover and apply tokens much faster — you can migrate entire experiences to design tokens and even preview dark theme within the same file, saving you time
  • Dedicated learning material including video walkthroughs and guided learning playgrounds to help you get started, accessible from within Figma

Follow the links from the Figma tooling page on atlassian.design, and check out the ‘getting started’ content inside that’s tailored for Marketplace Partners.

Note: We’ve designed all of these tools to be used by both Marketplace Partners and Atlassian staff alike. But please be sure to follow the usage instructions for partners, as they’re different due to the way Figma Community works.

[part 4/5 — back to top]

1 Like

[part 5/5 — back to top]

Detailed steps to update your apps to support theming

Enabling instances for theming, and planned API changes

:new: Updated Mar 2023:

  • You no longer need to fill in a form to enrol your instances to start developing using design tokens
  • Themes are now enabled on all instances, including for customers if they have themes tuned on in the Jira labs section of their personal settings
  • Getting started now? Awesome! Follow the latest instructions on one page here: Theming Connect Apps – developer.atlassian.com
  • Already developing as part of early access? Read the update in this message below

Right now, you need to opt-in to your development instance by letting us know, so that it is manually enrolled in the early access program. All necessary theme configuration CSS files will then be automatically injected into apps, only on those instances, and the DOM of your app will be updated onload.

To reiterate: customers will not see your apps in light/dark theme yet, only you will on those instances

We recognise that automatic configuration within your app’s iframes is not ideal long-term (thanks again for your feedback on this topic!) and we are currently working on an additional API to give you more control over initialising theming. This will make theming an explicit opt-in that you will be able to self-service. This is expected to be available in January. At that point, we plan to enable themed rendering of your apps to customers if you have opted-in in code and they have opted-in via Jira labs.

Don’t want to wait? Want to start migrating your app right now using the current method? Fill in this form to let us know about your development instances, and we’ll enable access.

Once enabled, applications powered by Connect, Forge UIKit, and Forge Custom UI should now have access to the design tokens API without additional configuration or dependencies.

Verify that it is enabled by inspecting the HTML of your application whilst shown in Jira.

<html data-theme="dark" data-color-mode="dark">
  <head>
    <link rel="stylesheet" type="text/css" href="path/to/css/files.css">
  </head>
  <body>
   <!-- Your app here --> 
  </body>
</html>

Pay special attention to the data-color-mode="dark" attribute, and also note the data-theme="dark" attribute. These reflect the current theme state of the parent product (Jira). They also match CSS selectors within the theme files so the appropriate CSS variables can be activated in response to theme changes.

  • data-color-mode="dark" represents the color “mode” of the theme, with possible values today being light, dark or auto. This attribute tells your application what “type” of theme is active on the page, so that images and theme overrides may be applied consistently.
  • data-theme="dark" represents the active theme(s), but this is internal behaviour and should not be read or modified in any way, since the names and shape of this attribute may change at any time as we add more themes.
  • For example, if an additional theme high-contrast-light is introduced, the color mode will still be light, telling your application that it should respect a “light” color scheme and render light image variants accordingly. Hence please only rely on data-color-mode as above.

It’s time to update colors to design tokens

All that is left is to use tokens in place of colors throughout your application.

To view, search and filter through the available design tokens, visit the “All design tokens” section on atlassian.design. This page includes a “Token picker” tool which, through a series of questions, will help you find the right token for your use case.

For examples of how design tokens can be used in components, and common pairings of background and text colors, view the design token examples.

Design tokens are CSS custom properties so for vanilla CSS, Sass and Less, we recommend accessing design tokens in the following way:

background: var(--ds-surface-raised);

For CSS-in-JS , we strongly recommend you install @atlaskit/tokens as a dependency and use the tokens() function, which provides additional type safety.

+import { token } from '@atlaskit/tokens';
import { B400 } from ‘@atlaskit/theme/colors;

-color: B400
+color: token('color.background.selected.bold, B400)

Please make sure to keep the @atlaskit/tokens package up to date to ensure the tokens suggested are accurate and match the version of tokens injected into your application from Jira.

For more details, read the tokens migration guide on atlassian.design.

Backward compatibility

If you publish a tokenized version of your application during the pilot program, you will need to use fallback colors in addition to design tokens to ensure there are no visual changes exposed to end users, since tokens will not be active for all customers until general availability.

This involves using CSS custom property fallbacks:

/* CSS, Sass, Less */
background: var(--ds-surface-raised, #eeeeee)
/* CSS-in-JS */
import { token } from '@atlaskit/tokens';
import styled from 'styled-components';

const App = styled.div`
  background: ${token('elevation.surface.raised', '#eeeeee')};
`;

Whenever a design token is not found, the fallback value will be shown instead. These values should always contain the color in use prior to adopting tokens. If done correctly, your app will appear with no visual changes until we globally enable light/dark themes, at which point tokens will be automatically enabled and shown in your application.

If you are creating new experiences with design tokens, please continue to use both a token and a fallback value. This will be necessary until design tokens are globally enabled as the default color experience across Atlassian products.

Bespoke color schemes

If your application uses colors that correspond to your unique brand, it is still possible to theme your app by querying the html[data-color-mode] attribute and styling your applications with your own tokens.

html[data-color-mode="light"] {
 --my-custom-background-token: white;
 --my-custom-text-token: black;
}

html[data-color-mode="dark"] {
 --my-custom-background-token: black;
 --my-custom-text-token: white;
}

Please note, this approach may cause color discrepancies between your app and the parent product, so it’s recommended to use it sparingly.

Staying up to date

Our design tokens are designed to evolve over time, moving through a lifecycle of active, deprecated, and deleted, eventually being fully removed from the theme (no longer functional). Tokens will be marked as deprecated in a minor version, soft-deleted (functional but will raise errors) in the following minor, and deleted in the next major release of the tokens library.

Please also review the @atlaskit/tokens changelog to monitor changes to tokens and API.

To simplify the migration and to simplify continuous adoption, we recommend you install and configure the following linters:

For CSS-in-JS we provide the following eslint plugin: @atlaskit/eslint-plugin-design-system

Install: npm i -D @atlaskit/eslint-plugin-design-system

Configure:

// .eslintrc.js 
module.exports = {
  rules: {
    '@atlaskit/design-system/ensure-design-token-usage': ['error', { 'shouldEnsureFallbackUsage': true }],
    '@atlaskit/design-system/no-deprecated-design-token-usage': 'warn',
    '@atlaskit/design-system/no-unsafe-design-token-usage': ['error', { 'shouldEnsureFallbackUsage': true }],
  }
};

For vanilla CSS, Less, Sass we provide the following Stylelint plugin:

Install: npm i -D @atlaskit/stylelint-design-system

Configure:

// .stylelint.js
module.exports = {
    rules: {
        'design-system/ensure-design-token-usage': true,
        'design-system/no-deprecated-design-token-usage': [true, { severity: 'warning' }],
        'design-system/no-unsafe-design-token-usage': [true, { shouldEnsureFallbackUsage: true }],
    },
    plugins: [
        '@atlaskit/stylelint-design-system',
    ],
};

These linters will warn and error for deprecated and deleted tokens respectively. They also have built-in auto-fixers that allow you to update your entire app to the latest tokens automatically via eslint --fix and stylelint "**/*.css" --fix .

Known issues and FAQs

Server-side rendering

Currently, support for server-side rendering (SSR) is not yet available. Apps utilising SSR may experience intermittent flashing between light/dark themes when loaded. If you are experiencing this issue, please make sure to let us know the details of your SSR solution so we can take that into account in our upcoming work.

Charts/HTML Canvas

Our design tokens are based on CSS custom properties (aka CSS variables), which makes it challenging to use tokens in JavaScript. For scenarios where knowledge of token values in JS is necessary, such as dynamic data visualisations via HTML Canvas, it’s not yet possible to use tokens. We are working on this and will be sharing a new API to support this early next year.

Illustrations and dark theme images

We are currently creating tools & guidance for switching graphical assets to match the active theme. We’ll share more information on this shortly.

My app uses ADF, how do I render colors in dark theme?

If you have a custom ADF renderer, please let us know. Special handling is required, and we’ll work with you on the details.

An @atlaskit component still appears in light theme even when dark theme is active.

Most @atlaskit components have been instrumented with the new design token API. It’s possible that you are using a version of the component before tokens were added. If this is the case, please upgrade the component to the latest version.

Review the changelog in the “Code” tab of the component’s docs to see which version introduces design tokens. For example: @atlaskit/avatar. If the problem persists after you have upgraded, please let us know.

What if my apps are for both Cloud and Data Center?

The Atlassian Design System represents how we’ll be designing Atlassian products into the future, even as we continue to support Data Centre (DC). We’re continually investing in our Design System, and we recommend you standardise your app’s design on the latest and greatest: the colors, elevations and design guidance that we’re introducing here.

Using design tokens as the starting point will make it easier for you to keep experiences familiar between your app and the parent product, as many customers move to Cloud.

We’re primarily focused on supporting apps in Jira Cloud today. But we’re open to ideas for how we can make it easier in the future for those of you who develop for both Cloud and DC, so please reply and let us know.

Once again, thanks for your support and please reply below if you have any questions.

We’ll be adding docs to atlassian.design with all of this info as well, once the planned API changes mentioned above are finalised. Happy tokenising!

[part 5/5 — back to top]

5 Likes

We use the same front-end (with AtlasKit and DS components) for both Cloud and Server/DC. If the AtlasKit / DS components are not aligned with Jira Server/DC, and customers notice this, we will redirect them to Atlassian Support. The promise from Atlassian has always been that both Cloud and Server/DC implement ADG3. We will hold you to that promise.

2 Likes

Can you elaborate on what these APIs will look like? I gave a few suggestions here Introducing design tokens, new colour foundations and dark mode - #37 by remie but did not receive any feedback on which solution is going to be implemented.

2 Likes

@stephenmok Thank you for the detailed overview. That helps a lot!

1 Like

@stephenmok any chance this (data-color-mode) could be added to dashboard wallboards too? Since at the moment wallboards always render in dark mode (regardless of a host mode) and the apps has a functionality to account for this using “.ac-content-wallboard” selectors. But it would be better not to add double functionality for wallboards and dark mode.

2 Likes

There’s also a question what to do with app icons in Jira navigation if we want to follow native product monochrome style

It’s either we now have to switch to colorful variant which will be visible both in dark and light theme and will not align with native product experience

Or there should be a possibility to specift dark/light icon in all modules that have user-facing icons

A perfect solution would be if it was possible to provide SVG icon in the way, so it can inherit primary/secondary icon color from current Jira styles (which is not currently possible AFAIK). But I’m not sure if it’s possible without embedding svg code, which can potentially become a security nightmare

Hey @remie, the team is still in the experimentation phase and is considering different options for implementing the theming APIs. At this stage, we intend to make theming an opt-in feature for Connect.

Hi @RaimisJ thank you for bringing this to our attention. We’ll follow up internally and get back to you.

Would you be open to sharing the different options during the experimentation phase for early feedback? Or at least ensure that the outcome of the experimentations is going to be a draft status for Marketplace Partners to give their opinions?

Hey @remie,

Currently, the plan is to follow your recommendation to, at a minimum, make theming an opt-in feature for Connect. The direction we’re experimenting with at the moment is to provide an AP method that allows you to initialise/opt-in to theming when the app loads (we’re also planning to look into options for SSR, we will share an update on that early next year.)

It would look something like this (ignore naming for the time being):

function themeChangedCallback(theme) {
 // This is fired when the parent app's theme preferences change at runtime
}

// Styles are injected into the page + attributes are mounted to the HTML tag
AP.mountTheme(themeChangedCallback);

Resulting in:

<HTML data-theme="dark" data-color-mode="dark">
  <head>
    <style data-attr="theme-light">...</style>
    <style data-attr="theme-dark">...</style>
  </head>
  <body></body>
</HTML>

We are also assessing the feasibility of an App Descriptor-based approach per the recommendation of another partner.

That being said, our approach is not locked in yet, we’re still iterating and open to feedback. We’ll do our best to factor in as much as we can whilst also balancing the constraints of the system.

By the way, I’m not sure if you saw my response to this thread, but we’re running an early access program to give our partners a chance to trial the implementation and provide feedback directly. Would really encourage you to check it out!

Would you be interested in enrolling into our ecosystem EAP to give tokens a try directly in your app? You’ve shared some good feedback on the API already so far so could be beneficial for you to participate more directly. More information here .

Cheers,
Dan.

2 Likes

+1 for having the (dashboard) wallboards use the same mechanism as the dark mode.

We also need a way to request a certain theme in iframes programmatically. Like others mentioned, wallboards are one example use case, though we also have others in mind (so just a wallboard-specific solution would not work for us).

How about something like this?

AP.setThemeOptions({
   theme: 'dark' | 'light' | 'auto',
   colorMode: 'dark' | 'light' | 'auto',
   // and there’s room for other stuff later
})
1 Like

How about something like this?

AP.setThemeOptions({
   theme: 'dark' | 'light' | 'auto',
   colorMode: 'dark' | 'light' | 'auto',
   // and there’s room for other stuff later
})

That would be the best solution, it would cover the wallboards case and any other cases that might arise in the future. This way we wouldn’t have to always ask Atlassian to deliver a specific change for each specific case / new feature apps need to deliver – apps would be able to do what they need, when they need.

Hi, we are testing the new dark theme integration with our app.

One thing we have noticed is the different CSS value for the background-color when the integration is displayed inside a Kanban view compared to the Issue view.

On the Kanban is used --ds-surface-overlay instead on the Issue is used --ds-surface. Since we don’t know if our app is displayed inside a Kanban or an Issue, we choose to set the background color as --ds-surface-overlay, but it doesn’t look so good in the Issue view.

How we can handle this difference of the background color ?

2 Likes

@AndreaSerra thanks for raising this! We are currently looking into a method for apps to receive information about the current surface they’re placed onto, and will provide updates once the API is available to use in Connect and Forge Custom UI apps.

In the meantime, we recommend using the surface that matches in the most places, or is seen most often by users - in the Jira Issue View this would be elevation.surface.
Let us know if you have any other questions, or other examples where this issue occurs.

1 Like

Hey partners,

@atlaskit/tokens version 1.0.0 is coming soon and changes will be required in your apps — please get ready, but don’t upgrade to 1.0.0 yet. Read all the details here:

Cheers,
Stephen

Hey folks, the changes mentioned above will be rolling out on Mon 27 Feb 2023 — please read the thread for more details of actions required. Thanks!