首页

app中的交互手势和意符设计

纯纯


PART 1 - 唐纳德诺曼关于交互设计的可视性的基本原则


唐纳德·诺曼所著《设计心理学1-4》一直被认为是设计行业经典,我在读这一套书的时候最令我感到共鸣的不是后来被大家大书特书第四本《情感化设计》,而是第一本《日常的设计》,这本第一本书最精华的内容是阐述了交互设计的基本原则,这个原则无论是对工业设计中的人和物件交互,还是说是建筑中的人和空间交互都有很深刻的指导意义。

作为一名app产品设计,对于这几个含义理解之后,融汇到app设计的情境下,会让你对之前工作流中的『交互设计』有全新的认识。

众所周知,交互设计借鉴了心理学/设计/艺术和情感等基本原则来保证用户得到积极愉悦的使用、情感和操作体验。交互设计之所以可以成为一门学科,本质在于可交互,而可交互的前提,是可以被感知(这个我在app的视觉美成因分析那篇文章里面已经说到过了),那么被感知的方式,往往是和人的五感有关。

触觉,听觉,视觉,味觉,嗅觉。只要能被人的五感所感知到,不论是和空间,和机器,和生活中的物件还是和人,只要发生五感的共情,我们就说是可以被交互的。(注意,本文中不考虑复杂多感交互,并且只考虑交互的一方是正常生物人。)

在人的五感之中,本文依旧着重讨论视觉,因为科学研究表明,在人五感的感知信息中,视觉视觉占比达到了惊人的83%。(其中听觉11%,嗅觉、触觉、味觉机加起来占比6%),而不管是什么设计,如果可视性不佳,都不能算得上优秀。

唐纳德·诺曼将交互的可视性原则归纳为和五种基本心理概念相关,这五中基本概念分别是:示能(Affordance)、意符(Signifiers)、映射(Mapping)、反馈(Feedback)和概念模型(Conceptual Models)。


i.示能(Affordance)

示能的概念和内涵来源于吉普森(J. J. Gibson)。此外,关于有形物品如何传达出人们与它们互动的重要信息,这个特性被吉普森命名为“示能”。

"示能"这个词,狭义的理解一下,是从可视性的角度明确了一个物理对象与人之间的关系。示能是物品的特性与决定物品预设用途的主体的能力之间的关系。示能的体现,由物品的品质同与之交互的主体的能力共同决定。示能的存在与否取决于物品和主体的属性。

还是举那个诺曼最经典的例子,如下图所示:

从视觉上看这张图,我们从以往的生活经验联想一种方形的,带纹路的黄色物质,再配合长期的视觉线索,我们会知道这张图上是一个木块,那从我们的视觉线索上,知道这个木板很细,(应该)能够轻易被折断;而且很轻,(应该)可以轻易被搬走。这些就是我们通过视觉判断这张图上呈现的"示能",而明确的我们和图上这个木材的交互关系。

那再看这张图:

我们通过生活经验的联想可以知道这是一个木门,为什么会区别这是木门而不是上面的木材呢?主要原因是因为这上面有个『把手』。在人的视觉中,有时候观测物体的某项"示能"是清晰可见的,比如上图那个木材可以被轻易搬动,而有很多物品的"示能"是不可轻易被感知的,比如上面那张木材的图,我们就不能感知到这个木材是可以被『轴转动』的。

而这张门的图上,大家想象自己是一个什么都不知道的野人,看到上面这个图,只有一块特别显眼的『把手』,你作为高智慧生物,是不是应该去触摸一下,并且企图能够与『把手』进行互动?

所以总结一下,如果这个门上没有把手,作为我们人类的认知而言,可能会认为这个门不能从外面被打开,但是如果这就是一个能从外面被打开的门,但是忘记设计外面的把手,那就意味着,这个物体"示能"的视觉通道被堵塞。(视觉通道被堵塞的"示能"可以被认为是一种"反示能"),"反示能"对交互作用是起到抵制作用的。也就是说,如果这个门是可以从外面被打开,但是我为了不让大家从外面打开,我在设计之初不加从外面打开的把手,一定程度上就可以抑制大家从外面打开的这种行为。

大家明白了么?

所以为了更有效的展现某些物体的视觉可交互,示能和反示能都必须被揭示出来,即可被觉察到。如果示能和反示能不能够被觉察到,就需要人为的把它们都标识出来,我们听过一些有效的手段就可以做到,比如在直立的木头一侧加上一个『把手』,这个把手就是"木头这种物体可以被人轴转动"这种"示能"的一个提示线索,你只需要旋转把手,稍加用力即可发现这个"示能"。

所以,我们把这种揭示"示能"的符号、提示功能、线索、称为『意符』


ii.意符(Signifiers)

划重点:示能决定可能进行哪些操作。意符则点名操作的位置。

在我的文章《交互闲谈02丨app中的非必要功能和用户界面上的流量法则》中,我对app中的意符进行了自己的定义:

用户界面上的意义符号,简而言之,就是一切用户感知中可以点击产生反馈的功能集合。

但是这是在以屏幕为介质的用户界面中我个人下的定义,但是在实际生活中,人们寻找蛛丝马迹,寻找任何可以帮助他们应对和理解的符号。任何可能标识出有意义的信息的符号都显得非常重要。人们所需要的和设计师必须提供的视觉线索,就是意符。

这就是为什么苹果第一代手机出来的时候会被大家奉为圭臬的原因,他在视觉上示能和意符都及其突出,一块屏幕和一个按钮,屏幕用户点击滑动交互,按钮用于点击交互,学习成本很低。大家试想一下之前的塞班系统,左上角和右上角两个按钮是和屏幕左下方的功能和右下方的功能映射,虽然也很易于理解,但是当大家看到苹果这么简单的手机的时候,相信所有人都是惊讶的:



△.示能和意符的关系

示能揭示了世界上作为主体的人(这里只考虑人),如何与其他东西进行互动的可能性。

一些示能是可视觉感知的,一些则是需要视觉之后联想感知(即不可直接感知)的。

意符指示能操作的位置。

一些意符是生活中的符号、标签和图样,如门上用符号标记的“推”、“拉”或“出口”,或指示所要采取行动的箭头和图示,或是朝向某个方向的手势,或其他的说明。一些意符仅仅是预设用途,譬如门的把手,或某个开关的物理结构。

划重点:在设计中,(尤其是UI设计中)意符比示能更重要。

示能和意符是本文中最重要的,下文会说到在app中的意符设计。


后面的映射,反馈和概念模型内容我简略说:

iii.映射(Mapping)

有一些自然映射是生物本能的或者是文化赋予的,比如如按照通常的习惯向上移动手势意思是增加,向下移动意味着减少,。当一系列可能的操作是可见的,当控制和显示契合自然映射时,设备就会容易使用。(具体参考我写的交互闲谈丨01里面那个视频手势的例子)

iv.反馈(Feedback)

反馈是控制论、信息论的著名概念。当我们做出了一个操作的时候,内心的预期是需要获得反馈的,如果在一个该获得反馈的地方没有获得反馈,人就会很疑惑,比如如果一个app的按钮点击之后没有跳转或者没有新的变化,那么人就会呆滞,如果反馈不及时,人还有可能会放弃。(比如网络不好导致的跳出率,比如一个不可点击的按钮做得太逼真用户疯狂点击发现没反应之类的 = =)

过多的反馈可能比过少的反馈更恼人。设计拙劣的反馈可能是旨在降低成本,最糟糕的是不恰当的无法解释的反馈。指手画脚的人通常是正确的,但他们的评论和意见如此之多,唠叨不停,会令人分心,而不是给予帮助。我记得很多年前(大概是2010年左右),还曾经见到过一款应用,用户但凡点击无效位置就会弹出一个Error的模态框,简直是令我绝望。 = =

v.概念模型(Conceptual Models)

概念模型通常是高度简化的使用说明,告诉你事物是如何工作的。概念模型只要有用就行,不必完整或准确。概念模型通常可以从设备本身推断出来,一些模型通过人与人相授,还有一些来自手册。(比如app新版本中那些半透明箭头加上文字的功能指引就是概念模型的一种,手游中一开始的新手指引也是。)




PART 2 - 屏幕的示能与基本的交互方式


