移动设备的交互和设计 - UCD大社区

有限屏幕的无限空间 -从空间角度谈移动界面扩展

wangrong03 — 2013-01-05 09:08:57

移动产品大家都不会陌生，几乎是无所不能，可以随时随地满足用户的多种需求。那么移动产品设计呢？有没有遇到类似的情况，PM小A说：产品要增加功能，在界面上加个入口，小意思嘛。小B说：内容太少了，咱们再扩展一下页面，没有难度嘛。小C说：能不能挤一挤多放个功能？用户真的有需求…

可界面的空间是有限的，内容需求却是无限的，从3.5寸到5.2寸到9.7寸的pad，不管多大尺寸的屏幕，都逃脱不了这样的命运。就像房屋的空间和放在里面的东西，永远存在东西放不下的问题。既然是同类的问题，能不能从相同的角度出发来找到解决方案呢？

在建筑学中，空间主要指视觉层面感受到的几何学意义的三维物理空间，也就是空间中的人对环境的一种三维层面的感受。因此空间扩展就是从不同维度来寻求解决方法，包括收纳、层级化分割和视觉感受扩张等。类比到移动产品的体验上，最基础的也是如何让有限的屏幕承载更多的功能，让用户感受到空间的舒适。本文就借助建筑学的空间扩展概念，从信息收纳、层级化信息、变脸和视错觉四个维度来谈谈屏幕空间的扩展。

收纳

顾名思义，把不用的东西收起来，表面上干干净净，打开会找到想要的内容，这种方式特别适合零碎功能的整合。

1.收纳方式分类，主要有以下三种。

a. 定义好收纳规则和内容

即规定整理好要呈现给用户的功能，这一种的关键点就是抽屉的标签，让用户在关着的情况下能究竟收在哪里，入口在哪里。

那么收纳的形式呢? 从交互模型来看有很多种，最典型的像Path 的侧边栏式，上下折叠式，沉入式，还有Android系统级操作的处理方法。目的都是在用户不会用到的时候，把相关的信息藏起来，收起来，并且有个永远存在的入口，当用户需求就能快速拉开调起，非常方便。

b. 定义好收纳规则后，用户随意扩展内容。

这种收纳方式特别适用于记事类或者日程类的应用，因为相对来说，这类应用的主要信息源是用户本身，且纵向无法预估和控制信息的量级。那么这样一种定义好收纳规则，但内容无限的方式就特别适用了。下图就是一种典型的记事本信息收纳方式。

c. 用户自定义规则和内容，随时可以整理替换抽屉的内容。

既然空间交给用户，怎样分割和收纳都由用户自定义，那么这一种方式的关键就是“扔”和“装”都要方便，可以简单快速的将内容装进抽屉。最直接的例子就是iphone的app界面，拖动叠加即可形成一个收纳，拿出去也非常方便。

2.收纳样式，主要分为“有门抽屉”和“无门抽屉”两种

a.有门抽屉

是指即使抽屉关闭，里面的信息收纳着，也需要固定存在的入口时刻提示用户从哪里开启，像侧边栏，永远有开启按钮的。

b.无门抽屉

是指开关抽屉门的都是通过高级手势操作唤起的，连门都不需要，只需要用户知道开启方式，比如长按、滑动指定信息条等唤起。
一般来讲，高级操作对应的也是收纳的较高级，不常用的信息，用户知道开启方式就可以，连抽屉门的空间都可以节省出来。

层级化信息

空间有限，那么要想空间利用更有效，可以将空间分割，分模块展现内容。不管是单纯的list列表，瀑布流，还是其他什么形式，总会从其他维度找到剩余空间。类比成道路交通，飞机、道路交通、地下轨道并行，便是充分利用了空间。移动界面中同级、下级的页面跳转，可以利用动效带给用户更接近真实的空间层级感。其中包括

a.同级多tab架构

b.下级筛选（包括下拉式和浮层式）

c.沉浸式下一级体验

即还原了相机近大远小的原理，通过层级分割展现更多信息页面，这种方式的好处是每个界面都可成倍扩展。

(以上只是各类别的列举，相同属性的内容都可进行扩展)

变脸

在Web 设计中不会在意细小的空间，状态条就是状态条，即使没有状态，空着也好，但移动空间实属宝贵，那么在不需要的时候显示其他内容，也不失为一种解决方案。基于代码实现的虚拟空间，都是可以有If-then条件的。
举例来说就是在XX情况下，按钮状态为A；在XXX情况下，此按钮状态为B。或者同样区域可以显示不同内容，承载不同的操作。

a.同区域显示不同状态

即延续web的状态条逻辑，将更多状态显示的集成发挥到极致，实时感知情境的变化，作为与用户直接沟通的对话窗口，承载更多信息来达到节省空间的作用。

b.同区域显示不同功能

像输入框的提示，情景化的按键等，会根据不同的框属性，适配不同功能按键。如下图所示比如联系人列表，在默认状态显示联系人列表名称，当用户需要搜索时，就会展开搜索框可进行输入。同一个区域在不同状态下，承担着两种不同的任务和内容，但这种方式的局限性是可扩展范围较小。适合一些小功能的位置集成。下图是某应用中的联系人列表，很直接的一个小点就是，将联系人列表显示和搜索联系人操作集成到同一区域，用户也容易接受。
同样同区域不同功能的变化在输入法的按键上体现的更为明显。

显示联系人列表

展开搜索框

目前对于移动端的应用，更多是对这种“变脸”逻辑的研究和扩展，很多产品也推出了情境化感知的概念，即扩展移动设备可感知的情境，增加if条件，让空间利用实现到极致。包括现在热门的对Smart Bar的讨论也是同样的道理。
因为移动设备有各种传感器，能实时收集用户信息，这些都是让应用变得更加智能的前提。

补充一点

在室内设计中，由于镜面具有反光和成像的功能，因此将其用于室内不仅能增加室内的亮度，而且能起到扩大空间感、丰富室内装饰效果的作用。这种视错觉的运用同样可以应用到移动界面设计中，通过轻量化视觉元素，增加转场动效等方式来使用户操作过程中体验更顺畅，从感受上起到扩展空间的效果。当然这更抽象到一种情感设计的层面，具体的应用方法还值得大家一起探讨。
下图同样为主屏解锁界面，一种是到点到点，另一种是点到边，哪种看起来空间更开阔呢？明显第二种会给人带来一种可扩展的空间感，第一种就显得完全平面化了很多，同样是一个界面的信息，第二种就给人一种更广阔空间的心理暗示，通过沉浸感的交互方式让用户感受到无限空间。

总结

好了，以上就是从建筑学空间扩展的视角出发，从收纳、层级化信息、变脸和视错觉四个层面分别对应到移动应用中,希望可以为你在移动应用中扩展信息空间的设计带来一点灵感，每个层面还可以扩展出更多的方式，我们一起在设计中不断积累和总结吧，充分利用屏幕空间，让有限的空间可以实现无限的延展。

转载请注明出自”百度MUX”

相关话题：移动设备的交互和设计源地址：http://mux.baidu.com/?p=3433

从app加载页面说开去

wangyi — 2012-12-17 18:27:04

都说好的交互设计的评判标准之一是“别让我等”，但互联网产品总是受制于实际的网络问题。移动端产品则更为明显，2G、3G环境下加载不够给力，wifi环境也未必每次都是那么顺利。因此“别让我等”更像是种奢望，我们倒应该思考的是“如何优雅而不令人烦躁的等”。与之最直接关联的就是app加载页面的设计。

一个app加载页面，大致分为3类：

(一)启动加载页

启动加载是我们打开app的第一眼所看到界面。会给用户留下该产品的第一印象。
通常启动加载页设计有几种：

1、固定的加载页

Logo、slogan、产品主色、版本号、出品团队，这是初级启动页面的基本构成元素，设计者的目的就是最直接快速的向用户传达产品形象，这也是让用户最直接了解产品的手段之一。但也因为实现成本低，且样式固定简单，久而久之容易审美疲劳。于是加载页开始升级。

这里要提到让加载页不那么孤立、突兀的方法：

视觉的延续性

。例如weiconote的加载页背景和它的主界面背景一致，视觉上达到了和谐的过度。

动效的使用

。通过淡出或开门等转场效果，让加载页面和内容页完美的过渡。例如豆瓣电影和天猫客户端。

2、会变的加载页

当一尘不变的加载页开始寻求出路，结果会是什么？对，会变的加载页。但是任何变化总得有迹可循，让用户得以理解。目前有2种维度：

1.节假日定制加载页

在不同的节日，启动加载页都会围绕节日&产品进行设计。在突出产品形象的同时，传达节日信息，是情感化设计的一个范例。例如掌上百度symbian。

另外一个有趣的例子是有些应用的启动页面，在用户生日时埋下的彩蛋：这种都是转移用户注意力的手段，让用户不再沉浸在等待中，而是通过这段等待时间传达其他有效信息，让用户不再烦躁。

2.不同版本定制加载页

当app版本升级后，启动加载页也随之升级，可根据当前版本的主题、特性或新增功能，设计符合该版本的加载页面。也增强了用户对新版本、新功能的认知度。

(上左新浪微博夏日版\上右新浪微博新年版\下左zaker嵌入游戏动漫版块广告)

3.同主界面的启动页

用app的内容页作为启动页面的内容，从启动加载页到加载完成的首页，版式内容几乎看不出差别。这样的启动页，让用户提前进入主要界面，强化用户对主界面的印象。也不容易造成很大的视觉跳跃感。但也存在问题，长得像主界面的加载页会给用户造成可用的假象，但如果加载的时间过长，点击伪主页如果无响应，也许会让用户恼火。

(pull time)

4.使用动画的启动页

在游戏app中，这种方式较为常见，在loading的过程中，用户看到是一段动态的flash。有时也有可能配以相关的游戏音乐。例如游戏subway surf。这种方式虽然最有富媒体效果，但同时却也因为比较消耗资源。有时候因为加载负担太重，甚至会造成画面不流畅。因此需谨慎选择。

(二)内容加载页

目前较常见的内容加载页会用加载模态框去表示当前正在加载中，实在是不怎么美观，且加载前和加载后的页面关联性很弱。这种体验实在是很令人头痛和不悦。

(zaker)

那有没有内容加载的好体验？
几种优化手段：

1.增加加载页面间的关联性，避免使用模态框

例如line的通知加载。加载进程在加载的通知项上进行，这时候不妨碍用户浏览上下的内容。

2.加载时就显示加载后的页面样式，最大化保持视觉连贯性

这种手法也就是为了尽可能多的在加载过程中告知用户有效信息，“你稍后即将看到的页面会是什么样”“会有哪些内容”，让用户提前有个预期，也让用户有了等待的欲望。

(flipboard)

3.加载时，预填充内容

这里的内容有2种。可以是提前预设好的，例如next day里的头图，再没加载出来前都用一直可爱的兔子图替代。另一种是，显示上次浏览留下的内容，像最近更新后的path，加载时，用户可以查看上次加载成功的内容，而且很巧妙的把加载中的图片黑白虚化处理。

(三)下载、应用的加载页

另一个常见的加载是下载/应用时的加载页面。下载和应用的过程可以看做是一个连贯的过程。而不要想象成两个独立的模态框。
在cardmon这个应用中，下载和应用的过程就被包装成了一个连续而精致的过程。
设计者找到了card和下载之间的联系，运用云端向信封连续不断发送卡片的动效，再加上下载进度条，让原本枯燥无味的下载等待过程展现出了那么一丝生气。在下载完成之后，进度条顺理成章的过渡成安装过程。动画效果依旧围绕着之前的卡片logo进行。同样的安装进度条依旧可以提示用户剩余的时间。

这一包装手法的要点即是，找到产品与下载之间的某种关联，合理运用动效、进度条、连续的处理下载安装过程。
另一种，是weico主题下载的形式，将下载和安装看做独立的两个过程。下载和安装分离的使用场景通常是，用户也许希望浏览、下载多个主题，再确定使用哪个。因此，下载被处理成取代下载按钮的进度条会比较合适，而非模态框。因为这样的加载方式不影响用户再浏览其他内容，不会让下载模态中断用户原本的浏览行为。

以上就是app加载的几种形式和设计方法。看似不起眼的加载页面其实恰是整个app是否用心和精致的点睛之笔。这一点点的等待时间也许会改变整个用户体验。再次总结，以上倡导的几个原则：

1.合理利用启动页面，赋予等待时间更多的意义

2.避免使用模态打断用户

3.加载页面，为用户提供预期，和更多有意义的信息

4.注意保持视觉的连贯性

