交互手势全解析之描述维度.docxVIP

交互手势全解析之描述维度 交互手势的描述维度是什么？在这里我们将其简单定义为影响一个交互手势呈现效果的变量。 在之前的文章中，提及过的描述维度包括稳定化效果、控制方式、阈值类型、时间限制、按下次数、触发时机，但它们的都是一些较为显性的描述维度，确定了某个手势的基本框架。 本文主要讲解之前未提到的较为隐性的描述维度，它们同样影响着用户的操作体验，包括角度与方向、反馈比率、热区。下面将逐一介绍。 一、角度与方向 角度与方向的知识在「交互手势全解析之位移类手势」中简单地讨论过一些，在这里会讲解地更详细。 位移类手势的方向一般为上下方向或左右方向，或者二者兼有之，但是想要触发操作，手指移动方向并不需要完全垂直或水平，默认会有一个容错角度。 当某个界面或模块仅支持上下方向或左右方向的位移类手势时，如下图所示，360度会1：1均分，每个方向有180度的容错角度，只要在角度范围内滑动，都可以触发相应操作，但需要注意的是在仅支持上下方向滑动时，如果完全水平方向去滑动，则不会触发任何操作，反之亦然。 虽然说角度的容错范围很大，但是滑动时离预期方向的角度偏离越大，单位长度产生的有效位移距离就会变少。例如下图中，在一个只能上下滑动的页面，垂直上滑和偏移上滑相同距离产生的有效位移是不同的，垂直上滑的效率明显更高。 当上下滑动和左右滑动同时存在于一个页面或模块时，会出现两种情况。第一种情况是被滑动的内容除上下左右外可以往更多方向移动，例如滑动照片或地图查看更多细节（如下图所示），是允许用户自由地朝任意方向滑动的。 第二种情况是，在单次操作中，只有上下或左右方向的滑动需求。360度会1：1：1：1均分，每个方向有90度的容错角度。在这种情况，上滑时手指滑动方向只要左右偏移不超过 45° 都会被判定为上滑，如下图所示。 对于这第二种情况，系统需要处理以下两个问题。 问题A：如果在上下滑过程中进行左右滑动的操作，系统如何判定？ 一般我们是不希望用户在一次操作中同时进行上下滑动和左右滑动的。系统如果判定某次滑动为上下滑动，为了避免误操作，在本次滑动结束前（滑动结束的定义：手指离开屏幕并且受控物停止移动或停止其他属性变化），左右滑动会被完全禁用，而且左右滑动的容错角度会临时分配给上下滑动，如下图所示。 例如，在iOS信息列表中，左右滑动可以唤起更多操作，上下滑动可以滚动页面，但是一旦进入上下滑动的过程中，不松手的情况下左右滑动唤起更多操作就被完全禁用了，且左右滑动的容错角度会临时分配给上下滑动。 问题B：系统是如何在某一次滑动时判定我们是想要上下滑动还是左右滑动呢？ 系统给予我们自然的使用体验背后是复杂的判定过程。判定的难点有两个，第一个难点：手指在操控屏幕时并不是一个稳定的状态，接触屏幕的一瞬间很容易抖动。抖动的方向也是不确定的，这个抖动需要判定为滑动吗？如果用户并不想滑动只是想进行点击操作的话怎么办? 第二个难点：手指在接触屏幕后，接触屏幕的手指面积是逐渐增加的，但向下的增加要比其他方向的多，如果直接识别的话会被判定为下滑，应该怎么处理？ 下图的动画是慢速模拟手指接触屏幕的过程。 为了解决上述的两个难点，系统会设定一个容错距离，用户的滑动位移如果在这个距离内，系统就会把手势判定为“点击”，只有当用户往某个方向的滑动位移达到或超过这个距离，系统才会判定为“滑动”。但是由于这个容错距离很小，作为用户的我们去操作时，是很难感受到这个容错距离的存在的。 基础规则讲完了，接下来针对第二种情况介绍一些负面案例，下图左是滑动前正常的角度分配，但是有时由于开发同学的失误，导致容错角度没有均分，出现下图右中触发上滑和下滑的角度极小的情况，进而导致用户在上下滑动时非常容易误操作为左滑和右滑。 网易云音乐也曾有过类似的遗留问题，iOS 端的播放页上滑调出评论页极易误操作为左右滑动黑胶切歌（下图 A ，现已修复），安卓端的账号侧边栏上滑浏览极易误操作为左滑收起侧边栏（下图 B ）。 因此，在验收阶段，角度的容错性检查也是重要的一环。因此在验收时间充裕的情况下，可以切换不同的手持方式分别体验一次，因为有些问题只有在特定的手持方式下才容易被发现。 二、反馈比率 之前提到过施控物（施加控制的一方）和受控物（被施加控制的一方）的概念。比率是受控物的某个属性变化与的施控物某个属性变化的比值。为了更好地理解这个概念，在这里举个例子。 如下图，在网易云音乐的播放页和微信小程序页面边缘右滑一个固定距离时，页面的下降距离是不同的，网易云音乐播放页的下降距离大约只有微信小程序页面的一半，我们可以认为对于这个交互，网易云音乐的反馈比率是微信小程序的一半。 比率的大小并没有绝对的优劣之分。比率越小，反馈越迟钝，但方便精准操作。比率越大，反馈越灵敏，效率高，但不方便精准操作。由于比率的这些特性，在不同的场景