百万个冷知识百万个冷知识

百万个冷知识
一起学习百万个冷知识

从交互的角度讲讲弹窗(中)(对于交互的理解是什么)

撰稿编者按:快捷形式是招揽目光的一类形式,无论是PC端还是终端端都广为采用。责任撰稿译者从可视化结构设计的视角,对快捷形式展开预测,与你分享。

中金他们小聊了呵呵快捷形式的表述与采用的常用情景,下期他们来聊点实际的:快捷形式的文本产业布局,本来下期想把常用的三种快捷形式难题:快捷形式的瓜葛(快捷形式叠快捷形式)、快捷形式的流程关系(连续快捷形式)都讲一遍,但完稿基本上产业布局以后发现字数超了,所以快捷形式那个话题从2期变成3期了。

一、快捷形式的基本上产业布局

以车为例,倘若他们把“车”此种物体身上的零部件分成三种:一类叫基本上配件、另一类叫附带。基本上配件(比如说发动机)是所有车都必须要有的是、没有它车就开不起来,甚至就不能叫车。而附带(比如说座椅、出风口),这些东西惯常,每一样车的配置可能都不太一样。比如说TB10上钳子是挖土机,装上将厂是货车。

在做规范化时,做命令行的逻辑和装嵌是很类似的:命令行的文本产业布局也有基本上配件和附带。基本上配件的差别下定决心了不同快捷形式类别(此种差别是比较大的、情景性的差别);而附带的差别则下定决心了同类别快捷形式的可扩展性(也是你表述的这类别快捷形式,无限大状态下最多能支撑怎样的情景)。

按上一篇文章从可视化的视角谈谈快捷形式(上)来讲,同时实现、重要信息展现、操作形式快捷形式各自的基本上配件可以细线这样:

△也没假使

细线这样了以后他们可以发现,就算是支持繁杂情景的大快捷形式,只不过骨架结构也是单纯的。以JIRA那个操作形式快捷形式为例:

△jira真的很爱大快捷形式

接下来他们就按照快捷形式的基本上框架产业布局来Pellegrue地回收快捷形式的基本上配件与常用附带,繁杂难题展开讲,单纯难题就单纯过:

相对单纯的:罐子、副标题、关闭形式比较繁杂的:文本区、主操作形式按键附带:“不再提醒”

二、快捷形式的罐子

罐子也是快捷形式体积,虽然在做规范化的时候快捷形式体积一般是UI去表述的,但作为可视化他们也须要思考一些事:

快捷形式的体积须要和文本网络连接。正常情况下,快捷形式如果是不须要纵向慢速的(当然横向慢速就更如果避免了)。倘若你的快捷形式体积须要慢速呵呵才能展现全重要信息,如果先考虑它是不是过小。大快捷形式和全网页、不同体积快捷形式之间,如果有明确的界限。可视化须要去界定怎样的重要数据量是快捷形式容纳的无限大,超过那个“无限大”所以快捷形式此种命令行就无法承载、须要采用其他的展现形式。

三、快捷形式的副标题

快捷形式必有副标题,能不能写清楚快捷形式副标题,算是区分合格可视化雕塑家与还差点意思的可视化雕塑家的Tikamgarh。只不过这事说繁杂也不繁杂,只有2个事须要注意:

(1)倘若那个快捷形式是由采用者主动促发的,所以快捷形式副标题如果与采用者促发快捷形式的操作形式按键同名,或者至少有相同的URL。此时快捷形式是采用者操作形式后的反馈,采用者须要通过快捷形式的副标题来确认自己是否进入了恰当的组件、展开了恰当的操作形式。

(2)快捷形式副标题与文本区说明文字要各有分工。一般来讲,快捷形式副标题单纯陈述难题、询问行为或者作出行为建议。文本区的说明文字展开来解释出现难题的原因,以及操作形式后的后果。

当然文案,或者更时髦的说法:UX writing,是一门很大的学问,甚至可以支撑起一个职位。所以这里讲的两条规则只是最为基础的原则,不能涵盖所有的是文案要求(比如说你要是做国际化,所以副标题和正文的首字母大小写、加句号不加句号都须要考虑)。另外,B端的文案规范化有时候也无法推广向C端营销类结构设计,因此本篇暂时不做更多讨论。

四、快捷形式的关闭形式

我之前写了一整篇文章来说明快捷形式的关闭形式:【PC结构设计】快捷形式为什么须要两个关闭按键?,总体而言:

作为一个非常底层的命令行,快捷形式(或者说窗体)如果兼顾大部分采用者的不同习惯,来保持整个系统有比较好的可用性。因此,建议在右上角添加“x”作为关闭操作形式性快捷形式的最短路径,并且佐以键控、点击遮罩等多种关闭形式;除非要求采用者明确表态(比如说要求同意协议)

当然,更便捷的关闭形式代表着更多的误触,如何平衡可用性和误触,就要根据具体情景具体预测了。

五、文本区与主操作形式按键

这两个东西不能分开来讲,它们是快捷形式结构设计里最繁杂、最经常出体验难题的部分。理解了文本区与主操作形式的关系,才能真正理解快捷形式的结构设计。

1. 文本区与操作形式的层级关系

做B端产品时,结构设计系统的稳定是非常重要的一件事。构成结构设计系统稳定的重要因素之一,是命令行的操作形式模式的稳定和一致性。那个部分属于结构设计中比较难以量化验证的地方,就算做得很好,也可能并不能从业务数据上找到特别正向的反馈;但要是做得不好,整个结构设计系统(至少是可视化系统)的逻辑会很快地被繁杂的业务摧毁崩溃。结构设计系统一旦不能自圆其说,那就没有系统可言了。因此为了避免此种情况,做可视化还是须要表述呵呵命令行的基本上层级关系和逻辑。

快捷形式的底栏层级高于文本区:底部操作形式栏上的主操作形式按键承载着全局操作形式,它的行为对快捷形式整体生效、可能会导致快捷形式关闭;而文本区的操作形式只对文本区生效,并不会导致快捷形式关闭。这意味着做可视化的时候,须要在样式上为全局按键、文本区按键作出区分,以免采用者产生困惑。

比如说说倘若他们是一个中学老师,现在正在新增一个班级列表,班级列表里有所有同学的名字:

到此为止文本区与操作形式的关系都还是清晰的,但一旦他们为快捷形式加入导航命令行——tab,那有些人可能就搞不清楚了。

首先他们在做快捷形式的时候,要尽量降低快捷形式的层级结构和文本繁杂度,尽量把采用者完成任务的关键重要信息一开始就展现出来,避免采用者在快捷形式里四处探索。但倘若说因为任务的因素非得在快捷形式上加tab的话,还是须要记住:属于快捷形式文本区的tab的层级低于快捷形式操作形式区。

在windows/mac的应用程序中,那个难题可以被官方规范化提供的group box组件解决——可以理解为把文本区从快捷形式上“框”了起来,在视觉上创造出文本区和操作形式按键之间的层级差别。但是由于当前互联网整体的结构设计趋势倾向于减少层级、扁平化,所以在日常做结构设计时往往不再能采用此种视觉上的处理形式,只能做可视化的人自己心里清楚。

还是以新增班级为例,倘若存在一个按键让他们按呵呵就能上传班级列表的excel,但是excel里有些名字可以读取出来,有些名字包含特殊符号(比如说,、…),须要人为修改呵呵,所以那个快捷形式也许就会这么做:

那个时候跳转到到“读取失败”tab,底部栏的主按键仍然存在——即使你可以给表单设置一些提交限制,要求读取失败的项目没有被手动修改的时候,不允许点击“新增”按键。

反过来说,正因为快捷形式的操作形式区层级比文本区高,并且tab是一个导航命令行而非选择命令行,因此tab+快捷形式的潜台词是“点击操作形式按键后,所有tab中的文本都会被提交,即使有些文本当前没有展现出来”,而不是“只有选中的tab会生效”。因此,倘若你须要让采用者在快捷形式上作出选择,就不要采用tab等导航命令行,而可以选择单选框/多选框此种典型的选择命令行(或者苹果的segemented control这样有点像导航的选择器)。

比如说说他们在新增班级快捷形式上给采用者提供了两个功能:手动新增或批量新增两者的文本区样式不一样,所以画出来则是:

值得注意的是,那个层级关系只能应用在快捷形式上,在网页全网页上往往存在层级高于操作形式按键的全局导航。

2. 文本区与操作形式的映射关系

有的是时候,快捷形式会提供多种操作形式选项,并且每种操作形式选项都会有大段的说明文字。