相关话题：移动设备的交互和设计源地址：http://mux.baidu.com/?p=3411

移动应用的十项设计原则及小提示

c7210 — 2012-11-19 15:13:44

移动设备与传统桌面设备虽然都被成为“计算设备”，但它们之间的差异是显而易见的：移动设备的屏幕要小很多，无线网络链接方面会有不稳定，电池续航能力较弱，等等。这份“弱点”清单可以列的很长，但如果你因此认为移动设备就是降级版的计算机，那同样是错误的看法。

实际上，从其他一些角度来观察，移动设备又是比桌面设备更加强大的。智能手机和平板电脑都是更加个人化的设备，它们会一直陪伴在你身边，让你随时随地都可以接入互联网获取所需的信息；它们身上还有传统设备所不具备的很酷的功能，包括GPS、数位罗盘、加速计等等。

所有这些差异都使得移动设备当中的应用程序在界面设计方面存在很多独到之处。我(英文原文作者)基于在自己的workshop中的工作经验，总结出了移动应用界面设计的十条原则及小提示，在这里与大家分享，希望能够帮助那些还不是非常熟悉这个领域的设计师们建立起一套有实践价值的设计思维框架。

1.设计观念

从传统设备转向移动领域，设计师们首先要做的是调整思维模式和设计观念。

专注：移动应用的本质目标是帮助人们以最高的效率完成特定的任务。少即是多，你要砍掉的产品功能通常会比你想象的多很多。
独特：从一开始就要理解你的应用与同类产品相比具有哪些独到之处，将其体现到产品的整体用户体验策略当中，并在交互及视觉设计流程当中着重突出这些卖点。
迷人：移动设备是相当个人化的工具，人们会在长久的使用过程中逐渐将感情融入到软硬件当中；应用程序同样要与用户在情感层面产生互动，通过各种友好的、有趣的、可信赖的设计与功能让用户觉得爱不释手。
体贴：不要将注意力过多集中在“开发”本身上，不要将自己的心智模型以及产品的业务逻辑作为设计的准绳。如果你确实希望自己的产品能够被更多用户所接受，那么必须学会站在他们的角度观察问题、制定设计决策。

不要用“多多益善”的观念打造移动应用

2.使用环境

说到移动设备的使用环境，人们通常会联想到专业商务人士在机场一手拖着行李箱一手摆弄智能手机的画面。不过这只是移动应用上下文环境的其中之一，我们需要考虑的使用情景可以归纳为3类：

打发无聊：其实很多用户会在家中窝在沙发里面使用移动设备。在这种情景下，人机会话时间更长，需求偏向于娱乐休闲，因此更加拟真的、令人愉悦的体验是必须的。
忙碌：前面说到的机场的画面算是比较典型了。这种情景下，应用必须能在用户一手持机的情况下帮助他们快速完成一些小任务目标；界面当中的文字及交互对象要够大够清晰，确保在不稳定的状况下依然可以辨识，便于操作。
异地：用户正在旅途中，或是处于相对陌生的环境里。这种情况下，不仅要考虑到前面一点当中提到的可读性易用性方面的问题，同时，网络链接、电量等方面的因素也是不能忽视的。针对这类情景设计的产品，要提供必要的离线功能支持，同时尽量精简那些会造成电量消耗的功能特性。

推荐阅读：iOS Wow体验 - 为应用的上下文环境而设计

3.通用的设计规范

不同类型的应用(实用型、效率型、沉浸型)有不同的设计与开发规则，但从整体角度上讲，为小尺寸触屏移动设备的应用进行设计的过程中，有一些全局性的规范需要我们注意：

响应性：如果用户执行了操作，应用必须立刻作出相应的反馈。响应性和速度不是一回事，也许有些功能的实现确实需要花上一段时间来完成，例如加在媒体文件，但你必须让用户知道该进程正在发生。(推荐阅读：为用户的成功操作提供正面反馈)
细节：我们在设计和开发过程中没有在意的细节之处很可能被用户轻而易举的注意到。优秀的细节设计非常有助于提升产品整体的体验满意度。想象一辆拥有强力引擎和靓丽外观的汽车，如果驾驶室没有经过认真打造，或是在路上一直发出讨厌的噪音，那么用户满意度显然会被大打折扣。
拇指：关于触屏操作，其实在多数情况下，我们只是在为拇指进行设计，除非你确定用户会同时使用两只手来操作设备。而且即使用户是在双手持机，通常也是使用两只拇指进行操作。所以，设计方案通常需要围绕着拇指进行考虑。
点击目标：看看自己拇指的手指肚，也就是用来触控界面的地方。我自己的看上去无论尺寸还是形状都像个瓶盖儿。即使长的再好看，对于移动设备界面当中那些微小的操作对象来说也显得大了些许。Apple在iOS界面设计规范中建议可触击元素的最小尺寸应该是44像素见方，不过在实际当中，不符合这条规范的案例也有很多，包括Apple自家的应用。另外，相邻元素之间的布局关系也是你需要留意的，例如，在创建内容类的应用中，将返回按钮直接搁在保存按钮旁边就不是个好主意。
内容：“直接操纵”是触屏设备交互模式的根基。用户可以直接与界面进行交互，而不需要鼠标一类的辅助设备(同时也是干扰因素)。这种模式的优点是不言而喻的，远的不说，我两岁的孩子可以轻松的使用iPad，但完全搞不定笔记本或台式机。对于运行在触屏设备当中的应用来说，更是要精简界面元素，使内容呈现方式与功能的操作方法尽可能的符合“直接操纵”框架下的直觉模式。
控制元素的布局：通常情况下，具有控制功能的界面元素需要被放置在内容的下方，这样我们在执行操作的时候才不会将内容遮挡住。想想看计算器、磅秤，或是眼前的计算机。虽然传统的桌面软件和Web页面都是将相关的导航和操作放在顶部的，但那只适用于鼠标操纵的情况，毕竟指针的尺寸相对于整个显示设备来说是微不足道的。
滚屏：多数时候，“折线以下”的忌讳同样存在于移动应用的界面设计当中。另外，对于某些应用来说，单屏模式可以带来更加坚实可靠的感觉，因为所有的内容都是可预知的。当然，在多数应用中，避免滚屏是不现实的，不过可以思考一下是否有什么方式可以减少滚屏带来的不确定感，让用户了解到那些还没有进入可视范围的内容的存在。

推荐阅读：又是为了触屏移动设备而设计

4.导航模式

新奇的导航模式越来越多了，在Path中你就能发现不止一个。不过如果你仍然决定采用那些用户所熟悉的原生标准导航模式，那么同样要确保你的选择是符合产品实际需求的。最常见的一些导航方式包括：

没有导航：单一界面的实用型应用(例如iOS自带的“天气”)。
Tab Bar：为应用提供的一种能够在全局层面上组织子任务、视图界面或功能模式的导航机制(例如iOS自带的“电话”)。
列表：用于在树形信息结构中进行浏览(例如iOS的“设置”)。

iOS的Tab Bar

iOS的列表导航

5.用户输入

在触屏设备中输入文字，这事儿几乎可以用痛苦二字来形容了，再棒的设备和应用也不例外。我们要做的是尽最大努力帮助用户降低负面感受。

智能手机的系统平台当中通常都会内置一些针对不同类型内容的键盘，例如文本、数字、Email、URL等。在你的应用中，确保针对不同的内容类型使用对应的键盘，提升用户输入的效率。
输入法自带的自动纠错功能有时真的蛮闹心的。可以为你的应用预先做好这方面的设置，例如打开或关闭掉某些字段的自动纠错(auto-correct)、自动首字母大写(auto-capitalisation)或是自动完成(auto-complete)。
如果你的应用确实需要用户输入很多文字，那么可以考虑为应用增加横屏模式，让用户通过更宽一些的键盘进行输入。

6.手势

电容触屏移动设备的一个标志性特色就是手势操作。

无形：手势是无形的，所以怎样进行合理的引导，让用户了解应用支持的手势操作，同时又不会很明显的破坏界面协调性，这就变的有点儿挑战了。
多点触控：要进行多点触控，正常人类通常需要两只手来配合操作。例如“双指张开”，要么是双手持机通过两个拇指完成，要么是单手持机同时用另一只手的两根手指来操作。有些时候这样其实蛮闹心的，例如当我走在路上一手拿着咖啡一手拿着手机时，如果应用当中的某些功能必须要我使用双指张开的手势来完成，我会觉得很难过(这也正是我个人觉得Clear好看不好用的原因 - 译者C7210)。
锦上添花：我个人始终认为手势操作，特别是各种炫酷的多点触控操作更像是一种锦上添花提升体验的辅助交互方式，即使用户不知道它们的存在，也应该可以正常的使用应用。

深入阅读：

7.屏幕定向

目前来看默认的也是最主流的屏幕定向方式仍是竖屏。
正如前面提到的，如果你的应用需要用户输入很多文字，那么最好考虑支持横屏视图模式，让人们能使用更宽一些的键盘。
对于内容阅读类的应用，也可以考虑在应用内增加独立的锁屏设置。

深入阅读：横竖屏切换中的界面设计与体验提升

8.交流

提供反馈：为用户的每一个交互行为提供即刻的反馈，否则用户会疑虑程序是否发生了什么问题，或是错误的认为自己并没有完成自己想要进行的操作行为。反馈的形式可以是触觉上的，例如震动，当然多数情况是视觉上的，譬如为交互对象增加高亮效果或是使用动画过渡效果。如果某个操作从执行到产生结果需要花上一段时间，一定要提供等待标示或进度条一类的视觉元素，让用户知道系统正在进行必要的处理工作。
模态对话：主要指Alert警告框，这是一种非常不友好的、会中断当前任务流程的对话方式，所以你应该仅在发生了重要问题或有可能导致严重后果的地方使用它来提醒用户。即使必须用到它，也要尽量保持文案的友好。
确认：当你希望用户对是否要执行某种操作进行确认时，动作表单(Action Sheet)会更加合理一些。相比于警告框，动作表单更像是在上下文当中对用户行为的响应，而不是唐突出现不明状况的东西。

9.启动加载

不能假设用户会连贯的使用应用直到完成目标。在某些情景中，用户很可能会暂时退出应用；当他们再次回来时，最好确保当前的状态和他们离开时完全一致，包括输入的内容及执行过的操作和设置等。

对于某些类型的应用，可以在加载时使用和首屏界面完全一致的“空界面”图片作为启动图像，这样做可以降低用户对等待时间的感知，让他们觉得应用从启动到加载完成只需花费很少的时间。不过需要注意的是，不要在这个“空界面”图片中放置任何交互元素。

twitter的iPhone应用加载界面

另外，尽量不要在启动图像中使用太多品牌信息方面的内容，因为这种方式很有可能让用户觉得他们正在看广告。

10.第一印象

应用图标：你的应用图标要在各种同类产品的图标海洋里进行战斗。本质上讲，它更像是名片而不是艺术品。要尽量在图标中表达出你的产品的主要功能和卖点，准确的体现出产品类型和定位。
首次启动：首次启动的表现往往可以决定一款应用的成功或失败。如果一位新用户在这个环节感到迷惑和受挫，他们会很快的放弃这款产品。如果你的应用提供了复杂的功能，那么可以考虑增加一些提示引导，帮助用户在最短的时间内对产品产生准确的理解。不过要注意的是，这些引导提示绝不能代替设计方案自身的自我描述性，如果你发现自己正越来越多的想着那些引导说明而减少了对界面设计方案的钻研，那么该反省反省了。(推荐阅读：具有引导性的移动应用界面设计模式)

译文代表原作者观点。欢迎发表评论，或到译者微博进一步交流探讨。

相关话题：移动设备的交互和设计源地址：http://beforweb.com/node/132

移动平台的产品设计世界

嘉飞 — 2012-08-02 11:06:44

随着智能手机的产生，人们对它们的使用时间与粘性迅速加大，移动互联网的发展越来越迅猛，越来越多的PC端产品开始把注意力集中在转移到方寸之间的屏幕之上时，有如潮水般汹涌。

当下的移动互联网产业，已经从单纯的以实现单一功能为主，到平台的转移，再到各个APP之间的产业链的形成，还有广告植入的各种运营手段产生各种盈利。充分说明了移动互联网的前景堪好。

如何设计出一个好的APP，是我们今天需要介绍的主题。

所谓移动平台，是指除了不方便搬动的PC机，所有方便移动和携带的电子设备。不仅仅是我们流行在使用的智能手机和各种pad，也同时包含了车载应用和各种家庭生活电子产品。

移动平台的特点：

1. 时间碎片化：

