3月份，Photoshop CS6 Beta版(下文简称PS CS6)发布公测，有着多项惊艳的新特性，工作中整天和像素打交道，感触比较深的特性就是PS CS6支持矢量对象绘制、变换时像素自动对齐网格。

当然，对象绘制、变换时像素对齐网格并不是PS CS6独有的功能，只是更智能更好用了，PS CS6的像素自动对齐网格功能在绘图过程中，无疑方便了很多，不必再担心图形边缘会出现模糊，但是我们在实际的图形设计过程中会发现，还是会经常需要调整 一些路径没有完全对齐到网格产生的半透明的过渡像素，用来平滑图形边缘减少锯齿感，或让图形看上去更饱满、更细腻，我们称其为次像素 (或亚像 素，Sub-pixel，一般用于屏幕显示技术等领域)，如下图所示。

图1-消除锯齿的次像素

趁着 PS CS6正式版还未普及，以PS CS5为例，和大家探讨矢量路径图形绘制时如何让像素对齐网格，如何利用路径调整次像素改善图形的饱满度的一些经验，希望对大家有所启发和帮助。

一、像素对齐网格

1.    对象绘制时像素对齐网格

像素对齐网格最大的作用就是避免绘制图形时出现虚边，解决图形模糊的问题，尤其是将画布放大数倍去抠界面、图标细节时，精度可以达到像素级，让设计师将精力更多的集中在创意表达层面，不必因为担心模糊而谨慎的去操作，从而提高工作效率。

在PS CS5初始状态时，只有当画布在100%比例下，也就是实际像素比例时，画出来的图形才不会模糊，放大或缩小画布到其他比例下，即使打开网格进行辅助，画 出来的图形也会模糊，如图2所示，蓝色图形与紫色图形分别为100%画布下不打开网格，和非100%比例画布下打开网格随意绘制的相同大小的矩形，我们能 明显的看到紫色图形边缘非常的模糊。

图2-对齐像素图形和未对齐像素图形的对比

 　　这时的网格没有起到作用，是因为在PS CS5初始状态时，网格的参数不是以像素为单位，而是毫米，如图-3，首选项窗口可以通过主菜单中“编辑>首选项>常规”或快捷键Ctrl+K来打开。

图3-初始状态下的网格参数

　　想要在常规图形 (矩形、圆角矩形、圆形) 绘制过程中，使像素在任何情况下都对齐网格，在PS CS5的首选项窗口中，对“参考线、网格和切片”选项卡的网格参数进行简单的设置，并配合快捷键就可以做到。

图3中可以看到网格线间隔的默认值是25毫米，将单位改为像素，这时单位前面的数值会自动变为1，这时的网格线并未与画布上的像素格对齐，需要 手动重新输入数值，且网格线间隔数值与子网格数值必须相等，图4展示的是在3200%比例下，两种不同数值网格所呈现出的效果，可根据自己的喜好进行调 整。网格可通过主菜单“视图>显示>网格“来显示或隐藏，快捷键为Ctrl+’(回车左侧的引号键)。

图4-不同网格参数呈现的效果

　　完成了如上设置，最后确保”主菜单>视图>对齐”及“对齐到>网格“两个选项已勾选，“对齐到>网格“选项在打开显示网格的情况下才可编辑。

图5-对齐功能及相关选项

像素对齐网格设置完成，以后在非100%视图下绘制常规图形，只要打开网格辅助，就不会出现模糊情况。像素对齐网格在PS CS5中还是存在一定的局限性，受到图形形状的约束，当使用线条工具、多边形工具、自定义形状工具绘制一些带有倾斜边缘或非直角的图形时，还是无法保证所 有角点和边缘对齐网格，当然这里的模糊更多的是防锯齿效果，可以利用网格手动调整。

2.    对象变换时像素对齐网格

PS CS5中，长宽都是奇数或都是偶数时，进行90°变换时都可以对齐像素，当长宽数值分别是奇数和偶数时，再进行顺时针或逆时针90°变换就会使图形模糊， 无法对齐到像素，这时可以先旋转，然后打开网格进行辅助，不要退出自由变换模式，拖动对象，这时边缘就会自动吸附对齐网格，如下图：