还是拿学校老师新增班级做例子:校园网新上线了一个功能叫“智能新增班级”,那个选项可以根据你的身份,自动检测你带的学生并填充到表格里,你只须要把他们对应的班级标注出来就好了,不须要一个个手动填写学生姓名,非常方便,所以推荐老师采用。但由于系统还不是很完善,因此只能检测到高中部和小学部的学生,带初中部学生的老师,还是须要手动新增班级。

倘若非要用快捷形式来做新建形式的选择入口,并且还按照他们之前的快捷形式基本上结构来处理,所以有些人可能会做成:

那个案例和诺曼《结构设计心理学》里那个炉灶与旋钮的案例不谋而合。这样结构设计的劣势是,采用者从读完文本区的文字,到去操作形式区展开行为,须要在心里先做一个判断——我是高中小学部还是初中部的老师?然后再做一个映射——高中/小学部点那个“智能新增”、初中部点那个“手动新增”。一来一去反应时间就变长了、出错概率也更高。

因此,他们可以在那个案例上增强文案与选择器的亲密性,让采用者做出判断的瞬间就可以完成操作形式,无需再做一次映射:

甚至,倘若那个任务以效率为第一标准并且规范化表述的比较宽松,他们还可以省略“下一步”按键,直接将点击生效的热区放置在文本区上:

同理,优化操作形式按键的文案也能帮助采用者消化文本区与操作形式按键之间的映射关系。比如说说此种再确认快捷形式:

习惯上来讲他们会将一个快捷形式的积极操作形式(确认、提交、更改…)修改为与快捷形式副标题或文本区联系性更强、更符合情景的说法,比如说说打印机的“打印”快捷形式,操作形式按键写作“打印”而不写作“确认”。这样做的好处也是帮助采用者减少反应的时间。

但另一方面,快捷形式的消极操作形式(一般是取消或退出,注意消极/退出操作形式不等于破坏性操作形式,比如说删除)的文案是不会修改的。这样做是为了让采用者无论在什么情景下,都能感知到“取消”是一个无害的、不会造成严重后果的安全退出形式(和快捷形式右上角的x一样)。

3. 操作形式按键与附带

理想状态下操作形式按键只有2个,但实际情况是多种多样的,所以有时候操作形式区也可能有超过2个按键。

我个人把3个操作形式按键作为快捷形式操作形式区的上限,倘若超过3个按键,所以就如果思考是不是去掉操作形式区,直接把按键放在文本区里,以便帮助采用者合理地判断自己如果按哪个按键。

当存在3个按键时,按键的摆放规则可以根据自己平台的特性下定决心,并没有通行的规则(但一般会将破坏性按键放在主操作形式按键的对侧)。倘若弄不清楚采用者的主要诉求,不用在多个按键中非要选一个推荐操作形式。

最常用的快捷形式附带是“不再提示”按键,选中后提交快捷形式,则那个快捷形式就在采用者或者设备维度不再出现了。那个操作形式常规上用checkbox实现,并且放在快捷形式文本区/操作形式区都可以接受。须要额外注意的有这么几点:

(1)对于同时实现快捷形式来说,点击“知道了”“立即开通”都能算是对快捷形式的一类表,因此选中“不再提示”以后,点击任何一个主要操作形式快捷形式都如果不再展现。而相比之下,选中“不再提示”后又点击“x”就意味比较含糊了,考虑到一般“不再提示”选框都不做默认选中,因此这里选中很有可能是采用者有强意愿,所以点“x”快捷形式也不展现也说得过去。

但对于操作形式快捷形式来说,“取消”是全局性的消极操作形式。在任何情况下,采用者点击“取消”的含义都是“放弃快捷形式上的一切已完成操作形式并且退出快捷形式”,所以这里只要采用者点击了“取消”,无论是否选中“不再提示”,都如果视作选择未生效。虽然这样做在具体情景内有违背采用者预期的可能,但为了全局可视化规则的一致性,这样是更合理的。

(2)有些人比较倾向于把“不再提示”做成操作形式按键。我个人只不过不太理解此种做法。

倘若那个快捷形式具有采用者价值,所以就持续弹好了,没必要设置“只弹一次”的限制;倘若那个快捷形式纯粹是商业化行为,那按键文案写成“我知道了”,直接修改按键的弹出逻辑即可,也没必要告诉采用者错过这次机会以后就不提示了。

责任撰稿由 @白话说可视化 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

未经允许不得转载:百万个冷知识 » 从交互的角度讲讲弹窗(中)(对于交互的理解是什么)
分享到: 更多 (0)

百万个冷知识 带给你想要内容

联系我们