一个人和一块(未通电的)触摸屏幕,在不借助道具的情况下到底能衍生出多少种交互方式?从五感出发去深入剖析的话大概分为:

嗅觉:用鼻子闻一闻这块屏。(发现并没有味道)

听觉:用耳朵听那块屏发出的声音。(发现并听不到什么声音)

味觉:用舌头舔一舔这块屏。(诶有点咸?)

视觉:用眼睛去看这块屏。(这是一块光滑的类似于玻璃的物体)

你们发现了么,对于一个原始的屏幕设备,比如手机,我们忽略按钮什么的物理按键,光思考那块没用通电的屏幕,如果你作为一个心智未开化的人(或者现在假设你就是一只猴),你真正对屏幕有建设的交互一定是在触觉上,我这么说大家能理解吧。我们不妨换位思考一下下,你现在是20年一个准备做概念手机的交互专家,你去穷举任何人和屏幕的交互,唯一有『肢体接触』的方法就是用手指(或者脚趾)去触摸,还有就是用舌头舔。用舌头舔会有口水,不利于屏幕的识别,万一漏电了画面太美不敢想。

所以,结论是,人类看到一块屏幕设备,这块屏幕设备的视觉示能最终导向了,人和屏幕的交互手段被定位在触觉上,而脚趾相对于人类来说没有手指灵活,所以最终我们把交互规定到手与屏幕的交互(简称交互手势)。

触觉:

我们来穷举一下手指和屏幕的交互方式:(图片来自Graphicpear,中文是我自己加上的。)


不要纠结于图,往下看,其实现今的所有的手势交互,我们基本操作分为:

一根手指:单击、双击、长按、拖动、上下滑、左右滑。

两根手指:单击、双击、长按、拖动、上下滑、左右滑、扩张放大、收缩缩小、旋转。

三根手指:单击、双击、长按、拖动、上下滑、左右滑、扩张放大、收缩缩小、旋转、捏按。

四根手指:单击、双击、长按、拖动、上下滑、左右滑、扩张放大、收缩缩小、旋转、捏按。

五根手指:单击、双击、长按、拖动、上下滑、左右滑、扩张放大、收缩缩小、旋转、捏按。

双手双指:单击、双击、长按、拖动、上下滑、左右滑、扩张放大、收缩缩小、旋转。

双手十指:单击、双击、长按、拖动、上下滑、左右滑、扩张放大、收缩缩小、旋转。

(上面写的双手双指是指每只手出一个手指,比如你们在手机修图时候的某些旋转操作)

其实你如果还要穷举的话,还有双手每只手一个指头、双手每只手两个指头、双手每只手三个指头、双手每只手四个指头这些奇怪的情况,但是由于现阶段手势足够完成日常操作,所以日常的人和屏幕交互并没有引入这些别的奇怪的方案。

我相信随着科技的进步和发展,其他的双手的交互操作也会大面积的被引入进来,起码我个人在看类似于黑镜啊还有别的欧美科幻片的时候,不止一次见到了这样的画面。(我印象最深的是黑镜第三季06,女主角操控手机方式是四指横滑,然后胖大叔操作无人驾驶的骑车的时候是双手旋转打开一个屏幕,然后再通过指头拖动目标完成导航交互。)这些电影里面反应的人的未来科技中蕴含了很多交互方法,大家可以看电影的时候多留意一下。

有点扯远了,回到手机app的交互手势,(除开游戏以外)一般单指双指即可解决。而先现今科技下,相对于大屏幕一些的平板电脑,无论是ipad还是Andriod厂商,都会引入三指,四指甚至五指的部分交互手势。

由于今天的主题是手机app,那我们下一部分就着重主要来说说手机app的交互。

PART 3 - 手机app中的意符分析


在设计中,尤其是UI设计中,意符比示能更重要。

理解这句话的本质是因为一块屏幕上人需要设计图形、按钮、内容。去让他完成一些具体事情,所以在屏幕显示的软件中的意义符号就需要有很深的引导性。

还记得之前我的定义么?用户界面上的意义符号,简而言之,就是一切用户感知中可以点击产生反馈的功能集合。

我们闲言少叙,先来看一个例子:

如图是喜马拉雅FM的app首页UI,我将从功能属性、视觉焦点两个角度,一排一排的进行分析:


角度一、首先从功能属性上进行分析:

第一层:NavigationBar上的意符为『消息』、『搜索框』、『历史』和『下载』,本质上是以功能名字命名的意符,其意符的表现形式为图片+文字。没啥好说的,每一项映射到自己的功能详情。

第二层:Tab的分类共有『热门』、『分类』、『康永来了』、『直播』和『广播』,其意符的表现形式为文字,这里大家看到『热门』标签本身变成橘黄色且下面有一个橘黄色细线,这是两个符号是通过这么多年的用户教育之后形成的意义共识,意义为:当前页面状态。这里我有一个小问题,大家猜如果这时候我右滑界面(采取的交互手势是单指向左轻滑),会发生什么事情?提供两个选项:

A、到『分类』页面。
B、到『订阅』页面。

详细绝大多数人都能答对,这里的正确答案是A,滑动到下一个tab『分类』。大家只知其所以然,感觉这里的tab本身就是靠滑动手势来控制的,但是更深层次的原因呢?为什么?

这里涉及到一个滑动切换tab的遍历解构,关于这个,我的网友@HoZiN老法师(大雾)的《浅议滑动Flick切换Tab导航 - 知乎专栏》这篇文章写得很棒,大家可以去看看。在这里我做粗浅的解释,在喜马拉雅这个app中,『首页』UI中的TabBar上的『热门』、『分类』、『康永来了』、『直播』和『广播』都是归属于当前BottomBar『首页』的,所以我们在滑动操作的时候应从当前深度的最近层开始交互。

如@HoZiN的下图所示:


如果用户滑动这个页面只能在首页的5个tab之间切换,我们认为他是下图的第一种,也即是在单一Bottom模块下切换(Hozin将其命名为独立Sub Navi切换,Sub Navi的意思其实也就是底部的Bottom navigation bar的意思,我上文中就直接简称BottomBar了,个人命名习惯而已大家能懂是这个意思就行),而另一种情况是有些app当滑动到最后一个tab,再右滑屏幕会进入到第二个Bottom模块,既是下图第二种的b-C和f-G的过程。虽然现在这种设计方式已经鲜有app在继续使用了,但是我在2017年的今天仍然是遇到了一些。并且有个特别而精彩的地方在于,一般情况下,b-C和f-G的滑动切换Bottom模块的这个交互往往是不可逆的。这点就比较有趣了,关于这个更深层次的原因可能是开发的原因,可能是产品没法做到每一个Bottom都有tab,也可能是因为别的app信息架构方面的原因,在这里就不展开了。

我们再继续单独看这个第二层:

215b59510beda8012193a31bbb4d.jpg

是不是发现有一个奇怪的格格不入的叫做『康永来了』的东西混了进来?这里我就必须吐槽一下喜马拉雅的产品设计团队了,作为一个普通用户,我本能的以为这个tab下一定是和康永来了有关的内容整合,放在这里是因为运营需要,这个其实在内容平台上很常见,大家看QQ视频和爱奇艺他们不也经常这么干,本身是一件无可厚非的产品推广的入口常态,然后我滑过去了发现其实他是『每日优选』的一个频道,只不过最近主推蔡康永的这挡音频节目:

如上图所示,这个奇怪的『康永来了』的tab归属到的不是康永来了的音频详情页,而是一个『每日优选』的列表页,那我就认为这个设计是欠妥的。

我为什么说这样的设计欠妥,其原因如下:

因为我确实是有几个月没有使用过喜马拉雅了,我不记得『康永来了』这个位置之前是不是叫『每日优选』,还是之前首页只有四个tag,这个希望有关注的读者下方给我留言确认一下。

那既然我不确定,我们不妨分两种情况去分析:

第一种情况:之前首页只有四个tag,而新加了一个以具体内容ip产品名(比如康永来了也好,或者明天老罗来了也罢)作为显示,实则是每日优选的一个强视觉tag,为的是引导用户点击具体ip产品之后看到每日优选的这个列表,从而为别的每日优选这个列表页导流。(我认为对于一个成熟的产品团队,不太可能是这种情况)

