《iOS应用软件设计之道》—— 3.1 流向:从一个画面到另一个画面

简介:

本节书摘来自华章出版社《iOS应用软件设计之道》一 书中的第3章,第3.1节,作者:(美)William Van Hecke ,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.1 流向:从一个画面到另一个画面

简单地说,线框图的主要困难在于指出如何将功能清单以一系列的二维画面表达出来。困难的一部分是提供画面间的流向,让用户感到合理、易于使用。下面看一些构建聪明的流向方案,可供采用。

3.1.1 导航控制器

导航控制器是iOS上最常见的画面切换方法(参看图3.1示例)。位于画面顶端的流向条指示出当前位置,并包含一个回退按钮。内容区的右向箭头提供沿层次结构向下的方法。这种组织方式使任意数目的分支路径成为可能,而且回到顶层的方法也是统一的。用户在这种流向方案中,可以垂直滚动长长的信息画面,水平方向则在画面层次结构中穿梭。导航控制器只适合有限数目的层次结构。倘若你的层次结构需要用户在四五个层次间变换画面,就可能需要将其平整化。(参看第12章,该章解释如何将界面的层次结构扁平化。)
screenshot

iOS用户都很熟悉导航控制器。它们可以追溯到2001年,最早的iPod上就用到了导航控制器。iPod采用旋转轮子来选择一行内容。在iOS中,导航控制器始终是最可靠、可预见来呈现树状层次结构的信息的方法。用户理所当然地接受这种方法,因为许多iOS应用软件都在屏幕的顶部提供了导航条,这是用户判断自己正处于哪个画面、如何回到某一画面的首要位置。是的,导航控制器就是在iOS应用软件中指引你去处的实用方法,你用它很少会出错。
大部分导航控制器采用标准的表格视图(本章稍后会说明)列出各画面的选项。但这不是可以尝试的唯一方法(参看图3.2的其他方法示例)。下面是创建导航控制器经验的仅有的几条严格规则。
screenshot

向下一层的操作涉及触摸某组件,该组件要么带一个右向箭头,要么显示的内容明显是用户想要切换到的画面提示。
在画面左上角应该有明确的回退按钮,标识有你回到的那个画面的名字(而非只有“回退”词语)。
在画面间切换时,应使用水平的滑动动画,向左滑动表示进入下级画面;向右表示回到上一级画面。
只要你遵循这些指导原则,用户就会有舒适、熟悉的流向体验。在此思路下,可以有些不同于普通表格视图的呈现方式。
地图,用户可以触摸某处来开启一个标签,然后点击呈现按钮(带有箭头状标记)以切换至细节画面。iPhone上的Maps应用软件就是个明显的例子,因为地图在显示地理信息方面,是个比列表恰当得多的方法。
一组富有表现力的大幅图片,特别是通过图片而非文字来标识你的条目时。这是个不用右箭头标记的特例,因为它们会破坏每个图标的表现。Podcasts的封面视图就是个例子,人们对色彩绚丽的封面图片的反应和情感比一组标题清单更强烈。
一组精心布置的内容预览图。对于专注某类内容的应用软件,这个方法更富有表现力,比一组标题清单更招人喜爱。Instapaper应用软件提供了网站各篇文章的条理性预览,帮你决定阅读哪篇。

3.1.2 分割视图

分割视图只在iPad上使用,它提供了同时呈现流向和内容的方法,有助于将流向的层次结构扁平化。iPad上大多数有分支的层次结构应用软件都采用分割视图,而且工作得很好。两侧内容的联系简单明了:左边面板里所选择的条目,会在右边面板里显示其详细内容。无论哪一边,都可以有带水平流向的导航控制器,但都没有导航功能。(是的,确实没有。人们已经试过了,这样会导致混乱的结果。)这意味着你有两个选项,在分割视图里延伸导航功能(参看图3.3有关这两种方法的说明)。
screenshot

