关于移动的交互设计:手机语音自动识别的交互...（精选7篇）

2024-09-14 17:37:57

小编给大家分享关于移动的交互设计:手机语音自动识别的交互...（精选7篇）的范文，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。。 - 素材来源网络编辑:李欢欢。

以下是小编收集整理的移动的交互设计:手机语音自动识别的交互...，本文共7篇，欢迎阅读与借鉴。

移动的交互设计:手机语音自动识别的交互...

篇1：移动的交互设计:手机语音自动识别的交互...

文章描述：浅析手机语音交互设计.

语音识别技术，也被称为自动语音识别，其目标是将人类的语音中的词汇内容转换为计算机可读的输入，例如按键、二进制编码或者字符序列，

语音识别技术作为输入方式，比按键输入和手势输入更为快捷，学习成本很低，对于非特定人连续语音识别系统的识别率达到98.73%，已经达到实用要求，具有广阔的应用前景，在手机端的应用有语音拨号、语音输入、语音命令、语音搜索和语音翻译等。

语音的技术原理比较复杂，可以从语音交互的过程来理解：

1.开启语音识别功能。一般由用户手动点击按钮启动，手机端暂时无法自动启动，如由语音命令启动或者根据音量高低判断开始识别。

2.进入说话界面。程序界面会通过视觉体现音量的变化。

3.说话完毕，系统开始分析。结束输入有两种方式：一是自动关闭，通常时输入单词完毕之后自己的关闭，另一种是用户手机手动关闭。系统处理过程可以分为以下几个步骤：

a）前端处理。该模块的主要任务是从输入信号中去除噪音等影响结果的因素，提取特征，供声学模型处理。信号处理之前会先进行断点检测，端点检测是指在语音信号中将语音和非语音信号时段区分开来，准确地确定出语音信号的起始点。经过端点检测后，后续处理就可以只对语音信号进行，这对提高模型的精确度和识别正确率有重要作用。语音增强的主要任务就是消除环境噪声对语音的影响。目前通用的方法是采用维纳滤波，该方法在噪声较大的情况下效果好于其它滤波器。

b）声学特征提取，

声学特征的提取既是一个信息大幅度压缩的过程，也是一个信号解卷过程，目的是使模式划分器能更好地划分。如上传音频会利用到语音编码解码技术，可以减少音频的文件大小、存储空间或者传输比特率。

c）统计声学模型。计算各个帧的声学特征，如上下文建模。根据发声机理，音之间只能渐变，前一音会影响后一音，从而使得后一个音的频谱与其他条件下的频谱产生差异，从而使模型能更准确地描述语音。

d）发音词典。发音词典包含系统所能处理的词汇集及其发音，类似于拼音输入法的词库。如输入法，词典更新热词和词库有组于提高匹配的准确率。

e）语言模型。语言模型对系统所针对的语言进行建模，如分析语音上下文。

由于音频文件大小的限制，本地只能存储少量的词典，这也就要求复杂的语音需要连接服务器分析。谷歌语音搜索在用户输入完成之后才提示无法联网，在启动输入之前就应该检查网络连接状况。

4.系统分析完毕输出结果。一种是根据结果自动显示结果，如bing搜索，另外一种是提供选项供用户选择，这和输出结果的概率高低有一定关系。用户选择的结果对于词典的排序产生影响，增强语音的自适应和强健性，帮助形成个性化输入。

根据产品可识别的词汇量区分产品，对于特定语音命令，用户只能输入符合命令的词汇，比如说出联系人名字搜索。输入法的词汇更多，而语句搜索不但需要庞大的词汇库，处理连续的语音输入需要区分连音和变音，还要求能根据上下文和热词输出更为合理的结果。条件限制越少，语音识别的难度越大。因为一定程度上避免模糊音，词典数据越少，输入特定词汇的准确率越高。

中文的语音输入与英文不同，英文匹配不到词典配置的词就无法识别，中文词汇由单字组成，中文可以根据单字识别。

io 5的输入法已经加入语音功能，会逐步变为手机输入的常规功能，最终输出结果的准确率和操作流畅度是衡量其交互优劣的重要标准。

篇2：移动设备交互设计:手机输入法的键盘布局...

文章描述：手机输入法：键盘布局那点儿事.

输入法，我国一个神奇特色的存在，

在国内，手机输入法可能是玩家用得最多的应用了。但凡是红红火火的操作系统，像Symbian、Android、iOS等平台，都可安装第三方输入法。由于原生中文输入的种种不给力，这给了大量厂商开发输入法的动力和机会。

本文这次只谈针对触屏手机设计的输入法，而由于其博大精深，这里我只谈谈输入法键盘的布局，而且还是触屏手机的。

T9与全键盘

这两种大概是日常生活中接触最多的键盘了。原生的Windows Mobile自带的输入法便是全键盘布局，iOS更是如此。T9自不必说，相信每一个玩家，总有那么几部数字键盘手机，享受过指尖飞跃的快感。

问题来了：这两种键盘，哪种更便于输入？

我的答案是这样的：对于英文输入，全键盘的优势巨大；而在中文输入这里，T9是大多数人的“掌上启蒙”。

对于中文输入，我还有更多的要解释的。为什么能肯定T9输入中文的便利呢？首先，受制于手机小巧的身材，硬要在屏幕上塞入的情况全键盘，无疑是个技术活儿：

太大了，容易遮挡页面，造成视觉上的不适，且没有顾及到手机屏幕大小不一的尴尬情况——本来屏幕只有三寸，还非得用全键盘，整个屏幕的内容区域，会感到压力很大；

太小了，对于电容屏这种“指尖操作”的玩意儿，想要精确点击键位，确实难为用户了。而且对于频频出现的“误操作”，会使用户对输入过程本身产生厌烦心理，不可；折中选择键盘大小呢？对不起，输入法不是买菜，“讨价还价”式的中庸思想，是荒唐的。

所以T9由于其键位少的特点，可以放心地将主要按键扩大，便于用户点击，减少失误率。而且，鉴于目前大多数触屏手机用户，或多或少以前都接触过数字键盘手机，这样的键盘布局，确实可以顺承以前的输入习惯。如果你说“全键盘不是更顺承么”、“电脑上不就用全键盘打字的么”等话语，我会说平时人用的是双手打字，到了智能手机上，“十根手指”会锐减到“双指”或更少的数量，其中的习惯，并不会那么顺滑的传承下来的。T9在中文输入这里，可谓优势巨大。

qwert全键盘（左图）在输入英文方面有得天独厚的优势，T9（右图）在输入汉字上当仁不让

选字区域的设定

输入完成后，我们会面临“选字”的阶段。我认为这个阶段分为这两部分：截取拼音和选择字符。它们有个共同的特点：需要处在一个显眼的位置。

这就比较好理解了，当你辛辛苦苦打完字后，总不能尴尬的寻找选字区域，作呆若木鸡状。这时一个优秀设计的选字框，不是跳出来以博得人眼球，来吸引注意。而由于目前大多数输入法，对拼音有着良好的断字，少数情况是需要用户手动选择拼音的。

所以它们的关系是这样的：选字>选拼音。

并且选字框应该是在这样的位置：1.符合逻辑习惯。2.不影响内容

什么叫符合逻辑习惯呢？这就像平时玩游戏做任务一样，沿着线索找到目的地，这么一个过程。于是我们可以发现，现在大多数手机输入法，它的选字框是这样的：位于输入区的上面，很符合人的习惯。并且在发短信的时候，我们可以发现，选字框的位置，恰好可以帮助人，与已经输入的内容联系起来。

但是有许多时候，我们所希望输入的字，并不会出现在选字区域。我们通常会做这么一个操作：翻页，以查找字。

又出现一个问题：怎样能让人快速找到候选字？

首先，应尽量降低人为翻页的频率，一个显而易见的道理就是：你所做的一切是为了提高效率的。少量的翻页背后是高效率的进程。最简单直白的办法就是，使选字框中的候选字（词）出现得多。但也不可过多，密密麻麻的排列会乱了人的眼；过少，明显违反“降低翻页频率”的目的。解决方案不是“取得两者间的平衡点”，而是有效利用键盘的空间结构：典型的例子是百度输入法“候选字占据输入区”的做法。但占据了输入区则意味着，用户无法及时修改输入内容，这确实是个的问题（iOS自带的中文输入法则不存在此问题）。

标点的位置

问题是这样的：当你需要的时候，这些该死的“小符号”应出现在哪里？

按照PC上的输入方式，最常用的标点——逗号，是在键盘右下角位置的，

电脑资料

因此当我们在手机上敲打这个符号时，应该下意识地向下方窥去——当然，大多数全键盘输入法都是这么做的。但无奈手机屏幕大小受限，你总不能指望把电脑上那套“Shift+组合键”生搬到手机上来。所以，正解是尽可能有效率地利用每一平方厘米，又得与字母键划清界限，常用符号右下角是必须占据的。

“，”、“。”、“？”——顶多是这些标点让用户无需跳转页面，顺理成章出现在右下方。至于“非明星标点”，理应设计一个符号键（最好位于类似PC上Shift键的位置，便于引导用户），将它们塞进去。

对于T9，情况就大不相同了。如果顺着沿用以前数字手机输入习惯的话，大多数情况是使用“1”或“*”来选取标点，现在是触屏手机时代，设计出来的T9键盘有1——9键，就已经够好的了，至于原来手机最下排的键：“*”“0”“#”，应该坚决省去——至少也得换成别的键，不能莫名其妙出现这几个标识。而“1”键的地位就比较微妙，虽然打字主要靠的是2——9键，但3*3的排列却极具对称美感。

这个时候，把“1”去掉像是个极不明智的行为，不如就把它设定成“标点键”吧。也不要把“1”去掉，不然1到9本是单位数中的翘楚，缺一个“1”显得别扭万分。至于那些常用标点（“，”、“。”、“？”），可以放在由“1”（假定是符号键）调出的“标点框”中，按频率排列位次，比如“，”、“。”、“，”、“！”、“…”的排列，就是按照输入频率排列的。但是这样做对于输入“，”这样的标点，则明显增加了不必要的一步操作（点击符号键）。

大多数输入法会将常用标点放在键盘下方，符合习惯

功能键的位置

这里指空格键、删除键和回车键的位置。

空格键：一般应位于底部中间区域，习惯成自然。

删除键：右上角，依然习惯成自然，就连S60的”c“键，依然是位于右上角的。

回车键：中间右侧。

总结：这类键我认为秉承PC的位置最好，无需记忆，让人下意识就能找到，这才是最方便的。

功能键最好移植PC上的位置，降低用户学习成本

中英混输的尴尬

正如前面说到的，全键盘适合英文，而T9更符合中文输入习惯。当你遇到需要频繁在中文和英文间，来回输入的情况怎么办。来回切换？一个风格收放自如、大开大合如全攻全守，一个风格轮转紧密、对称标准如防守反击。刚刚眼前还是Windows，转眼就变成了Linux，你不觉得别扭么。那么就使用T9？就那个输入英文的效率……别逗了。全键盘，你知不知道在公交车上打了很多字后，突然颠了一下，前功尽弃是什么感觉。好吧尽管我把切换键盘描述的那么不堪，但我还是相信大部分人会使用这种方式的。但我总希望它能再优秀一些。

自定义的键盘

这只是一个个人想法：就像WOW里插件的“一键换装”一样，你可以自定义按键的位置，从而定制一个符合自己输入习惯的键盘，并且可以在多个“键盘”中自由切换，以应对不同的环境。

听起来很美？的确是这样，那么它会大面积的收获赞誉么？肯定不行。作为一种功能，它太过高端，以至于对某些普通用户来说，这个功能让人懊恼，甚至困惑——他们需要这个么？也许大多数人只是想要一个简单，易于上手的输入法罢了。花太多时间定制个人习惯，那是Geek的行为。Linux在一些人口中很完美，却远远赶不上Windows的份额。

“不要给用户太多选择。”乔布斯语。

尾声

文字揭开的永远都是行业的冰山一角。在这个问题上，现在我只明白一点：包括布局，所有的一切都应该使文字输入变得快捷。

PS：向所有优秀输入法的工作人员致敬！

篇3：移动交互设计实例:触摸屏手机输入交互设...

文章描述：触摸屏输入的交互设计，

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

缺点

但是同样全键盘输入，触摸屏没有物理按键效率高，原因在于：

1.输入法需要定位手指的位置，比如双手操作电脑键盘时，左手食指中指定位在F键，右手中指定位在J键，而触摸屏无法像按键的凸点或者输入感觉定位，难以形成高效的盲打。

2.触摸屏本身点击没有物理按键精准，触摸屏点击目标区域没有真正点击到目标区域，偏向目标正中心的下方。无论是单手和双手输入，触摸屏本身误点击的概率高。在虚拟键盘这样按键密集型的区域，每个按键的可点击区域有限，误点击的概率更高。

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

4.手指移动范围较大，按键手机输入时手指局限于按键内，而触摸屏输入和切换输入框时手指还在非虚拟按键区域和按键区域切换。输入中文时，并不是像英文那样点击按键之后字符立即上屏，会显示拼音串选择需要的汉字再上屏，手指需要点击备选词。

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

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

中文输入

常规触摸屏中文拼音输入过程可以分为以下步骤：

1.输入字母，键盘提供字母输入建议。比如输入声母w，可以组合韵母“a、u”等高亮显示，但是这只是全拼有效，对于简拼没有意义。简拼输入时只输入拼音的第一码，在输入词组时合理运用简拼可以大大提高输入速度，缺点是容易出现重码。

2.已输入字母组成字母串，智能切词并显示候选词。单个候选词是根据字母中词库中匹配，词组短语和长句需要计算汉字组合的概率。用户在使用输入法也是训练不断更新的过程，使用时间越长，词库越符合个人的输入习惯。词库更新的方法有：

a）单个字母或者全拼匹配候选词的顺序调整。比如输入“hao”，第一个候选词“好”被选择的概率更大，但用户多次选择“号”，那么“号”可能会被调整为第一个候选词，

初始化词库可能由字典、常用短文、文章和网络用语等分别提取而成，候选词、汉字组合以及联想词的概率可以从词库中计算得出，更为复杂的长句输入需要分析汉语的语言习惯。

b）用户可以调整词库中字词候选的概率，也可以自定义词组，对本没有联系的单词建立关联，俗称自造词。比如输入“nima”，用户手动输入“ ”，下次再输入同样字母时就会变为候选词。电脑端计算更为智能，分两次输入“尼”和“玛”，有可能根据输入的先后顺序组成词组。

c）由网络和群体用户会对原有的默认词库的“新陈代谢”。如果多数用户输入了“ ”的概率超出一定概率并成为流行词，可以将该词汇更新到所有用户的词库当中。当词库的几个来源产生更新时，也会影响词库，比如网络上出现的热门事件“郭美美”。

3. 中文的智能纠错能适当缓解误点击导致的效率问题。长句输入时，如发现字母串中个别输入错误时，无法像电脑端这样使用方向键微调，只能整段删除。智能纠错是将疑似错误输入的字母与词库比对，经过运算之后返回正确的输入结果，可以对误点击中常见的打反字母、漏打字母和按错字母的情况进行纠错。这对于快速盲打非常有帮助，可以变相地增加字母的可点击区域，比如已输入“haohaizi”，当继续输入“uexi”，时，第6个字母会由i变为o。没有纠错的情况下，只会根据已输入的字母去匹配短语或者长句。有纠错之后，可以会按照多个字母去匹配，如想输入i，那么只需要点击“u、i、o”中一个，一个按钮的可点击区域变为三个按钮。

在输入过程中，故意输入错误部分字母，百度手机输入法会纠正已输入的字母串，搜狗手机输入法保留错误的字母串。

4.中英混输和输入数字标点，切换面板会打断输入流程，比如在中文状态下需要输入邮箱，由于@和.需要切换输入面板，目前只有对数字使用划词输入。因为单个常用字符切换面板是很低效的操作，特别遇到面板的切换入口和出口不一致的情况。

发展趋势

触摸屏的交互方式已经成为趋势，利用触摸屏的特点和优化程序是可以适当弥补缺陷，触摸屏的交互方式比按键更为丰富，甚至在特定情形下触摸屏输入更为方便。

输入银行账号、邮箱、地址栏和数据表等特殊类别字符段时，虚拟键盘可以改变输入法布局或者切换面板，便于用户快速输入。比如当输入账号邮箱时，虚拟键盘可以显示@和.等字符。遇到连续的输入框时，右下角的按钮变为“Next”，相当于电脑键盘的tab键，用于快速切换到下一个输入框。

手机端编辑字符时如能提供常用的命令会对虚拟键盘起到辅助的作用，这些命令通常显示在虚拟键盘的上方，不受输入法控制，属于应用程序自定义命令并同时出现或者消失。

篇4：移动产品设计之设计交互设计

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

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

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

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

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

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

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

（图片来源：Tapworthy）

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

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

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

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

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

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

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

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

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

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

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

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

篇5：移动界面隐喻设计交互设计

界面是什么？

是的，有些时候，我就在想这个简单的问题，而那时我的答案还是：界面是对软件应用解决方案的显性，使用图形化符号，向使用者解释它的功能与任务，

但最近一些认知却让我对这个问题有了新的回答：界面就是软件应用它本身。它不是一份对软件应用功能的图形化说明书，不是对软件应用功能与任务的图形化翻译，它就是软件应用本身，并且与之浑然天成。

一个简单的问题，仅仅从展开的iPad文件夹时界面的呈现，你觉得，有多少种方法，可以收缩起这个文件夹？

方法其实有三种：点击（Tap）文件夹图标或者点击其他区域；向上拖动（Flick）界面；双指在两侧向内滑动（pin close）。

第一种也许你早就知道，但后面两种，你也许会将信将疑地去尝试，相信我的说法。

所以，从我的角度上而言，这也许是人家常说iOS操作简单易懂的原因。在你点击文件夹后，文件夹展开的的这个动画，以及最终他的视觉样式，已经告诉你了，他应该怎么去关闭，你会不由自主的，就学会这些操作。

而这就是隐喻。《iOS Human Interface Guidelines》里面是这样解释隐喻对体验的影响的：当你应用中的可视化对象和操作按照现实世界中的对象与操作仿造，用户就能快速领会如何使用它。（When virtual objects and actions in an application are metaphors for objects and actions in the real world, users quickly grasp how to use the app.）

对我而言，iOS的文件夹更多的像一个抽屉的隐喻，并且，它的顶部还是玻璃材质的。从拉开的动画当中，他建立了一个类似抽屉的空间，你一看就明白了。

界面与界面之间，并不是简单的线性关系

我们不得不否认的一点是，界面与界面之间其实是应该纯在联系的，我指的这种联系是说，空间感。存在相互之间的层级和逻辑关系的，而且这种关系，越符合现实的，越好。越容易让别人理解，越来越不用让别人学习。

这就是我们需要做隐喻，我们需要通过它，去表现界面之间的关系。

隐喻给人以可预测性，用户能够轻易的理解你设计的软件应用。这是一种掌握的感觉，是一种控制的感觉。当用户操作时，他们知道下一步即将出现什么、怎么回去——即使是在第一次操作。

为什么需要在移动界面中注意隐喻设计？

1.导航缺失

一个触摸屏手机的物理尺寸在3.7寸左右，与一张信用卡相当。在这么狭窄的空间内，我们则不能秉着PC客户端“在一个主界面内完成大部分的任务”的思想，去设计移动客户端。我们必须把界面分拆。

与之而来的问题是，分拆后的界面是有逻辑的，但我们并不能照搬PC客户端中的方法：使用任务栏，层叠的模态对话框去表现这种逻辑。

因为我们根本就没有空间，所以我们得另辟蹊径。

所以，我们把界面拆分得更多独立化，让界面变成卡片式，一个界面只完成一项任务，保证界面之间联系的单一化，避免界面之间逻辑，或者跳转的混乱。

2.缺乏物理力学反馈

传统的手机上，用户使用键盘，去操作屏幕上的视觉对象，键盘在这个阶段中，扮演的其实是用户操作行为的翻译器。而iPhone的出现砍掉了这种操作行为的翻译，变成直接触摸，这是一项伟大的进步。

iPhone虽然缩短了操作行为的执行阶段，但却给操作行为的反馈阶段带来了麻烦：只有视觉反馈，手指触摸的物理力学反馈消失了。

你的手指不再能够感受到键盘按下的物理力学压力，甚至，假设你手指粗壮一点，你就几乎没法看见按钮是否被按下。而在输入时，这种情况尤甚，键盘手机上有着悠久历史的高效的“盲打”输入方式只能进入历史的存档中。

因此，我们更多的需要利用用户的视觉和听觉，去提供反馈。

隐喻设计内容

对于一个产品来说，隐喻设计不仅仅是动画，各种即时状态细节的设计，更多情况下，我们需要按步骤的去完成整个隐喻的系统性与结构化设计。他包含以下几项内容：

1.拟物化视觉外观与听觉反馈

隐喻设计的第一步，从应用的外观着手，如果可以的话，你应该考虑应用的外观表现出真实物理的肌理材质，以及合理的光影效果，并且，得正确的显示界面的元素的相互之间的空间层次感。

另外我们不能忽视的一种拟物化设计：音效。它不仅是对缺乏物理力学反馈的一种弥补的手段，在某些情况下，也是一种有效的反馈机制，如当屏幕处于关闭状态下时（这是经常的事情），拟物化的音效更能让用户了解当前用户的状态。iOS解锁屏幕的声音你还记得吗？还有敲击键盘的声音，以及照片拍摄的声音。这都很好的拟物化音效。

拟物化的外观很大程度上降低了用户的认知成本，无需阅读额外的文字，用户只要看到软件的样子，就知道它的用途，

2.即时反馈

假设，你在触摸屏的设备上，使用手势执行某项操作，但界面上没有任何的反馈。你就不得不去猜测一下，你遇到的是下面的那种情况：

你的操作手势有误，软件无法响应

程序当机了，暂时没有响应

对于情况二，很抱歉，我们也许实在无能为力。但是对于情况一，我们得有必要讨论一下，如果反馈用户操作手势有误，并指引或者帮助用户到正确的操作中了。

由此看来，传统网页上使用的反馈方式，移植到触摸屏设备上，实在是水土不服。移动设备最好的错误反馈，应该是即时跟随用户的手势操作的。

如上图示意，这才是一个触摸屏上，应该具备的一种反馈，它即时响应了用户的手势动作(即使可能是错误的)，而当用户释放操作时，又自动回归到正确的操作结果中来。

对于任何一个软件应用来说，他都是有学习成本的。有的成本高到离谱，比如Office，Photoshop之类的生产力软件，但也有低成本的，如计算器，记事本等。当软件应用而行拟物化设计之后，其实这已经降低了一些学习的成本。但如何继续降低学习成本？让用户犯错，并从错误中学习。

即时反馈缩减了操作与反馈之间的距离，有效降低了用户纠正错误的修复成本，也提高了用户学习的效率。

3.流动式动画

传统的软件界面之间的切换表现得较为粗暴，大部分情况下，他只显示命令执行前和执行后两个界面，而忽略了他们之间的那段过程。而在真实世界中，倘若没有这个过程，你甚至很难理解过程两端的界面，是如何联系起来的。

动画有一种无法比拟的表现力，它是与用户的最有效的沟通方式，一个精致，微细的动画，能够友好的衔接两个界面之间的切换，同时他还有以下的作用：

表现软件当前状态

提供对用户有用的反馈信息

加强用户直接操作的控制感

通过视觉表现用户的操作的结果

流动式的动画贯穿在整个iPhone操作系统中，也包括在非沉浸式应用程序中。但作为隐喻设计的一种手段，我们需要留意的是：动画只是常用于提高用户体验，它本身并不是用户体验的焦点。

隐喻设计的评判标准

1.符合现实逻辑的界面空间

流动式的动画成为隐喻设计的最后一块拼图，但是我们仅仅把拼图拼起来是不够的，我们还需要检验，这样的拼图是否符合真实世界的逻辑。

Flipboard始终如一地采用翻页的动画效果，无论是从首页进入，抑或是从某个订阅源中返回。他甚至还精细的制作了三种翻页动画效果：只翻动一页，翻动两页，翻动三页和以上；他给以用户这样一种感觉：

我订阅的所有内容，是一本杂志

任何页面都没有互相从属的关系，只有先后秩序的关系

在首页上的方块型的东西，等于杂志的目录

而国内的同类产品杂客，他所呈现的界面空间却稍有不同，整体上，他像是一个时刻变换封面的杂志柜。

但个人感觉，从杂志柜进入杂志的过程动画，有点粗暴且难以在现实生活中找到相关性。个人观点，若此过程动画能与iBooks打开书籍的动画类似或相同。也许更加符合现实逻辑。

2.自圆其说

简单来说，你的界面是如何进入用户的视眼，也应该以相反的方式，从界面中消失，并且，这个过程，是能够自圆其说的，且符合真实生活的隐喻的。

3.响应用户的直觉手势

移动设备最大的特点是：直接操作。如果你设置了你的界面是从下方推入，那用户可能会直觉性的认为，我把新界面向下拉，这个界面即可消失。

从图可以看到腾讯爱看成功的照顾到了用户从隐喻设计中所得到的直觉性手势，只需向下拉，用户就可以关闭此界面。

从外观上看，评论界面都处于主界面之下，而动画效果都属于主界面向下拉伸，评论界面向上推至界面顶部。但是杂客的同样响应了用户的直觉性手势，只需在正文界面中，向下拖动，即可激活评论界面，这不得不算是在twitter客户端上的一种进步和超越。

总结

其实理解移动界面的隐喻设计，并不是一件非常困难的事情，因为这是一个化繁为简过程后的结果。而困难的是：设计师应该跳出传统的按钮，点击等交互操作的局限中来，更多了考虑到和现实生活的逻辑结合和用户的直觉手势的响应。

对于移动的软件应用来说，隐喻设计的初衷是为了解决导航缺失和物理力学反馈缺失的问题，但同样，这也是移动产品的竞争力的核心体现。如何帮助用户更快的理解你的软件应用，如何帮助用户更顺畅的使用你的软件应用。这是我们每个设计师，都应该去真实生活中去寻找的答案。

来自：www.userkon.com/tolyer/metaphors_design_on_mobile_device.html

篇6：移动设备手势设计初探交互设计

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

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

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

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