说服您的团队切换到协作在线设计平台 Figma 并不是一件容易的事情，开放设计代表了从设计孤岛到协作的文化转变。 Show 因此，流行的社交媒体应用管理程序 Buffer 的高级设计师 James Morris 在这里提供了一些过度方案。James采取了循序渐进的方法，将 Buffer 迁移到 Figma，以确保他在整个公司范围内都支持该更改。之所以要更新设计工具是因为 Buffer 的团队完全处于远程状态，因此他们需要一种方便快捷的设计工具。 对于James而言，介绍 Figma 不仅仅是一种新的设计工具。这是关于改变设计在工程驱动型组织中的角色。 “默认情况下，您如何帮助设计团队在桌面上占有一席之地？”他说。 “您如何使设计成为产品开发的一部分？” Buffer 对工作透明度的承诺Buffer 被 Figma 吸引住并不奇怪，因为它的文化核心宗旨是透明度 — 在公司将所有员工的薪水在线发布。詹姆斯说：即便如此，设计团队仍在努力与其他部门合作，因为他们使用的工具把他们困在了另一个世界中。
其他团队的成员很难找到他们想要的设计，因为文件通常被深埋在 Dropbox 子文件夹中。即便找到，如果不购买支持它们的软件或升级到最新版本，就无法看到设计。即使获得了正确的许可，开发人员和产品经理也常常害怕打开设计文件，以防他们不小心将其保存在某人的电脑上。 “意识到选择的工具确实对沟通产生了巨大影响。詹姆斯在设计团队中犹豫不决，仿佛它拥有其他人没有的特殊文件一样。”James 说“ Figma 促进了相反的感觉，它就在我们身边。” Figma中的缓冲区文件结构图：  因为 Figma 在云端运行，所以本地问题消失了。任何人都可以通过其URL访问设计文件，并且团队可以拥有无限制的仅查看帐户（免费！）。查看者可以在设计稿中留下评论，也可从设计文件中提取前端开发标注以对其进行编码。 James 说：“我们有使用 Linux 的工程师，而那里的许多设计软件都不支持该平台。” “一个人准备购买Mac只是为了打开设计文件！此时，Figma的好处显而易见。” 第1步 – 开放式探索Figma 对 James 而言显而易见，但这并不意味着该组织的其他成员也很清楚。他知道获得支持的最好方法是展示而不是说出来。在公司范围内的电子邮件中，他介绍了“探索期”，要求团队尝试使用不同的设计和协作工具，来查看满足其需求的工具。
在此期间，James 收到了有关 Buffer 工作流程和解决方案的反馈。说Figma解决这些问题的方法，包括在他发出的原始文件就已备了详细说明。James 相信一旦人们试用了 Figma，协作功能便会证明自己。 第2步 – 展示，不直接告诉与产品经理的白板会议在此探索期间，James 使用创新方法来帮助团队和个人探索 Figma。由于 Buffer 是远程办工，所以第一步就是虚拟白板。James 居住在英国，因此他说服了 Buffer 的加拿大PM之一与他进行头脑风暴。 James 说：“我们俩都提出了不同的想法，比如人们将如何在 Google Doc 中进行协作，除了形状而不是文字。” “ Figma 展示得很快，非常容易就完成了。” 因为他们使用 Figma 进行实时协作，所以 James 不必坐在那里等待 PM 的正式规格表。 说服工程师为了说服 Buffer 的开发人员加入，James 将他们留在了自己的电脑前。 “我说，‘伙计们 请检查一下这是URL，请查看您是否可以获得所需的信息，” James 回忆道： “他们仅仅通过打开它就感到非常兴奋。” 开发人员可以免费使用 Figma 的查看设计中的 CSS、iOS（Swift）和Android（XML）数据。他们所需要的只是打开文件的链接，与 Photoshop 时代相比，时间几乎节省了90%
“ Figma 的卖点之一就是真实。我可以为设计创建一个URL，并且可以轻松共享该URL，而且该URL将保持不变。” James 说。 “而不是将设计再次导出为图像，也不必解释文件在 Dropbox 或 语雀 中的位置。” 吸引英格兰队的最后秘诀是什么？告诉他们 Figma 在 WebAssembly 中的工作。因为我们一直在推动浏览器技术的发展，所以您可能会发现有很多工程师听说过我们。 James 说：“其中有些人已经喜欢 Figma，因为他们正在使用 WebAssembly。” “您拥有最好，最方便的基于 Web 的应用程序。从工程学的角度来看，就是值得称赞的。” 用糖果追求设计师有时候，设计师可能是最难吸引 Figma 的群体。许多人担心开放，透明的设计。其他人则不认为 Figma 的基于Web的应用程序可以像台式机一样快地操作。 Figma 在性能方面做了很多工作，在某些情况下甚至胜过应用程序，但人们必须亲自体验它才能相信它。 因此，为了说服设计人员试用一下 Figma，请尝试一下糖果：矢量网络，团队远程协作设计功能，桌面应用程序、草图导入工具。 James 花了一些时间与其他 Buffer 设计人员一起打开了Figma文件，并演示了这些功能的强大。 James 说：“我们的初级设计师汤姆（Tom）并没有意识到组件的真正功能以及如何使它们更容易处理复杂的设计。” “在我向他展示之后，他惊奇地说‘哇，这太神奇了！’” 通常，一旦设计师对 Figma 糖果感到兴奋，他们就会留在 Figma 胡萝卜中，协作功能使他们更轻松地将设计移交给工程师，或将他们的工作传达给领导展示。 结论在给 Buffer 员工足够的时间尝试不同的设计工具并帮助他们发现 Figma 的优点后，James没有太多要做的工作来说服人们做出改变。好处显而易见，每个人都参与其中。为了最终确定该决定，他发出了最后的备忘录，总结了该公司为何选择 Figma 的原因。 James 在电子邮件中总结道：“设计工具 Figma 将帮助我们更加开放与协作，让我们的设计保持统一性，并缩小我们与工程师之间因设计交付存在的实现不一致的问题。” Hi! I’m Bruce Wu UI/UX Design, Product Designer, Freelance👋 Some Availability For Projects. My superpower is to channel my interdisciplinary skill sets to create appealing and delightful experience for users in meaningful ways, to make people's lives easy and simple. 1、背景 前端应用如果想抢占国际市场，则必须先要做国际化改造。以使用React框架开发为例，目前常用的国际化组件是react-intl或其衍生品。但不论使用何组件，遵循的模式都大致如下：开发时在项目根目录下增加语言包文件，每个语言包使用key-value格式的js或json存储数据，在项目编译时会把全部语言包一起编译进js文件，在使用时会在本地或服务器存储当前语种，切换时由组件切换对应的展示文案。 2、存在的问题实际在使用的过程中，虽然这种方式最简单，却随着开发的深入，就会发现这么做很多麻烦和不合理。 首先从开发体验上来讲，最简单的做法是每个语言包的文案都由开发手动维护，但当词条日益增多、支持语言多达二三十种时，再去手动维护语言包简直是人间噩梦，每次都得改动一大批文件，弄得我们在国际化上花费了很多不必要的时间，而且还不能保证准确性，可谓事倍功半。 其次从使用体验上来讲，随着语言包的数量增多和体积增大、势必导致最终编译的js文件过大，页面加载运行日益变慢，用户体验不断变差。 由此我们也将不得不对这种方式进行改进。 3、改进之路探索：一把辛酸泪关于前端页面国际化改造，网上也是有不少的案例和经验，总结来看是从三个方面入手优化：文案采集、文案翻译、文案使用。 3.1、文案采集首先当词条多、语种多时，手动登记肯定是不靠谱的。因此我们需要用一些工具来帮助我们对语言包进行自动采集更新。 3.1.1、从代码采集文案 我们可以借助babel工具，将我们的源代码转成以下格式的语法树（AST），然后遍历整个语法树获取到我们想要的国际化函数并获取其参数，最后转化成文案。 这是网上给的最多的解决方案，但是这种方式还存在缺陷，即当函数参数是变量时即文案是后台文案或复杂的文案组合时就无法准确获取到文案，即存在类似下面的情况： 为了解决部分词条不翻译或满足我们特定的解决方式，我们参考eslint的解决方案，在词条附近添加特定的注释来帮助我们的做一些自定义报错。但是这就需要对历史代码做处理，特别是一些老旧项目在改造时，如果遇到这种情况比较多时改起来程序员头发就得掉光。 3.1.2、从设计稿采集文案 如果项目开发流程严谨，每个页面开发时都有完整的设计稿（其实设计开发也应该要有完整设计稿，不然程序员怎么会知道做成啥样子），那么我们就可以从设计稿入手获取文案。因为设计稿不仅包含了页面的所有交互细节，也包含了页面所有的展示文案，只要我们能从中提取信息也不失为一种好办法。 目前设计软件有很多，大部分都支持自定义插件开发。以figma（很多大厂都是使用figma作为设计软件）为例，有figma开发平台（需要翻墙）给开发者插件开发指引，我们可以自己写一个插件，可以利用插件采集页面上的所有文案，手动过滤后即可得到文案。当文案比较复杂时也只需要插件支持用户自定义组合即可。 与第一个方案相比，从设计稿采集文案虽然需要更多的用户操作（用户选择文案组合方式和是否翻译），但是可以采集复杂的文案和后台文案。同时当产品经理修改文案时也可以通过插件更新设计稿，以保持设计稿最新（简直是设计师的福音）。 这种方式的缺点也很明显，如果程序员开发都没有设计稿，那就当我没说。 对于老旧项目，我们可以直接从语言包中采集旧文案，只需要对新做的页面按照这这种方式采集文案。 3.1.3、从产品文档采集文案 考虑到很多的程序员在开发时确实没有设计稿，我们也可以从产品设计文档中提取。要求产品经理将需要翻译的文案及其对应的翻译以表格形式放在文档固定的位置，然后再写个自定义工具扫描就能得到文案。与第一种方案相比，他也同样可以采集复杂的文案和后台文案，同时也不像第二种方案需要过多的用户操作。产品经理修改文案时也只需要对应的产品文档即可。 这种方式不方便对文案进行统一管理，会导致每个设计文档中都有零散的文案登记，会出现不同的产品经理对同一个文案有不同翻译的情况，同时这也相当于把程序员的体力活移给了产品经理，怎么说呢，相当不厚道（如果你觉得产品经理闲的老是给你们提伪需求，就当我这个句话没说）。 如果你们开发连设计文档都没有，那这个方案就不用考虑了，我只能说这个项目你们还能做下去简直是人间奇迹。 3.2、文案翻译当获取到文案时，我们需要有一个地方统一存放和翻译文档，提供产品经理和程序员查询和翻译的功能。 3.2.1、使用在线协作表格 当文案和语种数量不多时，我们可以考虑使用在线协作表格进行文案进行统一管理，目前腾讯文档和飞书表格都是免费且强大的工具，我们只需要自定义一个工具将采集到的文案通过腾讯文档或飞书表格的API上传至表格，后续交由产品经理去管理、翻译即可。但是这种方式缺少流程化管控，当文案数量多时查询和管理起来也是不方便。 3.2.2、使用在线管理平台 当文案和语种都比较多时，我们可以考虑使用管理平台来进行管理。他的功能和腾讯文档、飞书表格差不多，好处是加入了流程化管理（上报-翻译-审批-使用），同时检索起来也更方便。但是目前国内尚无好用且免费的翻译平台，自研的成本又很高的，所以这种方式好多公司都是望洋兴叹。 这里给大家推荐几个国外免费的平台：
3.3、文案使用当我们解决完文案采集和处理后，怎么使用便成了问题。目前用的最多的还是动态预加载和静态预编译两种。 动态预加载是指页面加载时加载部分或全部语言包，然后根据用户语言选择在页面上展示对应的语种的文案，这是目前最常用的解决方案，但是也是导致js包过大的原因。 静态预编译是指在项目打包根据语种将项目打包成多个语种的js版本，部署时通过页面路由切换，能降低js包大小，但是有多少个语种就得编译多少次，编译时间太长。另外一个需要对代码进行解析替换，就需要借助文案采集方案1,但是函数参数变量的问题和后台文案的问题不好解决。 综合上面两种方式的优缺，也可以选择一个折中方案。将语言包转成静态资源或请求，做成按需加载。我们需要在页面加载其他js前将语言包加载进内存并解析，然后再加载其他js,这样带来的代价就是增加了页面空白期。不过考虑到缓存机制和单个语言包大小，页面空白时间可控。如果不在页面加载其他js前加载完，就会导致使用到文案的变量在定义时获取不到文案，后续也不会再定义，也就相当于没效果。 再进一步考虑，如果我们能知道哪些个页面用了哪些个文案，当我们按路由给js分包时就可以在每个子页面加载前只加载该页面用到的文案，这样请求的大小将进一步减少，当然带来的代价就是请求会增多。如果我们能从设计稿中获取到文案，那么这种方式的可实现性很大。 4、最终方案考量因素在最终方案选择的衡量因素中，除了要考虑技术方案的利弊和可实现性外，还得考虑开发流程中各个角色的配合和工作量。好的方案不该只方便程序员，应该方便所有人。因此先将页面国际化中的参与角色和工作整理如下：
5、基于figma插件的前端国际化解决方案经过多方因素的衡量，最终选择开发figma插件并从figma设计稿中收集文案，收集完后上传至文案管理平台。平台会通知产品经理去翻译，翻译结束后平台会通知设计师去更新设计稿，然后设计师打开figma插件一键更新设计稿。同时平台也会通知程序员去重新编译项目，而在程序员开发时，平台会通知自定义的多语言组件自动更新本地语言包。由此产品经理、设计师、程序员三者的工作得到极大地解放。具体的流程见下图： 5.1、figma插件figma插件的开发手册可以参见figma开发平台（需要翻墙）。插件会分析页面所有的文本节点，并按照回车符和样式进行截断，截断后设计师可以选择组合方式，例如存在文案“点击 进入 获取更多”，插件会截断成“点击”、“进入”、“获取更多”，设计师可以选择组合成“点击{x}获取更多”和“进入”两个文案或“点击”、“进入”、“获取更多”三个文案等多个组合方式。同时设计师也可以选择改文案是否选择翻译，一系列的操作将保存在figma文件中，为后续的自动更新设计稿做准备。 每个文案都会有一个独特的ID和一个语义化key，代码中使用的是语义化key，这样有助于开发者理解代码，而ID是伴随文案终生，key可能修改但是ID不会变，也是因此，我们可以根据ID来判断文案有无修改，有修改时通过插件更新设计稿上的文字节点。由此设计师通过插件即可完成他在国际化中需要的工作，提升工作效率。 5.2、文案管理平台平台会接受插件上传的文案并和已有文案的内容进行比较，如果是未翻译过的文案则通知产品经理去翻译。产品经理也可以主动在上面进行文案调整，调整后会进入审批流程，交由制定人员审核后即可正式使用，而后平台便会发邮件告知设计师更新设计稿，也会通知开发人员去重新编译项目，同时也会将最新的文案信息推送给多语言组件。平台会标记每个文案的来源以及参考翻译结果，帮助产品经理快速定位文案使用位置且节省产品经理翻译时间。 5.3、多语言组件考虑到可实现性，目前做成每个页面按照路由去加载语言包不太好做，我们可以退而求其次，选择在页面加载js前将单个语言包加载进内存。这就需要用到多语言组件，它包含4块内容： 第一块是独立的后台程序，他会在项目开发阶段使用，会时刻接受平台推送的最新文案信息并转成语言包保存在本地。 第二块也是独立的后台程序，会在项目编译节点从平台获取最新文案并转成语言包保存在本地，然后断开连接。 第三块是提供预处理函数，会页面加载其他js前从即在指定语种的静态资源语言包并处理保存进window对象中。 第四块是多语言函数，可以在代码中使用，可以展示对应语种的文本，本质是从window对象中获取对应key的文案并返回。 借助这个组件，程序员只需要在代码中直接使用文案，而不用在手动维护语言包，极大地解放双手，提升生产效率。 6、最后经过我们项目上的实战使用，发现上述方案确实在开发效率和文案准确性方面都是很大的提升，也为设计师、产品经理省了不少事。同时我们也希望这篇文章也能对你们前端项目的国际化改造有一丝启发。如果对我们方案的实战产出感兴趣，可以通过公众号与小编进一步沟通。 我们是数数科技前端团队，目前负责游戏行业使用最多的用户行为分析系统的研发，同时也在积极探索前端新技术和新领域，如果你对游戏、大数据、可视化、工程化、全栈等方面有兴趣，欢迎加入我们，共创未来！ 联系方式
|
前端 使用 Figma
版權 © 2024 zh.wiewird Inc.
