6.6.3 应用的细节

为了能够在X公司的iPhone应用中实现更加合理的内容浏览机制,你决定首先从他们的桌面应用入手,进行更加细致的分析。经过一番实际的使用,你发现,在桌面应用当中,内容被划分为十个主类别,其中每个类别之下都有十个左右的子类,而每一个子类当中又包含着若干独立的内容对象。整个系统当中大约有几千个内容节点。

桌面应用中的交互模型是很容易理解的。它会向用户呈现一个网格状的选项列表,其中每个单元格都对应着一个内容主类别。选择了其中的某个主类之后,整个列表会被刷新,这个主类所包含的子类会依次填充到每个单元格当中。继续选择其中的某个子类,整个列表会再次刷新,并且被这个子类所对应的内容对象重新填充。这些内容对象通常可以填满多个界面,你可以不同的界面中切换浏览。

另外,这款桌面应用在导航方面做的不是很理想。用户必须至少进入到子类列表界面之后才能发现一个所谓的全局导航,而且当你深入到内容层面之后,会发现这个导航只能帮你回到顶级的主类列表界面。另外,在内容层面当中缺乏必要的上下文指示,用户很难发现当前的内容对象从属于哪个子类。

在你对这些流程进行实际体验的时候,要记得将自己的观察和想法及时地记录下来。这些记录也许会对交互模型的创建起到重要的指导作用。正像我们在列表模型改造练习当中了解到的,某些在表面看来无关紧要的零星想法,却有可能被扩展成为很有价值的交互概念。在某些情况下,你完全可以将那些从观察记录里归纳出的想法加入到交互模型文档当中。

根据当前案例的实际情况,你有针对性地在内容层级结构这方面做了特别的记录与分析;这些信息将对交互模型的构建方案产生决定性的影响。目前,我们对于内容结构的理解大致是这样的(见图 6-15):

《iOS Wow Factor》全书译文精选

图 6-15 X公司桌面应用当中的内容结构

桌面应用的交互模型当中有一个很严重的问题。正如我们在前文当中了解到的,当用户处于内容层面的时候,必须首先通过全局导航回到主类列表界面,才能再次进入子类列表界面或是某个子类当中的内容对象列表界面。而这只是众多问题当中的一个。你现在还不清楚桌面应用当中的这种网状模型能否适用于iPhone的用户体验模式。

既然我们已经在之前的练习中打造过一个网状模型,那么不妨试着对这个概念进行再利用,并且将我们先前定义好的交互机制运用到当前案例的信息结构当中。(见图 6-16)。

《iOS Wow Factor》全书译文精选

图 6-16 在网状模型中,从主类列表界面导航至子类列表界面

由于具有几乎相同的网格结构,这个交互模型与X公司的桌面应用在体验方面是具有很大相似之处的。对于那些已经熟悉了桌面应用的用户来说,这是好事。不过毕竟,这种模型在小屏幕设备当中受到的空间局限还是很大的。在iPhone当中,我们最多只能使用3行3列的网格,而在桌面应用中,网格可以达到10行15列,具体的列数还会随着显示器的规格不同而变化。

正像我们之前在模型改造练习当中定义过的,用户可以通过双指张开的方式展开网格单元,也可以直接点击单元格进入下层结构。不过在当前的案例中,我们要降低第一种方式当中的那个状态阀值,使系统在接收到双指张开的手势之后,能够立刻将单元格进行扩展,直至全屏状态。

这个交互过程中的关键要素就是单元格在展开时所表现出的过渡动画效果。我们希望给用户带来一种感觉,仿佛每一层界面都是嵌套在上一层界面当中的一个网格单元里的;当用户使用双指对某个单元格进行展开操作的时候,可以看到下层界面正在从格子当中呈现出来,并随着单元格的扩展而填满全屏。这种视觉交互效果可以准确地体现出这款应用的信息组织方式,而且对用户来说,这种交互模式也是非常直观的。

遗憾的是,这个模型当中还存在一些弊端,例如回到上层结构的导航方式问题。使用相反的操作手势,也就是双指捏合的方式进行回退操作是具有一定的可行性的,但是对于内容较为复杂的界面来说,这种交互方式的视觉效果缺乏干净利落的感觉。所以,网格模型的概念也许可以在某些特定的需求当中发挥其真正的潜力,但它似乎不适合当前案例中的应用。可以说,这种交互模型的扩展性并不是很强,我们无法将它很好地运用到一些常见的需求当中。

另外,这个交互模型是一种典型的双手解决方案,用户必须一手持机,同时使用另外一只手进行相关操作。这种交互方式本身谈不上不好,但是考虑到最终产品所处的移动上下文环境,这并不是一个很理想的模式。

对于当前的案例,有没有其他更加适用的交互模型呢?让我们回过头来重新思考一下常规列表的可能性。传统的单列纵向列表非常便于单手操作,而且很适合用来展现层级化的信息结构。这种特性几乎使其成为了iPhone当中最具普遍适用性的导航方案。不过也正是因为它的适用性太强,所以通过这种方式打造的交互方案通常会缺乏足够的创新性。有什么办法可以帮助我们以全新的方式来使用传统的列表模型呢?

在之前的练习中,我们曾经对单列纵向列表进行过天马行空般的改造,这次,我们不妨在保持标准列表原貌的基础上寻求一些局部当中的改进方法。在实际产品中,我们不能仅仅为了标新立异而刻意吹捧差异化的原则,尤其是不能在还有相关问题没有得到解决的情况下片面地采用并不适宜的方案。在当前的案例中,网格模型不能很好地帮助用户实现回退方面的导航功能,而且不便于单手操作。另外,正像我们在前文当中提到的,目前的桌面应用当中还存在着其他方面的问题,例如在内容层面当中缺乏必要的上下文指示,用户很难发现当前的内容对象从属于哪个子类,而且当你深入到内容层面之后,只能通过现有的导航机制回到顶级的主类列表界面等等。接下来,我们将致力于打造一个能够解决所有这些问题的新模型。

