Android所受到的追捧，无非也就是那些希望分到新操作模式下市场厂商的一种无奈惊喜。

不过，苹果在使用界面上还有一个特征就是全屏操作模式，可以说这种模式优点和缺点都共存。但全屏操作相对于多窗口操作模式来说，更适合于手势操作。因为 在固定区域上，手势具备唯一操作特性，例如用两指不同方向的划动，代表移动操作面，或其他指令，如果是复合的窗口则让指令变得复杂和莫名其妙，可以说，不 论是Android还是WP7，或WebOS都没有特别的理解手势操作的真正优势所在。

把手势操作常态化，还是苹果把iOS操作引进MacOSX的重要桥梁。例如在屏幕和触摸版之间，由于无法直接对应，而手势就可以取代按钮的作用。你可以用不同手势对计算机发出指令，而不是在屏幕的某个区域或位置准确按下。

现在苹果已经成功的把旋转，缩放，划动等手势操作成功的引进到操作界面。相信将来会有更多的程序操作是依赖于手势驱动指令。例如四指收缩表示抓取，四指 放大表示释放，四指抓取后，可以移动，这样就取代了原来的拖放操作，比原来更加直觉有效。目前采用的依然是两次操作，例如双击锁定拖拉对象，移动后，单击 释放。

在MacOS里面，三指和四指划动可以呼唤出特定的功能，例如程序切换，空间转移等等，但这样的定义还不够直觉。

因此，未来苹果的操作系统会引进更多的手势。

那些参与到app开发的企业，也会找机会大幅度拓展手势应用的范围，这些年，手势操作的SDK和API苹果每年都有不断的进步。

苹果在iPhone，iPad和Mac的手势操作进化中也不断分化，例如，iPhone可以更多借助于加速度传感器，陀螺仪，来实现更多的手势操作，例 如晃动，旋转，但这样的操作对于iPad来说则不那么实际，而Mac则基本无法使用这些操作优势。但也许将来的Magic TrackPad会提供这些传感器。但在桌面上就不是那回事。

不过iPod Touch则可以提供类似的遥控功能。把iPodTouch或iPhone作为遥控器也是很多应用的一个途径。

为了突破苹果的优势领域，其他厂商必须能够找到崭新的操作模式。就像微软的Kinect一样创新的模式才可能成功。但这种投入则不是一般公司所能胜任的。

个人在分析iOS产品优缺点的时候，曾经提出过按钮复合操作的概念，这就像当年单键鼠标和CTRL键结合的概念一样，例如当我们按下按钮来划动时可以实 施拖拉，抓取锁定等操作，苹果的趋势是取消按钮，而其他厂商可以反其道，更多的手势操作模式，可以有效区分产品，突破苹果的专利限制，而给用户更多的选 择，毕竟这种操作也是可行的，而且也很方便。如果普通的单指划动，配合两个按钮就可以实施常见的手势操作了。

而这种操作在Mac系统下利用键盘和触摸板很容易实现。

如果iPad和iPhone还可以大量使用Click操作，也就是定点点击操作，对于把手势操作引进的AppleTV和Mac则很难实现。因为手指的操作面和视觉操作面是分离的。

传统基于鼠标定位的转换操作模式下，Click是基本操作。由此而发展出庞大的UI指令系统。以按钮，快捷键来实现复杂的操作，而iPad和iPhone是对这种操作的一个过渡。

平板的直接操作和屏幕+操控板的操作是显著不同的两种类型操作。

平板的优势在于直观，由于操控板和屏幕之间需要一个信息切换的标记位来相互传达，则操控就不可能直接锁定操作对象。因此，未来的Mac下和TV下的产品操控界面将会有诸多的革新。

不过，缩放，旋转，多指划动等操作已经逐渐让这种隔空操作成为可能。Kinect产品在这方面也有明显的优势。不依赖于操控板也是一种革新。

相对来说，Mac是桌面产品，不可能有复杂的体位操作，操控板也基本上是附着在桌面上的，但TV则可以更加灵活。

对于隔空操作来说，应该随着划动的操作，出现操作对象的显性显示，而不是目前的图形对象静态响应。

例如棋类游戏，随着划动的出现，则出现操控棋子的焦点转移，或可操作位置的显性图形响应。对可操作的对象进行焦点明确和凸显。这是不同于鼠标操作的特 性。而这种特性在利用iPhone的remote操控ATV界面时有对应的设计结构。这样操控对象转移，和确认就不依赖于屏幕的对应位置。而鼠标的原始设 计则不是这样，鼠标依赖于光标Cursor的位置，对位置事件进行响应。这引来了很多今天的界面设计模式，但对于未来的手势操作则不完全适应。

手势操作的对象有两种，一种是手势本身，一种是操作对象本身。所有手势都是对一个对象或全局发出指令。在相册设计里面，苹果把这种操作优势体现的很明 确，例如缩放手势可以起到两个作用，一个是放大和缩小图片，一个是打开或关闭文件夹，也就是说，当出现列表的时候，收缩是回到文件夹，而放大是进入图片展 示。

但由于平板的特性，缩放手势可以作用于明确的屏幕对象，对于映射结构来说，例如屏幕和触摸板，则需要提供焦点对象，这可以用划动来转移焦点，而不需要传统的点击操作。

同样的模式在SketchBook上也有体现，例如三指左向划过，是Undo，向右是Redo.三指向下是笔头缩小，向上是放大，两只表示画板的移动，单指则是绘画操作。可以说，AutoDesk很深入的理解了手势操作界面的内涵。

