平面设计师不可忽视的“数据”
短视频泛滥的今天，足以证明纯文字或者纯图像的输出已不能满足人们对信息的摄入。看图太单调，看文字太枯燥，所以不断有设计师开始思考怎么重新设计图文的形式让信息视觉化效果更佳。
信息设计区别于传统的平面设计，它更着重于数据的视觉化。目前，全球范围内的设计师们都在寻求以更创新、更独特、更有趣的方式来展示数据，信息图表就是信息设计中的一个子集，它能够使人们更好的读懂数据。越来越多的国家和企业已将信息图表设计运用于各领域的日常工作。
信息爆炸的时代正好缺少了这样一种整合信息的手段，信息图表的形式正好帮助人们解决了这样的一个难题。所以说信息图表设计不等于视觉设计，平面设计师通过扮演数据分析师获得锻炼，通过数据对比掌握最真实的情况，拉大平面设计师的思维范畴同时获得更多尊重与信任。
信息图表早已出现
信息图表的历史早于网络，大约32，000年。公元前30，000年的洞穴绘画很容易被称为第一个信息图表，描绘了周边地区的动物和其他资源。作为数据的直观表示，它们绝对是信息图表。
埃及的象形文字也是如此。公元前3000年左右，古埃及人用这些信息图表来讲述生活，工作和宗教的故事。
更为现代的信息图表历史可能始于William Playfair，他是统计图形学的早期创新者。1786年，他出版了商业和政治地图集，其中显示了许多代表英格兰经济的条形图，折线图和直方图。他在1801年用第一张面积图和第一张饼图进行了跟踪。
1857年，英国护士佛罗伦斯·南丁格尔使用信息图形，说服维多利亚女王改善军队医院的条件。她的图表显示了克里米亚战争每个月的死亡人数和原因：可预防的蓝色疾病，红色伤口和其他黑色病因。
说到英格兰，信息图表历史上的一大步是在1933年，当时哈里贝克创建了伦敦地铁的第一张地图，只显示了描绘公共交通路线和车站的线路。这是一个重要的发展，因为它将视觉图表移动到日常生活中。
信息图表的应用范围
因为日常生活中最常被我们接触到的信息图表就是地图，所以总有人认为信息图表就是地图。其实地图仅是信息图表的用途之一，信息图表不应该被局限地认为只能作为地图使用，下面为大家普及一些信息图表案例：
①
说明书
②
游戏设计
③
网页设计
④
APP界面设计
⑤
指示系统
信息图表设计覆盖的领域非常广泛，小到说明书、地图、各种场合PPT制作、书籍设计、游戏、UI、App、而完成一项信息图表设计需要经过数据采集、分析统计、对比采纳、最后通过平面设计师制作完成。
全球著名信息图表设计师
Jan Schwochow
Jan Schwochow是柏林Golden Section Graphics机构的所有者和创意主管，并且在柏林的KircherBurkhardt机构设立了一个信息图表部门。自2007年以来，他一直在管理Golden Section Graphics办公室，该办公室目前拥有多达16名员工。该团队的工作获得了众多国家和国际奖项。
①
作品：一个模型体育场
②
启发性广告
Alberto Lucas López
Alberto Lucas López是华盛顿高级地理图形编辑，他的作品在美国、亚洲和欧洲获得了无数奖项。Alberto的信息图表从其他领域脱颖而出，因为他的精致和反由他不断寻求创新所驱动的直观概念。仅在2015年，他就赢得了50多项国际奖项。
①
作品：Fender Stratocaster
Antonio Farach
Antonio Farach是Muscat Media Group的信息图表编辑，也是阿曼时报和Al Shabiba的出版商。
①
作品：Crimean-Congo Fever
SUNGHWAN JANG张圣焕／韩国
韩国弘益大学美术学院视觉设计系学士、弘益大学产业美术研究院硕士。现为203 X Design Studio代表、文化月刊《Street H》发行人，他在2013年开设了自己的“信息图表实验室”，研究和设计了不少优秀的信息图表作品。
①
作品：Self-Publishing
②
作品：Understanding Cat Care
③
作品：Burger
④
作品：Korean SOJU
为什么我们要学习信息图表设计？
信息图表我认为它始于阿尔塔米拉洞窟里的绘画。最开始仅仅是用于视觉交流。随着语言、文字的出现以及纸张的发明，信息得到了的传达，以文本为主的书籍也成为了交流的中心。辨别出好的信息以及如何精准传达显得尤其重要。
我们可以轻松地在世界上任意一个国家的机场里找到厕所，是因为有代表“厕所”的图片和图画文字。当然图画文字只是信息图表中一个很小的部分。现在，我们生活的世界已经成为一个，比起文字，更多地运用视觉信息打破地域和语言限制的时代。
— 张圣焕2018年Malofiej奖铜奖获得者
Malofiej奖是由新闻设计协会举办的。如今这个奖项被称为信息图表界的普利策奖，Malofiej奖一直以来表彰在出版和线上的最佳信息图表。
Malofiej奖26届信息图表铜奖▲
为什么你的信息图表设计就是学不好？
渐渐地发现，信息图表设计已进入到国内视觉传达专业里，而事实上在国外信息图表设计早已是一门独立的专业学科，我们常常问为什么欧美国家做的UI那么漂亮？
这是有原因的，在国内师资相当缺乏的条件下，信息图表设计往往是走马观花，忽视制作方法上的有效性，导致作品要么拥有视觉冲击力却缺乏表达的准确性，要么就是由数据转化出的视觉效果平庸缺乏魅力。那么怎么样才可以制作出有魅力的信息图表设计？
经过深入的观察与分析，我们认为信息图表设计将改变平面设计的未来，由Helvetica 掀起的字体设计热蔓延全球，让字体设计意识得到重视与提高，而下一股推动这个信息时代发展的必定是信息图表设计，有魅力的信息图表设计记录时代的变迁，让世界越有魅力！
BranD × 张圣焕
作者：BranD
链接：https://www.sohu.com/a/245081283_611151
来源：搜狐
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
HT 是啥：Everything you need to create cutting-edge 2D and 3D visualization.
这口号是当年心目中的产品方向，接着就朝这个方向慢慢打磨，如今 HT 算是达到了这样的效果，谈不上用尽洪荒之力，但我们对产品结果很满意，特别是 HT 的用户手册，将例子和文档无缝融合一体，小小 10 来兆开发包居然包含了四十五份手册，数百个活生生的 HTML5 例子，还没体验过的同学可以点击 http://www.hightopo.com/guide... HT 手册入口玩一玩。
这样综合并可搜索的手册入口居然还常被问及 HT 的 Demo 在哪里？只能怪这些年深入人心的用户体验理念，把人惯得包括很多程序员都如此之“懒”，当然也怪我们没把用户体验的最后一公里做到位，于是最近 wangyinlong 同学人工例子抓图，将数百个手册例子进行了归类整理，最终形成了方便大家直观查找所有 HT 例子的页面：http://www.hightopo.com/demos...
很明显 http://www.hightopo.com/demos... 相比 http://www.hightopo.com/guide... 页面，对于 HT 老用户包括我们自己做技术支持，都感觉查找例子更直观方便，但对于 HT 初学者，面对这一堆数百个涵括通用组件、网络拓扑图组件、3D 组件、矢量图形、各种编辑器等等五法八门的 HTML5 例子盛宴，往往无从下手，为此我打算写个《数百个HTML5例子学习HT图形组件》的系列文章，引导各种电力、电信、工控 SCADA 等不同行业领域用户，学习使用 HT 这全套一站式 HTML5 图形组件。
拓扑图组件作为最典型的 HT 客户需求应用，自然是首篇登场。
HT 的拓扑图组件主要基于 HTML5 的 Canvas 技术，拓扑图是电力和电信的叫法，但该组件远不仅仅用于呈现节点和连线，在 HT 里面我们没把该组件狭义的称为 Topology、Network 或 Diagram，我们将该组件类名称为更通用的 GraphView，只要你有想象力，你可以用拓扑图组件做出任何其他组件，对于一些需求你想不出来用啥组件实现时，往往就是拓扑图组件需要站出来发力了：
可能大部分不在游戏领域混的同学会好奇上面两张图是什么鬼？这两张是开源的 HTML5 游戏引擎工具 QICI Engine （https://github.com/qiciengine...）游戏工程抓图，有兴趣的同学可到 Github 上下载试玩。
QICI Engine：A free JavaScript game engine library with a web-based comprehensive suite of toolset for making HTML5 games.
整个 QICI Engine 的 HTML5 游戏引擎编辑工具就是基于 HT 组件定制开发出来的，上图刀塔场景的资源管理器就是图标可缩放，图集可展开合并，可缩小变成树层次的 GraphView 拓扑图，而第二张的动作编辑器、曲线编辑器等等部分也都是 GraphView 的身影。
现在你应该能理解为什么我说拓扑图组件几乎可作出任何其他组件，当然定制其他组件是需要时间精力成本的，否则也不需要有其他组件的存在意义了，开发 QICI Engine 产品是另一个故事，今天就先不展开了。HTML5 游戏已经不是啥新鲜玩意儿了，但游戏开发工具完全基于 HTML5 可运行在浏览器还是有点意思的，下图附上阿明同学的得意之作《城市消消乐》抓图，有兴趣的可玩之：http://engine.zuoyouxi.com/ga...
回到今天的主题，学习使用拓扑图，第一步就是: Get Your Hands Dirty，哪怕你不熟悉 HTML，直接照葫芦画瓢按 http://www.hightopo.com/guide... 的代码构建出两个节点三条连线：
// 创建数据模型容器
var dataModel = new ht.DataModel();
// 创建拓扑图组件
var graphView = new ht.graph.GraphView(dataModel);
// 创建一个起始节点，设置名字和位置属性，添加到数据模型容器
var source = new ht.Node();
source.setName('source');
source.setPosition(100, 70);
dataModel.add(source);
// 创建一个结束节点，设置名字和位置属性，添加到数据模型容器
var target = new ht.Node();
target.setName('target');
target.setPosition(260, 70);
dataModel.add(target);
// 创建一条连线，设置起始和结束节点，添加到数据模型容器
var edge = new ht.Edge();
edge.setSource(source);
edge.setTarget(target);
dataModel.add(edge);
相信上面的代码很直观就能理解拓扑图构建的原理，很多人会问 HT 如何通讯获取数据，对后端有限制吗？HT 只是客户端组件，不介入到后台通讯，因此客户可以采用任何后台系统，Java、C++、PHP、Node.js 等等，可采用任何通讯方式 HTTP/AJAX、WebSocket 等，采用任何数据格式 XML、JSON 或 TXT 等，只需要最后用户根据自己格式的数据内容，采用 HT 图形库提供的标准 API 接口创建相应的节点、连线等图元，设置相关的属性信息，即可实现图形呈现，所以 HT 组件对后台和通讯方式没有任何要求。
以上的例子对于名称和位置的设置都是 demo 中随意设置的值，真正的系统用户一般会通过后台数据库查询，然后根据业务数据内容构建图元并设置相应的属性。你会发现虽然在构建拓扑图，但你80%的代码都在和 Data 和 DataModel 打交道，这两个又是什么鬼？其实绝大部分 HT 的客户开发完整个系统都没必要认真学习《HT for Web 数据模型手册》，也不用管 HT 采用的是啥 MVC/MVP/MVVM 框架，需要深入了解的可阅读 http://www.hightopo.com/guide... 手册
简单说 Data 就是 HT 的最小数据单元，对于 GraphView 组件可以说是一个图元，一个节点或一条连线；对于 Tree 组件可以说是一个树节点；对于 Table 组件可以说是一行记录，这些 Data 图元需要添加到 DataModel 的数据容器中，而 HT 的所有视图组件 GraphView、List、Tree、Table 甚至是 3D 组件 Graph3dView 都会绑定一个数据容器，这些视图都会监听数据容器的事件变化，进行自身组件的刷新显示工作，这些事件包括图元的属性变化、图元的增删，还有很重要的一个关系，就是图元的父子关系变化。
提到父子关系让我们来看看一个比较综合性的小例子：http://www.hightopo.com/guide...
// 创建数据容器
dataModel = new ht.DataModel();
// 创建拓扑图、属性页、列表、树、表格、树表组件
graphView = new ht.graph.GraphView(dataModel);
propertyView = new ht.widget.PropertyView(dataModel);
listView = new ht.widget.ListView(dataModel);
treeView = new ht.widget.TreeView(dataModel);
tablePane = new ht.widget.TablePane(dataModel);
treeTablePane = new ht.widget.TreeTablePane(dataModel);
// 创建组图元，添加孩子节点，加入数据容器
group = new ht.Group();
group.setName('HT for Web ' + ht.Default.getVersion());
group.addChild(hello);
group.addChild(world);
group.addChild(edge);
dataModel.add(group);
这个例子增加了设置父子关系的代码，同时有更多的组件（拓扑图、属性页、列表、树、表格、树表组件）绑定了同一个数据模型 DataModel，但用户的代码依然主要在 Data 和 DataModel 上的操作，这也是 HT 架构设计的优势，用户使用更多组件并没有增加新的学习成本，只要掌握的 DataModel 的基本操作，更多的组件也是如此。
虽然图元属性设置、增加变化甚至是选中操作都可以通过 DataModel 搞定，但并不意味着 DataModel 是万能的，有些需求还是需要通过 View 视图进行。例如很多基本需求是双击图元要做些业务处理，如何监听呢？怎么从 Node 上没找到啥 onClick 之类的接口？这可以从《HT for Web 入门手册》的交互章节找到答案：http://www.hightopo.com/guide...
graphView.addInteractorListener(function (e) {
if(e.kind === 'clickData'){
console.log(e.data + '被单击');
}
else if(e.kind === 'doubleClickData'){
console.log(e.data + '被双击');
}
});
如果你还想打破砂锅问到底为什么不直接在 Data 或 DataModel 上提供交互处理，Data 数据是可以给很多 View 视图共享用的，DataModel 甚至都不知道 View 视图的存在，
他们只会派发模型变化事件，而 View 通过监听模型的变化进行相应的更新处理，HT 的模型架构上极其类似 Facebook React https://facebook.github.io/re... 的 Flux
单向流设计理念：http://facebook.github.io/flu...
HT 的 DataModel 相当于 Flux 中的 Store 模块，拓扑图、树和表格这些自然对应 View 模块，一般发起 Action 动作就是后台数据变化，或者用户手工输入表格属性值之类，但最终都不是直接修改 View，都是从 Data/DataModel/Store 发起修改，然后数据模型派发事件给所有 View，最后 View 根据不同事件做相应的处理。
有兴趣的同学可以打开 http://www.hightopo.com/guide... 控制台，输入如图的代码体验下实时修改数据模型的效果：
刚才的例子我们提到了一个 Group 类型，这个类型图元节点在 GraphView 上显示成了组合效果，可双击展开合并，可跟随着孩子节点的位置大小变化和自适应变动，除了 Node、Edge、Group 外，HT 还提供了 Shape、Polyline、Grid、SubGraph 等多种图元类型，这些图元类型都具是有针对性的展示效果，以满足各种行业的基本图元需求：http://www.hightopo.com/guide...
对于连线 Edge，HT 还提供了自定义走向的扩展机制，并提供了相应的预制扩展连线类型插件，参见《HT for Web 连线类型手册》http://www.hightopo.com/guide...
当然预定义的类型再多也不可能满足千奇百怪的行业图元需求，这是你该阅读下《HT for Web 矢量手册》http://www.hightopo.com/guide... 的时候了，关于矢量的介绍以前写过两篇老文供大家参考：《HT全矢量化的图形组件设计》和《HT图形组件设计之道（二）》
以上这个例子你可以在这里玩：http://www.hightopo.com/demo/... 。相关视频：http://v.youku.com/v_show/id_...
另外 HT 的矢量内置了 Chart 类型，矢量内置的 Chart 不同于传统独立的 Chart 组件，传统的 Chart 是独立的视图 DOM 组件，但 HT 的拓扑是 Cavans 方式绘制，因此没法实现 Chart 组件和普通图元的不同层次融合显示，但矢量的 Chart 类型倒是完美的实现了这样的融合，很多工控应用的客户会将矢量 Chart 与拓扑图元素融合一体，可参见《基于HT for Web的Web SCADA工控移动应用》http://www.hightopo.com/blog/... 一文中 HT 的 Web SCADA 应用案例
当然你也可以把 HT 与 百度 ECharts 进行整合，只要是 HTML 图形组件就可以整合到 HT 的布局容器中，可参考《ECharts整合HT for Web的网络拓扑图应用》，此例子将 ECharts 整合 HT 拓扑图做了告警统计的图表呈现效果：
除了混合第三方图形组件库外，HT 图扑还能嵌入 SVG 的图片进行矢量呈现，参见《绘制SVG内容到Canvas的HTML5应用》
在某些特殊的情况下用户还可以将 HTML 元素嵌入作为普通的 Node 节点，并支持拓扑图的缩放、改变大小等等操作效果，可参考《HT for Web HtmlNode 手册》http://www.hightopo.com/guide... ，这种结合有一定的局限性，不到万不得已不建议用户使用该插件。
HT 提供了各种丰富的通用组件，以及复杂的拓扑图编辑交互插件 http://www.hightopo.com/guide...，用户分分钟可以快速开发出各种各样的编辑器工具。入门手册中也有个 http://www.hightopo.com/guide... 简单的编辑器例子，教用户如何自定义创建节点、连线和多边形的示例教材，学习自定义拓扑图交互可从此例子入手。
甚至可以像 http://www.hightopo.com/guide... 这个例子那样，关闭掉拓扑图的所有默认交互，直接通过添加原生的 HTML DOM 的事件监听进行自定义交互逻辑处理。
构建出拓扑图后很多人关系的是如何实现动画，动画从本质上来说就是在一定的时间点上驱动图元的参数变化，例如大小、颜色、粗细包括可见不可见等来实现各种动画效果，而 HT 本来所有图元都是数据驱动，用户随时可以修改 Data 上的任何属性，因此随便起个定时器 windwo.setInterval 不断改变图元属性值即可实现动画效果，但为了方便客户 HT 还提供了诸多方便函数和插件。
例如 http://www.hightopo.com/guide... 中的 ht.Default.startAnim 函数，该函数支持 Frame-Based 和 Time-Based 两种方式的动画，为了理解其中的 Easing 参数可参见 《透过WebGL 3D看动画Easing函数本质》文章和 http://www.hightopo.com/guide... 这个例子
如果是持续周期的变化可采用《HT for Web 调度手册》http://www.hightopo.com/guide... 的调度插件：
如果你喜欢 https://github.com/tweenjs/tw... 的 chaining 函数方式串联多种动画，可采用《HT for Web 动画手册》http://www.hightopo.com/guide... 的插件。对于连线流动、虚线流动等常见连线动画需求 HT 已经封装了相应的插件《HT for Web 流动手册》和《HT for Web 虚线流动手册》
HT 的拓扑图的节点位置都是逻辑坐标，并非 GIS 的地理信息经纬度坐标，但这并不妨碍 HT 的拓扑图可以和百度地图、GoogleMap、OpenLayers 等第三方 GIS 地图引擎进行整合呈现，参见《百度地图、ECharts整合HT for Web网络拓扑图应用》，该文将 HT 拓扑图、百度地图、ECharts、HT 连线流动和面板等插件做了个综合的呈现展示效果：http://www.hightopo.com/demo/...
拓扑图做完呈现需求效果之后，常会有拓扑图纸数据需要保存的需求，这个很简单，DataModel 内置将所有数据转换成 JSON 的功能，非常方便用户将拓扑图内容进行导入导出工作，一般用户会将 JSON 数据字符串化并进行压缩，然后存到后台数据库或文件系统，运行时再进行加载导入，这方面请参见《HT for Web 序列化手册》，其实 HT 的可序列化功能并非为拓扑图组件特殊设计，本质是整个 DataModel 数据层就可以序列化，所以意味着你可以存储表格内容、树层次关系包括 3D 场景。
关于客户端存储数据方面还可参考这篇文章《HTML5 Web 客户端五种离线存储方式汇总》
http://www.hightopo.com/guide...
另外 HT 的数据绑定功能是非常赞的特点，往往让你意想不到的寥寥几行代码即可实现很有趣的功能，例如下面这个例子，实现一个 Chart 图元在拓扑图中，用户看看拖拽图元实现饼图旋转，双击切换是否中空，只有寥寥十来行代码即可实现，我是想不到如何还能更简单实现这样的功能：http://www.hightopo.com/guide...
对于电信网管客户常常有告警的特殊行业呈现需求，这方面 HT 也提供了针对电信 OSS/BSS 网管拓扑图应用的《HT for Web 电信扩展手册》http://www.hightopo.com/guide... 插件，针对图元告警渲染、告警传播等提供了特殊定制化的展示效果：http://www.hightopo.com/guide...
虽然 HT 的拓扑图组件可以承载万以上的拓扑图元量，但如果这些拓扑图元都通过手工布局那是不可思议的工作量，因此 HT 为拓扑图组件提供的多种自动布局引擎算法，例如弹力布局、圆形布局、星型布局和层次布局等多种样式效果
《HT for Web 自动布局手册》http://www.hightopo.com/guide...
《HT for Web 弹力布局手册》http://www.hightopo.com/guide...
HT 还为拓扑图组件提供了贴心的鹰眼 Overview 插件（http://www.hightopo.com/guide...），整合上 HT 的 Panel 面板插件（http://www.hightopo.com/guide...）是用户常见的融合拓扑和鹰眼的展示方式，鹰眼具有实时同步拓扑内容，可滚轮缩放，点击定位，拖拽平移等操作方式，非常方便用户浏览导航大数据量拓扑图的应用场景。
拓扑图篇就写这些吧，HT 的拓扑图组件还有非常多的功能，无法在一篇博客中说透，我只能蜻蜓点水的提到大部分拓扑图应用需要关注的功能点，HT 更多的 HTML5 拓扑图功能留给大家去探索吧。
http://www.hightopo.com/guide...
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
环境搭建
首先在微信公众平台注册一个我们自己的账号：
根据注册提示完成注册
很多问题，并没有绝对的标准，重要的是，我们是否有主动去思考其背后的逻辑。
iOS 13.3 版本的 iMessage 功能原版与新版对比，好在哪里？为什么这么改？
这次 iOS 13.3 的更新点，有一处是对 iMessage 做了优化，这是苹果中国团队一直在着手解决的问题，在 iOS 13.3 上，具体的变化是把信息分为：
1. 解决歧义
原版的分段控件，显示的是「联系人与普通短信」和「不在通讯录」。
仔细观察的人就会发现，原版的「联系人与普通短信」所包含的信息，其实都不是已知联系人的信息，比如 95595 的通知信息，它本身不在通讯录里，所以按照原版的逻辑，它应该出现在右边的「不在通讯录」里。
但是，它还是在左边的「联系人与普通短信」里。而出现在「不在通讯录」的信息，大部分都是垃圾信息。
所以这里存在一个歧义，就是「不在通讯录」应该改为「垃圾信息」或「过滤信息」，而「联系人与普通短信」应该改为「所有信息」。
于是，新版应该是「所有信息」和「过滤信息」。接着，再从所有信息里区分成「已知联系人」与「未知联系人」，那么这个短信内容就分成了四个模块，分别是：
这样一来，分段控件就满足不了四类信息的呈现目的，于是用列表就会更直观。
2. 功能解读
用户陌生短信多，对用户干扰大。
通过「联系人是否在通讯录中」来区分短信类型可以有效管理陌生短信。
完全陌生：服务登录和身份认证的短信来源往往不在通讯录中；不完全陌生：在通讯录中的联系人和已回复短信的信息来源是熟悉的。
区别两者的好处是让用户更有针对性地进行操作：
明确操作更有助于对信息进行有效管理，优化存储空间。
总结：
结论：提升用户使用效率。
同是支付功能，为什么微信把收付款统一放在一起，且收款需要多一步操作，而支付宝把收款和付款分开放在首页？
功能点在产品中的层级处理，往往是由产品本身的定位决定的。
大家在思考问题的时候要记住一个原则，拿两个不同类产品做功能对比是没有意义的。
微信是社交平台，支付宝是超级工具，它们的定位不同，讨论说为什么这个是这样，而那个不是这样会显得很片面。
但为了解答这个同学的问题，我还是简单聊下。
收付款功能，对支付宝这个超级工具来说，是最高层级的功能，但是对微信来说并不是（虽然微信支付很棒，但是在微信的产品设计中还是以社交为主）。
另外，这两款产品，熟人之间可以用红包或转账完成交易，所以我们在讨论这个问题之前，得先把前提定为陌生人交易。
平时出去买东西，更多是扫商家打印出来的二维码付款，或给商家扫客户的二维码付款。
在商家场景，客户用收款的情况是很少的，除非出现支付错误，客户付多了。于是商家需要还钱，除了可以让商家操作全部退款，让客户重新支付之外；还能通过客户的收款码，把客户多付的钱，打给客户。
但是这样的场景很少，自然扫一扫和付款码的优先级，会比收款码要高（更不要说扫一扫是天然高优先级功能了）。
而对于支付宝来说，分开呈现可以理解，毕竟产品本身就是支付类工具的定位。而对于微信来说，在「+」里面再放置一个收款码，或者在「我的」里再拆分一个位置出来给收款码，用于陌生人之间的转账交易，显得有些多余，毕竟使用场景太少。
以至于两个都放出来对于社交产品微信来说没有必要，对于支付工具支付宝来讲，也需要将付款放置在收款之前。
重点。
其中还有个核心点是，微信的「收付款」不仅仅指的是收款码和付款码，它们还包括了赞赏码、群收款、面对面红包、向银行卡或手机号转账。
所以对于微信来说，收付款不是一个简单的收付款，而是在定义上，只要跟「收付款」有关的功能的入口。如果你现在方便，再看下它们的排列顺序。
所以，这个功能就不好拆分，一拆分，就不是两个二维码的事情了，而是 6 个子功能的问题。
这也是我前面说的，为什么两个不同产品的功能，不能简单用来对比的原因。仔细分析下就会发现，它们的差异会很大。
同样是即时通讯产品。微信与 QQ 的底部输入栏为何不同？
在聊天页的底部栏双方的功能承载数量不同：QQ 一共放置了 19 个功能，而微信放了 12 个，其中双方相重合的功能点共 10 个。
两者前 4 个功能基本一致：语音输入、图片、拍摄、表情包。QQ 将「红包」放置在第 5 位，微信则是将「语音通话」放置在第 5 位。
如果 QQ 像微信一样的底部栏设计会导致「更多」中需要放置 17 个功能点，按照现有排布方式会变成 3 页滑动（8+8+1）最后一个功能层级更深，使用率会更低。
总的来说，两者的功能排布所造成的差异可以是以下 3 点。
作为熟人社交的微信，与对方沟通的过程中比较注重沟通的效率和专注度，他们的对话往往是有明确主题和目标，希望创造冷静的对话环境。
QQ「每一天乐·在·沟·通」，在强调沟通的同时还突出了「乐」的重要性。
微信面向用户，特别中老年人用户，学习成本不能过高，所以在对话时不宜有太多内容，一是容易让用户困扰，二是容易误触。因此需要调性更稳，且懂得克制。
QQ 用户群体较年轻，而且社交群体多样化，因此发表情图片，语音功能变声，相机滤镜表情，红包有不同功能增加沟通时的互动性，同理动态头像（框）以及聊天字体的多样化都能使聊天内容更丰富，在满足基础的沟通交流上还要满足年轻人对于新鲜事物的探索。
功能在很多时候是需要看战略与方向的，比如 QQ 如果要推红包，就会把红包位置提前。所以 QQ 这样的底部功能在变化上更符合年轻化的气质。
总结：产品的定位和使用人群不同，在功能的表达方式上有明显的不同，QQ 功能更多的是「放」，直接展示功能吸引用户使用，而微信更懂得「收」，弱化次级功能，强化主要功能。
强化主要功能，弱化次要功能，也是提升用户体验的方式。
延展阅读：
有两种七日签到的机制，一个是连续签到，比如百度网盘。另一种是按自然周来算，比如掌上生活。作为 7 日签到功能，分别用这两种显示方式的原因是什么？
签到功能是通过虚拟或实际的奖励，提升用户的活跃度、增强用户粘性、提升登录注册转化率等等。
7 天连续签到。
连续签到的目的是，通过奖品价值递增，调动用户连续登录的积极性，提升产品日活情况。
这里的关键点有两个，一个是天数，一个是连续的。
7 天对比 1 个月，在时长上能被用户更好接受，虽然最终奖励不同，但积极性来说前者会更好，毕竟更容易完成。除非，最终奖品是超出预期的。
连续的话，譬如用户忘了或有一天不想签了，那第二天进来又成了第一天签到，于是索性就再也不参与了。
所以这类工具产品通常会把最终奖励设计得比较诱人，连续签到天数也设定得少一些，以此来提升用户粘性。
自然周签到。
自然周签到的好处是，即使有一天忘了签到，也不影响后面几天，且更便于系统发放奖品。
比如周一用户忘了签到，周二再来，还是可以对周一做签到操作，只是周一的签到奖品拿不到了而已。不过有的产品能通过补签卡来解决这一问题。
另外，用户每天来签到，看到的都是系统设置的当天发放的奖品，比如周二来签到的都是送圣诞帽，这样管理员可以根据预算情况、节假日、热点新闻等因素，来实时设置每日奖品的类型，与被领取的奖品数量，对运营工作来说会更灵活。
而像 7 天连续签到那样，每个人签到的天数都是不一样的，那么奖励也就不好评估。以至于连续签到奖励大多是积分等奖品。
排行中展示数据的动态变化有什么作用？（新热点、趋势）
更换频率差异。
微博实时热搜榜更新快，只需要根据排行就可以清晰了解信息热度，趋势的显示意义小；而淘宝热榜更新相对较慢，为了引导消费，所以提供了趋势指标帮助用户决策，上涨的趋势会起到「大家都在买」的心理暗示作用，刺激消费者点进去看看。
产品特异性。
用户对话题排行敏感，有明显下降趋势的图标，对控制舆情不利；对于淘宝热榜，商家和用户都需要知道更准确的搜索倾向，即上升下降趋势，了解商品热度。
文章来源：优设 作者：呆总丶
品牌 IP 化最大价值在于：通过挖掘品牌的人性，赋予性格、文化、价值观更像一个有血有肉有灵魂的人，通过持续的内容生产，吸引用户参与，进而使用户产生精神共鸣，在与用户产生关系的过程中给予情怀和温度、最终实现商业价值。
IP 在百度上解释为：（Intellectual Property）知识产权，指的是通过智力创造性劳动所获得的成果，并由劳动者享受成果的专有权利，是一种无形财产。现在市面上见到的 IP 现象呈现出来的是一种新商业现象、新商业模式、一种新的思维方法，比如我们见到的漫画、电视剧、明星、小说、游戏等……
用一句话解释：IP 就是自带流量、散发魅力、可以吸附粉丝、商业转化。
十多年前，品牌设计被叫做企业形象设计（VI），他的基本要素就是：企业 logo 图形、标准字、辅助图形、吉祥物设计等。设计师通过创意设计出简洁生动的图形传递品牌的形象，这个图形就像一个符号占领用户的心智。
企业的最终是要售卖产品达到盈利的目标，就要投入大量的成本去各种渠道推广品牌形象，比如灯箱广告、电视广告、车体广告投入等，以保持品牌曝光度。
1. 品牌IP化
近十年来，在早期一些互联网品牌变化中，我们发现京东、天猫、当当、国美……很多品牌都在打造动物形象。
从 2016 年开始，各个企业的品牌设计出现的一些新的方向，他们打造符合品牌的 IP 形象符号或者 IP family，比如知乎刘看山、 AcFun 的 AC 娘、哔哩哔哩的 2233 娘、QQfanmily、MTfamily，用一些傻呆、萌、贱、骚等个性鲜明的形象吸引粉丝，获得用户对品牌的好感度。
傻呆、萌、贱骚的个性IP形象：
IP族化：
从过去品牌设计发展到如今品牌 IP 化后，品牌逐渐变得有温度、有人格灵魂、更容易互动了。
1. 从理性功能定位转变到情感精神寄托
品牌设计在推广中强调的是产品功能，属于漏斗式输入。而品牌 IP 化追求的用户对价值和文化认同，提供给消费者的是一种情感的寄托。比如《故宫》不再是过去威武严肃的印象，以俏皮、卖萌的周边形象深受年轻人的喜爱，故宫的文化、传统元素也找到了新的传承渠道。
2. 用户购买行为由需要转变为热爱
品牌是通过传统的定位理论占据用户的心智，当用户需要什么产品？选择什么品牌？是根据产品融入脑海中品牌理念而选择了这个产品。比如当我们需要买去屑洗发水选择买海飞丝洗发水。
品牌 IP 后在一定程度上弱化了品牌，利用天生形象优势、人格魅力、深受用户追捧。用户的购买行为是感性的，由内心热爱驱动购买。比如爱莎这个形象深受女孩子的喜爱，有关爱莎的裙子、玩偶、绘本、电影等孩子会不顾一切要求购买。
对于企业来讲，是否可以生产一些吉祥物就可以进行品牌 IP 化吗？
其实并不是那么简单！品牌 IP 化远远不止于做一个动物卡通形象就可以了。我们在前面说到在 2012-2015 年互联网品牌大量采用动物形象，但是他们并没有形成品牌 IP 化。
判断品牌 IP 化的三个特征是看品牌 IP 化后是否具有内容持续生产力、跨界连接力、商业衍生力。
1. 品牌IP化可以持续输出内容、具备内容生产力
品牌 IP 化通过自身角色和人格设定，吸附更多的用户的喜欢和追捧。品牌 IP 化的形象可以成为一个优质的内容源，提供持续的优质内容，不断引发与用户的关注和互动。
内容具有持续性：
line 在全球深受粉丝的追捧，这很大一部分原因在于 line 不断持续制造内容。line 最初是韩国的一家通讯公司，2013 年因为表情包深受用户的热爱，并因此带来 10 亿的收入，之后 line 打造了ugc模式，由用户创作表情上传带来 147 万美金的收入。此后几年持续创作有新成员加入，制作新的热点和内容。
2016 年布朗尼妹妹丘可加入
2. 品牌IP化具有连接力，可以连接用户、跨平台、跨品牌连接不同圈层
连接不同圈层：
在以往品牌对产品的推广上，由于产品特点、行业本身的壁垒，品牌难以跨越圈层和其他品类进行营销方式上的更多尝试，而 IP 营销则打破了这一壁垒，跨越了产品品类和行业的界限，带来了营销方式和品牌创新上的更多可能。
比如 linefrineds 与京东、天猫、优衣库、VANS、悦诗风吟、施华洛世奇合作推出了很多联名款的产品：T 恤、护肤品、项链、运动鞋等。这些合作跨越了行业、品牌等。
连接粉丝或用户：
最初，熊本熊只是熊本县政府宣传案的「副产品」，但这只熊火爆程度比肩哆啦 A 梦。在形象产生一个月便策划一系列神奇而疯狂的事件，比如聘任熊本熊为临时公务员，熊本熊大阪失踪，寻找腮红事件等。这些具有热议感、刷屏感、卷入感事件曝光和粉丝持续产生了连接。
品牌 IP 化赋予鲜明的形象与性格，这样形象与性格能与用户产生更近的互动，当这个形象持续产生内容输出后，让用户会产生更强的参与感、立场感，品牌与用户也就更强地连接一起。
延伸阅读：熊本熊之父的故事
3. 品牌IP化具备衍生力，实现商业闭环
品牌 IP 化只是品牌在互联网时代的一个新的工具或者方法论，最终都是要实现商业价值。要想实现商业变现、长久发展，必须有不断跨界合作、衍生周边产品和服务的能力。比如 line，最初由一个卡通形象，慢慢发展到漫画、表情、周边。他可以在不同时代捕捉到当下的流行，并与之紧密结合，达成品牌 IP 在不同品类和不同时期都保持强有力的衍生变现能力。
品牌 IP 化最大价值在于：通过挖掘品牌的人性，赋予性格、文化、价值观更像一个有血有肉有灵魂的人，通过持续的内容生产，吸引用户参与，进而使用户产生精神共鸣，在与用户产生关系过程中给予情怀和温度、最终实现商业价值。
文章来源：优设 作者：咏舍
身为一个有超过十年使用经验的 Apple 用户，虽然不算太资深，但也曾经历这十多年来苹果大大小小的设备，大家都喜欢拿 Steve Jobs 和 Tim Cook 作为两个跨时代分水岭，早期的 Apple 让大家充满期待，引领着科技时代潮流，而现今则转趋于保守，更多的是账面上销售数字和市占率。或许不同时代考虑的因素不同，总而言之，可以看着一家公司不断推出各种产品也是相当令人兴奋的事。
想知道 Apple 产品演变历程，大部分的人都会直接搜寻维基百科条目，就能看到某个产品线不同年份的特色、规格和评价等信息，但如果想找出当年的发布影片、广告或图片可能就会有点难度，即使苹果有提供 Apple Keynotes 但也只有 2011 年以后的数据。
本文要介绍的「The Apple Archive」是一个非官方 Apple 档案库，收录从 1970 年代至今各种和 Apple 有关的资料，像是历年 WWDC 大会影片、电视广告、宣传图片或是一些采访影像等等，可以说是非常完整的苹果数据库。如果你想研究产品的演变过程，或是当年 Steve Jobs 曾说过那些话，都能在网站上找到数据。
The Apple Archive 采用年份方式将这些记录重新排列、索引，编制成更容易检索的数据网站，亦可使用搜寻以特定关键词找到相关内容，对于想研究 Apple 公司或产品会非常有用。
网站链接：https://www.applearchive.org/（访问速度较慢的用户建议搭梯子）
开启 The Apple Archive 网站，直接点选一个你想要浏览的年份，接着就能从上方选单找到特定的年份，网站收录的数据最早可以回溯到 1977 年，最近则是 2019 年（2020 年会在三月发表会后开始更新）。
每个年份页面会有新闻素材、图片、产品广告和 WWDC 发表会影片，除了标示出日期和地点外，透过底下的标签可以查看更多相关主题。
The Apple Archive 将影片部分全部上传到 Vimeo，例如 2008 年发布的 MacBook Air 就是相当经典的一段，Steve Jobs 从牛皮纸袋拿出超薄 MacBook Air 令全场惊艳。
在每个年份底下都显示当年的 macOS 主题，可能更早以前比较没有印象，但这十年的 macOS 背景相信大家不陌生，也可能或多或少都有看过。
最后，如果你想更快找到特定内容的话，点选年份、按下页面上的「View as list」就能以列表方式呈现该年度的所有内容，也会显示一共有多少个发表会、相片、影音数据，可以更快找到你想搜寻的内容。
值得一试的三个理由：
文章来源：优设 作者：Pseric
最近朋友们探讨起「设计价值」的问题，似乎每隔一定周期，这个问题就会被拎出来。我笑称，「时尚圈有轮回，我们互联网圈看来也是」。
虽然问题大同小异，但每次探讨的侧重点会不一样，在这里记录一下自己的一些看法。
设计的价值就是解决问题，这一点毋庸置疑。而当今行业内对设计解决问题方式和程度的讨论，离不开支撑和赋能两个词，支撑是我们的本职（做好自己），赋能是我们的升华（做得更多）。
如何支撑好，我们应该不需要过多讨论了，这是设计师价值的主线。但是如何赋能好，就是一个比较重要且有难度的课题了：一来我们要有全面的思维，去挖掘能够发挥的点；二来我们需要把握好边界和「尺度」，不然表现起来仿佛我们在和他人抢活。
不过还是需要说一句，虽然我们区分支撑和赋能，但是支撑和赋能其实不存在绝对边界，不同时间、不同空间都有不同定义：10 几年前设计价值的发挥可能只需要支撑即可，但是现在纯支撑可能不足以达到时代要求；A 企业 a 项目可能只需要支撑即可，但是 B 企业 b 项目则需要设计师发挥得更多。
支撑和赋能都是基于解决问题来定义的，如果我们要去寻找赋能的机会点，我们可以尝试扩充一下「解决问题」的使用场景，在含义上做下功夫：解决了问题、解决什么问题、很好地解决问题（评价者）……串成一句话就是「我如何很好地解决了什么问题」。这句话切出每个切面，就有很多机会点可以挖掘。
既然说「赋能」是增量，那么挖掘设计「赋能」价值的时候，无非是寻求一个锦上添花的「更」字，所以我们可以转化为一些形容词：「更好」、「更准确」、「更快」……究其本质，就是效果、效率、科学方法。我们可以用这个思路来排查和寻求赋能的要点：
何为「好」，这是一个主观评价，既然是主观评价，我们就要清楚「谁」。首要的肯定是用户（当然为用户解决问题已经是本职工作，是主线了，不一定归为「赋能」），除此以外就是我们工作中合作的所有人。
我罗列一些场景作为例子：
业务方希望设计师能够多方合作，一起参与到产品规划中，挖掘新的需求。
——这种情况设计可以做的是设计前置，贡献自己的 idea，帮助业务达成目标。（这里措辞是「帮助」，因为业务产品、运营才是主体，他们要对规划思虑周全）
你的项目成员希望你输出效率工具，提升合作效率。
——这种情况设计可以直接赋能，比如制定效率工具和方法，或者拉上项目成员，「一起干一票」。
你的上级希望你对团队有更多贡献
——这种情况设计师也可以直接赋能，自己贡献一套方案，或者发挥领导力拉上有共同想法的同学一起干。
……所有这些，其实都是「预期」，也是目标。这也是不少团队使用 360 度评价方式的原因，通过所有人进行满意度评价，来回答「好」这个问题。
有了预期，对什么问题的定义就更加顺理成章了。但是问题是需要定义的，能满足所有预期当然最好，但是现实中受限于人力、时间、能力等条件，我们也要划分出赋能的优先级，一般划分的依据，就是回答一个问题：「设计师及其方法对预期的达成有多大的作用」。
我再罗列一些场景作为例子：
业务上某个环节需要设计强参与，希望设计师强力且深刻的挖掘研究。如流程、交互、体验。
——这种情况措辞是「强参与」，是因为现在规范化的时代，涉及到「流程」、「体验」这样的手段，设计师和产品的边界在缩窄，有一些能力强的产品同学，通常也能考虑到基础的流程、信息、界面。设计师强参与则是想得更深、更多、更细。
——当然每个团队面临的情况不同，具体问题具体分析。
业务上某个环节本身就和设计强相关，设计好坏对最终结果产生直接影响。如运营设计。
——这种情况可以理解为问题就归设计师管，设计师可发挥的空间非常大。具体推动的时候就要看合作方对设计师的认可度和信任度，是否愿意放权、放权多少给到设计师来发挥。
项目组内开发和设计合作有摩擦，需要优化配合的方式。
设计团队凝聚力提升，需要设计师群策群力。
有一些朋友在「问题定义」环节经常遇到困惑，觉得容易产生合作的问题：举个例子，如果边界界定不清楚，似乎我们在抢产品、运营、开发同学的活儿在干，于是会畏手畏脚。但是我对这个问题有不同看法，预期是可以沟通交谈的，所谓合作一定是一个大家都很舒服、彼此共赢的状态。
正如下图所示的逻辑，如果边界重合，其实对结果是好事，因为我们把中间没有想到的坑都填了；如果中间存在缺口，那我们就通过沟通把缺口补齐。
PS：有一个挺有趣的现象，其实随着整个行业体系化发展，知识的鸿沟在减少，现在缺口的场景越来越少。回顾移动互联网刚刚发展起来的那几年，经常知乎、专业网站上面有讨论「xxx 如何撕逼」这样的合作问题，而现在则更多是「怎么做得更多更全面」这样的讨论。
过程是思维、手段、方法、时间过程的集合。每个环节的侧重点在哪，每个团队都不一样，而这也一定程度上和预期有关。
这中间可以挖掘的要点就是如何「更科学」、「更」，可以输出经验总结、方法沉淀。这些也是赋能价值的表现。
「如何」是一个难点，因为我们要突破现有的思维、方法、手段，不然怎么「更科学」、「更」。不过无论怎么突破，身为个体，离不开我们的思考，「知己知彼，举一反三」：
文章来源：站酷 作者：
heychen思录
闲着没事儿写了个小 demo ，获取手机上已安装应用信息，系统应用和 非系统应用
MD5 SHA1 SHA256 签名信息 点击签名信息可复制到剪切板，
GitHub：https://github.com/sunan-n/GetAppInfo
如下图：
<span style="white-space:pre;"> </span>主要就是这个方法，传参数进来获取相应的签名类型 信息<br />
public static String getSignaturesInfo(Context context, String packageName, String tpye) {<br />
// //获取包管理器<br />
PackageManager pm = context.getPackageManager();<br />
//返回包括在包中的签名信息<br />
int flags = PackageManager.GET_SIGNATURES;<br />
PackageInfo packageInfo = null;<br />
try {<br />
//获得包的所有内容信息类<br />
packageInfo = pm.getPackageInfo(packageName, flags);<br />
} catch (PackageManager.NameNotFoundException e) {<br />
e.printStackTrace();<br />
}<br />
//签名信息<br />
Signature[] signatures = packageInfo.signatures;<br />
byte[] cert = signatures[0].toByteArray();<br />
//将签名转换为字节数组流<br />
InputStream input = new ByteArrayInputStream(cert);<br />
//证书工厂类，这个类实现了出厂合格证算法的功能<br />
CertificateFactory cf = null;<br />
try {<br />
cf = CertificateFactory.getInstance("X509");<br />
} catch (CertificateException e) {<br />
e.printStackTrace();<br />
}<br />
//X509证书，X.509是一种非常通用的证书格式<br />
X509Certificate c = null;<br />
try {<br />
c = (X509Certificate) cf.generateCertificate(input);<br />
} catch (CertificateException e) {<br />
e.printStackTrace();<br />
}<br />
String hexString = null;<br />
try {<br />
//加密算法的类，这里的参数可以使MD4,MD5等加密算法<br />
// MessageDigest md = MessageDigest.getInstance("SHA1");<br />
MessageDigest md = MessageDigest.getInstance(tpye);<br />
//获得公钥<br />
byte[] publicKey = md.digest(c.getEncoded());<br />
//字节到十六进制的格式转换<br />
hexString = byte2HexFormatted(publicKey);<br />
} catch (NoSuchAlgorithmException e1) {<br />
e1.printStackTrace();<br />
} catch (CertificateEncodingException e) {<br />
e.printStackTrace();<br />
}<br />
return hexString;<br />
}<br />
<br />1.集成高德地图发布版和调试版的sha获取的问题
调试版，进入 ~/.android
执行
keytool -list -v -keystore debug.keystore
可以获得sha
2.发布版的sha获取需要找到发布版的key文件，例如
/Users/aboc/keys/phpec/key.jks
然后执行keytool -list -v -keystore /Users/aboc/keys/phpec/key.jks
会需要输入密码，密码在项目
android/key.properties 这个文件夹中，但密码是在创建的时候生成的
3.安卓打包的签名就是上面文件里面显示的md5
可以使用 一.查询keystore的MD5
可以在运行窗口，定位到keystore所在的路径，(以android默认keystore为例)执行cd /Users/aboc/.android定位到.android下
执行下面这条语句后就能显示Key的所有信息
keytool -list -v -keystore phpec.jks
这个方法获取到md5
或者用这里的这个工具
https://developers.weixin.qq.com/doc/oplatform/Downloads/Android_Resource.html
蓝蓝设计的小编 http://www.lanlanwork.com