移动设备的方便携带，也同时带来了它浏览时间的碎片化。以智能手机为例：我们通常在短暂的时间里，完成一件任务或者是进行一个娱乐事件，比如：散步、坐公交、睡前、午后闲暇、旅行的时候，开始拍照、分享、做笔记、玩游戏、购物，等等。在平均短短5-30分钟的时间里，思路常常被打断，手机常常被拿起放下，高效和轻交互，就成为了移动设计的特点。

2. 手势的应用：

移动触屏的产生，同时也带来了各种手势的配搭。这些手势的应用，相比于键盘、鼠标，能更加快速做出响应，并且降低学习成本，更加直观地进行人机交流。但触摸相比鼠标，却无法达到高度的精准，也无法出现像网页中的鼠标hover、悬停等的效果。东西方人的指尖触碰面积略有不同，但通常，它们合适的点击区域是在44-44px的范围里。

3. 屏幕的限制：

我们说移动平台的设计，其实就像是带着枷锁跳舞，这个枷锁不仅是来自各个平台系统的控件规范，还有最大的问题就是屏幕空间的有限，加之前面说过的44-44px的点击区域，更是需要我们的APP设计，在单个界面的展示，简洁再扼要，交互轻量再轻量，层级浅显再浅显。

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

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

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

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

实例1：flickr

图片分享是flickr的精神宗旨，在客户端中，只展现了转发，拍照，赞，评论，前后浏览几个最能体现产品的功能。而其他类似“感兴趣的”“小组”和各种应用，在这里就不再做实现。

4. 限制输入：

我们在使用智能手机和其他移动设备的时候，必须在环境不稳定，并且碎片时间里快速地完成任务，而不像在PC电脑前，沉溺专注地做一件事，而敲击键盘输入文字，却需要花费一定的时间精力，在不得已的情况下，用户并不喜欢在手机上长时间的敲击虚拟键盘，（各位一定有经常按错键的时候吧）所以许多优秀的app就会用其他的功能代替键盘，比如微信的语音功能。

如上是一款手机花费充值的app，在选择金额上，它通过用户利用滑动区域值，很好地解决了输入数字的问题.

5. 流量与费用的考虑：

移动用户通常包流量来实现上网的乐趣，所以我们在设计app的时候应该同时考虑到流量与耗电的节约，尤其是合理的图片展示对流量的影响。

比如weico+的应用，最新版节省了60%的耗电量，无疑是一大卖点。

还有新浪weibo的客户端，对于图片的展示，分成feeds小图、点击出中图、再点击加载详细大图，满足了各种用户浏览图片的需要，通过需求细分来达到了节约流量的目的。

设计要求：

现在我们要开始着手开始设计一个app，说到实际操刀，该从何入手呢？

首先你要了解自己的产品属性，它是一个全新的未有任何PC基础的app，还是移植性的app？

1. 全新的app设计：

每一个app都有它的精神宗旨。我们在这里给它一个定义叫做：产品定义描述（Application Definition Statement简称ADS），融会贯通，这个概念不仅体现在app的设计上，同时也体现在广告策略案等不同工作领域的形成引导。

合理地给你的产品定义非常重要。首先你要想好，你的产品大致是属于那种类型的app。

目前市面上的app大致分为3类：

实用工具型（Utility）：比如天气预报、录音、计算器、股票查询等应用。

生产效率型（Productivity）：这类应用主要是解决用户在极短并且不稳定的情况下高效地完成工作任务，比如印象笔记，mindmeister

沉浸型（Immersive）：这类应用多数为游戏类，它能让用户长时间地沉浸在应用上。比如angry-birds

在明确了想要的app的类型之后，

举例：比如今天我们想着手做一款生产效率性的应用，它能帮助用户随时随地记录旅行中的感想与记录，并且实现不同平台之间的同步。我们暂时起名叫traveller’s book

接下来要如何应用的程序定义呢？你可以尝试：

a. 列举所有你觉得用户会喜欢的功能点：

你可以像头脑风暴一样去尽量罗列你能想到的任务与创意，不要害怕嫌多，最后它们还会经过一场严苛的精简。以traveller’s book为例，脑袋中的感兴趣的任务可能是：

记录行程

订购机票

Chack随身物品

随心拍摄+分享

查找攻略

显示经历的足迹

标注所在地理位置

记录美食

……

b. 确定你的目标用户：

你的用户除了在使用移动设备，期待精致的图片，简洁的交互方式，出色的表现以外，还具备什么样的特性呢？以traveller’s book为例，你可以判断下列描述是否适合你的用户：

喜欢旅游

热爱购物或享受生活感动

善于分享

希望有经历与人生痕迹

写攻略

背包客

驴友

旅行时间3-5天的度假

旅行时间15天以上的旅行

……

考虑完这些问题，挑选三条最符合你目标用户的特性：喜欢分享与写感想，查找路线与攻略，方便订票（机票车票与门票）。

c. 通过对目标用户的定义筛选功能点：

如果在确定了目标用户的特性后，功能点只剩下寥寥数条，你就得到了它：伟大的程序应该像激光一样准确聚焦在用户想完成的任务上。

比如说，想想在第一步里你为旅行程序列数的大量潜在功能点。虽然这些功能点都很有用，但并不意味着每个功能点对用户同样有用。最重要的是，第二步中的目标用户对这些功能点的喜爱程度也不一样。

心里装着目标用户，再来检视功能点清单，最后能将程序聚焦在三个功能点上：拍照分享写记录，订各种形成票，获取位置查找攻略。

现在可以定义你的程序了，精确地概括程序的功能以及目标用户。好的定义应该是这样的：

“一个解决旅途攻略，记录点滴并线上购票的工具”

d. 为设备而设计：

我们知道不同的设备有不同的系统，不同的系统有不同的原生交互与UI控件，良好合理地利用，能紧密地高度地节约开发成本，并且达到用户体验一致，让他们感觉iphone的app的操作习惯就是应该按照iphone自身原有的惯性的。

2. 从网页移植产品：

更多时候当我们拥有一个成熟的网页产品的时候，我们会需要抢占用户在碎片里的时间，方便他们解决问题。这时候你需要重新考虑给予web的设计。

首先你要关注你的程序，提取重要功能，时时想着ADS，确保你不会因为过多的功能或提取错了重要功能而使应用发生了方向性的变化。
确保你的应用app，能帮助用户做事，更高效直接地完成任务，不论是游戏任务还是工作任务。
结合移动设备的特点，多考虑合适的交互：

合理轻松的触摸手势。

当内容展示不下的时候，可以考虑让用户翻页，因为在客户端，翻页是一件很轻松完成的动作。

重置主页图标，也许在web端，两个功能的按钮可能相隔很远，但在移动平台中，你需要重新考虑它们的位置产生的关系。

我们可以看到在“印象笔记”的实例中，toolbar上始终展现着贯穿整个应用的功能：添加事件、查看历史笔记、标签、同步、以及当你笔记过多时候的快速搜索。层级关系从三级列表层，变成了单层（如过toolbar也算层的话那就是两层）。砍掉了不那么重要的功能比如：事件分类、时间提醒、项目合作、还有分享给朋友等。

为不同的平台而设计

最后还不要忘记适应不同的设备平台。比如返回按钮，在ios和andriod上的界面都有出现，因为ios没有物理返回键，而andriod的设备平台虽然有物理返回键，但是当我们在进行一个任务的时候从屏幕把手指移动到物理键上就不是那么顺畅了。而在PLUM的设备中，应用有时候会把返回键去掉（PLUM的返回操作是物理键向左滑动），是因为PLUM的用户忠实度和习惯养成性非常高，第一反应就是使用物理键，所以这个时候在界面上的返回按钮就显得鸡肋了。

总而言之，我们必须在最短的时间里，展示出一个应用最主要的精神和功能。这样才能设计出你心中预期又理想的程序。

移动应用丰富动效的六点原则

elya妞 — 2012-05-08 12:21:43

如果想让你的移动应用更活泼更灵动，丰富的动效是不可少的，丰富的动效可以让你的应用更具活力，充满生机；丰富的动效可以让你的应用彰显效率，提升品质感；丰富的动效可以让你的应用充满魅力，引人探索；丰富的动效可以让你的应用减少焦虑，消除等待感；丰富的动效可以让你的应用充满韵味，有节奏感；丰富的动效可以让你的应用有出奇的信息组织，整洁高效。

这里主要介绍六种简单通用的方式——转场、邀请、过渡、反馈、缩放、吸附。

原则一：转场

由于手机屏幕空间有限，更多的内容会被隐藏在屏幕后边，或者屏幕的左边、右边、下边，转场动效能帮助应用营造一种空间方位感。转场动效是目前应用最多的动效种类，毕竟iPhone、Andoird、Wp7都有提供一些官方的动效的API，一些简单的动效可以直接调用官方API来完成。Android官方动效8个，iPhone官方动效19个，WP7官方动效6个，具体几个平台的动效有哪些差异，后续有机会分享。

原则二：邀请

直接提供邀请，告知用户可以做的事，效果最直观，引导性最好。但是要注意操作邀请一定是需要突出的主要功能或任务，不能什么功能都邀请用户试用一下，要知道，大部分用户只用到你应用里的20%就算不错了。邀请不能过于强制，如非必要，中断用户正在执行的操作是很不礼貌的行为。

原则三：过渡

当应用正在加载数据的时候，一定要给予过渡，让用户知道应用正在努力工作，系统级的过渡分为两种——进度条和菊花转，进度条是用在可预知完成进度和剩余时间的情况下；菊花转是用在无法预知剩余时间的情况下。iPhone上照片转发邮件、邮件从收件箱移动到垃圾邮件都有很好的过渡动效，让用户知道当前从一个应用跳转到另外一个应用，知道从一个文件夹跳转到另外一个文件夹，避免了迷路的麻烦。

不是所有情况下，都要清晰的告知用户当然任务的加载进度的，比如iPhone自带的短信应用，发送短信的时候有一个进度条，本意是好的，让用户知道短信发送的进度。但是由于进度条会给人造成一种明显的等待感，而且用户担心离开当前界面，短信就会发送失败（用户怎么知道同步和异步？），所以只能傻等在那里。其实完全可以让短信后台发送，只要保证发送失败有办法告知用户就可以。同理，那些图片分享应用也是如此，后台上传就可以了。

原则四：反馈

当任务成功或失败之后，需要有办法告知用户。比如Reeder客户端，就会在你点了Unread后，立刻弹层告诉你已标为Unread，在你点了Statted后，立刻弹层告诉你，已经Starred。反馈需要在合适的时间引起用户的注意，简洁明了的传达操作的结果，

如果是成功类的提醒，往往只是告知状态就可以了，用户无需执行操作，反馈就可以自己消失。而如果是失败类的反馈，则需要引起关注，可以相对强势一些，反馈出现的位置可以考虑相关性，比如帐号错误可以出现在帐号旁边，密码错误可以出现在密码旁边，采用相对警示的颜色和设计风格。

原则五：缩放

在一寸土一寸金的手机界面上耕耘，恨不得盖个复式小洋楼，一行当两行用。其实不是不可以，只需要一个设计思想——盒子主义。每一个功能模块都是一个盒子，在你不需要用到的时候，它只是一个盒子，上面贴着标签，你知道里面装的是袜子，当你需要的时候，你就可以打开盒子，露出里面很多很多双袜子。

比如Bluga这个输入框，当你不需要输入的时候，它看起来就是一个输入的入口，但是当你点击的时候，输入的辅助信息都出来了，更大的文字撰写框、位置、图片、发送按钮，你可以打开盒子，编辑一条丰富的消息。

原则六：吸附

吸附是网格系统中一个很具有美学色彩的设计，当你拖拽着一个应用切换位置的时候，这个应用会被自动吸附到对齐网格的位置，保证界面整洁利索（不像Nokia的某些手机，Widget可以满屏幕拖拽，跟我凌乱的桌面一样）；当你拖拽一个应用到另外一个应用上的时候，就可以变成一个文件夹，这里也是通过文件夹的样式和吸附的效果，让用户明白建立文件夹的交互的。

任何的动效，都需要经过场景和需求的思考，在什么样的特殊情景下，解决了什么样的问题，不要为了动而动，WP7的动效，恐怕看久了都会腻吧。

除了界面本身的动效之外，还需要包含震动、声音、手势等等因素一起去考虑，好的动效，配合着合适的音效、合理的手势，才是最自然的交互方式。

从今天开始，努力提升你的应用的品质，让它动起来吧！

相关话题：移动设备的交互和设计源地址：http://elya.cc/2012/05/06/1234/

产品的肢体语言–交互动画

