今年至今发生了很多事情，以至于过去半年内几乎没有在此地有所投入。本站建立于约去年此时，值此之际以此文复出我关于设计和实现的的写作与思考之旅。
记得国庆里一夜凌晨和朋友们吃完火锅，回到家中，静坐在窗前，发现过去这几个月，过得竟有些浑浑噩噩。似乎是一个思想上的真空，很多记忆和细节，如果不记录下来，真的是会遗忘的。
去年我写了一篇thinking in design, 今年我的主题想宽泛的‘focus’在gui （图形用户界面）的一切上，很难说每一小节之间的联系，但应该都是些值得记录下来的想法。
界面设计的早期经验
意识到，我似乎已经，并且将要长期和用户界面的设计和实现打交道，这些回忆且当是个引子。
我第一次尝试做UI大概是在高二下的时候，和我的同桌 江溯天 设计未来的社交网络。因为暂时不能访问到他过去相册的照片，具体的图纸现在已经算是遗失了。我所能记得的差不多有一些蓝色的六边形的结构，那时候差不多iOS7刚出来，我们就开始在简约上有所追求了。那时候我们之所以偏好于六边形，不仅是因为六边形能代表一种科技感，更是因为我们想要在UI设计上面做出像iOS7一样的革命性变化。如果你观察传统的（其实就是现在的）的界面呈现形式，用来乘载UI的骨骼的模式，都是矩形网格。所以当时为了满足内心某种革新的欲望，在当时的一些设计里边，积极尝试了六边形网络，甚至到后来，已经发展成纯粹的多边形，poly化，像水立方一样。后来我们也自认为这样做仿佛是走到奇怪的境地了，这样的UI，毫无使用逻辑可言，就表现形式上来看，与游戏无异。但是我们依旧没有停止当时疯狂的设想。到最后，我彻底放弃了对具体形态上的追求，设计了一种无边界UI，地图式导航，非常前卫和科幻。如果从现在的角度来看，其实在那个时候，对UI的思考已经跃升至整个人机交互的层面了。但是那时候并没有多少学习和积累，所以并没有深入下去。
除了这个，在高中我还和 江溯天 存哥 尝试做游戏。这个事情和前面的一样，随着后来高考，毕业，渐渐也就没了下文。 上了大学以后，突然有了在过去难以想象的空余时间，然而却已经没有人和我讨论这些东西了。在那段时间里，关于界面设计，我只产出了唯二的作品。正如我是因为想要做游戏，所以才有机会接触程序开发一样，在我玩了一些很棒的手机游戏以后，重新点燃了内心的创作欲望。在高三的时候有一个很火的游戏叫2048，这个2048是inspired by three的，three是一个很有意思的游戏。three当时对我一个启发是，和实体世界不同，虚拟世界的交互是极具自由的，人可以很自然的和某个游戏元素交互，游戏元素之间也可以相互交互，当这些元素随着环境随着状态表现出不同的行为，它就被赋予了虚拟空间内的生命，整个虚拟环境也会体现出真实感、生命感，虚幻的极致便是真实。当时的我还是一个国际象棋爱好者，所以我做的一件事情就是试图设计一款新的象棋游戏，每个棋子能够根据场上的形式和事件表现出不同的行为。大大提高游戏的乐趣。比如，你选择了一个棋子，对方一个棋子正好在你这个棋子的攻击范围之内，就会显露出惊恐的表情。比如当你全线溃败，棋子的形象就显得消沉。比如突然大意丢了皇后，那么会有一系列戏剧性的效果发生。不是很有趣嘛。
解构模仿
我不愿意模仿别人，即便别人有现成的成熟的体系。首先因为我是一个学生，能够不断的低成本的试错是我的优势。设计资源网站上有很多好看的东西，真的好看的不得了，要做作业了，要给别人做东西了，拿到需求赶紧上网看到好看的，模仿下来。倒不是功能上，创意上的模仿，你说我模仿个风格有什么不好，你看我模仿的越多，我越能自己做出一样好看的东西，我说这是靠模仿学习。但我是不愿苟同这样的想法的，这样的做法就是逃避思考与创作。模仿着别人做出好看的东西了，别人一称赞，就有成就感，以为自己超了近路，掌握了学习设计的捷径，孰不知这世上恐怕没有近路可走。
每当我想到这个问题，都不可避免的认为这是和创造行为的本质相联系。你说创造，是不是纯粹的对已有的具象进行组合和衍生？坦率说我不知道。你看古时候每个隔绝在各地的文明萌芽，他们的艺术文化都是截然不同，都和他们生活生产息息相关。他们组合的资源是有限的，我们所能想象的，他们所不能想象。所以我们的艺术我们的文化也是被我们的想象所制约的。从这个角度而言，模仿是无可厚非的事情。我认为创造是心智活动的外在映射，当你总是想着组合和衍生，你的创造就是在做组合和衍生，所以其实限制从来都来自我们自身，当你冥想一个抽象的感受，思绪，结构，并且表现出来，这种表现就是被你的心智所领导的，亦具有组合和衍生所不具有的特性，这就是更高一层的境界。从这个角度而言。模仿是在别人的圈内固步自封，当这种不知不觉的舒适感成为了习惯，那么就偏离了对大道的追求。
我们所说的设计风格等等，难道不是让人来模仿的，是。存在是合理且必要的，因为设计是和商业密不可分的。但本着我们是学生，或者我们处于并且永远处于设计的学习阶段。所以谨慎对待风格正如谨慎对待模仿。对于风格，不如进行禅宗式的解构，这世界上没有真正存在的风格，所谓的风格只是，表象的归纳和认识。与其追随模仿别人的风格，不如自由创造自己的风格，与其追求独树一帜的风格，不如追求艺术性与一致性的平衡。做出能真正面对自我的设计。
细节决定一切
自去年8月份以来，我已经在sketch里画了数百张界面，当一个人越执着于某个事情，他在这件事情上相对于其他人能有显著的对细节的观察和把握，设计用户界面的道路上的确就是在印证了这样的观点。这篇文章我写的也有一点时间了。最早，我主要在罗列很多过去这一段时间内一些工作经验，比如如何使用线条来分割空间引导认知，如何有效的通过排版去包含逻辑，如何使用字体投影样式等等。但是后来我把他们全删了，因为我认为这些东西的存在事实上是一种误导，因为这些规则和经验虽然很有可操作性，但是如果你去实践，会有很多问题。一方面，正如后文要指出的，他们不够普适。另一方面，这会使你完全堕落成一个美工，而无助如何去探索和积累新的经验。最重要的一点是，好的设计是多样的，似乎不存在一个确定的描述说好的设计应该是如何如何，选择一个解释，意味着放弃更广阔的世界，这不是在做设计。更何况这些条条框框而且相比市面上那些讲这些的书我肯定不如他们来的全面，不如不写。
做UI视觉你所应该时刻牢记的，在我总结而来，一是人的眼睛是无比敏锐的，即便是高清屏上的半个像素，也能被充分感知。二是做任何东西，诚意是至关重要的。你可以欺骗自己，但是不能欺骗别人。东西有没有认真做，有没有认真思考，是看的出来的，这个不是从工作量上，不仅仅是从工作量上能够反应出来，而是从质量上，堆砌细节，盲目拟物化，盲目添加效果有时只能适得其反。细节决定一切，但是细节不都是可见的，在于设计有没有思考，有没有追求，从每一个图元到每一个像素。曾经我以为追求每一个像素只是一句非常理想化的口号，然而事实上就是这样。因为我们的眼睛实在是造物之极致。在排版上，只要有一点点分布上的不匀称，都能被感知出来。不要轻视手头工作的繁琐和无谓，不要欺骗自己，这无助于任何事情。
SCREEN & BEYOND SCREEN
界面的呈现方式是屏幕，世界上屏幕有千千万种区分于，大小，分辨率，颜色深度，视距，等等。针对每一种情况，都有不同的设计规则。我们往往能认识到的是，手机屏幕和计算器的屏幕是截然不同的，电视机屏幕和显示器屏幕是不太相同的，电脑屏幕和手机屏幕差不多？高分屏和手机屏幕应该是一样的了？ 屏幕越像，我们的感觉就应该越接近，对，在这里，敏锐的观察力和对细节的把控又决定了一切，你以为你mac的Retina和你iphone的retina看起来一样没有颗粒感，其实当你自信的在电脑上做完图到手机上看的时候，细节真是天差地别。
这个有趣的怪圈就是，我们设计UI，都是在屏幕上做的，但是我们的目标设备的屏幕和我们进行设计的屏幕是不同的。这导致我们根本不知道某，决定是否正确，从而要不断的去真机上看。这是其实是一个巨大的限制。好像你开发东西，你并不知道写的对不对，写一段得去测一段，比较痛苦。其实让你意想不到更糟的情况是，目标设备不仅仅和你的屏幕不一样，使用环境也起到了决定性的影响作用。光照条件，屏幕亮度，甚至屏幕周围机身的颜色都能极大的影响到最终的效果。如果你有那种很淡很细的线，那么环境光太亮就感受不到了，如果你在屏幕边缘有亮丽的色条，那真机的醒目效果是大大削弱的，如果你的黑色导航栏有轻微的颜色倾向，那么这种倾向会因为屏幕黑边而放大显得很脏。等等等的例子不胜枚举。
所以要针对实际屏幕进行设计。看不到你的设计在真实屏幕真实环境下的呈现是危险的事情。现在的工作流已经基本客服了这一问题，sketch有sketch mirror，adobe家也有adobe家的产品。我主要使用的还是sketch mirror ，依靠局域网或usb线缆连接到机器，实时向目标机器更新画面。不错的生产力工具。
GUI IR &
在编译原理和编译器架构中，有中间语言这个概念。编译器前端的输出并不会瞄准某一个特定平台，而是一个跨平台的中间底层描述。编译器后端针对中间语言进行分析优化和目标平台的代码生成。这样，不用为每一个语言的每一个目标平台都写一套编译器，只要为语言提供中间语言的编译，就能完美生成所有的目标平台的可执行代码。
在图形界面设计方面，我试图也去寻找相关的思想和框架，即图形界面的中间语言。其实这样的构思和野心对于每一个号称能构建跨平台UI的框架都是存在的。但是至今没有像llvm的ir或者jvm的字节码一样通用的完善的解决方案。论实现，现在的 web 可以说充当了这一中间语言的存在。但仅仅是在平台上浏览器厂商实现了web这个平台，并不是一个中间语言的概念。当然，如果从结果导向来看，web已经成功的做到了一次编写到处运行的目标。现在差什么呢？ir一般是可以围绕它集中分析和优化的，它足够底层足够自由，论这些点，web都没有，而且还有沉重的历史包袱相关的设计问题。想到这里，我终于知道大神们为什么都想写自己的跨平台UI框架了，的确是足够诱惑，足够挑战，足够浪漫的事情。
布局的本质
所谓布局，本质上，就是指一个图元的长宽和在渲染坐标系中的绝对位置，即(x,y,w,h)这四个量。确定了这四个量，渲染器就知道把这个图元画在哪里，就完成了布局的过程。我们正常语境下的布局，比如说，这个元素和这个元素左对齐，这个元素垂直居中于这个元素，其实都来自用户界面模式的抽象，自从我顿悟到布局的本质后，一直试图解构这些已经熟知的应用模式。我们熟知的UI表述体系，无论是html，xml，都是一颗树，这是因为每个元素我们给它设定了从属关系，即所谓这个元素包含了另一个元素，所以整个UI它是有结构的，它不像我们在做图软件里，每个图元之间没有关系，仅仅是图层顺序的堆叠。既然说解构，那我们假设UI元素之间没有这样的从属关系，变成一张画板，有什么问题? 似乎没有什么问题，比如说定位，原先树上每个元素的位置，都是父元素位置叠加自己的相对位置，现在把树去掉，保持原先的父子同时移动特性，那就把原先递归到根节点收集相对位置的过程取下来变成一个位置依赖的表达式。又比如说撑满父元素宽度，那么同样是一个表达式，即等于父元素宽度，又比如说垂直居中，那就是一个y的表达式，它和自己的h，和父元素的h有关。
从这个角度想，我们可以认为要实现我们现在所谓界面的布局，只要认为任何元素 (x,y,w,h) 其实是 (f(…),g(…),m(…),n(…)) 四个表达式，每个值依赖与其它元素的值，或者是常数，或者是外部输入，这个外部输入可以是窗口的长宽，可以是滚动条滚动的距离，甚至的任何数据源。这个体系可以说是现在任何一种布局系统的超集，比如在web里，你百分比宽度只能取到父元素，对齐只能在父子之间，而上述的表达式布局，自由度几乎是无限的，你能引用任何元素xywh和任何数据源参与计算。所以父子关系树并没有在布局里有关键性的作用，但这种表达方式为什么大家还是不约而同的选择使用呢，甚至把元素相对布局功能基本限制在父子兄弟节点之间？
我认为有以下几点原因。其一我们知道，从工程实现上考虑，我们要把一个系统设计的充分抽象和复用，把东西都封装好，然后拼起来。像表达式这种依赖满天飞的布局模式，对于复用几乎是灾难性的，抽象的难度也是巨大的，为了封装和组合，牺牲了这样的自由。限制到父子的最小层级，保证了复用可以在任意粒度上进行。其二，css其实是在表达式布局的基础上的抽象，表达式布局虽然自由，这样的自由度我们对于做界面来说不需要，还有维护的极大困难。css可以说抽象了界面的常用布局模式，这里所谓的模式，来自于做界面常用的需求，比如说容器和内容的相对关系，比如多行文本，表格等常见的来自排版来自人类生活的东西，表达式就非常费劲和困难，几乎不可能了。其三，按照正常人的品味，声明式的实现远好与命令式的实现。你说一个表达式是声明还是命令，我还是倾向于是命令。比如说我这几个元素的宽度要等分那个元素，如果我要动态的添加前面的元素组，那要改的东西就多了。表达式布局过于底层了。元素之间的关系应当进一步需要抽象。
如果我自己设计一个UI的布局系统，树还是必需的，我还是希望能够开放这种最自由的布局方式。各个元素layout，draw的底层实现，包括想css这样的针对树结构的批量选择和批量属性派发也是要的，派发的东西也可以自己定义。这样就彻底解放了表现力。前面所述的几个元素的宽度要等分那个元素也给了我一些新的启发，树这种结构只定义了父子层级和兄弟顺序，兄弟之间不仅仅有顺序，也有一些关系，父子层级为相对偏移的自然存在提供了解释，有没有可能有限制的使用一些图的描述方式来进一步对界面表示进一步抽象，来强化兄弟节点之间的布局关系？稍微细想一下似乎问题很多，比如你这么构件一个易于编辑的图的文件结构都是问题，但是这个想法还是值得我进一步考虑的。
Working project
我们的UI绝大多数从代码文本手工构建。低效，即便诸如emmet类似的快捷工具被创造出来并没有从根本上解决在UI构建过程中，大量重复文本关键字的输入的痛点。同时，成篇的文本代码也并不利于快速定位问题和修改。正如没有人会手写svg来画logo一样，我们需要一个好用的界面化的UI设计器。
我想谈谈我最近在做的东西，它是一个用来做web界面的可视化辅助开发工具，兼具企业UI组件管理 UI组件共享平台等功能。
做这个产品的灵感或者说需求，来自我之前在必乾科技做千笔数学的相关经历。我们是个典型的小团队，其实是个微型团队。三四个人做了后端和三个前端加设计，自我感觉还不错，真的有点了不起。设计和前端是做的。等于说我对界面的设计和实现过程都很熟悉了。
因为css规则不正交，所以不熟悉的开发者需要耗时反复搜索查阅文档来实现特定某个简单需求。无数人写了无数关于如何垂直居中怎么实现的博客，无数人在外边距什么时候不塌陷纠结过，不是说你怎么连文档都懒得查，这是个客观存在的问题。一方面web的东西这么多，这些有时候用不到就忘记了，没用过的东西都不知道。另一方面损耗了生产力。我们难道不应该创造一个服务于此的工具链，帮助开发者回避坑的地方，无论是各种实现的弊端还是兼容性，总结现成的模式方便快速构建界面。而且由于css这样那样的设计问题，多人协作难以保证质量，如果我们在css的上层再抽象一层来描述界面，可以很大程度上避免这样的问题。
无论是多一层抽象还是将原本的UI构建过程界面化可视化，这样的操作以后，就很方便的能够做下游工作，例如图纸渲染和代码生成。这对于小团队是大有裨益的，比如说像我的情况。甚至不存在独立的设计岗位，有一定设计能力的前端工程师同时负责界面设计，或不存在独立的前端岗位，有一定实现能力的设计师同时负责界面实现。设计被经常反复修改，图纸更新后更新代码，或是直接在实现的过程尝试进行设计，即先修改实现至满意再完善设计稿。不仅仅需要代码实现来作为产品的组成，也需要图纸的存在来快速推演方案进行设计迭代，如此设计图纸和实现代码需要反复同步，造成低效。这种低效，不利于产品开发，也不利于团队内部形成定制化的设计和实现规范。如果通过这么一套产品和服务将UI开发和设计的过程 专业的 完善的 整合在一起。那么问题将迎刃而解。
很多开发者不愿意使用代码生成工具，是因为生成代码的逻辑是不可控的，你不知道如何改它，你不知道它什么时候什么地方会有问题，你不知道它哪里写的薄弱。但是针对UI，它的界面相关逻辑其实是轻的，html＋Css具有一定稳定性，不会说像完成一件事情有无数种方法，所以我认为构建相关的代码生成是可靠的。尤其是结构和样式方面，我们甚至可以针对不同的前端框架做生成，比如我们通过工具构建出了界面，不仅需要静态的，也需要angular的，也需要react的，生成也是很简单的事情，同时也免去了很多不必要的文本操作，提高生产力。
事实上，相似的设计器如dreamweaver，存在诸多设计问题，庞大臃肿，不能适应日新月异的web，并不能很好的解决上述问题。dw面向没有开发经验的设计师，它不是为了解决开发问题而存在。又比如Webstorm, 完全面向开发者，作为一个ide，相对于此，我想做的，其实是个中间的存在，能够兼顾两边的优势，为设计师能够直接生产用于生产环境的UI组件，为开发者能够以设计的模式快速构建UI代码。我也搜索到了一些相类似的产品，比如webflow，但是我认为它是做烂了。虽然看起来像那么一回事，但是无论是使用交互还是性能体验都有严重的问题。重要的是他最后定位竟然是一个cms快速建站，我觉得这是不对的，可能这样能快速捞到钱。我会在后续相关主题的文章中详细比较和说明我的设计。
我们现在处于web发展一个重要时期，就是组件化，无论是各个框架的设计，还是标准的推进上。所以产品的核心应该围绕一个组件设计器，通过组件设计器设计组件，组合组件，直到组合页面。如此，企业级的组件库就可能被有效构建和管理，如果我们将存储，分析，高级构建功能包装成后端服务，前端使用web或electron， 后端部署在企业内部，那么可以做成一个面向企业的开发工具。控制整个企业可复用UI组件的构建 组合 发布 共享 版本控制 设计工作流整合。
网站升级
今年67月份我其实一直在做下一版新界面，开了两个新的repo，前后端都推倒重写了，一个是mkalex-spa,是新前端，另一个是mkalex-rest-backend, 基本说是按之前的前后端分离的方向走的。前端用的是很熟悉的Vue，后端实践体验了一下node，用的是koa.js，async await写的很爽，洋葱模型很好的抽象了整个请求处理的过程。这次我终于扔掉了orm的拐杖，学习了一些数据库方面的东西，裸写sql。整体感觉有点简陋，有点冗余。特别是数据库字段那些，重复很多。好处也是显而易见的，就是简单，什么事情都是在我的控制之内。但总规之前是django嘛，django真的是非常完善了，现在很多事情都要自己做。此时，我竟然有点怀念jekyll了，简简单单挺好。
在新版里我做了很多设计，很多飞跃，新的技术使得体验能够上升一个台阶。在过去一段时间里，我经常看Medium，是一个国外的博客平台。他的阅读体验就很好，无论是是桌面还是移动端。我总结一个是图片的问题，他那里，图片点了可以全屏放大，这时候要是再滚动页面，图片能够自然的缩小回去，这个体验很棒。这个可以做，没什么问题。说起图片，在我另一块作品集那里，图片可以说是主要元素了，如何去优化那里的图片呈现，就是比较头疼的问题，渐进加载是最好有的，我试了写图片格式自带的渐进加载，感觉还凑合吧，Medium他是先来一个大半径的高斯模糊在一个canvas上，然后再逐渐清晰起来，效果就不错。我也看到新版知乎有模仿的。这个需求就不是很好做了，我以前写过模糊的滤镜，知道大半径的模糊是非常消耗性能的，web上脚本语言是存在性能瓶颈的，就需要寻找一些比较hack的高性能模糊算法，我找到了一些，都其实并不是很好实现。Medium这种模糊变清晰的特效其实也存在问题，只有图片加载完全结束以后才会开始变化，就使得用户看到内容延迟了，我们假设图片都是自上而下下载加载的，那有没有可能，这种渐变模糊只存在图片正在加载的下边缘呢，这样等于说有一个渐变的遮罩慢慢的揭露整个图片，这种体验就很棒。实现是个大问题，图片标签它没有为这种连续加载行为提供接口，硬要做可以用canvas和blob模拟一个，但这样就很不划算了。Medium除了图片做的不错，在文字排版上也并不逊色。我对于文章内容都采取了两端对齐的策略，虽然左右能对齐显得整齐划一，却在中英混排时字距显得混乱和松散。text-align:justify的行为是无法控制的，Medium没有做两端对齐，这在我现在看来是正确的选择。
我也考虑过引入web app的支持，短期还是不会去做的，虽然现在已经全面迁移到单页应用了，变身webapp也没多大困难，其一主要是目前iOS上的支持非常有限，尤其是service work上，其二需要全站的https支持，我不是很想加钱搞这个。当然，虽然没有service worker可用，meta标签表示说还是要支持一下，这样，你把网站添加到主屏幕以后，进去就可以看不到浏览器外框了。
这次我也想搞些特效什么的，我认为最有搞头，最有意思的方向，是webgl。3d的东西放在哪里都是吸引眼球的，在three.js 的主页上，罗列了满屏的应用例子，这些网站的绚丽程度真的让我对web的表现力有了新的期待。opengl的书买来都积灰了。
Markdown需要import功能！
在我去年写jekyll的时候，发现了markdown这个好东西。md让人专注于内容，而不是表现。对于专注内容的人来说，这东西作为简单的写作工具真的很棒，但是如果作为像博客这种网站类型主要内容的承载者，我觉得它有一些问题。
功能无法扩充，这是主要的问题。其实也不是无法扩充，人家都是支持内嵌html的，就是扩充起来不好办，不优雅。举些例子，比方说我需要写一个图片，这个图片能够点了以后全屏放大，原先的写法好像连呈现大小都没法控制，更不要说这种东西了。我也不方便改编译器，我也需要原先默认的语法，所以能不能自己造一个语法，就好像写了一个自定义标签一样，它就根据这个编译成我需要的东西。其实这种类似的需求还是很多的，比方说我希望在md里直接写一些Latex，拿个什么括起来，到时候编译以后就是图形化的公式，又比方说我现在有个小的pdf文件要嵌入进来，我可以像图片一样，写个标签配置个大小，它到时候给我在页面上搞一个小的pdf阅读器，这种东西我觉得是有这个客观需求的，它不需要存在于语言的核心，但是应该被妥善支持，可以理解为插件或者包引入的机制。
我认为一个好的解决方案是，建立一个语法扩展的接口，引入一个新的语法约定，编译器遇到这个东西，就知道这里需要被插入外部扩展的内容，然后解读扩展的类型和配置，把配置交给类型对应在头部import进来的实现文件进行解析，解析完成后，插入返回的html。 头部的import像其他语言的包管理器一样，可以有官方的维护的仓库，也可以是自己的实现。这样就很自由了。 比方说我自己写博客，我突然想要自己发明一个时间轴功能，我就可以去mpm这种地方看看有木有现成的包，没有我就自己写一个，什么交互样式逻辑我都能自己控制，进去一个json配置，出来一个html，就好了。不是很棒嘛。我需要画个什么饼图，地图，小玩具，都好办，而且也好维护。
其实现在这么做根本没有什么问题，很简单，这个东西我会在我这个网站的下个版本搞一个出来。只记得当时写jekyll就很郁闷，什么导航，什么页脚，什么都可以自己完全自定义，唯独最重要的内容，它的表现形式被markdown框死了，这是在是不应该。
最后
这篇零零散散的记叙了我在GUI领域的见解洋洋洒洒竟然有万余字。总结而言，几乎是做界面让我走上了写代码的不归路。我知道原教旨主义的geek们都很讨厌GUI，但无论是CLI还是GUI，各有各的优劣。我自认为我是一个有追求的人，如果让我从人机交互，从人文的，从技术的角度看，GUI都是比CLI要先进的多的多的东西。它承载了我们看到的虚拟世界中的一切，使得机器不再寒冷和复杂。GUI的一切，也是艺术，人文，科技的交汇点，值得我深入学习和追求下去。
