首发：https://www.yuque.com/jingwhale/blog/do37mc
最近在整理设计规范的过程中，尝试使用了 Airbnb 公司发布的 react-sketchapp 工具。从react-sketchapp公布之初，它就迅速被设计师和前端工程师们所关注，作为非主流边缘设计师，我被它所吸引，得知后便进行了了解并进行了体验。
这种跨境工具提供了一种新颖的想法，并在一些特定情况下有其应用场景。
[En]
This cross-border tool provides a novel idea and has its application scenarios in some specific situations.
一、React – SketchApp 是啥？
React – SketchApp 是一个开源库，为设计系统量身定制。它通过将 React 元素渲染到 Sketch 来连接设计和开发之间的鸿沟。
这个神奇的开源库给设计师们提供了一个全新的设计工作流程：在时下最流行的 React 前端框架下用代码进行设计，并实时渲染到 Sketch 中审阅设计。细思恐极，在设计圈大红大紫的 Sketch 虽说占了开源库的一半名字，但其实担当的只是一个浏览器的角色。真正留下的设计文档则成了代码。
二、为啥？？为啥？？
你一定在想，为什么好好的，突然让所有设计师用起代码做设计了？为啥又要用前段框架了？这成本对我们来说有多高？听听 Airbnb 怎么说。
一个设计系统可以让设计师复用样式、组件、图形，这可以给设计师更多的时间去进行更高层次的思考。同时，一个好的设计系统也让工程师自信地添加新功能，而不用去看密密麻麻的标注线，痛苦地和设计师来回调整像素。而同样的，一个完善的设计系统一般都是非常庞大而复杂的，想有序地构建和发展这个系统，本身就有着巨大的工作量。在我们团队中，瓶颈就在 Sketch Template 上。
就拿 Airbnb 的设计系统 DLS 举例，它从字体、颜色、间隙的规范开始，逐渐发展成了跨平台、跨屏幕尺寸、跨语言的丰富设计库。当然作为一个设计系统，永远也不会有完成的时候，我们持续的向其中增加内容，更改和调整已有的组件，让每一个人都可以使用它。
但是在这个过程中，每一点对这个系统的增加和更改，都会产生很大的工作量。文档需要更新，每个 App 都需要调整，Sketch Template 又要重新绘制。而所有这些工作还必须协同进行。
基于图形的设计工具在版本控制上有着先天的劣势，所有的可以拖来拖去的元素经常让我们对设计系统的状态产生不确定感。「移动端 Title 字体是多大来着？」「现在最新的方案还是这样子么？」「这个组件在不同屏幕上怎么显示？」诸如此类的问题在办公室中几乎是时时出现 。相反，代码相对来说就更容易管理，同时我们已经有了对代码版本管理的积累和基础。而维护 Sketch Template 还只能依靠劳动密集的人工管理。因此我们希望通过代码来优化整个工作流程。
Sketch 文件本身倒是可以直接用代码组织，但是提供的 API 却经常变化。相反 React 框架给可复用文档提供了完美的封装形式，同时有前端基础的设计师可能已经比较熟悉了。
三、核心优势
剔除 Airbnb，在仔细看了相关文档和项目样例后，总结出了一下这个开源工具在构建设计系统时的核心优势：
稳定的文档：使用成熟的前端框架作为设计系统的基础，可以保证整个设计系统的长期可用性。
[En]
Stable documentation: using a mature front-end framework as the basis of the design system can ensure the long-term availability of the whole design system.
数据的清晰度和准确性：以代码作为描述设计的形式，杜绝基于图片描述设计时容易产生的数据不稳定。
[En]
The clarity and accuracy of the data: take the code as the form of describing the design, and put an end to the data instability that is easy to be generated when describing the design based on the picture.
可进行响应式设计：比起 Sketch 略显简陋的 Resizing，React 提供了功能完备的布局系统，可以在设计端进行准确完整的响应式设计。
版本管理：避开了基于图片设计的版本管理难点，git 等工具组织设计系统，让系统更实时、可考。
跨平台开发：因为和 ReactNative 采用同一套布局系统，配合 ReactNative 可以很好地进行跨平台工作。
引入真实数据 & API：可以和任何前端开发一样引入真实的数据和 API 实现例如、等有趣的功能。
当许多团队构建大规模设计系统时，这些优势确实可以击中痛点。
[En]
These advantages can really hit the pain point when many teams build large-scale design systems.
相比之下 React – SketchApp 在这些问题下，跳出了原有的思考方式，用超前全新的方案解决目前方案的痛点。
四、使用React-Sketchapp制作styleguide模板
说了这么多概念上的东西，大家一定很期待从实用角度看看它到底是怎么工作的，接下来就让我们对 React – SketchApp 做一个初步的体验。对它同样感兴趣的也可以根据下面步骤一起尝试。
使用React-Sketchapp制作调色板和文字模板，效果如下：
1）调色板
2）字体
2、调色板与文字原理
1）调色板
调色板是一组规律的16进制码。可以将色彩体系解读成两个层面：系统级色彩体系和产品级色彩体系。系统级色彩体系主要定义了中台设计中的基础色板、中性色板和数据可视化色板。产品级色彩体系则是在具体设计过程中，基于系统色彩进一步定义符合产品调性以及功能诉求的颜色。这里选用的是Ant Design的色彩系统。
Ant Design 的基础色板共计 120 个颜色，包含 12 个主色以及衍生色。这些颜色基本可以满足中后台设计中对于颜色的需求。
色板生成算法 主要代码：源代码：ant-design-colors
function main(color, index) {
var isLight = index ;
var hsv = tinycolor(color).toHsv();
var i = isLight ? lightColorCount + 1 - index : index - lightColorCount - 1;
// i 为index与6的相对距离
console.log(hsv)
return tinycolor({
h: getHue(hsv, i, isLight),// getHue 获取色相渐变
s: getSaturation(hsv, i, isLight),// getSaturation 获取饱和度渐变
v: getValue(hsv, i, isLight),// getValue 获取明度渐变
}).toHexString();
};
根据颜色值、色号与主色色号(6)差的绝对值、减淡/加深这三个参数获取渐变后的色值，其中 HSV 的三个值分别经过了渐变调整：
“Hue”(色相)的渐变核心代码如上，首先判断冷暖色调；
“Saturation”饱和度的渐变核心代码如上，对于减淡与加深的饱和度进行了不同的处理，其中减淡递减的值更大，说明减淡的过程中饱和度迅速下降，而由于主色的饱和度一般较高，因此加深的时候饱和度不必增张过快，尤其是最深的颜色，进行了特殊处理。
“Value”明度的渐变核心代码如上，对于减淡与加深的明度进行了不同的处理，其中加深递减的值更大，说明加深的过程中明度迅速下降，这是由于主色的明度一般较高，因此减淡的时候明度不宜增长过多。
综合来看 3.x 色板生成算法的实现可以看到，主色的选取很重要，一般主色选取饱和度较高、明度较高的颜色才能更好地匹配这个色板生成算法。
2）字体
字体是体系化界面设计中最基本的构成之一。我们的用户通过文本来理解内容和完成工作，科学的字体系统将大大提升用户的阅读体验及工作效率。Ant Design 字体方案，是基于『动态秩序』的设计原则，结合了自然对数以及音律的规则得出。 在中后台视觉体系中定义字体系统，建议从下面五个方面出发：
字体家族
主字体
字阶与行高
字重
字体颜色
3、制作原理
调用的API，在编辑器中通过React代码绘制SketchUI规范。
具体的，通过调用Ant Design 的色板生成算法ant-design-colors产生出基础色板和中性色板的颜色值，然后使用React-Sketchapp基础组件编写代码渲染到Sketch的当前页面中。字体模板亦是如此。
具体步骤如下：
1）、确保，本地安装Node，git。
2）、本地Clone code_sketch_resource 工程项目
code_sketch_resource项目依据React-Sketchapp官方项目的styleguide例子基本框架。
git clone https://github.com/jingwhale/code_sketch_resource
npm install
npm run render
4、关键代码分析
1）获取调色板色值：
首先，依赖ant-design-colors组件库
$ npm install @ant-design/colors --save
其次，获取调色板色值
import { generate, presetPalettes } from '@ant-design/colors';
// Generate color palettes by a given color
const colors = generate('#1890ff');
console.log(colors); // ['#E6F7FF', '#BAE7FF', '#91D5FF', ''#69C0FF', '#40A9FF', '#1890FF', '#096DD9', '#0050B3', '#003A8C', '#002766']
console.log(presetPalettes);
/*
{
red: [...],
volcano: [...],
orange: [...],
gold: [...],
yellow: [...],
lime: [...],
green: [...],
cyan: [...],
blue: [...],
geekblue: [...],
purple: [...],
magenta: [...],
}
*/
2）调色色板UI开发
调色色板UI：父组件Palette_new.js和子组件Swatch_new.js。代码如下：
父组件Palette_new.js
// @flow import * as React from 'react'; import { View,Text} from 'react-sketchapp'; import SwatchN from './Swatch_new'; const SWATCH_WIDTH = 285; type P = { colors: any, }; const PaletteN = ({ name,colors}: P) => ( <View name={name} style={{ width: SWATCH_WIDTH, flexWrap: 'wrap', marginRight: 33, marginBottom: 64 }} >{name} {Object.keys(colors).map(index => ())} ); export default PaletteN;
子组件Swatch_new.js
// @flow import * as React from 'react'; import { View,Text} from 'react-sketchapp'; import type { Color } from '../processColor'; const SWATCH_WIDTH = 285; const SWATCH_HEIGHT = 56; type P = { name: string, color: Color, }; const SwatchN = ({ color ,index,name}: P) => ( <View name={name+"-"+index} style={{ width: SWATCH_WIDTH, height: SWATCH_HEIGHT, backgroundColor: color, flexDirection: 'row', }} >{name+"-"+index} {color} ); export default SwatchN;
3）react-sketchapp主要Components：
更多具体代码请参考code-sketch-resource项目库。
五、总结
1、系统设计资源不仅需要，而且非常需要使用react-sketchapp创建。用代码组织管理系统设计资源Sketch 文件，是最好的方式。系统设计资源包括设计规范，它是有规律且相对固定的思维产物，这非常适合用代码管理。
2、React-sketchapp 只是提供了一个思路，打通程序与设计后，诸如此类的工具还有非常大的空间等待挖掘。
例如：在交互设计中使用代码绘制页面流程图，或使用代码进行自动配色系统。
[En]
For example: use code to draw the page flow chart in interactive design, or use code for automatic color matching system.
3、人工智能交互设计？
既然组件是固定的，设计原则也是固定的，为什么不让代码交互并产生交互草稿呢？您只需要输入关键字，依次进行页面布局、功能设计，偶尔还可以手动调整本地组件的位置和大小。当然，这个想法可以节省50%的中后台设计系统设计和制作原型的时间；前台设计需要更多的用户体验设计，所以可以先设计初稿，然后再加强设计，优化用户体验。
[En]
Since the components are fixed and the design principles are fixed, why not let the code interact and produce interactive drafts? You only need to enter keywords, in turn for page layout, functional design, and occasionally manually adjust the location and size of local components. Of course, this idea can save 50% of the time of designing and making prototypes in the middle and background design system; foreground design requires more user experience design, so you can design the first draft first, and then strengthen the design to optimize the user experience.
当然，我已经在设计和实现这个系统了，不是很令人兴奋吗？让我们拭目以待！
[En]
Of course, I am already designing and implementing this system, isn’t it very exciting! Let’s wait and see!
附：
https://github.com/jingwhale/code-sketch-resource
https://github.com/airbnb/react-sketchapp
https://github.com/ant-design/ant-design-colors
Original: https://www.cnblogs.com/jingwhale/p/10502204.html
Author: jingwhale
Title: 使用 React-Sketchapp 管理你的设计资产
相关阅读
Title: 文献知识图谱可视化_科学知识图谱论文很好发表吗？
科学知识图谱论文很好发表吗？
文献计量与知识图谱应该是先学会，再应用。
我曾经打过一个比方：似懂非懂做研究，就像醉酒的李白，什么都敢写(实际上，这是一些知识图谱论文的问题)。
[En]
I once used an analogy: if you don’t know how to do research, just like the drunken Li Bai, he dares to write anything (in fact, this is the problem of some knowledge graph papers).
现在很多发表的bibliometrics analysis、bibliometrics mapping和Scientometrics mapping的论文都有问题。
暂且不说基本概念和原理不懂，直接用软件(比如CiteSpace、VOSviewer或者Histcite)分析的论文，好多论文都出现了软件使用错误和不当的情况。
这个是需要思考的，不能什么方法”热”、什么方法”新”就直接套数据去用。
(当然所谓的”先发优势”害死人，我曾经就遇到过很多人着急发表，因为晚一些在审稿人和编辑看来就不”新”了。期刊成了求新不求对的媒体了吗？应该不是！)
期刊编辑部也应该在送审的时候，邀请跨学科的专家来审稿，做好学术出版的守门人。上次的《冰川冻土》编辑责任和审稿人责任应该也不小。
[En]
When submitting for review, the journal editorial department should also invite interdisciplinary experts to review the manuscripts and be the gatekeepers of academic publishing. Last time, the editorial responsibility of Glacier and Frozen soil and the responsibility of manuscripts reviewers should not be small.
最后，文献计量与知识图谱不是照着操作指南，简单出几张图的照猫画虎式的解读。无论中文还是英文的这类论文数量已经达到了泛滥的程度，作为知识图谱的实践者需要对自己的结果负责。
[En]
Finally, bibliometrics and knowledge graph are not simple interpretation of several pictures according to the operation guide. The number of such papers in both Chinese and English has reached a flood, as practitioners of the knowledge graph need to be responsible for their own results.
我国学者使用该方法发表的SCI/SSCI论文：
简单检索了一下，共得到了1057篇论文。
近十年来论文的产出情况，近两年来论文的产出有点疯狂。2019年平均一天就有一篇该方面论文发表。
中文论文更加疯狂。
主题为CiteSpace的论文一共就达到了2955篇。在2019涉及CiteSpace的论文就达到了1097篇。也就是说大约每天有3篇主题为CiteSpace论文发表！
目前出现的问题：
- 数据库的检索错误。现在的科技论文索引数据库不是百度，很多人就当百度来用了。导致在检索中使用的检索策略严重错误。
- 严重缺乏文献计量与知识图谱的基础理论。表现在对文献计量的相关理论方法的认识就是参考几篇论文，并不真正了解。在后面结果的分析中，与理论毫无关系。
- “低劣的图谱+天马行空””的解读造就了一批中英文论文发表。从图谱的质量来看，对软件的认识程度仅仅停留在 照着指南操作的层面。在论文中出现的图谱混乱不堪，根本不知道可视化了啥，核心的节点和关系是啥，核心的聚类是啥？ 为何这类论文发表了很多，而且每年有上百篇的SCI论文？其中的一部分论文与作者的天马行空的解读是分不开的。软件得到的结果应该是基于一定的理论和技术基础的， 很多作者不以为然，而且抛开软件本身的理论基础不管，对出现图谱按照自己的理解去解读。
- 为何会发表呢？ (1)期刊的编辑责任不能推脱。很多这类论文送到了”专业”领域人员的手里。仅仅是和论文专业相关的论文，而没有送到进行文献计量和知识图谱人员的手里。导致一些低劣论文发表。 (2)审稿人接受审稿后，只能审自己懂的部分。比如知识图谱可视化的质量不会判断，只能看作者的文字是啥就是啥。毕竟大多数审稿认为作者文字的描述是客观的，是基于图谱结果的。 最后，通过指南的学习，一般在一个月只能就能分析出图谱。但是论文的写作不是很快能完成的工作。 低劣的文献计量论文是很好发的，即使是SCI(事实也证明了这一点)。
- 质量较高的文献计量与知识图谱论文的发表是需要时间的沉淀。不仅要对自己的所学的专业有深刻的认识，而且要对文献计量理论、方法以及工具要比较熟悉。这个跨学科研究不是想象中的那么容易。
速度与数量有了，我们想要质量！也希望知识图谱能够在健康发展中逐渐深入，并在各个领域开出健康的学术果实。
下面一些文献计量学论文出现了Correction和Erratum….
扩展阅读：
-
过去30天冠状病毒事件的关注趋势
-
Biorxiv和CNKI上冠状病毒论文
-
Scopus中冠状病毒研究的概况
-
Web of Science冠状病毒科技论文的在线可视化
-
CiteSpace对冠状病毒的文献分析
-
我国学者冠状病毒的科学知识图谱分析
-
冠状病毒科学知识图谱分析(上)
-
冠状病毒的科学知识图谱分析(Europe PMC)
-
PubMed冠状病毒研究的在线可视化
Original: https://blog.csdn.net/weixin_30755903/article/details/112655692
Author: 心望田
Title: 文献知识图谱可视化_科学知识图谱论文很好发表吗？
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/127483/
转载文章受原作者版权保护。转载请注明原作者出处！