Gucs3 — 2012-04-15 14:36:54

随着体验经济时代的到来，人们对产品界面的期待值也越来越高，交互动画在手机领域的应用已经非常普遍，例如Iphone充分发挥了动画在交互易用性方面的优势。而交互动画会给用户带来一种舒适、自然和流畅的感觉。交互动画逐渐成为了产品与用户之间的沟通方式，成为产品的肢体语言。尤其是目前高端机的性能提升迅速，也为交互动画的执行效率提供了有效的硬件保证。

Google地图的让工具化与拟物化结合，不论是翻起页面的效果，还是图钉的效果，都是还原真实场景中的操作，通过动画的表现，让其更加逼真。也使界面更加的有层次。
在产品设计过程中，合理运用交互动画让产品与用户更好的互动，让产品变的更具情感，合理的动画运用可以：

提高用户操作流畅性
随着移动终端设备硬件以及软件的不断强大，带给用户的选择也会越来越丰富，用户在使用产品功能的同时，也追求完美的操作，与产品产生良好的互动。
目前app以及wap站的视觉效果绚丽完美的同时，同时带有很多的复杂视觉元素，处理好每个视觉元素的关系，以及有效的传达用户操作后元素之间的关系变化，就需要设计交互动画，阐述其变化的逻辑与过程，让操作更合理，更流畅。

提高用户兴趣，降低学习成本
通过巧妙的交互动画让用户理解产品功能，进而让用户产生良好的心理感受。让用户更容易了解功能，更好的方便的使用产品。有时详细功能的讲解，往往不如一个简单的交互动画效果更具吸引力。目前在游戏中广泛应用。

强化品牌一致性
弹出层，界面滑动，分屏，返回，前进等等，这些交互动画无不流露出品牌的特性与情感
一个标志性的动画效果，往往也会是一个产品的代言。

交互动画设计法则

传达有价值的信息
在用户完成行为之前把结果展示给他们，使他们能更确定自己的行为，避免出错。帮助用户预见自己的行为将造成的结果。
在iphone的屏幕上移动应用图标时，当你把一个图标拖动到一个位置时，旁边的图标会向后或向两侧移动告诉你当你松开手时这个图标将要停放的位置。
以下是总结的交互动画的一些设计原则：

阐述清晰，精确引导
动画是可以清晰阐述产品功能间的切换过程的。当用户进入一个不同的交互模式时，比如两个应用程序之间的切换，动画可以提供一个指引，告诉用户已进入另一个场景。
当我们最大化窗口的时候，这个窗口不是简单的直接放大，而是平滑地向四周展开。这样我们就可以清晰地知道这个窗口被放大了。

动画时长巧妙掌控
在设计动画时，注意动画执行的时间，并且在一些较高频率操作的功能中的动画，是要可以通过操作（点击两次此操作，或是其他操作，点击空白处或是目标区域等等）跳过的。

执行效率需多考虑
目前交互动画在高端机方面应用越来越多，但是各个机型的配置不尽相同，在考虑动画时，需注意各个机型的执行效率，如果覆盖面较广的产品，需要设定一个合理的可支持最低配置以及搭建测试环境，以便确保动画在执行时不会给机器带来过大的压力。

尊重现实规律，或让用户具有“超能力”
就是要符合逻辑规律与自然规律。比如动画中如有位移，应与指向目标位置方向移动；拟物化的设计，就需要真实的动画去模拟还原真实的过程。有时也可以在真实的场景中，让用户完成真实场景中人类不能完成的事情同样也会跟用户满足感。

点到为止，过犹不及
动画的使用犹如双刃剑，顺其势可披荆斩棘，塑造更完美的产品，如使用不当或是滥用，则往往适得其反。

使用频率较高的功能，慎用交互动画
如果是用户使用率非常高的功能，交互动画时一定要慎重。动画执行次数过多也会让用户反感，并延长操作时间。

用户输入，请勿打扰
用户在专注于内容的创建或是填写信息时，动画会分散用户的注意力，甚至让用户产生坏心情。但是信息提交，信息发送等操作，设计巧妙的动画，往往会增加用户的成就感。

尊重用户习惯，“标新立异”不可取
我们要避免触及系统的标准行为，尽量尊重用户习惯。在iPhone中，动画式响应方式是标准的界面风格，比如窗口内容的上下卷滚、元素的出现和消失，以及内容的放大、缩小等等。
用户清楚这些常见的界面元素是如何工作的，他们不愿在每次点击按钮的时候，被迫花费多余的时间去看一些不必要的动画。

相关话题：移动设备的交互和设计源地址：http://mux.baidu.com/?p=2185

触屏手机点击区域的小秘密

elya妞 — 2012-03-07 17:38:37

做触屏手机产品设计，要注意所有的可点击元素都有足够的点击区域，但是这并不是说你要把所有的按钮图标链接都设计的足够大，手机上的视觉焦点和操作焦点是不一样的，操作焦点是可被放大或移动的点击区域。

这里分享几个点击区域的小秘密，帮你解决操作准确率的问题。

一、扩大操作焦点

iPhone自带的控件NavigationBar上的Button、TabBar上的Item、ToolBar上的ButtonItem，实际的点触区域都是被放大了的。

虽然iPhone导航栏上的操作按钮仅有29px高，但是它的实际点触区域比整个导航栏的高度还要高出5px左右，大概能达到44px+5px，这样用户就不用小心翼翼的去点击返回按钮了，按钮点起来比看起来要大的多。

如果导航栏下边区域还有按钮，或者输入区域，点击下边的按钮经常会触发导航栏上的按钮，这点很多开发人员都可能遭遇过，我看到Cocochina上就有不少类似问题，比如wyx遇到的问题，比如dave遇到的问题。

类似的，新浪微博的撰写微博界面也是个列子，当用户想编辑第一行的文字的时候，点击文字经常会误触顶部操作栏的取消或发送。随享微博客户端也是，顶部导航栏下边有一排操作图标，还是比较容易引发误操作的。

底部标签栏的可点击区域也比视觉焦点要多出5个像素左右，标签切换是比较常见的操作，这样一个小改动帮用户提升了标签切换的准确率。

但是正因为iPhone标准的TabBar的点击区域是有扩张的，所以如果你在TabBar上方放置可操作区域，都比较难以点击，Foursquare和USA today等应用最后都是采用自定义TabBar的方式规避问题的。

关于和设置往往被做成半透明图标，浮动在界面上，如果操作焦点=视觉焦点，那么用户就只能杯具的削尖指头去点了，还好这两个按钮的实际操作焦点要比视觉焦点大的多，保证了足够准确的点击。

Android4.0规定的有效可触摸的UI元素标准是48dp，一般来说，48dp转化为一个物理尺寸，约为9毫米。建议的目标大小为7~10毫米，这一点与iPhone一致，这是一个用户手指能准确并且舒适触摸的区域。
如果所示，你的UI元素可能小于48dp，图标仅有32dp，按钮仅有40dp，但是他们的实际可操作焦点都达到了48dp的大小。

二、下移操作焦点

由于用户在进行各种操作的时候，需要确保自己准确的点击到了相应的元素，所以一般情况下，右手持机的用户，落点会偏右偏下，见下图：

我们的UER把手机屏幕分成6*12个可点击的焦点，从用户的点击落点监测可以看到，右手持机的用户有很大一部分点击落点和视觉焦点是有很大偏差的，偏差具有一定的规律性。屏幕右下方格外明显。

如果你的应用是操作密集型，可以考虑调整有效点击区域，整体往右往下偏移几像素，准确率会有所提升。

##此部分内容希望有过类似研究的同学可以共同探讨##

三、留白以规避误点击

当然，仍然有很多情况，我们是无法用放大操作焦点或偏移操作焦点的方式来解决的，那就是当两个可操作元素确实离得比较近的时候。这时候，iPhone内置的应用会巧妙的采用留白排版方式以规避误点击。

比如iPhone系统的输入框，如果框右边有发送按钮的话，我们可以发现右侧是有个明显的留白的，由于中英文字体差异，中文的留白略大于英文。这个留白，一方面是为了规避跟发送按钮焦点太近的误操作问题，一方面是为了给滚动条留足够的空间。

而带有全部删除按钮的输入框，文字离全部删除按钮也会有适当留白，规避切换光标时可能引发的误操作。

当遇到焦点密集的问题的时候，我们都是可以利用增加行间距、元素间距和留白的方式来解决可点击区域问题。

最后再啰嗦一句小图标元素大点击区域的实现方式，方法1：UI提供带透明点击区域的图标，就是一张透明的图，上面一个小图标；方法2：UI提供一个大点的透明的图，覆盖到图标上面，点到上面就执行操作；方法3：程序人员自己去实现，方法请问他们，嘿嘿。

又是为了触屏移动设备而设计

C7210 — 2012-02-24 16:31:33

印象当中，最近这些年的春天总是会带来让人觉得真心别扭的气候体验，雨和冷风就像催化剂一样，让生活和工作当中的人和事也变得异常凌乱，仿佛一团被咀嚼到完全失去味道的槟榔。November Rain前奏当中的钢琴旋律多少可以让心安然一些，一旦摘下耳机便又是个令人想要把自己的脑袋拧下来吃掉的世界。

可脑袋一旦被拧下来，就什么也无法吃的样子了，不是吗。说正事儿吧。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中的同类界面，它们都在底部导航工具栏的上方放置了一些控制按键。如果以我们在前文当中提到的一些原则标准来衡量的话，这种做法其实不算得当；但是在这几个具体的情景当中，这些控制按键的大尺寸特质却可以有效的降低它们与底部导航工具栏之间的视觉冲突。

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

相关话题：移动设备的交互和设计源地址：http://beforweb.com/node/49

手机产品设计中的反馈提示

limengran — 2012-02-10 23:22:12

在产品的设计中，“反馈”是很重要的一个交互特征，它是一种界面输出物，用以给用户正确的引导信息，帮助用户判断和决策。而反馈的形式也是多方面的，视觉、听觉、嗅觉、触觉、正面的、负面的，都是在为用户传递信息。而没有反馈或反馈很差的交互，只会让用户产生失效和无助的负面体验。

在煤气中加入硫和笨，为的是通过臭味提供危险信号的反馈。地铁里的门在关闭前会发出滴滴的报警声，是用来告知乘客车门将要关闭的信息。这都是生活中无处不在的反馈。

今天要和大家讨论的是在手机产品中，用户在信息交互过程中所得到的反馈形式。

1.反馈的必要性

在用户与产品进行交互的过程中, 产品对于用户的每一次行为都要有清晰的、及时的提示和反馈，从而使用户获得操作行为结果的信息。

如果产品不提供任何信息反馈, 那么用户就无法确定自己操作行为的的结果，反馈机制是产品设计中不可或缺的基本元素，它是用户前进道路的指向标。

2.反馈的形式

反馈的形式是多种多样的，在不同的场景不同操作中要选择适合的反馈类型。而在手机产品中更要考虑操作区太小被手指遮挡住的情况，反馈一定要明显，并呈现在可视范围内。下面尝试对手机产品中的反馈形式做一些总结。

2.1 气球状通知

气球状通知是一个小型的弹出窗口，用于通知用户出现非关键性问题或控件处于某种特殊情况。

上图中的信息提示是用来解释指向菜单的功能，即该菜单项是做什么的，属于说明类的反馈提示，说明文字应简洁、实用，避免提供用户显而易见的信息，需要设定合理的显示时间。

上图的气球状通知是当选中某一项功能（或方式）时，界面显示该功能对应的简要说明，用来告知用户选中此项功能将要执行的操作是什么，此类反馈通知一般触发后显示3秒钟就自动消失了。此类的反馈通常不会太重要，因为很容易被用户忽略。

2.2 对话框

对话框是最常见的反馈和提示形式，它存在的价值在于要引起用户的高度重视。

上图中的反馈提示是当用户触发某一项操作且需要用户进行再次确定及选择时显示的对话框，此类反馈的方式一般用在较为重要的提示信息上，需要用户进一步操作。操作按钮要尽量突出，确定不会出现死循环和重复操作，提示文字要简练易懂，以减少对文字的阅读压力。

上图的反馈属于过渡类的反馈提示，是通知用户当前界面所处的一种特殊状态，告知用户可以做什么及产品正在做什么。

2.3 按钮/图标/链接的按下状态

按钮/图标/链接的按下、选中的反馈效果，在手机产品中一样不能缺少。

上图的例子中当用户按下按钮或图标时，该按钮背景会增加一个按下的指纹，图标背景会变成高光，这种实时的反馈让用户即时直观地看到操作被响应了。

2.4 声音

