Đặt tên cho Design Token

Design Token là nguồn chân lý duy nhất cho các thiết kế ban đầu như màu sắc, tokens. Nếu bạn chưa quen với chủ đề này, bạn có thể muốn tìm hiểu những kiến thức cơ bản về Design Token trước.

Đặt tên Design Token theo các cấp độ(level)

Token thường được chia thành các cấp độ khác nhau, mỗi cấp độ có một trường hợp sử dụng cụ thể, tôi sẽ giải thích sau.

Có một số tên phổ biến cho khái niệm cấp độ này:

  • token levels
  • token types
  • token tiers
  • token layers
  • token groups

Nó không thực sự quan trọng bạn sử dụng cái nào. Tuy nhiên, bạn nên đảm bảo rằng bạn chọn một cái được hiểu rộng rãi trong tổ chức của bạn.
Tốt nhất là chọn một tên, ví dụ: token tiers và sử dụng nó một cách nhất quán. Bạn cũng nên giải thích nó trong phần đầu của bất kỳ tài liệu nào. Design tokens đủ phức tạp đối với những người mới làm quen với chủ đề này, tôi không muốn làm cho nó phức tạp hơn.

Tôi sẽ sử dụng thuật ngữ token tiers trong suốt bài viết này để đề cập đến các loại token khác nhau.

Illustration symbolizing the idea of design token tiers

Token tiers

Có ba cấp thường được sử dụng trong các design systems, Mỗi cấp mã thông báo thêm một khả năng cụ thể vào hệ thống thiết kế. Bạn có thể chọn nếu bạn muốn sử dụng tất cả các tầng hoặc chỉ một hoặc hai.

Token tiers level đầu tiên

Token trong level này lưu trữ các giá trị thô và nhờ đó mà xây dựng cơ sở của hệ thống thiết kế. Vì những cái tên phổ biến này là:

  • core tokens
  • base tokens
  • basic tokens
  • foundation tokens
  • meta tokens

Level này chịu trách nhiệm chính về giao diện của sản phẩm cuối cùng bằng cách xác định tất cả các giá trị có thể được sử dụng. Ý tưởng này dẫn đến những cái tên như:

  • global tokens
  • brand tokens
  • palette tokens
  • option tokens
  • choice tokens

Cuối cùng, tokens trong level này thường chỉ được sử dụng trong nội bộ. Đây là lý do tại sao chúng đôi khi được gọi là private token hoặc internal tokens.

Trong bài viết này, tôi sẽ gọi chúng là core tokens.

Token tiers level thứ 2

Tokens trong level này. Tên của chúng mô tả mục đích sử dụng của mã thông báo. Vì những cái tên phổ biến này là:

  • semantic tokens
  • alias tokens
  • applied tokens
  • purpose tokens

Các token trong level này được sử dụng nhiều nhất trong toàn bộ ứng dụng. Chúng đại diện cho các lựa chọn mà nhóm hệ thống thiết kế đã thực hiện liên quan đến thời điểm sử dụng token nào. Đây là lý do tại sao các tên sau đây lại phổ biến:

  • common tokens
  • application tokens
  • decision tokens

Trái ngược với mã token level 1, những token đó được cho là được sử dụng bởi tất cả mọi người và do đó đôi khi được đặt tên là public tokens.

Tôi bài viết này tôi sẽ gọi chúng như là semantic tokens.

Token tiers level thứ 3

Tokens trong level này tham chiếu đến semantic tokens và gắn chúng với giá trị component cụ thể. Vì những cái tên phổ biến này là:

  • component tokens
  • overwrites
  • overwrite tokens
  • scoped tokens

Trong bài viết này, tôi sẽ gọi chúng là component tokens.

Illustration symbolising naming design tokens with different pieces like namespace, type, category and state

Các yếu tố dành cho tên của tokens

Tên token được tạo thành từ các yếu tố khác nhau. Tùy thuộc vào từng level mà các phần tử khác nhau được kết hợp để tạo thành một tên token.

Namespacing

Điều này đề cập đến một tiền tố được thêm vào tất cả các token trong hệ thống, như --md (viết tắt của material design) trong thiết kế material design hoặc spectrum- trong hệ thống adobes. namespace giúp tránh các vấn đề khi design tokens của bạn sử dụng cùng tên với tokens từ các hệ thống khác được sử dụng kết hợp. Điều này xảy ra chẳng hạn khi tích hợp vào một hệ thống sử dụng một cái gì đó như bootstrap.

