一年一度毕业季来袭高校毕业展海报简直「神仙打架」
大家好，我是美丫姐，今年，因为疫情原因，各大高校毕业生可以说是哭笑不得，先是因为人聚不齐，拍个毕业照都拍不成，只能上手 p。
再是各高校想方设法也要让毕业生有个难忘的毕业典礼，纷纷搞了一出「赛博朋克」拨穗仪式。
这得亏是大白天，要是晚上在校园撞到这玩意儿还不得给人吓个半死！
不禁让网友纷纷大呼「搞点阳间的东西吧！」
但即便是这样，也丝毫没有减少，艺术院校办毕业展的热情全国各地各大艺术院校，都纷纷举办起了线上毕业设计展，斩断大家想逃过做毕设的念头，毕业设计展照常举办，那么毕业设计展宣传海报也一定少不了。
接下来，就让美丫姐带着大家来品品，今年各大艺术院校令人「眼花缭乱」的海报。
广美以其缩写 GAFA 组成的动态 3D 图形利用视差让人产生错觉，颇有几分韵味。
就是搭配上富有节奏的 BGM 后，让人不禁想到那句传唱大街小巷的广告词「一年逛两次海澜之家，每次都有新感觉」。
你看，这亦实亦虚的透明物体像不像甲方虚无缥缈的需求……
彼时，这一叠叠的纸张是一次次熬夜赶的作业此时毕业了，这一叠叠纸张将会是你被打回重做的稿子
去年被全网吐槽的天津美院海报，天美 2019 年毕业展海报
今年选择打一张规规矩矩的保守牌
不管甲方有多奇葩但毕竟给了钱，不管有多少坎坷都得咬着牙勇往直前 ，逆流而上！
这向四面八方发散的线条就像甲方天马行空的想法，没有重点，也似乎没有终点。
稀疏的黑白线条，就像学设计后你的头发，做设计，做到最后白了少年发，又秃了头。
这需要瞪大眼看的 PPT 式动态海报，不正代表着更新迭代快速的时尚圈嘛！
毕业，能带走的是属于大学 4 年的回忆，难以带走的，是积攒 4 年的行李，一看这阵仗，快递费肯定不便宜。
中间的圆就像催眠师摇摆的钟表，这毕设，是越做越瞌睡……
两耳不闻窗外事，一心只往屏幕钻，这才是一个优秀设计师的优良品质。
设计师：「你好，有什么需要我服务的吗？」
甲方：「需要做一个 logo，目前预算 20」
设计师：「好的，再见」
俗话说得好，做设计不带参考线，都展现不出设计师有多用心。这不，理工学院密密麻麻的参考线，哪个甲方拿到手不会觉得物超所值。
只是辅助线过于密集我看了三遍才看出写的啥。
甲方的心就像一个无底黑洞，你永远不知道他在想啥，他给你的意见也总是在你意料之外。
做设计师，不仅要会动手，还得眼观六路，耳听八方能说会道，还要会「嗅」出空气中的氛围，这才能把甲方爸爸服侍得妥妥帖帖。
每个看向不同方向的眼珠，就像一个项目有好几个甲方，每个甲方都有自己的想法。
艺术，总是得留有一丝丝神秘感才能吸引大家的眼球，就像马赛克后内容总是令人好奇。
除了大陆各大高校毕业展海报外，台湾的毕业展海报也是百花齐放。
作品记得署名，被盗了你都没地儿哭去。
水印打得再满也不如自个儿的脸辨识度高，实际上毕业作品是个 AR 滤镜。
设计就是一场探索，多走几次，就能摸清楚甲方的套路。
选专业前犹豫做什么设计，设计系毕业后：「做什么设计！」
遇到蛮不讲理的甲方，多深呼吸几次忍忍也就过去了。
保持一个乐观的心态，才能发现设计的世界多姿多彩。
你看这从上到下密密麻麻的人海，就像是一次次尝试够到甲方需求，却又一次次失败的你。
看这毕设把孩子逼得这医院看来没少去。
无论何时，回忆起肝毕设的日子，就连软件页面都能浮现在眼前。
当你正式成为设计师你会发现，做多了辣眼睛的设计，你的眼球将会变成消耗品。
纵观今天所有的毕业展的海报设计，有的难以理解，有的让人出乎意料，但唯一可以肯定的是，无论条件多糟糕，哪怕不能像往年，有展馆可给学子们呈现自己的创意，热爱设计的大家，创作的热情，也没有被这场突如其来的疫情浇灭。
虽说有些海报可能不能做到，让所有人满意，但校方也尽力，为同学们搭建了一个可以展现，大学四年学习成果的舞台。
文章来源：优设 作者：你丫才美工
通常产品经理在立项前都要思考需求的实现方式：是原生做？还是 H5 做？
问题的答案会因实际情况有所不同，如果追求体验，那原生效果更好，如果追求短频快，那就选用 H5，或是两者结合。
CCtalk 是个涉及 7 大端的跨平台产品：iOS、Android、PC、Mac、Web、触屏、小程序。我们在日常项目中（尤其是用户增长类的项目）越来越多选择用 H5 实现，然后以低成本适配方式应用到不同客户端。
这样做的好处在于：
降低了开发成本。原本要涉及 iOS、Android、PC（PC 和 Mac 用同一套 Qt 实现）、H5 这 4 个端的开发人员，现在采用内嵌页的方式，可以做到完全不涉及移动端和桌面端，或者仅是入口放置这类比较简单的工作。
降低了维护成本。如果有优化调整，可以只改 H5 页面，不用各个端都动手。
好处显而易见，当然这也不是件一本万利的事。看下面这张 App 和 PC 屏幕尺寸的对比图就明白了，长宽比差异这么大，页面在适配的时候，有时需要优化调整布局。
△ App和PC屏幕尺寸对比
如果要真正做到流畅顺滑的体验，流式布局是最佳选择，但是对设计和开发的要求都很高，维护成本也不小，这让大多数团队望而却步。所以还是自动适配宽度、媒体查询（断点适配）等相对低成本的方式比较香。
如何以低成本的方式做适配？这个问题涉及 2 个方面：框架和页面。
△ 框架和页面
先来看看框架，大致有 4 种：触屏、App、PC、Web。通常一个项目会涉及其中的几种，也有少数情况都涉及。（此文暂不讨论小程序，有机会再写一篇关于小程序设计的文章）
1. App
CCtalk 用的 App 框架容器是公司横向团队提供的 Web View，有 2 种：
常规的导航样式。元素包括：返回、页面标题、分享（根据需要选择展示或不展示）。安卓和 iOS 略有区别，iOS 为了导航栏的顺滑过渡效果，用的是同一个 Web View，所以无法满足在一系列页面中部分页面有分享按钮，部分页面没有分享按钮。安卓用的不是同一个 Web View，所以没有这个问题。（此处不展开讨论）
透明头部导航。常规导航无法满足一些个性化的设计需求，所以透明头部导航就应运而生了。可以对导航栏进行自定义设计，营造沉浸式的体验。
△ 2种头部
2. PC客户端
PC 客户端的框架导航包括：返回上一页，返回首页。页面内嵌时，要留意容器导航和页面导航是否有重复或遗漏。假如要保留页面导航栏，那需隐藏返回按钮；如果去掉页面导航栏，则需将导航栏上原有的操作（例如分享）通过悬浮等方式保留。
△ PC端的全局导航
一般的设计流程是：先设计触屏页面，再去看看 PC、Web 页面是否需要调整。
响应的总原则：提高屏幕利用率。
具体评估标准有 3 点：
页面元素从小到大可分为：控件→组件→模块→页面，按照不同维度的复用，并结合自身的项目经验，整理出 3 种常见的方法（此处是重点，看我看我）。欢迎小伙伴一起讨论补充。
△ 3种常见的适配方法
这种方法最简单，几乎不用动脑子。具体实施方式又分两种：
案例1-拉到指定宽度：
像帖子这类结构简单的内容页一般都可以直接拉伸。注意检查是否有遗漏操作，一般在 PC 端可以采用悬浮按钮的方案将移动端的操作保留。
△ 帖子页
案例2-居中显示，两边留白：
如果页面直接拉伸给用户增加了操作成本，可以采用将主体内容居中，页面两边留白的方式。
实名认证项目是将同一套实名认证流程复用到 3 个不同的使用场景中，所以页面需要适配触屏、web、PC 弹窗 3 个框架尺寸。如果将触屏页直接在 Web 上拉伸，那不仅样式上不美观，而且右侧的「修改」、「获取验证码」等操作按钮距离左侧的标题太远，根据格式塔的接近原理，右侧的一列蓝色操作反而会被误以为是一个整体，脱离和主体的关系，不易于操作。所以我们的做法是放弃拉伸，而是将主体内容居中显示，页面两边留白。
△ 实名认证页
这种方式虽然简单，但也要注意可能会涉及一些细节调整：
如果所有页面都能这么轻松适用于各个不同端，那对设计和开发来说真是省心省力，皆大欢喜。然而现实不会这么顺风顺水，有些页面放到不同的框架内会「水土不服」，这时就需要设计师出马做些调整。
这种调整适用于有图片和列表的页面。从设计层面改动不算大，而且开发量适中，开发也比较能接受。
案例1-排行榜
在课程排行榜项目中，有一个榜单列表页，展示榜单的具体排名和奖励等信息。
如果直接把触屏页面搬到 PC 端，满眼是大写的「丑」，从设计角度分析，用户的阅读负担和操作负担也过重，屏幕利用率低，鼠标滚了半天也没看完一半榜单。
△ 直接拉伸——丑&不好用
所以这个页面需要设计师改造一下才能适配到 PC 端，具体怎么做呢？
我们来分析一下它的页面框架和模块。页面从上到下分为：奖励 Banner、tab 区、列表区和我的排名 4 部分，结构相对来说比较简单，在 PC 端可以保持大的框架结构不变。
△ 页面结构
因为移动端是以纵向为主的屏幕，而 PC 端是宽屏，需要进行调整的模块分别是：奖励 banner区（图片类），其他名次列表（列表类）。对于图片适配，在这个项目中可以采用不同端使用不同比例图片的方案。对于列表适配，在 PC 端由 1 列调整为 2 列，以提升阅读效率。
△ 保持页面框架，调整图片和列表模块样式
案例2-课程售卖页
图片的适配处理，除了采用不同比例的多套图之外，还有另一种方式——保持图片比例不变，调整页面布局。将图片和标题从上下结构改成左右结构。
△ 课程售卖页
小结：
保持页面框架，调整模块内样式的方法适用于结构相对简单，有图片和列表等特殊元素的页面。
对于图片适配，有 2 条思路：
如果页面模块多、结构复杂，靠小改还是会造成阅读障碍和操作负荷，那就要用方法三——模块级复用，重组页面布局。
案例-课时学习页
课时学习页是个多模块的复杂页面，分别有视频播放区、课时基本信息、目录、网师、评价和推荐。整体思路是将页面结构由 1 列调整为左右 2 列，以此来提高屏幕的利用率。
模块的具体位置根据其重要性以及和内容主体的相关度来排布，例如目录：从平台角度希望用内容吸引用户，增加观看时长；从用户角度是需要经常点击切换的，对于这种重要性高又操作频繁的模块，当然应该放在第一屏内。例如推荐：和内容主体的关联度不高，所以优先级低，放在右侧较小的区域内。
△ 课时学习页
在复用模块时，要注意是否有手势操作的场景。如果触屏端有左右滑动的模块，在 PC 端适配有 2 种做法供参考：
另外，要注意浮层的特殊处理。手机端一般通过浮层展示更多信息，在 PC 端适配时，需将浮层调整为固定模块。例如移动端吸底的课程介绍浮层，在 PC 端改成固定在目录下方。
△ 浮层的适配
以上是我结合项目经验总结的 3 种低成本页面适配方法。当然，在具体的适配中还会遇到许多细节问题，需要 case by case 去处理。
文章来源：优设 作者：鱼游设计
你的设计是否能被理解？为什么设计的价值总是不被人认可？本文将从深入浅出，带你了解全局性设计思维的真正力量。
你的设计是否能被理解？为什么设计的价值总是不被人认可？
设计不仅仅只是带来美感，好的设计能够为产品、公司甚至整个社会创造巨大的价值。而在创造好的设计这个过程中，最重要、也是最容易被人忽视的，便是设计思维。
何为全局性设计思维？它能够为设计师带来哪些价值？本文将从设计的本质出发，结合设计的发展趋势，带你了解全局性设计思维的真正力量。
目录
这篇文章的主要内容，来自我在 19 年底的一个沙龙分享。整个分享以设计思维的角度入手，讲述了全局性设计思维的来源和重要性，以及我是如何在不同产品线上去运用这种设计思维的。
何为全局性设计思维？为什么要讲这种思维方式？
这是我一直在探索并实践的一种设计思维。从最开始的理论雏形，到各种项目的实践，不断进行修正和完善，最终形成了一套卓有成效的思维方式。通过这种思维方式，我逐步帮助产品解决了许多长期性的问题，并最终构建了各种不同类型的设计体系。最终，随着品牌矩阵与产品体系的落地，形成了一个完整的网易智慧企业设计体系。
△网易智慧企业设计体系
因为篇幅原因，本篇文章将重点从理论层面阐释全局性设计思维的导论、价值及使用方式。而具体的实战案例，我之后将会以另外几篇单独文章的形式进行展现，并详细讲解在设计过程中的一些细节与过程。希望能够帮助大家更深入地去理解如何根据不同的场景正确地去使用这种思维方式。
未来可能会包含以下几篇文章：
当然，目前的设计体系仅仅只是一个开始，未来还有很长的路要走。
希望本文能够为你带来小小的启发，让设计思维帮助你更好地发挥设计的价值。如果你对某一方面特别感兴趣，可以直接跳到这一章进行阅读，无需浪费过多时间。如果你有任何疑问，也欢迎随时与我交流。
这次把序放在了第二段，这样子看上去就不那么不务正业了哈哈。当然，写序更多的是为了记录生活，希望每一篇文章不仅仅只是传递知识，更是一篇有温度的文章。
整个 2019 年中，经历了很多事情，人生观也随之发生了些许变化。
从并肩作战的同事的不断离去，到逐渐需要考虑团队的发展。从单打独斗闯天下，到思考如何让整个团队更加优秀、如何建立完善的设计体系等等。
角色、心态、责任，以及如何坦然地面对自己。
活在当下，用心生活。这是我一直当作座右铭的语录，也是我希望给自己的承诺。总是试图去尝试这种状态，但却异常艰难。像我这样的人，看上去总是「积极向上」，总是「规划未来」，总是希望事事完美，强迫着每个细节的完善。但不知不觉中，人生好像开始进入了「自动驾驶」的模式，活在了过去的思索中，活在了未来的规划中，唯独对于当下异常麻木。
这并不是我想要的生活，我开始尝试做出改变。
偶然间，通过一些书籍，我开始尝试正念禅修。感受每个呼吸中空气的流动、感受身体的每个部分、感受当下空间发生的每一件事情。虽然只是很浅显的境界，但正念依然对我产生了巨大的影响。我开始重新地审视自己的人生，审视自己的生活状态。
△ 网易蜗牛图书馆：与快乐的小伙伴们
这种感觉，就像再次的呼吸了新鲜空气一样。
我们其实只存在于当下的时空中，过去和未来，并非真实存在的事物。回想一下，我们有多久没有像小时候一样，完完全全、毫无杂念地享受在当下的时光中了？
用心活在当下，平静地接纳一切发生的事物，这种感觉真是太美好了～
对于设计师来说，什么能力更为重要？是设计这门「技术」本身，还是思考如何去设计的「思维」能力？
对于不同的设计师来说，一定会有不同的答案。
这两种能力本身并不矛盾，他们相互影响，互相促进——就像「术」与「道」之间的关系。设计能力决定了设计作品的输出质量，而设计思维则决定了你思考问题、解决问题的能力。
然而，在现实的大环境下，「术」的重视程度远高于「道」，造成了很多设计师与日常业务的「分离感」。以至于，多数的设计师，无法将自己的设计能力有效地用于日常业务中；抱怨他人不理解设计，也因此错失了许多机会。
重视设计美感，其实并没有问题。视觉是最直接的表现方式，我们从最初开始喜欢这个行业，并最终成为设计师，大概都是因为如此。包括我个人，也是美感的追求者，常常为了几像素的细节，调整无数稿。也常常沉浸于自己的作品无法自拔。
但是，美感之后，设计还需要什么？
路易斯·沙利文曾讲过：「形式追随功能」。而功能存在的意义，则在于解决问题。视觉的形式、美感，很多时候只是包裹在外侧的表层，而解决问题才是设计真正的核心。视觉的表现，一定要遵循解决问题的方式，向用户传递恰当的信息，最终引导用户以此来解决问题。
因此，我更希望更多的设计师，在追求美感的同时，能够重拾设计思维本身，寻找设计最根本的价值。
我们其实可以站得更远一些。学会去理解事物，学会用设计去解决问题。再以此为基础，通过你的设计能力去塑造它、点亮它，让它成为一个真正美好而又有价值的设计。
而设计的价值，将会成为你的价值。
互联网时代中的数字产品设计，需要什么样的设计思维？或者说，当下我们需要什么样的设计思维？
这个问题的答案，好像一直在变。
互联网本身便是一个新的形态，1989 年「万维网」发明，1996 年中国引入互联网，到今年已经有大约 24 个年头。我们经历了不同的互联网时期，而「设计」的概念也一直在变化中。
Internet 1.0 PC 互联网时代。在这个时代，我们将大量的信息虚拟化，并通过网络进行信息传递。而我们的「设计师」们大多被称为「美工」，我们的「设计思维」，便是将信息变得更好看。
Internet 2.0 移动互联网时代，或者称为消费互联网时代。自从 2007 年乔布斯发布第一代 iPhone 之后，叠加 4G、wifi 等技术，手机成为日益重要的终端，世界逐渐进入了移动互联网时代。伴随着 iPhone 与其应用的出现，乔布斯让所有人理解了「用户体验」的重要性。我们不再是「美工」，我们变成了「UI 设计师」、「交互设计师」。而这个时代，我们的设计思维变成了「用户体验思维」。
那么，下一个时代在哪里？我们的设计思维又将如何转变，才能适应下一个时代？
1. 红利消失、增长触顶，互联网下半场到来
最近几年，我们已经能够明显地感知到——互联网的「寒冬」真的来了。随之而来的，便是互联网的发展方向似乎也正在发生变化。于是大约从 2017 年开始，互联网圈内逐渐出现一个新的名词——互联网「下半场」。人们普遍认为，中国的互联网将会由消费互联网时代进入下一个时代，即互联网下半场。
我并不完全认同互联网「下半场」的称呼。互联网本身是一个年轻的行业，中国互联网「下半场」，其实更像是互联网发展方向转变的标志。
因此，我们认为的下一个时代的方向，也许将会是 Internet 3.0——即产业互联网时代。
互联网为什么必须要进入下一个时代？
对于互联网企业来说，一方面在成本端，随着人口红利消退，劳动力价格上升，企业的成本将逐渐升高，倒逼管理者使用系统和工具来提率；另一方面，在收入端，野蛮增长的时代结束，增量经济转向存量经济，红利经济转向效率经济。
在「成本」与「效率」的双重压力下，再加上整个市场经济的下行周期，整体经济出现下滑，而一些依靠融资的互联网公司将难以为继。因此企业不得不寻找方法来提升效率，降低成本——而这正是企业级软件（ToB 产品）最擅长的地方。
因此，在互联网寒冬之下，ToB 市场便理所应当地开始被重视。
让我们纵观整个中国市场的发展，互联网的兴起虽然促进了消费领域的蓬勃发展，但产业领域的发展则因此受到了巨大制约。中国率先从消费端、从第三产业开始数字化，然而在第一、二产业的数字化进程似乎并不是很快。一个重要的原因是，人口红利促使了消费互联网的快速发展，而这种红利让人们忽视了产业互联网的重要性。
在寒冬之下，我们终于发现，消费互联网蓬勃的基石，正是底层坚实的产业互联网。产业互联网如果不能得到有效的发展，则整个市场经济将无法更进一步地发展。
因此，产业互联网时代的到来，是中国互联网发展的需要，也将是大势所趋。
2. ToB市场将迎来机遇
产业互联网的发展，需要依托 B 端领域的发展，并逐步融入并带动整个产业进入互联网时代。那么，B 端产品在中国目前处于一个什么阶段呢？
对于整个中国的 ToB 行业发展现状，大多数的人并没有一个清晰的概念。盘点中美上市的科技公司会发现，美国 toC 领域与 toB 领域市值之比是 6:4，但在中国这个数字是 20:1。
虽然互联网的整体环境不同，但中国 ToB 行业的发展，显然是落后太多了。于是乎，2018 年开始，BAT 大举布局，PE、VC 加速进场——中国 B 端产品已经逐渐进入必须发展的时候了。
中国市场已经坐拥全球最发达的消费互联网体系，而产业互联网的发展却严重滞后。
同时，对比 B 端中云计算领域的 IaaS、PaaS、SaaS 三层架构，全球市场中 SaaS 占据了 52.5% 的份额，在中国却是 IaaS 分走了最大的蛋糕，占比达 61.2%。中国市场 VC 的投资总额已经与美国相当，在 SaaS 领域美国企业获得了全球 70.1% 的融资，而中国只有 11.7%。
因此，在互联网下半场，相对于 ToC 行业的触顶，ToB 行业将会迎来历史级的发展机遇，随之而来的将会是产业互联网时代的逐渐到来。而在整个 B 端产品的类目中，SaaS 产品作为企业级软件中最集成的产品，也将随着这股浪潮迎来爆发式的增长。
什么是 SaaS 产品？很多同学并没有接触过 B 端行业，平时用到的也都是 C 端产品，所以对 B 端产品的了解比较少。在 B 端行业最热门的云计算领域中，目前普遍会分为三层架构。SaaS（Software as a Service–软件即服务）；PaaS（Platform as a Service–平台即服务） ；IaaS（Infrastructure as a Service–基础架构即服务）。
附：云计算领域，三种不同的架构与对应的服务。
PaaS 基于 IaaS 实现，SaaS 的服务层次又在 PaaS 之上，三者分别面对不同的需求。越往上层，产品的集成度越高，提供的服务也就越丰富，而用户所需要的自行解决的东西就越少。而最顶层的 SaaS 产品，便是用户可以直接购买并使用的云端产品。
我们为什么要了解这些趋势？
因为一个新的时代，对应一场变革，也将成为一次新的机会。不管是 SaaS 产品还是其他 B 端产品，都将在新的时代中逐渐得到重视。而 C 端产品的发展策略，也将迎来新的变化。对于许多设计师来说，这将会是一个新的机遇。
顺势而为，方能乘势而上。
那么，在逐渐到来的产业互联网时代，设计师需要注意哪些东西？设计思维又将进行如何转变？
产业互联网时代，意味着 B 端产品将得到重视，并与 C 端产品逐渐趋于平衡。因此，了解设计思维的变化，我们首先要从 B 端与 C 端产品之间，在产品设计与产品策略之间的差异性说起。
1. 服务对象的差异性
从服务对象来看，C 端产品的服务对象是人，产品的目标是针对人们生活方式进行的变革、升级。而 B 端产品的服务对象则大多是企业，目标是帮助企业进行商业效率的提升，从而产生价值。
服务对象的差异性，决定了产品在发展策略也将存在着较大的差异性。
2. 产品「打法」上的差异性
从宏观的打法上看，消费互联网时代会更求「快」，而产品互联网时代则会更偏「稳」。
C 端产品的服务对象是人，而人的需求在个体差异性上相对变化较小，这就决定了 C 端产品通常都拥有广阔的用户市场。
因此，消费互联网时代就像是资本在辽阔平原的角逐，长驱直入。讲究快速占领市场，不断地试错、不断地调整。从团购到直播，从打车到短视频领域的兴起，再到最后的单车大战落幕。消费互联网时代的每一次风口，都伴随着各种「游击战」式的竞争。入场速度、快速调整能力、资本深度，都直接影响了最后的结果，而最终的结果也往往是胜者为王，败者将快速地被市场淘汰。
B 端产品的服务对象是企业，而企业间的需求差异性则非常巨大，这就决定了 B 端产品通常需要较强的纵深能力。相对应的，其用户群体在总量上就比较小、但也相对稳固。
因此，产业互联网就像在崎岖丛林的蹒跚前行，渐次演进，如同一场旷日持久的拉锯战。一方面，产业互联网的链条非常长，需要长期的深耕、积累才能逐渐站稳脚跟。而这也导致了产品的壁垒足够深厚，同类产品在短期内无法快速跟进。另一方面，企业间的差距需求的差异性非常大，因此产业互联网存在非常多的细分市场，不同的产品各自在不同的赛道中深耕。而其最终的结果往往是百花齐放，各自盛开。
3. 整体行业的协同发展
虽然整个市场都不断地强调——ToC 增长触顶，ToB 是一片蓝海。但这并非是「取而代之」，而是逐渐走向整体的「协调发展」。中国 ToB 的发展的一个重要根基，其实是「中国拥有世界上最成熟的消费互联网体系」这一巨大的优势。
因此，ToC 在很长的时间内，仍然会是互联网的主力，而 ToC 市场的转型，也将有赖于 ToB 产品所提供的服务。
而随着中国将「互联网+」政策上升为国家战略，更是明确了以互联网带动传统产业的发展方向。因此，互联网的下半场，即产业互联网时代的最终形态，将是互联网与传统行业的「融合式发展」。
ToB 产品将会成为带动互联网下一轮发展的核心驱动力。一方面帮助 ToC 领域完成转型，进入更健康、更稳健的发展阶段；另一方向，ToB 领域赋能传统产业与互联网相融合，并最终完成产业升级。
4. 产品形态的融合与趋同
整体产业的融合趋同，意味着产品的特性也将互相融合。一个很重要的现象是：C 端产品逐渐变得不那么 C 端了，而 B 端产品也越来越变得不像 B 端了。
比如 C 端产品的主流赛道中，随着头部产品的赛道日渐趋于稳定，其产品体量也因为业务扩展而不断增加。同时，因为产品体系的逐渐形成，为了服务更多的 C 端用户，会有越来越多的 B 类用户进入平台，而为了满足 B 类商家的需求，产品的 B 端属性变得越来越强了。
而随着 B 端产品的不断受到重视，原先不被重视的产品 UI、用户体验也逐渐在 B 端产品中得到加强。B 端用户虽然服务于 B 端，但使用者终究是人。而随着竞争的不断加剧，原来的「重功能、轻体验」思路逐渐式微。我们逐渐发现，许多 B 端产品长得越来越像 C 端产品了，甚至在 UI 和体验层面做的与 C 端产品不相上下。
因此，随着产品属性的融合趋同，意味着设计思维势必会与消费者互联网时代存在差异。而我们的设计思维将不仅仅局限在诞生于消费互联网时代的「用户体验思维」。我们需要更新的、更广阔的设计思维，以满足下一个时代的产品发展需要。
那么，新的思维是什么？它将从何而来？
从整个市场的协同发展，到产品形态的融合趋同。那么，我们的设计思维需要如何进行相应的变化？是同样进行「融合趋同」，还是另辟蹊径，寻求新的视角？
1. 关键词提取
首先，不管设计思维如何变化，它一定需要同时满足两种产品设计思维的特性。通过前文的分析，我们可以在产品设计特性的维度，提取各自的关键词进行分析：
产品体验：诞生于消费互联网时代的用户体验思维，在产业互联网时代依然是产品设计中最重要的部分。无论是 C 端还是 B 端产品，用户体验必然是产品的核心竞争力，只有足够好用、好看，产品才能获得更多用户，最终获得商业上的成功。
灵活性：在消费互联网时代，在激烈的竞争中，C 端产品的灵活性的打法对于产品的突围至关重要。而未来的 B 端产品竞争将会加剧，这就需要 B 端产品也逐渐需要较强的灵活性。
成长性：产品的发展必将伴随着不断的变化，特别是具有一定体量之后，产品设计的成长性将至关重要。因此，产品的设计是否能够预见未来发展，满足不断变化的产品形态，伴随着产品不断地成长，也将成为产品是否能够持续获得成功的关键因素。
产品效率：因为产品服务对象的关系，B 端产品一直是产品效率的代名词。而在人口红利消失与经济下行的压力下，产品效率将成为所有企业关注的重要因素之一。产品的效率不仅影响着企业的成本，也是产品竞争力的重要体现。
这四个关键词，将会是我们在未来所需要关注的四个重点关键词。越是往左，则「C」属性越强，因为它更多地从用户的角度出发，更关注用户体验。而越是往右，则「B」属性越强，因为它更多地从企业的角度出发，更关注企业的长期发展。
2. 跳出单一层面，寻求新视角
在四个关键词中，我们会发现，特性越是靠右，其所需要的整体性就越强。要满足灵活性，就需要用户体验与产品策略相关联。要满足成长性，则要进一步结合底层的开发能力。而产品效率的提升，则需要产品的设计与不同层面都有着紧密的耦合。
在互联网设计发展的过程中，我们从单点只关注视觉表层的「美工时代」，逐渐发展为关注线性的「用户体验思维」。在对于产品用户体验层面，确实有着长足的发展。
但是，单一层面的用户体验思维，在逐渐成熟的互联网时代中，逐渐显示出了一定的局限性。我们的价值局限于单一的体验层面，我们似乎无法对产品形成更大的影响力，也难以为产品带来体验之外的更多价值。
因此，设计思维想要满足新时代的需求，就需要同时满足前文提到的四个关键词。这就要求我们需要跳出单一层面，以全局的维度去思考产品的设计。
因此，全局性将成为未来的关键，我暂且将这种思维方式称为——全局性设计思维。
全局性设计思维，即在设计过程中，始终能以更高的维度去审视全局，思考当下的设计。
何以全局，如何跳出单一层面？这种思维方式的前提，是你要首先了解整个产品（亦或是物体、组织等）的运行方式，清楚的知道整个产品需要达到的目标，从而准确、合理地对针对目前的局部做出设计，并最终构成整个完整的形态。
而「全局」的前提，是你拥有更高的眼界。你的眼界越高，你对产品、市场、甚至整个社会的洞察就越全面，你就能够解决越大的问题，你能够实现的价值就越高。眼界是基础，解决更大的问题是目标，而全局性设计思维则是实现这个目标的方式与过程。
全局性设计思维，可以帮助我们跳出产品的单一层面，去思考从产品层、到体验层、再到开发层这一完成的整体。让设计满足体验层的同时，满足产品层面的目标，同时让产品的设计与开发高度耦合，将整个产品串联成一个完成的整体。
好了，讲了这么多，我们具体应该如何去运用全局性设计思维呢？
全局性设计思维，的应用方式非常广泛。它并不是一个固定的方程式，而是一个更高层面的指导性设计思维，能够通过不同的形式，来帮助你解决问题。
1. 全局观——在生活思考更多可能
在尝试这种思维之初，我们可以通过一些小的实践，去锻炼这种思维能力。
在日常的生活、工作中，其实我们有大量的事物可以练习和运用这种思维方式。比如你在装修一个大房子，需要去选择房子里的家具。当你在购买家具时，常规的思维方式是：这个家具在某个房间时应该是怎样搭配的，所以我要购买什么样形状、颜色的家具，来满足这个房间的需要。
但是，用这么思维方式来购买家具，将为对家具的灵活性与长期价值造成一定影响。从居住环境的长远来看，也许这个家具有可能会因为某些原因，需要放到另一个房间，而它的形状、尺寸、配色却无法满足其他房间的需要。最终，我们只能重新购买，或者接受一个风格、尺寸上并不搭调的房间出现。
因此，当我们在购买家具时，我们是否可以利用全局性设计思维，从整体空间的角度出发（而非单个房间），去思考如何让家具满足更多空间需求。长此以往，我们不仅可以打造一个风格统一的大空间，同时也能增加每个家具的利用率，在无形中也增加了这个家具本身的价值。
之所以举家具这个例子，是因为这个原理与产品设计的原理非常类似。你可以将这个房子看成是整个产品，而家具则是不同的组件。通过不同的家具（组件），构成了我们的不同功能模块（房间/功能区），而所有的功能模块则构成了整个产品（房子）。
房子（产品体量）越大，房间/功能区（功能模块）就越多，家具（组件）的多样性、复杂性就越高，我们就越是需要从全局的角度去思考装修的统一性（风格体系化）和家具的通用性（样式组件化）。只有这样，我们才能更好地去打造一个风格统一、体验一致，同时又具备足够自由调整空间的「大房子」。
2. 全链路——从全流程中重新思考设计
当你仔细地去理解许多非常著名的设计作品时。你会发现，几乎所有优秀的、巧妙的设计，往往在设计中都体现了全局性的设计思维。它不仅仅解决着当前的问题，同时也能够解决更大的问题，发挥巨大的价值。
比如著名的坂茂卫生纸的设计，看似普通，只是将卫生纸的轴心从圆形改成了方形，但它却成为了举世闻名的、公认的好的设计。为什么呢？
我们先了解一下这个设计为什么好。
首先，传统的圆形纸卷拉出来的纸会比你实际需要的更多。而方形纸卷则由于阻力的作用，让你用得更少，从而起到了解决资源的作用。其次，在运输过程中，圆形的纸卷之间会产生很大的空隙，而方形纸卷则能够紧紧靠在一起，提升空间利用率，从而起到降低运输成本的作用。
这简单的设计，居然发挥了如此大的作用。
那么，为什么我们在设计时就没有考虑到这些问题呢？因为我们从最开始，就没有从「纸」的整个全流程来去思考问题。
让我们「站的更远一些」，纸这个商品，并非只是我们见到的在商店售卖的那一刻。它从工厂中制造完成，通过运输送到每个超市中，当我们购买以后，它又会在很长一段时间内，出现在卫生间，陪伴你使用的每一刻。我们可以将整个流程分为 3 个场景，而每个不同的场景，又将会对纸本身有着不同的影响。
当我们能够考虑到卫生纸的运输过程时，我们就可以通过设计去降低运输成本；而当我们可以考虑到用户的使用场景时，我们就可以通过设计，去提升阻力，降低使用量，间接地去提升用户的使用体验。而当我们通过全局性设计思维，可以同时解决这三个问题时，我们的设计就是好的设计，就拥有了更高的价值。
发现了吗，为什么你没有想到相同的设计方案？设计能力并不是关键，设计思维才是指引你做出好的设计的前提。当你能按上述的方式，去思考整个流程、不同的场景，我相信大多数的人都能够设计出坂茂的设计方案，甚至比这个方案更好的解决方式。
通过前面的两个案例，相信大家已经了解了全局观、全链路两种应用方式。
那么，我们最最最关心的问题——如何在业务中去使用这种思维呢？
在产品设计中，全局性设计思维也有着非常多样化的使用方式和场景，在之后的文章中我也会讲到很多应用方式。但是，在所有的方式中，我认为最为有效的，便是以全局性设计思维，帮助产品去构建一个完整的设计体系。
什么是设计体系？谈及设计体系，大多数设计师会认为，设计体系就是设计规范。「不就是找个名次包装一下规范嘛？」
我们为什么需要设计体系？它与设计规范有何不同呢？
设计规范是设计师最为熟悉的一种规范文档。在产品设计时，优秀的设计师通常都会建立设计规范。然而在实际的项目中，设计规范往往无法难以有效实施。比如在开发眼中，规范并不符合开发规则，过于碎片化。而产品经理通常又不会去了解设计规范，因此在构建产品框架时也常常随意发挥。
很多项目做到最后，设计规范仅存在于纸面的意义，并随着项目的发展逐渐混乱。为什么会这样？
因为不同职能间的思考方式存在差别，设计规范对于其他职能来说经常难以理解与运用，无法与其他职能形成有效联动。
设计规范仅仅是基于视觉层面的规范，它是一个「平面」。而设计体系则是贯穿于产品的每个层面的、与产品深度结合的完整体系，它是「立体」的「有机生命体」。
设计体系的核心在于「体」，它是贯穿于整个产品的完整体系。设计体系由设计师创造，并深度融合于产品每个部分。它能够让产品更紧密、更统一、更有序，伴随着产品的生长，与产品共同进化，并最终推动产品的发展。
创造并推动这一体系，则要求设计师需要更全面的能力。只有充分地去理解并参与产品的每个部分的设计，才能让设计真正延伸至产品的每个部分。
而创造这一切的前提，便是全局性设计思维。
罗马不是一天建成的，设计体系也是如此。设计体系的建立是一个漫长的过程（与产品体量相关），需要在前期投入更多的精力。但若是你的方法得当，就会在项目中越来越轻松，并以此形成良性循环，而你也会越来越有成就感。
如何正确地去构建设计体系呢？我在这里总结了几个要点：
树立观念
首先，树立长期的体系化意识是必要前提。在任何项目中都要时刻保持体系化思维，着眼于整个项目，去寻找体系化的推动时机。当你在潜意识中拥有这种思维之后，你会自然而然的将其植入到设计中。
以解决问题为导向
体系化并非凭空建立，而是建立在解决问题的基础之上。设计体系的本质，就是由无数个标准化的解决方案，最终构成的一个完整的体系。因此，我们要以解决问题为导向，以全局性思维去思考问题的本质，最终建立适用于全局设计体系。
以小为始，重视质量
脚踏实地，从小处入手，去发现产品中最基础的一些问题。表面上看这些问题，对项目影响不大，但他们数量庞大，加在一起便会严重影响整个产品的效率。因此，我们要首先建立高品质的基础体系，再以此为基础构建更大的体系。
不要一开始就设法建立一个巨大的体系，那样只会是一盘散沙，因为它的结构是无序、混乱、不健康的。而这也是大多设计规范缺乏有效性和可实施性的根源。
梅拉妮·米歇尔的《复杂》一书中讲到，任何复杂系统，都是由无数个体通过简单的算法所构成的。在算法领域也是同样的原理，一个优秀而强大的代码，必然是由无数个小型模块，通过简单的算法耦合形成巨大的代码矩阵。基础算法越强大、代码结构越「健康」，可扩展性和灵活性就越强，其能力就越强大。
从规范入手，由面到体
从本质上来说，设计体系是由「多个层面的规范」组合而成的。因此，由设计师推动的体系化建设，往往最初都是从设计规范这一「单层规范」开始。但是，设计体系的建设需要将单层的规范，通过不同的方式，转化为不同层面的规范，最终由面到体，形成体系化。
换位思考，寻求跨职能合作
设计体系的建立与维护，通常需要多职能的通力协作。因此，我们需要经常换位思考，在完成设计的工作，帮助其他职能完成目标。只有这样，才能得到更多的信任，并以此为基础推动更多体系化的建设。
比如我在设计一个功能模块的页面时，首先会与不同模块产品经理进行交流，了解不同的业务需求，并从产品层面就开始寻求统一性与通用性。这样的话，当其他模块需要同一个功能时，前端便可以直接复用，同时后端的数据也可以进行互通。而在开发端，我也会详细了解不同端的开发实现原理，务求设计规范与开发规则在理解上的一致性。这一既方便了开发理解规范，同时也从根本上提升了开还原的准确性。
长此以往，整个团队就能够建立良好的沟通和互信关系。有了这种默契，设计体系的推动就容易多了。
保持优化，不断成长
设计体系的另一个重要价值在于，它是可以伴随产品不断成长的。所有产品都是在发展中不断变化的，过分僵硬的规则，将会对产品发展起到反作用。
在业务发展中，产品一定会不断地加入新的功能模块，并对原有页面作出相应的调整。因此，设计体系需要时刻与产品策略保持一致，及时与上下游职能沟通，不断地针对产品发展进行优化，以保证设计体系能够符合产品的发展需要。
使用正确的推动方式
体系化最终能否成功实施，推动的方式至关重要。
在日常的项目中，大多数的业务方对设计体系了解甚少，也难以体会其中的价值。因此，他们通常会认为这些东西毫无必要，多数情况也不太愿意配合体系的推进。如果强行推进，反而会引起不必要的阻力，招致反感。那么，我们应该如何正确的去推进设计体系建设呢？
为他人带来价值：首先，寻找双方共同的利益点是首要任务。也许是可以让其他职能的工作更，也许能够促使其达成 KPI，再不直接，那也一定能够为整个产品带来价值（不然你也没必要推了）。总之，设计体系一定要能够为他人带来价值，这样才能顺利推进。否则人家凭什么要协助你推进，因为你美丽可爱吗？你也可能比较可爱，但总归是不能一直这么来吧。
在解决问题后提出方案：不要一开始就啪一下抛出一个「宏大的理想」，大部分人会觉得你不切实际。你只需要通过这个体系，帮助业务方先解决一个问题，然后再提出你解决方式的来源——一个严谨的、可验证的、长远价值的体系化解决方案。
寻找合适的推动时间：最后，对于设计体系来说，寻找到正确、恰当的推进时机至关重要。比如当你在平时突然想要提出，对现有品牌进行升级时，大多数业务方都会认为你是没事找事。而如果情况是在新的一年中，产品进行了概念的升级，这时候你将概念以及未来的品牌规划融入在你的方案中，再去推进品牌升级，就会容易很多了。
-本文旨在引导大家更好地理解和学习这种思维方式，想要用好全局性设计思维，光靠讲是远远不够的。最重要的是能将这种思维带入到产品中，为业务带来更大的价值。
因此，在后续的几篇文章中，我将通过不同类型案例，为大家深入讲解全局性的具体实践案例。
全局性设计思维 | 如何打造强大的品牌体系
为什么要建立品牌体系？品牌体系有哪些价值？设计师应该如何推动品牌体系的建立？
本文将带你了解网易智慧企业品牌体系的建设与推动全过程，聊一聊品牌体系建设的那些事儿～
FishDesign组件库 | 从零到一构建企业级UI组件库
我们为什么要建立组件库？在产品的什么阶段需要组件库？如何抽象业务组件？组件库设计过程中有哪些重要的细节需要注意？
本文带你深入了解，网易 Web 端组件库——FishDesign 组件库从零到一的完整全过程。
全局性设计思维 | 如何构建事业部级大型设计体系
设计体系有什么价值？如何基于不同的业务建立设计体系？设计师如何推动体系化建设？在体系化过程中有哪些需要注意的地方？
我将会在这篇文章中，为大家介绍网易智慧企业设计体系构建全过程。
样式组件化+规范体系化，形成产品设计体系，整体重构产品线。
结合品牌体系，推动事业部更多产品加入体系，形成智慧企业 Web 端产品设计体系。
推动更多产品/业务融入体系中，让智慧企业设计体系不断成长，赋能业务发展。
好吧，似乎文章又写得偏长了一些。只能说，想要认真地讲清楚一个道理，确实不是一件容易的事情。
设计思维本身并不复杂，但想要讲清楚它的背景、原理及价值，就需要把它整个掰开来讲。而为了确保设计思维的可实施性，又需要经过大量的实践研究，自己能够走通以后，才能与大家分享。
坦白讲，似乎整个社会都在追求快节奏、碎片化阅读。但若是因此而丧失了自己学习的节奏，那么等于是没有节奏的，你的知识体系也将是东拼西凑，无法形成一套完整的体系。这也是我更新比较慢的原因之一，希望大家读完文章，能够切实地得到一些东西，这就很有意义。
文章来源：优设 作者：Jady13
QQ 游戏中心经过设计改版之后，我们重新设定了整体的世界观——多彩的游戏宇宙。并且对多个模块及内容进行了新的设计升级，其中也包括重要的图标图形。
1. 延展思考
因此基于目前较为完整的图标图形，希望可以拓展出更多不一样的设计内容，并且可以应用在不同的位置，例如空白页、运营内容、背景等等。
2. 问题分析
基于目前的图形可以很明显的得到 2 个问题：
3. 设计启发
3D作为 2020 的主流设计趋势之一，可以很好地表达设计氛围。因此想尝试跨次元的设计方式，从 3D 图形的角度去思考，尝试更多可能性。
下面主要是分享我在制作 3D 图标中的一些方法和流程，以及 2D 与 3D 图形设计中思考的差异性，希望可以跟大家互相学习，一起探讨这方面的设计。
虽然是 3D 的图标，但实际上使用到的软件包括有：Cinema 4D（C4D）、Sketch、Photoshop（PS）、illustrator（AI）。
整体的大概流程：
3D 与 2D 最大的差别在于多一个维度来表达图形，因此我们在 2D 向 3D 转化的过程中，需要思考一些基本的原则，并且结合这些规则，降低 3D 图标与 2D 图标违和感。在这次的 3D 图标中我总结了以下几条基本规则。
1. 圆变球
在 3D 软件中表达圆有 2 种方式：球体、圆柱体。在实际的设计中，我们需要根据实际情况判断是否变成球体或者圆柱体，这里建议单体呈现的圆形设计成球体，在这种情况下球体相比圆柱体更能表达圆形的视觉感受。
例如下面气泡的例子，球体化的表现比圆柱体化的表现更加饱满，光影效果更加丰富。
2. 方变块
与上面的规则比较接近。当我们在 2D 图标中使用矩形之类的图形，建议使用立方体来表达。优点：立方体可以增加图标上的细节表现；增加厚度更有利于光影的表达。
例如下面礼物的图标，我们在实际的 3D 场景下应该更贴合现实生活中的认知，设计成礼物盒子的效果。
3. 结合实际认知
除以上的 2 种建议之外，我们在实际建模的时候还需要结合实际认知而定。例如金币、游戏卡的设计应该是带有厚度的片形；钱包设计成折叠的效果。
4. 适当简化图形
2D 图标向 3D 图标的转换过程中，需要适当进行简化，一些不必要的内容可以适当进行删减。主要的目的是：
5. 增强空间思维
2D 的图标只有一个平面，因此大部分情况下是一种「纸片性」的思维，常规的 2D 向 3D 的转换思维是增加厚度，但实际上出来的效果并不理想。因此在转换的过程中，需要使用空间的思维去思考，在 3 维的空间中应该是怎么样的。例如下载和收件箱的图标，常规的思维可能是在 2D 的图标上增加厚度，但转换成空间思维就是让其具有立体感和空间感的形体。
6. 图标状态补充
在实际建模的中会发现，很多模型在静态下是可以进行简单处理的，但结合动态或实际认知，就需要相关细节状态补充。例如礼物和宝箱图标的开盖效果，因此把实际的盖子和盒子/箱子的模型做出来，以便于动画的实际表达。
在进入 C4D 之前，需要清楚不同图形可以使用什么方式建模，因此我们可以进行一个简单的分类，分为：常规图形和异形。两种图形在建模中的方式会有一些小差异，当然一个图标也可能包含这两种类型，因此实际操作中可以灵活处理。
1. 常规形：使用基础物体建模
部分简单的有规则的图形，可以直接使用 C4D 的基础物体（例如：立方体、球体、柱状体、锥体等），通过对基础物体的调整后得到模型，例如下面的图形。
案例展示
2. 异形：AI路径+挤出
在实际操作的过程中发现部分模型较难通过基础形调整得到，或是直接建模会比较耗时。因此我们可以导入 AI 路径再挤出的方式来得到我们的模型。例如下面的图形
案例展示
基于以上的以上 2 种类型的图形，这里分享一下制作的过程和心得。可能不够全面，但希望大家可以一起来补充互相学习。
1. 对齐中心点
基础建模对齐中心轴点是一切开始的重中之重，这里会涉及到很多后续的调整和其他命令的应用（例如挤出、对称等命令）。例如一些中高阶的人物建模也是非常依赖中心点对齐来实现对称命令的。
2. 结合图像
在 C4D 视图本身具有多视图，可以结合不同视图导入不同视角的平面结构进行制作，常见情况下的建模可以导入三视图（例如角色、人物之类的）。而图标相对来说是很简单的，所以这里只应用正面视图即可，其他的视角可以自行脑补后制作。
结合图像的好处：
操作流程：正视图下快捷键 shift+V 调出视图背景——选择背景——添加图像。或在视图选项中调出，然后配置即可。
3. 结合路径
如上图标类型中的描述，部分异形的图标如果直接在 C4D 中绘制会相对耗时，因此我们可以结合路径的方式，再使用挤出的命令来实现我们想要的模型，这样可以大大提升异形物体建模的效率。
C4D 中对 AI 的图层只会读取颜色的边缘，然后生成路径。因此在 AI 中编辑的路径，依据实际的情况选择填充或者描边，然后再拖拽进 C4D。如下产生的效果对比，左边为填充图形，右边为描边图形。
操作流程：使用 AI 导出 8.0 版本的路径——拖拽进 C4D——添加挤出命令——设置挤出高度及封顶样式。
4. 使用变形器
一些简单的形变可以通过变形器的应用，得到我们想要的造型。例如下面的案例，外星人脸是在圆形的基础上使用 FFD 进行调整，而宝箱则在方形的基础上使用锥化来达到圆弧的效果。
C4D 的渲染效果主要是依赖于材质和灯光的配合，熟练者往往可以依靠经验有效率的制作，但我们也可以通过锻炼总结出一些常用的材质参数或者布光的位置来提率。因此我也从这次的 3D 图标制作中总结了一套关于材质和布光的方法。
C4D 场景的主光源我们可以通过全局光照+天空的方式来营造整体的氛围，这组光的特点在于具有比较柔和的效果，并且模拟自然的环境光效。
全局光照开启后，需要依赖灯光、天空光来对物体进行照射，如果设定后未增加灯光或者天空，在渲染时只能渲染出一片黑色。（全局光照——主要是模拟真实的光照效果，通过光源投射到物体上再经过无数次的反射和折射出来的效果，因此也能解释为什么只加全局光照渲染不出来内容。）
操作流程：渲染设置——效果——全局光照
添加天空增加天空作为基础光照补充
操作流程：地面快捷入口——选择天空——添加材质球——勾选发光——添加 HDR 贴图。
下面通过一些案例对比来看看全局光照及天空的对比效果
全局光照-开和关的差异
从下面的案例我们可以明显看到差别，全局光照关闭后的图标相对暗淡一些，整体图标的光反射也相对减弱了许多。
有无天空的差异
天空有助于增强图标的光感，添加天空后整体图标的细节和质感也相对更加丰富。相对，无天空整体图标质感则有所下降。
天空是否增加HDR贴图的差异
添加 HDR 贴图可以增强场景内物体的环境反射，让物体材质更加丰富增强细节质感。在一些强反射的场景下非常依赖 HDR 贴图的使用。从以下案例对比，可以明显看到差异性。
整体添加三盏灯光来营造整体的场景氛围。主要分为：主光（最强）、补光（增强阴影面的亮度）、背光（补充背面环境的光源，增强环境光氛围，勾勒轮廓）。在实际的场景中可以根据实际的反射效果和氛围，调整灯光的位置、与物体的间距、明暗度。
灯光对于物体的作用会随着颜色的差异，产生的光亮度也会有所差异，因此在实际的使用过程中，对于灯光的位置、反射的细节都可以进行微调来达到最优的效果。
色相的对比：不同色相在同样的灯光作用下产生的效果具有稍微较小。
明暗的对比：深色和浅色在同样的灯光作用下产生的效果差别较大。
实际案例对比：从下面的实际案例对比可以明显看出同样灯光下不同色相的明显差别，绿色的两部产生过度曝光。因此可以通过调整灯光的距离或者亮度来解决这一问题（如上面灯光分布建议）。
3D 图标由于相对简单，材质上主要使用颜色和反射的配合就可以得到不错的质感。当然如果希望在质感表现上更加丰富，亦可考虑增加其他的内容项来进行补充
颜色的设定
图标的颜色基本上与原图标的颜色保持一致，但部分颜色但实际渲染效果会存在些许差异，因此我们在材质上也可以根据视觉效果进行微调，视觉上保持统一的颜色感受。例如礼物的图标，如果按原来的颜色，亮部会过渡曝光，因此适当提高了亮部颜色的饱和度。
颜色偏差
在 3D 的场景内是通过各种光与颜色的反射而成的，因此即便同样的颜色，在实际渲染出来的 3D 图标和 2D 图标也会存在一定颜色偏差。
反射是本次 3D 图标中材质非常重要的一环，基本的效果都是来源于对反射的设定。整体主要设定了反射的类型、粗糙度、反射强度、高光强度、层遮罩的颜色。由于图标的颜色并不完全一致，因此在粗糙度、反射强度、高光强度是一组动态的参数。
参数变化的对比
如下面的案例，针对不同颜色的图标在粗糙度、反射强度、高光强度上都有差异性，因此不是说设定好一组参数之后就那个完全适用所有的颜色，因此这里会根据实际情况调整，但整体的视觉效果保持一致。
层遮罩的设定差异
除了基础的反射类型及参数，还需要在层遮罩中添加菲涅耳来增强反射的丰富度。默认的菲涅尔是一组黑白的颜色材质，我们可以通过调整暗部的颜色来增强图标的颜色饱和度和丰富度，如下案例对比。
静态的 3D 图标显得精致，增加动效之后的 3D 图标则除精致外，还更加富有趣味性和新鲜感。3D 的动效与 2D 有着明显的差别，可以更多维度地思考物体的运动轨迹、变化方式。
首先我们需要根据不同造型对需要制作动效的图标进行简单的分类，这个分类的主要作用在于明确不同图标的动效设计方式，为动效的设计方式进行铺垫。根据已有的图标划分为：单体形、组合型、拼装形。
单体形
图标以单个或单组形体呈现，或者整体造型属于某个已存在的事物或者形体，整体图形内容具有不可切割性。
组合型
图标通过两组或两组以上的图形内容组合而成，图标由主形（图标实际的外轮廓造型）和点缀图形（用于图标表意或者提升图形内涵）组合而成的图标，图标可进行拆分或者重组后形成动效。
拼装形
图标本身可能在现实中不存在的事物或物体，通过创意思考而得到的图形，图标的动效更具有可发散性和可重塑性。
结合上面的类型差，在设计动效的时候也会稍稍不同。重点在于表达不同的图标具有的特性，因此我们可以根据这些特性去设计图标的动画方式。
自体运动
对应单体图形，图标动效通过自身的位移、旋转、形变而产生，这类图标的动效比较靠近现实生活中接触的感知或图形动效本身具有普适性认知。例如火箭升空、UFO 飞碟、放礼炮、开宝箱等。
组合运动
对应组合图形和拼装图形，多图形运动组合而成，图标的多个部件可从不同轴向开始进行不同的轨迹运动，最终进行完整的图标融合。各个部件本身可能也存在位移、旋转、形变等动效，可以更大程度丰富图标的动效表现。
部件运动
整体动效相比前面两种类型较为简单，通过某个图标上的部件运动来表达动效的内容，因此这个部件需要是图标上较为明显的图标特征，这样更能让人具有记忆点。
音效是这次 3D 图标设计的点睛之笔，结合音效可以更加丰富地表达图标动效的趣味性。不同的图标动画反馈出来的音效是不一样的，因此赋予对应的音效反馈才是更合理的表达。
1. 选择音效
在实际的配置音效的过程中发现，部分图标比较难找到相关联的音效。但我们可以通过较为类似或者可以表达出该图标动画过程中的声音反馈的音效。例如活动小礼炮用的是开葡萄酒塞的声音，开宝箱用的是开门的声音，飞碟（UFO）用的是一组电子音效等等，并且从相关声音中窃取其中一段需要的。
2. 组合音效
部分图标的动画效果很难通过一条音效进行表达，因此需要叠加 2 组或者 2 组以上的音效来丰富整体的感受。例如手柄人图标叠加了三组不同的音效来表达，游戏卡叠加 2 种不同的音效。
3D 的图标或 3D 类型的内容如何与 UI 结合？相信大家也时有思考这方面的内容。基于这次的 3D 图标设计，我也进行了初步的尝试，从几个方面来简单聊聊这方面的内容。
1. 3D图标对于UI设计的作用
在尝试之前，我们需要明确 3D 内容对于 UI 设计作用是什么？我简单总结了几个关键点：
2. 3D ICON X Tab bar
当我们设计 Tabbar 的时候，首先想到的表现方式往往是有趣的图标图形设计、结合动效之类的方式。但我们或许也可以考虑使用 3D 的图标+动画的方式来表达我们的设计。
3. 3D ICON X 运营内容
一些相对简单的运营内容，我们可以考虑将元素进行 3D 化设计，这样可以一定程度增强整体运营的视觉表现力。
4. 3D ICON X 空白页插图
3D 插图是 2020 的设计趋势之一，结合 3D 的插图让整体的设计更加具有氛围感。
5. 3D ICON X COVER
将背景中的某些元素结合 3D 图形进行设计，让整体的氛围更加具有空间感和立体感。
本次结合实际项目中的内容进行不同维度的设计尝试，并且希望，可以从中去寻找到更多设计的可能性和突破点。当然这只是系统化设计思考中的一步，但可以启发后续更加深入的 3D 设计探索。
文章来源：优设 作者：ID设计站
前言
前面几篇我们就 Redux 展开了几篇文章，这次我们来实现 react-thunk，就不是叫实现 redux-thunk 了，直接上源码，因为源码就11行。如果对 Redux 中间件还不理解的，可以看我写的 Redux 文章。
实现一个迷你Redux（基础版）
实现一个Redux（完善版）
浅谈React的Context API
带你实现 react-redux
为什么要用 redux-thunk
在使用 Redux 过程，通过 dispatch 方法派发一个 action 对象。当我们使用 redux-thunk 后，可以 dispatch 一个 function。redux-thunk会自动调用这个 function，并且传递 dispatch, getState 方法作为参数。这样一来，我们就能在这个 function 里面处理异步逻辑，处理复杂逻辑，这是原来 Redux 做不到的，因为原来就只能 dispatch 一个简单对象。
用法
redux-thunk 作为 redux 的中间件，主要用来处理异步请求，比如：
export function fetchData() {
return (dispatch, getState) => {
// to do ...
axios.get('https://jsonplaceholder.typicode.com/todos/1').then(res => {
console.log(res)
})
}
}
redux-thunk 源码
redux-thunk 的源码比较简洁，实际就11行。前几篇我们说到 redux 的中间件形式，
本质上是对 store.dispatch 方法进行了增强改造，基本是类似这种形式：
const middleware = (store) => next => action => {}
在这里就不详细解释了，可以看 实现一个Redux（完善版）
先给个缩水版的实现：
const thunk = ({ getState, dispatch }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState)
}
return next(action)
}
export default thunk
原理：即当 action 为 function 的时候，就调用这个 function (传入 dispatch, getState)并返回；如果不是，就直接传给下一个中间件。
完整源码如下：
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) => next => action => {
// 如果action是一个function，就返回action(dispatch, getState, extraArgument)，否则返回next(action)。
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}
// next为之前传入的store.dispatch，即改写前的dispatch
return next(action)
}
}
const thunk = createThunkMiddleware()
// 给thunk设置一个变量withExtraArgument，并且将createThunkMiddleware整个函数赋给它
thunk.withExtraArgument = createThunkMiddleware
export default thunk
我们发现其实还多了 extraArgument 传入，这个是自定义参数，如下用法：
const api = "https://jsonplaceholder.typicode.com/todos/1";
const whatever = 10;
const store = createStore(
reducer,
applyMiddleware(thunk.withExtraArgument({ api, whatever })),
);
// later
function fetchData() {
return (dispatch, getState, { api, whatever }) => {
// you can use api and something else here
};
}
总结
同 redux-thunk 非常流行的库 redux-saga 一样，都是在 redux 中做异步请求等副作用。Redux 相关的系列文章就暂时写到这部分为止，下次会写其他系列。
一、前言
前端的模块化规范包括 commonJS、AMD、CMD 和 ES6。其中 AMD 和 CMD 可以说是过渡期的产物，目前较为常见的是commonJS 和 ES6。在 TS 中这两种模块化方案的混用，往往会出现一些意想不到的问题。
二、import * as
考虑到兼容性，我们一般会将代码编译为 es5 标准，于是 tsconfig.json 会有以下配置：
{
"compilerOptions": {
"module": "commonjs",
"target": "es5",
}
}
代码编译后最终会以 commonJS 的形式输出。
使用 React 的时候，这种写法 import React from "react" 会收到一个莫名其妙的报错：
Module "react" has no default export
这时候你只能把代码改成这样：import * as React from "react"。
究其原因，React 是以 commonJS 的规范导出的，而 import React from "react" 这种写法会去找 React 模块中的 exports.default，而 React 并没有导出这个属性，于是就报了如上错误。而 import * as React 的写法会取 module.exports 中的值，这样使用起来就不会有任何问题。我们来看看 React 模块导出的代码到底是怎样的（精简过）：
...
var React = {
Children: {
map: mapChildren,
forEach: forEachChildren,
count: countChildren,
toArray: toArray,
only: onlyChild
},
createRef: createRef,
Component: Component,
PureComponent: PureComponent,
...
}
module.exports = React;
可以看到，React 导出的是一个对象，自然也不会有 default 属性。
二、esModuleInterop
为了兼容这种这种情况，TS 提供了配置项 esModuleInterop 和 allowSyntheticDefaultImports，加上后就不会有报错了：
{
"compilerOptions": {
"module": "commonjs",
"target": "es5",
"allowSyntheticDefaultImports": true,
"esModuleInterop": true
}
}
其中 allowSyntheticDefaultImports 这个字段的作用只是在静态类型检查时，把 import 没有 exports.default 的报错忽略掉。
而 esModuleInterop 会真正的在编译的过程中生成兼容代码，使模块能正确的导入。还是开始的代码：
import React from "react";
现在 TS 编译后是这样的：
var __importDefault = (this && this.__importDefault) || function (mod) {
return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
var react_1 = __importDefault(require("react"));
编译器帮我们生成了一个新的对象，将模块赋值给它的 default 属性，运行时就不会报错了。
三、Tree Shaking
如果把 TS 按照 ES6 规范编译，就不需要加上 esModuleInterop，只需要 allowSyntheticDefaultImports，防止静态类型检查时报错。
{
"compilerOptions": {
"module": "es6",
"target": "es6",
"allowSyntheticDefaultImports": true
}
}
什么情况下我们会考虑导出成 ES6 规范呢？多数情况是为了使用 webpack 的 tree shaking 特性，因为它只对 ES6 的代码生效。
顺便再发散一下，讲讲 babel-plugin-component。
import { Button, Select } from 'element-ui'
上面的代码经过编译后，是下面这样的：
var a = require('element-ui');
var Button = a.Button;
var Select = a.Select;
var a = require('element-ui') 会引入整个组件库，即使只用了其中的 2 个组件。
babel-plugin-component 的作用是将代码做如下转换：
// 转换前
import { Button, Select } from 'element-ui'
// 转换后
import Button from 'element-ui/lib/button'
import Select from 'element-ui/lib/select'
最终编译出来是这个样子，只会加载用到的组件：
var Button = require('element-ui/lib/button');
var Select = require('element-ui/lib/select');
四、总结
本文讲解了 TypeScript 是如何导入不同模块标准打包的代码的。无论你导入的是 commonJS 还是 ES6 的代码，万无一失的方式是把 esModuleInterop 和 allowSyntheticDefaultImports 都配置上。
初始化
使用 https://github.com/XYShaoKang... 作为基础模板
gatsby new gatsby-project-config https://github.com/XYShaoKang/gatsby-hello-world
Prettier 配置
安装 VSCode 扩展
按 Ctrl + P (MAC 下: Cmd + P) 输入以下命令,按回车安装
ext install esbenp.prettier-vscode
安装依赖
yarn add -D prettier
Prettier 配置文件.prettierrc.js
// .prettierrc.js
module.exports = {
trailingComma: 'es5',
tabWidth: 2,
semi: false,
singleQuote: true,
endOfLine: 'lf',
printWidth: 50,
arrowParens: 'avoid',
}
ESLint 配置
安装 VSCode 扩展
按 Ctrl + P (MAC 下: Cmd + P) 输入以下命令,按回车安装
ext install dbaeumer.vscode-eslint
安装 ESLint 依赖
yarn add -D eslint babel-eslint eslint-config-google eslint-plugin-react eslint-plugin-filenames
ESLint 配置文件.eslintrc.js
使用官方仓库的配置,之后在根据需要修改
// https://github.com/gatsbyjs/gatsby/blob/master/.eslintrc.js
// .eslintrc.js
module.exports = {
parser: 'babel-eslint',
extends: [
'google',
'eslint:recommended',
'plugin:react/recommended',
],
plugins: ['react', 'filenames'],
parserOptions: {
ecmaVersion: 2016,
sourceType: 'module',
ecmaFeatures: {
jsx: true,
},
},
env: {
browser: true,
es6: true,
node: true,
jest: true,
},
globals: {
before: true,
after: true,
spyOn: true,
__PATH_PREFIX__: true,
__BASE_PATH__: true,
__ASSET_PREFIX__: true,
},
rules: {
'arrow-body-style': [
'error',
'as-needed',
{ requireReturnForObjectLiteral: true },
],
'no-unused-expressions': [
'error',
{
allowTaggedTemplates: true,
},
],
'consistent-return': ['error'],
'filenames/match-regex': [
'error',
'^[a-z-\\d\\.]+$',
true,
],
'no-console': 'off',
'no-inner-declarations': 'off',
quotes: ['error', 'backtick'],
'react/display-name': 'off',
'react/jsx-key': 'warn',
'react/no-unescaped-entities': 'off',
'react/prop-types': 'off',
'require-jsdoc': 'off',
'valid-jsdoc': 'off',
},
settings: {
react: {
version: '16.4.2',
},
},
}
解决 Prettier ESLint 规则冲突
推荐配置
安装依赖
yarn add -D eslint-config-prettier eslint-plugin-prettier
在.eslintrc.js中的extends添加'plugin:prettier/recommended'
module.exports = {
extends: ['plugin:prettier/recommended'],
}
VSCode 中 Prettier 和 ESLint 协作
方式一:使用 ESLint 扩展来格式化代码
配置.vscode/settings.json
// .vscode/settings.json
{
"eslint.format.enable": true,
"[javascript]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint"
},
"[javascriptreact]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint"
}
}
ESLint 扩展会默认忽略.开头的文件,比如.eslintrc.js
如果需要格式化.开头的文件,可以在.eslintignore中添加一个否定忽略来启用对应文件的格式化功能.
!.eslintrc.js
或者直接使用!.*,这样可以开启所有点文件的格式化功能
方式二:使用 Prettier 扩展来格式化代码
在版prettier-vscode@v5.0.0中已经删除了直接对linter的集成,所以版没法像之前那样,通过prettier-eslint来集成ESLint的修复了(一定要这样用的话,可以通过降级到prettier-vscode@4来使用了).如果要使用Prettier来格式化的话,就只能按照官方指南中的说的集成方法,让Prettier来处理格式,通过配置在保存时使用ESlint自动修复代码.只是这样必须要保存文件时,才能触发ESLint的修复了.
配置 VSCode 使用 Prettier 来格式化 js 和 jsx 文件
在项目中新建文件.vscode/settings.json
// .vscode/settings.json
{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
}
说实话这个体验很糟糕,之前直接一键格式化代码并且修复 ESLint 错误,可以对比格式化之前和格式化之后的代码,如果感觉不对可以直接撤销更改就好了.现在必须要通过保存,才能触发修复 ESlint 错误.而在开发过程中,通过监听文件改变来触发热加载或者重新编译是很常见的操作.这样之后每次想要去修复 ESLint 错误,还是只是想看看修复错误之后的样子,都必须要去触发热加载或重新编译,每次操作的成本就太高了.
我更推荐第一种方式使用 ESLint 扩展来对代码进行格式化.
调试 Gatsby 配置
调试构建过程
添加配置文件.vscode/launch.json
// .vscode/launch.json
{
// 使用 IntelliSense 了解相关属性。
// 悬停以查看现有属性的描述。
// 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Gatsby develop",
"type": "node",
"request": "launch",
"protocol": "inspector",
"program": "${workspaceRoot}/node_modules/gatsby/dist/bin/gatsby",
"args": ["develop"],
"stopOnEntry": false,
"runtimeArgs": ["--nolazy"],
"sourceMaps": false,
"outputCapture": "std"
}
]
}
的gatsby@2.22.*版本中调试不能进到断点,解决办法是降级到2.21.*,yarn add gatsby@2.21.40,等待官方修复再使用版本的
调试客户端
需要安装 Debugger for Chrome 扩展
ext install msjsdiag.debugger-for-chrome
添加配置文件.vscode/launch.json
// .vscode/launch.json
{
// 使用 IntelliSense 了解相关属性。
// 悬停以查看现有属性的描述。
// 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Gatsby Client Debug",
"url": "http://localhost:8000",
"webRoot": "${workspaceFolder}"
}
]
}
先启动 Gatsby,yarn develop,然后按 F5 开始调试.
收集了一些工作中常用的工具。
如果你有好用的工具或者有意思的工具网站，要留言哦！
React是Facebook开发的一款JS库，那么Facebook为什么要建造React呢，主要为了解决什么问题，通过这个又是如何解决的？
从这几个问题出发我就在网上搜查了一下，有这样的解释。
Facebook认为MVC无法满足他们的扩展需求，由于他们非常巨大的代码库和庞大的组织，使得MVC很快变得非常复复杂，每当需要添加一项新的功能或特性时，系统的复杂度就成级数增长，致使代码变得脆弱和不可预测，结果导致他们的MVC正在土崩瓦解。认为MVC不适合大规模应用，当系统中有很多的模型和相应的视图时，其复杂度就会迅速扩大，非常难以理解和调试，特别是模型和视图间可能存在的双向数据流动。
解决这个问题需要“以某种方式组织代码，使其更加可预测”，这通过他们(Facebook)提出的Flux和React已经完成。
Flux是一个系统架构，用于推进应用中的数据单向流动。React是一个JavaScript框架，用于构建“可预期的”和“声明式的”Web用户界面，它已经使Facebook更快地开发Web应用
对于Flux，目前还没怎么研究，不怎么懂，这里就先把Flux的图放上来，有兴趣或者了解的可以再分享下，这里主要说下React。
那么React是解决什么问题的，在官网可以找到这样一句话：
We built React to solve one problem: building large applications with data that changes over time.
构建那些数据会随时间改变的大型应用，做这些，React有两个主要的特点：
另外在React官网上，通过《Why did we build React?》为什么我们要建造React的文档中还可以了解到以下四点：
Virtual DOM 虚拟DOM
传统的web应用，操作DOM一般是直接更新操作的，但是我们知道DOM更新通常是比较昂贵的。而React为了尽可能减少对DOM的操作，提供了一种不同的而又强大的方式来更新DOM，代替直接的DOM操作。就是Virtual DOM,一个轻量级的虚拟的DOM，就是React抽象出来的一个对象，描述dom应该什么样子的，应该如何呈现。通过这个Virtual DOM去更新真实的DOM，由这个Virtual DOM管理真实DOM的更新。
为什么通过这多一层的Virtual DOM操作就能更快呢？ 这是因为React有个diff算法，更新Virtual DOM并不保证马上影响真实的DOM，React会等到事件循环结束，然后利用这个diff算法，通过当前新的dom表述与之前的作比较，计算出最小的步骤更新真实的DOM。
component 的使用在 React 里极为重要, 因为 components 的存在让计算 DOM diff 更。
State 和 Render
React是如何呈现真实的DOM，如何渲染组件，什么时候渲染，怎么同步更新的，这就需要简单了解下State和Render了。state属性包含定义组件所需要的一些数据，当数据发生变化时，将会调用Render重现渲染，这里只能通过提供的setState方法更新数据。
好了，说了这么多，下面看写代码吧，先看一个官网上提供的Hello World的示例：
<!DOCTYPE html> <html> <head> <script src="http://fb.me/react-0.12.1.js"></script> <script src="http://fb.me/JSXTransformer-0.12.1.js"></script> </head> <body> <div id="example"></div> <script type="text/jsx"> React.render( <h1>Hello, world!</h1>,
document.getElementById('example')
); </script> </body> </html>
这个很简单，浏览器访问，可以看到Hello, world!字样。JSXTransformer.js是支持解析JSX语法的，JSX是可以在Javascript中写html代码的一种语法。如果不喜欢，React也提供原生Javascript的方法。
再来看下另外一个例子：
<html>
<head>
<title>Hello React</title>
<script src="http://fb.me/react-0.12.1.js"></script>
<script src="http://fb.me/JSXTransformer-0.12.1.js"></script>
<script src="http://code.jquery.com/jquery-1.10.0.min.js"></script>
<script src="http://cdnjs.cloudflare.com/ajax/libs/showdown/0.3.1/showdown.min.js"></script>
<style>
#content{
width: 800px;
margin: 0 auto;
padding: 5px 10px;
background-color:#eee;
}
.commentBox h1{
background-color: #bbb;
}
.commentList{
border: 1px solid yellow;
padding:10px;
}
.commentList .comment{
border: 1px solid #bbb;
padding-left: 10px;
margin-bottom:10px;
}
.commentList .commentAuthor{
font-size: 20px;
}
.commentForm{
margin-top: 20px;
border: 1px solid red;
padding:10px;
}
.commentForm textarea{
width:100%;
height:50px;
margin:10px 0 10px 2px;
}
</style>
</head>
<body>
<div id="content"></div>
<script type="text/jsx">
var staticData = [
{author: "张飞", text: "我在写一条评论~！"},
{author: "关羽", text: "2货，都知道你在写的是一条评论。。"},
{author: "刘备", text: "哎，咋跟这俩逗逼结拜了！"}
];
var converter = new Showdown.converter();//markdown
/** 组件结构：
<CommentBox>
<CommentList>
<Comment />
</CommentList>
<CommentForm />
</CommentBox>
*/
//评论内容组件
var Comment = React.createClass({
render: function (){
var rawMarkup = converter.makeHtml(this.props.children.toString());
return (
<div className="comment">
<h2 className="commentAuthor">
{this.props.author}:
</h2>
<span dangerouslySetInnerHTML={{__html: rawMarkup}} />
</div>
);
}
});
//评论列表组件
var CommentList = React.createClass({
render: function (){
var commentNodes = this.props.data.map(function (comment){
return (
<Comment author={comment.author}>
{comment.text}
</Comment>
);
});
return (
<div className="commentList">
{commentNodes}
</div>
);
}
});
//评论表单组件
var CommentForm = React.createClass({
handleSubmit: function (e){
e.preventDefault();
var author = this.refs.author.getDOMNode().value.trim();
var text = this.refs.text.getDOMNode().value.trim();
if(!author || !text){
return;
}
this.props.onCommentSubmit({author: author, text: text});
this.refs.author.getDOMNode().value = '';
this.refs.text.getDOMNode().value = '';
return;
},
render: function (){
return (
<form className="commentForm" onSubmit={this.handleSubmit}>
<input type="text" placeholder="Your name" ref="author" /><br/>
<textarea type="text" placeholder="Say something..." ref="text" ></textarea><br/>
<input type="submit" value="Post" />
</form>
);
}
});
//评论块组件
var CommentBox = React.createClass({
loadCommentsFromServer: function (){
this.setState({data: staticData});
/*
方便起见，这里就不走服务端了，可以自己尝试
$.ajax({
url: this.props.url + "?_t=" + new Date().valueOf(),
dataType: 'json',
success: function (data){
this.setState({data: data});
}.bind(this),
error: function (xhr, status, err){
console.error(this.props.url, status, err.toString());
}.bind(this)
});
*/
},
handleCommentSubmit: function (comment){
//TODO: submit to the server and refresh the list
var comments = this.state.data;
var newComments = comments.concat([comment]);
//这里也不向后端提交了
staticData = newComments;
this.setState({data: newComments});
},
//初始化 相当于构造函数
getInitialState: function (){
return {data: []};
},
//组件添加的时候运行
componentDidMount: function (){
this.loadCommentsFromServer();
this.interval = setInterval(this.loadCommentsFromServer, this.props.pollInterval);
},
//组件删除的时候运行
componentWillUnmount: function() {
clearInterval(this.interval);
},
//调用setState或者父级组件重新渲染不同的props时才会重新调用
render: function (){
return (
<div className="commentBox">
<h1>Comments</h1>
<CommentList data={this.state.data}/>
<CommentForm onCommentSubmit={this.handleCommentSubmit} />
</div>
);
}
});
//当前目录需要有comments.json文件
//这里定义属性，如url、pollInterval，包含在props属性中
React.render(
<CommentBox url="comments.json" pollInterval="2000" />,
document.getElementById("content")
);
</script>
</body>
</html>
乍一看挺多，主要看脚本部分就可以了。方便起见，这里都没有走后端。定义了一个全局的变量staticData，可权当是走服务端，通过浏览器的控制台改变staticData的值，查看下效果，提交一条评论，查看下staticData的值的变化。
国外应用的较多，facebook、Yahoo、Reddit等。在github可以看到一个列表Sites-Using-React，国内的话，查了查，貌似比较少，目前知道的有一个杭州大搜车。大多技术要在国内应用起来一般是较慢的，不过React确实感觉比较特殊，特别是UI的组件化和Virtual DOM的思想，我个人比较看好，有兴趣继续研究研究。
和其他一些js框架相比，React怎样，比如Backbone、Angular等。
与传统PC桌面不同，手机屏幕的尺寸更加小巧操作，方式也已触控为主，APP界面设计不但要保证APP功能的完整性和合理性，又要保证APP的功能性和实用性，在保证其拥有流畅的操作感受的同时，满足人们的审美需求。
接下来为大家介绍几款手机appui界面设计
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
--手机appUI设计--
（以上图片均来源于网络）
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
更多精彩文章：
蓝蓝设计的小编 http://www.lanlanwork.com