声音同样能为用户提供有用的听觉反馈，但是它不应是唯一的或主要的反馈方式。因为用户的使用场景可能会迫使他们关掉声音。尤其手机的使用环境复杂多样，在地铁、商场等嘈杂的环境，声音的反馈就很容易被忽略。同时，过多的声音反馈也会造成听觉上的噪音，所以声音的反馈不应是主要的反馈方式，并要允许用户关掉声音。
比如iPhone发送短信发送成功后的提示音，按下手机键盘上的按键时的提示音，新浪微博的信息拉取成功后的提示音，后台推送消息的提示音等等，都巧妙的运用了声音反馈。

2.5 振动

振动为触觉反馈的一种表现形式，让用户通过触觉来感知产品的反馈及回应。

当我们将手机由声音调到振动时，声音的反馈提示就变成了振动提示。比如当有电话打进来时、接收到新消息时、接通电源充电时的反馈提示都变成了振动。
而有些产品中也可以设置新消息振动提示，打开此开关后，有新消息送达时的提示也就变成了振动提示。

2.6 动画

顺滑的动画会给用户提供有意义的反馈，帮助用户直观地了解到操作的结果。

上图的例子都是通过一个显著的动画过程让用户知道操作是如何执行的，把衣服丢进购物车，把照片扔进垃圾箱等等，这些形象的拟物化的动画能够帮助用户清晰地感知到整个操作执行的全过程。

上图中的例子适用在那些会持续很多秒的长流程里，将等待过程采用动画的进度形式显示，展示已完成的进度，并在可能的时候提供解释信息，以减少用户的焦虑。

2.7 灯光

灯光的提示，在一些特殊环境中有特殊的应用，比如在黑暗的地方或者是用户视线不在手机屏幕上时，灯光的反馈提示就以它独特的闪烁方式引起用户的注意。
手机指示灯大多是用在提示电量不足，即当手机快没电的时候，指示灯会按照一定的频率闪烁红光。还有充电的时候，红色指示灯常亮，充满电之后变成绿色。
还有一些手机的灯光应用在提醒功能里，比如有新消息、未接来电的时候，屏幕会自动亮起提示用户。

3.反馈的内容

3.1 信息

反馈提示的信息应简洁、实用。避免不带格式的大段文本，避免提供用户显而易见的信息或只是重复屏幕上的文字。

上图中的例子可以看到用户完成操作后给出的清晰的提示信息，告知用户操作的结果。

3.2 警告

警告框用于向用户展示对使用程序有重要影响的信息。
警告框浮现在程序中央，覆盖在主程序之上。警告框的外观强调了这样一个事实，它的到来是由于程序或设备的状态发生了重要变动，并不一定是由用户最近的操作导致。

上图中的警告是告知用户当前产品的状态，需要用户引起重视。警告框通常至少有一个按钮，用户点击后即可关闭窗口。警告框上也总会有标题，并展示额外的辅助信息。

3.3 错误

错误是提示用户操作出现了问题或异常，无法继续执行。

上图中的例子为输入的信息有误，界面给出了相应的错误提示，告知用户为什么操作被中断，以及出现了什么错误。错误信息要尽量准确、通俗易懂，有效的错误提示信息要解释发生的原因，并提供解决方案以使用户能够进行修复。

3.4 确认

确认是用于询问用户是否要继续某个操作，让用户进一步对所作的操作进行确定和执行，为用户提供可反悔的可撤销的退路。

上图中的例子是让用户对一些执行结果较危险或不可逆的操作进行二次选择和确认，用户防止用户误操作。

4.反馈的位置

4.1 状态栏

反馈的提示信息在状态栏，因为手机屏幕较小，可利用的空间有限，而放在状态栏则是一种很好的空间利用，但此位置不是很明显，建议只显示重要程度不高的信息提示，如好友消息提示，操作结果提示等次要信息。

4.2 导航栏

反馈的提示信息在导航栏，此类提示一般为连接状态的展示，临时将导航栏的内容代替为连接状态，表示当前产品正在努力连接网络拉取数据中。此位置适合显示临时的较重要的提示类信息。

4.3 内容区上方

反馈提示在内容区上方，导航栏下方，通常为拉取新内容，加载新信息的一种快捷方式，默认的提示信息是隐藏的，向下拉界面时才显示对应的提示信息，以引导用户进行操作。此位置的提示需要和内容进行紧密的关联结合。

4.4 屏幕中心

反馈信息在屏幕中心，通常为整体性的较重要的信息提示，需要引起用户重视的、系统的提示均可以显示在此位置。

4.5 菜单栏上方

反馈提示在菜单栏上方，此位置基本没有限制，可根据需要灵活使用，可以是产品的整体信息的提示，也可以是界面底部相关内容的提示。

4.6 菜单栏

反馈信息在菜单栏上，在此位置的显示提示信息的产品较少，因为通常菜单栏都会被菜单占满，不会有位置显示提示信息，可在一些菜单项较少的产品中进行应用。

4.7 跟随手势随机出现

反馈提示位置随机出现，根据手势或操作的位置临近出现，要注意尽量避免提示文字被遮挡。

5.反馈的时间

参考网页中的响应时间规律，一般而言，在0.1秒内显示反馈结果用户是可以接受的。1秒是用户保持不间断的思维流的限定时间，如果是超过了0.1秒而少于1秒内没有特别的信息反馈时，用户是会产生疑惑的。
对于长时间的延迟，用户会想在等待完成期间去处理其他事务。所以需要显示将要完成的时间（通常选择进度条或百分比来表示），不然会大大降低用户的期待值。

6.反馈的设计原则

为用户交互行为的各个阶段提供积极、即时的反馈予以响应。
要避免过度的反馈，以免给用户带来不必要的干扰。
能够及时看到效果，操作简单的成功型提示不需要反馈。
对提供的反馈要允许用户以最方便快捷的方式完成选择。
将状态分类（对/错/提/警等）并进行差异化设计。
不打断用户的意识流，给出的反馈提示要避免遮挡用户可能会去查看或者操作的对象。

7.总结

反馈需要引起用户注意，快速明确地传递操作的结果，不让用户产生迷惑，尤其在手机的操作中，产品需要即时响应用户的手势动作，手势操作虽快速轻便，但没有鼠标按下时嗒嗒声的安全感，也十分受限于设备屏幕的灵敏度，所以即时的、有效的操作反馈是非常重要的。
总结划分的如有不当，还请大家一起来斧正。

相关话题：移动设备的交互和设计源地址：http://mux.baidu.com/?p=2182

生活中的交互之小户型设计

S++ — 2011-12-07 23:49:19

在房价高涨的今天，对于年轻的家庭以及单身一族来说，通常会选择小户型作为过渡。小户型设计却仍然要求“麻雀虽小，五脏俱全”，小面积与增加功能的矛盾日益加深。与小户型设计及其相似的还有近些年来兴起的手机交互设计。现在各个企业都如火如荼的进行着手机客户端的设计开发，手机界面尺寸有限，如何尽量少的形式表达出用户真正的需求，又让用户有好的体验呢？

1. 减少不必要的

在小空间设计上，不能要求面面俱到，要懂得牺牲的魅力。开放式设计可以让空间得到最大的利用，将卧室、客厅、餐厅打通，形成大空间态势，减少固定笨重的装修，用灵活可变的轻质隔墙，甚至滑轨拉门或其他可移动家具来取代原有的密闭隔断墙，既节省空间，使居室更显通透感，同样也可以让你拥有独立的空间。

床头部分可以增加弹簧，白天收起增大活动空间，晚上睡觉时再放下，

在手机交互设计中

1. 精简内容

手机界面尺寸比较小，又要考虑符合手指点击的面积，所以往往不会像web页面中把详细分类及信息全都铺出来，导航条也不会像web界面设计中的细长的一条，只能精简内容显示最常用的几个版块。

2. 隐藏菜单

对于占空间比较大，在特定情况下才需要的东西可以设计为隐藏菜单，需要使用时再显示出来

2. 纵向发展

将床面抬高，不知不觉中增加了床面以下的可利用空间

继续抬高床的高度，下面的空间可以作为衣柜和书桌空间

手机交互计中

列表页的设计，现在的智能机最大的特点就是用到手指的动作，所以列表页长一点没关系，用手指滑动上下或者左右翻页比web界面上的翻页效率高出很多

1. 信息量比较大的表格结构的列表，这种页面在web页面中显示时会出现纵向滚动条，在手机交互设计中多数用上下滑动

2. 如果做分屏设计的通常使用横向滑动，横向滑动的特点是一次滑动一屏，但是想一次只移动一点点的话就不适合做横向滑动了。

3. 还有一种分享类型的列表，由于不停的会有新的分享图片出现，更新频率比较高，所以图片排列比较密集，为方便用户自由控制移动多少位置通常也采用上下滑动。

3. 功能区共享

在居室有条件的情况下，我们会让各个空间独立，比如说：我们会单独设立客厅，餐厅，书房等等… 这也就是我们说的几室几厅，它各个房间的功能，但如果是小户型，就没那么多房间可供你划分，我们接触最多的是零居室，也就是说只是一间房，甚至于厨房都是敞开的，只有卫生间是独立的。因此，许多空间必须是重叠的，甚至于是单一空间多用途，比如说：餐桌可以成为书桌，还可以兼顾吧台的作用；榻榻米可以成为客卧，同时它又是个书房；在下铺的床板下，还可以有一个小拖床，不用时可以推到床下，也可以单独推到另外房间使用。适合小户型的家具天生要身兼数职。

餐桌可以成为书桌，还可以兼顾吧台的作用

榻榻米可以成为客卧，同时它又是个书房

在手机交互设计中

由于空间有限，功能区共享的设计随处可见。

1. 一个区域的不同位置有不同功能。

例如在大多数读书软件中，阅读中的屏幕上显示的是书的正文内容，单击页面左侧时书向左翻页，单击页面右侧时书向右翻页，单击屏幕中央区域，书页的上下空白处分别会出现一些功能菜单。这就是在一个一页书上共享了翻页、章节选择、进度调节等许多功能的入口。

2. 一个按键长按和短按有不同功能。

例如iphone键盘英文输入法时，短按一个字母键输出英文字母，长按字母键时会弹出相似的拉丁文常用字母

3. 对一个区块施加不同的动作有不同功能。

例如iphone中的列表记录，当单击某条记录时，是查看该记录的详细信息，当选中某条记录并用手指进行横向滑动时，此时会在相应的列表记录旁边出现一个醒目的红色删除按钮，点击按钮系统则自动删除此信息。

总结：还是那句话，交互设计无处不在。在我们的日常工作中，很多地方都可以借鉴到生活中积累的经验。

下篇预告：生活中的交互之交通指示牌

浅析手机Web App的交互设计

daichuanqing — 2011-11-27 22:14:31

HTML5为提高手机网页的体验提供了诸多的可能性，交互效果越来越接近原生App，故而成为Web App，有望将APP功能引向浏览器，让移动平台的竞争由系统平台转向了浏览器之间。

Web App比起原生App和wap有着自身的优缺点，先简单了解下其特点，掌握设计趋势，也便于以后在设计中应用。

离线存储

离线存储的意思是第一次访问是下载网页，以后在无网络的情况下也可以使用。一个离线应用程序就是一个URL列表–HTML，CSS，JavaScript，图片，或者其他类型的资源。访问时探测到服务器列表的缓存名单时，会触发下载事件，根据名单下载指定的文件存储到本地。

在下载的同时，浏览器将会周期性的触发进度事件，此事件包含了诸如多少文件已被下载，多少文件仍然处于下载队列等信息。当缓存名单中所有列出的资源被成功下载后，浏览器触发下载完成事件。

当再次访问时，浏览器会再次检查网站的缓存名单，通过对比名单和本地的资源，得知是否需要加载新资源。新版本加载完成之后不会立即被使用。后台可以下载新网页，也不会强制用户打断当前操作流程，重新刷新页面。

如果此过程中的任何一点出现可怕的错误，你的浏览器将会触发一个错误事件，并立即终止。类似于安装应用程序，中途不可以出错。

Web App可以利用存储的特性将重要和重复的数据保存在本地，避免页面的重复刷新，减少重要信息在传输过程中被泄露，增量传输修改内容。

而离线存储但也不是Web App特有的问题，浏览和阅读类App也有离线的使用需求，用来应对随时可能出现的网络问题。如离线模式是利用网络闲暇时间下载内容，当用户打开App时立即开始阅读。或者是网络不佳情况下保存用户的操作记录和加载相对重要的文字内容，之后再依次上传已更新的数据，如微博的发送队列机制。

交互操作