图6-变换图形时对齐网格

二、利用次像素让图形更饱满

举个小例子，看看次像素在图形设计中的作用，抛砖引玉。

在界面设计中，经常会绘制下拉菜单等控件上的三角形箭头形状，最常见的做法就是用铅笔工具点象素画出来，如图7-a所示，看上去很清晰，但在分 辨率较小的屏幕上看，会稍显生硬、有锯齿感，影响界面的细腻度；用路径对齐网格绘制箭头，如图7-b所示，解决了锯齿问题，但看上去体量感被削弱了，不够 饱满；图7-c中所示的效果，是对次像素微调后的效果，既消除了锯齿，而且在体量感上不输第一种方案的效果。

图7-三种不同方法绘制的箭头

　　没看出差别？我们将三种方案放在一起对比下，见图8，从左至右依次为图7中的a、b、c方案，我们看到中间的b方案虽然没有了锯齿，但体量上明显小于a、c方案，而c方案同时具备无锯齿、相等的体量感两个优点。

图8-下拉箭头效果对比

　　通过放大图片我们可以看到在次像素上的差别，要达到方案c的方法其实很简单，看看下图放大的效果和路径你就明白了。

图9-使用路径改善后的次像素

　　只要将角点上的路径锚点分别向外移动一点，让原本颜色比较淡的次像素稍微加深就可以了，操作时，放大画布让调节更细微和精确，选中锚点，轻点多次键盘上的方向键来移动即可，这个方法不局限于箭头形状，大家可以开启像素眼去发现更多的应用场景。

总结

　　啰嗦了这么多，希望这些小的点能对大家工作有所帮助和启发。我们总是希望利用现有的资源做更多的事，不断的探索设计 中的更多可能性，关注设计细节的展现，无论是PS CS5还是即将发布的 CS6，每一项功能改进都激动人心，使操作更加得心应手，也帮助设计师能够在更智能的环境中专注于创意表达，提高输出效率，相信 Adobe CS6设计套装在各个方面都不会让人失望，让我们一起期待。

(本文出自Tencent CDC Blog)

现在 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 看到了原文。计划自己翻译的。结果今天发现有人翻译了。我就转过来收藏了。

最近把 iPhone 的样式更新了，主要是正对iPhone 的触摸特性把一些链接的点击区域放大了。iPhone 上由于屏幕限制就主打横屏浏览模式，搜索和分享在竖屏状态下是隐藏了的。

现在直接使用 iPhone 访问本站就可以看到新的针对 iPhone 优化后的主题样式了。

预览图在这里：

首页竖屏：

首页横屏：

列表竖屏：

列表横屏：

文章竖屏：

文章横屏：

还有就是评论的插入表情的地方，我把可点击区域加大了。

感觉这次 iPhone 又是像 iPad 那样朝 Web APP 形式发展了。呵呵。

这个结合了自己这两个多月的工作所以遇到的问题，以及HTML5 的一些新特性来做一些应用上的介绍。

给 iOS 设备定制页面

其实只要网页已经使用了 HTML5 的标准来构建的网页，只需为 iOS 准备CSS 样式表文件就可以解决这个问题了。就像这篇文章里面的效果一样。没有使用任何相关的插件来实现。

iOS 设备都有一个特性那就是支持重力感应，屏幕的内容会随着设备在手里面的方向状态进行屏幕分辨率的宽度自适应。SO，浏览器在 CSS 的解析上就有了横竖两种分辨率的判断。不过 iPad 和 iPhone 的支持上又是有点区别的。Android 的也支持这个，不过 Android 详细的情况，由于本人没有测试的机器就无法做说明了。

CSS 在用在移动设备上网页的 link 链接的代码上面要做一些修改，需要修改一下 media 属性。

由于 iPhone 的横竖屏的判断是通过最大宽度来判断的代码，那么 CSS 链接的媒体检测代码要做如下修改了，代码如下：

<link rel=”stylesheet” type=”text/css” media=”screen and (max-width:320px)” href=”iphone.css” />

<link rel=”stylesheet” type=”text/css” media=”screen and (min-width:321px)” href=”iphone_landscape.css” />

