令牌桶生成令牌_设计令牌如何有效使用令牌

令牌桶生成令牌

“It used to be that designers made an object and walked away. Today the emphasis must shift to designing the entire lifecycle.”

“过去,设计师制造了一个物体然后走开了。 今天,重点必须转向设计整个生命周期。”

Paul Saffo — technology forecaster

Paul Saffo-技术预测员

什么是设计令牌? (What is Design Token?)

The central place where tiny pieces of UI information will be used across several platform during the conception of a digital product which are design tokens. The concept was created by Salesforce and name comes from Jina Anee. Design token(DT) allows product team to better collaborate and ensure brand consistency across any platform.

在作为设计令牌的数字产品概念期间,将在多个平台上使用少量UI信息的中心位置。 该概念由Salesforce创建,名称来自Jina Anee 。 设计令牌(DT)使产品团队可以更好地协作,并确保任何平台上的品牌一致性。

DT are also design decisions, represented as data, that ensure systematically unified and cohesive product experiences.

DT也是以数据表示的设计决策,可确保系统地统一和凝聚力的产品体验。

Design Tokens are visual atoms of the design system — specifically, they are named entities that store visual design attributes.

设计令牌是设计系统的视觉原子-具体地说,它们是存储视觉设计属性的命名实体。

We use then in place of hard-coded values in order to maintain a scalable and consistent visual system.

然后,我们将使用替代硬编码的值来维护可扩展和一致的视觉系统。

Jina @jina

吉娜@jina

设计令牌的类型? (Types of Design Tokens ?)

Following are the types of DT which are the building blocks and design decision that make up our design language.

以下是DT的类型,它们是构成我们的设计语言的构建块和设计决策。

全球通证: (Global Token:)

Example of global token in the image

They are the primitive values in our design system, they are represented by context-agnostic names. Typography, color pallet, animation values are all stored as a global token. These values can be directly used, and are inherited by all other type of token.

它们是我们设计系统中的原始值,由与上下文无关的名称表示。 印刷术,调色板,动画值都存储为全局标记。 这些值可以直接使用,并且可以由所有其他类型的令牌继承。

别名令牌: (Alias Token:)

Example of alias token in the image

These token relate to a specific context or abstraction. Aliases helps us to communicate the intended purpose of the token and are much effective when a value with a single intent will appear in multiple places.

这些标记与特定的上下文或抽象有关。 别名有助于我们传达令牌的预期目的,并且当具有单一意图的值出现在多个位置时,别名将非常有效。

特定于组件的令牌: (Component-specific token:)

Example of component specific token in the image

These type of token are an exhaustive representation of every value associated with a component. They often inherit from alias tokens, but are named in such a way that it allows engineering teams to be as specific as possible in applying token in development of the components.

这些类型的令牌是与组件关联的每个值的详尽表示。 它们通常从别名令牌继承,但是它们的命名方式使工程团队可以在将令牌应用于组件开发时尽可能地具体。

设计令牌如何工作? (How Design Token Works?)

We can place token into our Design System(DS) to the elements like Sizing, Font Families, Font Styles, Font Weights, Font Sizes, Line Heights, Border Styles / Colors / Radius, Horizontal Rule Colors, Background Colors, Gradients, Background Gradients, Box Shadows, Text Colors, Text Shadows, Time, Media queries, Z-index, Icons to name some few.

我们可以将令牌放置到我们的设计系统(DS)中,以找到诸如大小,字体系列,字体样式,字体粗细,字体大小,线条高度,边框样式/颜色/半径,水平规则颜色,背景颜色,渐变,背景渐变等元素,框阴影,文本颜色,文本阴影,时间,媒体查询,Z索引,图标等。

In a DS, we generally use especial entities called “design-tokens” to store the design decisions. These entities are in the shape of key and value pairs which are served in file format like JSON or YAML. These files are later used as inout files, processed and transformed to generate different output files. With these enabled to us we can maintain and scale our design across all the permutations.

在DS中,我们通常使用称为“设计令牌”的特殊实体来存储设计决策。 这些实体采用对的形式,以JSON或YAML等文件格式提供。 这些文件以后用作inout文件,经过处理和转换以生成不同的输出文件。 启用这些功能后,我们可以在所有排列范围内维护和扩展我们的设计。

Diagram showing how token can be used in designing all products and its ecosystem
Design token for dummies article 傻瓜设计令牌文章

This diagram reflects how an ideal workflow looks like implementing DT in action. A designer makes the design decision into his choice of tool. The tool has its plugin and API which provides us with the key/value pairs in the format of YAML/JSON format. These can also be generated with loads of tools available online like Theo, Gulp Task, Dragoman, Postcss-map plugin, Style dictionary, Tools. The generated files can be served to the developers with dynamic values from our design tools which can be built to make products into different devices everywhere.

该图反映了理想的工作流程看起来像在实践中实现DT的样子。 设计师将设计决策纳入他选择的工具中。 该工具具有其插件和API,可为我们提供YAML / JSON格式的键/值对。 这些也可以使用在线提供的大量工具生成,例如Theo ,Gulp Task, Dragoman ,Postcss-map插件, Style字典 Tools 可以使用我们设计工具中的动态值将生成的文件提供给开发人员,该工具可以用来将产品制作到各地的不同设备中。

