Iphone和Android系统手机风靡全球的同时，移动互联网的发展也掀起了一股热潮。最近发现身边一些朋友纷纷在做手机上的 第3方应用，或多或少碰到了些困惑，也许对于做惯了基于浏览器的产品的设计师来说，有一些比较典型的要点容易被忽略，这就容易引发出：找不到手机软件的感 觉、布局经常改变、设计和优化时找不到明确的立足点等等一系列令人困惑的问题。本人有过一段手机交互设计的时光，将在这里罗列一些总结或感想，带一些建 议，供看官们斟酌和评判。      抛开定位、使用环境这样的用户研究体系的大头，专注于说明手机交互设计的特点，其难点在于如何有效的结合硬件、软件平台和设计规范。

以硬件区分手机类型：

• 仅以物理硬键控制操作的机型（后文简称按键机）
• 主要以触摸方式操作的机型（通常包含主页、挂机等物理键）
• 物理硬键齐全，但支持触摸操作的机型（外形和按键机型一样）

主流的可安装第3方应用的软件平台：

• 塞班s60（第3和第5版）
• Windows Mobile for PPC
• Android
• Iphone OS
• Java（目前有非常巨大的智能和非智能机型群是包含java平台的）
• 其他还有很多，诸如plam os、UIQ等

交互设计规范：

一个有经验的设计开发团队，在项目初期会率先着手建立或检查相应平台的设计规范。和web控件规范一样，手机交互设计规范定义了一些常用 控件、组件等的布局和响应方式，提炼设计中的公共部分，减少设计和开发的重复思考，并确保整个设计体系的一致性。不同的是，手机交互设计规范不仅有着限定 作用，它同时还是一个信息架构的体现、一个创新的过程、并且它还对后续的交互设计起到一定指导作用。我们了解到的iphone的无菜单的风格、各种操作手 势、弹出框、标题栏和返回按钮，都是在这个阶段就需要定义好的，而不是具体到某个功能中才任由设计师发挥（所以说创新应该作为一个系统工程，而不是在某几 个细节上灵光闪现）。

从设计第三方应用的角度看，大致可以浓缩成以下几个版本的设计规范：

• S60第3版―有一套比较经典和严谨的规范 。另外S60第5版虽然是触摸屏机型，但是对于交互设计师的工作来说两者区别并不巨大，只是把OK键 替换换成了点击，以及零碎的一些变化。
• Java版―事实上由于左右物理控制键和方向键、OK键是按键机型的普遍配置，S60第3版规范的适用 范围是非常广泛的，稍微修改一点就可以适 用于Java平台。区别在于手机的“删除”和“返回”两个物理硬键的配置不太一致，所以需要统一将右下角的命令默认为“返回”，在编辑文本时，临时变为 “删除”。这样牺牲了某些机型的某些操作的效率，保证了这个整体的机型都可使用。
• Iphone OS―Iphone的出现一举打破了之前若干平台固有的设计定势，硬键和操作模式都精简了许多。 不过其缺少固定的menu模式， 这对第三方软件的设计来说是个巨大的挑战，要么需要很大程度上脱离iphone自身的设计规范体系，要么就极端精简功能。
• Android―跟从了一些iphone中的经典手势，操作和页面布局风格上相对保守一点，保留了menu和back两个硬键，虽然不够独树一 帜，但是在功能和设计之间做的了一个不错的平衡，对于第三方应用来说，这是一个可以有宽广发挥空间的平台。

根据上文所述，接下来我就主要以S60第3版、Android、Iphone OS为代表，通过抽取手机交互设计规范中的部分，来说明他们 的特性和区别，顺带展开一些个人经验的叙述。

大家请看以下截图：

上面几幅图并没有刻意选择同一类型的界面来对比，我们不妨先仅关注硬键/全局功能键，会发现他们之间的显著不同，实际上反映到设计过程中，这 样的区别对界面设计造成的影响要来的更大。

下面以摘取手机交互设计规范的形式来陈述：

1.硬键和手势控制

S60第3版

Android

Iphone:

以上硬键和手势对于操作的控制，需要我们在设计前有个十分清晰的认识，并且整个团队达成一致，如有精力则需要专门写到设计规范文档中。硬键控制是没有什么 改动余地的，两款触摸机型可以对手势适当进行取舍，毕竟有些应用用不到所有的手势，能精简操作最好。

