Windows Mobile

Windows Mobile 将熟悉的 Windows 桌面扩展到了个人设备中。

Windows Mobile是微软为手持设备推出的“移动版Windows”，使用WindowsMobile操作系统的设备主要有手机、PDA、随身音乐播放器等。

优点：界面和操作都和电脑上的Windows十分接近，对于机友来说十分熟悉又上手；各种保存在电脑或手机里的信息、资料可以轻松实现共享；有大量的应用软件可供用户选择;

缺点：占用系统资源高、容易系统崩溃、机型价格相对较高。。

Mac OS X （苹果iphone的系统）

优点：全触摸设计，真的是一次手机，娱乐性能强，第三方软件多

缺点：系统封闭，功能不是太全面

Google Android

该平台由操作系统、中间件、用户界面和应用软件组成，号称是首个为移动终端打造的真正开放和完整的移动软件。

优点：具备触摸屏、高级图形显示和上网功能，界面强大，可以说是一种融入全部Web应用的单一平台

缺点：采用该系统的机型少，上手有点难度;

Android，这是一个开放和灵活的现代平台，已经不能要求更多了。对于HTC Sense未来的发展方向，他认为语音、增强现实和3D都很有意思，但重要的是在合适的时候恰当地使用这些元素。HTC在更高的层面思考，手机将成为人们体验各种技术的中心，他们还在观察手机与其他产品的交互：汽车、电视、机顶盒、PC。这种生态系统的思维将产生许多强大的使用场景。“通过手机可以做各种你想都想不到的事情，这种设想的实现不会太久。

设想将来有这样一个软件，各个平台都有（PC或是移动设备），他会记录用户的操作、录入等习惯，像上传明信片一样传到云服务器，同时进行分析，然后对自己的不同设备进行同步，自动设置真正属于自己设备。界面有一定的可看性，操作方面易上手（第一次用就能很好的把玩儿），快捷（象黑莓一样有快捷键），没有滞后（这点很看重），以及更好的高效性。

1.时间碎片化：手机常常被拿起放下，高效和轻交互，就成为了移动设计的特点。

2.手势的应用：这些手势的应用，相比于键盘、鼠标，能更加快速做出响应，并且降低学习成本，更加直观地进行人机交流。但触摸相比鼠标，却无法达到高度的精准，也无法出现像网页中的鼠标hover、悬停等的效果。

3.屏幕的：在单个界面的展示，简洁再扼要，交互轻量再轻量，层级浅显再浅显。

如何在有限的屏幕中展现更多的信息。有三个要素：

a. 巧妙地利用工具栏与toolbar的隐藏与浮出，最大程度地展示主题，同时快速的做出交互动作。

b. 合理放置控件布局：尽量把最重要的交互按钮和信息，放置在第一屏中，这点相信在PC端网页设计中也同样适用。

c. 有针对性的移植：现在有越来越多的客户端应用，都来自于成熟的网站产品的转移，但网页所能承载的信息与交互，远远大于客户端。于是我们应该高度解理产品的核心功能与精神理念，提取最重要的信息模块，进行客户端的转化移植。

4.输入：用户并不喜欢在手机上长时间的敲击虚拟键盘，（各位一定有经常按错键的时候吧）所以许多优秀的app就会用其他的功能代替键盘，比如微信的语音功能。

触摸屏手机输入时会在界面绘制虚拟键盘，用于输入字符，可以使用在所有应用程序中。特别是在短信和邮箱等需要频繁输入文字时，其输入速度直接影响用户操作效率。

5.触摸屏没有组合键，输入数字和符号需要切换面板。

6.移动输入光标需要精准点击或者借助于放大镜，物理按键可以直接使用方向键切换光标，对于修改错误字符操作产生不便。

3.点击时没有按键那样明确的触感反馈，由于手指点击会遮住按钮，iPhone的按钮被点击时会放大的视觉反馈。

2. 各个平台的特点及优势

1）平台的硬件特性

a) 平台的按键

手机按键是系统自带的，平台也会把按键的功能带入到系统的客户端应用中，他也天然地与用户操作相融合。

手机按键一般分为两类，功能键和导航键。功能键被指派为特定的功能，用户按了后，触发对应的功能，一般与屏幕内容关系不大，如拍照键，只是启动拍照，在其他的客户端中基本无效。

另一类是导航键，被赋予了特定的逻辑规则，她的操作与屏幕有一个逻辑映射的关系，但操作与操作对象分离，用户按键后，在屏幕中得到对应的反馈。如【Back】映射为返回前一页，点击【Back】后，屏幕的内容返回到上一页。

功能键能直接启动功能，它本身对交互的影响不是很大。而导航键则是交互设计的重要组成部分。主要应该注意以下几点：