max-width:320px 限制了屏幕的最大宽度为 320，也就是 iPhone 竖屏状态下的屏幕宽度。

min-width:321px 限制了屏幕的最小宽度为 321， 由于竖屏的时候屏幕宽度为 320 了。不可能变成 321，那么一旦屏幕检测的时候发现宽度大于 320 了，那就会自动判断为横屏状态。

不过，在实际的应用中发现 iPhone 4 在处理网页的时候竖屏分别率宽度是 320×480，而不是 640×960 的分别率。也就是说网页上iPhone 和 iPhone 1～3 代的分别率是一致的。所以在设计 iPhone 4 专用网页的使用只需按照竖屏 320×480 和横屏 480×320 的分别率设计就行了。

iPad 下做判断就方便很多了，iPad 没有使用屏幕分辨率来做检测，而是直接使用了媒体检测中的 orientation 属性，代码如下：

<link rel=”stylesheet” type=”text/css” media=”screen and (orientation:portrait)” href=”ipad.css” />

<link rel=”stylesheet” type=”text/css” media=”screen and (orientation:landscape)” href=”ipad_landscape.css” />

orientation 是用于屏幕方向检测的属性。直接使用就行了。orientation:portrait 表示竖屏，orientation:landscape 横屏。这样就没有什么好说的了。

不过貌似这两种方法 Android 都支持，无论固件是 2.3 的还是 3.0 的。

另外 media 属性里面的 screen 是指屏幕设备，也可以用 all 代替，all 指所以设备。不过不推荐这样用。

横竖屏的状态判断搞定了，那么接下来就是 CSS 样式的编写了。 由于 iOS 和 Android 使用的都是 WebKit 的内核，那么就可以放肆的使用 CSS 3.0 的属性来渲染页面了。

既然都是 WebKit 内核了，应该就没有什么差异存在了。但是还是要注意一个问题，那就是 position 属性了，代码如下：

position:fixed;

这个代码没什么问题啊。是的，看起来问题的。这是个会让定义了这个属性的元素以一种绝对的位置固定在屏幕上，不会被页面滚动影响的。但是这个在 iOS 下面失效了。

Why？ 我也不知道为什么。反正就是失效了。背景图片的 fixed 定位在 iOS 下也会失效，貌似只要是和 fixed 有关的都会失效。估计这个和 Safari Mobile 版有关系了。

要是横竖屏都各用两个 CSS 文件那么在切换的时候会出现一个闪屏的问题，其实这是浏览器在切换 css 是产生的渲染替换问题。解决这个问题的方法就是在编写横屏的 CSS 文件的时候，先引用竖屏的 CSS 文件然后在竖屏的 CSS 基础上做 CSS 样式覆盖的调制。比如宽度的调整。类似这样：

竖屏样式 (portrait.css) 内容：

div{width:768px;}

横屏样式 (landscape.css) 内容:

@import url(“portrait.css”);

div{width:1024px;}

这样横竖切换的时候感觉就流畅很多了。

网页 iOS 桌面图标

Safari Mobile 版有个挺有意思的功能就是可以把当前网页添加到 iOS 的桌面作为一个程序图标显示。界面如下：

也就是这个 “添加至主屏幕” 的功能，这个应该是叫 Web 剪辑吧。

添加至主屏幕过后就会在主屏幕上生成一个用网页微缩图作为图标的 APP 图标。点击后会打开添加的网页。其实可以利用这个功能做个网站的快捷方式了。也可以把网站模仿成一个 Web App 来使用了。

要模仿就要添加几个东西，一个是添加桌面图标、启动画面和隐藏 Safari 的工具条和地址栏。

添加桌面图标的方法就用 iOS 特有的代码了。代码如下：

<link rel=”apple-touch-icon” href=”apple-touch-icon.png” />

图标的尺寸推荐 114px X 114px 的矩形 PNG 图片，圆角和高光效果是 iOS 自动添加上去的。

如果你不想要自动添加的圆角和高光效果，那么可以用下面的代码：

<link rel=”apple-touch-icon-precomposed” href=”apple-touch-icon.png” />

这样点击过后还是会出现一个和屏幕尺寸一样的网页的截图，那么就需要添加一个启动画面来替换了，代码是：