第二种情况:之前首页就有『每日优选』这个tag,只不过后来为了运营或者强视觉需求,改成了具体ip产品名。(我倾向于第二种假设)

我猜测喜马拉雅的团队本质上是希望借助类似于康永来了这样大的ip露出,通过从视觉上的突出(视觉突出这一点确实做得很好)从而博取用户流量,然后让用户通过查看『康永来了』这个具象的兴趣点tab,进入每日优选的这个列表,从而为别的每日优选产品导流。

从文案层面来说『康永来了』确实比『每日优选』更吸引人,但是如果是我来设计这个地方的话,我个人倾向还是放一个每日优选的tag,毕竟这是所有用户都能懂的语言,而康永是谁?这个问题毕竟不是所有人都知道的。

如果实在是通过数据或者产品运营需求表示,我们需要强调『每日优选』的话,那我会把每日优选的视觉也做得像现在康永来了一样突出,但是名字不能变,还得叫『每日优选』。

那如果康永来了这个ip市场运营那边吩咐了,确实需要持久强推怎么办?

办法有,比如banner位就可以直接推,而且banner位可以直接跳转到具体ip的详情页,路径更加简短,用户马上就可以购买,不像现在跳到的是一个每日优选的列表,用户还得通过一次点击才能进入详情。

还有另一种极端的情况,如果有一天运营同学告诉我,banner位不允许一直放康永来了,但是市场同学又告诉我康永来了这个ip很重要,需要长时间强推。那我的办法可能是有以下两种:

第一种办法是在第三层的最前面(必听榜的前面)加一个独立的康永来了tag,这样的做法是开发成本简单易行,但是不够优雅。但是你连『小雅音响』这种智能硬件购买页入口都放在上面了,多放一个运营强推ip也没毛病啊。_(:зゝ∠)_

第二种办法虽然比较decent一些,是在第四层和第无层的中间开辟一块很小的次banner位去放,如下图所示:

但是我个人是不推荐这种做法的,哪怕未来这个次banner可以扩展为多个次banner轮播我也不推荐,因为如果是这样的话,用户首页第一屏留给『猜你喜欢』的内容展示就很有限了。

总而言之吧,第二层tab的『康永来了』一定是一个待埋点考量的争议设计。我只是提出我个人的见解,不一定对,大家切勿偏听偏信。好了我们继续往下看。

第三层和第四层:图片banner和分类频道icon,其意符的表现形式为纯图片/图像+文字,banner嘛这个没啥好说的,通过自动左右切换的图片告知用户一些产品需要告诉用户的信息而已。分类频道icon我之前的几篇文章里面都有提到一些,记得在我的文章里我说到的格式塔原理么,大家打眼一看这个分类频道icon就知道右侧还有一些,是可以滑动的。

第五层和第六层:这个就更没啥好说的了,就是一个常规的带图片的宫格列表(我习惯这么叫他们,你们想怎么叫都行)页,其意符的表现形式为图片+文字,右上角有点击更多有一个向右的图标表明是可以点击跳页的(具体参看我写的分割线那篇文章)。到一个内容更丰富的item列表页。那么我问大家一个问题,为什么猜你喜欢的这个图片不也做成左右滑动的而要做成这样固定展示6张的呢?

这里主要是有两方面的原因,第一是做成左右滑的话,屏幕空间最多只能展现三张半,不如现在这个展示6张露出得多。第二是有一个很有趣的交互上需要注意的点,大家看如下图所示:

我标记蓝色线框的部分大家看到了没,这个banner也是可以滑动,分类频道icon也是可以滑动的,整个页面Tab也是可以点击跳转的。这也就意味着,如果要执行tab滑动跳转这个交互手势,我想能采用的滑动热如右图红色所示,区域本身就已经很小了。如果下面猜你喜欢也做成可以左右滑动的话,那么Tab的滑动手势热区面积更小了。如果真是那样的话,那这个Tab就不该设计成可以滑动加载的。

所以说嘛,app中的意义符号设计直接决定了这个app的易用性。不要乱来。

第七层:这就是bottombar具体没什么好讲的了,也就是五个图形意符,各自表示着自己的意义映射。现在很多app中大家会发现有些底部是只有icon没有文字的,有些是带了icon也带了文字的,带文字的目的也是为了解决图形联想带来的意义映射路径多的情况。这个不多说了。来看第二个角度。


角度二、从视觉上进行分析:

按照视觉强弱来看,『康永来了』、『banner』、『猜你喜欢』是页面最重的视觉部分,其次是频道入口icon和下面的Bottombar,最后是navigationbar上的小溪、搜索、历史和下载。从视觉上看,其实作为内容平台的喜马拉雅设计的很赞,没有任何问题。内容产品本身占有最强视觉强度,功能意符占有较弱视觉强度。这就是为什么猜你喜欢要用图片+文字的宫格列表,不用类似于item之类的原因,因为比如这里的每一个节目都换成是一个item,那视觉只集中左边的图片上,而不像现在三张图片这样聚焦。

最后抛出一个视觉上BottomBar的问题,现在很多app会在实心icon还是线性icon上面纠结,知乎的BottomBar一直采用实心icon,而Airbnb一直采用线性icon,到底为什么?

我会在下一期的交互闲谈里面说这个问题,大家也可以想一想,其实(如果我理解的没错的话)答案就在我上面这段论述中。



PART 4 - 手机app中的意符设计需要辩证的几小点


一个擅长app中意符设计的人,本质就是对appUI设计有十足把握的人,关于这里的几点辩证只是提出来说一下,具体的UI设计过程中这样的问题不胜枚举,大家可以留言交流。


一、BottomBar上的意符到底要不要加文字?

手机中可供点击反馈的意符设计分为很多种,有纯图片的(比如banner),有图形+文字的(比如BpttomBar上的那些),有纯文字的(不如上文中喜马拉雅的切换tab,比如『点击查看更多』、『点击展开』、『滑动加载』之类具有诱导性的文案),还有纯图形的『比如像『一个One』这样的app底部BottomBar是只有图片不带文字的』,还有一些是按钮形式的。

在这些意符的设计中,意义识别是尤其需要被设计的。如果一个图形无法表现他应有的意义,那就一定要在附近加上文字形成一个完整的意符。

举个例子:已下载这个icon已经被所有app用烂了,大家一听就知道应该包含一个向下的箭头,比如历史记录也是,大家都能想到是一个时钟,这就是长期教育用户之后用户产生的意义联想。所以喜马拉雅和腾讯视频中的这两个意符设计,一个是带文字,一个是不带文字,都不影响用户识别体验。

但是比如再举一个例,『我的』图标,现在大家都习惯用一个『人头像』,而一切新奇的产品比如说『氧气app』,才用的是一个圆圈,那么这个时候如果是意义识别为主导的产品(比如电商啊或者用户不是那么年轻的)就会选择在下面加上一行中文。这样的话在图形上发挥得再不易识别,也可以借助文字瞬间映射到。

那比如像『一个One』、『Medium』和『500px』这样的众多app,他们的BottomBar都是一个纯图形:

纯图形带来的其实是一种新奇感和简洁的设计感。相对的,和用户需要花更长时间的视觉判断,比如第一张图是『一个One』,第2,3,4个icon其实很易识别:一本书,一个音符和一个播放三角能够很简洁的代表文章,音乐和视频。第二张图相对就没有那么容易识别了,尤其是第三个图标,意义指向不明确,但是由于Medium是一个国外设计师聚集的网站,所以其实也还好,设计感在一定程度上会优于识别也没问题。图3是500px,这5个icon就更易识别了。

所以,如果你采取无文字的BottomBar,那么请UI设计师用心设计你的icons。


二、设置引导用户点击加载的意符应该如何设计?

有一个app需要设计这样一个功能:文字默认折叠展示3行,但是点击之后需要(非跳页)加载全文,那么请问需要设置怎样的意符引导用户点击?

传统的大概是三种方案:

第一是在文字第三行的前四个字用其他颜色(比如蓝色)标记为『加载更多』,用户一点之后加载全部(早期知乎的做法)。

第二种是在文字第三行结束之后再第四行的位置居中放一个『点击加载更多』,用户点击之后加载全部。

第三种是在文字第三行结束的位置放一个省略号即可,用户阅读之后发现没读完,自己会尝试点击。