（1） 客户端的交互导航设计应该支持平台的导航按键的操作。不管你是否已经在屏幕中有虚拟按钮代替了按键已有的功能，也应该支持系统按键的导航逻辑。

（2） 客户端用到了平台的功能键对应的功能，应该支持功能键的操作。如，在客户端中需要调节音量，则应该支持系统音量的按键来控制。

（3） 所有客户端对按键的操作都必须保持一致，不要随意互用。

b) 平台的屏幕适配

由于不同平台的开放程度很不一样，不同的平台产品对于屏幕的大小的设计很不一样，有些只有很少的尺寸分布；有些有很多不同的尺寸，这给适配带来了很多问题和麻烦。屏幕适配设计参见我之前的博文。

c) 平台支持的其他硬件：传感器，屏幕特性等

iPhone 推出来后，迅速风靡全球，创造了一个革新的时代（也有人说iPhone本身不是，但是他创造了一次），除了设计本身外，几个传感器的合理使用也立下了汗马功劳。主要包括，重力加速度传感器、陀螺仪、接近传感器、电子罗盘等。这些传感器在不同的情景下，创造了很多独特的体验，极大的增强了手机的可玩性。

不同的平台或是手机会支持不同的传感器，在界面设计时，也需要考虑它们在不同平台上支持的普及程度，以及不支持的时，能提供的相关代替设计方案。

2）平台的界面特性

a) 应用入口形式

应用程序的启动入口是指用户启动程序的交互界面及操作形式。不同的平台上，对于启动入口操作和界面也有较大的区别，这是展示平台特性的第一印象。同时，不同平台及手机公司为了使品牌形象更加突出也会在这里多做文章。

从交互特性上看，应用程序的启动入口主要有以下几个特征和注意点：

b) 页面基本结构

页面的基本结构布局，决定了手机界面的主要风格，在不同的平台上为了表现出设计的差异和风格，在界面布局上都有所不同。但是，总的来说还是没有与iOS有何本质的不同，主要在形式上略微的不同。

iOS：

Android：

Windows Phone7：

Android 的手机厂商都更改了原生系统的界面，不同Android手机在界面的展示上多有不同。在Android客户端的设计上，本身有不少都是从iOS上直接移植了界面，导致了它的更多不同。但是不管怎么样，界面上操作和导航逻辑要符合平台本身的特征。

在框架的设计上，我是倾向于把最核心的操作放在底部，方便用户的单手操作。iOS的设计把导航按钮方在左上角，远离大拇指的操作区域，就是容易造成用户脱手“甩机”，也影响操作效率。

c) 主要导航特性：

导航作为一个平台的主要交互特性之一，不同平台之间也存在较大的差异。iOS在设计上逻辑严密，所有的应用自成一体、浑然天成；相比之下，Android像是由iOS和android设计师杂交的产物，在不同的应用上导航系统混乱，不太成体系；Windows Phone 7 的导航在界面展示上，标题采用全景图的形式，真是另辟蹊径，自成体系。

在这里主要讲一下不同平台下的导航按键、title和Tab、返回逻辑、退出程序几个小点。

d) 菜单及操作形式

这几个代表当前最高水平的移动平台，都是以手指触摸为基础的直接操作界面。iOS只提供了直接操作的方式；Android和Win Phone 7 还增加了几个硬键按钮配合操作，但总体也是以直接操作为主。几个平台都有菜单操作，但是展示的形式不同，但也在相互的借鉴。

由于手机屏幕较小，一屏内容往往显示一个对象或信息单元，toolbar的操作正是对这个单元进行操作的。如果是对单元内的对象操作，更多的设计都是在界面中直接设置操作对象（如屏幕内的操作按钮）。

e) 信息提示

信息提示方式，各个平台之间也都在相互学习。信息list作为Android系统的最核心的设计优势，现在iOS5也开始应用。同时许多Android手机及锁屏应用在锁屏界面与提示信息间做更多地权衡，使用户能更快地处理信息，提升效率。

各个平台都提供了对话框的形式，只是在叫法上略有不同，如alert，popup，dialog，raw notification等，其主要的交互操作没有区别，都是对话框的基本操作形式。也有一些变异的反馈提示框，如android系统提供的快速消失的反馈提示，做成轻量级的，对用户干扰也减到更少。

Android系统提供的状态栏的消息提示机制，是处理多应用push信息的一个十分创新的设计，可以说是android系统的最佳设计。用户可以在任何界面中，快速的向下拨动状态栏呼出信息list，也可以再向上拨动手指收起提示信息。但是，在最近看到的iOS5上也看到了它的更新特性中，这一点就赫然在列。所以，有好的特性，不同的平台也会相互学习。