This links between our design and developments tools would allow design teams to update core styles in their design tool and see the result automatically synchronized the whole design development ecosystem.

设计和开发工具之间的这种联系将使设计团队能够更新其设计工具中的核心样式,并看到结果自动同步整个设计开发生态系统。

Image showing Design token community group
design-token/community-group 设计令牌/社区组

实施设计令牌 (Implementing Design Token)

In this demo we will be covering just a single design element in our DS. The element would be Typography. We will be using Figma API and a plugin named Styled Dictionary which will help us to convert our token data which are base colors, typography, spaces, box shadow etc. in a single JSON file to design tokens.

在本演示中,我们将仅介绍DS中的单个设计元素。 元素将是“版式”。 我们将使用Figma API 和一个名为 样式字典 这将帮助我们在单个JSON文件中转换基本数据,版式,空格,框阴影等令牌数据来设计令牌。

We will first make an empty folder and install our plugin, and do our API call with the help of provided Figma developer API.

我们首先将创建一个空文件夹并安装插件,然后在提供的Figma开发人员API的帮助下进行API调用。

yarn init
yarn add style-dictionary

The above command will set an empty package.json file with our required package style-dictionary.

上面的命令将设置一个空的package.json文件,其中包含我们所需的package style-dictionary。

const axios = require("axios");async function getFigmaObjTree(figmaApiKey, figmaId) {
axios.get('https://api.figma.com/v1/files/' + figmaId, {
headers: {
"X-Figma-Token": figmaApiKey,
"Content-Type": "application/json"
}
})
.then(res => {
let result = res.data;console.log(result);
})
.catch(err => {
console.log('errors');
console.log(err);
});
}getFigmaObjTree('******figmaAPIKEY******', '****FigmaID****');

We here pulled data from the Figma API. But, unfortunately, Figma doesn’t provide values inside each style only type and name.

我们在这里从Figma API中提取了数据。 但是,不幸的是,Figma并没有在每个样式类型和名称中提供值。

So, we will get only typography from our artboard here. Lets take a look at screen recording below:

因此, 在这里我们只能从画板上得到字体。 让我们看一下下面的屏幕录像:

An interactive GIF showing design token in action

After we pulled our data from the API what we did was placed our base.json file created into our src. And we ran our next command in our terminal to get the token into sass files with command below:

从API提取数据后,我们将创建的base.json文件放入了src中。 然后,我们在终端中运行下一个命令,使用以下命令将令牌放入sass文件中:

yarn build

Then with the above command we have our build ready which have been converted to Sass file. The code we have is as below:

然后,使用上述命令,我们已经准备好将其转换为Sass文件的构建。 我们拥有的代码如下:

const StyleDictionary = require("style-dictionary").extend({
    source: ["src/**/*.json"],
    platforms: {
        sass: {
            transformGroup: "scss",
            buildPath: "stylesheets/",
            files: [{
                destination: "_typography.sass",
                format: "scss/variables",
                filter: {
                    type: "type"
                }
            }]
        }
    }
});


StyleDictionary.buildAllPlatforms();

结论 (Conclusion)

Design token process using Figma with its API
DT creation process
DT创建过程

DT are the central source of truth for our tiny UI information to store, design and relate information such as Colors, fonts, spaces, animation etch. By embedding DT into our design tools we can leverage maintenance, reliability, organization and scalability of our DS. With the DT in place we will have following benefits

DT是我们微小的UI信息存储,设计和关联诸如颜色,字体,空格,动画蚀刻之类的信息时,真理的主要来源。 通过将DT嵌入我们的设计工具中,我们可以利用DS的维护,可靠性,组织性和可扩展性。 有了DT,我们将获得以下好处

  • Use Token as variables.

    使用令牌作为变量。
  • Design decision applied to context.

    设计决策适用于上下文。
  • Reusable data in dynamic form across multiple platforms.

    跨平台以动态形式可重复使用的数据。
  • Design decision are propagated through a system.

    设计决策通过系统传播。
  • Managing and reading tokens from a central place.

    从中央位置管理和读取令牌。
  • Keep whole ecosystem in sync.

    使整个生态系统保持同步。

Using DT is here to solve many problems and obvious create new ones. The endless back and fourth between designers and developer to update our code time a design makes changes has been simplified. This affords designers the same flexibility that a developer has in a dev environment, allowing for a quick, easy exploration of DT updates and ability to roll out without any change in code or time consuming frequent deployments. I would highly encourage using DT in your current DS to make lives easier for ourselves.

在这里使用DT解决了许多问题,并且明显地创造了新的问题。 在设计人员和开发人员之间不断更新和更新代码的时间,简化了设计更改。 这为设计人员提供了与开发人员在开发环境中相同的灵活性,从而允许快速,轻松地浏览DT更新,并能够在不更改任何代码或不花费大量时间的频繁部署的情况下进行部署。 我强烈建议您在当前的DS中使用DT,让自己的生活更轻松。

Please find the link for working code in my GitHub repository link here.

请找到链接,在我的GitHub库环节的工作代码在这里

推荐参考 (Recommended references)

Note: This article is inspired from the workflow by Pavel Laptev generating design token with figma.

注意:本文的灵感来自于 Pavel Laptev 使用figma生成设计令牌 的工作流程

翻译自: https://uxdesign.cc/design-tokens-how-to-use-them-effectively-d495ff05cbbf

令牌桶生成令牌

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值