交互与延伸

三、交互

交互设计是一个指向目标明确，同时实现方式多样的领域（即条条大路通罗马）。也就是说，好的交互设计没有标准答案，但评判一个交互设计的好坏也很容易：能否满足使用者心理模式和行为模式上的需求。所以，在评判一个交互设计的时候，交互设计本身的逻辑和体验者的习惯起点都是同等重要的影响因素。交互设计本身的逻辑会在下文详细展开，使用者的习惯起点也需要在开始的时候交代清楚，即笔者是一枚三年多的的iOS（7、8、9、10四代）和曾经的原生Android 4.5和5用户。

总体而言，以用户导向的交互设计理念出身的MIUI和以设计师导向的出身的Flyme，现在都谈不上纯粹由用户导向，或者纯粹设计师导向了。由此造成的状况是，二者在交互上有了更多的重叠，但依然彼此保持各自的特色。

a、唤醒与解锁

进行对比的两部机子都有实体的home键，两个ROM都可以通过home键和电源键进行唤醒，并无区别。与此同时，Flyme还可以通过双击息屏来唤醒（不排除是Pro 5的特性），使用起来体验不错。MIUI无此功能，不过同样在息屏状态中双击音量下，可以快速呼出相机，挺有用的一个设计。

在解锁界面，两个ROM都是上划解锁和下滑进入通知栏。不过，Flyme左右滑动都无反应，其相机与iOS 9及之前的iOS一致，需要向左上滑动呼出，而这种设计在使用时候需要使用者投入更多注意力，更精准的操作才能实现，不是一个很好的交互，用例不多（在iOS中更多通过解锁进入后，上划菜单进入）。

MIUI左划可呼出相机，右划可呼出小米家，与当前使用的iOS 10更接近，用起来也更为方便 。

b、主屏呼出与返回呼出

主屏键和返回键是两个类似、但有区别的Android特色交互。这两个交互是Android中最基本，也是各个ROM实现方式最多样的地方。在开始对比两个ROM之前，先从原理上来来对主屏键和返回键进行定义和区别，以便于更好理解和评价两个ROM的交互设计 ：

在Android中，当按下Home键，默认情况下stop前台的actiity，即activity设置成onstop，而不是ondestory。如果再次启动该activity不是调用onCreate，而是调用onSavedInstanceState方法，保持上次Activity的状态则是从onRestart开始->onStart->onResume。而当按下back键则不同，back键默认finish前台的activity，即activity的状态为onDestory为止，再次启动该activity则从onCreate开始，不会调用onSavedInstanceState方法。Android返回键与Home键区别

具体而言，在主屏呼出方面，Flyme和MIUI都依靠实体home键来实现，二者的home键也都有两个层次，即「轻触」和「按下」。其中，两个ROM的「按下」都是主屏呼出功能；而Flyme的「轻触」是返回呼出功能，MIUI的则依然是主屏呼出功能。两个ROM「按下」主屏呼出的设计基本与通常（Android与iOS）的交互设计相同，不过MIUI的「按下」则是可用户定制的，其余的功能如下图所示。Flyme的「轻触」返回呼出后文会提及，MIUI更希望用户以「轻触」的方式来进行主屏呼出，这对于我来说需要一定的习惯调整的时间。

返回呼出方面，Flyme只依靠了home键的「轻触」，MIUI则依靠在home右侧的半虚拟返回键实现。Flyme的实现方式虽然与我之前的使用习惯不同，但用起来也很舒适，甚至都希望iOS能借鉴。

c、多任务管理

多任务管理也称为后台管理，主要解决不同应用间的切换和后台应用处理的问题。多任务管理是各类交互里最考验交互设计功力的部分。其既涉及设计逻辑，也涉及动画表现，充分表达了交互设计的整体思路。

Flyme和MIUI的多任务呼出区别明显，Flyme依靠从屏幕最下方向上滑动呼出。MIUI则是依靠点击home键左侧的半虚拟键来呼出。

就呼出方式而言，MIUI的学习成本更低，Flyme存在一定的学习成本，没有提示是很难想到这种方式的。但就使用体验而言，Flyme明显好于MIUI ，不论是操作的流畅性，还是动画的效果，Flyme都做得相当不错。不过之所以偏爱这一功能，也可能是因为在iOS中养成的底部上划呼出习惯。

后台应用的处理方面，Flyme索性就将卡片式的特性发挥得淋漓尽致，通过进入后台界面后，上下滑动来切换不同应用，左右滑动当前显示最大面积的应用来进行后台停止；MIUI则是进入后台界面后，左右滑动来切换，上下滑动来进行后台停止。两个ROM在这一部分逻辑类似，但MIUI小家子气的动画使得我难得喜欢 。

d、桌面搜索

两个ROM在搜索的交互设计上几乎是一样的，区别仅在于平面设计。

首先，两个ROM都可以进入桌面后上划来呼出搜索。其次，搜索交互都有三个层次，无搜索、瞬时搜索和键入搜索三个状态。其中，瞬时搜索是指在介入了文字后，点击搜索按钮（或回车键）前，搜索页面自动弹出的状态；键入搜索是指点击搜索按钮（或回车键）后的状态。

