现在 iPad 也有视网膜屏幕 (retina display)了。正是依赖这视网膜显示屏，iPhone 4 的分辨率达到了640×960 pixel，iPad 的分别率达到了 1536 x 2048 pixel。不过为了保持向下兼容性，iOS 在网页上仍然是 320 × 480 point 和 768 x 1024 point。

也就是说，在不进行缩放的情况下，显示普通图片时，它会用4个像素来显示图片中的1个像素；而在显示retina图片时，每个像素都对应图片中的1个像素。这样网页上面的图片就会模糊了。文字却没有这个问题，因为文字是适量的。也就是说要解决图片模糊这个问题可以用 svg 适量图片来替换。

iOS 用 SDK 开发 iOS 应用时，只要将图片名加上“@2x”后缀，就能让支持retina display的设备自动显示这个解析度更高的图片。但 Safari 等使用 UIWebView 的应用在展示图片时，却无法利用这个特性，因为这样会造成大量没必要的HTTP请求。

不过解决这个问题的方两种一种是用大小为原图的 2 倍尺寸的图片来缩小来显示，另外一种就是直接使用 svg 适量图片。

方法一：先来看看用原图大小2倍缩小的方法：

如果图片是直接用 HTML 的 img 标签显示，假如 图片的大小是 60 x 60 px 的那么在 img 标签里面的尺寸就不能是 60 x 60 px，而必须是30 x 30 px。

请看下面的演示效果：

HTML：

图1

图1 为原始30×30 的图片。

图2

图2 为原始 60×60 的图片缩小后的预览。

CSS：

如果是用做 CSS 背景图片那么就要设置 background-size 属性了，如：

background-size:30px 30px;

示例如下：

图3 为原始30×30 的背景图片。

图4 为原始 60×60 的背景图片设置 background-size 后的效果。

使用 iPhone 4或者 新款的iPod 浏览本文就很清晰的发现这两个图片的显示问题了。

方法2： 就是直接使用 svg 格式的适量图片了。

使用方法：
<img src="icon.svg" width="30px" height="30px" alt="" />

或

background: url(icon.svg) no-repeat;

如果你是为了节约流量那么只准备一套大尺寸的图片就行了，然后直接使用方法一中的方法缩小图片显示尺寸就行了。

要是你想面面俱到的话那就准备2两套图片吧。

在网页中，pixel 与 point 比值称为 device-pixel-ratio，普通设备都是1，iPhone 4是2，有些Android机型是1.5。你就可以用 css 的media 查询来做判断加载哪套图片了。css media 查询的代码如下：

<link rel="stylesheet" href="retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2)"/>

或者：

@media only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2) {
}

另外推荐一个制作 svg 的软件，那就是 Linux 下大名鼎鼎的 GIMP。这个软件 也有 Windows 和 Mac 的版本，下载地址为：http://www.gimp.org/downloads/

这个软件被称之为 Linux 下的 PhotoShop。也可把图片转换为 svg 适量图。

补充：做图和切图的时候，图片最好为 2 的倍数，也就是说切图的时候尽量使用偶数。基数不能被整除，坐标这些会出问题。

玩飞镖的时候，靶心是最难射中的位置，因为靶心是整个靶面上面积最小的部分。越是小的目标，就越是难以达到。这个准则在移动设备的触摸屏幕上同样适用。

众所周知，对于触屏设备用户来说，面积小的目标比面积大的目标更难操纵。所以，在设计移动设备界面的时候，触控目标一定要充分的大，足以让用户操作 自如。但是多大才算充分呢？多大才是对于大多数用户最合适的尺寸呢？各大移动设备开发者已经认识到这个问题，最常见的做法是在各大厂商的用户界面设计文档 中寻找答案。

那么，设计文档怎么说？

Apple的IPhone Human Interface Guidelines推荐触控目标的最小尺寸是44*44 pixels。Google的Android Design说7-10mm是比较理想的尺寸。Microsoft的Windows Phone UI Design and Interaction Guide推荐的最小触控目标尺寸为7*7mm（26*26px），理想的尺寸为9*9mm（34*34px）。Nokia的开发指南建议目标尺寸应该不小于10*10mm（28*28px）。