iOS上也有它的创新提示，就是在程序图标上来进行新消息数量的提示，这在后面的几个平台上都有应用，只是不同的平台上，表现形式略微不同，就是视觉上微创新。

Windows Phone 7 提供了tile形式的提示信息显示方式，那只是样式上的不同，在设计的本质上，差异不大。

3. 移动应用在多平台适配的原则

一个产品的规划，很少会仅局限于某一个平台，都会进行跨平台的适配。那应该如何进行适配呢？

这里主要有两个观点，以设备为中心来设计还是以应用为中心来设计；以设备为中心的设计师认为，应用界面应该与设备的设计规范保持一致，让用户快速上手，不觉得陌生。以应用为中心的设计师认为，保持所有的平台上的一致性，同时，很多多平台的应用开发工具也是为开发人员提供了多平台界面移植的便利，但是对用户体验是否好，却有待思考。

在多平台适配中遵循如下原则

1） 客户端的设计规范应该以平台规范为基础

2） 在多平台中，应保持统一的品牌标识，包括logo，视觉风格，核心功能点等等。

3） 更多地与平台的特性相融合，运用平台提供的特色功能，来减少用户的输入或者其他体验提升点。如拍照输入，传感器的使用等。

每个平台都需要注意的问题有：

1） 移动的特性决定了手机信号的强弱不均，如何处理在弱信号下的设计？

2） 需要考虑在断网情况下，如何快速恢复中断？

3） 如何设计手机推送的问题？

4） 如何尽量避免手机的固有，如屏幕小，输入不方便，电源紧张等？

5） 如何尽量通过手机的特有特性来提升体验，如各类传感器，声音提示等？

4. 后记

当我从3月份拟好提纲写这几篇文章到现在，不过短短几个月时间，各大公司的移动平台就都推出了新的版本，对平台特性总结的速度有些赶不上平台更新的速度。

从本质上说，iOS是一个开创性的设计，也引发了客户端的高潮，其他的平台还没有脱离iOS的痕迹，虽然各大公司都在努力创新，形成自己的风格，但是还远没有到开创、的程度。

从客户端的交互设计上来说，我们要做的是如何发挥平台的特性上的设计优点，把客户端的体验去做好，而不是去改变平台的设计特性。所以，做客户端设计的设计师，需要时刻关注平台特性的更新，这都是你提升客户端体验的契机。 

设计模式

设计模式是在为解决特定问题，可以采用常用的一些常规模式。同时，就像ios guildline里面说的，平台模式也可以减少用户的认知负担：“用户喜欢了标准化控件的使用方法和行为，所以他们不必停下来思考该怎么使用他。当面对那些看起来、用起来不符合标准的控件时，用户之前的经验就失效了。”

Iphone中的”设置”就很好的解决了某个问题：当我同时对A、B、C…等操作编辑但又不互相影响的时候，就可以采用设置这一模式。

这对于其他app中的设置和其他信息架构起到启发作用。

键盘

还以小小的键盘为例，在iphone app交互设计中，免不了涉及用户输入时调用相关的键盘。交互设计师提供的交付物最好能够明确表现何时采用合理的键盘,以减少用户输入的需求。

1、拨号键盘

顾名思义，用在拨号或者只需要输入数字的地方。

比如：iphone QQ登录或是搜索好友，调用的键盘就是类似拨号的数字键盘。

2、邮箱输入键盘

产品的登录和注册少不了填写相关的邮箱。Iphone在联系人信息中就对邮箱使用了非常便利的键盘。

“邮箱键盘”方便输入英文还有@字符。

3、url地址,移动互联网的普及让用户输入网址更加便捷。

iphone网址输入时调用键盘

▪iphone Native App较常见的导航如下图所示：

▪

▪手机屏幕底端：A、B、C、D四个tab组成该Native App的全局导航，这是我们经常见到的tab导航栏。

▪手机屏幕顶端：主要有四种形式。第①种形式是在该位置中心显示产品的logo；也可以将logo适当调整位置，将常用操作或快捷入口放在该位置的右侧。第②种形式是在该位置有两或三个tab选项。第③种形式是在该位置中间显示当前任务标题，在左右两侧放置导航控件或功能控件。第④种形式是在该位置放置搜索框。

▪与以上的Native App导航方式相比，Web App导航方式有着巨大的不同，如下图所示：

▪

▪Safari浏览器的工具栏将一直占据着屏幕的底端位置，全局导航只能被动移动到屏幕的顶端位置。这是影响Web App导航设计的最重要因素。

▪如果产品的功能比较少，且没有特别要突出的功能的时候，可以设计成上图中第①种导航方式。此时存在的问题是如何表现出产品的品牌，毕竟在Safari浏览器登录某网站比运行一个Native App给人的品牌认同感弱很多。