手机网页的操作发送只有点击，点击链接和控件，交互方式非常单一，而Web App 的操作将越来越接近应用程序。

1.Web App的建立离不开网络速度的提升，加载更多的内容，图形元素更为丰富。同时更多的JS交互，便于用户操作和形成扁平化的信息架构。

图标取代文字链接，界面更为美观，便于识别的。点击区域不限于元素的视觉区域，便于用户点击。同时排版不受限制，可以达到原生App的视觉效果。

增加标签栏，首页呈现更为的内容，减少界面的层级关系，页面关系更为明确。

界面可以部分更新，在需要时再呈现，减少界面的刷新，保存视觉的稳定性。

气泡框可以减少页面跳转，适合消息提醒等微任务的处理。信息架构上越来越接近原生App，有利于扁平化层级关系和减少界面跳转等设计元素将得到更多的应用。

2.识别更多的手势操作，如下拉刷新和右滑存档等平移手势。操作不必全部呈现在界面中，和平台操作保证一致。

3.调用系统硬件，如重力感应等传感器，不过在手机端还鲜有应用案例，离大规模应用还有一定的距离。

总之，交互上可以按照原生App的设计方式，效果将越来越接近，主要区别在于：

1.设计中要考虑到浏览器地址栏和工具栏的占有空间，和其对App的操作存在一定的影响。

2.暂时不适合调用系统底层接口，更适合web网站适配手机做的分支版本。

3.由于HTML的限制，交互的细节上存在一定的差异。

4.动效还没大规模的应用，但Web App界面操作将更为流畅，界面跳转时的平滑移动已经可以实现，以后还有更多的动效得到应用。

5.现阶段信息架构还混杂着原生App和wap两种架构方式。

参考资料：

W3C HTML5

Mobile Web Application Best Practices

HTML5离线存储

Making It a Mobile Web App

Css iPhone

Developing Mobile Web Applications and Mobile Widgets

Getting Started with iOS Web Apps

Youtube Mobile Web App

[IBM developerworks]HTML5 Web app

App加载交互-当前窗口进入新窗口

seanmao — 2011-11-27 21:27:23

App窗口的加载（如:列表窗口进入详情页的loading方式）是一个容易被忽略的问题。为什么呢？原因很多：1.大家（包括设计师）都习惯了Web端先进入新页面，后等待加载的方式，app直接沿用了；2.网速好的情况下，两种加载方式使用体验没太大差别。3.设计师、产品经理通常觉得加载是工程师该考虑的，可是除非项目时间充裕，且遇到非常有sense工程师才会有考虑提前加载。

然而，很多情况下提前加载的好处非常明显，gmail，alipay、ios Native SMS也都在默默的使用。下面我们就来解析下两种加载方式：

通常两种方式
方式一：在新窗口载入。（A到B，在B窗口载入）

这种方式沿用了传统互联网的页面载入方式，也很常用。
优点：窗口即时切换。
适用：B窗口信息量大，如长篇图文混排信息页。
建议：
1).进入B时不要使用空白窗口，采用预置的格式化信息（图片的占位符，信息分隔样式等）；
2).带入A窗口面已加载过的的部分信息，
3).对B窗口的信息进行分段载入。(这样用户边阅读提前载入的信息，边等待，减少焦躁情绪)

范例：图02&图04载入中页面采用了预置格式化，在信息载入前已经把信息框架传递给了用户。用户对将要载入的信息有了预见。

图01 图02

图03 图04

方式二：在当前窗口载入完成后，再切换下一窗口。（A到B，在A窗口载入完成，再进入B）

这种方式相对使用的较少
优点：不会出现空白页面，切换页面完整性好。
适用：B窗口信息少，载入时间快，以文字为主的页面。或者A窗口已在执行某个任务，且有延续性。比如A窗口为一个音频播放页，用户在进入B页前可以继续收听。
建议：需要考虑网络极端不好的情况，载入信息极少时使用，如图05，ios原生短信应用采用的就是当前页载入，当遇到手机报之类的大量信息，就感觉界面卡上一小会。不过介于大部分短信都是文字为主，这样设计无可厚非，如果加载时间长的情况下如图06一样提供状态就更完美。

范例：

另外提交信息（如注册、登录等）一般都在当前窗口返回状态并处理加载。

提醒：加载方式是死的，上面提到的两种方式其实也可以根据具体情况结合灵活使用。

比如：在A窗口载入的列表数据前几条拉取完整的数据信息，用户切换到详情B的情况下就直接可以看了。然后后台预读取余下的信息。减少用户切换延迟。(gmail就是这么干滴。前面5封邮件先预取。)这样做对服务器来说，要求高了些，但体验Smooth很多，大家具体用的时候自己权衡。

另外提一句，进入前务必保存A当前的状态，B返回A时回到进入前状态（如在第15条进入，返回时第15条信息在原来位置，并且配合原高亮消失效果）

相关话题：移动设备的交互和设计源地址：http://xdc.baidu.com/?p=789

移动产品设计之ios导航模式

kent.zhu — 2011-10-27 22:15:25

写在前面：刚开始接触移动产品设计的时候对着设计指南懵懵懂懂的感知了一下，但是还是不甚寥寥。最近读《触动人心》，发现作者对ios的导航模式的总结实在太棒了，于是写下这篇读书笔记。

导航始终是产品设计的重头戏，往往产品设计中90%的事情就是在做导航。在iphone中预置了3种可以直接使用的导航模式，平铺列表、标签页、树状结构，每种模式都配有不同的工具栏和控件。三种导航模式可以独立使用也可以混搭，让你的用户可以优雅的穿行与你的应用之中。

（图片来源：Tapworthy）

平铺列表

这种方式主要用于只有一个主屏的简单应用。这种方式很适合浏览并发现类的应用，因为他的信息架构简单到极致，没有信息层级也没有组织结构，就像一叠卡片一样。主要信息在卡片的“正面”展示，“反面”就是简单的设置，向左右滑动即可翻页，典型应用比如内置的天气应用。

当然，平铺列表式导航也可以根据你的需要随意的添加、删除卡片。从某种意义上讲，他的扩展性优于标签页式导航，因为标签页模式中类目与顺序都是固定的。

在平铺列表模式的页面底部都添加了页面分页控件，其表现为一排小圆点。小圆点的数量代表了平铺的页面的数量，而高亮的小点则是另外一种形式的导航，他显示了当前所在页面的位置。同时，页面分页控件也是可以操作的，点击控件的左半部分或者右半部分或者直接左右滑动可以切换上一个/下一个页面，不过，页面分页控件每次只能翻一页，而不是直接跳转到某一页去。一般而言，页面分页以不超过10个为最优，超过了20个就会溢出屏幕了….

另外，为了更好的表达”卡片堆“的隐喻，最好不要在平铺模式下设计多个不同的滑动手势。在触摸屏上大家都能在单一方向上进行滚屏，但是2个方向的滚屏需要更好的精度，这种做法有些挑战人机工程学了。

标签页

在ios上标签页一般依附在屏幕的底部，标签栏将应用功能一一归类，点击一个标签就会跳转到相应的页面上，然后该标签以高亮的形式表明你当前的位置。在标签页模式下，每个标签对应的页面都可以有自己的界面风格和特定的内容与功能，看起来就像是在运行一个独立的应用。

标签栏的高度是49像素，每个按钮都会包含一个文本标签和图标，按钮的宽度取决于放置按钮的数量，标签栏限制最多可以放5个图标，超过之后会在第5个按钮的位置出现”更多“的标签。

当然，标签栏以49像素的高度存在其实占用了不少的屏幕空间，所以在某些情况下可以适当的去掉标签栏，典型的就是图书类应用的全屏阅读模式。

树状结构

这种模式简单来说就是将层级信息分类到一棵倒置的树枝上。这种导航模式很适合列表，点击列表中的一项可以看到新的列表，列表可以再进行分拆，直到进入项目的详情。树状结构的一个变形就是表格视图，也就是我们常说的”9宫格”，这种变形更加的图形化。

当然，根据信息的不同，树状模式中的标签也可以进行分组。一个树状模式可以分为若干的组，每个组可以包含任意数量的行数。

3类导航模式的比较

导航模式	优点	缺点	代表应用
平铺列表	适于信息架构及简的浏览性页面；内容可自定义且数量可变；隐喻明显，手势单一；占用页面空间少；	无法快速进行跳转翻页；最多只能容纳20个页面；难以包容滚屏，对长文本不利；页面指示器不够明显，其他页面容易被忽略；	天气
标签页	点击一次即可访问应用所有的主要功能；清楚告知用户主要功能和当前所在；	只能显示5个；应用的大多数页面都会始终占据一定的屏幕空间；	Instagram
树状结构	处理大量的类别、功能和类目；组织方式的隐喻容易理解；可直接对内容进行交互，占用屏幕空间小；适合用户自定义分类；	主功能只有在最顶层才会被显示，不能在每个页面都展现；主功能和分类直接切换比较麻烦，必须先回到顶层；	Mail Facebook

导航模式的组合应用

平铺列表、标签页、树状结构3种导航模式并不是互斥的，完全可以在一个应用里对他们进行混搭。这种混搭可以帮助我们克服单个导航模式的短处。

模态视图

我们经常会遇到在某个路径中滑出一个单屏、进行编辑、查看信息、操作界面的上的内容的情况发生。这是一种应用行为的特定形态，一般带有流程的界面变更的情况发生，比如一张页面临时取代了整个应用程序的显示屏，我们称这种处理方式为“模态视图”。默认情况下，模式视图从屏幕底部边缘滑上来切一半覆盖了当前整个屏幕,模态视图完成和程序主功能有关系的独立任务，尤其适合于主功能界面中欠缺的多级子任务。这种操作会暂时绕开应用的正常操作。

模态视图常常被用来编辑或添加内容，当你需要的时候模态视图一般从屏幕底部滑出而后遮盖先前的页面，当你完成任务后滑出的页面也会相应的缩回去，然后可以继续之前的流程。有些控件和界面元素只在次要任务中被偶尔用到，模态视图很好的把他们暂时隐藏了，并且当需要的时候出现，有效的节约了屏幕空间。

模态视图有点像是导航中的死胡同，为了能够让用户也可以同样方便的回到正常的流程中去，模态视图除了正常的操作之外一般还有加上一个“完成”按钮，或者“取消”按钮。

最后，一个移动产品设计的礼仪问题

当用户从你应用的一个地方跳转到另外一个地方再原路返回来的时候，应用应该主动恢复到他上次离开的样子（千万不要重新加载，你懂的！）。这玩意学名叫状态恢复，这种保持不变的礼仪对移动产品的体验来说相当重要！

拒绝一页一页又一页

michelle — 2011-10-24 10:25:58

手机屏幕大小有限，但应用产品功能太强大，十多个页面都装不下，于是我们总会面对一级又一级的次级界面，并迷失在其中。

而实际上，我们对一个产品的要求往往很纯粹，大多数的操作也就集中在那2,3个页面中，虽然次级界面有助于我们把握逻辑关系，但过多的页面“转场”更让我们感到焦虑。

那么如何能有效的利用空间，使我们能在当下的页面完成更多的操作，实现更多的功能呢？下面就和大家分享一些APP应用和他们的解决方案。

以上界面中的这些小细节设计，有效的减少了页面的“转场”和繁冗，使得用户更便于记忆和使用。当然，仔细观察，还有很多诸如此类的设计值得我们思考和学习，优化应用产品的品质。

iphone Web App 导航设计探讨

一叶苦雨 — 2011-10-21 10:53:24

最近在做iphone端Web App的项目。由于产品形式新颖，技术环境不成熟，公司给与了较宽松的研发时间。在一个月的交互设计阶段，每个环节都得到多次讨论推敲，我从中感悟颇多。导航系统的设计是一个比较典型的点，拿出来与大家分享讨论一下。

导航系统所遭遇的挑战

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导航设计的关键所在。

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

移动产品设计之设计

kent.zhu — 2011-10-09 19:40:17

按照我的理解，场景、任务、用户可以称之为设计的三要素，每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的。同样的设计遇到不一样的场景就会有不一样的方式，从Web设计到移动产品设计亦然。

曾经有个朋友问我，从Web设计到移动产品设计你感觉最大的差异点是什么？我觉得，最大的差异点在于用户使用场景的变化，场景的变化引发了交互方式巨大的变化，从而也使得信息呈现方式有所不同，再加上硬件设备的差异，最终使得2者千差万别了。所以，移动产品设计之设计应该首先从用户的使用场景出发，同时考虑用户的硬件设备差异，综合以上2点去帮助用户完成某个任务。