虽然每个设计文档都给出了大体的合适尺寸，但是我们可以看到各个设计文档都有所不同。实际上，有些他们所推荐的尺寸是远小于用户手指尺寸的，而正是这些误差导致了用户在操作过程中的种种问题。

小目标，大问题

如果触控目标太小的话，用户需要付出额外的精力来进行精确的点击。用户需要不断的调整他们的手指来点击目标并获得反馈。有的人习惯用指腹，这样可以 覆盖整个目标区域，但如此以来就很难在点击的同时看到按钮的内容，也看不到点击的反馈。而有些人用指尖，这样可以在点击的同时获得视觉反馈。如果用户需要 多次尝试才能到达目标的话，就会影响任务操作的顺畅，耗费了不必要的精力，并且增加了用户的挫折感。

除此之外，小的触控目标还很容易导致误操作。当小的按钮被组合在一起的时候，用户很容易因为目标太小而点击到邻近的按钮，从而触发了其他动作。这样 的误操作在用户使用大拇指进行操作时尤为明显。有些用户为了在点击的同时看到反馈甚至将手指侧过来进行点击，其实，这完全是可以避免的。

对于用户来说，很多时候他们只有一只手来操作设备，单手握持设备的时候，大概就只能用拇指进行点击操作了。我们的设计不能因为用户用的是拇指而不是食指而出现更难点击的情况，更不能导致他们的误操作。

食指的平均宽度

MIT的一项研究指出，大多数成年人的食指宽度为16-20mm，换算后大约为45-57px，在设计文档中，只有Apple的44px还比较接近。

如果触控目标的宽度能够达到45-57px，那么操作起来就很舒适了，并且在进行点击的时候，按钮的边缘是可见的，这样点击的反馈也能很好的体现出来。用户点击和拖放目标的速度也能大大提高。根据费茨定律，目标越小，达到目标的时间越长。小的目标需要用户付出额外的精力去精确的点击它，增加目标的宽度就不用担心这些问题了。

拇指的平均宽度

有的用户喜欢用食指进行操作，而用拇指的用户更是大有人在。两者最大的不同在于拇指更宽。一个成年人的拇指宽度大概是25mm，换算之后大约是72px。

对于拇指用户来说，72px宽的触控区域能够很好的进行定位，同时也能看到目标的边缘和角落，从而获得反馈信息。

Microsoft Research的一项研究发现，触屏用户的误操作数量随着点击目标的增大而减小，用户点击目标的速度也随之变快。

虽然增大目标的尺寸有诸多好处，但在某些情况下也有例外。大家都知道，移动设备的空间是很有限的，如果一味的增大按钮目标的尺寸，移动设备尤其是手 机的屏幕肯定会不够用。所以在设计的时候，我们必须解决屏幕大小和点击目标大小之间的冲突和矛盾，在屏幕允许的情况下尽可能的使用充分大的按钮目标，如果 实在不行，我们还有设计指南的推荐尺寸可用。

游戏中的应用

另一个我们需要考虑的问题是用户什么时候用食指，什么时候用拇指。如果是在游戏当中的话，用户会更倾向于使用拇指进行操作，想想PSP，NDS。所以，游戏应用中的控制区域最好要适合拇指的宽度。同样，触控目标的大小要既能舒适的控制，又能看到目标的反馈。

毫无疑问，让移动应用中的触控区大小与用户手指尺寸相匹配大大提高了应用的可用性。如果用户在使用移动应用的时候还要特别花注意力来进行点击操作，那么其用户体验必将大打折扣。

英文原文：Finger-Friendly Design: Ideal Mobile Touchscreen Target Sizes

翻译原文：http://www.uedreamer.com/?p=258

PS：此文在上月21号月初的时候在 SmashingMagazine 看到了原文。计划自己翻译的。结果今天发现有人翻译了。我就转过来收藏了。

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” 一直都没有记住我。

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

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