▪如果将产品logo表现出来，且产品需要将用户常用功能突出（比如刷新功能或者发布入口），就需要设计成上图中的第②种导航方式。

▪如果在A功能板块下，还需要设置子类别选项，则导航栏中又多一组tab。此时的导航方式就如同上图中的第③种了。

▪当然，在执行某一项任务的时候，全局导航可以暂时“归隐”，只保留一行标题栏和左右两侧的导航控件或功能控件。如上图中第④种导航方式所示。

▪在该产品设计中，为方便用户在各功能板块之间快速省力地切换，设计师希望全局导航栏可以保持长久悬停，不要像一般wap网页似的让导航随网页滚动消失。这样的话，基于浏览器的Web App 导航系统便捷性就和Native App相媲美了。

▪然而，浏览器工具栏将全局导航逼到了屏幕的顶端，却又造成了导航头部过于沉重的问题。如下图所示：

▪

▪如果将logo栏中的常用功能（例如刷新或发布入口）和全局导航都设计为悬浮停留的形式，内容区的信息展示空间就比Native App减少了一行的高度，如上图中的①。而且，某些页面需要在全局导航的下方出现二级导航；悬停不动的3行导航大大吞噬了屏幕本来就很宝贵的内容显示空间，如上图中的②。

▪让用户在如此狭小的空间不得不频繁滑动屏幕浏览信息，这样的体验太糟糕了。这个严重的问题很让设计师困扰，因此需要重新设计一下导航系统。设计过程主要包括：优秀竞品分析、方案遴选。

▪优秀竞品分析

▪首先，分析对比了三款优秀的Web App：Google+、FT Web App、Twitter的导航方式。浏览环境均为iphone Safari浏览器。

▪1.Google+

▪

▪导航系统特点：

▪￭全局导航单独形成一个页面，其他页面不出现全局导航；

▪￭导航栏沿用了ios系统原生控件的形式：标题+导航或功能控件； 

▪￭标题栏在页面中悬停不动

▪优点分析：

▪保证了每个信息浏览页面的导航栏简洁轻薄，尽量少的占用信息详情的显示空间；保证了其核心功能（此处是微博浏览功能）的良好使用体验。

▪缺点分析：

▪全局导航隐藏较深，降低了用户在不同功能板块快速切换的便利性；全局导航隐藏较深，用户看不到其它板块功能，大大降低了用户点击使用其他功能的可能性。

▪2. FT Web App

▪

▪导航系统特点：

▪￭Safari浏览器URL一栏一直悬停存在，并将品牌文字FT Web App显示在顶端;

▪￭全局导航被隐藏起来，点击功能键后在页面顶端出现；

▪￭二级导航出现在页面顶端；

▪￭全局导航和二级导航由于新闻板块数量较多，都采取了单行空间不完全呈现的方式，可滑动选择其中某一项；

▪￭所有导航随页面滚动，不在屏幕中保持悬停；

▪优点分析：

▪FT Web App导航设计最大的优点就是繁重导航的轻量化处理。全局导航和二级导航中的新闻板块都非常多，若将这些板块都展示出来，恐怕要占用屏幕的一半显示空间。FT Web App于是将全局导航隐藏在一个功能键之后，二级导航也只给了一行的显示空间。

▪缺点分析：

▪展示给用户的导航只是其全部新闻板块的冰山一角，无法给予用户全部概况浏览的机会，也就无法很好的激励用户去尝试被隐藏的新闻版块；同时，用户寻找某一个新闻版块或者在页面底端回到页面顶端的操作成本略高。

▪3.Twitter

▪

▪导航设计特点：

▪￭全局导航只有一行，品牌展示浓缩在主页图标中（Twitter小鸟图标）；

▪￭全局导航一直保持在屏幕顶端悬停不动，不随页面滚动而滚动；

▪￭二级导航在点击全局导航某tab后，以菜单列表形式出现。

▪优点分析：

▪在屏幕顶端悬停不动的全局导航，可以方便用户在不同的功能板块之间快捷切换，降低了用户的信息寻找成本；Twitter Web App的导航只有一行，为用户保证了尽量大的正文内容显示空间。

▪缺点分析：

▪一些常用的功能键被隐藏在二级导航中（比如新信息发布入口），一方面增大了用户的寻找成本，另一方面降低了这些常用功能对用户的激励使用效用。

▪基于对以上三款Web App产品导航系统的分析，设计师对目标项目的导航系统设计形成了以下框定：

▪￭全局导航方便用户快速寻找以及功能板块间的切换；