显然,第三种方法仅适合社区类app或者贴吧或者问答类app,因为一般用户读都很难读完,更别说给你点击一下了。第一种和第二种也是见仁见智,一般情况下我个人推荐第一种,因为需要文字折叠成三行的页面就说明本身画面排布很紧张,就不要另起一个第四行放『点击加载更多』了。


三、app中的按钮设计,什么时候应该有push色,什么时候应该没有?

这是我的微信公众号后台有一个小伙伴的提问,push色这个东西在网页上有别的更多作用,但是在app中,一般就只用来反馈行为。

有两种情况:

第一种是你点击某个意符,这个意符发生变化(颜色或样式变化)同时跳转。

第二种是你点击某个意符,这个意符完全不发生变化但是页面跳转。

从用户期待每次行为都得到反馈的心理上来说,我们当然希望所有的意符都能呈现及时反馈以证明你的点击行为是有效的(也就是上面的第一种)。但是有时候由于反馈动效我们写得不尽如人意问题,我们看到冗长(哪怕只有半秒)切重复的的反馈内心就会就会很烦。

举个例子比如原生安卓的Material Design点击每个item都会出现一个水波动效反馈,当然原生Material Design的动效是足够优秀的,所以我们会觉得很有新奇感。但是你们如果试试把安卓的这个动效拉长别说一倍,拉长三分之一。你们一定会崩溃的相信我。



PART 4 - 总结


1、app产品设计和UI的设计中,意符的设计是当众最重要的一环,因为每一个意符作为产品的功能入口和行为入口,它们不光光是产品的流量节点。更是app产品信息架构的核心提现。

2、在设计app的意符的时候,要更多的考虑到意符所蕴含的具体交互手势(比如喜马拉雅的tab bar就包含了滑动和点击)以及具体的对用户行为的思辨。

3、app中意符的设计一定是框架层面的设计,他的本身视觉层级不易过高,最好不能超过app主体信息。

4、意符的意义映射要尽可能的单一,最好能让用户一眼就了解这个意符是代表什么功能什么意义。

5、app意符的观察、分析、设计是一个长期的过程,大家可以试着多问自己一些为什么。




文章来源:站酷   作者:Seany

分享此文一切功德,皆悉回向给文章原作者及众读者.


免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务



交互手势全解析之位移类手势

seo达人



通过本文,学会根据需求设计合适的位移类手势,能够判断手势的体验问题并提出相应解决方案,并与开发同学高效沟通确保落地。

 

前言

一年前更新了文章《交互手势的容错性和逻辑性》之后,有很多读者朋友询问是否能够做一个详细的讲解交互手势的系列文章,讲解每个手势的不同之处、应用场景以及在工作中如何使用。

我非常理解这些读者的痛点,因为我在日常的工作中,也经常遇到一些难题。比如同样是滑动,但是些许参数的变化就会导致体验的天差地别,应该如何进行选择。再比如与开发同学沟通过程中如何准确描述自己想要的效果,让最后的结果不至于与自己的预期不一致。

这些难题也促使我大量思考,大量体验各种产品的手势操作,希望能够从中总结出规律,让手势的设计与落地能够有理有据。现在经过一段时间的积累,我认为我在这方面可以讲一些能够帮助大家的内容了。不足之处,希望大家指正。

今天给大家带来专栏的第一篇《交互手势全解析之位移类手势》。

 

1 位移类手势的描述维度

手势作为图形界面与用户之间沟通的方式之一,在便携电子设备上大量应用。与实体按键相比,它有着纯粹的简洁性和无尽的创造性,手指的个数变化、不同变量的组合能够创造出无数的操控方式。

位移类手势是指代那些通过手指接触屏幕后的位置变化从而操控电子设备的手势,本篇文章主要讲解单指操作的位移类手势,多指的位移类手势(如捏合)将放到后续文章中讲解。

一谈到位移类手势,大部分设计师的脑海中可能会浮现出拖拽、甩动和轻扫这三个术语。然而,当我们想仔细谈论他们三者之间的区别时,大部分设计师可能无法准确地描述。为了能够准确描述三者的区别,我们在这里引入三个维度的概念,它们分别是控制方式稳定化效果、以及阈值类型,这三者的不同的变化组合可以创造不同的位移类手势,拖拽、甩动和轻扫之间的区别也是这三个维度影响的。当我们在讨论不同位移类手势之间的区别时,不如说是在讨论这三个维度之间的区别。比如常见的轻扫手势,因为这三个维度的变化就会产生不同的变种,而且不同变种在体验上也存在很大差别,若不分场景随意使用,很容易就影响用户体验。那接下来我们首先了解一下这三个维度。

 

1.1 控制方式

第一个维度是控制方式,它分为绝对控制相对控制,也可以通俗的表达为跟手不跟手,区别如下。

绝对控制/跟手:施加控制的一方(后文简称施控物)的某个属性变化与被施加控制的一方(后文简称受控物)的某个属性变化是对应的

相对控制/不跟手:施控物的某个属性变化与受控物的某个属性变化不是对应的

比如在网易云音乐的播放页(下图左),左右滑动黑胶时,手指是施控物,黑胶是受控物,手指的横向位置变化和黑胶的横向位置变化是对应的,即绝对控制。上滑调出评论页时(下图右),评论页的位置和手指的位置没有对应关系,手指的上滑仅仅控制评论页是否出现,即相对控制。

与相对控制相比,绝对控制允许用户去操控受控物的属性变化过程,因此给予了用户更强的掌控感。比如在微信读书阅读页边缘右滑,手指的横向位置与书籍封面的变化过程对应,模拟现实生活中慢慢合上书的感觉,如下图。

但是在有些场景,为了避免混乱,属性变化过程是不适合被用户绝对控制的,此时我们应采取相对控制的方案。比如 iOS 的相机中,左右滑动切换拍摄模式,由于前后不同模式之间的页面框架变化较大,切换时会有过多元素的属性变化,如果使用绝对控制就会导致切换拖沓且混乱,使用相对控制就能避免这个问题。

 

1.2 稳定化效果

1.2.1 定义

当我们使用手势控制某个受控物时,由于手势的某个属性(如手指位移)达到阈值,进而导致受控物的某个属性稳定在了特定状态的效果被称为「稳定化效果」,或者也可以称为「吸附」。

稳定化效果能够保持界面的视觉秩序,避免过多的中间状态导致界面的杂乱,进而帮助用户聚焦信息。

是否有稳定化效果是区别轻扫与另外两个手势即甩动和拖拽的重要维度,当某个位移类手势有稳定化效果,我们就将其称作轻扫

以滑动切换抖音视频为例,当手指上滑的位移距离和释放速度其中的某一项属性达到阈值后,下一条视频会往上移动到一个固定的位置然后进入稳定状态,而不会出现停留在不完整的中间状态,如下图所示。

在 iOS 端的微信消息页左滑某条消息后会出现更多操作按钮,按钮会在手指滑动的距离达到阈值并松开后稳定在一个固定的大小,而不会停在类似下图左所示的混乱的中间状态。

在多内容选择的场景中,如果滑动与选中是绑定的话,一般需要使用稳定化效果。例如在 iOS 相机里选择滤镜时,滑动滤镜选项不但能够控制滤镜选项的位置,并且会自动选中一个位于中间位置的滤镜,位置的稳定化避免了被选中选项的不明确。

如果滑动与选中是分开的,比如美图秀秀的滤镜选项需要先滑动后选中,这种情况下稳定化效果不是必要的。

 

1.2.2 与效率的关系

不同的稳定化规则带给用户的体验差异是非常大的,最明显的差异是在效率方面。我们使用稳定化效果的强弱来理解,稳定化效果越强,单次滑动能够切换的选项个数越少,效率越低。稳定化效果越弱,单次滑动能够切换的选项个数越多,效率越高。

比如在比较常见的 banner 切换功能中(下图左),无论手指位移和释放速度的值有多高,banner 只能切换并稳定到下一个,不能够一次切换多个 banner。而在网易云音乐的首页排行榜中,一次滑动能够切换多个内容卡片。因此,我们可以说前者的稳定化效果比后者强。

拖拽和甩动虽然没有稳定化效果,但是也存在效率的高低。我们可以将其与轻扫放在一起做对比,如下图所示,拖拽、稳定化效果强的轻扫、稳定化效果弱的轻扫、甩动它们切换效率依次增加。

