为触屏移动设备而设计
openkk 13年前
<div id="news_body"> <p> 在本文中，作者 Josh Clark 将向我们介绍一些触屏移动设备用户界面设计当中需要注意的问题，并对 iPhone、iPad 和 Android 相关设备在触控交互体验方面的友好性进行了对比和分析。</p> <p> 对于移动设备的操作系统及应用来说，判断其用户界面设计方案是否优秀的一个重要衡量标准，就是看它对于手指触控操作的友好程度。相对于桌面计算 设备及相关的软件环境，触屏移动设备所具有的交互特性几乎将用户体验设计师们带入了工业设计的领域；设计方案更多是在体现着人机工学方面的原理，而不再是 仅仅用来规划内容与功能的视觉呈现方式。</p> <p> <strong>拇指热区与底部原则</strong></p> <p> 首先，我们需要了解人们通常会以怎样的方式将手指停靠在设备上。拿手机来说，普通青年们多数会使用拇指来进行触控操作，所以触屏手机的界面交互方案基本是围绕着拇指来进行打造的。</p> <p> 拇指的功能具有相当的弹性，同时也受到一定的局限。对于常规的触屏手机来说，我们可以使用拇指扫过屏幕当中的大部分区域，但其中大约只有三分之 一属于真正有效的触控区域。所以在设计当中，要尽量将最重要的界面交互元素放置在这个范围当中。在右手持机的状况下，有效触控区域位于屏幕的左下方。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/1d2b7db2daa87ff87727a95ca11a6f2e.jpg" width="200" height="371" /></p> <p> 这也正是移动系统或应用中一些重要的工具栏或导航结构通常被放置在界面底部的原因。与此相反的是，在传统的桌面设备系统环境中，导航菜单一类的 界面元素通常被放在界面顶部，无论是本地软件还是网页基本都是如此。对于我们有限的拇指作用范围来说，这种传统布局方式显然不能很好地适用移动设备的用户 界面。</p> <p> 相比之下，左下角还是右下角的问题略显次要。我们在实际当中经常会更改左右手持机方式，想想看是不是这样，譬如对于右撇子来说，当他们正在写字 或是需要同时使用鼠标操作桌面设备时，通常会将手机交于左手操作；而左撇子们则正相反。不过在多数时间内，使用右手持机的用户还是要相对较多一些。</p> <p> 底部原则可以帮助我们对界面当中的可触控元素进行更好的组织。最常用的功能按键应该被放在拇指最容易触摸到的热点区域当中，而其它相对次要或是 比较敏感的控制元素则应该尽量避开这个区域。以 iOS 中的“编辑”按钮来说，它通常被置于界面右上方，这个位置即可以保证它清晰可见，同时又不会被很容易的触碰到，以免发生误操作。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/969de954ffdc5ed9fc94be61125c6f5d.jpg" width="200" height="373" /></p> <p> 另外，底部原则不仅与拇指的作用范围有关。当我们使用拇指在屏幕上进行操作的时候，手指下方的内容部分将会被遮挡住；只有将交互控制元素放在内 容区域的下方，才能让这种负面效应降至最低。其实这是一条具有广泛适用性的设计原则，我们可以在很多其他类型的设备中看到这种原理的体现，例如 iPod、计算器、带有实体键盘的普通手机、电子秤等，无不是内容在上，控制在下。</p> <p> <strong>我，机器人（Android）</strong></p> <p> 在 Android 设备中，底部原则这档子事被机身下方的实体硬按键搞的复杂了些许，尤其是冰淇淋三明治之前的平台。这些硬件级的控制按键占据着底部区域，在某种程度上会与 应用内的底部交互元素形成视觉上的竞争。彼此层叠在一起的软硬件工具栏会使用户在快速操作的过程中产生迷惑，增大误操作的几率；对于在两个维度上共存于拇 指热区当中的软硬件按钮，它们之间的冲突几乎是不可避免的。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/c44a770517e065b40621c0a88e3082bf.jpg" width="200" height="388" /></p> <p> 固化的硬按键是无法被移除的，避免控制元素之间产生冲突的最直接的办法就是让虚拟与实体的工具栏在视觉上彼此分离，而这就意味着需要将 Android 应用中的相关控制元素和导航结构放置在用户界面的顶部。这自然不是最理想的解决办法，因为界面顶部离拇指热区远着呢，你要触摸其中的某个按键时，几乎会将 半个手掌都覆盖在屏幕上。不过比起与硬件工具栏层叠在一起的方式来说，这种解决方案仍是利大于弊的。</p> <p> 这种将重要的控制及导航元素放在顶部的做法与 iOS 设备的方式正相反。虽然 iPhone 的 Home 按键同样在机身底部，但它的表现形式与 Android 设备的硬按键有很大区别，它不会对应用界面底部的相关操作元素带来视觉上的干扰。下面的截图展示了 Foursqure 应用在这两个平台中的界面设计方案对比：</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/c7fb3969a69087ca32aa337bccd39788.jpg" width="330" height="335" /></p> <p> <strong>移动版本的网站</strong></p> <p> 毫无疑问，当我们在移动设备中浏览网站页面时，类似的问题也会出现。我们可以将网页理解为应用中的应用，因为它需要通过浏览器这个应用程序进行 输出呈现。移动平台当中的很多浏览器都会将一些常规的控制元素放在底部工具栏里，这在某种程度上又有可能与页面当中交互元素产生视觉上的冲突。所以，对于 移动版本的站点来说，一个最基本的设计原则就是不要将重要的控制元素或导航结构通过 CSS 的 position:fixed 定位方式固定在用户界面底部。</p> <p> 不过，与 Android 应用中的解决方案有所不同，对于 Web 页面来说，将控制元素与导航结构放在界面顶部的做法同样会产生很大问题。毕竟当前绝大多数的主流触屏手机仍属于小屏幕设备，而传统 Web 页面的横向全局导航结构通常由若干包含着一到两个词语的导航项组成，这对于手机屏幕来说显得太拥挤了，我们必须另想办法来解决导航栏布局的问题。</p> <p> Luke Wroblewski 在 Mobile First 一书中提到：“在很多移动版本的站点中，用户首先会看到一大坨导航结构，而不是内容。在移动应用的上下文环境当中，时间永远是宝贵的，流量搞不好是要花钱 的，你必须尽最大努力让用户在首屏中得到他们最想获取的信息。”</p> <p> 确实是这么回事。移动版本的站点，在布局方面，应该使主要内容尽量多的占据着首屏当中的空间，而导航结构则应该以某种缩略的形式出现在相对次要 的位置。Wroblewski 通过一个实例来倡导这个设计模式，也就是 Ad Age 的移动版站点。其首屏当中，除了网站标题及最新内容列表之外，右上角的菜单按钮是界面当中唯一一个交互控制元素。当用户点击这个按钮时，导航列表才会出现 在屏幕当中。看上去，整个导航列表好像是另外一个界面，但它实际上是被放置在页面最下方的，而菜单按钮只是个锚点而已。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/8e7d6a175f60332e47e69d5444ab8632.jpg" width="330" height="418" /></p> <p> Wroblewski 继续发言：“这个设计方案在首屏当中使用了最小化的导航机制（只有一个按钮链接），用户可以集中精力去阅读每个分类当中的最新文章。当他们浏览至当前页面 的底部时，还可以直接通过导航列表来探索更多的内容。最棒的是，顶部的菜单按钮只是一个锚点，整个导航机制不涉及到任何会导致交互流程复杂化的元素，例如 JavaScript、覆盖层或是独立的导航页面等。”</p> <p> “内容在上，控制在下”的规则看上去挺简单的，不过一旦涉及到实际的上下文环境，例如操作系统或浏览器的用户界面特性，设计师们要考虑到的情况就变的复杂了。截至目前，我们可以将讨论过的话题归纳为几点设计原则：</p> <ul> <li>对于 iPhone 中的客户端应用，尽量将重要的交互对象及导航结构放在界面底部。</li> <li>对于 Android 中的客户端应用，尽量将重要的交互对象及导航结构放在界面顶部。</li> <li>对于移动版本的网站页面，尽量将导航结构放在页面底部（注意，不是当前用户界面的底部）。</li> </ul> <p>这些设计原则仅限于手机的上下文环境当中，而对于屏幕规格较大的触屏设备，例如 iPad 来说，规则就要发生变化了。</p> <p> <strong>平板电脑</strong></p> <p> 拇指热区的相关规则同样适用于平板电脑，不过，由于持机方式不同，热区的位置也有所变化。iPad 的拿法在很大程度上取决于整个人的姿态。我们在站着的时候，需要一手持机一手操作；坐在桌前的时，我们往往会用一只手像支架一样从侧面架住 iPad，而另外一只手用来戳戳点点；坐在椅子上的时候，我们通常会将它放在膝上进行操作；而躺着或是半卧着的时候，又会将它立在腹部，一手支撑，一手操 作。</p> <p> 每一种持机方式几乎都对应着一种特定的热区规则，而且在每一种姿态当中，设备与我们身体的距离也有所不同。例如，站着的时候，我们会把 iPad 端的比较近，而躺下的时候就相对较远了。</p> <p> 虽然听上去有些复杂，不过在这些上下文情景当中的交互行为还是存有一些共同特征的。首先，用来持机的那只手通常会握住机身的上半部分，因为这样 最符合杠杆原理；相应的，拇指热区基本会位于屏幕的前三分之一部分，偏向左上角或右上角。其次，iPad 的屏幕相对较大，用户很难像使用 iPhone 那样瞄上一眼就能看到界面当中的几乎全部内容。正像对待普通的印刷品或是 Web 页面那样，用户通常会首先将目光聚焦于 iPad 界面的顶部区域，所以我们的设计方案也要相应的在这一点上符合用户习惯。换句话说，在操作 iPad 的过程中，无论是目光还是手指，它们的主要活动区域都是设备的上半部分。而机身的下半部分不仅会在很多时候被用户视而不见，而且在某些特定的环境中它真的 是不可见的，例如当我们躺在床上的时候，这部分很可能被衣物或被子遮挡住，实在是悲催。</p> <p> 所以，与手机界面不同，在 iPad 及同类平板设备的应用当中，主要的交互控制对象应该被放置在界面的左上角或右上角，以便拇指可以很容易的触摸到。Instapaper 和 推ter 在这方面做的都不错：</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/989d85e90bd3b5a7d8d6154266f050ba.jpg" width="300" height="385" /></p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/d4ed783013ff731c29d6766adaf0ba33.jpg" width="330" height="424" /></p> <p> 需要注意的是，应该尽量避免将交互元素放在屏幕顶端正中间的位置，否则用户在进行操作的时候，手掌会将很大一部分内容遮住。实际上，任何会对下 方内容产生直接控制作用的交互元素都不应该被放在这个位置。在 The Daily 的 iPad 应用当中，内容正上方有一个滑块，用户可以通过拖动它来前后切换文章页面。意图不错，不过当你执行这个操作的时候就会发现，自己的手掌会遮挡住文章内容， 而手指则会挡住缩略图，体验弱爆了。单凭这一个地方的疏忽，这个设计方案就足够作为反例登场了。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/df70172efb72781f4715f25694529c50.jpg" width="330" height="422" /></p> <p> <strong>又一个底部原则</strong></p> <p> 我们可以从 The Daily 的失策当中了解到，对于 iPad 应用来说，在某些特定的情况下，控制元素还是避开顶端微妙。你可以将它们放在底部甚至侧面，只要控制元素本身及其所需的交互行为不会对内容的可读性造成影 响。我们来看看 Sydney Morning Herald's的 iPad 应用是怎样做的。如下图所示，在该应用的界面底部有一个页码指示器，当用户对其进行拖动操作的时候，对应页面中的文章标题就会以列表的形式出现在指示器的 上方，使用户不用翻页就能大致了解其他页面当中的内容。虽然文章标题列表会将页面中的内容遮挡住，但在这个交互情景当中，用户最为关注的是列表中的文章标 题，而不再是原来的主要内容区。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/660a14439cfedbf45a81a145f1dbae00.jpg" width="330" height="497" /></p> <p> 对于在不同的情况下究竟应该将控制元素放在顶部还是底部的问题，我们不妨在这里弱弱的归纳一下：</p> <ul> <li>对于那些起到界面导航作用的交互元素（例如“菜单”、“返回”、“关闭”等），以及用来完成分享、收藏、编辑、删除等功能的按钮，通常可以将它们放置在界面顶部。</li> <li>对于那些用于浏览或预览内容的控制元素来说，界面底部是最佳位置。</li> </ul> <p> 所以，我们可以在很多书籍或杂志应用当中看到，页面缩略图列表通常会被放在界面底部。假设你正在设计一款与地图相关的应用，界面当中有一个地标 托盘，用户可以将地标从这个托盘当中拖拽出来，并“按”在地图上的某个地方。在这个例子当中，托盘同样应该被放在界面底部，这样可以保证当用户从托盘里将 地标拖拽出来的时候，地图不至于被手遮挡住。</p> <p> <strong>交互对象的尺寸</strong></p> <p> 如果说交互对象的布局位置取决于平台类型及持机方式，那么它们的尺寸则在很大程度上由手指的大小来决定。我们必须将这些交互元素设计的足够大，才能保证用户可以进行准确的辨识和触击。</p> <p> 不过，要做的多大才算够呢？不妨抬起手看看自己的指尖。很多系统平台的设计规范都在这方面进行了描述，不过我个人觉得苹果做的仍是最棒的：理论 上，可触击元素的最小尺寸应该为 44 像素（约1/4英寸或 7 毫米）见方（The comfortable minimum size of tappable UI elements is 44 x 44 points）。</p> <p> 请注意 point 与 pixel 的换算关系在 Retina 屏与普通屏幕之间区别。</p> <p> 在移动应用的上下文环境中，足够大的按钮不仅便于操作，而且可以让用户维持必要的注意力，避免被周围的环境所干扰。</p> <p> 44像素见方的最小规格只是一种理想状态下的情况，在实际当中，合理的折中方案通常是必需的。即使是 iPhone 用户界面中的很多原生控件也避开了这个规则的限制。最典型的一个例子就是系统自带的键盘，其中每一个键位的高度是 44 像素，但宽度只有 30 像素；而横屏状态下，其宽度是 44 像素，高度则变为 38 像素。不过这也是苹果的无奈之举，因为怎样都必须将完整的 QWERTY 键盘搞到界面当中，所以必须在设计方案当中有所取舍。</p> <p> 参考苹果的做法，当空间的局限使得我们确实无法实现 44 像素见方的设计方案时，应该尽量保证其 44×30的最小规格。</p> <p> <strong>元素的尺寸与空间布局</strong></p> <p> 上个世纪，不少人都被卡西欧的计算器手表浪费了大量的青春年华。问题不仅仅在于那些微小的按键会让戴着它的人看上去很二，最不靠谱的是，这些按 键的排布实在是太紧密了。你想按5，但通常会按到 8 或是2；与其说是计算器，还不如叫它幸运转盘更合适些。尺寸过小的按键以及毫无间隔空间的布局，是产生这种结果的两个最直接的原因。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/b4143cf69d46be67cfe7397c0287572b.jpg" width="300" height="200" /></p> <p> 为小屏幕设备进行界面设计的时候，这类挑战确实是我们经常需要面对的，而造成问题的根本原因却通常不是产品需求本身。无论是在计算器手表的全盛 期，还是如今，我们时常会听到产品需求方翻来覆去的念叨着：“咱就把这些东西再挪近一些吧……我只想在这个工具栏里再加一个按钮……”。</p> <p> 如果我们必须在设计方案当中将交互元素排布的非常紧密，那么至少要把它们各自的尺寸尽量做大。想想 iPhone 原生的拨号键盘界面，或是 Skype 等应用。界面当中的拨号按键之间的间隔通常都很小，甚至没有间距；而每个按键的尺寸几乎可以用巨大来形容，因为这样可以有效的降低误操作的几率。</p> <p style="text-align:center;"><img alt="为触屏移动设备而设计" src="https://simg.open-open.com/show/278b8dd52169c51491edcf1422b964fb.jpg" width="200" height="300" /></p> <p> 其实，无论是 iPhone 原生的拨号界面，还是上图所示的 Skype 中的同类界面，它们都在底部导航工具栏的上方放置了一些控制按键。如果以我们在前文当中提到的一些原则标准来衡量的话，这种做法其实不算得当；但是在这几 个具体的情景当中，这些控制按键的大尺寸特质却可以有效的降低它们与底部导航工具栏之间的视觉冲突。</p> <p> 所以，要在有限的小屏幕可视区域当中打造出成功的用户界面设计方案，我们必须结合实际的产品需求，在交互元素的尺寸和空间布局等方面做好充分的权衡与判断。</p> <p> Via <a href="/misc/goto?guid=4958330703018123698" target="_blank">Netmagazine</a><br /> 来自: <a id="link_source2" href="/misc/goto?guid=4958330703819130352" target="_blank">www.iteye.com</a></p> </div>