▪￭导航尽量轻薄化处理，尽量保证足够的正文内容区显示空间；

▪￭将用户经常使用的功能键呈现在前面。

▪方案遴选阶段

▪基于项目的实际需要以及对竞品分析的思考总结，设计师尝试了3款导航设计方案，并对每一款方案的优劣之处进行了详细分析。

▪导航设计方案一

▪

▪设计说明：

▪￭ ABCD是产品的四个功能板块，组成全局导航。

▪￭ 全局导航在屏幕顶端保持悬停不动。

▪￭ E是新消息发布入口，属于用户常用功能。

▪￭ E采用半透明显示方式。

▪￭ E停留在屏幕的右下角

▪该方案的优点：

▪屏幕顶端只有全局导航一栏，导航的轻量化为正文内容区节省了尽量大的显示空间；全局导航悬停不动，可以便于用户快速切换到不同的功能板块。

▪该方案的缺点：

▪右下角的新信息发布入口致使浏览页面不够清爽，会对用户造成一定的视觉干扰；新信息发布入口没有必要在任何页面都显示，于是可寻性出现了危机；品牌logo无法显示，品牌感较弱。

▪导航设计方案二

▪

▪设计说明：

▪￭ E是新消息发布入口，属于用户常用功能。

▪￭ ABCD是产品的四个功能板块，组成全局导航。

▪￭ 屏幕顶端的两行导航栏在用户刚进入页面的时候出现，在用户滑动屏幕浏览信息的时候消失。

▪￭ 屏幕右下角半透明功能键在导航栏消失后出现，点击该键导航栏出现。

▪该方案的优点：

▪浏览信息的时候导航栏消失，为用户提供提供了最大的正文内容显示空间；可以显示logo，品牌感较强；新信息发布入口的可寻性较好。

▪该方案的缺点：

▪屏幕右下角半透明功能键致使浏览页面不够清爽，会对用户造成一定的视觉干扰。

▪导航设计方案三

▪

▪设计说明：

▪￭ E是新消息发布入口，属于用户常用功能。

▪￭ ABCD是产品的四个功能板块，组成全局导航。

▪￭ 屏幕顶端的两行导航栏在用户刚进入页面的时候出现，在用户滑动屏幕浏览信息的时候第一栏向上消失，第二栏上移至顶部保持悬停不动。

▪￭ 手动下拉全局导航栏，可以下拉出第一栏导航。

▪该方案的优点：

▪浏览正文信息的时候，仅显示全局导航一栏，做到了导航的轻薄化；全局导航悬停不动，可以便于用户快速切换到不同的功能板块。

▪该方案的缺点：

▪下拉全局导航时，可能会有误操作的危险，虽然可能性很小。

▪综合以上的分析，考虑到正文内容区显示空间的大小、对产品的操作便利性以及产品品牌感三方面因素，最终决定将方案三作为导航设计的基本形式，并继续进行进一步丰富细化。

▪总结：

▪浏览器的工具栏一直占据着屏幕的底端位置，全局导航只能被动移动到屏幕的顶端位置。如何平衡操作的便捷性与正文信息显示空间最大化的关系，是Web App导航设计的关键所在。

▪最佳方案总是权衡的结果。每一款设计方案解决某些问题的同时也会产生新的问题。此时设计师需要知道哪些功能是最重要、优先级最高的，保证核心功能的良好用户体验是评判设计方案的重要准绳。

可脑袋一旦被拧下来，就什么也无法吃的样子了，不是吗。说正事儿吧。Designing for touch，关于这个话题及相关的文章，最近貌似已然铺到大街上了，不过我还是做我的吧。在标题里加了个不伦不类的“又是”二字，以示区分。内容方面应该会有些交集，但这是我自己的。Josh Clark老师最近蛮活跃的。在本文中，他将向我们介绍一些触屏移动设备用户界面设计当中需要注意的问题，并对iPhone、iPad和Android相关设备在触控交互体验方面的友好性进行了对比和分析。欢迎，走着。

对于移动设备的操作系统及应用来说，判断其用户界面设计方案是否优秀的一个重要衡量标准，就是看它对于手指触控操作的友好程度。相比于桌面计算设备及相关的软件环境，触屏移动设备所具有的交互特性几乎将用户体验设计师们带入了工业设计的领域；设计方案更多是在体现着人机工学方面的原理，而不再是仅仅用来规划内容与功能的视觉呈现方式。

拇指热区与底部原则

首先，我们需要了解人们通常会以怎样的方式将手指停靠在设备上。拿手机来说，普通青年们多数会使用拇指来进行触控操作，所以触屏手机的界面交互方案基本是围绕着拇指来进行打造的。