那么我们决定添加稳定化效果后,如何选择强弱程度呢?选择没有绝对的对错,整体来说主要考虑两点,业务诉求和用户诉求。例如在常见的 banner 切换中,banner  的总数量一般不会很多,业务的诉求是希望尽可能曝光每一个 banner ,使感兴趣的用户进行消费,因此这里比较适合做稳定化效果强的轻扫。在云音乐的排行榜案例里,不同用户感兴趣的榜单是不同的,稳定化效果弱的轻扫可以方便用户单次滑动切换多个,快速切换到自己感兴趣的榜单的大概位置。

百度 App 的表情面板原本是左右轻扫浏览表情,在一次改版中改为了上下甩动浏览。主要目的之一就是为了提高浏览效率、降低非首屏表情的曝光难度。

微信视频号的改版是一个典型的案例,旧版的微信视频号的视频流并不是类似抖音那样的全屏化形式和轻扫手势(下图右),而是占据屏幕尺寸三分之一到二分之一之间的卡片形式(下图左),并且使用甩动而非轻扫。视频号问世初期优质内容匮乏,社交推荐算法不完善,贸然模仿抖音式的全屏化形式和轻扫手势的话,会导致用户浏览到劣质视频时负面感受被增强且切换效率变低,反之卡片形式加甩动手势给予了用户更自由的选择空间,提高了用户的切换效率,降低了负面体验。等到如今时机成熟,再从卡片形式和甩动手势换成全屏化形式和轻扫手势就势在必行了。

在某些场景,用户需要先通过高效的方式选择特定区域的内容,然后进入聚焦状态进行内容浏览和慢速的切换,此时我们需要设计两种切换效率不同的手势应对前后场景的变化。如下图,在 iOS 的照片 App 中,先使用切换效率较高的甩动进行粗略切换找到目标图片大概位置,点击进入大图模式时使用切换效率较低的轻扫进行精确切换查看。

 

1.2.3 触发时机

触发稳定化的时机可以分为释放前和释放后,不同的时机带给用户的体验也不同。释放前稳定化指的是用户使用手指滑动屏幕时,手指位移达到阈值后,手指无需离开屏幕,稳定化即可被触发。如下图左,iOS 的相机滑动切换滤镜使用的就是释放前稳定化。释放后稳定化指的是用户使用手指滑动屏幕时,手指位移或释放速度达到阈值后,手指必须离开屏幕,稳定化才能被触发。如下图右,常见的 banner 切换。

释放前稳定化可以避免拖沓,增加切换效率,但是缺点是无法反悔回退且缺乏掌控感。反之,释放后稳定可以反悔回退,掌控感强,但是缺点是比释放前稳定化拖沓了一些。

 

1.3 阈值类型

阈值是能够触发变化的最小值。比如当水的温度达到 100 度时就开始变成水蒸气,100 度就是一个阈值,温度是阈值类型。在手指与屏幕的交互中,手指在屏幕上的某个停留时间、位移、释放速度、点击次数等都可以成为一个阈值类型,达到相应阈值后就可以触发相应的变化,常见的变化有受控物的位置、大小、不透明度等,理论上变化可以是任意的。

在位移类手势中,通常会用到的阈值类型有手指位移释放速度,手指位移是用户在手指触摸屏幕时的位置与之后某个时间手指位于屏幕的位置之间的距离,释放速度是用户的手指在屏幕表面进行位移后离开屏幕那一瞬间的速度。

市面上的 App 暂时不存在仅通过释放速度判定而与手指位移无关的阈值判定方式,因为其不太符合常识。因此我们在设计位移类手势时,能够选择的阈值判定方式常见的有两种:

  • ① 判定手指位移和释放速度满足任意一个即可;
  • ② 仅判定手指位移。

当我们设计手势时,就需要考虑两者的区别。由于 ① 比 ② 增加了释放速度带来的额外移动距离,因此 ① 的主要优点是高效。但是由于我们无法预判释放速度带给受控物的移动距离长短,所以相对应的缺点就是易误操作和不精确。②就恰恰相反,由于不存在释放速度造成的不确定因素,它的优点是不易误操作和精确,缺点是低效。

甩动和拖拽之间的区别就在于阈值判定方式,甩动是 ① ,拖拽是 ② 。如下图,当在微信消息列表找相应的消息时,用户的诉求就是能够快速找到特定消息的位置,对特定消息的出现在屏幕的位置也没有特定要求,只要能够被手指点击到即可,因此选用甩动较为合适,但是对于调节音量、亮度这一类的操作,滑动的范围有限,因此用户对效率没有太高的要求,但是对于滑块位置的精确度有要求,因此选用拖拽是更为恰当的。

再举一个反例,在 Steam 移动端横滑首页的泳道卡片时(下图左),使用的手势是拖拽而不是甩动,浏览起来特别低效。更适合的做法应为甩动,会更符合此场景下的快速浏览的诉求,如下图右的豆瓣。

对于轻扫来说,使用哪种阈值判定方式有多种情况(如下图所示)。在本文中,根据阈值类型、稳定化效果以及控制方式的不同我将把轻扫分为 A-E 共 5 类(A-E的命名方式仅存在于本文章,因此在向其他人传达时,尽量使用在后文我介绍的手势描述而不是类别名称,以便于对方理解。)。后续会为大家仔细举例讲解,大家现在仅了解一下即可。

当我们在刷抖音视频时使用的手势就是轻扫,是否滑动到下一条视频进行播放的判定方式是① 判定手指位移和释放速度满足任意一个即可,对应的手势类别是上面表格中的轻扫A。如下图所示,在刷抖音时,如果使用判定手指位移的方式,我们可以将手指在垂直方向位移大于半个屏幕高度的距离,从而切换到下一个视频。如果使用判定释放速度的方式,我们可以移动任意的垂直距离但是手指离开屏幕时保留一个速度从而切换到下一个视频。大部分情况下用户都会使用判定释放速度的方式,因为既省力又便捷。

如果将阈值判定方式改为 ②仅判定手指位移,对应的手势类别是上面表格中的轻扫 B,并且位移的阈值设置得比较大的话,给用户带来的负面体验可能将是非常大的。比如下图中打开美图秀秀的短视频评论浮层后,想要下滑收起时,App 仅判定手指位移,而且这个位移阈值设置得比较大,对于希望通过快速滑动一小段距离收起浮层的用户来说体验很差。即使由于开发资源有限我们只能做到仅判定手指位移,我们也可以通过减少手指位移的阈值来降低负面体验。

但是某些场景下,②仅判定手指位移是更加合适的。比如想要在微信中下拉打开小程序选择页,就只能通过手指位移达到一个特定的阈值才能够触发,无论怎么用力滑动去增加释放速度都无法打开小程序选择页。这样处理的原因是在微信消息列表页,上下滑动浏览微信消息是一个高频操作,如果释放速度也能作为打开小程序页面的阈值的话,用户可能就极易在下滑消息列表时误操作,无意间打开小程序选择页。

因此,对于位移类手势,选用哪种阈值判断方式要依据用户使用场景和诉求,不能想当然地设计。

 

2 常见位移类手势解析

了解完三个基础维度后,我们再将其进行组合,从特定手势的角度更全面地理解它们的差异和使用场景。三个维度的排列组合能够生成十余种位移类手势,我列举出了常见的 7 类,如下图所示,这 7 类基本涵盖了 95% 以上的场景,我将一一举例说明。由于施控物控制受控物改变的属性一般都为位置,因此接下来在描述下面手势的定义时我都以受控物的位置变化进行举例。

 

2.1 拖拽

2.1.1 定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动,无论释放时手指是否仍有速度,受控物都会立即停止移动。(下图的动态演示由 Principle 制作,观看会有些不太直观,大家可以在文章结尾处下载 Principle 源文件后导入到手机里体验,源文件包含文章提到的所有位移类手势)

 

2.1.2 特点

精确度高但效率低。由于阈值类型仅判定手指位移且没有稳定化效果,拖拽适用于对操作精度要求高,对效率要求低的功能。

 

2.1.3 案例

在 iOS 设置中调节亮度时,在有限范围内,手指左右拖拽可以控制亮度变化。

 

2.2甩动

