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.
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:
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.
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 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à:
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ư:
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.
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à:
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:
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.
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à:
Trong bài viết này, tôi sẽ gọi chúng là component 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.
Đ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.
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.
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.
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).
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.
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:
Tuy nhiên, mức tăng giữa sm và md có thể là 4px và giữa md và 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à:
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:
Intended element:
Intended part of a UI:
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
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.
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ư:
--yds-core-font-weight-regular
--yds-core-font-family-display
--yds-semantic-font-style-body-weight
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à:
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à:
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à:
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à:
Đặ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: