时间: 2021-07-30 10:11:05 人气: 15 评论: 0
编辑导读：手势作为图形界面与用户之间沟通的方式之一，在便携电子设备上大量应用。位移类手势是指代那些通过手指接触屏幕后的位置变化从而操控电子设备的手势，本篇文章主要讲解单指操作的位移类手势，与你分享。
一年前更新了文章《交互手势的容错性和逻辑性》之后，有很多读者朋友询问是否能够做一个详细的讲解交互手势的系列文章，讲解每个手势的不同之处、应用场景以及在工作中如何使用。我非常理解这些读者的痛点，因为我在日常的工作中，也经常遇到一些难题。
比如同样是滑动，但是些许参数的变化就**导致体验的天差地别，应该如何进行选择。再比如与开发同学沟通过程中如何准确描述自己想要的效果，让最后的结果不至于与自己的预期不一致。这些难题也促使我大量思考，大量体验各种产品的手势操作，希望能够从中总结出规律，让手势的设计与落地能够有理有据。
现在经过一段时间的积累，我认为我在这方面可以讲一些能够帮助大家的内容了。不足之处，希望大家指正。今天给大家带来专栏的第一篇《交互手势全解析之位移类手势》。
手势作为图形界面与用户之间沟通的方式之一，在便携电子设备上大量应用。与实体按键相比，它有着纯粹的简洁性和无尽的创造性，手指的个数变化、不同变量的组合能够创造出无数的操控方式。
位移类手势是指代那些通过手指接触屏幕后的位置变化从而操控电子设备的手势，本篇文章主要讲解单指操作的位移类手势，多指的位移类手势（如捏合）将放到后续文章中讲解。
一谈到位移类手势，大部分设计师的脑海中可能**浮现出拖拽、甩动和轻扫这三个术语。然而，当我们想仔细谈论他们三者之间的区别时，大部分设计师可能无法准确地描述。为了能够准确描述三者的区别，我们在这里引入三个维度的概念，它们分别是控制方式、稳定化效果、以及阈值类型，这三者的不同的变化组合可以创造不同的位移类手势，拖拽、甩动和轻扫之间的区别也是这三个维度影响的。
当我们在讨论不同位移类手势之间的区别时，不如说是在讨论这三个维度之间的区别。比如常见的轻扫手势，因为这三个维度的变化就**产生不同的变种，而且不同变种在体验上也存在很大差别，若不分场景随意使用，很容易就影响用户体验。那接下来我们首先了解一下这三个维度。
第一个维度是控制方式，它分为绝对控制和相对控制，也可以通俗的表达为跟手和不跟手，区别如下。
绝对控制/跟手：施加控制的一方（后文简称施控物）的某个属性变化与被施加控制的一方（后文简称受控物）的某个属性变化是对应的。
相对控制/不跟手：施控物的某个属性变化与受控物的某个属性变化不是对应的。
比如在网易云音乐的播放页（下图左），左右滑动黑胶时，手指是施控物，黑胶是受控物，手指的横向位置变化和黑胶的横向位置变化是对应的，即绝对控制。上滑调出评论页时（下图右），评论页的位置和手指的位置没有对应关系，手指的上滑仅仅控制评论页是否出现，即相对控制。
与相对控制相比，绝对控制允许用户去操控受控物的属性变化过程，因此给予了用户更强的掌控感。比如在微信读书阅读页边缘右滑，手指的横向位置与书籍封面的变化过程对应，模拟现实生活中慢慢合上书的感觉，如下图。
但是在有些场景，为了避免混乱，属性变化过程是不适合被用户绝对控制的，此时我们应采取相对控制的方案。比如 iOS 的相机中，左右滑动切换拍摄模式，由于前后不同模式之间的页面框架变化较大，切换时**有过多元素的属性变化，如果使用绝对控制就**导致切换拖沓且混乱，使用相对控制就能避免这个问题。
1.2.1 定义
当我们使用手势控制某个受控物时，由于手势的某个属性（如手指位移）达到阈值，进而导致受控物的某个属性稳定在了特定状态的效果被称为「稳定化效果」，或者也可以称为「吸附」。
稳定化效果能够保持界面的视觉秩序，避免过多的中间状态导致界面的杂乱，进而帮助用户聚焦信息。
是否有稳定化效果是区别轻扫与另外两个手势即甩动和拖拽的重要维度，当某个位移类手势有稳定化效果，我们就将其称作轻扫。
以滑动切换抖音视频为例，当手指上滑的位移距离和释放速度其中的某一项属性达到阈值后，下一条视频**往上移动到一个固定的位置然后进入稳定状态，而不**出现停留在不完整的中间状态，如下图所示。
在 iOS 端的微信消息页左滑某条消息后**出现更多操作按钮，按钮**在手指滑动的距离达到阈值并松开后稳定在一个固定的大小，而不**停在类似下图左所示的混乱的中间状态。
在多内容选择的场景中，如果滑动与选中是绑定的话，一般需要使用稳定化效果。例如在 iOS 相机里选择滤镜时，滑动滤镜选项不但能够控制滤镜选项的位置，并且**自动选中一个位于中间位置的滤镜，位置的稳定化避免了被选中选项的不明确。
如果滑动与选中是分开的，比如美图秀秀的滤镜选项需要先滑动后选中，这种情况下稳定化效果不是必要的。
1.2.2 与效率的关系
不同的稳定化规则带给用户的体验差异是非常大的，最明显的差异是在效率方面。我们使用稳定化效果的强弱来理解，稳定化效果越强，单次滑动能够切换的选项个数越少，效率越低。稳定化效果越弱，单次滑动能够切换的选项个数越多，效率越高。
比如在比较常见的 banner 切换功能中（下图左），无论手指位移和释放速度的值有多高，banner 只能切换并稳定到下一个，不能够一次切换多个 banner。而在网易云音乐的首页排行榜中，一次滑动能够切换多个内容卡**。因此，我们可以说前者的稳定化效果比后者强。
拖拽和甩动虽然没有稳定化效果，但是也存在效率的高低。我们可以将其与轻扫放在一起做对比，如下图所示，拖拽、稳定化效果强的轻扫、稳定化效果弱的轻扫、甩动它们切换效率依次增加。
那么我们决定添加稳定化效果后，如何选择强弱程度呢？选择没有绝对的对错，整体来说主要考虑两点，业务诉求和用户诉求。例如在常见的 banner 切换中，banner 的总数量一般不**很多，业务的诉求是希望尽可能曝光每一个 banner ，使感兴趣的用户进行消费，因此这里比较适合做稳定化效果强的轻扫。在云音乐的排行榜案例里，不同用户感兴趣的榜单是不同的，稳定化效果弱的轻扫可以方便用户单次滑动切换多个，快速切换到自己感兴趣的榜单的大概位置。
百度 App 的表情面板原本是左右轻扫浏览表情，在一次改版中改为了上下甩动浏览。主要目的之一就是为了提高浏览效率、降低非首屏表情的曝光难度。
微信视频号的改版是一个典型的案例，旧版的微信视频号的视频流并不是类似抖音那样的全屏化形式和轻扫手势（下图右），而是占据屏幕尺寸三分之一到二分之一之间的卡**形式（下图左），并且使用甩动而非轻扫。视频号问世初期优质内容匮乏，社交推荐算法不完善，贸然模仿抖音式的全屏化形式和轻扫手势的话，**导致用户浏览到劣质视频时负面感受被增强且切换效率变低，反之卡**形式加甩动手势给予了用户更自由的选择空间，提高了用户的切换效率，降低了负面体验。等到如今时机成熟，再从卡**形式和甩动手势换成全屏化形式和轻扫手势就势在必行了。
在某些场景，用户需要先通过高效的方式选择特定区域的内容，然后进入聚焦状态进行内容浏览和慢速的切换，此时我们需要设计两种切换效率不同的手势应对前后场景的变化。如下图，在 iOS 的照** App 中，先使用切换效率较高的甩动进行粗略切换找到目标图**大概位置，点击进入大图模式时使用切换效率较低的轻扫进行精确切换查看。
1.2.3 触发时机
触发稳定化的时机可以分为释放前和释放后，不同的时机带给用户的体验也不同。释放前稳定化指的是用户使用手指滑动屏幕时，手指位移达到阈值后，手指无需离开屏幕，稳定化即可被触发。如下图左，iOS 的相机滑动切换滤镜使用的就是释放前稳定化。释放后稳定化指的是用户使用手指滑动屏幕时，手指位移或释放速度达到阈值后，手指必须离开屏幕，稳定化才能被触发。如下图右，常见的 banner 切换。
释放前稳定化可以避免拖沓，增加切换效率，但是缺点是无法反悔回退且缺乏掌控感。反之，释放后稳定可以反悔回退，掌控感强，但是缺点是比释放前稳定化拖沓了一些。
阈值是能够触发变化的最小值。比如当水的温度达到 100 度时就开始变成水蒸气，100 度就是一个阈值，温度是阈值类型。在手指与屏幕的交互中，手指在屏幕上的某个停留时间、位移、释放速度、点击次数等都可以成为一个阈值类型，达到相应阈值后就可以触发相应的变化，常见的变化有受控物的位置、大小、不透明度等，**上变化可以是任意的。
在位移类手势中，通常**用到的阈值类型有手指位移和释放速度，手指位移是用户在手指触摸屏幕时的位置与之后某个时间手指位于屏幕的位置之间的距离，释放速度是用户的手指在屏幕表面进行位移后离开屏幕那一瞬间的速度。
市面上的 App 暂时不存在仅通过释放速度判定而与手指位移无关的阈值判定方式，因为其不太符合常识。因此我们在设计位移类手势时，能够选择的阈值判定方式常见的有两种：① 判定手指位移和释放速度满足任意一个即可；② 仅判定手指位移。
当我们设计手势时，就需要考虑两者的区别。由于 ① 比 ② 增加了释放速度带来的额外移动距离，因此 ① 的主要优点是高效。但是由于我们无法预判释放速度带给受控物的移动距离长短，所以相对应的缺点就是易误操作和不精确。②就恰恰相反，由于不存在释放速度造成的不确定因素，它的优点是不易误操作和精确，缺点是低效。
甩动和拖拽之间的区别就在于阈值判定方式，甩动是 ① ，拖拽是 ② 。如下图，当在微信消息列表找相应的消息时，用户的诉求就是能够快速找到特定消息的位置，对特定消息的出现在屏幕的位置也没有特定要求，只要能够被手指点击到即可，因此选用甩动较为合适，但是对于调节音量、亮度这一类的操作，滑动的范围有限，因此用户对效率没有太高的要求，但是对于滑块位置的精确度有要求，因此选用拖拽是更为恰当的。
再举一个反例，在 Steam 移动端横滑首页的泳道卡**时（下图左），使用的手势是拖拽而不是甩动，浏览起来特别低效。更适合的做法应为甩动，**更符合此场景下的快速浏览的诉求，如下图右的豆瓣。
对于轻扫来说，使用哪种阈值判定方式有多种情况（如下图所示）。在本文中，根据阈值类型、稳定化效果以及控制方式的不同我将把轻扫分为 A-E 共 5 类（A-E的命名方式仅存在于本文章，因此在向其他人传达时，尽量使用在后文我介绍的手势描述而不是类别名称，以便于对方理解。）。后续**为大家仔细举例讲解，大家现在仅了解一下即可。
当我们在**抖音视频时使用的手势就是轻扫，是否滑动到下一条视频进行播放的判定方式是① 判定手指位移和释放速度满足任意一个即可，对应的手势类别是上面表格中的轻扫A。如下图所示，在**抖音时，如果使用判定手指位移的方式，我们可以将手指在垂直方向位移大于半个屏幕高度的距离，从而切换到下一个视频。如果使用判定释放速度的方式，我们可以移动任意的垂直距离但是手指离开屏幕时保留一个速度从而切换到下一个视频。大部分情况下用户都**使用判定释放速度的方式，因为既省力又便捷。
如果将阈值判定方式改为 ②仅判定手指位移，对应的手势类别是上面表格中的轻扫 B，并且位移的阈值设置得比较大的话，给用户带来的负面体验可能将是非常大的。比如下图中打开美图秀秀的短视频评论浮层后，想要下滑收起时，App 仅判定手指位移，而且这个位移阈值设置得比较大，对于希望通过快速滑动一小段距离收起浮层的用户来说体验很差。即使由于开发资源有限我们只能做到仅判定手指位移，我们也可以通过减少手指位移的阈值来降低负面体验。
但是某些场景下，②仅判定手指位移是更加合适的。比如想要在微信中下拉打开小程序选择页，就只能通过手指位移达到一个特定的阈值才能够触发，无论怎么用力滑动去增加释放速度都无法打开小程序选择页。这样处理的原因是在微信消息列表页，上下滑动浏览微信消息是一个高频操作，如果释放速度也能作为打开小程序页面的阈值的话，用户可能就极易在下滑消息列表时误操作，无意间打开小程序选择页。
因此，对于位移类手势，选用哪种阈值判断方式要依据用户使用场景和诉求，不能想当然地设计。
了解完三个基础维度后，我们再将其进行组合，从特定手势的角度更全面地理解它们的差异和使用场景。三个维度的排列组合能够生成十余种位移类手势，我列举出了常见的 7 类，如下图所示，这 7 类基本涵盖了 95% 以上的场景，我将一一举例说明。由于施控物控制受控物改变的属性一般都为位置，因此接下来在描述下面手势的定义时我都以受控物的位置变化进行举例。
2.1.1 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，无论释放时手指是否仍有速度，受控物都**立即停止移动。（下图的动态演示由 Principle 制作，观看**有些不太直观，大家可以在文章结尾处下载 Principle 源文件后导入到手机里体验，源文件包含文章提到的所有位移类手势）
2.1.2 特点
精确度高但效率低。由于阈值类型仅判定手指位移且没有稳定化效果，拖拽适用于对操作精度要求高，对效率要求低的功能。
2.1.3 案例
在 iOS 设置中调节亮度时，在有限范围内，手指左右拖拽可以控制亮度变化。
2.2.1 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动。若释放时手指仍有速度，受控物将移动一段距离后才慢慢停止，移动的距离与释放速度呈正相关。若释放时手指速度为 0 ，则受控物立即停止移动。
2.2.2 特点
精确度低但效率高。由于阈值类型判定释放速度和手指位移，甩动适用于需要快速浏览较多内容的场景，如滚动浏览列表。
2.2.3 案例
在微信的消息列表页，使用甩动手势控制列表上下移动，若释放时仍有速度，列表将仍移动一段距离后才慢慢停止。
2.3.1 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动。若释放时的速度和手指位移有任意一个达到阈值，受控物将稳定在一个新位置。若释放速度和手指位移没有任何一个达到阈值，受控物将回到原位置。
2.3.2 特点
由于轻扫拥有稳定化效果，因此它能够保持界面的视觉秩序，避免过多的中间状态导致界面的杂乱，进而帮助用户聚焦信息。接下来讲解的其他轻扫类型都有这一特性，就不一一赘述了。轻扫 A 与接下来要讲解的轻扫 B-E 的最大不同之处在于轻扫 A 的阈值类型为「释放速度和手指位移」，这让轻扫 A 与轻扫 B-E 有两点不同，一是轻扫 A 可以通过释放速度的快慢去控制内容的切换数量的多少，更加高效，二是轻扫 A 可以通过用手指在屏幕滑动很短的距离但离开屏幕时保留一个速度来切换内容，因此更加省力。
2.3.3 案例
在**抖音时，如果使用判定手指位移的方式，我们可以将手指在垂直方向移动大概半个屏幕高度的距离，从而切换到下一个视频。如果使用判定释放速度的方式，我们可以移动任意的垂直距离并且手指离开屏幕时保留一个速度从而切换到下一个视频。
2.4.1 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动。若释放时手指位移达到阈值，受控物将稳定在一个新位置。若释放时手指位移没有达到阈值，受控物将回到原位置。
2.4.2 特点
轻扫 B 与轻扫 A 相比唯一的区别是阈值类型减少了释放速度的判定方式，这提高了触发切换的难度，使操作成本变高，但是在某些场景下，这也降低了误操作的概率。如下拉**新等。
2.4.3 案例
比如想要在微信中下拉打开小程序选择页，就只能通过手指位移达到一个特定的阈值才能够触发，无论怎么用力滑动去增加释放速度都无法打开小程序选择页，这样处理的原因是在消息列表页上下滑动浏览消息是一个高频操作，如果释放速度也能作为打开小程序页面的阈值判定方式，用户可能就极易在下滑消息列表时误操作，无意间打开小程序页面。
因此，当页面已存在一个滑动操作的情况下，还存在另外一个方向相同的滑动操作且仅**在边界情况下才能触发时，为了避免误操作，**将后者的手势设计为轻扫 B 。
上文提到，轻扫 A 的阈值类型为判定「释放速度和手指位移」，轻扫 B 的阈值类型为仅判定「手指位移」，由于前者的实现成本比后者高，导致本应适合做成轻扫 A 的功能有时只能妥协做成轻扫 B ，比如之前提到过的美图秀秀的短视频评论浮层案例，但我们也可以通过减少手指位移的阈值来降低负面体验，后文**讲解如何与开发同学沟通。
2.5.1 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，但是受控物并不随着手指的控制而同步移动，仅当释放时手指位移达到阈值时，受控物才开始移动并稳定在一个新位置。若释放时手指位移没有达到阈值，受控物位置则一直保持不变。
2.5.2 特点
上文讲到过释放后稳定化和相对控制的缺点，释放后稳定化比较拖沓，相对控制让用户缺乏掌控感。两者如果应用到了同一个手势（即轻扫 C ），就**导致用户在滑动屏幕时得不到任何反馈，用户**疑惑是否因为自己操作不当或是设备出现故障。只有当用户手指离开屏幕后才**发现触发了操作，整体的交互流程给用户一种滞后与延迟的感觉。
因此轻扫 C 与其他类别的轻扫相比存在劣势，但是它也存在很多的 App 的 H5 页面中，我的猜测是由于 H5 对于判定释放速度和绝对控制这两个维度与客户端相比难度大很多，因此只能退而求其次选择轻扫 C 这个较差的方案，实际上在同样的应用场景中用轻扫 A 替换轻扫 C 可以带来更好的体验。
2.5.3 案例
下图左是 ** 的个性装扮的 H5 页面，卡**的切换使用的就是轻扫 C ，如果能够优化为轻扫 A 体验**更好，比如下图右的音街首页卡**的设计。
2.6.1 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，但是手指位移达到阈值前受控物并不随着手指的移动而移动。若手指位移达到阈值，无需手指释放，受控物将开始移动并稳定在一个新位置。若手指位移没有达到阈值，无论是否释放，受控物位置则一直保持不变。
2.6.2 特点
相对控制的方式降低了用户的掌控感，释放前稳定化减少了操作的拖沓感。使用此手势的场景是在多个对象之间切换时，我们不希望用户过于自由地操控对象之间的属性变化过程，并且牺牲掌控感从而增加单次的切换效率。
2.6.3 案例
比如 iOS 的相机中，左右滑动切换拍摄模式时，由于前后不同模式之间的页面框架变化较大，切换时**有不同元素的属性变化，如果使用绝对控制和释放后稳定化就**导致切换混乱且拖沓，使用相对控制和释放前稳定化就能避免这个问题。
2.7.1 特殊说明
上文我们讲到，通过轻扫手势 A-D 对受控物的绝对/相对控制都是存在于稳定化前，受控物一旦稳定化，就脱离了手指的控制，需要手指离开屏幕后再次接触屏幕开始下一次控制。
轻扫E的不同之处在于它可以在受控物稳定化后，仍然控制受控物朝着下一个节点稳定化，在每个节点之间切换时能够明显感觉到分段感，如下图案例所示。
由于轻扫E相对于轻扫 A-D 的特殊性，控制方式中的绝对控制和相对控制无法覆盖这个特殊现象，因此我们使用「多段相对控制」来命名轻扫E的这种特殊的控制方式。
2.7.2 定义
使用手指在受控物位置按下后，操控受控物沿着某个方向移动，若手指位移达到阈值，无需手指释放，受控物就稳定在了一个新位置，但是此时手指还是仍然可以操控受控物继续移动的，并且继续移动过程中如果手指位移达到阈值将**到达下一个稳定化状态。
2.7.3 特点
轻扫 E 适用于需要在多个对象之间快速切换和确认的场景，它的使用感觉很接近拖拽。如下图所示，我们可以这样理解，当被切换的对象数量接近于无穷大同时每个对象之间的距离接近无穷小时，轻扫 E 就可以视为拖拽。
2.7.4 案例
iOS相机人像模式切换打光方式、微信的通讯录滑动字母索引导航，它们都使用轻扫 E 来满足多个对象之间快速切换和确认的需求。
了解完上述的维度和常用手势后，我们在脑中就可以形成一个思考框架。当我们要针对一个功能设计位移类手势时，就可以从阈值类型、稳定化效果以及控制方式这三个维度思考。接下来我用一个我参与过的实际项目作为案例给大家讲解一下思考过程。
本案例是网易云音乐陌生人版一起听中的一个功能，一起听的双方在听歌过程中**收到彼此共同信息，比如听歌口味相似度、是否同城、都喜欢哪些歌手等，目的是为了增加可玩性和互动性、降低退出率，鼓励用户互相了解、提高一起听过程中的社交体验。
为了营造仪式感和避免信息过载，共同信息的展示方式设计为了一次只能看一条，进入浮层后默认展示最新的一条，可以通过滑动查看上一条。因此为了避免出现两条同时占据展示区域的混乱状态（如下图左），我们为其添加了释放后稳定化效果（如下图右），同时为了方便用户可以快速浏览旧的共同信息，这里使用的稳定化效果是较弱的，用户可以通过滑动一次切换多个共同信息。
由于需要满足用户快速浏览旧的共同信息的诉求，阈值类型选用了「判定手指位移和释放速度满足任意一个即可」，用户可以通过控制释放速度进而控制信息的切换数量。控制方式则选择了掌控感强的绝对控制。最后的结果如下图所示。综合三个维度进行归类，此手势为稳定化效果较弱的轻扫 A 。
位移类手势的方向一般为上下或左右，但并不是一定要完全垂直或水平才能够触发手势。当上下滑动和左右滑动同时存在于一个页面时，默认**有一个容错角度，比如上滑时手指滑动方向只要左右偏移不**过 45° 都**被判定为上滑，如下图所示。
但是有时开发同学出现失误，导致容错角度没有均分，例如下图中触发上滑和下滑的角度极小，导致用户在上下滑动时非常容易误操作为左滑和右滑。
云音乐也曾有过类似的遗留问题，iOS 端的播放页上滑调出评论页极易误操作为左右滑动黑胶切歌（如下图 A ，现已修复），安卓端的账号侧边栏上滑浏览极易误操作为左滑收起侧边栏（如下图 B ）。
因此，在验收阶段，除了上述的三个维度外，角度的容错性检查也是重要的一环。因此在验收时间充裕的情况下，最好要切换不同的手持方式分别体验一次，因为有些问题只有在特定的手持方式下才能够被发现。
客户端的角度判定方式实际上是一个比较复杂的过程，上述的内容是简化的版本。后续将延展为一篇独立文章给大家仔细聊一聊。
上文讲到，基础的三个维度即阈值类型、稳定化效果和控制方式决定了手势的类别，是设计阶段一定要定义清楚的。但是除此之外，设计一个手势需要定义的细节非常多。比如受控物的移动是否有速度曲线？手指位移与受控物之间的位移的比率是多少呢？这些都是开发阶段不得不面对的。幸运的是，安卓和 iOS 有系统封装好的一套系统组件可以调用，操作系统自行解决了刚才讲到的细节问题，但是 H5 框架下是无法调用系统组件的，手势的各种细节都需要前端开发人员自己编写，难度较大，大部分情况只能实现一些比较简陋的效果，这也是为什么在很多 H5 框架下的界面滑动的体验比较差的原因。
由于信息不对称，与开发的沟通过程中，很容易出现理解偏差。比较常见的错误有：将甩动误解为轻扫 A ，将轻扫 A 误解为轻扫 B 或甩动。如果造成效果达不到预期的情况，很多设计师不知道如何让开发同学修改，只能说“这个手势不丝滑，优化一下”，开发同学也是一头雾水，不知道往哪个方向优化。如果我们能够直接说出“阈值判定方式现在只有手指的位移，需要释放时的速度也能够触发跳转；这个位移的阈值太高了，滑动时很难触发跳转，需要把阈值改为 16pt ”类似这样准确的描述，就能够大大降低沟通成本，顺利验收。为了避免沟通出现问题，下面我将日常经验总结出现希望能够帮助到大家。
首先，一旦涉及到位移类手势，除了必要的文字描述外（可参考上述的手势定义的描述），最好给开发体验 demo 或者其他 App 上类似的效果，否则很容易产生理解偏差。各种 App 上的类似效果大家可以用本文的每个手势的案例给开发同学展示，但是 App 可能**更新，案例可能在未来某个时间就找不到了，所以我用 Principle 做了一个简易的基础 demo 集合（如下图，源文件在文章末尾下载），和我上述介绍的手势是对应的，大家可以拿着这个 demo 给开发同学演示大概的效果，也可以在这个 demo 源文件修改。
下载链接： https://pan.baidu.com/s/1iaFrcFwzC58TG3L17bjC_Q 密码: asto。
拖拽和甩动由于需要定义的细节参数都被操作系统提前封装好了，一般不需要我们给到额外的标注。但是对于轻扫，我们需要将细节定义清晰，下面将详细讲解。
上文讲到，阈值类型一般有两种：① 判定手指位移和释放速度满足任意一个即可；② 仅判定手指位移。①的开发成本高于②。
如果我们选用轻扫的阈值类型是①，开发同学编写代码需要两个参数的阈值，分别是手指位移和释放速度。手指位移阈值一般默认为受控物的1/2，例如下图的全屏短视频和 Banner 。
当然我们也可以自定义一个阈值，比如 100pt 、受控物高度的 1/6 等，没有特别的需要的话使用默认值即可而且也不用给开发同学特殊说明，但是如果有特殊需要想要修改默认值，就要告知开发同学你自定义的手指位移阈值。对于释放速度阈值，通常默认就非常的小，几乎是大于 0 即可触发，一般情况下使用默认值即可。
在本应该选用①的场景中，如果由于技术成本原因不得不选用②，需要注意的是由于缺少了释放速度的判定，手指位移的阈值我们需要设置得小一些方便用户触发，否则就**出现上文中美图秀秀浮层的那样的体验问题。经过我的实验，手指位移阈值一般定为 16pt 是比较适中的，既不**太容易误操作也不**难以触发。
轻扫是一定存在稳定化效果的，关键在于告知开发是释放前稳定化还是释放后稳定化。从开发的角度讲，系统**监测用户的行为，用户在使用滑动时**有按下（down）、移动（move）、抬起（up）三个行为，释放前稳定化是在移动阶段判断阈值并触发操作、释放后稳定化是在抬起后判断阈值并触发操作，开发成本几乎没有区别。
上文提到过稳定化效果强弱的概念。稳定化效果越强，单次滑动能够切换的选项个数越少，效率越低。稳定化效果越弱，单次滑动能够切换的选项个数越多，效率越高。首先，我们需要确定单次滑动允许切换多个还是只允许切换一个，如果允许切换多个，开发同学**设定一个控制切换难度的系数，而只允许切换一个的话就不存在这个系数。通常我们也不需要修改这个默认系数，但如果想让操作更加难或容易触发，可以告知开发同学修改这个系数。
绝对控制比相对控制的开发成本高，如果开发资源并不是很紧张，需要绝对控制的场景就不要退而求其次使用相对控制。涉及到轻扫手势一定要告知开发同学控制方式，否则很可能被视为相对控制处理。
通过本文的学习，我们不但可以在开发工作进行前与开发同学高效沟通，保证开发工作的顺利进行，也可以对自家移动端产品的现有手势进行逐一排查发现问题点进行记录，并且找到合适解决方案，然后用准确的语言描述给开发同学。下图是我在进行手势排查后输出的表格，挑选出一些有代表性的案例给大家作参考，开发同学可以通过它快速明确问题，理解解决方案。
本篇文章的归纳总结是通过日常积累和思考得来，希望能够帮助大家在设计与沟通层面解决实际问题，如果有任何疏漏和不严谨的地方，希望大家能够指出，后续的更新**将专栏不断完善，交互手势系列暂定的后续更新计划如下。
基础篇：
①位移类手势（本篇文章）
②点击类手势
③其他类手势
进阶篇： ④交互手势的特性
**越篇： ⑤设计创新型手势
有兴趣的小伙伴可以持续关注哦~
文章提到的手势 demo 下载链接： https://pan.baidu.com/s/1iaFrcFwzC58TG3L17bjC_Q 密码: asto。
参考书籍：
《交互设计语言：与万物对话的艺术》 作者: 罗涛
《交互设计精髓 4》作者：[美] 艾伦·库伯 / [美] 罗伯特·莱曼 / [美] 戴维·克罗宁 / [美] 克里斯托弗·诺埃塞尔
参考文章：
百度APP「表情面板」体验升级
微信视频号为什么没有采用全屏沉浸式交互
参考网站：iOS Human Interface Guidelines
本文由 @Ballen成明 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