2.2.1定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动。若释放时手指仍有速度,受控物将移动一段距离后才慢慢停止,移动的距离与释放速度呈正相关。若释放时手指速度为 0 ,则受控物立即停止移动。

 

2.2.2 特点

精确度低但效率高。由于阈值类型判定释放速度和手指位移,甩动适用于需要快速浏览较多内容的场景,如滚动浏览列表。

 

2.2.3 案例

在微信的消息列表页,使用甩动手势控制列表上下移动,若释放时仍有速度,列表将仍移动一段距离后才慢慢停止。

 

2.3 轻扫 A

2.3.1 定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动。若释放时的速度和手指位移有任意一个达到阈值,受控物将稳定在一个新位置。若释放速度和手指位移没有任何一个达到阈值,受控物将回到原位置。

 

2.3.2 特点

由于轻扫拥有稳定化效果,因此它能够保持界面的视觉秩序,避免过多的中间状态导致界面的杂乱,进而帮助用户聚焦信息。接下来讲解的其他轻扫类型都有这一特性,就不一一赘述了。轻扫 A 与接下来要讲解的轻扫 B-E 的最大不同之处在于轻扫 A 的阈值类型为「释放速度和手指位移」,这让轻扫 A 与轻扫 B-E 有两点不同,一是轻扫 A 可以通过释放速度的快慢去控制内容的切换数量的多少,更加高效,二是轻扫 A 可以通过用手指在屏幕滑动很短的距离但离开屏幕时保留一个速度来切换内容,因此更加省力。

 

2.3.3 案例

在刷抖音时,如果使用判定手指位移的方式,我们可以将手指在垂直方向移动大概半个屏幕高度的距离,从而切换到下一个视频。如果使用判定释放速度的方式,我们可以移动任意的垂直距离并且手指离开屏幕时保留一个速度从而切换到下一个视频。

 

2.4 轻扫 B

2.4.1 定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动。若释放时手指位移达到阈值,受控物将稳定在一个新位置。若释放时手指位移没有达到阈值,受控物将回到原位置。

 

2.4.2 特点

轻扫 B 与轻扫 A 相比唯一的区别是阈值类型减少了释放速度的判定方式,这提高了触发切换的难度,使操作成本变高,但是在某些场景下,这也降低了误操作的概率。如下拉刷新等。

 

2.4.3 案例

比如想要在微信中下拉打开小程序选择页,就只能通过手指位移达到一个特定的阈值才能够触发,无论怎么用力滑动去增加释放速度都无法打开小程序选择页,这样处理的原因是在消息列表页上下滑动浏览消息是一个高频操作,如果释放速度也能作为打开小程序页面的阈值判定方式,用户可能就极易在下滑消息列表时误操作,无意间打开小程序页面。

因此,当页面已存在一个滑动操作的情况下,还存在另外一个方向相同的滑动操作且仅会在边界情况下才能触发时,为了避免误操作,会将后者的手势设计为轻扫 B 。

上文提到,轻扫 A 的阈值类型为判定「释放速度和手指位移」,轻扫 B 的阈值类型为仅判定「手指位移」,由于前者的实现成本比后者高,导致本应适合做成轻扫 A 的功能有时只能妥协做成轻扫 B ,比如之前提到过的美图秀秀的短视频评论浮层案例,但我们也可以通过减少手指位移的阈值来降低负面体验,后文会讲解如何与开发同学沟通。

 

2.5 轻扫 C

2.5.1 定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动,但是受控物并不随着手指的控制而同步移动,仅当释放时手指位移达到阈值时,受控物才开始移动并稳定在一个新位置。若释放时手指位移没有达到阈值,受控物位置则一直保持不变。

 

2.5.2 特点

上文讲到过释放后稳定化和相对控制的缺点,释放后稳定化比较拖沓,相对控制让用户缺乏掌控感。两者如果应用到了同一个手势(即轻扫 C ),就会导致用户在滑动屏幕时得不到任何反馈,用户会疑惑是否因为自己操作不当或是设备出现故障。只有当用户手指离开屏幕后才会发现触发了操作,整体的交互流程给用户一种滞后与延迟的感觉。

因此轻扫 C 与其他类别的轻扫相比存在劣势,但是它也存在很多的 App 的 H5 页面中,我的猜测是由于 H5 对于判定释放速度和绝对控制这两个维度与客户端相比难度大很多,因此只能退而求其次选择轻扫 C 这个较差的方案,实际上在同样的应用场景中用轻扫 A 替换轻扫 C 可以带来更好的体验。

 

2.5.3 案例

下图左是 QQ 的个性装扮的 H5 页面,卡片的切换使用的就是轻扫 C ,如果能够优化为轻扫 A 体验会更好,比如下图右的音街首页卡片的设计。

 

2.6 轻扫 D

2.6.1 定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动,但是手指位移达到阈值前受控物并不随着手指的移动而移动。若手指位移达到阈值,无需手指释放,受控物将开始移动并稳定在一个新位置。若手指位移没有达到阈值,无论是否释放,受控物位置则一直保持不变。

 

2.6.2 特点

相对控制的方式降低了用户的掌控感,释放前稳定化减少了操作的拖沓感。使用此手势的场景是在多个对象之间切换时,我们不希望用户过于自由地操控对象之间的属性变化过程,并且牺牲掌控感从而增加单次的切换效率。

 

2.6.3 案例

比如 iOS 的相机中,左右滑动切换拍摄模式时,由于前后不同模式之间的页面框架变化较大,切换时会有不同元素的属性变化,如果使用绝对控制和释放后稳定化就会导致切换混乱且拖沓,使用相对控制和释放前稳定化就能避免这个问题。

 

2.7 轻扫E

2.7.1 特殊说明

上文我们讲到,通过轻扫手势 A-D 对受控物的绝对/相对控制都是存在于稳定化前,受控物一旦稳定化,就脱离了手指的控制,需要手指离开屏幕后再次接触屏幕开始下一次控制。

轻扫E的不同之处在于它可以在受控物稳定化后,仍然控制受控物朝着下一个节点稳定化,在每个节点之间切换时能够明显感觉到分段感,如下图案例所示。

由于轻扫E相对于轻扫 A-D 的特殊性,控制方式中的绝对控制和相对控制无法覆盖这个特殊现象,因此我们使用「多段相对控制」来命名轻扫E的这种特殊的控制方式。

 

2.7.2 定义

使用手指在受控物位置按下后,操控受控物沿着某个方向移动,若手指位移达到阈值,无需手指释放,受控物就稳定在了一个新位置,但是此时手指还是仍然可以操控受控物继续移动的,并且继续移动过程中如果手指位移达到阈值将会到达下一个稳定化状态。

 

2.7.3 特点

轻扫 E 适用于需要在多个对象之间快速切换和确认的场景,它的使用感觉很接近拖拽。如下图所示,我们可以这样理解,当被切换的对象数量接近于无穷大同时每个对象之间的距离接近无穷小时,轻扫 E 就可以视为拖拽。

 

2.7.4 案例

iOS相机人像模式切换打光方式、微信的通讯录滑动字母索引导航,它们都使用轻扫 E 来满足多个对象之间快速切换和确认的需求。

 

3 实战案例

了解完上述的维度和常用手势后,我们在脑中就可以形成一个思考框架。当我们要针对一个功能设计位移类手势时,就可以从阈值类型、稳定化效果以及控制方式这三个维度思考。接下来我用一个我参与过的实际项目作为案例给大家讲解一下思考过程。

本案例是网易云音乐陌生人版一起听中的一个功能,一起听的双方在听歌过程中会收到彼此共同信息,比如听歌口味相似度、是否同城、都喜欢哪些歌手等,目的是为了增加可玩性和互动性、降低退出率,鼓励用户互相了解、提高一起听过程中的社交体验。

为了营造仪式感和避免信息过载,共同信息的展示方式设计为了一次只能看一条,进入浮层后默认展示最新的一条,可以通过滑动查看上一条。因此为了避免出现两条同时占据展示区域的混乱状态(如下图左),我们为其添加了释放后稳定化效果(如下图右),同时为了方便用户可以快速浏览旧的共同信息,这里使用的稳定化效果是较弱的,用户可以通过滑动一次切换多个共同信息。

