本文是《iOS Wow Factor:Apps and UX Design Techniques for iPhone and iPad》第二章译文精选的第一部分,其余章节将陆续放出。上一篇:iOS Wow体验 - 第一章 - iOS人机界面设计规范纵览
关于本套译文分享的详情及目录结构,请参考iOS Wow体验 - 译文分享说明。
全文由C7210自发翻译(编译),并首发于Beforweb.com,如需转载,请注明译者及出处信息。英文原书版权由Apress所有,中文引进版的版权由相关出版社所有。
iOS用户体验的成功与流行不是由某个单独的设计元素或交互方式造就的,它是一种整体效应的体现。然而,要想真正理解是什么原因让iOS如此迷人,我们必须将这个整体拆解开来,逐一进行分析。接下来,就让我们对那些定义了iOS用户体验框架的基本要素进行深入解析。
首先,我们会把注意力放在一些层面较高的问题上,包括界面外观的隐喻与效用、直接操纵的理念以及Home键。随后,我们将从界面空间模型和用户心智的角度出发,对iOS系统及应用的交互机制进行分析。最后,我们还将对iOS简洁易用的设计理念做以了解,并看一看所有这些不同方面的要素是怎样通过视觉设计统一成为一个整体的。
相对而言,iOS系统本身是缺乏视觉隐喻性的。然而,这并没有影响交互操作方面的可感知性与易用性。我们可以从这个现象中看出,在过去的十多年中,用户本身也在发生着改变。正像前文所提到的,iPhone的物理设计,尤其是Home键,使其一经推出就引发了不小的争议;这充分体现了当时的大众和媒体所广泛持有的保守观点。不过很显然,iPhone的设计是经得起时间考验的,原因就在于,这种设计理念代表着与旧设备的分道扬镳,同时,它也淡化了与传统桌面设备之间的关联。
iPhone用户界面的设计理念强调了“效用”,而非“隐喻”。众所周知,苹果在很久以前就已经在桌面设备当中创造出了革命性的、富含隐喻元素的图形化用户界面。这套设计方案很快也被PC所采纳,大家都沿用至今。类似“桌面”、“文件”、“文件夹”这样的概念都是非常容易理解的,它们以图形化的方式呈现在系统框架中,用户可以直接对这些界面元素进行操作。这样的人机交互方式已经在我们的头脑中变得根深蒂固了。在这种情况下,苹果为什么会选择通过非隐喻的方式来打造iOS呢?
回头看看iPhone刚刚发布的那个时代,将它与当时的同类设备进行比较,我们就会发现,更加倾向于“效用”而非“隐喻”的设计思路并非苹果所刻意创造出来的。经过了功能与导航方式的复杂演化历程,当时的智能手机和功能手机在交互设计方面已经确立了相对稳定的、更加适用于移动设备的模式。界面通常采用九宫格的形式,由各种应用图标组成,用户通过四向导航进行控制操作。这种设计方案确实很有效用,用户可以快速扫描屏幕,找到相应的应用图标,选择并执行任务;速度与效率在这里起着决定性的作用。比起相对复杂的隐喻化环境,用户在这种更加倾向于“效用”的界面中不必花费时间去思考各种交互元素的隐喻含义。
所以iOS也采用了类似的做法。虽然它的用户界面缺少明显的、整体化的视觉隐喻性,但从本质上说,iOS仍然是一个高度可视化的系统。其主界面向用户呈现了一个抽象空间,代表各种应用程序的图标分布在其中。有的图标只包含一些非常简化的图案,不涉及对应用功能的描述;另外一些则相对复杂,对产品本身的功能具有一定的描述性。
多数情况下,用户会首先根据图标的视觉外观来识别某个应用;图标下方的标签文字对于应用的识别作用只是次要和辅助性的。当用户在进行多屏切换的时候,这种行为特征将变的特别明显,他们会以很快的速度浏览屏幕中的图标,以决定是否要继续扫到下一屏。应用图标的外观特性也是iOS能够在视觉上保持简单易懂的重要原因。
iOS设备中没有文件系统的概念,这也与其用户界面的非隐喻特质不谋而合——没有“文件”,那么 “桌面”和“文件夹”这样的隐喻化元素自然就失去了存在的意义。对于不同类型的数据,iOS有它自己的一套处理方式,无论是内容的创造还是获取,数据都会作为应用程序工作流的一部分而运行。用户不需要在复杂的文件系统中进行组织和管理工作,当他们需要完成某些操作任务时,也不必在各种文件中进行繁琐的查找。每个应用都会独立地管理与其相关的内容对象,这种机制也决定了用户在iOS中对于不同类型的内容进行组织和管理的操作方式。下面是一些具体的例子,每一条都按照“应用名称”、“内容类型”、“组织与浏览方式”的顺序进行排列:
类似这样的例子还有很多。尽管不同的应用在交互方式上具有很多相似之处,但它们还是会以各自独有的方式对相关的内容对象进行组织和管理。
在这些例子中我们还可以看出,应用程序内部的用户体验模式并不像iOS系统本身的那样抽象,它们在很多时候是高度隐喻化的。通常,小尺寸设备并不适合采用在视觉上具有复杂隐喻性的用户界面。要使小屏幕中的应用界面足够吸引人,在设计上所面临的挑战还是很多的。正如我们在前文中提到的,iPhone的界面设计是以“效用”为优先的,但这并不意味着我们无法在应用内部实现高度隐喻化的用户界面。实际上,我们已经在很多优秀的iPhone应用当中看到了这方面的设计典范。不过,具有高度隐喻化的应用界面设计方案只有放在iPad中才能更加充分地体现出它的价值。
iPad代表着一个全新的产品类型,在它身上并不存在传统移动设备当中关于效用与隐喻的历史遗留问题。iPad所面向的是更加闲适化的需求,娱乐性的重要程度超过了速度与效率。虽然iPad与iPhone运行着同样的操作系统,但在应用程序内部的视觉表现方式上却存在很大的不同。屏幕尺寸的差异固然是造成这种分化的主要原因,但另一方面,具有高度隐喻性的拟真界面风格也成为很多iPad应用的重要特色。无论是界面的视觉效果,还是交互操作的物理体验,这些应用都对现实中物体的行为特征进行了高度的还原。虽然这种界面设计方式在其他类型的设备中也是可行的,但iPad的特性使这种拟真效果上升到了新的高度。
图 2-3 iPad的Calendar应用
当应用产品还处于概念阶段时,隐喻与效用是我们必须考虑和权衡的两方面因素。不过,这两者之间并非是互相排斥、非此即彼的关系。不妨观察一下你手头的那些应用,它们的构建方式体现了怎样的理念?它们的界面和交互方式更加偏重于隐喻还是效用?通过这样的分析,我们可以更好的理解这两个概念在实际设计方案中的实现方式,并逐渐学会将这些理念运用到自己的产品当中。
直接操纵,对于任何类型的触屏设备来说都是绝对的基础性概念。它的大意是,用户可以直接控制界面中的交互对象,完成某项任务。相对的,间接操纵就是指我们必须依赖于某种输入设备,通过移动某种指针或焦点,间接的控制交互对象。要实践直接操纵的理念,最关键的一点,就是要在交互行为中拉近输入方式与交互对象之间的介质距离,使用户难以察觉虚拟的交互对象与现实的操作行为之间的屏障。直接操纵在iOS设备的用户体验中发挥着重要的作用,很多让用户觉得新奇和兴奋的交互方式都是基于这个理念的。
其实,用户对于“直接操纵”这个概念的理解是与生俱来的。因为从本质上讲,它所映射出的就是我们与真实世界之间的互动方式。现实中,我们会拖拽一个物体而使它移动,某个按钮被按下时会表现出凹陷的效果。对于这些互动,我们不需要借助任何设备或指令的控制;交互对象的反应行为也是可以预测的,并且会符合我们对于现实世界规律的认知。
然而,要在iPhone和iPad这类实际屏幕尺寸极其有限的触屏设备中有效的实现直接操纵的理念,其中还有不少有待跨越的障碍。为了优化可用空间,当前惯用的做法是将交互元素做的尽可能的小;然而在很多时候,它们被设计的太小了,以至于破坏了可用性。所以,对于触屏设备交互元素尺寸的把握确实是具有挑战性的。目标对象越小,触摸的难度就越大,尤其对于那些在小范围区域内集中排布的控制元素,用户误操作的可能性会非常大。目标对象本身容易因为手指的遮挡而难以辨识,周围的其他元素也很容易被错误的触摸到。
从这方面讲,想要在iPhone这种屏幕尺寸过于狭小的平台环境中打造足够健壮并且易用的触控系统,挑战将变得尤为突出。不过,我们还是可以看到一些很优秀的设计方案。最好的例子莫过于iOS自带的虚拟键盘。苹果曾经面临的挑战,就是怎样设计一款能够在如此狭小的空间内,特别是在竖屏的状况下仍然可以让用户自如使用的键盘系统。无论怎样,按键都必须做的很小很紧密,而这样又会让你很难看清刚刚按到了哪个键。那么又是怎样的原因让这套键盘可以在实际的使用过程中有效而流畅的工作呢?苹果带来的解决方案是这样的:
图 2-4 iPhone的虚拟键盘
这些做法将具有高度健壮性的交互设计理念与各种复杂的技术结合了起来,有效的克服了人机工程学和可用性方面所固有的一些局限,解决了在小尺寸触屏设备中实施直接操纵的常见弊端。不过必须承认,这的确是一种风险很大的处理方式;除非你有足够的资源去创造完美的方案,优化和扩展核心交互方式,否则还是尽量避开这种棘手的情况为好。
在直接操纵的交互环境中,用户固然需要与目标对象产生直接的互动,以改变其状态,或触发相应的功能;但在很多时候,具有变通色彩的设计方案同样是可行的。我们完全可以通过一种相对间接的方式来“直接”操作目标对象。例如,在某些特定的情况下,按钮确实无法做的更大,那么不妨在它周围设计一个可以起到相同控制作用的“目标区域”。用户可以通过对目标区域的操作来完成交互行为,而无需精确的触击到那个位于该区域中心的小按钮。进一步说,你甚至可以将目标操作区域与交互对象进行分离。这点也引出了下一个小节的话题。
“手势”两个字的用途很广泛,在不同的上下文环境中,它的含义会有很大区别。当我们谈到硬件设备通过复杂的机械原理,将人的肢体动作编译为输入信号并传入系统的过程时,这个词基本就是它字面上的意思。对于苹果来说,“手势”二字在更多时候所指代的是一些特殊的触控操作方法,这些方法已经超越了直接操纵理论所定义的基本输入方式的范畴。通常,这些“手势”需要多个触摸行为同时发生(多点触摸),以引发特定的系统响应。不过,iOS中的一些基本手势仍然属于直接操纵理论所定义的范围。其实,在抽象的层面,很多手势是大同小异的,它们只是根据上下文情景的不同而存在着微小的差别。
下面是iOS中最常见的一些手势:
除此之外,越来越多的新手势也开始出现在iOS当中。看看它们能否被用户和其他应用开发者迅速地接纳,是一件挺有意思的事情。这些新手势大多是对以上几种基本手势的扩展,而且更适合用作系统级别的全局导航与控制,因为这些手势并不是针对某个应用中的特定交互组件所设计的。它们大都需要多指配合操作(超过两指),这也是将它们与那些专门用于控制应用界面交互对象的标准手势加以区分的重要标志。
正如我们在前文中提到的,虽然Home键曾经饱受争议,但如今,它已经被广泛的接纳了。
在以前几个版本的iOS中,Home键的功能是可以被定制的,人们可以通过双击Home回到主屏幕,或是进入搜索、联系人个人收藏、拍照、iPod音乐播放等功能界面。而之后的版本中,Home的定制功能被取消,苹果显然更希望这个按键可以专门用在那些有助于提升系统导航功效的方面上。
要理解苹果的这种思路变化,还得从iPhone本身的用途转变说起。除了使用常规的手机功能之外,用户会将越来越多的应用塞进它们的iPhone,这种趋势必然会对系统平台的支持能力提出越来越高的要求,而这也正是推动iOS不断进化的一个主要驱动力。为了满足用户在这方面的需求,设备的存储能力也在一直在提升,而另一方面,随着应用商店的成功,以及各种专业化应用程序的不断涌现,用户的需求和渴望又被进一步的扩大。苹果自然希望人们会下载更多的应用,但实际情况是,用户人均持有的应用数量超出了他们最初的预期和准备。怎样让系统对越来越多的应用程序进行有效的组织管理,并提供高效的导航方式呢?这逐渐成为苹果必须不断面对和解决的问题。
曾几何时,在iPhone中打开一款应用是很简单的,你只需要快速浏览屏幕并找到这个应用的图标,点击进入。也许你的应用图标需要两屏才能放得下,即使是这样,你也可以快速滑动到第二屏继续寻找;最多只需几个简单的手势,我们就可以很容易的找到想要的应用。慢慢的,两屏发展到了五屏,在这种情况下,通过快速滑动前后切换屏幕的方式就开始显现出弊端了。 通常,切换超过三次之后,人们的方向感就会开始下降;一屏接一屏的应用图标在眼前快速的前后滑过,视线无法聚焦,你甚至会忘记自己正处于哪一屏,很快就会产生疲劳与挫败的感觉。
随着iOS的进步,苹果的设计师们创造出了一系列优秀的方案,用来帮助用户解决安装应用过多所造成的问题。如今,我们能够通过一种可自定义的二级结构,将同类应用分组收纳。而“多任务切换”功能则可以帮助我们在不退出当前界面的情况下,通过多任务栏快速查看和选择最近使用的应用。另外,我们还可以通过搜索功能直接进入应用。而无论怎样,我们都可以通过Home键来快速的回到主屏幕。
这又将话题带回到了Home键不断变化的本质上。设备的导航机制正在被赋予着越来越多的功能,相应的,Home键的重要性也在不断增强。对于简洁的iOS系统界面来说,额外的导航控制功能是不能被接受的;而应用内部的用户界面则不然。对于后者,我们必须按照人机界面设计规范所要求的那样,对各种导航控制功能进行全面而明确的考虑,并保持设计模型的一致性。如果应用界面中缺乏相应的图形化控制组件,那么在导航与定位方面的辅助功能就必须由Home键来承担了。在不同的应用情景中,Home键通常会提供以下几方面的功能:
前面两点也可以通过快速滑动的手势来完成,不过在很多时候,Home按键的效率更高。而应用切换功能则只能依靠Home按键来调出(iOS5开始,该功能也可以通过多任务手势或是AssistiveTouch来调出)。
这三点常见功能也反映出了Home键在导航控制方面的演变过程。除此之外,Home键还能提供一些系统层面的功能,它们也同样遵从着一系列清晰的设计模式。例如通过单击将设备从休眠模式中唤醒,或是通过双击让设备在锁屏状态下调出iPod音乐播放功能。这些交互过程中并不包含与导航相关的操作,可见Home键同样可以被赋予其他方面的重要功能。通过这些我们可以看出,苹果确实在iPhone的一些最普遍的需求用例中提供了很多非常优秀的解决方案。类似的例子还有通过长按Home键(3秒)进入语音控制状态,以及可以为Home键绑定三连击行为所触发的功能。
将来的iOS中, Home键也许会被赋予更多的用途。说不定它还会从iOS设备上消失,市面上流传的一些有趣的推测也让我们看到了这种情况最终发生的可能性。或者,它也有可能被某种非硬件的控制方式代替;相应的,原本由它触发的各种功能也可以通过一些新的手势来控制。无论怎样,我们可以放心的是,苹果会一直让iOS设备在这些方面保持进步。
译文代表原作者观点。欢迎发表评论,或到译者微博进一步交流探讨。