Build a design token sync demo

[mcman12]

Research done last week by @delisma and @JoshBeveridge Working on a proof of concept that goes from Figma to code (design tokens), will talk more about it at review on Thursday.

[delisma]

• Design Token and their Value Proposition presentation
• Arcade: Scale Brand Decisions With Confidence (usearcade.com)
• Specify | Design Data Platform (DDP) (https://specifyapp.com/)

[delisma]

https://images.zenhubusercontent.com/390478939/e03dff4b-ab0b-4dcd-b190-8159b74657b7/design_workflow_optimized.mp4 Inspiration for designer/developer/policy workflow

[delisma]

About naming convention:

Definitely many parts of govt could have a different design. Scope for Canada.ca design is limited to those institutions subject to the Directive on the management of comms, which is more or less FAA schedules I, I.1, II.

So crown corps and other schedule III institutions are out of scope. Even of those within scope, there are exceptions; like RCMP, agents of parliament and a few others, for unique and bizarre reasons.

And then there’s the quasi-judicial which are in scope, but we have recognized that they need a different treatment due to their unique role.

It’s messy, but then so is govt :wink: That's why I think that a good naming convention can frame the mess between dept identities, web properties and campaigns. Effective token names improve and sustain a team’s shared understanding of visual style through design, code, and other interdisciplinary handoffs.

Terms matter. As we make things, we must be able to browse and search tools to quickly recognize and recall the purposeful decisions we’ve made. Not just in code and documentation, but in design tools too.

Small teams working in one namespace with limited collaborators need not worry about levels for namespace. However, given that tokens can propagate style across many departments, scopes and platforms, prepending namespace(s) to scope variables to a system, theme or domain can be essential.

System Name Many systems prepend a namespace level using a:

• System name, such as comet- or orbit-, even gcweb-😒 . Short system names, such as five characters or less, typically work well.
• System acronym for long names, such as slds- (for Salesforce Lightning Design System) or mds- (for Morningstar Design System).

As a result, common tokens namespaced to gcds (Government of Canada Design System) could appear to developers as $gcds-color-text-primaryand $gcds-font-family-serif, distinct from and easy to trace relative to the variables our team creates.

Theme Systems may often offer a theme (Crown Corp., RCMP, quasi-judicial org) that shifts colour, typography and other styles across a component catalog. A theme’s primary purpose would be to flow visual decisions that extend and often override existing tokens.

Domain A domain (aka department?) level offers namespaces for a group to create, isolate, and distribute a set of tokens on their own beyond the set coming from the system’s core.

[delisma]

Peter Smith 1:45 PM a solid naming convention will be really helpful in a messy complex environment like the GC Arianna Merritt 1:46 PM epic - one of our favourite words :) Peter Smith 1:47 PM ISED is letting EPIC go I believe... they are switching to Drupal Peter Smith 1:49 PM ISC, ISED, GAC even IRCC which has major web assets outside AEM Peter Smith1:58 PM ... there's so much technical and design debt in many of these depts....

[delisma]

Design token format specification

Example 1:

{
  tokens: [
    {
      name: 'Foo',
      value: 'Bar'
    },
    {
      name: 'I am a token',
      value: 'This is a value',
      description: 'A nice description.',
      data: {
        myOwnFlag: true,
        oneMoreThing: 'yay'
        vendor: {
          '@sketch': {
            // ...
          },
          '@figma': {
            // ...
          }
        }
      }
    }
  ],
  data: {
    vendor: {
      '@sketch': {
        // ...
      },
      '@figma': {
        // ...
      }
    }
  }
}
Example 2

{
  tokens: [
    {
      name: 'Foo',
      value: 'Bar'
    },
    {
      name: 'I am a token',
      value: 'This is a value',
      description: 'A nice description.',
      category: {
        'Color': {
            'value': 'Primary'
        }
    },
    alias: {
        'value': 'Also known as',
        'value': 'Peter Parker'
    }
      data: {
      myOwnFlag: true,
      oneMoreThing: 'yay'
      vendor: {
        '@sketch': {
        // ...
        },
        '@figma': {
        // ...
        }
    }
  }
}
Example 3:

{
  color: {
    brand: '#000',
    action: '#999'
  },
  space: {
    'line-height': [ 1.2, 1.4, 2 ],
  },
  type: {
    'page-headline': {
      family: 'SF',
      weight: 900,
      size: '2.5rem',
      line-height: space[ line-height ][ 2 ]
    },
    'section-headline1': {
      family: 'SF',
      weight: 700,
      size: '2rem',
      line-height: space[ line-height ][ 1 ]
    },
    'section-headline2': {
      family: 'SF',
      weight: 700,
      size: '1.5rem',
      line-height: space[ line-height ][ 1 ]
    },
    'body': {
      family: 'SF',
      weight: 300,
      size: '1rem',
      line-height: space[ line-height ][ 0 ]
    }
  }
}

[ioanacontu]

Discuss at the tech sync.

[mcman12]

created https://github.com/cds-snc/gc-design-tokens and gave admin rights to David, Pierre, Francis and Josh

[ioanacontu]

On pause while focus is on the naming convention.

[ioanacontu]

Potential demo for Review this week.