由于需要满足用户快速浏览旧的共同信息的诉求,阈值类型选用了「判定手指位移和释放速度满足任意一个即可」,用户可以通过控制释放速度进而控制信息的切换数量。控制方式则选择了掌控感强的绝对控制。最后的结果如下图所示。综合三个维度进行归类,此手势为稳定化效果较弱的轻扫 A 。

 

4 手势角度的处理

位移类手势的方向一般为上下或左右,但并不是一定要完全垂直或水平才能够触发手势。当上下滑动和左右滑动同时存在于一个页面时,默认会有一个容错角度,比如上滑时手指滑动方向只要左右偏移不超过 45° 都会被判定为上滑,如下图所示。

但是有时开发同学出现失误,导致容错角度没有均分,例如下图中触发上滑和下滑的角度极小,导致用户在上下滑动时非常容易误操作为左滑和右滑。

云音乐也曾有过类似的遗留问题,iOS 端的播放页上滑调出评论页极易误操作为左右滑动黑胶切歌(如下图 A ,现已修复),安卓端的账号侧边栏上滑浏览极易误操作为左滑收起侧边栏(如下图 B )。

因此,在验收阶段,除了上述的三个维度外,角度的容错性检查也是重要的一环。因此在验收时间充裕的情况下,最好要切换不同的手持方式分别体验一次,因为有些问题只有在特定的手持方式下才能够被发现。

客户端的角度判定方式实际上是一个比较复杂的过程,上述的内容是简化的版本。后续将延展为一篇独立文章给大家仔细聊一聊。

 

5 客户端的差异

上文讲到,基础的三个维度即阈值类型、稳定化效果和控制方式决定了手势的类别,是设计阶段一定要定义清楚的。但是除此之外,设计一个手势需要定义的细节非常多。比如受控物的移动是否有速度曲线?手指位移与受控物之间的位移的比率是多少呢?这些都是开发阶段不得不面对的。幸运的是,安卓和 iOS 有系统封装好的一套系统组件可以调用,操作系统自行解决了刚才讲到的细节问题,但是 H5 框架下是无法调用系统组件的,手势的各种细节都需要前端开发人员自己编写,难度较大,大部分情况只能实现一些比较简陋的效果,这也是为什么在很多 H5 框架下的界面滑动的体验比较差的原因。

 

6 高效沟通

由于信息不对称,与开发的沟通过程中,很容易出现理解偏差。比较常见的错误有:将甩动误解为轻扫 A ,将轻扫 A 误解为轻扫 B 或甩动。如果造成效果达不到预期的情况,很多设计师不知道如何让开发同学修改,只能说“这个手势不丝滑,优化一下”,开发同学也是一头雾水,不知道往哪个方向优化。如果我们能够直接说出“阈值判定方式现在只有手指的位移,需要释放时的速度也能够触发跳转;这个位移的阈值太高了,滑动时很难触发跳转,需要把阈值改为 16pt ”类似这样准确的描述,就能够大大降低沟通成本,顺利验收。为了避免沟通出现问题,下面我将日常经验总结出现希望能够帮助到大家。

首先,一旦涉及到位移类手势,除了必要的文字描述外(可参考上述的手势定义的描述),最好给开发体验 demo 或者其他 App 上类似的效果,否则很容易产生理解偏差。各种 App 上的类似效果大家可以用本文的每个手势的案例给开发同学展示,但是 App 可能会更新,案例可能在未来某个时间就找不到了,所以我用 Principle 做了一个简易的基础 demo 集合(如下图,源文件在文章末尾下载),和我上述介绍的手势是对应的,大家可以拿着这个 demo 给开发同学演示大概的效果,也可以在这个 demo 源文件修改。

下载链接: https://pan.baidu.com/s/1iaFrcFwzC58TG3L17bjC_Q  密码: asto。

拖拽和甩动由于需要定义的细节参数都被操作系统提前封装好了,一般不需要我们给到额外的标注。但是对于轻扫,我们需要将细节定义清晰,下面将详细讲解。

 

6.1 阈值类型

上文讲到,阈值类型一般有两种:

  • ① 判定手指位移和释放速度满足任意一个即可
  • ② 仅判定手指位移

①的开发成本高于②。

如果我们选用轻扫的阈值类型是①,开发同学编写代码需要两个参数的阈值,分别是手指位移和释放速度。手指位移阈值一般默认为受控物的1/2,例如下图的全屏短视频和 Banner 。

当然我们也可以自定义一个阈值,比如 100pt 、受控物高度的 1/6 等,没有特别的需要的话使用默认值即可而且也不用给开发同学特殊说明,但是如果有特殊需要想要修改默认值,就要告知开发同学你自定义的手指位移阈值。对于释放速度阈值,通常默认就非常的小,几乎是大于 0 即可触发,一般情况下使用默认值即可。

在本应该选用①的场景中,如果由于技术成本原因不得不选用②,需要注意的是由于缺少了释放速度的判定,手指位移的阈值我们需要设置得小一些方便用户触发,否则就会出现上文中美图秀秀浮层的那样的体验问题。经过我的实验,手指位移阈值一般定为 16pt 是比较适中的,既不会太容易误操作也不会难以触发。

 

6.2 稳定化效果

轻扫是一定存在稳定化效果的,关键在于告知开发是释放前稳定化还是释放后稳定化。从开发的角度讲,系统会监测用户的行为,用户在使用滑动时会有按下(down)、移动(move)、抬起(up)三个行为,释放前稳定化是在移动阶段判断阈值并触发操作、释放后稳定化是在抬起后判断阈值并触发操作,开发成本几乎没有区别。

上文提到过稳定化效果强弱的概念。稳定化效果越强,单次滑动能够切换的选项个数越少,效率越低。稳定化效果越弱,单次滑动能够切换的选项个数越多,效率越高。首先,我们需要确定单次滑动允许切换多个还是只允许切换一个,如果允许切换多个,开发同学会设定一个控制切换难度的系数,而只允许切换一个的话就不存在这个系数。通常我们也不需要修改这个默认系数,但如果想让操作更加难或容易触发,可以告知开发同学修改这个系数。

 

6.3 控制方式

绝对控制比相对控制的开发成本高,如果开发资源并不是很紧张,需要绝对控制的场景就不要退而求其次使用相对控制。涉及到轻扫手势一定要告知开发同学控制方式,否则很可能被视为相对控制处理。

 

7 手势排查

通过本文的学习,我们不但可以在开发工作进行前与开发同学高效沟通,保证开发工作的顺利进行,也可以对自家移动端产品的现有手势进行逐一排查发现问题点进行记录,并且找到合适解决方案,然后用准确的语言描述给开发同学。下图是我在进行手势排查后输出的表格,挑选出一些有代表性的案例给大家作参考,开发同学可以通过它快速明确问题,理解解决方案。

 

结语

本篇文章的归纳总结是通过日常积累和思考得来,希望能够帮助大家在设计与沟通层面解决实际问题,如果有任何疏漏和不严谨的地方,希望大家能够指出,后续的更新会将专栏不断完善,交互手势系列暂定的后续更新计划如下。

基础篇:

  • ①位移类手势(本篇文章)
  • ②点击类手势
  • ③其他类手势

进阶篇:

  • ④交互手势的特性

超越篇:

  • ⑤设计创新型手势

有兴趣的小伙伴可以持续关注哦~

文章提到的 Principle 格式的手势 demo 下载链接: https://pan.baidu.com/s/1iaFrcFwzC58TG3L17bjC_Q  密码: asto。

 

参考书籍:

《交互设计语言:与万物对话的艺术》 作者: 罗涛

《交互设计精髓 4》作者:[美] 艾伦·库伯 / [美] 罗伯特·莱曼 / [美] 戴维·克罗宁 / [美] 克里斯托弗·诺埃塞尔

 

参考文章:

百度APP「表情面板」体验升级

微信视频号为什么没有采用全屏沉浸式交互

 

参考网站:

iOS Human Interface Guidelines

 

原文地址:站酷

作者:Ballen成明

转载请注明:学UI网》交互手势全解析之位移类手势

蓝蓝设计建立了UI设计分享群,每天会分享国内外的一些优秀设计,如果有兴趣的话,可以进入一起成长学习,请扫码蓝小助,报下信息,蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作,也请与我们联系。

截屏2021-05-13 上午11.41.03.png