拇指是很不可思议的，据说它是将我们与动物区分开来的重要标志之一...拇指的功能具有相当的弹性，同时也受到一定的局限。对于常规的触屏手机来说，我们可以使用拇指扫过屏幕当中的大部分区域，但其中大约只有三分之一属于真正有效的触控区域。所以在设计当中，要尽量将最重要的界面交互元素放置在这个范围当中。在右手持机的状况下，有效触控区域位于屏幕的左下方：

这也正是移动系统或应用中一些重要的工具栏或导航结构通常被放置在界面底部的原因。与此相反的是，在传统的桌面设备系统环境中，导航菜单一类的界面元素通常被放在界面顶部，无论是本地软件还是网页基本都是如此。对于我们有限的拇指作用范围来说，这种传统布局方式显然不能在移动设备的用户界面当中很好的适用。

相比之下，左下角还是右下角的问题略显次要。我们在实际当中经常会更改左右手持机方式，想想看是不是这样，譬如对于右撇子来说，当他们正在写字或是需要同时使用鼠标操作桌面设备时，通常会将手机交于左手操作；而左撇子们则正相反。不过在多数时间内，使用右手持机的用户还是要相对较多一些。

底部原则可以帮助我们对界面当中的可触控元素进行更好的组织。最常用的功能按键应该被放在拇指最容易触摸到的热点区域当中，而其它相对次要或是比较敏感的控制元素则应该尽量避开这个区域。以iOS中的“编辑”按钮来说，它通常被置于界面右上方，这个位置即可以保证它清晰可见，同时又不会被很容易的触碰到，以免发生误操作。

另外，底部原则不仅与拇指的作用范围有关。当我们使用拇指在屏幕上进行操作的时候，手指下方的内容部分将会被遮挡住；只有将交互控制元素放在内容区域的下方，才能让这种负面效应降至最低。其实这是一条具有广泛适用性的设计原则，我们可以在很多其他类型的设备中看到这种原理的体现，例如iPod、计算器、带有实体键盘的普通手机、电子秤等，无不是内容在上，控制在下。

我，机器人(Android)

在Android设备中，底部原则这档子事被机身下方的实体硬按键搞的复杂了些许，尤其是冰淇淋三明治之前的平台。这些硬件级的控制按键占据着底部区域，在某种程度上会与应用内的底部交互元素形成视觉上的竞争。彼此层叠在一起的软硬件工具栏会使用户在快速操作的过程中产生迷惑，增大误操作的几率；对于在两个维度上共存于拇指热区当中的软硬件按钮，它们之间的冲突几乎是不可避免的。

固化的硬按键是无法被移除的，避免控制元素之间产生冲突的最直接的办法就是让虚拟与实体的工具栏在视觉上彼此分离，而这就意味着需要将Android应用中的相关控制元素和导航结构放置在用户界面的顶部。这自然不是最理想的解决办法，因为界面顶部离拇指热区远着呢，你要触摸其中的某个按键时，几乎会将半个手掌都覆盖在屏幕上。不过比起与硬件工具栏层叠在一起的方式来说，这种解决方案仍是利大于弊的。

这种将重要的控制及导航元素放在顶部的做法与iOS设备的方式正相反。虽然iPhone的Home按键同样在机身底部，但它的表现形式与Android设备的硬按键有很大区别，它不会对应用界面底部的相关操作元素带来视觉上的干扰。下面的截图展示了Foursqure应用在这两个平台中的界面设计方案对比：

移动版本的网站

毫无疑问，当我们在移动设备中浏览网站页面时，类似的问题也会出现。我们可以将网页理解为应用中的应用，因为它需要通过浏览器这个应用程序进行输出呈现。移动平台当中的很多浏览器都会将一些常规的控制元素放在底部工具栏里，这在某种程度上又有可能与页面当中交互元素产生视觉上的冲突。所以，对于移动版本的站点来说，一个最基本的设计原则就是不要将重要的控制元素或导航结构通过CSS的position:fixed定位方式固定在用户界面底部。

不过，与Android应用中的解决方案有所不同，对于Web页面来说，将控制元素与导航结构放在界面顶部的做法同样会产生很大问题。毕竟当前绝大多数的主流触屏手机仍属于小屏幕设备，而传统Web页面的横向全局导航结构通常由若干包含着一到两个词语的导航项组成，这对于手机屏幕来说显得太拥挤了，我们必须另想办法来解决导航栏布局的问题。

Luke Wroblewski在Mobile First一书中提到：“在很多移动版本的站点中，用户首先会看到一大坨导航结构，而不是内容。在移动应用的上下文环境当中，时间永远是宝贵的，流量搞不好是要花钱的有木有，你必须尽最大努力让用户在首屏中得到他们最想获取的信息。”