再次，三个状态的内容也较为类似。无搜索都是新闻热点+常用应用（MIUI外带一个搜索历史）。瞬时搜索则以本地应用搜索为主，因为Apple拥有系统全局搜索的知识产权，所以Android的本地搜索也仅止于通过应用名称，来查找本地有什么应用，无法对应用内的内容进行搜索。就日常使用来说，全局搜索确实很实用，特别是iOS 9移植spotlight入iOS，将api开放给第三方之后，搜索也成也我使用频率最高的几个app之一。

至于键入搜索，两个ROM都是接入网络搜索，但在点击搜索结果后，Flyme直接在搜索内建浏览器打开，MIUI则跳出接入其他浏览器的提示。因为，两个网页搜索都是默认百度搜索，切不可更改，故不用。

e、其他交互

以下是两个ROM并不都有的一些交互设计，大致罗列一下。

Flyme的悬浮球

Flyme 5的悬浮球是个相当不错的交互设计。开始还以为是对iOS中AssistiveTouch的模仿，但后来发现，它的实现程度和有用程度都比iOS的强。

首先，Flyme悬浮球的尺寸比AssistiveTouch小。我之所以不用AssistiveTouch的一个重要原因在于其太大了，不论多大的屏，都会碍手碍脚。与此相比，Flyme悬浮球则很适合，既不会找不到，也不会妨碍屏幕操作。

其次，在操作逻辑上，Flyme悬浮球只有一层，即可以直接对这个白点进行操作，并且只有轻点（返回键）、上（主屏键）、下（通知栏呼出）、左（上一个应用）、右（下一个应用） 五个基本的交互功能（当然，也能进行定制）；AssistiveTouch则有两层，只有点击第一层后才能进入功能界面，这也是另一个不用的原因，操作逻辑太长。

MIUI的通知栏

通知栏已在上一篇里说过，在这主要吐槽一下它的一个交互设计细节。MIUI通知栏的消息左划出现对应用的禁止，左划才是消除通知。尽管可以理解这一设计是因为MIUI想缩短交互逻辑层级，但想消除一个应用的一条通知，与禁止一个应用的通知功能的使用频率差距，对于一个用惯了左右滑动都是消除信息的我来说，实在很大。

语音

两个ROM都有语音助手这个交互，但他们现在的实现程度和我现在的使用程度，都还只能归到其他类。Flyme 5的语音助手「小溪」和MIUI的语音助手「小米」都是依靠科大讯飞的技术，理论上两个的区别不大，实际试用后，也区别不大。

四、生态

随着手机市场硬件销售进入红海，从硬件设备的盈利已经越来越难，各个硬件厂商对于ROM的重视和投入也越来越大，不同ROM之间的水平区别也在缩小。在这一前提下，如何凭借ROM来实现新的盈利，基于ROM发展的生态也就愈发重要。对于用户来说，一个ROM也许只是一些美学和习惯上的考量，可以随时刷机换其他ROM。但由ROM衍生的生态产品，则是可以实实在在抓住用户，给用户提供附加价值的东西。

a、移动支付

移动支付作为当前最具增长潜力，对于用户便利性最大的领域，已经成为各个OS和ROM试水的领域。不过，依赖银联系统的ROM移动支付需要面临一个重要的问题：

移动支付市场上，银联很弱势，而支付宝、微信支付则占有极大的市场份额。支付宝市场占有率是63.41%，财付通（包括微信支付和手Q）则为23.03%，银联占0.69%。

尽管如此，自Apple pay登陆中国后，各种要做 X pay的新闻不绝于耳，然而到目前为止，推出支持银联的线下支付系统的也就2、3家吧 。在我看来，线下支付方案之所以还没有如各种ROM中的应用商城一样如雨后春笋涌现，是因为线下支付方案考验的是一个ROM背后的公司，在公共关系能力和公共影响力方面的能力。

不过就当前各种 pay的表现而言，与银联和各个商业银行的合作已经有一定的套路和基础，不远的将来这方面出现更多合作者的可能性也很大。而支付方案中对于市政服务卡的支持能力，则是区分当前各种pay的主要标志。一方面，与市政服务卡相关的是高度行政相关的领域；另一方面，对于用户来说，基于银联的各种pay在日常支付场景已经不敌支付宝、微信了，要想用起各种pay，似乎只有找支付宝、微信还没触及的领域。根据这一思路来看的话，现在能刷北京公交一卡通的，只有小米 pay！！ （这也是小伙伴买它的原因！）。

就实际体验而言，MI pay不论是一般银行卡支付，还是公交卡支付的实现程度都是不错的，除了一次因为升级导致NFC没有默认在小米支付频道，而导致刷不出公交卡外 ， 基本没有在滚滚人流中，耽误后面的人的情景。

至于魅族的支付方案，除了前些年吵过mPay外，现在基本处于停滞状态，既没有一般银行卡支付，公交卡也只停留在深圳（感觉每个有NFC功能的主流手机品牌都支持）。

（未完待续）