一个类似于Settings应用软件,其侧边栏一直显示顶层,内容区可以导航。这样,它可以在大量的顶层条目间跳转,如果必要,右侧区域将显示具体的条目内容。
另一种选项类似Mail应用软件,侧边栏可以导航,内容区总是显示左边侧边栏所选的条目内容。当你在右侧要显示定义明晰、内容一贯的内容,例如电子邮件时,这是个好方法。人们可以在其信箱结构中切换,只要他们触摸某封邮件,右边区域就能更新,显示邮件的内容。
在采用分割视图时要记住,你需要决定在垂直放置模式下发生什么:要么仍显示分割视图,要么隐藏侧边栏,在触摸左上角的按钮时再调出侧边栏。在你采用刚才提到的Settings风格导航方式时,很容易得出答案:始终保持侧边栏可见。左上角的回退按钮意味着你没有地方放置侧边栏切换按钮。(有些应用软件,如Facebook,还是设法做到了。它隐藏了侧边栏,但在非顶层的其他层次,侧边栏总是无效的。)
而对于Mail风格的应用软件,答案取决于时刻显示侧边栏与用户多大程度上想专注于内容区孰轻孰重。在Mail应用软件里,垂直放置模式是隐藏侧边栏的,因为用户希望有个较大尺寸的消息显示区域(参看图3.4对这些选项的说明)。
screenshot

3.1.3 页签

页签条提供了在画面底部呈现顶层导航的方式。对于需要快速访问若干顶层画面的应用软件,这是个理想的办法。经典的例子就是iPhone上的Music应用软件,它提供了艺术家、播放清单和音乐本等页签。听音乐的人可能想快速跳转到某个类别,然后定位到他们感兴趣的内容上。页签条意味着即使他们已经离“艺术家”顶层好几层,仍然可以通过即刻触摸“专辑”页签,而在“专辑”层次结构中导航(他们也可以触摸已选页签,回到顶层,再这么做)。若采用页签条,应在整个应用软件中提供顶层导航。页签视图可以包含导航控制器,而不是其他一些办法。
采用页签视图将是个大的抉择,因为页签条对使用该应用软件的人,在大部分时间甚至整个时间都是可见的。你只能一次提供4~5个顶层类别。如果超过5个,用户就要费心去想他最常用的是哪个,其他类别只好隐藏到“更多”页签内。即使你目前只有几个页签,日后还要添加几个页签,这个问题还会困扰你。除非你的应用软件强烈受益于这种“马上能到顶层”的导航方式,否则还是考虑换个一般的导航控制器吧。
除了那些专门任务(简单地说,就是模态视图)对应的专门画面,每个画面都需要划出49点高的区域给暗黑色条(即使你想把它着色成别的颜色,仍应将此区域定义为较深色)。与只有较少组件的工具栏相比,页签条的尺寸、颜色和高亮效果应当在画面的视觉组成方面起中心作用。这样会加强页签条的角色意义,即在整个应用软件中起顶层导航作用,让用户只需触摸一次就能切换到层次结构中的不同分支。

3.1.4 分段控件作为页签

你可能经常需要对同样的信息提供不同的视图,或者同一画面提供不同变体。也许将这些选项组织成类似页签的分段控件,而提供开关来切换它们。由页签条控制整个应用软件,从一个顶层条目跳转到其他顶层条目,但这种轻量级页签风格(称为分段控件的页签)只对当前画面的内容或呈现有影响。因此,你可以提供一个画面的两到三种风格。如果你通过浮动框来快速访问一个以上的控件集合,这样的分段控件也许正合适。iWork应用软件在其检查器浮动框里充分利用了这个技巧。
不要太依赖这个技巧。当导航方案来回在导航控制器中水平滑动切换,又在分段控件的页签之间来回切换时,会让人感觉随意和糊涂。

3.1.5 多种个性

有个办法可以优雅地把几种完全不同的界面和导航结构融合到一个应用软件里。触摸一个按钮(通常位于屏幕左上角),整个界面就变成了新的界面,有时还带有自己的导航方式。最杰出的例子是iBooks应用软件,它有着全面的书店购物体验以及阅读体验,并在这两种体验之间通过三维方式过渡。这种宏大而炫目的动画,让人感觉似乎是在进行重要的导航跳转——“去书店”——而不是启动另一个应用软件。在买书的过程中,书翻回到书架时会在半空中盘旋,在逻辑上把两边关联起来。这是个相当少见的方案,只有在确实需要时才这么用。但在你需要把两种相似而又截然不同的界面关联到一起时,这种方案才是无价之宝。

3.1.6 模态视图