确实是这么回事。移动版本的站点，在布局方面，应该使主要内容尽量多的占据着首屏当中的空间，而导航结构则应该以某种缩略的形式出现在相对次要的位置。Wroblewski通过一个实例来倡导这个设计模式，也就是Ad Age的移动版站点。其首屏当中，除了网站标题及最新内容列表之外，右上角的菜单按钮是界面当中唯一一个交互控制元素。当用户点击这个按钮时，导航列表才会出现在屏幕当中。看上去，整个导航列表好像是另外一个界面，但它实际上是被放置在页面最下方的，而菜单按钮只是个锚点而已。

Wroblewski继续发言：“这个设计方案在首屏当中使用了最小化的导航机制(只有一个按钮链接)，用户可以集中精力去阅读每个分类当中的最新文章。当他们浏览至当前页面的底部时，还可以直接通过导航列表来探索更多的内容。最棒的是，顶部的菜单按钮只是一个锚点，整个导航机制不涉及到任何会导致交互流程复杂化的元素，例如JavaScript、覆盖层或是的导航页面等。”

“内容在上，控制在下”的规则看上去蛮简单的，不过一旦涉及到实际的上下文环境，例如操作系统或浏览器的用户界面特性，设计师们要考虑到的情况就变的复杂了。截至目前，我们可以将讨论过的话题归纳为几点设计原则：

∙对于iPhone中的客户端应用，尽量将重要的交互对象及导航结构放在界面底部。

∙对于Android中的客户端应用，尽量将重要的交互对象及导航结构放在界面顶部。

∙对于移动版本的网站页面，尽量将导航结构放在页面底部(注意，不是当前用户界面的底部)

这些设计原则仅限于手机的上下文环境当中，而对于屏幕规格较大的触屏设备，例如iPad来说，规则就要发生变化了。

平板电脑

拇指热区的相关规则同样适用于平板电脑，不过，由于持机方式不同，热区的位置也有所变化。iPad的拿法在很大程度上取决于整个人的姿态。我们在站着的时候，需要一手持机一手操作；坐在桌前的时，我们往往会用一只手像支架一样从侧面架住iPad，而另外一只手用来戳戳点点；坐在椅子上的时候，我们通常会将它放在膝上进行操作；而躺着或是半卧着的时候，又会将它立在腹部，一手支撑，一手操作。

每一种持机方式几乎都对应着一种特定的热区规则，而且在每一种姿态当中，设备与我们身体的距离也有所不同。例如，站着的时候，我们会把iPad端的比较近，而躺下的时候就相对较远了。

虽然听上去有些复杂，不过在这些上下文情景当中的交互行为还是存有一些共同特征的。首先，用来持机的那只手通常会握住机身的上半部分，因为这样最符合杠杆原理；相应的，拇指热区基本会位于屏幕的前三分之一部分，偏向左上角或右上角。其次，iPad的屏幕相对较大，用户很难像使用iPhone那样瞄上一眼就能看到界面当中的几乎全部内容。正像对待普通的印刷品或是Web页面那样，用户通常会首先将目光聚焦于iPad界面的顶部区域，所以我们的设计方案也要相应的在这一点上符合用户习惯。换句话说，在操作iPad的过程中，无论是目光还是手指，它们的主要活动区域都是设备的上半部分。而机身的下半部分不仅会在很多时候被用户视而不见，而且在某些特定的环境中它真的是不可见的，例如当我们躺在床上的时候，这部分很可能被衣物或被子遮挡住，实在是悲催。

所以，与手机界面不同，在iPad及同类平板设备的应用当中，主要的交互控制对象应该被放置在界面的左上角或右上角，以便拇指可以很容易的触摸到。Instapaper和Twitter在这方面做的都不错：

需要注意的是，应该尽量避免将交互元素放在屏幕顶端正中间的位置，否则用户在进行操作的时候，手掌会将很大一部分内容遮住。实际上，任何会对下方内容产生直接控制作用的交互元素都不应该被放在这个位置。在The Daily的iPad应用当中，内容正上方有一个滑块，用户可以通过拖动它来前后切换文章页面。意图不错，不过当你执行这个操作的时候就会发现，自己的手掌会遮挡住文章内容，而手指则会挡住缩略图，体验弱爆了。单凭这一个地方的疏忽，这个设计方案就足够作为反例登场了。

又一个底部原则

