上个星期，公司内部的信息管理系统第一版算是完工了。有点经验教训得及时记录一下。
1. 系统刚刚登陆的时候，程序员们没有任何操作，也不一定有人把他拉到某个项目下面，所以这时需要一个默认的页面，类似于欢迎、或者暖场，但是做交互设计的时候没有考虑到。等到系统上线了才发现并没有这个默认的页面。
2. 由于该系统是Web的，后面我会参与到CSS的调整修改，因此在UI设计的早期环节，或者说交互设计的后期，应该考虑一下信息的架构。或者说，在着手绘制设计稿的时候，最好就一并思考一下组件的分布。比如哪些属于titlebar，哪些属于featurebar，container和table表等等的布局关系。
3. 之前一直秉持的态度是让工程师先开发吧，后面再改样式表，但是后来发现，很多DOM层面的嵌套已经被写死了，修改起来虽然并不困难，但是总是需要一遍遍地找程序改，归结起来，可能还是自己的经验不足。
先写这么多，其实不止这些。
天气炎热，人心难免浮躁。
来到招行信用卡中心上班后，由于公司对上网的种种限制，导致一直没怎么光顾以前经常上的设计网站。周末在家，终于有时间可以好好地畅游一下这些老地方。
现在的用户体验设计圈有点像地理大发现的时期，各种各样的新鲜设计工具层出不穷，各种各样的设计规范、设计理论应接不暇；从国外的设计博客到国内的设计网站大家都在谈论动效设计并争相上传自己的作品，设计圈的大街小巷里都在谈论如何创造牛逼的交互、精致的产品。同时，人们还依然为交互、视觉这样概念化的职能范畴辩论不休。
我想在这个设计的大发展时期，对于年纪不大但是也上了点年纪的用户体验设计从业者来说，是有些难熬的。
关于我们这个行当有非常之多的称呼方式。更多的时候我们喜欢把自己称为UX设计师，或者叫用户体验设计师，而不愿意叫自己UI设计师，这是因为前者听上去好像还高端一些，可能是由于有个X字母在里面，后者听上去则感觉像处于产业链条的中下游。
Read More
这篇文章取自SmashingMagazine, 作者Bryan James前段时间做了个独立站，名叫“In Pieces”，在前端和设计圈里火了一阵子。这篇文章讲述了他是怎样利用CSS的Clip-Path的属性来构建这一切的。
原文链接：www.smashingmagazine.com/2015/06/02/the-making-of-in-pieces/
基于Web的展示形式经常被用来推广各种高端产品。CSS的Clip-Path属性很少有人知道，在我（指作者，以下同）学习了这个属性之后，我用了五个多月的时间构建了自己的线上产品In Pieces，它旨在让人们去了解世界上30种濒危物种。这个网站不光在展示这些动物，用户还可以深入了解一些数据、下载壁纸、甚至获取一系列的海报。此外，网站支持移动设备。
In Pieces始自代码实验而非一个宏大的计划。2014年年中我接触了CSSClip-Path中的Polygon属性，觉得它具有非常大的前景。几个月过去了，我发现人们好像都没有怎么在Web上应用它，可能是大家都在使用SVG、canvas以及WebGL的原因。我觉得Clip-Path是个好机会，可以创造点之前人们没有想过的新花样。
如果你没有接触过Clip-Path，Dirk Schulze有一篇教程可以看看，非常不错。举个栗子，讲一个常见的四角div转成一个三角形可以通过下面的办法：
.polygon-div {
-webkit-clip-path: polygon(0% 0%, 50% 100%, 100% 0%);
}
我想知道的第一个事就是polygon属性与CSS过渡属性能不能结合。幸运的是，他们可以在一起。
.polygon-div {
background: #f00; width:100px; height:100px;
-webkit-clip-path: polygon(0% 0%, 50% 100%, 100% 0%);
-webkit-transition: 1.8s cubic-bezier(.7,.3,0,1);
}
.polygon-div:hover {
-webkit-clip-path: polygon(20% 59.35%, 30% 58.95%, 40% 61.08%);
}
了解了技术特性，我便开始构思项目。我的想法是要让展示的多边形具有美感，要有一种视觉上的亲和力。也许多边形的动物是个不错的尝试。首先，我搞清了一件事：多边形在艺术方面可不是一个新鲜事物,在Behance这样的艺术作品集网站上，随便搜一下“Polygon animals”就能找到很多相关作品。这一点对于“创意”这个词来说很重要。我看过关于那些作品的评论，有的人提到“折纸风格”，有的人提到“多边形风格”，但这只是视觉层面的，深入点说，这些构造图面的方式是一种碎片化的处理，它隐喻着事物本身就是“碎片化”的，他们的存在也是“碎片化”的。如果没有想到这个层面，那我的项目只能是个形而上的作品。
将技术融于设计和艺术中是一件非常浪漫的事情。
其他创意也接踵而至，比如我想要每个展示的动物用30个碎片来构成，同时展示的数据也要用碎片来表达。下面放点干货，讲讲我是怎么深入到技术细节的。
每个动物形象都是我亲手创作的。如果你仔细看我的代码就会发现，每个动物都是由30个div彼此堆叠构成，嵌套在一系列的父级div里。然而这30个div又同时隶属于30个动物。
最简单的方式就是在Ai里构图。创作出30个动物确实有点繁琐，但从另一个角度讲也是整个项目中简单直接的一个工作。主要是受到多边形数量上的限制。
接下来我把这些动物示意图放进浏览器中勾画他们的路径。考虑到有30个示意图需要转换成代码，绝望的我需要一个更加速度有效的方式。我设计了这样一个流程：把30个多边形放到指定位置，然后分别移动他们的点对准下面的PNG。有一些线上的工具，比如「CSS Plant Generator」、或者Bennett Feely的「Clippy」，都能帮助我们勾勒clip-path需要的端点。但是我需要的是更为定制化的工具，因此我用Js做了下面这个功能：
解释一下：
· mouseX 和 mouseY 表示点击时的鼠标位置
· shapesoffset 表示div与浏览器窗口左上角的距离
· shapesmouseX 和 shapesmouseY 表示鼠标在polygon-wrap中的相对位置
· mousepercentX 和 mousepercentY 计算鼠标在polygon-wrap中的百分比
· finalmouse 和 normalised 将十进制的百分比转成CSS接受的值
· nodecount 表示我在屏幕上点击了多少次。因为所有的多边形都是三角形，所以这个数字记录从0到3，然后循环回0。
这个函数能够让你在屏幕上点击三次，然后勾出一个三角形的div，三角形的端点就是基于百分比的。你的每三次点击就会生成一个字符串，以浏览器Alert的形式输出位置信息，这样你就能把这些位置复制黏贴进你的CSS里。如下图：
我们需要做的还不仅仅是勾画多边形的路径，我们还需要知道每个多边形的颜色。从Ai里复制每个颜色再拷贝进Sublime里太麻烦了。其实有个应用可以帮助我们：「Sip」，它能够直接吸取颜色放在剪贴板中，随时准备输出给CSS。
这样，我就能够吧30个动物一个一个地用代码表示出来了。但紧接着又一个麻烦出现了。如果你要两个矢量图形彼此紧挨着，他们之间会出现一条虽然微弱但很显眼的线，就像Ai中那样。所以我需要小心谨慎地调整一些点的位置，好让这些碎片互相之间有些重叠。麻烦在于：我怎么知道我要调整的多边形是究竟是哪一个？（译者：这就有点像有个10胞胎的母亲，看着自己的一堆孩子里有一个犯错了，但是母亲怎么才能知道叫那个犯错的什么名字）这时候CSS多边形的另一个优势来了：它们能够像遮罩一样把图像放进去。这样，我做了30个背景图片，每个图片都满是重复的数字。我把每一个图片都顺序地放进相应的多边形里，这样，我就能够直观地看出我要调的多边形是第几个了。
In Pieces很大程度上根植于类名的增删改，其实每个动物都是一样的，本身没有区别。我们只需对父级div改个类名就可以实现CSS的变化。这些动物以数组的形式存储：
var animalList = [‘crow’, ‘vaquita’, ‘tamarin’, ‘frog’, ‘owl’, ‘turtle’, ‘oryx’, ‘iguana’, ‘seahorse’, ‘armadillo’, ‘sloth’, ‘kakapo’, ‘echidna’, ‘penguin’, ‘damselfly’, ‘bear’, ‘parrotfish’, ‘camel’, ‘butterfly’, ‘ostrich’, ‘panda’, ‘tapir’, ‘sifaka’, ‘lynx’, ‘rhino’, ‘peccary’, ‘okapi’, ‘loris’, ‘hirola’, ‘drill’ ];
每当一个新的物种被引用，我都会让它产生这样的变化：
prevAnimal = ( animalList.indexOf($(‘#animalchanger’).attr(‘class’)));
这其中，#animalchanger是控制物种们的父元素，被设定成animalList中的某个字符串值。这行代码决定了目前这个动物在物种列表中的索引。这一切都是为了创造newAnimal变量。比方说，界面中有一个按钮叫做“下一个动物”，它背后的代码是这样的：
newAnimal = prevAnimal + 1;
当然同时还会有其他很多代码伴随着发生，但是新的动物的索引一旦创建，我们就可以把它放在div的类中：
$('#animalchanger').attr('class',animalList[newAnimal]);
现在你知道多边形是怎么做的，同时也知道了通过类名的改变来操作每个物种共用的多边形。下面才是最好玩的：动画！
之前讲过，所有的都是基于CSS的，运动也是一样。为此，我设定了一系列的基础过渡（base transition)，好让用户的每个操作都能显示合适的动作。
不过有个事我要提一下，在上面的代码例子中，我们要计算下一个动物是从左进入还是从右进入。
if (prevAnimal > newAnimal) {
$('.wrap').addClass('right-to-left');
$('.wrap.left-to-right').removeClass('left-to-right');
} else {
$('.wrap').addClass('left-to-right');
$('.wrap.right-to-left').removeClass('right-to-left');
}
这个需要通过SASS的for循环来实现。
$fluidpolygons: .7,.3,0,1;
.left-to-right {
@for $i from 1 through 30 {
$s: ($i*0.04+0.3s);
$t: ($i*0.02s+0.2s);
$ct: ($i*0.02s);
:nth-child(#{$i}) {
transition:
-webkit-clip-path $s $t cubic-bezier($fluidpolygons),
background-color $s $ct;
}
}
}
.right-to-left {
@for $i from 1 through 30 {
$s: ((31-$i)*0.04+0.3s);
$t: ((31-$i)*0.025s+0.2s);
$ct: ((31-$i)*0.02s);
:nth-child(#{$i}) {
transition:
-webkit-clip-path $s $t cubic-bezier($fluidpolygons),
background-color $s $ct;
}
}
}
看到了吗，有多种多样的速度和延迟属性可供使用。Sass的for循环用来改变过渡的时间和延时效果，取决于多边形的索引。比如说，一个从左至右的运动，第十个多边形会有一个0.7秒的过渡效果外加一个0.4秒的延时。反过来的方向则仅仅是翻转一下顺序——将索引号减去31即可。
动物们不是通过CSS动画移动的，原因是我不喜欢中途突然发生“插进去”的那种突兀的效果。我设定了两个种状态：初级运动和次级运动。
function animalStates(e) {
setInterval(function(){
e.removeClass('state-four');
setTimeout(function(){
e.addClass('state-two');
}, 1000);
setTimeout(function(){
e.removeClass('state-two');
e.addClass('state-three');
}, 2000);
setTimeout(function(){
e.removeClass('state-three');
e.addClass('state-four');
}, 3000);
},4000);
}
function animalStatesSecondLevel(e) {
setInterval(function(){
setTimeout(function(){
e.addClass('two-state-two');
}, 1000);
setTimeout(function(){
e.removeClass('two-state-two');
}, 1100);
setTimeout(function(){
e.addClass('two-state-two');
}, 1400);
setTimeout(function(){
e.removeClass('two-state-two');
}, 1500);
},3000);
}
每个状态实际上都是替换了新的CSS，而多边形只是移动到新的位置、改变下颜色之类的。重要的是，一旦“动画阶段”开始（也就是一个动物完成了它从上一个动物的变形），多边形上一个过渡的时间属性以及延时属性就会被重写。
比如下面的Gif，你可以看到，animalStates控制着金毒蛙的生囊运动，而animalStatesSecondLevel控制着眼睛的眨动。
Clip-Path属性在大多数主流浏览器中都能被支持，是的，除了IE。此外，火狐浏览器也有点小问题，因为他们对于这个属性是基于SVG路径的，意味着对坐标系的变换要在CSS之外完成。这时我的降维（译者：原文用词是Fallback，指的是网页设计中使用了前沿技术的同时还能考虑到老浏览器的用户的做法）方法是这样的：如果用户在他们的浏览器中无法看到那些动物们的过渡、动画、转场效果，那么我就仅仅是给他们一系列的图片，简单地做个幻灯片效果，视觉上其实差不多，这些用户一样能够理解我这个项目的意义所在。
使用Clip-Path，你不可避免地会遇到一堆问题，尤其跟当转场过渡结合的时候。首先，他们在应用了透明属性的过渡时就不能产生叠加效果——有时候他们干脆就不发生任何变化，就像老电视机接不到信号了。
之前提到过，我是用了一大坨的父div来实现位移、旋转和缩放的。如果不做这些嵌套，光是这些多边形直接的变换就产生了大量的问题，问题多到差点直接让我放弃这个项目。
原则上来说，retina设备支持Clip-Path是没问题的，少量的多边形还没什么问题。但是当有30个多边形的时候，就出现了之前说的透明度堆叠的问题。比如说，你会注意到在非Retina的桌面屏幕上，我在小动物的周围加了一些装饰，让视觉上看起来完整一些，但是在Retina设备上，除非我把它们去掉，否则程序就不运行。
毫无疑问，为了获得良好的性能，我还需要做很多优化工作。之前提到了，Retina上面有一些瑕疵，需要移除一些东西。但是我也做了很多CSS的工作，让其更加整洁，帮助网站运行地更加平滑。
想一下吧，你让浏览器在同一时间处理30个物体的移动，这很可能会出问题。但如果你给一个0.199秒的动画配上一个0.200秒的延迟，其实就等于同一时间只移动一个物体。事实上，如果动画是一个链式结构一个个进行，性能几乎可以提升30倍。
制作主菜单这一环节是我最喜欢的，制作它的方法我还用在了很多别的地方上。
你们能看到的菜单像一个圆圈一样具有宽度和高度的尺寸，但其实整个div是建构在一个没有宽和高的父级div上的。这个位于界面中心的父div包含有30个独立的div表示各个物种，同时每个物种还带有伪元素用来创造交互动作。但是整体其实十分简单，我想给你们展示一下它们是如何放置的：下面是一个非常简单的代码
.hover-detector {
div {
position: absolute;
left: 0; top: 0;
margin-left: -35px; margin-top: -35px;
width: 70px; height: 70px;
@for $i from 1 through 30 {
&:nth-child(#{$i}) {
$r: ($i*12deg - 7deg);
@include transform(rotate($r) translateY(-230px));
}
}
}
}
这里，30个div元素被引用为div。我使用了Sass的for循环好让每个div以其中心锚点为参考转移至相应位置。总共30个元素，因此，每12度转个角，然后让元素离圆心偏离230个像素。
类似D3这种工具可以极大地扩展我们与可视化数据之间的交互，脱离方块、圆圈等几何限制，我们可以创造具有触觉的信息。
CSS多边形也可以用这种方式实现，非常简单。在In Pieces的可视化图表中，我用了跟制作主菜单相同的技术，只用了一个单一的div结合clip path的变换，我就可以在圆形表格中放置那些数据和数字。
下面这行代码展示了如何快速方便地制作一个上图那样的极坐标表格：
-webkit-clip-path: polygon(31% 4%, 66% 11%, 84% 36%, 81% 63%, 60% 74%, 43% 68%, 37% 55.5%, 42.5% 47%);
整个项目的标题带有一种刮痕的纹理。这用到了CSS的新技术：给文本加上图片遮罩。
仅针对Webkit浏览器，下面是用来实现这个效果的代码：
.textured-type, .animal-nav-content h2 {
background:
url('../img/textured-ui/repeat-white.png') center center repeat;
background-size: 80px 60px;
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
animation: scratchy .253s linear forwards infinite;
}
keyframes scratchy {
0% { background-position: 0 0; }
25% { background-position: 0 0; }
26% { background-position: 20px -20px; }
50% { background-position: 20px -20px; }
51% { background-position: 40px -40px; }
75% { background-position: 40px -40px; }
76% { background-position: 60px -60px; }
99% { background-position: 60px -60px; }
100% { background-position: 0 0; }
}
它本质上就是融合了基本的CSS文本遮罩技术以及Webkit浏览器的CSS动画，简单地将文字的背景图片快速周期性地移动，创造一种动感的刮痕感。
人们对In Piece的反响令我震惊。我们可以针对“在客户项目中做Webkit-only的网站是否合适”这种问题讨论一整天。然而实际的点击和公众的反馈显得更有意义多了。我觉得未来，CSS的多边形可以有巨大的潜力。
欢迎来到这个博客。
这里登载的内容，大都与设计有关，偶尔会有关于职场的心得或是前端的学习经验。
写博客暂时没有什么别的商业目的，只是为了记录学习的经验，同时锻炼文笔。
这个网站基本是在业余时间进行维护的，除了定期上传我的作品以外、我还会时不常地创作点自认为有趣的试验品。
博客的更新不会很频繁，但我会力求每一篇文章都是精心之作。
希望来访的人能够喜欢。
早上继续每天的Js学习，看到了客户端检测（Client Detection）这一章，其中讲到了User Agent。
《Javascript高级程序设计》中，对User Agent的检测方法所持的态度是“有争议的”。书中推荐的是依据功能需要的语法能力识别（Capability detection），然后是浏览器习性识别（Quirks detection），两种都不行，再考虑User Agent方法。UserAgent最具争议的地方就是欺骗性（Spoofing），也就是通过发送的字符串来伪装成某个浏览器。
想起以前做我查查购物助手的时候，360安全浏览器就没法检测，因为它就一直把自己伪装成Chrome。听说是有一段时间各大互联网公司集体反360的后果。只是听说，不多说了。
书里面继续讲述了UserAgent的历史
————翻译开始————
关于HTTP 1.0和1.1的规范，浏览器在请求时应当发送一个字符串来指代其名字和版本。
第一个网页浏览器，1993年出自美国国家超级计算中心的Mosaic的User-agent是这样的：
Mosaic / 0.9
意义就是这是Mosaic浏览器，版本是0.9。
后来网景公司推出自己的浏览器，内部代号Mozilla，其实是Mosaic Killer的缩写（看到这我真笑了，有点像后来苹果研发Iphone时经常拿Palm开涮的感觉，许多测试文本都是“It’s not a Palm, damn”）。网景浏览器二代是第一个被大众广泛使用的浏览器，User-agent格式如下：
Mozilla / Version [Language] (Platform:Encryption)
网景浏览器保留了把产品名和版本号放在开头的传统，同时加上了下面的信息：
·Language：使用地区的语言
·Platform：使用的操作系统，或者浏览器是基于什么应用的
·Encryption:加密方式。包括U（128位加密）、I（40位加密）、N（不加密）
一个典型的网景2发出的User-agent是这样的：
Mozilla/2.02[fr](WinNT;I)
意为：网景2.02，法语国家使用，运行在WindowsNT，40位加密。
那个年代，通过User-agent来识别浏览器还挺方便的。
96年，网景3发布了，成为了当时最受欢迎的浏览器，风头盖过了Mosaic。User-agent只经历了点小变化，去掉了语言标识符，允许传递CPU的信息:
Mozilla/Version ( Platform;Encryption [;OS-or-CPU description])
紧接着魔头微软发布了IE3。但是由于当时的网景太火了，以至于很多服务器端都要先看看是不是网景然后再提供页面。这就导致了IE没法访问很多页面。于是微软不得不在发出的字符串中稍作修改，以与网景浏览器适配。这样就产生了这种User-agent格式：
Mozilla/2.0(compatible;MSIE Version; Operating System)
比方说，跑在Win95上的IE3.02的User-agent是这样的：
Mozilla/2.0(compatible; MSIE 3.02; Windows 95)
由于那时大多数的浏览器识别就是看看你User-agent的前半部分，所以IE成功地伪装成了网景浏览器。这种做法实际上违背了浏览器标识符的一些初衷，真正的浏览器版本号被掩埋在了字符串中间。
97年的秋天，网景发布第四代浏览器，名字也从Navigator（导航者）变成了Communicator（沟通者）。User-agent则继续保持3代时的格式：
Mozilla/Version ( Platform; Encryption [; OS-orCPU description] )
这样，一个跑在Win98上的4代网景，user-agent是这样的：
Mozilla/4.79 (Win98;I)
同时期发布的IE4，User-agent长这样：
Mozilla/4.0 ( compatible; MSIE 4.0; Windows 98 )
这样，两者又在版本号上保持一致了，都是4.0。不过，同步也就到此为止。后来当IE4.5亮相在Mac上时，Mozilla的版本还是4，而IE的版本号变成了4.5：
Mozilla/4.0 ( compatible; MSIE 4.5; Mac_PowerPC )
到了IE7，形式还是差不多：
Mozilla/4.0 ( compatible; MSIE 7.0; Windows NT 5.1 )
直到IE8引入了一个新的标识符，叫Trident，表示渲染用的引擎，格式就变成了下面这样：
Mozilla/4.0 ( compatible; MSIE Version; Operating System; Trident/TridentVersion )
Trident标识符是用来帮助开发者决定IE8是否跑在兼容模式下的。通过这个标识符，就能判断一个浏览器是IE7还是兼容模式下的IE8。
IE9轻微地改了一下格式：Mozilla版本号被写到了5.0，然后Trident版本号也被写到了5.0。一个IE9的默认User-agent长这样：
Mozilla/5.0 ( compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0 ）
当IE9跑在兼容模式的时候，旧的Mozilla版本号和MSIE版本号则被重写了。所以一个以IE7兼容模式运行的IE9，User-agent是这样的：
Mozilla/4.0 ( compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0 )
所有这些工作，就是为了能让老的user-agent识别脚本正确地工作。
火狐的核心就是Gecko渲染引擎。最开始Gecko是作为Mozilla推网景六代的一部分被开发的。在网景六代中，有一个详细的规范指导着如何书写User-agent。格式是这样的：
Mozilla/MozillaVersion (Platform; Encryption; OS-or-CPU; Language; PrereleaseVersion)Gecko/GeckoVersion ApplicationProduct/ApplicationProductVersion
其中，标识符的含义如下：
这样，一个运行在WinXP的网景6.21的User-agent可能是长这样的：
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/2011128 Netscape6/6.2.1
运行在WinXP的火狐是这样的：
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
运行在Mac上的Camino（我没听说过）是这样的：
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.6) Gecko/20070809 Camino/1.5.1
很多时候，识别出具体是什么浏览器已经不重要了，重要的是看它是不是基于Gecko的。也是从那时候开始，Mozilla的版本号5.0就再也没有变过，估计以后也不会变了。
火狐4推出以后，Mozilla公司简化了User-agent字符串。主要改动包括：
·去掉环境语言标识，也就是Language
·当浏览器使用强加密的时候，加密标识符Encryption也不显示了。
·平台标识Platform去掉了，因为在OS-or-CPU中已经包含的操作系统的信息。
·GeckoVersion被写死成了：“Gecko/20100101”。
这样，一个最终版本的Firefox4的User-agent是这样的：
Mozilla/5.0 ( Windows NT 6.1; rv：2.0.1) Gecko/20100101 Firefox 4.0.1
2003年的一天，苹果宣布将发布自己的网页浏览器，名叫Safari。渲染引擎则叫做WebKit。名字算是对KHTML的一个演变，这个KHTML曾被用做基于Linux的Konqueror渲染器的引擎。数年之后，Webkit分裂成了它自己的开源项目，专注于渲染引擎的开发。
针对这个新的浏览器和引擎做开发的人面对了当IE3同样的问题：你怎么知道那些著名的站点们能否识别你？解决方案则是把User-agent的信息扩充，好让那些站点相信这个浏览器跟主流的浏览器是兼容的。这导致了User-agent的如下写法：
Mozilla/5.0 (Platform; Encryption; OS-or-CPU; Language) AppleWebKit/AppleWebKitVersion (KHTML, like Gecko) Safari/SafariVersion
举个例子：
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1
有趣的点在这：“KHTML, like Gecko”，苹果那段时间遭受了很多来自程序员的声讨，因为这条字符串就像在戏弄客户端以及服务端，把Safari当成Gecko。苹果的反应跟当初的微软也差不多：我们为了兼容嘛~
Safari 3 发布的时候还在“Safari”前面加上了一条“Version/3.0.3”，不过还是跟Gecko一样，识别重点在于是不是WebKit浏览器，而不是具体是什么浏览器。
Google采用WebKit做渲染引擎，不过使用的是一个不同的Javascript引擎。Chrome的User-agent保留了所有从WebKit沿袭来的信息，同时加上了一小段给Chrome用的。格式如下：
Mozilla/5.0 (Platform; Encryption; OS-or-CPU; Language) AppleWebKit/AppleWebKitVersion (KHTML, like Gecko) Chrome/ChromeVersion Safari/SafariVersion
于是，一个Chrome7的User-agent写法如下：
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.7
(KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7
貌似Webkit版本号和Safari版本号要这么一直同步下去了。
iOS和安卓的默认浏览器都是基于Webkit的，因此具有同样的User-agent字符格式。iOS设备浏览器的格式如下：
Mozilla/5.0 (Platform; Encryption; OS-or-CPU like Mac OS X; Language) AppleWebKit/AppleWebKitVersion (KHTML, like Gecko) Version/BrowserVersion Mobile/MobileVersion Safari/SafariVersion
注意哦，它增加了“like Mac OS X”来识别Mac系统，还增加了“Mobile”标识符。“Mobile”标识符被用来识别是移动版还是桌面版的Webkit内核。平台的识别则会以“iPhone”、“iPod”、“iPad”来表示。
比如：
Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us)
AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16
安卓浏览器的格式与iOS的相同，只是Mobile标识符后面没有版本号。
Mozilla/5.0 (Linux; U; Android 2.2; en-us; Nexus One Build/FRF91)
AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
———— 翻译完 ————
社交网络就是一颗毒品，会让人上瘾。你把你的喜怒哀乐放大化，po在网上，期待得到别人的窥视。你自己也不知道是不是真的想让人知道你的想法。你在给别人点赞的同时，也希望别人能为你点赞，就像一个交易系统。越是沉迷于其中，就越是无法自拔。
我几乎很少刷朋友圈，也不怎么上传朋友圈。就像以前的很多社交网站那样，它们会让你深陷其中。得意的时候发个照片，配上点文字，目的不外乎想给别人炫耀一下，或者想让固定的某些人看到它，失意的时候也发个自拍，想让别人感同身受，期待某些人能理解。其实无非是生活中的琐碎杂事而已，你的朋友真的能认真地去为你的喜悦而喜悦吗？能真正地为了你的苦恼而想办法吗？
我不反对社交网络，毕竟它有好的一面，它极大地降低了现代人分享的成本，我们遇到了好玩有趣的东西、能开阔视野增长见识的东西都可以拿来给朋友分享，同时我们也从朋友们的分享中增长更多知识。
但人的一生时间终究有限，尤其是年轻的时候，还是要把时间多花在修身、增长才干上。目前的朋友圈，给人带来的正能量极其有限。其实你就算不通过朋友圈去了解当今世事，以现在媒体的趋同性来说，你也早晚能通过其他渠道知晓这些东西。
网络让人们的注意力变得分散。一旦你发了个朋友圈，时不时就像看一下有没有人给你回复点赞，根本没法静下心来钻研什么。有这时间，多读读书多好。
我自己用Path，会把一些生活的点滴记录一下，只跟妻子分享，为的是以后可以回顾我这段时间做了什么。
不止一次在图书馆里，看到坐在对面跟我一样的年轻人，手里捧着几本书，一会看看手机，一会发发文字，我不知道他一个下午能看多少书，要我说你何必来看书呢，呆在家里，一边看剧一边摆弄手机不是更好吗？
当然，凡事也有例外。我的一个开公司的高中同学，每次相聚总是手机不离手。当然那是因为他加了很多群，里面有他的投资人、他的合作伙伴以及三教九流各色人等，他要做的是时刻掌握一些“信息”，尤其是他炒股，炒的是内幕，新鲜的信息非常重要，所以他总是泡在社交网络上，与其说我的这个同学是沉迷社交网络，不如说他是在利用社交网络。
一个人，可以用他在某一方面精湛的技艺、可以以他在某一领域相当深厚的专业积累，或者哪怕现实一点，用他的巨额财富，来赢得别人的尊重和钦佩。在朋友圈中将自己的一举一动、一言一行都展示出来，没有任何意义，每个人的时间都是有限的，人们只会去关注自己，以及那些跟自己的利益有关的人和事。
这是个残酷的现实。
如果现阶段还做不到充分利用社交网络，如果想在这个年纪有所提高，那我们还是要离社交网络远一点。毕竟在你还啥也不是的时候，你的状况、你的喜怒哀乐、你的任何想法，除了你自己，其实真没有什么人关心。
这也是个残酷的现实。
每一个行业，都有那么几头牛，与那么几座神。
随着职业生涯的不断进展，我们总能发现在自己所从事的这个行业中，存在着大牛人。
大牛们各有各的崛起之路，有点英雄不问出身的感觉。有的人几乎没有什么学历，有的人不是科班出身，他们可能是在机缘巧合的时候接触了某一领域，或者不经意间发现了原来自己对某某事物的喜爱远超过生活中的其他方面，于是奋然跃身其中，再加上自身有那么点天赋，更重要的是对这一领域的事物有着非利益驱动型的热爱和旁人无法比拟的投入，然后逐渐成长为了大牛，如果过程中得到高人指点，则更加省时。
大牛们的存在让我们总是想着要前进，他们就像行业标杆竖立在前面，时刻提醒我们不能松懈。
然而，除了大牛，还有另一类人，我管他们叫「神」。
如果说大牛们是在一个已知的领域不断进取，刷新新的战绩，为人们所学习，神们则更多的是在开创某个全新的领域。
为什么直到现在依然说包豪斯是现代设计的发源？那是在一个特定的天时地利人和下鬼使神差地让一群神们凑在了一起。他们的探索和尝试完全地打开了一个新的世界，直接或间接地改变了百年内世界的长相。
我们可以通过自己的努力，去做一头牛，但是若想成为神，除非有时运相济。
之前有猎头推荐员工宝的职位，他们让面试设计岗位的应聘者写一些关于他们产品的体验意见。于是我认真地体验了一下，写了点建议给他们。现在我还不知道我能否应聘的上，但不妨我先把这点东西分享出来。
总的来说，用户购买理财产品过程中被给予一种什么样的感觉？
我们平时购买东西会有这么几种体验：①被推销，常见于理发店被推荐洗发水、办公楼被推荐保险、冷不丁的情况下接到陌生人打来电话被推销投资店铺什么的 ②有购买意愿，但不够了解，比方说想买一个单反，但不知道什么牌子什么价位比较好 ③知道自己要什么，想花最低的价，比方说想买最新的iPhone，但是行货太贵，于是趁着去香港的道上顺一台。
理财产品大致是第二种，用户来了之后，肯定是由理财意愿的。他/她所想的，就是在这个平台上快速地知道什么适合自己，或者说自己口袋里那些钱，投什么能回的最多还风险最小。
作为一个用户，我关心的是这几个方面的问题：
1. 我钱包里可怜的XX元 * 我必须忍痛的XX个月 = 我能白捡的XX钱
能够直接或间接地告诉我这个公式，才能让我掌握情况。就像电商网站不光告诉你原价多少、现价多少，还要告诉你它等于打了几折一样，用户现在就是这么懒，你要帮他把一切需要他算计的东西都算好。
2. 用户购买了互联网理财产品后，除了按照先前所说的那样给用户以净收益，除此以外还能有什么特别的好处吗？
3. 这个平台能否在提供理财产品、理财信息之外，促进用户之间的联系，使他们在其中相互讨论、学习，这样既能提升用户活跃，也能拉高平台价值。
说完了大的方面，就说点具体的，可能说的不对、都是个人观点。
首先是视觉上的，用陆金所（http://www.lufax.com）的网站做对比
我用的是13寸的笔记本，作为登陆后的第一屏，陆金所提供的信息量大大多于员工宝的。陆金所的界面给人看上去像是一个稍微有点嘈杂的交易所，而员工宝则更像街面上高冷的专卖店。我想大多数来理财的用户还是会喜欢陆金所的这种感觉吧。
陆金所的界面更加强调数字。在陆金所的整体视觉中，很多时候数字都是被加强的。无论是从字号还是颜色上，用户关心的数字都会得到应有的突显。而员工宝则显得有些平淡。我没法说这两者的好与坏，就像人们吃饭有重口有清口。但是我觉得就提高转化率的方面来说，应该还是陆金所的设计要有效一些。
然后是交互上的
还是老生常谈的问题，当使用Tab来横向切换内容时，如果内容刚好是一个瀑布流下来的，那么切换最好加上一个过渡效果，好让用户知道我被指引去了哪里。
列表是一种用的十分多的交互模式。但是越是平常的东西就越是需要引入注意。
列表的使用可以分成两种情况：
1. 用户浏览列表的目的是搜索确切项目时，可以使每条列表项尽可能简短，只展示关键信息 并在信息结构上尽量保持一致，这样有助于用户在快速滑动列表的时候迅速发现目标的不同
2. 如果用户的浏览是希望在列表项之间比较进行对比、甄选和归类时，则需要列表项之间 在信息上有些人为的区分，以方便用户在头脑中标记关键项，进行下一步的筛选
出现在员工宝首页的列表，显然是为了让用户在众多理财产品中选择性地挑选。用户在列表中浏览时会根据他的个人偏好，以决定是否进入一个产品查看详情。这时，员工宝的列表项则显得太过雷同，而且没有图片来帮助用户在头脑中标记产品，所以我认为是不利于用户进一步走向购买路径的 ·这就好比我们在商场买东西，希望售货员能够为我们分析各个同类产品的优缺点。
除此之外，我还写了一些其他方面的建议，不过更偏产品方面，超出设计的范畴了。
花了将近3个月，每天的早晚班车时间，终于把这本英文版的Jony Ive给读完了。最开始1天只能看10页不到，后来基本上两天一章。网上对这本书褒贬不一，有的说这本书是做设计的人都应该看看，有的说这本书对Ive在苹果方面的工作写的不够多。我感觉这本书还是很值得读的。Ive在苹果的很多工作到目前还是极度的保密状态，书中也提到过，就连从苹果离职多年的工程师，在回忆此前的工作时也是有的说有的不能说。书作者能调研那么多人捞到这些材料已经实属不易。毕竟用报道和记叙的方式描述一个当下还活的好好的人不是一件轻松的事情。下面是读书笔记————
Ive的父亲，Mike Ive是一名银匠。他从小就鼓励Jony拆装各种工具和物品、理解不同的工具是怎样被设计和使用的。可以说很早地就在开发Ive在设计方面的天赋。
Ive在纽卡斯尔理工（现在叫诺森比亚大学）获得了工业设计的学位。那座学校被认为是英国工业设计最好的学校。他们的设计教育秉承的是从德国包豪斯延续下来的方法。如果说美国式的设计教育是让设计师更好地服务于产业，把学生培养成为一个好的雇员，英国式的教育则更倾向于实验性质，鼓励学生们去追求有激情的东西。
入大学的第一天，别的学生正在参加学校的开学典礼，Ive则是去别的地方去领设计奖项，他在高中就已经开始参加设计比赛并拿奖了。
纽卡斯尔被人们称作Party Town，意思就是总是有各种各样的party可以参加。但是Ive回忆他的大学生涯却感觉没那么有意思，“除了在学校里认真学习，几乎什么都没干过。“
学校里的讲师回忆Ive的时候，形容他为一个聪明且刻苦的学霸。“他对待工作的态度细致地让人难以置信，他对他的作品总是不满意，总是在想尽一切办法来提高。”
有很多设计师相信，设计前期做的调研越多，最后的结果就越趋向于完美。但是Ive的方法一般是：迅速抓住问题的核心本质，创造出直观的解决办法，同时兼顾可行性、优雅度以及对细节的考虑。
Ive曾和两个朋友一起开办过设计事务所，取名叫橘子（Tangerine），为了生存，他们不仅要承接各种设计服务，同时还要扩展知名度。采用的办法就是把他们认为好的作品（或仅仅是模型）拿出来在设计杂志上面做广告。但是Ive很不适应这种工作，他只想全身心地投入设计工作，对运营、市场等等方面既无兴趣也无经验。（我认为这一点也是后来乔布斯去世后Ive根本不会去争取CEO位置的本质原因）
在设计事务所期间，Ive工作的也不算太顺心。他总是想创造出完美的东西，有时候他的设计甚至极为前沿、超越了当时的时代。但是客户并不总是很理解。经历过几次投标失败之后，Ive开始对设计公司的工作感到失望。后来他回忆起这些，说到“非常重要的是，我想明白了我适合做什么、不适合做什么。我只对设计感兴趣。但是在怎样建设一个公司方面，我实在不在行。”
在开发iMac G3的过程中，艾维和他的设计团队提出了一种新的造型，在显示器的后面加上一个把手。这个把手其实没有具体的用处，人们也不会随便拎着这个把手来回走，但是用艾维的话讲，这个把手极大地提升了电脑给人的亲切感。
“在那个时候（90年代），人们对于技术产品还不是很适应，如果你对一个东西有恐惧感，你就不会去碰它。所以我想，如果有一个把手在上面，就能在人和产品间塑造一种联系。它很直观，让你可以去碰它，让你感觉它跟其他的电脑可不一样。”
这个设计受到了工程师和生产商的反对，但是好在乔布斯喜欢。在艾维给乔布斯做提案的时候，乔布斯感觉非常酷。没用艾维怎么费口舌，乔布斯就感受到了iMac那亲切、有趣的设计特点。
Norman回忆道：他（乔布斯）更关心的是产品应该是什么样子，根本不会去听反对意见。为了得到正确的结论，他会在做决定之前倾听别人的意见，但是一旦做了决定，就连神仙都改变不了他的主意。
iBook的最初想法来自头脑风暴，而不是焦点小组或市场调研。后来Ive回忆起来，“我们不会去做焦点小组，尽管那也是设计师的责任。”
“如果你去问人们明天的设计应该是什么样的，这十分不公平，因为大众根本没有这个概念”
PowerBook的设计中引入了磁力闩，使得开合笔记本变得非常容易有趣。在谈到细节是如何将一个好的产品变成一个伟大的产品时，Ive说：
“关键在于对事物要保持近乎狂热的观察，哪怕它们已经是平淡无奇到无以复加了；而且要对细节有一种几乎是强迫症般的关注，即使它们已经被看了无数次了” ——原文：
” The decisive factor is fanatical care beyond the obvious stuff, the obsessive attention to details that are often overlooked “
Jony 对PowerBook的内部构造很满意，也很骄傲。在设计博物馆2003的年度展览上他还亲自拆了一台。
“把它拆开来看，你就会发现我们对那些你们看不见的地方有多么地关注”Jony说“我认为而且期望着产品的内部结构、产品的塑造工艺与产品本身都应该有一种一致性的美，比如说如何把铝材质的部件激光焊接在一起等等…”——原文：
“We took it [PowerBook] to pieces so you can see our preoccupation with a part of the product that you’ll never see,” Jony said. ” I think – Ihope there’s an inherent beauty in the internal architecture of the product and the way we’re fabricating the product: laser-welding different gauges of aluminium together and so on…”
工作中，一想到我们才只是不过是刚刚开始，还有很多东西可以做、还有很多地方可以努力，我和我的团队就倍感精神，最振奋的事情莫过于此。”——原文
“One of the great things about our team, about working so closely together,”Jony added,”is the feeling that we’re really only at the beginning of something, that we have only just started. We still have lots more to do.”