Thông thường, namespace sử dụng tên của hệ thống thiết kế hoặc tổ chức ở dạng đầy đủ hoặc ở dạng viết tắt.

--spectrum-color-primary
--yds-typography-size-sm

Tier

Nếu bạn chọn cung cấp nhiều tiers cho người dùng của mình, bạn có thể muốn thêm tier cụ thể vào tên mã thông báo. Điều này làm cho người dùng thấy rõ họ đang làm việc với loại token nào.

--yds-core-color-blue-600: #0070F4;
--yds-semantic-color-primary: var(--yds-core-color-blue-600);
--yds-component-primary-button-bg: var(--yds-semantic-color-primary);

Nhập tiền tố hoặc hậu tố

Tiền tố hoặc hậu tố chủ yếu được thực hiện với loại token, ví dụ: color hoặc radius. Điều này chủ yếu quan trọng đối với việc sử dụng code nơi các developers có thể nhận được một danh sách dài các tokens được đề xuất.

Cá nhân tôi thích đặt loại tiền tố như một loại phân loại cấp cao nhất, ví dụ: --color-background—subtle. Điều này cho phép bạn nhập --color và chỉ nhận được đề xuất cho các color token trong IDE của bạn.

--yds-core-color-blue-600
--yds-semantic-radius-default
--yds-semantic-headline-1-size
--yds-semantic-headline-1-weight

Scales

Scales rất tuyệt vời khi đại diện cho nhiều yếu tố trong một họ. Thông thường, tôi sử dụng số(numeric) hoặc thứ tự(ordinal).

Numeric Scales

Numberic Scales có thể là 1-5, 0-1000 hoặc 0,0.1,0.2, .... Nói chung, người ta mong đợi rằng trong thang số, sự khác biệt giữa bước này với bước tiếp theo có kích thước giống hệt nhau hoặc tuân theo một mức nghiêm ngặt thuật toán, ví dụ: nó tăng gấp đôi kích thước giữa mỗi bước.

Numberic Scales thường được sử dụng cho các họ màu như Blue-100 đến Blue-1000 nhưng cũng có thể hoạt động cho những thứ như z-index hoặc shadows.

Tuy nhiên, bạn không bao giờ nên sử dụng scales trực tiếp đại diện cho giá trị, chẳng hạn như size-20 cho token size có giá trị 20px. Điều này vô hiệu hóa tính trừu tượng và các lợi ích khác mà bạn nhận được design tokens.

--yds-core-blue-100
--yds-core-blue-200
--yds-core-blue-300--yds-core-spacing-unit-1x
--yds-core-spacing-unit-2x
--yds-core-spacing-unit-3x

Ordinal scales

Các ordinal scales thường có hướng, v.d. các mặt hàng trong scale ngày càng lớn hơn, nhưng chúng không nói lên điều gì về sự khác biệt giữa các mặt hàng riêng lẻ.

Một ví dụ điển hình là các cỡ áo thun thường được sử dụng: sm, md và lg. Bạn có thể lập luận về điều này:

  • md is larger than sm
  • lg is larger than md
  • this means lg must be larger than sm

Tuy nhiên, mức tăng giữa sm md có thể là 4px và giữa md lg có thể là 8px.

ordinal scales thường đặc biệt hữu ích đối với những small scales có khoảng năm items. Các loại thang thứ tự phổ biến là:

  • Importance: Primary, Secondary, Tertiary, ...
  • Intensity: none, low, normal, medium, high, max
  • Strength: Weak, Moderate, Strong, Extreme
  • Level: Level-1, Level-2, ...
  • Speed: instant, immediate, quick or fast, moderate, slow, deliberate
--yds-core-radius-sm
--yds-core-radius-md--yds-semantic-color-on-dark-low-emphasize
--yds-semantic-color-on-dark-normal-emphasize--yds-core-shadow-weak
--yds-core-shadow-moderate--yds-core-z-index-lvl-1
--yds-core-z-index-lvl-2--yds-semantic-animation-speed-instant
--yds-semantic-animation-speed-fast

Categories

Token thường có thể được phân loại tùy thuộc vào vị trí hoặc thời điểm chúng nên được sử dụng. Điều này đặc biệt nổi bật trong colors với các danh mục như:

Situation:

  • Informational
  • Tip
  • Warning
  • Error
  • Success
  • New
  • Updated

Intended element:

  • text color
  • on color
  • icon color
  • fill color
  • border color
  • Shadow color

Intended part of a UI:

  • Background color
  • Foreground color
  • Canvas color
  • Surface color
  • Interaction color
  • UI Color
  • Link color
--yds-semantic-color-warning
--yds-semantic-color-success
--yds-semantic-text-color-default
--yds-semantic-border-color-hover
--yds-semantic-color-link-default
--yds-semantic-color-link-hover
--yds-semantic-color-link-visited
--yds-semantic-color-link-active

Shades, tints & more

Có một số thuật ngữ trong visual design có ý nghĩa xác định và có thể được sử dụng để biểu thị một token cụ thể như blue-tone

  • tone thêm xám hoặc ít sôi động hơn
  • shade thêm vào màu đen hoặc tối hơn
  • tint thêm màu trắng hoặc màu sáng hơn
  • subtle a less intense or vibrant
  • intense or vibrant dữ dội hơn và đầy màu sắc
  • bold mạnh mẽ, dữ dội hơn, to hơn
  • prominent or pronounced đáng chú ý hơn
--yds-semantic-color-background-subtle
--yds-semantic-color-text-prominent
--yds-core-color-primary-shade
--yds-core-color-primary-tint

States

States đặc biệt hữu ích cho các yếu tố tương tác. Tuy nhiên, có thể có các khía cạnh trạng thái khác trong giao diện người dùng của bạn cần xem xét.

  • default, standard or resting
  • hovered
  • pressed, active
  • selected, highlighted
  • visited
  • disabled or inactive
  • enabled
  • focused or in-focus
  • custom states like downloaded, completed, archived
--yds-semantic-shadow-floating-default
--yds-semantic-shadow-floating-hovered
--yds-semantic-color-ui-disabled
--yds-semantic-color-primary-pressed

Names

Trong một số trường hợp, mô tả names có thể là tất cả những gì bạn cần.

Ví dụ đối với đường cong nới lỏng, có những tên thông dụng như: easyIn, easyOut hoặc easyInOut. Những tên đó cung cấp đủ trừu tượng để cho phép bạn thay đổi các giá trị. Có những thứ tương tự như:

  • font weight regular, medium, bold
  • font families monospace, serif, sans-serif, display
  • font styles like caption, body, headline

--yds-core-font-weight-regular
--yds-core-font-family-display
--yds-semantic-font-style-body-weight

Modes, Platforms, etc.

Tùy thuộc vào nhu cầu của bạn, có thể có các nhóm khác để xem xét. Tuy nhiên, hãy đảm bảo rằng việc thêm một cơ chế nhóm có ý nghĩa và hợp lý bằng đủ các tokens khác nhau cho mỗi nhóm. Các ví dụ phổ biến là:

Modes like:

  • light, dark, high-contrast
  • day and night

Platforms like:

  • iOS
  • Android
  • Web
  • Mac
  • Windows

Device categories like:

  • Mobile
  • Desktop
  • Big screen
  • Watches
Illustration symbolising patterns that can be use to create names that fit together in the system

Các mẫu đặt tên phổ biến

Core tokens

Core tokens lưu trữ các giá trị thô để làm cho chúng có thể sử dụng lại trong semantic tokens của bạn. Tên của chúng phải phản ánh các giá trị mà chúng lưu trữ và đại diện.

Nhưng chúng vẫn nên cung cấp một chút trừu tượng để các giá trị có thể được điều chỉnh. Điều này có nghĩa là bạn không nên đặt giá trị trực tiếp trong tên, ví dụ: không bao giờ đặt tên cho chúng là size-4px, mặc dù vậy, color-red thì được. Nó cho phép bạn điều chỉnh giá trị hex miễn là nó vẫn có màu đỏ.