目前iOS的API也没有对对象焦点转移响应做出完整的系统，相信随着手势操作的深入，会不断出现类似的API.

为动态界面做好准备吧，也许不久的未来，你看不到那些堆满按钮的界面。但也可以顺畅操作。

(via:http://blog.sina.com.cn/s/blog_44de5fff0100oz26.html)

在客户端的设计过程中，针对不同的屏幕大小，应该如何来设计？是否每个大小的屏幕尺寸都需要一个新的界面布局，还是所有的屏幕尺寸都使用相同的界面布局？我们将在下面的内容中来探讨这些内容。

一、当前热门手机的屏幕大小

下图中，我抽取了国内某个网络电器城某周的10大畅销手机排名：

虽然只是2010年中的某一周的手机销售量排名，由此可以看出，当前使用中的手机屏幕差异很大，各种屏幕大小和分辨率都有。如果为了适配更多的用户群体，则需要考虑的手机屏幕大小和分辨率更多。【不过，根据当前的手机发展趋势，及手机客户端的使用行为可以看出，最主要需要用户关注的手机屏幕是2.4吋以上，240*320以上的手机屏幕，因为这样的手机使用客户端的频率和用户量都会更多。个人建议更多地是考虑320*480及以上的屏幕。】

二、屏幕大小正确理解

说起屏幕大小的时候，会有两种表达方式，1） “我的屏幕2.4吋，你的屏幕3.5吋。” 2）“这个屏幕分辨率 240*320，那个屏幕分辨率为320*480。”但在设计过程中，屏幕的分辨率和屏幕的实际尺寸必须同时考虑。

这里首先有几个概念需要再澄清一下：

屏幕物理尺寸：屏幕对角线长的实际尺寸，如2.4吋，3.5吋等等
屏幕分辨率：屏幕所能显示像素的多少。如，240*320等。
屏幕密度（pixel per inch）：以每英寸的像素数。每英寸的分辨率数，如160ppi。
物理尺寸决定了屏幕的实际尺寸，而分辨率可以表示屏幕上可以呈现的像素点数，屏幕密度决定了屏幕的精细程度。相同的屏幕大小，如果分辨率高，则屏幕元素更精细。一个界面元素在屏幕里的实际尺寸却是与屏幕密度相关，屏幕密度较小的屏上，界面元素的实际尺寸就会大些，反之亦然。

在进行手机界面布局中，除了元素的像素值外，考虑元素的实际尺寸也非常重要，甚至更为重要（人眼是要靠物体成像在视网膜上的视角大小来进行识别感知，视角是与物体实际大小和距离有关）。

在不同屏幕中，不同的图标点阵或者不同的字体及大小的汉字，在人的主观感知上，会有一个最优的结果值。在设计的过程中，我们需要根据这个最优值来进行界面的布局及设计。

也可以看出，这个用户感知最优的取值也与使用手机的人群有关（如年龄大的用户需要物理尺寸更大的界面元素）。

在不同屏幕中，不同的图标点阵或者不同的字体及大小的汉字，在人的主观感知上，会有一个最优的结果值。在设计的过程中，我们需要根据这个最优值来进行界面的布局及设计。

也可以看出，这个用户感知最优的取值也与使用手机的人群有关（如年龄大的用户需要物理尺寸更大的界面元素）。

三、设计过程与屏幕适配思路

1．确定目标的屏幕大小

屏幕大小由宽度和高度两个因素决定，但是在布局手机客户端的过程中，最关心的是宽度值。宽度确定后，高度可以由滚动或者翻页来显示所有内容；文字可以在适当的位置折行；标题栏可以伸缩适配屏幕宽度等等。但并不是不考虑高度，图标、文字、特殊的组件不仅需要考虑宽度，也需要考虑整个屏幕的布局是否与之适配。

由于不可能对所有的客户端进行单独的开发，因此，需要对手机屏幕的大小的归类。同时，在设计中也不会真的只考虑屏幕大小一个因素，屏幕大小和操作系统、手机类型等还是存在很大的相关性的。

首先，我们先来定义一下手机的屏幕大小的归类档次：

A. 小屏幕：宽度240 px 以下屏幕或者2.4 以下屏幕

一般以非智能机为主，归在这个分类中的手机屏幕，一般是以java版本的客户端为主。
B. 中等屏幕：宽度240~320 px，或者2.4~3.0吋屏幕

智能手机以Symbian或S60 v1,2,3，Windows mobile为主流；或者是非智能手机的客户端以java版本为主。
同时包括240*320的宽屏手机。
C. 大屏幕：宽度320 px以上屏幕或者 3.0吋以上的屏幕

iPhone 手机只有两个版本的适配，屏幕物理尺寸保持一致；
Android 系统手机及衍生平台手机
Win phone 7 系统手机
Nokia S60 v5，symbian 3等
D. 平板屏幕：7吋及以上的屏幕【可以不包含在手机中，^_^】

由于当前的平板电脑上的应用的开发都是基于手机应用的功能，但是，平板的屏幕物理尺寸大增，使用情景也和手机不一致，在设计上有很多的特殊性，可发挥空间也更大，因此个人建议单独的设计。

其次，根据我们的产品战略，来确定待开发产品的用户群体来确定一款目标手机屏幕。由于对于某个业务的手机客户端都不会只推出其中的某一款（除非是战略上的用户群确定为使用某种手机的特殊业务），而是会对不同的手机平台分别进行适配。因此，确定的目标手机屏幕，应该是在该档次中最主流的手机屏幕大小，在以此为基准向上或向下来适配其他的同档手机。

2．适配原则

1）  客户端的logo，在各个手机上都应该清晰地显示

2）  标题或者底部栏必须100%的与手机宽度适配

3）  文字内容如果显示不下的话，可以自动适配宽度进行折行

4）  图片可以根据宽度进行自动缩放，屏幕宽度超过图片本身时，显示图片本身的大小

5）  适配过程中，界面的元素的宽高最小值应该符合用户的主观舒适范围值。

6）  不能完全使用分辨率的绝对比例来对界面布局进行缩放；

3. 适配思路分析

根据我们前面的分析，

C类大屏幕大小主要以Android、iPhone、win phone 7 和Nokia V5等手机为主，它们都是触屏手机，在适配上可以划为一个档次。

B类中等屏幕大小智能机主要以Symbian 和Windows mobile为主，因此在适配这两个平台时，主要集中在B类屏幕间的适配。

B类中等屏幕大小还有一块是非智能手机，使用Java客户端，同时，A类小屏幕大小主要使用Java客户端，因此，Java类客户端需要适配的范围更广，至少应包括B类和A类的屏幕大小。

（1）Android 与iPhone手机的适配

iPhone 本身就只有两个分辨率及一个屏幕大小尺寸，可以很好的来适配（最多出两套图片即可，系统会自动读取）。

对于android，由于其开放性，导致了各种屏幕的大小及分辨率都有。但Android系统有一个很好的特性，系统会根据屏幕的分辨率密度来进行自适应。但是，当密度差异较大时，自适应后，图标会由于拉伸变得模糊影响效果。这时，必须要通过重新设计新的图标或者加大间距来保持最佳的视觉效果及更便利于用户操作。

Android 手机屏根据屏幕的分辨率密度和物理尺寸，可以分为以下几类：

注：图中的【】内的值为手机所占的百分比值。Android 开发平台数据，不一定准

Android 提供了如下的机制来对不同大小和密度的屏幕进行适配：

1）  图片资源的缩放

基于当前屏幕的密度，平台自动加载任何未经缩放的限定尺寸和密度的图片。如果图片不匹配，平台会加载默认资源并且在放大或者缩小之后可以满足当前界面的显示要求。如果没有多套资源，平台会认为默认的资源是中密度的屏幕资源（160dpi）。例如，当前为高密度屏幕，平台会加载高密度资源（如图片），如果没有，平台会将中密度资源缩放至高密度。

2）  根据分辨率和坐标自动缩放（密度不同的屏幕适配）

如果程序不支持多种密度屏幕，平台会自动缩放绝对像素坐标值和尺寸值等，这样就能保证屏幕元素能和密度160的屏幕上一样能显示出同样物理尺寸的效果。平台会根据密度的比例来缩放实际尺寸的大小。

3）  兼容更大的屏幕大小（屏幕不同的适配）

当前屏幕超过程序所支持屏幕的上限时，定义supports-screens元素，这样超出显示的基准线时，平台会以屏幕大小的比例来缩放整个屏幕。

由上表格也可知，当前的Android手机主要集中在标准屏的中密度和高密度两个型号上。因此在设计中，主要是设计其中的一种为主，再去适配另一个型号即可。对于在一个档次上的手机，都会根据上述的三个原则，系统自动去适配。个人认为，在进行Android手机设计时，如果只准备一套资源时，应该以高密度的版本为主，这样去适配中密度时，效果更好。

当然，如果屏幕的密度差异较大时，自动适配的效果肯定不会，如果要取得更好的适配效果，必须针对几个不同的屏幕密度进行单独设计屏幕元素，提高视觉满意度。

（2）非Android、iphone的手机适配

对于其他的非Android、iphone手机，则需要更多地考虑其适配规则，这些手机系统不提供自适应的适配。

简单整理规则如下：

1）  向上适配（标准屏向更大【分辨率高，物理尺寸大】的屏幕适配）

在向更大的屏幕适配时，根据设备分辨率的不同，会分为两种状态。

A．如果两者的屏幕分辨率密度（dip）差不多，物理尺寸更大的屏幕。那可以直接在当前尺寸上拉长、拉宽即可，图标、行距都可以保持不变。

B. 如果屏幕密度要大很多，物理尺寸差不多的。则适配点包括：

设计多套图标，需要有更大分辨率的图标
使用不同的字体，需要更大的字体来适配大设备分辨率的屏幕
增加行间距
自适应放大内容中的图片
Tab页签 需要根据屏幕的大小来确认每屏最多显示的数目。
考虑一些复杂界面，增大界面中的一些元素的分辨率，会导致许多东西需要重新设计。这种情况需要重新设计该界面。
2）  向下适配

在向更小的屏幕适配，这种情况较少，那会集中在如下几点：

考虑一些极限点的改进，需要适配到小屏幕的手机中，如标题的最大字数等。
title、bottom栏与小屏幕宽度适配。
考虑到行高（行信息展示）的设计是否适合更小的屏幕高度。
在结构上，需要考虑在小屏幕中，显示是否合适。
根据屏幕密度的比例来设计屏幕元素，需要更小分辨率的屏幕元素
使用小的字体，具体的大小需要根据屏幕的大小来设定。
（3）竖屏横屏适配

横竖屏的适配，在本文中，不过多讨论，这里只是简单的整理一下，我自己的理解。

对于不同功能的应用，都有其特定的页面展现形式，个人并不赞同蛮目对任何应用不加选择的都去适配横屏。

个人观点如下：

1）  不同的应用，在设计的过程中，对于选择不同的屏幕有不同的选择，如普通list多的应用，竖屏更合适；显示图片更多的界面，或者想更好的展示全景的应用，横屏更合适。

2）  不必遵循，对任何的应用都可以自动进行横屏竖屏的切换。如果觉得没有必要横屏或者竖屏的应用，就可以不切换。

3）  由于用户在使用手机的过程中，经常会无意中调整位置，从而导致手机误认为是要进行横竖屏的转化，从而更容易导致操作上的失误，引起用户的反感。

4）  横竖屏的切换时，允许用户对于同一个界面有不同的展示方式。例如不一定在竖屏时时list方式显示，在横屏时也和竖屏保持一致，这时横屏可以有更好的适应横屏的展示方式，使用户更好的操作。

由于手机系统各异，手机的屏幕尺寸五花八门，屏幕的性能也呈现多样性，还有触摸屏和非触屏的区分，这四个变量结合起来，会有无数种不同的情况，如何能使你的应用完美地展现给用户，适配固然很重要。但是，更重要的是你要在适配之前，确定应用的目标群体。如果你的应用主要是针对高端手机用户的，那你何必去考虑低端的手机呢？毕竟为了很少的用户，使你花了很大的力气，可能会有不值得，这一点绝对值得每一个设计师思考。

===========

题外话

一般来说，我们在设计一个产品时，首先需要确定产品的用户群体，然后基于用户群体来设计针对该用户群特点和使用行为的界面。但是对于手机客户端，感觉这个过程不能完全适用：

原因是因为，我的客户端设计主要是针对不同的手机平台（Android、ios，Win Phone 7，Palm Pre，Symbian…）来开发的，因此，开发出来的客户端适用于所有的持有该手机的用户。但是这些手机持有者是否都有相同的特质，是否都喜爱使用该客户端，是个很大的未知数。另一方面，如果我在建立用户群时，完全根据用户的需求、使用行为又或者人种学特征来分类，那每一群人中持有的手机各不相同，那又该如何定义每个不同平台下的客户端的功能呢？

当然，有人也会说那就先了解不同的手机平台的用户群特征，然后再研究这群人对本客户端应用的需求和使用行为，以此再来设计客户端，目前来说这是更好的研究思路。

总之，这样深入的讨论，会发现客户端会越想越复杂，有人说手机客户端的设计是最复杂的，是很有道理的，值得大家更多地探讨…

(via:http://ued.taobao.com/)

MT 主机的合租邻居 mg12 现在在阿里巴巴的 UED 团队, 好像混得不错, 最近喊着闹着要招人了, 在这帮发个招聘文章, 欢迎推荐和自荐.

工作地点: 杭州阿里巴巴总部
产品类型: 电子商务网站 (国际站)
招聘职位: 交互设计师, 视觉设计师, 前端工程师, 用户研究员

招聘详情请访问以下页面:
阿里巴巴国际站 UED 招聘网站

或者看我这了转載的信息

交互设计师：

• 了解商业需求，给出产品的原型设计方案，并保证其基本的可用性
• 通过分析和讨论，用户研究，不断改进产品原型的设计
• 分析商业需求和技术可行性，在有限的项目资源内，给出双赢的解决方案
• 通过设计，解决项目实施过程中可能出现的界面问题，确保最终的用户体验

前端工程师：

• 规划网站的样式结构
• 制定网站表现层规范
• 通过文档、分享等各种形式，帮助其他团队成员产出高质量的交付物
• 探索和开发一流的表现层解决方案，为网站和 UED 团队的目标作出贡献
• 探索 WEB 标准在阿里巴巴网站中的最佳实践，并且推广和执行这些最佳实践

用户研究员：

• 理解设计方案中的问题，并由此给出用户研究方案
• 发现方案设计中的问题，通过各种用户研究来论证
• 通过访谈、调研、数据挖掘等手段，发掘网站现存的问题，并有能力刨深根源
• 总结各类用户问题，给设计提出建议，并协助来论证设计结果

简历请至:
ke.suk@alibaba-inc.com (附件需小于 10MB)

点这里查看更多职位

减少概念……增强信心：

• 你是不是引入了新的概念？为什么？真的必要吗？
• 你能去掉这些不需要的概念吗？
• 其中的区别有意义吗？
• 用户体验会延续同样的概念吗？

小的好或坏也很重要：

• 哪些重要的“小事”是经常会碰到的？
• 哪些小问题是你在着手解决的？
• 少做一些更好。
• 不要把小事从你的体验中去除。
• 为深思熟虑的细节制订计划。
• 修正小的错误。

看起来和用起来都很棒：

• 你的用户体验哪里最棒？它看起来有那么好吗？
• 用户第一眼看到的东西能够让人觉得它用户体验很棒吗？
• 用户体验符合期望吗？
• 用户很清楚能做什么吗？
• 是不是只提供了必要的步骤？

要解决的是让人分心的事，而不是可发现性

• 减少令人分心的事情。
• 不要让功能自己之间进行竞争。
• 致力于新的功能。
• 下列方法不能解决糟糕的可发现问题：
  • 在开始菜单上添加图标。
  • 在桌面上放置图标。
  • 在通知区域放置图标。
  • 使用通知。
  • 提供首次运行体验。
  • 提供功能教程。

旋钮和问题前的 UX ：

• 调低问题的音量。
• 只问一次。
• 不要要求配置来获取数据。
• 这个问题是不是已经问过了？
• 寻找合并统一的机会。

个性化，而非定制化：

• 这个功能是否能让用户自己来表述元素？
• 你是否能够区分个性化和定制化？
• 个性化是需要成为新的功能，还是可以利用现有的功能和信息（如用户的位置、背景图片或排列方式）？

体验的生命周期：

• 考虑下列各个阶段下的用户体验：
  • 安装与生成
  • 首次使用与定制
  • 常规使用
  • 管理与维护
  • 卸载或升级
• 以一个已经使用了 12 个月的用户身份来审视整个体验。它是否具有：
  • 合理的内容
  • 合理的“音量”

为移动人士建造：

• 所有的 UX 原则对于 12 英寸和 20 英寸的屏幕都是等价适用的。
• 允许用户被打断。
• 考虑启动和中断（快速恢复，不要妨碍其他用户体验）。
• 考虑获取或失去连接。
• 性能永远是用户体验的杀手。

ps:微软的细致可以渗透到产品中的每一个环节，或组成人机界面的每一个像素，实在令人钦佩。

轻巧的Apple

注重设计过程：

• 在设计过程中引入用户交互的5个目标：
  • 了解您的目标客户
  • 分析用户的工作流
  • 构造原型系统
  • 观察用户测试
  • 制定观察用户准则
• 做出设计决定
  • 避免功能泛滥
  • 80% 方案
• 优秀软件的标准
  • 高性能
  • 易于使用
  • 吸引人的界面
  • 可靠
  • 灵活
  • 互操作性
  • 移动性

人机接口设计准则：

• 人机接口设计准则
  • 隐喻（尽量使用隐喻来描述程序的概念和功能，这样可以利用一些已有的概念和知识。）
  • 反映用户的心智模型（用户的心智模型应该在产品的用户接口的设计中体现出来，主要体现在应用程序窗口的布局，工具栏上图标和控件的选择和组织，以 及面板的功能等。）
  • 隐式和显式操作（显示的操作清楚的表明了对一个对象操作的结果。隐式的操作通过一些可视化的线索或者上下文来表达结果。）
  • 直接操作 （直接操作是隐式操作的一种，它会让用户觉得可以直接控制计算机显示的对象。）
  • 用户控制一切（允许用户而不是计算机来启动和控制操作。）
  • 反馈和交互（反馈和交互意味着通过合适的反馈以及和程序之间的交互从而让用户时刻知道现在发生了什么，而不仅仅是当事情出错时显示一个警告。）
  • 一致性（在用户接口上的统一可以让用户使用从其他应用程序学到的知识和技巧。）
  • 所见即所得（用户应该可以找到程序的所有功能。）
  • 容错性（提供充分的容错性以鼓励用户使用程序的各种功能─也就是说，大部分的操作都是很容易恢复的。）
  • 感知的稳定性（为了给用户一个稳定的感知，对于对象以及实施在这些对象上的操作，Aqua接口提供了一个清晰的限制集合；为了不破坏用户对稳定性 的体验，程序应该保留用户更改过的配置，例如窗口的大小和位置等；提供程序运行的状态和反馈让用户知道程序正在进行的任务，同样能提高感知的稳定性。）
  • 整体美学（整体美学意味着信息经过良好的组织并且和视图设计一致。）
  • 避免“模式”（尽可能的让用户在任何时候都能做他们想做的事情。避免使用模式对话框来将用户锁定在某个操作中，以至于在当前操作完成前用户不能做 别的事情。）
  • 管理程序的复杂性（开发一个易于使用的程序的最好办法就是设计得尽可能的简单。）
• 设计的优先级
  • 满足最低限度的要求
  • 发布用户期望的功能
  • 让您的程序与众不同

ps:苹果的轻巧不仅体现在它的工业设计上，更多的是它的操作系统和软件的用户体验层面。

Jon Wiley- Google User Experience Designer 在一次专业分享中,提到了Google 的用户体验设计原则：

1. 有用（Useful）：以用户为焦点，关注他们的生活、工作和梦想。
2. 快速（Fast）：争取节省每一个毫秒。
3. 简单（Simple）：简洁就是力量。
4. 魅力（Engaging）：能够唤起新手的好奇心，能够吸引资深用户。
5. 革新（Innovative）：勇于创新。
6. 通用（Universal）：全世界适用的设计。
7. 盈利（Profitable）：为现行的和将来的商业模式做好安排。
8. 优美（Beautiful）：外观具有视觉愉悦性，但是不会令用户分心。
9. 可信（Trustworthy）：值得用户信赖。
10. 人性（Personable）：加入人性化因素。

ps:谷歌的简洁永远是它的产品特色，从谷歌网站的每个界面到浏览器chrome的用户体验与交互，都尽力把复杂问题设计得让用户感觉到最简单。

(via)

做得好一点的公司，一般是项目经理/部门主管+投资方（项目管理中的投资方，实际上就是老板，反正就是决定你要做什么并给你钱的人）来承担产品工程师的角色，由美工来承担Web前端工程师的角色，特别是Web前端工程师，是最容易被忽略的角色。

企业想挤出利润，无非两个方面，一个是开源，另一个是节流。而这两个角色，恰恰可以用开源节流来比喻，产品工程师可以设计出更好的产品，这就是开源，Web前端开发工程师可以精简网页代码，提高用户访问速度，减小企业带宽上的支出，甚至可以减小服务器上的支出，这不是节流是什么？相比有些企业，以靠克扣员工工资来实现节流，这个节流要节省得多。

产品工程师

很多公司的流程基本上是这样的，由需求部门（一个或者多个，如果公司小，可能就是老板等几个人）提出需求，提交到项目经理或者IT部门主管，然后 IT部门主管根据需求进行开发，这中间可能要判断是做还是不做，判断的依据主要是开发难不难，麻烦不麻烦，很少去考虑合不合理。各位，看到什么问题没有，很多IT的部门主管，他只是一个管理者+项目经理的组合，或者干脆就是一个项目经理。需求部门交给我的需求，我按照要求按时按质做完就OK了。但时，需求部门往往是不懂互联网的，这种情况很多公司大量存在，对于一些老板本身就是做互联网的，或者较大的公司，这种情况会比较少。

问题就来了，一个不懂互联网的人，根据自己的喜好或者自己的判断来提出一些需求，有些需求可能很无理，有些时候可能是自己的喜好，有些时候可能是违背互联网的基本准则的。而技术部门往往是只要没有技术难度就开发吧，反正我就按你要求做了，这个中间，没有一个懂互联网的人来把关。注意，懂互联网的人，不是懂技术的人，懂技术的人很多都是不懂互联网的。比如说我曾经见过有公司的老板要在网站的两边加一副对联，结果别人说像灵堂一样，也曾经有公司的老板要把网站做得像电视一样（不是视频网站，就是一个非常酷的过场动画这样子，想法是好的，可惜不适合大型网站，不利于访问也不利于SEO）。

这个时候一定要有一个产品工程师或者产品组来承担这个中间人，注意，还没有到美工的层面，他需要根据需求方的需求，再加上自己对互联网的了解，来设计这个产品。他要考虑到浏览器、带宽、用户习惯等等内容，以确定如何布置页面中的内容，确定功能之间的关联。在这个时候，如果产品工程师不懂技术，可以邀请Web前端工程师和项目经理/部门主管参与，因为某些地方为了用户体验可能要使用到一些技术，需要由这些人来确定是否要行。

Web前端工程师

相对于产品工程师，这个职位显得很加缺乏，因为产品工程师很多时候可以由项目经理或者部门主管兼任，但Web前端工程师这个职位，是很多公司都不重视的职位，很多公司是这样的，Html和CSS由美工负责，而Javascript由程序员负责。但问题是，很多美工对Html/CSS只能实现，至于规范也速度很少考虑，而程序员对Javascript就更加了，从我接触过的程序员中，绝大多数人觉得Javascript是一个比较简单的语言，没什么前途，看不起这种语言，也认为Javascript只能实现一些交互而已。

所以实际上，很多企业是用两个懂一点点的人，来做这个重要的工作。如果让我来选择，我愿意放弃一个，甚至两个程序员，来换一个Web前端工程师。为什么要这么做？我认为，一个网站两个非常重要的地方，就是他的交互性与速度。很多程序员喜欢划分前台与后台，他们都认为前台不重要，只要后台功能完成了，前台不是很简单的事么！不！不是这样的，前台比后台重要，为什么这么说？你想想，一个用户是通过什么接触到你的网站的，是前台，是Web页面，而不是后台冷冰冰的程序。你有再强大的功能，如果用户操作起来很复杂，那么用户也会抛弃你的，除非用户别无选择，比如说工信部的备案，但问题是，现在互联网同质化越来越厉害，抄袭也变得风行，你真的有这么高的技术壁垒让其它公司没有办法做到和你一样的产品么？

注意，不要钻牛角尖，我并非说后台完全不重要，你要非说就算你前台再好，我后台一个死循环出不来，那不是也没戏，这是抬杠！除了大型网站和逻辑错误，现在多数网站并不存在后台影响速度的问题，或者说影响不是那么明显。前台所带来的问题，要比后台带的问题多得多，也容易解决得多，往往是可以花少量的代价来解决大问题的，可是往往很多企业愿意去花钱买带宽买服务器租CDN以提高速度，却不愿意请一个Web前端工程师来解决这个问题。同时，请注意，就算你服务器再快你的带宽再高，用户的带宽是不变的，如果你超出了用户带宽的阀值，你所做的一切将都是豪无意义的。

程序员往往可以实现Javascript的功能，但是由于Javascript的特殊性，他们很难以最优化的方式来开发Javascript代码，就可能就造成他们去网上Copy一段Javascript，然后只要实现效果即可，大量重复的甚至是有Bug的代码被应用到网站中，这些代码将会影响到用户的执行效率，降低用户体验。在HTML方面，这也是程序员的弱项，他们也觉得这个东西太简单，实现起来很容易，但是HTML和Javascript都是入门易深入难的东西，如何合理地组织Html+CSS，让浏览器更快更有效率地执行，这个也是需要很多年的经验的。

在用户体验方面，大公司可能用UE/UI等部门，而小公司的话，一定要有Web前端工程师，美工只是设计页面，很难照顾到用户体验这个层面，当然不排除有些美工已经有这样的水平。实际上用户体验也和产品设计一样，都属于开源的一部分，因为如果用户体验好就能带来更多的用户，不是开源是什么。

最后，我想分析一下造成这两个职位被忽视的原因，产品工程师一职，往往被项目经理或者部门主管+投资人代替了，一般来说，做到主管级的人对行业多多少少算比较了解，所以这个职位的缺失可能不会带来大问题，但也有时候会因为这个职位的缺失而导致项目失败的安例发生，这就要求主管同时也要有产品工程师的能力。

Web产端工程师是最容易被忽略也是最不好招聘的职位，究其原因，是因为部门主管往往是做技术出身的，而技术人员常常会轻视或者忽视前台的工作，也正是这个原因，造成了Web前端工程的工作比较低，所以很多人不愿意去做这个职位，我就常常看到新人如果让ta学习Html/CSS /Javascript，ta就会问你，什么时候我才可以真正编程啊，这样就形成了一个恶性循环，企业不重视，工资上不去，程序员也就不愿意学习了。然后，这个职位可以给公司省下非常高的费用，可以节省数个程序员，减少带宽及服务器。不信？试试看吧！

(via)

2019 年计算机的应用会变成什么样子？微软告诉你。

这个就有点像 微软的那个 Surface 电脑了，呵呵。视频在这里

这个视频里面展示的技术有 电子纸、电子墨水、微型投影仪、微型摄像机、还有那个印度小子展示的那个技术。

据我所知这些技术大多都在实验室里面出现了的，有部分已经在面世了。这些技术要全部投放到市场只是一个时间问题了。希望 到 2019 年真的会像微软描述的这样。

附两张投影的身体上面的操作界面图：

MIT的印度天才Pranav Mistry搞了很多新玩意。虽然有一些类似的见过。但是他把世界和数字相互融合在一起的想法还是很棒的！创意不能有束缚。我们需要out of box.

以下是一段视频，长达13分52秒。但是，我相信你一定不会错过任何一秒。哪怕是它有关于科技，演讲人有浓重的印度口音，但是它如此贴近我们的生活，如此关怀人性，努力把人从“机器前的机器”里解放出来，以至于你会目不转睛地看完这段实况，而且遐想翩翩，愿意努力活到22世纪。

如果说，Windows系统的图形化界面把人们从Dos系统下解放出来，用更符合直觉和人性的方法让人们对电脑进行操作是一次新技术的跨越的话，那么视频里这套Prarnav Mistry提供的第六感（Sixth Sense)装置，则是另外一次意义更为深远的腾跃。和它相比，目前甚嚣尘上的所谓“物流网”，只是这个新技术的小小注脚，无论在深度还是广度上，都无法与之比拟。 网络和电脑技术，终于使得数字世界和现实世界全面融合，人类升级为真正意义上的数位人！新时代就要开始了！

(via)

这是什么玩笑？为什么不能用 Google 的帐号登录谷歌音乐？

还有 Twitter 的这个 “Remember me” 一直都没有记住我。

当前这个窗口一关，然后再次打开，那个你是谁啊？

不知道这是程序员的疏忽还是什么。

最近在公司做一些软件，然后BOSS 提了一些问题和建议让我感到有些意外。本来我在设计东西的时候都是把自己放在用户的角度去设计的，结果发现自己的角度设计出来的东西还是让用户使用起来过于复杂了些。不过值得庆幸的是这个BOSS 不是程序出生的。不过这也是从事这行几年来的感受：程序出生的BOSS 会有习惯性的程序思维重视功能而不重视易用性的问题。而非程序出生的则是注重好不好用。好了不说这些了。

先说网页方面。对于字体，我自己感觉就是用系统自带的字体来做为网页的字体就是最好的兼容方式。因为基本上都是通用的字体了比如：Arial, Geneva, Arial, Verdana, sans-serif 。而且这些字体几乎所有的系统上都是自带了的。然后在页面的编写时也请用这些字体，好保持设计的一致。要是你非要用其他字体做默认字体那我也那你没法。

我经历的一个案例是：我和一个朋友一起去见一个客户，给那个客户看到了成品的网页和设计稿上的字体不同。这也不能怪我那个同事，这是他做的设计。不过他用的字体是微软雅黑，而客户那没有装微软雅黑，导致客户的反感，然后就因为是成品的网页和设计的不一致而不买账。不过即使那个客户是个SB 也无所谓。其实客户在乎的是一致性，做出来的要和看到效果图一样，那他才会满意。微软雅黑这个字体是不错，但是普及率很低，一般人都是用Vista 才会用到这个字体。使用这个字体的意图是很好的，但是没有考虑到字体通用性。

网页的分辨率也是一个问题，现在基本都是 1024*768的了，设计的时候还是要以 1008*600为基准来设计。宽屏的分辨率也是这样，考虑到阅读的习惯我建议网页的页面宽度都固定宽度，不用去自适应了。因为宽屏不是用来阅读的。曾经在800*600为主流时，页面宽度大都以770或780px为标准；在1024*768为主流时，页面宽度大都以950或960px为标准。当时准则很简单，首页固定宽度，因为版面容易控制；内文页自适应宽度，因为可以让更大屏幕（主要是1024*768）用户单屏看到更多内容。还有就是浏览型的网站尽量别用三栏，三栏太难设计，一个合理的页面不需要一下子摆出来那么多内容。

而我现在用的显示器都是16：10的宽屏。我现在都不用去最大化窗口来浏览网页了。感觉没那个必要了。我习惯把窗口拖大到 1024×700 左右的窗口大小来浏览网页。不过宽屏还是用来看电影最舒服了。

软件界面在设计方面主要就是质感的表现，图标栏目。具体的来说这是简单的也是很难的。简单来说就是渐变＋纹理来体现质感。困难的来说就是质感的应用要配合你所设计的风格。光靠渐变也可以不过有时没有纹理来点缀也是不行的，反而质感会大打折扣。要说这个的参考那就是多去看看一些设计的好的软件界面了。还有就是图标，一个好的图标会起到画龙点睛的作用。图标可以用简单的线条来构成。也可用写实风格。不过要配合你设计的界面的风格那才更好。

软件界面在色彩方面的搭配就去看看常见的软件的配色吧，我比较推荐去参考一些出名的软件的配色。其它的没有什么好说的主要是看个人的对色彩感觉和灰度的应用了。比如我就喜欢用蓝紫黑这些颜色。最后就是要找个搭调而且耐看的配色那就是最好的了。

软件除了这方面以外就要在意用户体验了。用户体验这个我就不多去说了。简单来说就是 用词要简单明了。比如我最近的一个项目里面的一个处理邮件接收的弹出对话框标题，程序给的名字是“收邮件头”。结果 公司里面有部分人看到后就不明白。最后改成 “读取邮件列表”。

用户体验除了这个还要在乎用户的操作习惯，按钮的摆放位置等等一些细节的东西。有时用文字比图标表达意思来的更快跟明确。

好了就说这些了。详细参考资料如下：

• 网页用多宽才更合适？
• 宽屏不是用来阅读的
• 宽屏幕下的 Web 设计

以下阅读资源我就只给出地址了。自己复制到地址栏去查看吧。

• http://www.uitimes.com/2006-10/2006102902228.htm
• http://www.uirss.com/Modules/28_83.asp
• http://www.uirss.com/Modules/27_44.asp
• http://www.uirss.com/Modules/28_85.asp
• http://www.uirss.com/Modules/28_67.asp
• http://www.uirss.com/Modules/28_49.asp
• http://www.uirss.com/Modules/28_47.asp
• http://www.uirss.com/Modules/28_38.asp
• http://www.uirss.com/Modules/28_36.asp
• http://www.uirss.com/Modules/28_32.asp
• http://www.uirss.com/Modules/28_33.asp
• http://www.uirss.com/Modules/28_30.asp
• http://www.uirss.com/Modules/28_29.asp
• http://www.uirss.com/Modules/28_20.asp

软件的安装和卸载没有想象的复杂，甚至比Windows还简单。大部分软件只需拖放到程序文件夹里面就可以正常使用了。安装后也不用去做过多的设置就可以直接使用了。

触控板虽然没有IBM的指点杆好用但也有有趣的地方，比如：用2个指头点击就是右键菜单、2个指头一起拖动就可以移动滚动条。用起来很方便虽然我还有点不习惯。可我现在已经喜欢上了这种方式的触控板操作。呵呵。

Safari 的确是最快的浏览器。当初Jobs发布Safari的Win版时我看了展示的数据，起初有点不相信，又看了Nicky写的文章又有点怀疑，现在完全肯定了在相同的网络环境下Safari是打开网页最快的浏览器。但我还是习惯用FireFox。

由于内置了蓝牙和无线上网功能，我现在可以用蓝牙来连接手机来无线上网了。而且设置起来也很方便，我30秒就搞定了。现在这篇文章我就是用蓝牙上网来写的。可惜3G网络从提出到现在一直都没有开通。要不就可以享受跟快的速度了。香港已经全城开通WIFI网络了比3G还要快，而且据说是免费使用的。真希望在香港啊，呵呵。

Mac OS X 系统的用户体验除了下面这点是瑕疵以外都是很不错的。正所谓不可能提供十全十美的完美的用户体验。其他方面都比Windows要好很多。

我发现的这个 不爽的问题，就是Leopard 系统在复制文件和目录的过程中，在处理出现同名的目录的问题上没有把目录和文件区分开来。也就是说把目录当成文件来替换了而不是覆盖。而且这个问题在某些 Linux 发行版上也有。

比如：我把一个从移动硬盘拷贝过来的名字为“cd1”的、里面只有一个mp3文件的目录，替换了一个在音乐文件夹下的同样名为“cd1”的目录。当我打开音乐文件夹下的“cd1”目录后，发现里面只有那个刚复制过来的mp3文件，原有的文件都没有了。原本在这个名为“cd1”的目录里面有3张CD歌曲的文件。

去年我在使用 Mandriva Linux 时也遇到过这个问题， 那次替换导致整个/usr目录包括所有下级目录和文件被替换成里面只有一个Flash Player 控件的目录。因此导致我重装Mandriva Linux。

我想这个问题可能是开发者在开发时的疏忽造成的。如果苹果公司把这个问题解决了那就完美了。现在在这个问题解决之前，我得小心的复制文件和目录了。

这个问题就是一个用户体验的BUG而且有点严重。有没有人知道苹果系统的反馈方法啊 。我要反馈问题。

(PS：也可能是我从Windows转过来还没有适应。)

除了Linux以外我现在使用的Mac OS X是我所购买的第一个正版系统。Linux本来就是免费的不存在购买一说和盗版一说。都是可以在官方的网站自由下载。Windows和Mac OS X就不行.。

恩，现在总结一下。我用了MacBook之后很惊讶苹果软件和硬件的匹配程度（应该说是搭配）。虽然Mac OS X也和Windows有让人不满意的地方，也有用户体验上的BUG，总体来说Mac OS X比Windows要好很多。 至少我现在不用对流氓软件、木马和病毒抄心了，可以享受计算机带来的方便了。

PS:又要发布一个手机主题了。呵呵