文章来源:站酷   作者:陈皮Celia 

分享此文一切功德,皆悉回向给文章原作者及众读者.
免责声明:蓝蓝设计尊重原作者,文章的版权归原作者。如涉及版权问题,请及时与我们取得联系,我们立即更正或删除。

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务


从4个方面,深度解析App中的卡片切换与交互手势

前端达人

最近收到小伙伴的一个问题,以下两种卡片切换怎么用。

以下是我收到的两个不同案例,第一眼给我们的感受就是这两个case不都是可以通过手指左右滑动嘛?

从4个方面,深度解析App中的卡片切换与交互手势

好像有区别,但是具体有什么区别,分别可以怎么用,一下子又说不上来,那么大家可以来听听我的理解!

形态、手势与预期

不知道大家家里是否有两种门,一种是转动把手可以向内或者向外打开的,另一种是拽动把手进行左右移动的,就像下面这个样子。

从4个方面,深度解析App中的卡片切换与交互手势

我们可以通过把手和门的样式判断出如何对其进行操作,所以两种卡片,首先在形态上就有区别,一种是平铺一种是叠加,也就是一个是二维一个是三维。所以有小伙伴问要问,那又怎样,实质上都是卡片切换,为什么在banner上不可以用叠加态呢?

除了在形态上的区别外,还有交互手势的区别,大家以为叠加和平铺都是轻扫切换吗,首先这两种形态都有通过轻扫手势可以进行状态切换的过程,但实质上,叠加状态控制的是当前卡片与下层卡片,而平铺状态控制的则是一整个轮播容器,并且叠加卡片除了轻扫以外还可以拖拽。

从4个方面,深度解析App中的卡片切换与交互手势

这里再说一个交互手势的区别:轻扫(swipe)、甩动(flick)、拖拽(Drag)的区别,拖拽和前两者比较好区别,大家应该都玩过地摊游戏像套圈圈,轻扫和甩动就像你站在原地往目标一扔,而拖拽就像是你探出半个身子,把圈放到最近的一个玩具头顶上再放手,是不是很形象

从4个方面,深度解析App中的卡片切换与交互手势

那么轻扫和甩动的区别是什么呢,我们这里简单的描述两者在可见范围内的区别,比如:

1. 惯性

比如我们操作移动端信息列表的时候,大拇指对于内容界面的滚动进行的是甩动,上滑后页面不会马上停下,而会滚动一会再停下。这就相当于给了一个物理世界的摩擦力的效果,但是轻扫则几乎不明显。

2. 位移

轻扫所经过的位移较短,基本上在该容器中发生位移变化,虽然两者其实都可以不限制方向,但是位移的距离是有区别的,轻扫更短,甩动更长。

3. 力量

轻扫无论你的初速度还是力量多大,都只能完成稳定的动作与状态,例如侧滑删除,不管再怎么用力和加速都只能让对象在指定的范围内呈现。

4. 范围

这个其实很有意思,不知道大家最近是否更新了iOS,更新的同学可能在编辑闹钟页面会觉得想要原地爆炸,因为我们看下图

从4个方面,深度解析App中的卡片切换与交互手势

无论是轻扫还是甩动,我们都需要有一个明确的范围,在老版本中的时间切换,轻扫和滚动都能很快速的选择到时间,因为我们可以同时看到上下文并且做出预判,但是新版本就变得有点阿西吧的感觉,为了更精准的选择到时间我们必须从轻扫/甩动换成滑动,甚至类似于拨动的手势,难用至极。所以轻扫的范围也会比甩动的视觉范围更小。

那么轻扫和甩动怎么区别呢,大家可以理解为,轻扫是在甩动的基础上给被拖动对象增加了稳定效果,所以既然增加了稳定效果,那么惯性和位移都被固定、稳定化了,比如列表左滑删除,tab左右滑动的切换。

从4个方面,深度解析App中的卡片切换与交互手势

从4个方面,深度解析App中的卡片切换与交互手势

另外,大家可能觉得甩动和轻扫可以控制我们界面中大部分对象,可以帮助我们浏览,而且要我们可以将甩动进行稳定的轻扫控制。但并非那么简单,我举两个糖炒栗子,例如音量和进度的调节,我们是不可以用甩动或者轻扫,因为无法准确控制,只能使用拖拽。

从4个方面,深度解析App中的卡片切换与交互手势

5. 知乎的悬浮按钮

另外在知乎的话题切换中有个悬浮按钮,这个按钮不知道大家是否操作过,他既可以拖拽,也可以甩动,问题来了,如果对其甩动会出现两种情况,第一种,返回屏幕一侧吸附,第二种吸附到屏幕另一侧。

从4个方面,深度解析App中的卡片切换与交互手势

两种情况取决于你是否甩动过了某一条“边界”,也就是说你的手指在控制这个“圆形”对象时,何时进行了“关闭”(也就是何时手指离开了屏幕),所以这里咱们要说的是,如何选用手势进行对象控制,要取决于具体的场景和需求,这里的圆形控制器并不需要非常精准位置,所以对其赋予了拖拽和甩动两个手势,那当然这里轻扫也可以啦,只是没什么卵用。

6. QQ的未读气泡

还有比如qq的未读气泡,拖拽和甩动都可以删除它,但是轻扫不行。

从4个方面,深度解析App中的卡片切换与交互手势

其实这些规则我们在交互动效的工具中都可以很好的体现,比如拖拽开始-拖拽结束,对应的就是手指的接触拖动-手指的离开。

从4个方面,深度解析App中的卡片切换与交互手势

所以做个小总结,轻扫是甩动的稳定化效果,并且适合距离较短的进行操作,轻扫和甩动都是非化操作。

我们再回到这个案例本身,叠加和平铺卡片的交互手势,叠加卡片利用的是轻扫,并且还具有拖拽的手势属性,而平铺的卡片可以轻扫,相当于单张浏览,类似banner切换,并且也可以具有甩动的可能,比如淘票票的热映卡片,不过平铺的时候一般单张卡片不适用甩动,轻扫即可,因为单张卡片使用甩动,信息基本看不清楚,多张卡片使用甩动更容易提高检索的效率。

从4个方面,深度解析App中的卡片切换与交互手势

另外用过探探的老司机们都知道,喜欢哪个美女帅哥就往右边“扔”卡片,为什么是扔呢,因为这个“扔”包含了选择的意思,就像性感的荷官在发牌一样,这张卡牌就是你的了!当然,既然发给你了,你也不能退,再想找回来就难咯

所以其实在手势上,叠加态的卡片切换在我们的预期和常规使用中,有着选择、不可逆的属性,那这就和平铺的二维卡片切换就完全不同了。

从4个方面,深度解析App中的卡片切换与交互手势

对比

叠加态的卡片更不方便信息对比,而平铺卡片则可以,例如腾讯视频的vip等级卡片切换。没有对比就没有伤害,不造成伤害,就促进不了买卖。所以你看非诚勿扰都是排一排给你选的而不是一个出来不行换另一个,因为你不知道下一个会不会更不喜欢。

从4个方面,深度解析App中的卡片切换与交互手势

神秘性

叠加态的卡片就像是德州扑克一样,不知道大家是否all in过,是否赌赢过最后一张牌,在没有发出那张牌的时候,我们总是抱着期望,所以叠加的卡片,在我们普通人的预期中是潜意识的提高的,而平铺的卡片就像已经发在你手里的卡片,你可以观察、对比,但是没有了未知感和神秘感,所以抖音是如何让你上瘾的,让你沉浸在其中的,大家现在可以理解了吗。

从4个方面,深度解析App中的卡片切换与交互手势

有限与无限性

叠加态的卡片在展示上会给你一些样式,告诉你这里有好多张,并且是永远切换不完的,而平铺卡片则通常需要告知用户外这里有几张,你看到了第几张,所以又多了一个轮播指示器来帮你记忆。

从4个方面,深度解析App中的卡片切换与交互手势

从4个方面,深度解析App中的卡片切换与交互手势

综上所述,方案没有好坏,只有适不适合当前的场景。所以,在什么场景下用什么样的切换大家学废了吗?


转自:优设网

蓝蓝设计www.lanlanwork.com )是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 平面设计服务

日历

链接

blogger

蓝蓝 http://www.lanlanwork.com

存档