2023：面对自我的提问与面对自我的回答
1108：为什么要以腾讯文档与 Figma 作为内容维护源
什么是内容：
当我们考虑内容驱动的页面时，我们就需要一个和前端分离的后台来管理内容。
实际上任何一个页面都可以说被其背后的“内容”驱动。这个内容可以是数据库或后台。
对于工程师来说，维护这些“内容”的时候，甚至不需要 GUI，而是一个终端就够了。随后有人针对数据库做了 GUI app；或者基于后台接口做了如 postman 的 app。
因为实际上直接去操作数据库对谁都不怎么友好。
也就是说，为了更好地维护内容，我们往往需要再开发一套前端来间接地去操作数据库。
为什么要用腾讯文档与 Figma？
就是要让他们去充当这个前端。
- 因为不用开发。他们本身就是强大的 WYSIWYG 或 GUI 工具。
- 因为接口足够。只要他们肯把内容交出来，让我们存好。
- 因为多人协作。
- 因为服务可靠。背靠大公司的稳定服务。
1031：关于富文本编辑器
开发富文本编辑器，当然和开发其他的前端页面不同。首先，它显然不是页面。
我最开始以知识库的方式构想过，但它不应该是知识库。
我后来以足够自由和标准的格式工具构想过，但它不应该自由，因为它需要被设计规范约束。
那么，这样一个微信广告特色的编辑器，是富文本吗？还是一个 Webflow？
以这个特色出发，提供具有各种排版和功能的格式，这不就是我们应该努力的方向吗？
反思：
我认为，业务应该被设计规范约束，但不应该直接为页面设计服务。它是工具，不是页面。它终归由内容驱动，而非设计驱动。
- 要考虑增加维护的包袱（突然想学别人说熵）。页面下线了，代码就可以删了。但工具必须向过去兼容。
- 要考虑工具的通用性。一个页面可以是一次性的活动，但一个工具的一种功能不要只在一个地方使用。
- 要考虑使用者的感受。太多定制化的格式会让人上手复杂。
那么我们的方向错了吗？我们的方向没错，只是可能有点过了。我们应该以设计规范约束，在这个过程中提供通用组件，尽可能帮助内容提供者、设计者、录入者及开发者的高效。
但其不应该首先为页面设计服务。
0810：如果我不写 Web UI，那么也会毫无追求。
接触过以小游戏为底层的封面广告、接触过以 Flutter 为底层的原生页，我开始理解为什么工程师对 UI 缺乏追求。
第一，是困难。这些底层本身能力不完备，存在着很多局限。这些局限由不得自己解决，还原设计这件事本身变得痛苦。antfu 说，我知道自己不是设计师。我能做的只是看别人的作品，从中参考和衍生。设计更多是我技术工作中的旁支，它变成了自己趣味的延伸。
我想，如果我所使用的工具，连实现他人的设计都尚且困难，那还能够体味额外的什么趣味呢？
第二，是无聊。一份设计稿标注得越详尽，实现的难度就越低，工程师的信心就越高，合作过程就越是顺利 —— 每实现一点都会有非常明确的完成感，会充满信心，会心满意足地抵达，会不再怀疑自己、不再于自负与自责之间反复徘徊。可是，回头看这些正面的情绪，却都抵不过一个词：无聊。
综合两点，这就是在一件本就无聊的事的基础上施加痛苦。自己痛苦不说，与设计师的合作成为互相消磨与妥协。甚至问出一些哭笑不得的问题：
事情绝不应该是这样的，且不说要共赴卓越，工作本身都缺乏了意义，设计与开发的沟壑变得越来越大，合作便丢失了信任。
UI 工程师要尽力地缩小这条沟壑。
- 第一，如上所说，要足够擅长自己的工具；
- 第二，只聊 UI，只关心实现。
我们不聊设计和开发，我们不聊 Figma 或 CSS。我们不应该由工具的差异定义了职业的界限。
当然，有的时候我们需要这个界限，但是当我们聊 UI 的时候，我们不应该有这个界限，或者说我们不应该由这个界限为基础，开始我们的聊天。
实际上我们都在做 UI 和 实现 UI —— Figma 也是在实现 UI。一份设计在被某样工具输出之前，并没有具象地存在在哪里。照这样想的话，我们所谓 Figma 是设计工具，其实确切说 Figma 是“面向设计师的实现工具“，其实和 CSS 一样，都是在实现 UI，他们的差异就是一个有 GUI、一个没有而已。
这是我在试图理解设计师和理解设计过程。这也是在试图在暗示自己：如果设计师有能力将想法用 Figma 实现的话，我为什么就不能用 CSS 实现呢？我们之间真的差别那么大吗？这不才是沟壑本身吗？
如果说 “UI 工程师要尽力地缩小这条沟壑”，就是做更多的工具、做更多的效率优化。这也没错，但：
- 思想的融合比这些更达本质。当然了，能做出东西才是实干者该干的事，但思想确实是本事；
- 只有都关心 UI，我们才能够统一追求。
换位思考一下，一个设计师将自己的设计稿交付出去后，需要经历数周甚至数月的开发实现。在这个过程中，他不断地等待、修改、磨合，甚至丧失对设计初衷的掌握。他并不清楚原因是什么，因为他不理解开发为什么会遇到这些问题。他只知道他要改什么、支持什么，他只知道目的是什么，却也只是知道目的本身而已。
这也是设计与开发之间的沟壑。
当设计师说“开发说做不到”的时候，他到底在表达什么？ 他在说：“我能交出什么样的答卷，很大一部分仰仗于开发团队的能力。但我对他们的能力，一无所知。我除了从我的视角思考解决方案以外，什么都做不了。”
作为 UI 的开发者，我们要在“能实现”和“不能实现”这两个答案以外寻找一些其他的答案：“能实现的 UI，怎么把它更好”和“不能实现的 UI，怎么把它变好”。在以 UI 为核心的思考下，在以设计视角说出开发解决方案的话语中，才会帮助设计师进行他的工作。
“开发说做不到”这样的事不怪任何人。作为 UI 开发，我们也不需要真的解释给设计师为什么会发生这些，他们就算知道了，转头也便忘了。我从来不喜欢这样的沟通，但我看到设计师必须和开发在做这样的沟通，因为这是他们唯一能做的事。我的意思是，既然如此，我们就不应该谈无用的话，我们只应该谈 UI，只有 UI 和体验是我们共通的语言。
这些话都是一些刻意的反思，本身早已变成了我的工作惯性。它们自然而然地发生在我的身上。我发现很多开发者正是没有这样的惯性，使得他们根本察觉不出 UI 的问题，更不论如何做得更好了。
他们愿意修改、愿意变得更好，但从来不和设计师在同一个位面思考相同的问题。因为对他而言、对他的团队而言，有其他更重要的事情需要考虑。
做 UI 的开发：将 UI 作为核心目标，以设计视角提出开发解决方案，最终实现之。
0723：如何理解重构（设计稿还原）的工作？
把一个设计进行重构的工作，其实是一种对设计的重新实践。重新实践的过程则是一种从零开始的体会和理解。理解为何如此，理解每一个细节。
认为 “还原只是把设计稿搬一遍，而无法获得或创造新价值的过程。” 这样的想法不能说总是对的。因为只有 UI 的实干者才有可能真正理解 UI。正是在此之上，别人的设计稿才会变成我们共同的作品。我无法保证这是必然的，但我起码相信。
0722：所谓理解，从来虚伪。
世界上不存在百分之百的相互理解。审慎地看待自己的同理心，永远带有距离感地面对世界。
0721：正确地处理感受。
所有的想法用于严于律己，它们本身是为了更高的自我要求。
我有比较强的“技术崇拜”。对于设计而言，我也认为“这个动画感觉有点快”比之“这个动画看起来是 100ms，有点快”，或“这个字体不好看”比之“这个字体看起来是 Arial，它有几个缺点”更为专业。
感受并不能作为设计者的工具，它至多是一个建议，一种衡量标尺。我厌恶自己以感受作为仅有的能力。感受不值钱、评价不值钱，我只认可自己作为实干者的资格。
分析并理解设计细节，而不仅仅是停留在“感觉很好”，有助于培养审美能力、提高执行水平、体味背后的乐趣，并增加对追求卓越这件艰难的事的实感和敬畏。
这是属于实干者的骄傲。
0720：幸福是快乐的碎片。
快乐与不快乐都是人生的碎片。
快乐的碎片，会变成记忆，然后越送越远。觉得可惜了，就要把快乐加多，把碎片连线。幸福才不在回忆了，而在现在，而在每刻。
不快乐的碎片，也方便了挥手作别。水为送，山为迎，春如醉，秋如醒，流水浮萍皆为过往。
春宵苦短，及时行乐。
0101 - 0630
对于我来说，保护自己意志力的方法就是 being negative。我不是一个 positive encourager。对于已完成的事情具有多大的价值，我很可能会持保守、批判性的态度。
如果用一句话来解释动效，应该是什么呢？目前的答案：在屏幕和体验之间存在的连续感（a sense of continuity between screens and experiences）。
CSS views transition & linear function，在可见的未来 css 动画也会跟上 js 才能实现的 feature，并且变得更好。很难不兴奋。
今天又看了一下 wwdc18 关于手势和动画的讲座。深刻，也共鸣。 甚至把参数和代码都放出来，感觉 apple 的人其实也没有那么复杂。 然后去翻别人的无论是谁的动效原则，翻出来不过是那几条，做的也不过是定几个 easing duration。然后发现就算是自己的官网，都没办法很好贯彻这些“基础原则”。
我们觉得这些太基础简单了，觉得自己可是个专业的人，自己的感受足以凌驾于这些“基础原则”之上，现在还提这些简直是动效的小儿科。
可是知道和做到就是差那么多。
apple 说 playfulness is a natural consequence of a fluid interface，说 fluidity as a medium.
这些话是浪漫的，是属于做 UI 的实干者的浪漫。那些以为深谙基础原则的人绝无可能讲出这样的话。做到基础原则，一点都不小儿科。
我只关心 UI，在过程中我明明不关心所做的到底是在设计还是在开发。因此我应该告诉自己没有道理困惑。因为我该清楚：自己只关心 UI。
浪漫主义者崇尚自我，在感受上独立，在精神上渴求浪漫。
人生许多事都可以被经历者浪漫地看待。甚至那件事本身是怎样都变得不重要。即美并不是一种本质或特性，一件事不存在其本身的美（或说浪漫）。
浪漫不是一件事实，是心甘情愿地相信。因此不要回头、不要后悔，不光如此，还要知道：浪漫不是不后悔，浪漫是早已开始不想后悔。
在 UI 表现这一领域的知识面与实践程度是非常重要的。表现相关的技术力，会反补到设计力。
如果要做到看到一个效果，就能花较少的时间想通其当下的最佳实践。那么需要从事这份事业至少 5-6 年。不断犯足够多的错误，是达到最佳实践的前提。这是我的个人感受。
一期二期如果是为了分步发展，那么是一个正向的事。但现实并不是发展的逻辑，是删减的逻辑。“我们把这一期完不成的放到二期。” 这没什么问题，当然也没什么意思。
UI 开发的工作通常“人在设计这，活在技术那”。以后尽量“活在设计这”。哪怕下游不用我的代码，我自己的代码权限也不会被被人收走。