디자인시스템 토큰 이름붙이기 [Naming Tokens in Design Systems]

디자인 시스템의 토큰에 이름 붙이는 방법을 알아봅니디.

부제 : 비주얼 스타일을 설명하는 용어, 유형 및 분류; Base, Modifier, Objects, Namespace

원문 : https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676

Naming Tokens in Design Systems

디자인 토큰은 Salesforce가 2014년에 개념을 개척한 이후로 (Salesforce pioneered the concept in 2014)

많은 디자인 시스템의 시각적 기반을 제공했습니다.

저는 2016년에 디자인 토큰에 대한 열정적인 기사(impassioned article on design tokens in 2016)를 썼고

이 주제에 대한 제 에너지는 계속해서 커지고 있습니다.

시각적 스타일 시스템이 컴포넌트, 플랫폼 및 출력의 광범위한 환경에 확산됨에 따라

디자인 토큰과 그들의 이름은 점점 더 중요해지고 있습니다.

효과적인 토큰 이름은 디자인, 코드 및 기타 조직(interdisciplinary)간 의사소통 시,

시각적 스타일에 대한 팀의 공유된 이해를 개선하고 유지합니다. 

용어(Term)는 중요합니다.

우리는 일을 할 때 우리가 내린 결정을 빠르게 인식하고 기억할 수 있는 도구를 사용해야 합니다.

코드와 문서뿐만 아니라 디자인 도구에서도 마찬가지입니다.

코드(왼쪽), 문서(가운데) 및 디자인 도구 스타일(오른쪽)에 걸친 디자인 토큰. 이름이 완벽하지 않습니다. 불일치를 발견할 수 있나요?

그리고 이름을 붙이는 것은 어렵습니다.

원문에는 다양한 빅테크들이 공유한 자신들만의 방법론이 있으니 참고하세요

예시 : 세일즈 포스 (Ferrua & Rewis, Clarity 2019)

Salesforce UX Token hierarchy (Ferrua & Rewis, Clarity 2019)

기초부터 시작하기

단순한 디자인 토큰도 레벨을 이용한 네이밍 패턴을 보여줍니다.

예를 들어 $esds-color-neutral-42 토큰은

namespace(이 예에서 esds; "EightShapes design system"을 나타냄),

category, variant, scale 네 가지 수준을 갖고 있으며 값 #6B6B6B에 매핑됩니다.

유사하게, $esds-space-1-x는 namespace, category 및 scale 레벨을 갖고 있으며 값 16px에 매핑됩니다.

 

Complicated tokens comprised of many levels: namespace, category, concept, property, variant, and scale

위의 일반적인(generics) 디자인 토큰이 아닌 더 많은 레벨을 포함한 토큰은 복잡하지만 구체적인 토큰으로 이어집니다.

$esds-color-feedback-background-error 및 $esds-font-heading-size-1은 값의 목적을 좀더 구체적으로 나타냅니다.