当特定任务不太适合一般的导航层次结构时,可以使用模态视图来应对。在打开模态视图时,应用软件的正常导航和功能暂时失效,应用软件处于一个特定的“模式”,这就是其名称的由来。典型的例子就是Mail应用软件的编写消息界面。这种模式随处可用,与你处于层次结构的什么地方毫无关系,所以它能即时将你带出层次结构,以处理编写消息的操作。然后再把你带回原先所在的地方。
在iPad上,有若干个选择来呈现模态视图(如图3.5所示),每个方式都有自己的特色。
全屏:iPad屏幕相当大,所以全屏的模态视图大有可为。当用户要花费大量时间在此模式上,而可以忘却主应用软件时,这个选项很合适。全屏模态视图占据整个设备的屏幕,它给人的感觉是应用软件里嵌套的应用软件,专属于某个特定的任务,嵌入Twitter应用软件里的网页浏览器就是个例子。你可以很顺畅地打开某人推送的某个链接,花上45分钟来阅读某篇有趣的文章,或者观看视频。这种体验需要用到整个屏幕,其他应用软件在后台运行,而不会占据屏幕的任何部分。
screenshot

页框栏:这是全屏风格的弱化,页框栏有着有限的宽度。在垂直放置模式下,它看似全屏模态视图,占满全屏的768点宽度;但在水平放置模式下,它仍然只有768点宽度,让其下面的界面可见但是灰的。Mail应用软件的编写邮件界面采用了这种方式。其体验很类似于全屏风格。用户能容易地花费大量时间和精力写个邮件,所以应该有个安静、专门的空间来做这件事。但它与全屏风格有个关键的区别:页单不会让其界面太宽。1024点宽度的编写邮件区域会导致相当长的文本行,是排版方面很典型的失误。眼睛从一行末尾移动到下一行开头要走的距离太长,导致阅读错误、认知疲劳(参看第4章有关排版的话题)。
表单栏:这是页单风格的弱化。表单只占据540 × 620点的区域,在屏幕中间悬浮着,界面的其他部分则被灰掉。它不能脱离应用软件的情境太远,因此更加轻量。对于需要一些空间但只占用片刻的任务,如对某个网页业务输入信用账号、导出文档或者改变应用软件整体范围的设置,这个方法很有用。
当前情境:有时你需要在现有视图里呈现一个模式,例如,浮动框或分割视图里的一侧。也许你想在内容窗格正显示内容时,允许用户访问侧边栏;或者需要突破浮动框的导航层次结构,以执行某个特定任务。不应总用这种风格的模态视图,但你在特殊情况下采用它将是件好事。
浮动栏(作为模态视图的替代方案):浮动框往往不是模态视图,但可利用它以轻量方式实现某个模态视图。如果你在考虑模态视图,不妨自问浮动框会不会更好。浮动框让用户更贴近情境,而不是将他们的操作与情境分割开。(若你想让浮动框感觉更像模态视图,则可以赋予它“取消”和“完成”按钮,并且不允许点击别的地方来关闭此浮动框。但这种设计已经不符合潮流了。)因此如果手头的任务关系到屏幕上的现有界面,而不需要模态视图那么大的空间,就尝试用浮动框吧。
在iPhone上,模态视图就更简化了:它们总是全屏的,因为没必要再小了(尽管部分卷曲(partial curl)过渡风格会留下现有空间的大部分区域)。大部分时间你都应用直截了当的垂直过渡,即将模态视图从屏幕底部滑动上来,在任务完成后将其滑走。要注意,过渡过程并未将上个屏幕推走,就像水平导航做的一样,而是将其盖住,因此在此模式完结后它仍应在原位置。用户对那种类型的过渡会认识、理解成正常导航操作的临时偏离。其他过渡也许会让用户猜想,他们是不是转到了应用软件的其他地方。请参看第6章,了解更多关于过渡的知识。

3.1.7 浮动框

浮动框是iPad上特定的小组件,乍看起来并不起眼,但作用非凡。它是个矩形的小窗口,指向调用它的对象。但低劣的浮动框会使iPad体验变得烦琐,因为有若干个微妙的理由。
在桌面上你不需要像窗口那样应对它。它无法移动,通常也只有需要的那么大。
它在你需要的时机和位置出现。
只要你完成对它的操作,它会立即消失,要么因为你走完了其微小的工作流,要么你决定不再用它而将它点走。
它通常让你仍处于相关界面的情境里,浮动框的出现不会太干扰你打开前的思绪。
它假定你在实时编辑,并想保存操作,除非手工取消或撤销。点击浮动框让其消失并不会让你放弃掌控。
所有这些功能组合起来,说明采用浮动框是种轻量级的做法。因此,界面可以设计得更“平静”。可以容易地调出、使用某功能,并在用不到时不理它,无需时时都在屏幕上摆放着,所以你会很惬意地采用浮动框(第14章讲述有关平静界面的详细内容)。
另一个关于浮动框的令人兴奋之处在于,它们能够包含自己的画面和导航层次结构,与主应用软件的流向截然相反。你可以将浮动框想象成iPad屏幕上小小的iPhone。这个iPhone有它自己的迷你应用软件,处理大型应用软件的某个方面。浮动框导航可以采用导航控制器、分段控件页签和模态视图。