当然，从生态系统的角度而言，移动生态系统也是迥异与互联网生态圈的。移动生态系统可想象成拥有许多层的系统，每一层都依赖于其他层，他们相互依存构成了无缝的端到端的体验。

运营商在最底层，他们是移动生态系统正常运作的基础，他们负责基础设施建设并维护与用户的关系；运营商运营着无线网络，而网络能力同时也受制于设备与与天线的类型；而由于不同设备对工业标准解释的不同直接早就了移动生态系统最大的挑战，移动设备碎片化；软件与服务要在设备上运行就需要有平台，移动平台主要分为授权平台、专有平台、开源平台，其中我们熟知的有Java ME、iphone、Balckberry、android等；移动平台通常是与他所运行的操作系统绑定在一起的，比如symbain、Windows Mobile、ios、android；而开发者通常能够访问到的就是这些平台的应用程序框架并以不同的语言来开发应用程序。

在移动产品设计的过程中我们也会经常有意无意的涉及到生态系统的某个层面，而哪怕用户只想在移动端做极其简单的事情比如“访问我的博客”，都必须通过这些层，所以，这导致整个的移动环境十分复杂，整个移动产品设计需要具备的能力与素质也相对更甚。

移动产品设计之使用场景的变化

没有了舒服的人体工程学座椅，只有拥挤的车厢或者顶着烈日的街头；没有了灵活的鼠标和舒服的键盘，只有晃动的屏幕和方寸间的按钮；你不再是一边放着歌一边刷着网页，而是希望能够迅速的找到你想去的那个店铺；你也不会成天挂在线上，而是会经常担心这个月的流量是不是又超标了……

这种场景的变化呈现给我们的是用户在移动设备上不断的碎片时间的消耗，用户越来越没有耐心。这看起来挺糟糕的，可实际上也是好事，这种使用场景的变化会迫使你放弃做类似Web端大而全的产品设计的想法。相反的，你会聚焦去解决用户在某一个碎片时间段里的需求。这种更聚焦的“单核思维”需要贯穿与整个移动产品设计中（详见：更多的限制，更简单的设计）。

移动产品设计之设备的变化

你的用户会使用什么样的设备来访问你的应用？这个问题是每个设计师在设计最初需要思考的。你的用户所使用的设备需要从多个维度去考虑，如操作系统、使用的网络环境、设备的分辨率等，这些信息都必须被综合起来考虑，最终运用到产品设计中去。对没错，这就是移动产品设计中臭名昭著但又很好玩的“适配”。2个同时使用android手机的人在使用同样一个应用程序的时候可能体验是天堂与地狱的差别，而即使同样都使用iphone但是在不同的网络环境下体验也不一样。这些，都需要去考虑…..

当然，这里有另外一个问题我觉得可以探讨一下，那就是不同平台直接的设计借鉴与移植。我的感觉是ios与android完全可以按照同样的一套架构去设计，只是在具体的交互方式上按照不同平台的特性去做就OK。比如同样是删除在ios上是左右滑动在android上是长按。

另外，这种硬件设备的变化也是移动产品设计与Web产品设计一个很大的差异。在移动产品设计上，一定要充分利用设备本身去完成设计。相对Web产品而言，移动设备自身提供了很多硬件能力，比如光感、磁阻、陀螺仪、….对这些能力的运用是移动产品设计的起点（详见：移动产品设计之硬件能力）。

移动产品设计之交互方式的变化

整个移动产品的的交互过程可以概括为，用户触发某个任务跟客户端发生交互，客户端将该任务反馈给服务端，服务端向后端请求数据并做数据拼接同时反馈结果给客户端，客户端将最终结果展现给用户。当然，某些复杂的任务实际上需要客户端向服务端并发数次的请求。

考虑与服务器端的交互并不是移动产品设计所独有的，但是却是移动产品设计过程中最需要设计师去“设计”的交互。因为这关乎3个事情，对用户流量的消耗和用户操作的流畅性，同时也是对客户端性能的一个考验。这是我认为目前移动产品设计的用户体验最重要最根本的地方，保证客户端性能的稳定性，用户可以在低网速条件下顺畅的操作，同时尽可能的帮助用户节省流量，而UI层面的体验问题反倒是其次的。twitter和foursquar不论是在ios和android甚至symbain上都没有花哨的界面，但是他们仍然是我心目中当之无愧的最优秀应用。

同时，从键盘机到触屏机再到多点触控甚至于目前的语音助理，我们发现移动端的人机交互方式在不断的演进。于此同时我们也发现，越是高端的移动设备用户的“惰性”反而越强，用户期望能够使用更低成本的交互更快速的完成任务，这也是移动产品设计必须要面对同时也是移动产品设计师最能有成就感的地方。

最后，单就手机端产品设计而言，对于移动平台的选择

iphone这2年的势头太猛烈了，加之推广渠道单一产业链相对完整，所以iphone客户端的设计、推广都很容易见效且效果巨大；android太过开放，直接结果就是渠道纷繁复杂但无一能处把控之势，所以推广费力且收效甚微，小团队可以在开辟完ios战场并有成效之后果断跟进；symbian？如果可以，迅速放弃吧！WP7势头可观，但目前不太适合小队伍入场，大团队可先做储备。

相关话题：移动设备的交互和设计源地址：http://www.ikent.me/blog/3957

移动设备手势设计初探

CDCer — 2011-09-05 14:58:49

嘿~最近在做各种移动端的产品，设计啊体验啊操作啊，用的手都起茧，工作之余也思考了“手”这种较新的交互方式，以及它与界面的关系。本文从手势的种类，应用场景，存在的可用性问题以及如何设计四个大的部分谈起，在此抛砖引玉供大家思考和学习。

移动设备大行其道的今天，手势是一个流行词汇，那手势是什么呢？手，是人类各种创造性活动的天然工具，人们天生就会使用手的动作去表达情感，比如人们会使用握手来表示友好，聋哑人使用一套用手语来代替语言交流，这些都是手势在生活中的应用。可见自古以来手势就是一套特定的语言系统，在人的交流中发挥重要的作用。从交互上看，手势实际上是一种输入模式。我们现在在直观意义上理解的人机交互是指人与机器之间的互动方式，这种互动方式经历了鼠标、物理硬件、屏幕触控、远距离的体感操作的逐步发展的过程。

然而交互设计领域，大家普遍探讨的手势概念，是区别于传统的键盘操作和鼠标操作的。后面会着重研究移动设备的手势操作，主要从手势存在的问题、应用场景以及设计时应注意什么说起。

1. 利用鼠标、光标的轨迹模拟手势

网站www.kakarod.com，采用了大量的屏幕模拟手势交互，点击、拖拽等动作，生动活泼让人眼前一亮。

2. 在物理硬件上的手势

苹果Magic Mouse鼠标, 。macbook触摸板均支持单指多指滑动等多种手势。

3. 在触摸屏上的手势

主要有长按、轻触、滑动、拖动、旋转、缩放、摇动这八种手势。

4. 远距离体感

通过摄像头，传感器等捕捉手甚至整个身体的姿势，来进行控制。

5. 未来的手势

利用全息投影以及传感器，在空间或者投影上直接操作，这个已经应用在某些领域，相信不久的将来一定会广泛服务于我们的生活。PS：在苹果最新申请的专利中就提到了“投影手势操作”的技术，乔帮主这次又会带来什么革命性的产品就让我们拭目以待吧。

当然在生活中也还有其他的手势操作，这里就不再赘述。本文主要研究的是目前爆发式增长的移动设备上的触摸屏手势操作，以ios，android系统为主。触屏上的手势是指，将一系列多点触摸事件综合为一个单独事件。分析触摸屏上的手势使用现状，发现相对于传统鼠标键盘，手势交互操作一些明显的特点。下图是从时间和空间两个维度总结出的手势概览。为读者在手势设计时提供参考。

可用性研究的专家Don Norma在最新一期的《Interaction》杂志中也对手势交互界面进行了质疑和抨击，认为新的手势交互界面有很多地方没有遵循已经建立好的交互设计原则，使得经过良好测试和业内已被理解的交互设计标准正在被推翻、忽略和违背。

笔者通过分析现有的app 应用，以及多产品的设计经验，发现此质疑不无道理，主要有以下几个问题：

1.精确性降低
以 ios为例，相比光标1像素的精度，手势的精确性要低很多。适合手指点击区域需要做到44*44px（iphone4以下设备），配合手势的轻重有0~20px的偏差，所以触屏界面需要使用更大尺寸的控件响应面积。iPhone 3GS、iPad和iPhone4屏幕分辨率密度分别为163 ppi 、132 ppi和326ppi，可以看到3GS和iPad的控件响应像素接近，单边应达到44px的标准，而iPhone4则需要再扩大几倍。

2.缺乏可见性和一致性
以iPad Pages这个App为例，比如文稿中有2个对象，你想要使它大小一样，有以下两个方法：你可以通过双指拖拽利用边缘参考线让它们大小一样，当然这种放大缩小的方式在很多App中都很常见，因此很容易想到。另外你也可以这样做，用一只手指拖拽其中一个对象的同时，用另一直手指触碰你想要与之相同的对象，当出现符合大小提示时先抬起第一个手指再抬起第二个手指，那么这两个对象的尺寸就完全一样了（这两种方式在app中没有任何帮助和说明）。那么很显然，没有人会轻易发现第二种手势方式。即使发现了也不会很快知道如何使用。再比如android的长按操作也是如此。

造成这个问题的重要原因是手势界面通常没有代表动作的可视元素，手势即动作。若是通用自然的手势就没问题，若是罕见的组合手势那用户就很难发现它，并有可能带来可用性问题。

3.增加操作成本以及误操作
在位移上
手势操作相比于呆板的鼠标点击的确生动有趣了许多，但一些操作，比如放大缩小和下拉却增加了操作成本，在鼠标上滚轮就能完成的事，触屏上就需要手指上下拖动许多下。
在力度上
手势操作没有鼠标按下的物理反馈，因为力度也难以掌握，有时糟糕的设计会让用户误以为是自己操作的问题，从而反复尝试。
在灵敏度上
ios的触屏都很灵敏，轻触和长按的操作界限很模糊，并且除了固定的Button，很多操作的响应区都很大，不受Button大小限制。因此常常会不小心碰到使某个操作响应，例如在通话记录播出一个号码以及备忘录的右滑的删除。

4.受限于物理因素
物理按键
带来真实的触感和一定的操作中断感，后期的手机逐渐弱化物理按键，手势与屏幕结合的更紧凑。Android用硬件按钮触发菜单，意味着你无法预知什么程序以及在什么情况下会有菜单选项。因为硬件按钮始终在那里，无论程序是否需要它。

上图从左往右依次是Plam pre、palm pre2、palm pre3，返回按钮与手机屏幕融合得越来越紧凑
横竖方向
直接受限于物理按键，android设备的物理按键位置不统一，横竖屏切换时不便于快速辨认，手势的连贯操作会受到比较大的影响。如果app支持水平方向，考虑将返回按钮和常用的菜单直接显示在软件界面上。因此app应考虑直接提供“返回”按钮。

设备尺寸
大屏幕的Pad支持更多的多指复杂手势，手机大多单指操作。
控件形态
按钮的大小控制（不同分辨率下大小的转换）、拖动时的反馈提示、滑动选择与点击的转化。

基于上述可用性问题，总结出手势操作设计时应该注意以下几点：
1.操作引导
这里可以是详细的帮助界面也可以是隐喻图形化的引导（隐喻要符合用户的心智模型），例如分页的圆点标识，或者切换页面露出一部分内容，可长按的系统icon，翻起的页脚升，甚至动画等等。这里的提示程度自己拿捏，效率型应用，尽量做到清晰可见，即看即点。沉浸型应用可以适当预留探索的空间，让用户自己去发现，带来预期之外的惊喜。比如QQLiveHD首页拉绳的晃动。但是，要注意的是隐藏手势和快捷手势不能影响主操作流程，可以作为辅助手势来使用。

2.操作反馈
手势操作快速轻便，但没有鼠标按下时didadida声的安全感，也十分受限于设备屏幕的灵敏度，所以操作反馈的作用至关重要。例如icon按下时的响应，这里除了没有mouse over的效果，其他三态和PC端是一致的，缺一不可。除此之外还要考虑的是操作区太小被手指遮挡住的情况，反馈一定要明显，并呈现在可视范围内。比如QQ通讯录的姓名检索操作。除了视觉反馈声音也是一种有效的反馈方式，比如iPhone发送SMS发送成功的声音。新浪微博的feed拉取，tweetbot等，都巧妙的运用了声音反馈。