(각각 #B90000 및 64px에 매핑됩니다).

$esds-marquee-space-inset-2-x-media-query-s는 컴포넌트명과 category / scale의 의미를 갖고 있네요

충분한 의미를 나타내기 위해선 분류와 유형의 충분한 레벨이 필요합니다.
충분한 레벨은 그룹으로 구성하기에 충분한 수준을 의미합니다.

• Base :
  • cateogry(예: color),
  • concept(action)
  • peoperty(size)
  • 토큰의 중추 수준
• Modifier :
  • variant (primary)
  • state (hover)
  • scale (100)
  • mode (on-dark)
  • 위의 어떤 것(어떤 토큰의 변종)을 하나 이상 나타내는 수준
• Object :
  • component(button)
  • component 내의 element(left-icon)
  • component group (form)
  • 컴포넌트를 나타내는 수준
• Namespace :
  • system(esds)
  • theme(ocean 또는 하위 브랜드)
  • (비즈니스)domain(retail)
  • 혹은 어떤(극단적인 경우 모두!) 무언가를 나타내는 수준

Bloomberg, Salesforce, Orbit, Morningstar, Infor 및 Adobe에서 primary action의 호버 색상을 나타내는 토큰

Tokens presenting a primary action’s hover color, from Bloomberg, Salesforce, Orbit, Morningstar, Infor and Adobe

각 시스템은 레벨을 다르게 적용합니다.

위의 다이어그램은 primary action의 호버링된 색상을 나타내는 토큰에 대한 6개의 서로 다른 카탈로그의 토큰을 보여줍니다.

이 문서에서는 base를 modifier, object, namespace로 의미를 확장하여 토큰 이름을 지정합니다.

그 과정에서 완전성, 순서 및 다계층 구조와 같은 원칙과 주제는

토큰 인벤토리가 증가함에 따라 팀이 직면하는 문제에 대한 이해를 심화합니다.

 

물론 최선을 다해도 최적의 토큰 명을 찾지는 못할 수 있습니다.

---

Base Levels

category, property, concept

category 및 property는 토큰 이름의 기반이 되는 출발점을 제공합니다.

컬렉션이 커짐에 따라 토큰 하위 집합이 concept을 이용해 구성되므로 카테고리 수준만으로는 충분하지 않습니다.

Category

토큰은 color, font 또는 space과 같은 원형적인 범주 내에 존재합니다.

연관된 variant 용어가 있는 공통 카테고리

카테고리는 시각적 스타일 문제에 걸쳐 있으며 때때로 겹칠 수 있습니다.
보통 각 시스템에서는 각 카테고리를 다른 방식으로 명명합니다.

일반적인 카테고리는 다음과 같습니다.

• color
• font (aka type, typography, text)
• space (aka units, dimension, spacing)
• size (aka sizing)
• elevation (aka z-index, layer, layering)
• breakpoints (aka media-query, responsive)
• shadow (aka depth)
• touch
• time (aka animation, duration)

위의 목록에서 볼 수 있듯이, 예제는 "선호 용어"(font와 같은)

다음에 동일한 목적으로 다른 시스템에서 사용되는 "변형 용어"(예: 타입 및 타이포그래피)를 의미하는 "aka"으로 이어집니다.

이러한 동등한 용어는 팀이 통제된 어휘(controlled vocabulary)를 형성 시 영감을 주기 위해 제공됩니다.

원칙: 동음이의어를 피합니다.

최상위 카테고리조차 어려운 선택을 유발합니다.

type은 동음이의어이며, 타이포그래피의 약칭이나 카테고리(유형)와 같이 다양하게 해석됩니다. 골칫거리입니다!

유사하게, 일부는 타이포그래피를 텍스트로 대체하지만 text는 content 및 property의 동의어이기도 합니다.(나중에 자세히 설명합니다).

타이포그래피가 너무 길기 때문에 팀은 종종 font를 선택하게 됩니다.

Property

category는 토큰을 정의하기 위해 관련 property와 쌍을 이룰 수 있지만,
의도적으로 의미 있는 값을 정의하기에 쌍 만으론 충분하지 않을 수 있습니다.

Category/property example pairs

색상과 관련한 예는 text, background, border 및 fill이 포함되며
다음과 같이 일반적인 토큰이 생성됩니다.

$color-background: #FFFFFF
$color-text: #000000
$color-border: #888888

일반적인 타이포그래피 property에는 size, weight, line-height, letter-spacing 이 있습니다.

$font-weight: normal
$font-size: 14px
$font-line-height: 1.25

범주/속성 쌍은 매우 일반적이지만, 유용하지 않습니다. concept과 modifier가 필요합니다.

Concept

토큰은 하나 이상의 Concept(개념)을 추가하여 Category 별로 그룹화할 수 있습니다.

예를 들어 color은 variant와 함께 다음과 같은 concept으로 그룹화할 수 있습니다.

• feedback (aka notification, messaging, alert)
  • success , warning, error 같은 variants
• action (aka cta, interactive, interaction) to corral colors affording calls-to-action (links, buttons, …) and selected items (like tabs, navigation items, checkboxes, radio buttons, and filters).
  • 어려운 내용입니다. https://ux.stackexchange.com/questions/14115/is-there-a-science-to-what-colors-to-use-on-primary-call-to-action-buttons 를 확인하세요.
• visualization (aka dataviz, charting, charts). The financial Morningstar Design System even includes sub-concepts within visualization for correlation, valuation, performance, and asset-allocation colors and a default visualization color order.
  • variant는 시각화 대상 수치(performance 등)
• commerce colors
  • variants for sale, clearance, inventory, and timing urgency.

즉 concept은 variant과 결합하여
$color-feedback-success, $color-action-primary 및
$color-visualization-performance-positive와 같은 토큰을 형성합니다.

타이포그래피 토큰은 종종 heading(aka header, heading-levels, headline, display) 및 body(text라고도 함 - 동음이의어가 또 있습니다!) 같은 개념으로 그룹화됩니다.

eyebrow heading 또는 lead(일명 lede, deck, subheader, subhead)개념와 같은 특수화 케이스는

각각 headings(1, 2, 3, …) 및 body(s, m, l) 개념과 다르게 느껴집니다.

이러한 명명 문제는 충분히 목적이 있는 이름을 달성하기 위해 variant 및 scale 수준이 어떻게 필요한지 암시합니다.

원리: 내부의 동질성, 간의 이질성

모든 수준, 특히 개념에서 클래스 내 동질성(예: 시각화)과 클래스 간의 이질성(예: 시각화 vs 상거래)을 위해 노력합니다.

개념 수를 적게 유지하기 위해 sale 및 clearence를 visualization에 포함할 수 있지만,

visualization은 차트를 위한 것이고

나머지는 이커머스 비즈니스 폴로우를 위한 것입니다.

고유한 의미가 주어지면 별도의 개념으로 나눕니다.

---

Modifiers

variant, state, scale, mode

토큰은 variant, state, scale 및 mode 수준을 수정(modify)하여 목적을 부여합니다.

Modifier는 category, concept 및 property 수준과 독립적으로 또는 함께 사용됩니다.

그리고 stylistic typology를 형성합니다.

Variant

variant은 대체 사용 사례를 구별합니다. 예를 들어, 디자인 언어는 다음과 같이 텍스트 색상을 변경하여 계층 구조와 대비를 만듭니다.

• primary (aka default, base)
• secondary (aka subdued, subtle)
• tertiary (aka nonessential)

마찬가지로 인터페이스는 사용자에게 다음을 경고하기 위해 feedback 색상을 다양화합니다.

• success (aka confirmation, positive)
• error (aka danger, alert, critical)
• information (aka info)
• warning
• new

$color-text-primary, $color-background-warning 및 $color-fill-new와 같은 토큰은
category / property 쌍을 variant와 결합합니다.

 

원칙 : 유연함 vs 특정성

$color-success와 같은 토큰은 category(cateogry)와 variant(success)을 많은 시나리오에 적용할 수 있는 간결한 식별자로 결합합니다.
사용자가 background, border 또는 font(text)에 $color-success를 적용할 수 있는 여지를 남깁니다.

 

유연성은 특정성을 희생하고 더 나아가 적용의 정확성을 희생합니다.

success 색상은 텍스트 또는 배경에 사용할 수 있지만 동시에 적용하면 안됩니다.

더욱이, 성공을 반영하는 개체는 텍스트 대 배경 대 테두리에 대해 뚜렷한 색상이 필요할 수 있습니다.

이 경우 토큰에 속성 수준을 포함하면 더 구체적이면서도 덜 유연한

$color-background-success 또는 $color-text-success이 됩니다.

---

State

토큰은 대화형 상태(State)를 기반으로 속성을 지정할 수 있습니다.

• default
• hover, when a pointer is positioned above an object
• press / active, between the time a user presses and releases an object
• focus, when an object is able to accept input
• disabled, when an object is not able to accept input
• visited, for alternative link display when already visited
• error, when an object is in an error state

상태는 종종 Object(button) 또는 variant(secondary)가 있는 Category(color), Concept(action) , Property(text)와 연관됩니다.
그 결과 $color-action-text-secondary-focus와 같은 완전한 형태의 토큰이 생성됩니다.

---

Scale

토큰은 사물에 적용되는 다양한 size, space 및 기타 옵션의 선택을 확장합니다. 일반적인 scale은 다음과 같습니다.

• 값의 나열
  • Enumerated values like heading levels’ 1, 2, 3, 4, and 5.
• 정렬된 값의 나열
  • Ordered values like Google Material color levels of 50, 100, …, 900.
• 정해진 범위의 스케일
  • Bounded scales like HSL’s 0 to 100 lightness value to vary shades of a tint, such as slate gray’s slate-42, slate-90, and slate-95.
• 비율
  • Proportion, often establishing a base 1-x and growing (2-x, 4-x, …) and shrinking (half-x, quarter-x, …) relatively.
• 티셔츠 사이즈
  • T-shirt sizes, starting with small (variants: s), medium (variants: m, standard, base, default) and large (variant: l) and expanding to xl, xs, and xxxl. Pro tip: Size ≠ space, so consider using proportion instead of t-shirts for space despite what I said four years ago.

scale은 일반적인(generic) 토큰과 목적이 있는 토큰(Purposeful token) 모두에서 나타납니다.

예를 들어, 대부분의 시스템은 32px에 대해 $esds-space-2-x와 같은 일반적인(일명 primitive한) 스페이서를 정의하고

목적있는 사용을 위해 #6B6B6B 색상에 대해 $esds-color-neutral-42와 같은 별칭을 지정합니다.

이 경우 2-x 및 42는 각각 비율 및 밝기를 의미합니다.

 

목적이 있는 토큰은

$esds-font-size-heading-level-1 및

$esds-font-size-body-small와 같은 토큰에 대한

category(font), concept(heading) 및 property(size)의 컨텍스트에서 scale(level-1)를 지정합니다.

흔하지 않지만, 특이도(specificity)는 concept/scale 쌍들을 하나의 토큰으로 연결합니다.

예를 들어, heading의 스케일을 값의 나열 수준(1, 2, 3, …)으로

미디어 쿼리 중단점(media-query)스케일을 티셔츠 사이즈로 설정후 결합하여

45px과 같은 값을 나타낼 수 있습니다.

(즉, 브레이크포인트 l일때, 2레벨의 폰트 사이즈는 45px)

Mode (Usually, for “Light” and “Dark”)

토큰은 Mode Modifier를 사용하여 element가 나타나는 둘 이상의 surface/background 설정에서 값을 구별할 수 있습니다.

이것은 별개의 라이트 모드와 다크 모드를 가능하게 하고

표현력이 강한 시스템은 추가 브랜드 색상(brand-color) 모드로 확장될 수도 있습니다.

(EightShapes의 경우 많은 컴포넌트가 놓이는 orange surface).

예를 들어 수직 필터,수평 탭 ,수직 네비게이션에서 항목의 호버링된 배경색을 식별하기 위해

$color-action-background-secondary-hover-on-light 및

$color-action-background-secondary-hover-on-dark

모두에 대한 토큰이 필요할 수 있습니다. 

이것은 토큰의 양을 증가시키지만 실제로는 작은 부분집합으로 제한되며
많은 예측 가능한 목적에 재사용할 수 있는 더 간단한 값(예, $color-accent-hover-on-dark)의 별칭으로 지정함으로써 완화됩니다.

원칙: 명시적 기본값 대 잘린 기본값

mode를 사용하는 토큰은 defailt 배경(일반적으로 "light" 또는 white)을 가정하고

"dark" 대안에만 on-dark modifier를 추가할 수 있습니다.

이것은 on-dark가 관련 없는 많은 토큰에 on-light를 추가하지 않아도 됩니다.

반면 일부 시스템은 형제 토큰에 대한 병렬 구성에 의존하여 토큰 세트를 예측 가능하게 반복하므로
on-light, on-dark 및 on-brand 모디파이어 명이 명시적으로 필요합니다.

원칙: 수정 용어를 포함하거나 제외합니까?

토큰은 dark 또는 light와 같은 레이블 앞에 on-fore와 같은 용어를 추가하여 더 명확하게 읽습니다.

그러나 on-dark는 더 많은 공간을 차지하며 입력하는 데 더 많은 노력이 필요합니다.

그러한 선택은 개인 취향에 크게 치우쳐 있습니다.

물론, 나는 on-light의 가독성을 선호합니다.

그러나 내 의견의 Cap Score(Cap Watkin의 “Sliding Scale” 참조)는 이미 존재하는 컨벤션을 파괴할 정도로 강하지는 않습니다.

 

---

Objects

component, element, component group

토큰은 컴포넌트 카탈로그 전체에서 의도적인 결정의 재사용을 약속합니다.

그럼에도 불구하고 몇 가지 컴포넌트에서만 토큰을 재사용할 수 있는 순간이 있습니다.

즉, 단일 컴포넌트에만 적용될 뿐입니다.

Object 수준은 component, 중첩된 component 내의 element, 또는 컴포넌트 그룹과 관련된 토큰을 분류합니다.

이것은 일반적으로 form과 같은 컴포넌트 클러스터에서 작업할 때 발생합니다.

예를 들어, input 컴포넌트는 $esds-color-text-primary와 같은 기존 토큰을 사용하여 텍스트에 색상을 지정합니다.

반면에 토큰 컬렉션에는 input의 border 색상 및 roundness에 적용할 만한 게 없을 수 있습니다.

$esds-color-neutral-70과 같은 일반 토큰과 4px와 같은 명시적 값이면 충분하지 않습니까?

 

컴포넌트 내부

테두리 색상은 다른 곳과 관련이 있을 수 있지만 보장할 수는 없습니다.

이 경우 해당 컴포넌트별 토큰($esds-input-color-border)을 어딘가에 기록하고 싶을 것입니다.

하지만 어디에 있어야 할까요?

글로벌 토큰은 시작 장소가 아닙니다.

대신, input의 디자인 사양이나 input.scss 파일의 헤더와 같은 해당 컴포넌트의 특정한 위치에 기록하십시오.

이러한 위치는 기존 이름을 사용하여 결정을 기록하고 다른 컴포넌트에서 작업할 때 과거 결정을 참조하는 데 편리합니다.

중첩 엘리먼트

input과 같은 원자(atomic) 컴포넌트조차도 아이콘 및 링크와 같은 중첩 엘리먼트를 가질 수 있으며 스타일을 재사용할 수 있습니다.

중첩된 컴포넌트 엘리먼트에 특정한 토큰은 BEM CSS 방법론과 마찬가지로 컴포넌트 이름과 엘리먼트 이름을 모두 포함할 수 있습니다.

마찬가지로 요소별 토큰은 input.scss와 같은 로컬 컨텍스트에서 아래와 같이 나타날 수 있습니다.

: $esds-input-left-icon-color-fill, $esds-input-left-icon-size, $esds-input-inline-link-color-text

컴포넌트 그룹

form(ui-controls 또는 form-controls라고도 함)과 같은 컴포넌트 그룹은

한 컴포넌트에 로컬인 토큰과 관련이 있으며 의미 있는 그룹을 함께 형성하는 다른 관련 컴포넌트와 관련이 있습니다.

예를 들어 Select, Checkbox 및 Radio Button은 테두리에 $esds-color-neutral-70을 사용할 수도 있습니다.

결정은 많은 수의 컴포넌트와 관련이 있으므로(내 경험에 따르면 3개 이상)

지금은 다음을 수행할 때입니다.

• 글로벌 토큰에 $esds-forms-color-border를 추가합니다.
• $esds-input-color-border를 $esds-forms-color-border로 바꿉니다.
• input.scss에서 $esds-input-color-border를 제거합니다.
• Select, Checkbox 및 Radio에 $esds-forms-color-border를 적용합니다.

원칙: 컴포넌트 내부에서 시작한 다음 컴포넌트 간 토큰으로 승격

후보자를 식별하고 지역에서 글로벌 위치로 토큰 아이디어를 승격하는 관행은 토큰을 점진적으로 추가하는 건강한 방법입니다.

원칙: 성급하게 결정을 글로벌화하지 마십시오

일관된 form 엘리먼트 테두리에 대한 공통된 필요성은 예측 가능합니다.
이러한 엘리먼트는 함께 설계되며 이러한 규칙의 필요성은 빠르게 나타납니다.

다른 경우는 명확하지 않습니다.

popover와 menu가 나중에 등장할 수도 있는 툴팁 작업을 상상해 보십시오.

시스템은 shadow와 notch roundness을 재사용할 수 있지만 보장할 수는 없습니다.

이 경우 툴팁 설명 특정 토큰을 해당 컴포넌트에 로컬로 유지하고 나중에 팝오버 또는 메뉴 시작 작업 시 참조하십시오.

이것은 짜증나게 주관적인 논쟁("이것이 notched-layers입니다!")과 글로벌 네임스페이스를 조기에 오염시키는 것을 방지할 수 있습니다.

---

 

Namespaces

system name, theme, domain

제한된 공동 작업자가 있는 하나의 네임스페이스에서 작업하는 소규모 팀은 네임스페이스의 수준에 대해 걱정할 필요가 없습니다.

그러나 토큰이 많은 범위와 플랫폼에 걸쳐 스타일을 전파하기 위해 존재한다는 점을 감안할 때

시스템, 테마 또는 도메인에 대한 범위 변수 앞에 네임스페이스를 추가하는 것이 필수적일 수 있습니다.

System Name

많은 시스템에서 다음을 사용하여 네임스페이스 수준을 추가합니다.

• 시스템 명(System name) : comet- or orbit- 같은 시스템 이름. 5자 이하와 같은 짧은 시스템 이름은 일반적으로 잘 작동합니다. 그렇지 않으면 ...
• 시스템 약어(System acronym) : slds-(Salesforce Lightning Design System용) 또는 mds-(Morningstar Design System용)와 같은 긴 이름의 약어입니다.

결과적으로 esds로 네임스페이스가 지정된 공통 토큰은
팀이 생성하는 변수와 구별되고 상대적으로 추적하기 쉬운
$esds-color-text-primary 및 $esds-font-family-serif로 개발자에게 보여집니다.

Theme

시스템은 종종 컴포넌트 카탈로그 전체의 색상, 타이포그래피 및 기타 스타일을 전환하는 테마를 제공할 수 있습니다.

예를 들어, 메리어트와 같은 조직은 JW 메리어트, 르네상스, W, 코트야드 및 기타 호텔에 대한 테마를 정의할 수 있습니다.

테마의 주요 목적은 기존 토큰을 확장하고 종종 무시하는 시각적 결정을 내리는 것입니다.

Marriott's Courtyard 테마의 경우 버튼, 체크박스, 선택한 탭 강조 표시와 같은 구성 요소에 브랜드 액션 색상(#a66914) 토큰이 흐를(flow) 수 있습니다.

테마 아키텍처에서 이름 지정 및 토큰 흐름(flow)에 대한 규칙은 이 기사의 범위를 벗어나는 상당히 복잡한 주제입니다.

그러나 여기에는 테마 수준의 의도를 명확히 하기 위해 몇 가지 "테마에 대한 테마"가 설정되어 있습니다.

 

예를 들어, 어떤 (예: $aads "Animation App Design System"을 사용하는) 애니메이션 앱이

ocean, sands, mountain, and sunset과 같은 색상 테마를 제공할 수 있다고 가정합니다.

각 테마는 일반화된 컨텍스트와 특정 컨텍스트 모두에서 유사하지만 고유한 디자인 토큰이 달라야 할 수 있습니다.

// General tokens to alias thematic colors to many contexts
$aads-ocean-color-primary
$aads-sands-color-primary
$aads-sunset-color-secondary
// Specific token overrides and extensions
$aads-ocean-color-heading-text-1
$aads-sands-color-heading-text-1
$aads-mountain-color-alert-background-success​

토큰 결정을 기록하는 한 가지 방법은 시스템 네임스페이스(예: aads)에 테마(ocean)를 추가하여 $aads-ocean의 네임스페이스를 좁히는 것입니다.

이 네임스페이스는 시스템 작성자에게 기본 토큰 값을 재정의할 수 있고, 때때로 확장할 수 있는 테마별 값을 매핑 장소를 제공합니다.

예를 들어, 바다 테마에 대한 시각적 결정을 컴파일할 때 다음 매핑이 관련될 수 있습니다.

$aads-color-text-primary 
  = $aads-ocean-color-primary;
$aads-color-forms-text-metadata 
  = $aads-ocean-color-primary;
$aads-color-background-secondary-on-dark 
  = $aads-ocean-color-primary;​

원칙: 테마 ≠ 모드. 테마는 결국 on-light, on-dark 색상 응용 프로그램이 필요할 수 있습니다.

Marriott courtyard 컴포넌트에는 Marriott renaissance 컴포넌트에 필요한 만큼 밝은 모드와 어두운 모드가 필요할 수 있습니다.

결과적으로 테마는 두 개념을 모두 사용하는 시스템에서 색상 모드와 직교합니다.

Domain

아직 실제로 이를 관찰하지는 못했지만 시스템이 design system tiers에 대한 토큰 생태계를 지원하도록 확장될 것으로 예상합니다.

도메인(비즈니스 단위라고도 함) 수준은 그룹이 시스템 코어에서 오는 집합을 넘어

자체적으로 토큰 집합을 생성, 격리 및 배포할 수 있는 네임스페이스를 제공합니다.

예를 들어, marquees, 카드 타일 시스템 및 기타 판촉 컴포넌트를 구축하는 consumer 그룹은
새로운 토큰을 광범위하게 만들 수 있습니다.
이로 인해 다음과 같은 consumer 네임스페이스에 토큰이 생성될 수 있습니다.

$esds-consumer-color-marquee-text-primary
$esds-consumer-color-promo-clearance
$esds-consumer-font-family-marquee
$esds-consumer-space-tiles-inset-2-x

이러한 지역적 결정은 여러 테마(다양한 소비자 제품 라인) 또는 색상 모드(comsumer의 라이트 어두운 모드)에 적용해야 할 수 있습니다.

모든 조직이 다르기 때문에 일반적인 이름이 없습니다.

한 은행은 신용 카드, 은행 및 대출 도메인으로 나눌 수 있지만

다른 은행은 판매 및 서비스 그룹으로 나눌 수 있습니다.

인터넷 회사는 소비자 대 기업을 대조할 수 있습니다.

팀은 공개 응용 프로그램과 파트너 응용 프로그램 및 내부 응용 프로그램을 구분할 수 있습니다.

 

외부에서 보면 Shopify Retail과 같은 그룹이 핵심 Polaris 팀에서 얻은 것을 확장하는 "Retail" 토큰의 혜택을 받고

그 중 일부가 다른 팀에 유용하거나 심지어 코어 토큰으로 승격될 수 있다고 상상할 수 있습니다.

---

Lessons Learned

레벨에 관계없이 토큰 명명 토론에서 completeness, order 및 polyhierarchy 주제가 반복됩니다.

Completeness

단일 토큰이 모든 가능한 수준을 포한하지는 않습니다.

domain, theme, element와 같은 일부 수준은 거의 필요하지 않습니다.

다른 수준(양적 scale 대 질적 variant)은 상호 배타적인 경향이 있습니다.

가용한 모든 수준을 독단적으로 포함하지 마세요

중복 토큰 튜플을 피하세요

대신 목적과 의도를 충분히 설명하고 식별하는 데 필요한 수준만 포함하세요.

// Good
$esds-shape-tile-corner-radius
$esds-shape-tile-shadow-offset
// Bad, redundant
$esds-shape-tile-corner-radius-default-on-light
$esds-shape-tile-corner-radius-default-on-dark
$esds-shape-tile-shadow-offset-default-on-light
$esds-shape-tile-shadow-offset-default-on-dark

Order

내 프로젝트 및 기타 공개 컬렉션에 걸쳐 토큰을 검토할 때 입증된 것처럼 일반적인 토큰 수준 순서는 없습니다.
따라서 다음은 안정적으로 유지되는 것을 확인한 몇 가지 패턴입니다.

• Base 레벨은(category, property, concept) 가운데 위치하는 중추입니다.
  • Base 내부 레벨 순서는 계층적 엄격성 (color-interactive-background), 가독성(interactive-background-color), 카테고리와 프로퍼티 수준을 쌍으로 나란히 위치하느냐에 따라 다릅니다. (color-background-interactive).
• Namespaces (system, theme, domain)은 처음에 위치합니다.
• Modifiers (variant, state, scale, mode) 는 마지막에 위치하는 경향이 있습니다.
  • Modifier 내부 레벨의 순서는 일관적이지 않습니다. mode는 조건부로 마지막에 오는 경향이 있긴 합니다. (주로 on이 앞에 붙어있고, 색상 관련한 모드이면서, 그때도 몇몇 이유가 있을 때이긴 하지만...)
    • Order within modifiers isn’t consistent, although mode is often last (given its framing of “on” and use limited to only color and, even then, only when there’s a distinction).
• Object 레벨의 순서는 (component group, component, and nested element) 네임스페이스에 종속되며 선행할 수 있는 컨텍스트를 설정합니다.
  • 따라서 네임스페이스 뒤, Base, Modifiers 앞에 나옵니다.

여기에 제시한 레벨 순서는 유일한 옵션은 아닙니다.
시스템의 레벨 순서는 사용하는 레벨, 시스템에 필요한 것, 각 팀원의 취향에 따라 다릅니다.

Polyhierarchy

concept, category, variant 및 기타 수준이 겹치고 경쟁할 수 있습니다.

예를 들어 "errror red"는 concept variant color-feedback-error 및

object variant ui-controls-color-text-error (입력, 확인란, 선택 및 기타 양식 컨트롤용 패키지에 포함됨)일 수 있습니다.

이것은 우리로 하여금 다음을 결정하도록 합니다.

이 의도적인 결정을 어느 수준에서 저장합니까?
동일한 결정을 두 개의 다른 위치에 저장해도 됩니까?
두 가지 다른 선택의 목적이 거의 동일한데 토큰을 하나로 합쳐야 할까요?

color-feedback 및 ui-controls-color-text은 에러 외에도

각각 다른 변형((warning, success, info and label, value, and helper-text, respectively)이 있을 수 있습니다.

빨간색 값이 같더라도 두 세트의 완결성을 중시합니다.

따라서 나는 하나(객체 변형)를 다른 하나(개념 변형)에 앨리어싱하는 것을 고려할 것입니다.

$ui-controls-color-text-error = $color-feedback-error
                             (= $color-red-36)
                             (= #B90000)

이것은 또한 ui-controls-color-text-error red가
color-feedback-error의 다른 용도에 영향을 미치지 않으면서도 나중에 조정될 수 있는 가능성에 대비합니다.

---

가능한 많은 토큰 수준에 대해 생각하는 것은 벅차게 느껴질 수 있습니다(이렇게 긴 블로그 게시물도 마찬가지입니다).

다음에 토큰을 살펴볼 때 팀이 함께 공유하고 성장할 수 있는 어휘의 선택지가 많다는 것을 위안으로 삼으세요(...)