<link rel=”apple-touch-startup-image” href=”screen.png” />

这部分代码是从 iOS 的开发网站上找到的。不过貌似只支持竖屏的启动图片。 启动画面的图片规格要和 屏幕的尺寸一样，只是高度要减去 状态栏的高度也就是 显示电池信号那栏的高度。比如 iPhone 的启动画面的图标尺寸为 320×460， iPhone 1～3代和 iPad 的 状态栏高度为 20px。，而 iPhone 4 为 40px，那么启动画面 iPhone 4 的尺寸应该为 640×920。iPad 为 768×1004。这个也是 iOS App 启动画面的尺寸规格。

加上这两个图片和你就发现这个和一个原生的 APP 程序基本一样了。只是为什么打开的时候还是有地址栏和底部的工具栏呢？那就还需要添加这行代码，把快捷方式打开的页面全屏化。代码如下：

<meta name=”apple-mobile-web-app-capable” content=”yes” />

这个就是把网页作为 Web App 的 meta 属性了，同样还可以添加一个状态条的样式 meta 属性，让自己定义状态条样式。这个的代码如下：

<meta name=”apple-mobile-web-app-status-bar-style” content=”black” />

apple-mobile-web-app-status-bar-style 的 content 值为 3个，分别为 default (默认)、black (黑色)、black-translucent (黑色透明)。和原生 iOS App 上面的定义一致。

有时候页面里面的一串数字会被浏览器自动判定为电话号码，点击后就可以直接呼叫出去。为了避免这个还需要加上下面的屏蔽代码：

<meta name=”format-detection” content=”telephone=no”>

这下这个网页通过添加至主屏幕后就像一个真正的 App 出现在 iOS 的主屏幕上面了。但是细心的还是会发现，为什么字体会被缩小很多呢。这个是 Safair Moblie 版的自动缩放适应特性了。没有了这个你就不能使用那个很酷的缩放手势来放大页面了。既然是要做一个移动设备上的网页那么就要干掉这个特性了。那就要禁用自动缩放了，还是要使用 meta 便签来搞定，代码在这里：

<meta name=”viewport” content=”minimum-scale=1.0,maximum-scale=1,width=device-width,user-scalable=no” />

viewport 里目前有四个可以设置的属性，它们各自的作用如下：

• width：设置 viewport 的宽度，即 iOS 模拟 PC 浏览器的宽度，之后 iOS 会这个宽度展现的页面同比缩放到屏幕上。设置  width=device-width 后就不会再进行缩放了，因为宽度是指定使用设备的屏幕宽度。
• minimum-scale 和 maximum-scale：是控制允许用户缩放操作的最大和最小缩放比例。
• user-scalable：标识是否允许用户对页面进行缩放操作，取值有两个 yes 和 no。设置为 no 就不允许进行页面缩放操作。

这样就像一个 Web App 的网页了。不过要注意的是这里提道的 link 和 meta 标签都需要放在 <head></head> 里面。

如果你不喜欢这种上面提到的全屏模式，而是只想隐藏掉地址栏那么用这个JS代码就行了：

<script type=”application/x-javascript”>

addEventListener(‘load’,function(){setTimeout(scrollTo,0,0,1);},false);

</script>

注意 type 是 application/x-javascript 而不是 text/javascript。不过这段 JS 代码只在 iPhone 里面有效。

使用 HTML5 构建的页面还可以在浏览器启用 HTML5 的本地缓存列表来缓存一些资源文件在浏览器的本地缓存里面，这样可以达到加速浏览的目的。

Web App 用上了这个本地缓存列表，那么就可以在离线的状态下使用了。

PS:本站已经启用这个缓存列表来加速网站访问了。使用过程中发现本地缓存这东西还是有些问题，下次再说了。

iPad 的主页竖屏：

iPad 的主页横屏：

iPad 的 Blog 页竖屏：

iPad 的 Blog 页横屏：

点击iPad 上Safari 的分享菜单上面的 “添加到主屏幕” 就可以在 iPad 的桌面上添加本站的快捷访问图标，添加后有惊喜。