（从下面开始，会有一些功能界面，请允许我偷懒一下，用线框代替实际界面截图）

2.菜单

S60第3版的菜单是由左软键或OK键调出，需要定义以下几点：

（注：聚焦到某一条目上时，通常按OK键是打开，但有一些内容包含几种看起来级别相当的操作，此时会弹出菜单选择）

• 如何收回
• 背景是否雾化
• 每屏最多显示多少条
• 有无二级菜单，如果有，怎样调出和收回，和一级菜单的位置关系，焦点条的区别
• 菜单项文字靠左
• 数字标号，如果整个软件能保证菜单项目均在10位以内，建议加上，这样可以与数字键盘对应
• 对聚焦项或当前页面不适用的菜单项，是不显示还是文字变灰处理。
• OK键菜单只包含针对聚焦内容的操作项，需控制在一屏之内，避免二级项
• 菜单项的排序规则：针对聚焦项的在上，其他的在下，这两部分中分别按照使用频率从上至下排列

Android

Android传统的菜单是由menu硬键调出，比较多的是2-3行，每行2-3项，看起来像是一些按钮，所以里面的图标和文字都居中。作为第3方应用， 如果菜单项稍多，做成一纵列的文字项从操作上来看也未尝不可，毕竟用户刻意记住其默认的菜单形式也没有什么好处。只是仍然需要注意控制一下数量，如果需要 二级，可以考虑做成弹出的，比如在一级项中选择“排序”，之后弹出选择框来选择

Android还有一种长按菜单，按住某个项目达到一定时间后，会弹出在触点附近的位置

Iphone

Iphone并没有一个明确和固定的菜单模式，较保守一点可以说是没有。一些类似菜单的操作通常是通过弹出选择，或者是拆分成几层，一次 次点击进入更深层的页面去寻找按钮的形式来达成。所以要做Iphone平台的第3方应用的同学应当提前做好准备，从产品策划开始就着手考虑这个问题。最有 效的办法是首先尽可能的缩减功能，其次尽可能的缩减操作方式。否则会发现为了一些细枝末节的操作，还需要设定好几层页面。当然，也可以加入一条操作栏来作 为辅助，只是整体风格和操作就不Iphone了。

说到这里，不得不结合前两点延伸一下，对导航系统进行说明：

众所周知，导航系统主要担负着几个任务：展示内容架构、表明当前位置/状态、表明可以去哪里。在网页上的典型形式为全局导航条。在手机上， 导航系统同样重要，但是受限于屏幕尺寸，一般没有足够的空间放置这样的组件，但手机有着自己的体系：

我们可以看到各平台对导航系统的规划：

• 标题-显示当前位置，可以是文字、图标+文字、也可以是一系列tab
• 菜单-显示可以做些什么，通常包含两种类型的选项：a只针对选中项/只针对当前页，b全局功能如设置和帮助，也就是说菜单大多数作用是发起针对当 前页的操作，或者转到和当前页面没直接关系的页面
• 返回-这个比较复杂一些，也是最需要设计师注意的。鉴于第2条对于菜单形式的描述，如果再加入关联页面的选项，项目数量和类型会使菜单不堪重负。 并且页面标题通常无法准确表达出相应页面的内容，即使放入菜单，也需要用户花时间去理解和回忆。所以“返回”很重要：一个固定的位置，简单机械的一个动 作，一按―一看―一按―一看，不需要刻意寻找和思考。在一个没有全局导航的环境里，一步步后退到自己浏览过的页面，从而了解当前的页面体系，或者重新发起 一系列操作，是个能保证用户找到位置的简单高效的模式。

在做第3方应用时，需要尽可能严格保持以上几点的规范化

3.焦点

焦点更大的意义是在按键机型上，用一个带底色的条框衬托出当前选中的项。

对焦点的设定和控制应当尽可能的简单，需要定义默认聚焦的位置、是否允许上下左右循环