Các yếu tố phổ biến của tên core token là:

  • namespacing nếu bạn sử dụng nó trong hệ thống của mình, hãy sử dụng nó cho các core tokens của bạn.
  • token types các loại mã thông báo tiền tố hoặc hậu tố mã thông báo của bạn với type
  • numeric scales thang số rất hữu ích đặc biệt cho các họ màu hoặc đơn vị định cỡ
  • ordinal scales thang đo thứ tự như t-shirt hoặc level hoạt động rất tốt cho những thứ như radius, elevation, shadow, v.v.
  • categories danh mục rất quan trọng đối với token cụm, đặc biệt là màu sắc.
  • names tên có thể được sử dụng cho những thứ như font weights, ví dụ: 400 hoặc regular. Các giá trị khác có thể được đặt tên tương tự, ví dụ: font-family với monospace hoặc serif.

Semantic tokens

Semantic tokens tham chiếu đến core tokens và đề xuất mục đích sử dụng cho nó. Do đó, tên của chúng không bao giờ được tham chiếu đến giá trị. Chúng có mức độ trừu tượng cao. Tên điển hình có thể là color-background hoặc shadow-floating-hovered.

Một số semantic tokens rất cụ thể, như color-link. Những thứ khác rộng hơn như color-background-surface. Phần quan trọng là người dùng có thể hiểu mã thông báo nên và không nên sử dụng cho mục đích gì.

Các yếu tố phổ biến của tên semantic tokens là:

  • namespacing nếu bạn sử dụng nó trong hệ thống của mình, hãy sử dụng nó cho các semantic tokens của bạn.
  • token types các loại mã thông báo tiền tố hoặc hậu tố mã thông báo của bạn với type
  • numeric scales cố gắng tránh dùng cho semantic tokens. Chúng không truyền đạt một mục đích sử dụng. Tuy nhiên, đôi khi bạn có tokens mà không có mục đích sử dụng cụ thể. Ví dụ color shades cho hình minh họa.
  • ordinal scales tránh dùng cho semantic tokens. Tên thường chính xác hơn, ví dụ: radius-default thay vì radius-md. Đôi khi điều này không hoạt động, ví dụ: đối với z-index, trong trường hợp đó, một thang đo như level là tốt.
  • names cực kỳ quan trọng đối với semantic tokens. Ví dụ: body, headline title cho font styles.
  • shades, tints & hơn thế nữa rất hữu ích để tạo các biến thể của tokens.
  • states giao tiếp khi nào sử dụng một token cụ thể và hoàn hảo cho các semantic token.
  • platform, modes, etc. rất hữu ích tùy thuộc vào hệ thống của bạn, ví dụ: cho các chế Light và Dark.

Component tokens

Component tokens tham chiếu đến semantic tokens để sử dụng chúng trong một thành phần cụ thể. Điều này cho phép người dùng ghi đè các thuộc tính riêng lẻ cho tất cả các thành phần của một loại.

Ví dụ: một button có thể có component tokens là button-radius. Theo mặc định, button-radius tham chiếu đến giá trị của semantic tokens, ví dụ: radius-default. Người dùng có thể thay đổi button-radius thành bất kỳ thứ gì, ví dụ: 10px. Điều này thay đổi tất cả các button mà không ảnh hưởng đến bất kỳ button nào khác sử dụng radius-default.

Các yếu tố phổ biến của tên component tokens là:

  • namespacing nếu bạn sử dụng chúng trong hệ thống của mình, hãy sử dụng chúng cho các component tokens của bạn.
  • token types các loại mã thông báo tiền tố hoặc hậu tố cho component tokens.
  • states giao tiếp khi mã thông báo thành phần được sử dụng, chẳng hạn như on hover.
  • names luôn được sử dụng cho các component tokens. Cụ thể là tên của component. Điều này cho phép người dùng biết token ảnh hưởng đến component nào.
  • platforms cũng có thể được sử dụng. Ví dụ: khi token sử dụng các kích thước phông chữ khác nhau cho thiết bị di động và máy tính để bàn.

khái lược

Đặt tên design tokens phức tạp và phải được thực hiện cẩn thận. Bạn không thể điều chỉnh tên sau khi hệ thống được xuất bản mà không đưa ra thay đổi đột ngột (điều mà bạn nên cố gắng tránh mọi lúc).

Khi đặt tên cho design tokens, hãy ghi nhớ mục đích của token:

  • core tokens đặt tên cho một giá trị thô để kích hoạt chúng và cải thiện khả năng bảo trì.
  • semantic tokens xác định các trường hợp cụ thể trong đó giá trị được tham chiếu nên được sử dụng.
  • component tokens cho phép ghi đè các giá trị cụ thể cho tất cả các component của loại.