夏日要到了，酷热的天气，灿烂的阳光，想在夏日里获得众人的目光和赞美，快试试小白介绍的几招，一起打造清爽的夏日装，让在一切更加舒服，有活力。
嗯…咳咳。这是说视觉界面上设计的事，无论是web、移动或客户端，要想视觉更加清爽下面的建议都会有帮助的。

1.让布局更有空间感

脱掉！嗯…对的…
要想清爽，就得把身上多余的衣物，一层一层的脱掉！
在一个有限的空间里塞满大量的元素和信息，就算设计再华丽，信息再精彩，焦点还是无法长期停留在该空间。对于信息量丰富的界面，要想视觉清爽，空间感显得有为重要，这包括：主次信息之间的比例，各个信息模块之间的距离，单个模块里信息的间距。

2.使用简单的几何元素

曲线！嗯…也不完全这样理解…
脱掉厚重的衣物，身体的线条自然会显现出来，但想吸引更多的目光，那就得把线条练得好点。
在界面中使用简单几何元素做点缀或分割，有助于视觉焦点迅速寻找主要内容，便于信息的传达。
几何元素在人的思绪中是一种没有滞碍的概念，往往传达出干净有力，目的明确的态度和姿态，这最符合清爽的氛围。

3.留白和采用浅色系的邻近色

夏日，海滩上，鲜艳的色彩的确是夺目的主角。
但作为日常着装，那样的色彩就不耐看了，而简单浅色系则显得干净舒服。
色彩在界面的作用是营造体验氛围，为的是更好的突显内容，尽量减小使用中的干扰，建议太强烈的色彩不适于在以大量信息为主题的常用界面设计中。
适合营造氛围的邻近色特点是，层次丰富、活泼，既保持了统一的优点，却没单调、呆板的缺点。而浅色系的色彩与白色相搭配显得界面单纯、柔和、谐调，却有优雅、微妙的色感。

以上是小白的小小建议，愿你在设计界面时，希望界面清爽的时会有所帮助。

(via:http://uedc.163.com/5394.html)

上图中间一排图片边框的色彩就不协调了，如果在图片是不确定的情况下，加边框时最好是给图片与边框之间加上边框距。

下图表面看上去没问题,细看之下有点小别扭,放大后就可以看清楚了,导航文字偏高,搜索框与导航没有对齐,搜索框中Button图标距离也有问题。

调整之后如下图：

在看下面的例子：

上图中区块上下间距与左右间距不匀称，和前几的列子一样，文字与区块上下垂直间距不协调，下图是修正后的结果。

在来看一组给图片加框的效果：

在来看图列间距：
下面这个列图看似没问题，其实有两个细节问题（其中一个应该算是用户体验的问题）。首先第一列与第二列的间距要比第二列与第三列的距离要小2px，对于这 个问题，有人会说这个间距用CSS定义就统一了，不会存在差异！注意了，我们讨论的是视觉设计，不能把这个问题丢给前端，否则你后面丢过去的更多（相信 我），其次纵间距太小排的过于紧密。

调整过后如下图:

4)关于阴影与质感：
在设计点缀版面时需要有深度和3D质感的时候，可能就会用到投影、阴影、光线感等效果。但web设计和平面广告不同，太强、太硬的质感只会让页面显得粗糙，web页面是个很细致的活，还是那句话，这里只说细节，先看图：

阴影要小一点、颜色要浅一点,另外这里面其实还有一个问题，和前面讲的边框一样，如果图片是的投影颜色与图片颜色（或背景颜色）相同，效果会很尴尬，所以要边框一样给图片加一个间隔距离：

理论上讲，将一个没有质感的元素进行投影或加阴影是不现实的！前面讲的一些阴影效果，元素本身没有任何质感。看下面的例子：

上图Button和价格区块的投影没有质量,修改后如下图:

其实阴影和质感是随网站整体风格相关联的,某种情况下还不如不加上去。

关于深色背景下的质感，阴影和投影是不现实的，所以只能用发光或光线质感来实现。

就说到这里了，没时间往下说了，我要整理东走了，上面都只是你可能不注意的小小细节问题，你注意到的我也不会说了。（uimaker.com搜集发布）

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/)