《iOS Wow Factor》全书译文精选

图 6-17 拥有独特交互方式的传统单列纵向列表。用户可以在某个列表项中向左轻扫,使原本处于隐藏状态的二级列表结构呈现在这个列表项当中。

这个解决方案第一眼看上去很普通,也很容易理解,它似乎就是一个内容类别列表。然而这个模型在很多方面都与iOS当中的标准列表有所区别。用户在前两层信息结构当中进行导航操作的时候,整个列表的视图模式是不会发生变化的。当用户选择了某个主类之后,对应的子类列表会直接出现在这个主类所在的列表项当中。这个过程所涉及到的状态变化只会发生在当前列表项的可视区域里。用户可以在这个列表项区域当中通过上下滚动的方式来浏览子类列表,而当前区域以外的部分则始终保持不变,也就是说,用户无需离开当前界面就能随时访问其他主类当中的子级分类。

我们可以让用户通过向左轻扫的方式将子类列表“拖入”主类所在的列表项可视区域当中,也可以让他们对某个其他位置上的目标对象进行相关操作,来触发某种动画效果,使子类列表移入可视区域。你可以对各种方式进行构思和尝试,并从中找到一种操作体验最自然的、误操作几率最低的来加以使用。

这种交互模型在导航和浏览方面的效率很高,用户可以在同一个界面当中同时查看两个层面的信息。不过这里同样存在一些很明显的问题,例如子类列表会被局限在一个非常有限的可视区域当中,用户一次最多能完整看到一到两个条目。另外,这种模式本身只支持两个类别层面之间的导航,要查看最终的内容对象,我们还需要使用另外一个模型将内容完整的呈现在屏幕当中。所以,这种模式也难以很好地适用于当前的案例。

我们希望找到一种新的方式,它即可以沿用上面这种模型在导航方面的灵活性,同时又能使内容具有更好的可读性。另外,在上面的模型当中,主类条目的表现形式以及对有效空间的占用率也可以得到适当的优化。需要记住,这款应用的核心需求当中要求我们提供一种快速高效的机制,以帮助用户更好的浏览内容。我们对于交互模式的思考必须围绕着这个中心思想进行展开。

我们继续在列表的概念上做文章,不过这次,我们可以试着为列表增加一些不同的属性,使阅读方式更具流动性。如下图所示,这种模型当中不存在彼此分离的视图状态变化,它是一种连贯的、更具动态化的解决方案,而且对用户的交互行为具有更好的响应性。

《iOS Wow Factor》全书译文精选

图 6-18 该模型将主类与子类列表整合到同一个层面中,使浏览更加迅速。用户可以通过纵向滚动来浏览主类列表,在某个主类当中通过横向滚动来浏览子类列表。

这个交互模型与之前的那些有所不同。初始状态下,界面为导航结构和其他功能保留了一定的空间。说到这款应用当中的其他功能,我们并没有进行过相关的描述,因为对于当前的案例练习来说,那些细节问题并不重要,我们的主要目的是站在一个较高的层面上,构筑整个产品的核心体验模式。所以目前,我们只需要将注意力放在与内容的导航与浏览相关的交互模型上就可以了,因为这些方面才是整个产品的基础与核心。

最初,这个模型只会呈现出一部分主类导航项。每个主类都以文字标签的形式出现,用户无需任何操作即可直接获得子类列表当中的分类信息。这种二维导航结构可以帮助用户以非线型的方式在同一个层面中浏览原本属于不同层面的信息。

要查看更多的主类以及它们对应的子类列表,用户只需执行纵向滚屏操作。当主类列表接触到屏幕的上边缘时,排在最前面的几个主类条目就会自动收起,以便为后面的留出显示空间。在这个过程中,用户不需要进行任何控制,纵向滚屏这个操作本身就会触发这种类似手风琴风箱折叠一样的效果。

要查看某个子类当中所包含的内容对象也是很容易的。当用户在默认视图中选择了某个子类时,界面会过渡成为一个新的网格内容模型,这个模型即可以像默认视图那样对内容进行分类呈现,同时也支持没有文字标签的单列网格单元(见图 6-19)。要查看某个内容对象,用户只需要点击横向列表当中的某个单元格,内容对象就会扩展至全屏。

《iOS Wow Factor》全书译文精选

图 6-19 子类列表视图。在横向的内容对象列表当中点击某个单元格,内容对象就会扩展至全屏。

在这个模型当中,我们可以将用于回退的导航控制元素放在界面顶部。这个控制元素既可以是一个简单的返回按钮,也可以是相对复杂的类似面包屑的形式。最重要的是,相比于之前的几个模型,这次我们终于能够以一种比较合理的方式来实现导航控制机制了。

可以说,这是到目前为止我们能够找到的最佳解决方案了。你可以将这套方案落实在交互文档当中,并直接通过这个文档向X公司的相关决策人员及团队做以讲解,引导他们站在用户的角度去理解这款模型的出色之处。从这个交互模型当中,他们也能很直观地体会到这款应用与竞争对手的产品相比所具有的创新性。你完全不用花费时间去打造线框原型、视觉稿或是高保真原型来完成这项工作

对交互模型的创建过程进行了完整的了解之后,你还可以沿用在这个案例当中学到的方法,继续通过其他产品概念进行练习和尝试,看看能否从中得到一些新的感悟。