在按键机型上，4个方向键控制焦点向4个方向移动。 通常一个方向只限一种移动方式，如上左图：上下键控制列表区的焦点在列表项间移动，左右键控制标题栏的tab左右切换。 如果列表区也分左右的话，处理起来就复杂了，应极力避免。如上右图：需要先向上移动焦点到标题栏，然后才能按左右键切换tab？但如果当前焦点所在的项处 于第2屏，第3屏，或者更靠下呢？是否需要一直按住“上”，直到上边的内容滚好几屏后才聚焦到tab上？

在一些情况下，焦点容易被遗忘，其中某些对触摸屏机型同样适用：

如上图，页面中包含了一些可操作的元素：人名、图片、网址，这里也会隐藏着一些典型操作，例如对网址可能有“打开”“复制”“保存为书 签”等操作，此时聚焦并按OK键或者点击则需要出现弹出菜单。

另外还需要注意上文提到的横向和纵向切换焦点的问题，正文中同一行如果有两个名字可以聚焦，但是左右方向键已经被标题栏占用，那么切换人 名的优先级应降低，改用别的形式，即使是按上下方向键来左右切换人名也是可以的。

4.弹出框

除了菜单功能的以外，弹出框一般出现在屏幕底端，同时其他屏幕其他部分背景雾化，这有利于用户的视线从密密麻麻的小屏幕中快速找到关键：

弹出框有很多种类型，除了“确定”“取消”等元件的基本布局以外，几个平台区别不是很大，大致可以分成几个类型和对应的处理方式，以下是 我归纳和建议的一些处理方式，只列最适用于S60第3版的：

5.列表

列表项的呈现可以集中定义几种模式：常态、编辑/被调用：

常态：

编辑/被调用：

6.还有一些方面可以事先定义：

• 搜索逻辑
• 事件处理：无信号、低电量提示的形式和时机、来电、来短信、闹钟时间到、缓存已满、发现新版本等
• 文本输入：光标的移动、删除和复制粘贴、选中地址/人名等
• 复杂逻辑的返回路径：有时候会出现操作路径中断并跳转的情况。比如正在写短信时，弹出提示收到新短信，用户此时通过弹出框直接转到了查看短信的界 面，此时“返回”是返回到查看短信的上一层，还是回到编辑短信的界面，这些情况想要集中处理，是比较令人头疼的问题。不久前我大概归纳过一套返回逻辑，大 意是：a路径默认是从操作步骤向前一步一步返回，或者逐层向上返回；b如果遇到路径跨页面体系转移，先按照a的方式返回，到达跨页面跳转的界面时，允许跨 一次跳转，之后按a的方式返回。

以上罗列了一些我的归纳和心得，开始新项目的时候基本可以按此思路先把这些方面统一规范，提及都是习惯用法，追求稳妥的项目可以直接套用，追求创新 的项目也可作为一个评判依据。

最后，用一个简单的例子提及一下：设计与系统规范尽量保持一致的重要性。

假如我们把mac系统的软件风格直接搬到windows中，那么在切换不同软件的时候，最小化、关闭等按钮的忽左忽右，会使我们经常默认就 把鼠标移动到了相反的方向。

每1个第3方应用在手机中都不可能一个程序在战斗，手机中会自带很多系统应用，例如电话本、短消息、设置、浏览器等，他们都遵循着一样的规 范，用户每天也会在这些程序中切换若干次。如果一个第3方应用和他们的基本操作方式不同，每次都会使用户经历仔细观察、出错等过程，想象一下每切换一次软 件就要转换一套思维的痛苦吧。当然，规范是可以打破的，如果我们找到了简单高效并且操作方式和习惯用法没有冲突的方式，可以尝试一下。例如以前触摸屏的列 表项点击一次是聚焦，再次点击为打开，后来普遍改为点击一次就打开。

建议继续学习：

1. 手机界面适配    (阅读：4846)
2. 用谷歌浏览器来当手机模拟器    (阅读：4174)
3. 校园场景中的手机使用调研    (阅读：3985)
4. 2011年手机产品设计趋势（1）：精致实用的界面    (阅读：3940)
5. 手机原型设计工具    (阅读：3653)
6. 手机客户端适配性    (阅读：3427)
7. 手机交互设计资料    (阅读：3313)
8. 触摸屏手机输入法的一些思考    (阅读：3130)
9. 手机游戏设计初体验    (阅读：3169)
10. 再议手机交互设计原则    (阅读：3022)