3.误操作
手势操作相比鼠标更灵活，如果你的程序非常复杂，承载的信息很多，大部分区域都是响应区，那么发生误操作的几率也会大大增加。因此要让用户可以及时撤销操作，时刻知道现在发生了什么，而不是仅仅当发生后给出一个警告。常用于较重要或隐晦的手势，例如删除，一键清除，长按等等，二次确认操作就显得至关重要。

OMG，不知不觉讲了这么多⊙﹏⊙b，以上只是手势交互的初探，对于这个应用领域，还有很多值得研究和探索的地方，欢迎大家一起来探讨和学习。

最后，感谢“弹指之间”小组成员此次研究上的给力贡献！撒花~最后奉上之前在TED看到的由Jeff Han带来的一则关于手势交互的精彩演讲： http://www.ted.com/talks/lang/eng/jeff_han_demos_his_breakthrough_touchscreen.html

Android 3.0（蜂巢）交互&UI设计规范

雷蒙德 — 2011-08-31 18:26:02

Android OS自上市以来，由于缺乏统一规划，使得不同设备在 1.5、1.6、2.0、2.1、2.2、2.3几大版本徘徊，本人用的HTC Hero(俗称G3)也是从1.5~2.3一个个版本，10多个rom手动刷机试过来的，过程及其纠结 ~。
多系统版本带来的问题就是缺乏交互、UI的一致性，外加硬件厂商HTC、摩托罗拉、三星、夏普（创新工场点心OS）、小米（MIUI）等公司热衷于UI的个性化发挥，以及民间高手的DIY rom 等因素，影响着安卓饭儿的用户体验，使各阶层用户徒增学习使用成本，也让APP开发者在不同版本兼容性间疲于奔命。

过渡开源的Google终于明白一个道理：没有规矩不成方圆，对搭载Android 3.0系统的所有平板电脑进行UI设计规范的梳理。自微软、苹果之后， google也终于推出了自己的UI设计规范，这对用户来讲是个贡献。

此规范的主要目的在于统一Android 3.0设计思想，从视觉设计、UI模式，框架特点、前端开发等方面去指导、影响后续开发者。

这就是Android 3.0的系统初始UI，考虑下蜂巢比ipad设计好在哪里

多任务、板块之间的灵活切换、工具添加……通过缩略图，而变得更加直观。

Action Bar、多栏布局、应用程序导航，这些系统功能在姜饼（Android 2.3前版本）和蜂巢（Android 3.0）之间的设计异同及取舍

UI及交互细节的细节处理：去除文本框、文字间距与框体尺寸（dip）

Popup的设计

关于Back和Up的交互流程设计

在这插一句：Back 按钮 在Android 2.3前版本里它是一直是个硬邦邦的实体按键，由于这个脑残的设计，让许多用户想”返回”却在屏幕操作中找不到门路，最可怕的是每个”back按钮”在不同硬件设备中的位置不一样！这你敢信吗.

而在Android 3.0中，Back采用触摸按键和屏幕融为一体，欢呼！

PPT下载地址：

http://file.1mobile.cn/KunlunUED-1mobile-android_phones_and_tablet-modify.ppt

由Kunlun UED（www.gameued.com ） &1mobile(www.1mobile.cn ) 联合翻译

Android应用程序需不需要手动退出？

阿智 — 2011-08-25 20:43:01

不止一次，也不止一个人问过这个问题。我都回答了：不需要。但是，还是要记录下来。

我们不妨从了解这个系统对于应用程序管理的一些内部机制开始说明原因。

对于Android系统而言，包含“进程”和“服务”。“进程”有正在运行的，也有刚刚离开在后台缓存的。“服务”是一个无界面、长时间运行的应用功能，并且不会轻易被终止。

我们知道，在Android中可以快速通过主页键（home）或者使用返回键（←）逐步离开应用程序。

主页键：

在当前运行的应用程序的任意界面，按下主页键会快速回到手机主屏幕。同时这个应用程序的进程将在后台被暂停并建立缓存，再次启动应用程序时可以方便地返回刚才的界面。（现场被保留）

当然，在你按下主页键回到手机主屏幕时，因设计需要，也有可能会在后台运行一个甚至多个进程和服务，以保证这个应用程序在后台是“活的”。

尽管我们知道了后台会产生各种各样的“进程”与“服务”，但你并不用担心它们会把你的手机拖累。当运行新的应用程序发现内存可能不够用时，系统会自动在后台释放部分缓存在后台的进程，以保障可运行新的应用程序。这是一个智能的、良性的供给体系。

返回键：

Android系统使用返回键来进行屏幕后退，以及关闭对话框/菜单/屏幕键盘。

对于传统的本地客户端应用程序，每个屏幕可以理解为一个活动（Activity）。通过返回键可以快速回退到当前应用程序的上一个活动，也可以离开当前应用程序打开的新的应用程序的某个活动。

所有的活动呈堆栈结构（一种串行形式的数据结构），正在运行的活动处在最顶端。当你按下返回键，会清除当前活动并恢复上一个活动。如下图示例：

（配图出处：http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html ）

如果你连续按返回键，活动一个个被抽离，就像剥洋葱一样。

在Android的应用程序里，可以通过“意图”功能，在当前应用程序（任务）的某个活动启动另一个应用程序（任务）的某个活动。

比如下图的示例，在“有道词典”主界面单击超链接“意见反馈”打开浏览器访问目标网页：

在目标网页界面，你可以使用返回键快速返回刚才的“有道词典”主界面。

而接下来这个例子，体验则是非常糟糕的：

如上图，在目标网页想要返回上一个任务需要历经几番周折。

一遍又一遍地回退浏览器的浏览历史，甚至还要回到浏览器的起始页，然后弹出一个对话框询问是否要退出……

天哪！我快要疯掉了。

Android官方对于多个任务间的活动堆栈处理机制，可以看下面这张图来解释：

（配图出处：http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html ）

从图中我们可以看到，一开始在后台的“任务B”的“活动Y”经由“任务A”的“活动2”的一个按钮抽调到了前台，而随着“任务B”的活动一个个被剥离，最终整个“任务B”被结束了，并且使用返回键又回到了“任务A”的“活动2”。

返回键实现了调用新任务之后快速返回的便利，而不是只能迂回地回到应用程序列表并找到上一个使用的应用程序再次启动。

当所有的活动从堆栈中清除，任务结束。也就是说，在应用程序的主界面按下返回键时，应用程序就已经退出了。
除非，这个应用程序设计了后台运行的进程和服务。比如"新浪微博"，即使你在应用程序主界面按下返回键退出了，在“程序管理”>“正在运行”界面上仍然可以看到正在运行的进程和服务。（需通过菜单键切换至“显示当前运行的服务”视图）

正如上面提到的，后台服务是一个无界面、长时间运行的应用功能，并且不会轻易被终止，即便你使用“任务管理器”。（其实可以在“服务”界面找到它并且手动停止服务，只不过没有这个必要性，交给系统自动处理即可。长时间不使用某个任务时，系统会认为你已经不再需要了并且会自动帮你结束。）

至此，我们已经知道为什么Android应用程序不需要手动退出了。因为聪明的系统已经帮助用户做了许多事情，包括退出应用程序以及恢复可用内存。

受限于Android官方对设计规范的态度，Android并没有像iOS那样明文告诉设计者不需要这个不需要那个。Android应用程序的设计模式也因此而“百花齐放”，很难形成较为统一的体验。比如本文提到的需不需要手动退出Android应用程序的话题，如果在iOS中看到屏幕上有退出应用程序的按钮，是一件搞笑的事情。

无论如何，Android也好iOS也罢，用户本来就不需要关注“进程”或“内存管理”、“任务管理”这些东西。用完，离开界面即可，就这么简单！把用户不需要关注的问题抛给用户，无异于“不想让小孩玩火，但是又给他一个打火机。”

而设计师们，该做些什么了。改变吧！

看到这里，也许你会问：既然Android应用程序在后台被挂起暂停了，但是为何开多了应用程序手机还是会变慢呢？

一方面：新运行的应用程序如果需要较大的内存，自然会比较慢。另外，如果手机本身的内存过小且CPU不给力，系统自然会因较频繁地自动结束进程释放缓存而导致手机在某些时候运行比较慢的感觉。

也正因为这样，我们知道了为什么“任务管理器”会如此流行，甚至成了“装机必备”。人们用它来快速提前释放缓存以保证运行新应用程序时有足够的内存。当然，随着CPU频率越来越高，内存越来越大的发展趋势，手动清除缓存已经慢慢变得不再需要。

另一方面：临时启动的后台服务可能会导致手机变慢。有些应用程序在后台监听到指定的事件会自动启动，比如操作系统本身的“Google服务”，又比如连接USB并且在PC上启动“豌豆荚手机精灵”，手机上的“豌豆荚守护精灵”会自动启动。为了避免这种情况，只能建议你有选择性的安装应用程序了。聪明的软件需要先进的硬件来支持。

也许你又会问：既然在应用程序主界面用返回键可以直接退出应用程序，可是为什么某Android应用程序（尤其是国内的）要弹出退出确认对话框呢？

这其实更多的是产品人出于不希望自己的应用程序太容易被用户“退出”，或是担心“误操作”的原因，为此给用户增加一道障碍墙。

瞧瞧我们眼前的PC软件吧！单击窗口右上角的 X 图标后，也有不少软件在做同样的事情呢。

毫不客气地说，这是典型的把责任推卸给用户的做法。似乎在警告用户：“真的要退出了？确定的话我就不管你了！”

我们应该尽可能少使用对话框，提供必要的容错支持。允许用户犯错，并给予恢复的机会。比如你可以允许用户在按下返回键离开应用程序后还能再次返回现场。这在很多优秀的第三方应用程序上均有体现，比如Twitter、米聊……

当然，沉浸式的应用程序除外。比如视频正在播放或者游戏正在进行的画面，应尽可能地不要让用户犯错被退出。沉浸式的应用程序应提供沉浸式的保障，因为游戏或电影进行到一半被退出往往是无法返回现场的。

最后，补充说明：本文所说的“退出”是指退出应用程序，而不是指退出帐户的登录状态。如果你的应用程序是需要用户使用帐号密码登录的，那么提供“退出登录”（或叫“注销”）的功能是必要的。

原生启示录

张雅秋 — 2011-08-16 21:53:59

之前写过一篇关于andoid和ios对比的文章——乔布斯改变移动未来的人。

人们通常认为苹果是靠iphone卓越的外观设计轻松取得5%的移动市场份额和他人望其项背的利润，但老乔自视苹果是一个缔造优质软件的企业。他曾夸口苹果在软件上的水平要领先业界5年。今年ipad2发布的时候乔布斯还是没免俗的演示自己开发的应用。老乔让两大软件主要负责人出场并介绍包括iMovie在内的软件产品，并赞赏有加。

其实这一切都是老乔在向app store的开发者传递一种信息。利用苹果自带原生app或者推广的app告诉开发者和消费者“标准”，以这些原生app让开发者和用户了解、熟悉交互操作和平台特点。

举个栗子：）

设计模式

设计模式是在为解决特定问题，可以采用常用的一些常规模式。同时，就像ios guildline里面说的，平台模式也可以减少用户的认知负担：“用户喜欢了标准化控件的使用方法和行为，所以他们不必停下来思考该怎么使用他。当面对那些看起来、用起来不符合标准的控件时，用户之前的经验就失效了。”
Iphone中的”设置”就很好的解决了某个问题：当我同时对A、B、C…等操作编辑但又不互相印象的时候，就可以采用设置这一模式。

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

手势

ios guildline对手势的总结

手势都是相对应交互操作。比如：右滑动显示删除的手势。很多app都采用这个方法，合理隐藏掉“删除”button。

QQ音乐向右拨动出现“删除”和“分享”有效节省了有限的显示空间。

键盘

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

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

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

2、邮箱输入键盘

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

“邮箱键盘”方便输入英文还有@字符。
3、url地址

移动互联网的普及让用户输入网址更加便捷。

iphone网址输入时调用键盘

图标

图标是人机界面对于操作隐喻作用的代表。图形对于操作的表达一个源于共识的认知，比如数字表示顺序、箭头表示方向。还有平台图标的共识。

ios人机界面手册对于部分图标的说明

with的拍照和action不会引起用户迷惑，这些图标保持传达性的同时表现自己的风格。

文案

“所有用于与用户沟通的产品文案，都需要保证你的用户能够理解。也就是避免使用行业术语，了解目标用户，以判断所使用的文案是否适用于他们。

常见的一些用语：返回、设置、保存、分享都是安全语言。