3.1.8 导航定制

迄今为止,我们已经查看了iOS提供的标准导航方式。倘若你有软件工程的资源来任意支配,则你可以创建所设想的几乎任何导航方案。但要谨慎。许多满足特定需求的应用软件会以聪明、原创的方式呈现某种体验,但不是所有的应用软件都有这种特定的需求。对原本用常规方法就能解决的问题,采取出乎意料的设计会适得其反。为了让自己的应用软件标新立异,而想使用某种聪明、独特的导航方案,则要谨慎(参看第14章关于独特设计的建议)。

3260418f1492cc261b549cff232b71057adba43f

在构思新导航方案时,一定要记住最重要的事情,就是它们要让人感觉空间上有一贯性。常规的导航控制器在用户看来轻车熟路,因为它们很容易就能勾勒出如何实现的地图(这经常称为意识模型)。更深的层次位于右边,较高层次则留在左边。模态视图可从屏幕外滑入,在不需要时滑出屏幕。在iBooks应用软件中,触摸书架上的某本书可以让它面向读者放大,并打开书本;iWork应用软件呈现类似的体验,在点击某个文档时,会把这个文档放大显示,编辑完后再缩小到原始状态。GarageBand做得更形象,它启动时是同样的文档方格,但添加了各种各样的乐器,还有垂直旋转效果的音轨概览。(请参看图3.6所示的GarageBand导航方案地图。)
即使用户从来不有意识地考虑应用软件的意识地图,但若违反了这个意识地图,用户就会耽误时间。所以在屏幕画面变化时,要使用顺畅、可感知的过渡,特别是变化很大时。导航空间表现得越简单,就越容易让用户感到稳定而有连
贯性。

相关文章
|
缓存 iOS开发
iOS启动画面不更新的问题
iOS启动画面不更新的问题
132 0
|
设计模式 前端开发 iOS开发
iOS设计模式
iOS设计模式
124 0
|
存储 jenkins 持续交付
自己动手设计一款iOS自动构建发布工具
自己动手设计一款iOS自动构建发布工具
281 0
自己动手设计一款iOS自动构建发布工具
|
iOS开发
iOS头部渐变的表格视图设计(二)
iOS头部渐变的表格视图设计
109 0
|
iOS开发
iOS头部渐变的表格视图设计(一)
iOS头部渐变的表格视图设计
104 0
iOS头部渐变的表格视图设计(一)
|
iOS开发
设计iOS中随系统键盘弹收和内容文字长度自适应高度的文本框
设计iOS中随系统键盘弹收和内容文字长度自适应高度的文本框
171 0
设计iOS中随系统键盘弹收和内容文字长度自适应高度的文本框
|
开发工具 git iOS开发
iOS简易蓝牙对战五子棋游戏设计思路之一——核心蓝牙通讯类的设计(二)
iOS简易蓝牙对战五子棋游戏设计思路之一——核心蓝牙通讯类的设计
197 0
|
算法 iOS开发
iOS简易蓝牙对战五子棋游戏设计思路之一——核心蓝牙通讯类的设计
iOS简易蓝牙对战五子棋游戏设计思路之一——核心蓝牙通讯类的设计
136 0
|
存储 开发框架 C#
iOS数据持久化之二——归档与设计可存储化的数据模型基类(二)
iOS数据持久化之二——归档与设计可存储化的数据模型基类
194 0
iOS数据持久化之二——归档与设计可存储化的数据模型基类(二)
|
存储 iOS开发 开发者
iOS数据持久化之二——归档与设计可存储化的数据模型基类(一)
iOS数据持久化之二——归档与设计可存储化的数据模型基类
140 0
iOS数据持久化之二——归档与设计可存储化的数据模型基类(一)