我们可以从The Daily的失策当中了解到，对于iPad应用来说，在某些特定的情况下，控制元素还是避开顶端微妙。你可以将它们放在底部甚至侧面，只要控制元素本身及其所需的交互行为不会对内容的可读性造成影响。我们来看看Sydney Morning Herald's的iPad应用是怎样做的。如下图所示，在该应用的界面底部有一个页码指示器，当用户对其进行拖动操作的时候，对应页面中的文章标题就会以列表的形式出现在指示器的上方，使用户不用翻页就能大致了解其他页面当中的内容。虽然文章标题列表会将页面中的内容遮挡住，但在这个交互情景当中，用户最为关注的是列表中的文章标题，而不再是原来的主要内容区。

对于在不同的情况下究竟应该将控制元素放在顶部还是底部的问题，我们不妨在这里弱弱的归纳一下：

∙对于那些起到界面导航作用的交互元素(例如“菜单”、“返回”、“关闭”等)，以及用来完成分享、收藏、编辑、删除等功能的按钮，通常可以将它们放置在界面顶部。

∙对于那些用于浏览或预览内容的控制元素来说，界面底部是最佳位置。

所以，我们可以在很多书籍或杂志应用当中看到，页面缩略图列表通常会被放在界面底部。(可以参考之前iPad应用的十大用户体验设计准则一文当中展示的Martha Stewart Living杂志以及Pulse的设计方案)假设你正在设计一款与地图相关的应用，界面当中有一个地标托盘，用户可以将地标从这个托盘当中拖拽出来，并“按”在地图上的某个地方。在这个例子当中，托盘同样应该被放在界面底部，这样可以保证当用户从托盘里将地标拖拽出来的时候，地图不至于被手遮挡住。

交互对象的尺寸

如果说交互对象的布局位置取决于平台类型及持机方式，那么它们的尺寸则在很大程度上由手指的大小来决定。我们必须将这些交互元素设计的足够大，才能保证用户可以进行准确的辨识和触击。

不过，要做的多大才算够呢？不妨抬起手看看自己的指尖。很多系统平台的设计规范都在这方面进行了描述，不过我个人觉得苹果做的仍是最棒的：理论上，可触击元素的最小尺寸应该为44像素(约1/4英寸或7毫米)见方。

The comfortable minimum size of tappable UI elements is 44 x 44 points.

请注意point与pixel的换算关系在Retina屏与普通屏幕之间区别。

在移动应用的上下文环境中，足够大的按钮不仅便于操作，而且可以让用户维持必要的注意力，避免被周围的环境所干扰。

44像素见方的最小规格只是一种理想状态下的情况，在实际当中，合理的折中方案通常是必需的。即使是iPhone用户界面中的很多原生控件也避开了这个规则的。最典型的一个例子就是系统自带的键盘，其中每一个键位的高度是44像素，但宽度只有30像素；而横屏状态下，其宽度是44像素，高度则变为38像素。不过这也是苹果的无奈之举，因为怎样都必须将完整的QWERTY键盘搞到界面当中，所以必须在设计方案当中有所取舍。

参考苹果的做法，当空间的局限使得我们确实无法实现44像素见方的设计方案时，应该尽量保证其44×30的最小规格。

元素的尺寸与空间布局

上个世纪，不少人都被卡西欧的计算器手表浪费了大量的青春年华。问题不仅仅在于那些微小的按键会让戴着它的人看上去很二，最不靠谱的是，这些按键的排布实在是太紧密了。你想按5，但通常会按到8或是2；与其说是计算器，还不如叫它幸运转盘更合适些。尺寸过小的按键以及毫无间隔空间的布局，是产生这种结果的两个最直接的原因。

为小屏幕设备进行界面设计的时候，这类挑战确实是我们经常需要面对的，而造成问题的根本原因却通常不是产品需求本身。无论是在计算器手表的全盛期，还是如今，我们时常会听到产品需求方翻来覆去的念叨着：“咱就把这些东西再挪近一些吧...我只想在这个工具栏里再加一个按钮...” 加你妹啊！

如果我们必须在设计方案当中将交互元素排布的非常紧密，那么至少要把它们各自的尺寸尽量做大。想想iPhone原生的拨号键盘界面，或是Skype等应用。界面当中的拨号按键之间的间隔通常都很小，甚至没有间距；而每个按键的尺寸几乎可以用巨大来形容，因为这样可以有效的降低误操作的几率。

其实，无论是iPhone原生的拨号界面，还是上图所示的Skype中的同类界面，它们都在底部导航工具栏的上方放置了一些控制按键。如果以我们在前文当中提到的一些原则标准来衡量的话，这种做法其实不算得当；但是在这几个具体的情景当中，这些控制按键的大尺寸特质却可以有效的降低它们与底部导航工具栏之间的视觉冲突。

所以，要在有限的小屏幕可视区域当中打造出成功的用户界面设计方案，我们必须结合实际的产品需求，在交互元素的尺寸和空间布局等方面做好充分的权衡与判断。