如何通过可用性测试来指导设计
最编程
2024-04-14 18:01:33
...
最近总结了一些关于做“可用性测试”的想法,希望可以帮助大家,解决界面设计中的问题。
一、什么是可用性测试
可用性测试是指让用户完成特定的任务,从而发现界面设计中可用性问题的测试方法。
常用的可用性测试方法有“A/B测试”、“卡片分类”、“问卷调查”、“面对面测试”等方式,我们下面重点聊一下“面对面测试”。
面对面测试,即让用户当面来体验我们的产品(也可能是初版Demo,或者原型,甚至是类似的竞品),通过近距离观察用户的操作行为,来发现实际使用中的问题,据此优化我们的设计。
二、设计师为什么要做可用性测试
(1)站在小白用户的角度发现新问题。因为产品设计师对自身产品的功能已经非常熟悉,通过自身想法设计出来的产品,往往和小白用户的心智模型有出入,这个时候就需要通过可用性测试来发现问题。
(2)弥补纯设计理论的不足。,理论和实践还是有差距的,两者相互结合,才能发挥最大的作用。
(3)让设计更有说服力。在项目过程中和产品经理、研发人员讨论时,往往会出现争论不下的情况,而根据以往的经验和理论知识又难以判断。这时通过实际的可用性测试,从用户最真实的角度来重新审视,可以让我们的设计更有说服力。
(4)提升自己的“产品感”。通过和真实的用户不断接触,培养自己“站在用户角度思考”的能力,提升产品设计能力。
三、做可用性测试的步骤流程
STEP1 设计测试任务
首先我们应该为测试确定使用场景,让测试的参与者更有代入感,更好地完成任务。
常见的场景:今天加班完准备回家做饭,现在我们想用这个APP购买食材并配送到家,方便我们直接开始做饭。
然后我们开始设计测试者要完成的任务。通常优先设计与核心功能界面相关的任务,再考虑次要的功能界面。
测试任务应该有一个明确的起点和终点,从哪一步开始,完成了哪一个操作后结束,这些都需要在事先想好。
测试任务不能有任何对被测者的引导和暗示,例如:我们不能直接问:“请找到下单的按钮再哪里,然后去下单”,而是应该告诉被测者:“现在你想买这个商品,你应该怎么做?”然后观察他们是否能够及时发现这个按钮,并且正确理解按钮的含义。
STEP2 招募测试人员
招募的测试人员的大的原则是:尽量贴近最真实的目标用户情况;
比如本次更新是针对老用户的深度优化,那么我往往会找一些对产品已经有一定了解的用户来使用,对比之前的体验,看看是否达到了优化的效果;
如果产品针对的是普通用户或者新增功能,那最好找不了解产品的“小白”用户,从0开始发现问题。
当然,最理想的情况是任何人都能轻松地使用,所以“小白”用户通常必不可少。
关于测试人员的数量问题。之前有研究表明,5个用户足以测试出85%的问题,参与测试的人越多,发现的新问题越少。当然这里需要结合实际工作情况来考虑。
STEP3 开始测试
好啦,现在终于开始测试了。邀请测试用户到会议室,倒上一杯暖暖地咖啡,先简单的做一个开场白,营造一个轻松的氛围;同时要让测试用户知道:目标是测试我们产品的可用性,而不是测试他会不会使用我们的产品。以避免产生不必要的压力。
接着告知用户使用的场景、任务目标,开始体验。
测试的过程中,推荐采用“发声思维”的方式,即让用户在使用的过程中,将自己所想的内容通过声音同步表达出来,帮我我们了解现在的情况和用户内心的想法。
实际操作时,用户往往因为害羞等原因,没有将自己的想法说出来,这时就需要我们进行一定的干预,比如问用户:“你现在在干什么呀?”,“你是怎么想的呢?”来试探用户的想法。
在测试的过程中,我们作为观察者,不能对用户进行暗示和指引,否则会使我们的测试结果出现偏差。
同时我们应该做好观察和记录,用户所说的内容和实际的想法往往不一致,仅听用户说是不行的,用户的实际操作才代表了内心真实的想法。一些细节的动作,微表情,肢体语言都能反映出用户此时此刻是否遇到了麻烦,做好记录,帮助我们改进设计。
STEP4 测试完成
测试完成后,我们可以用“回顾”的方式,和用户聊一聊之前操作过程中的想法,以及对产品的建议。最后再给参与测试的用户一个小礼品作为奖励,一方面出于礼貌和感谢,另一方面也是为了提升“参与测试者”的体验,营造良好的氛围。
STEP5 结果分析
测试完成后,我们需要对数据进行分析处理,用测试的结果指导设计。
(1)整理数据
通常我们用表格的形式,将测试过程中的“任务名、用户体验目标、测量方式、任务目标时间、任务实际完成时间、是否完成”等信息进行统计整理。
(2)分析问题的影响程度
我们可以从“效果、效率、满意程度、发生频率”四个方面,来评估问题的影响程度。根据影响程度的不同来决定哪些需要优先迭代。
(3)详细描述问题
仅仅用表格的形式记录数据十分简略,我们还需要通过详细描述问题,让其他人更清楚具体情况。通常描述问题时,需要包含几个方面:“问题概述、用户任务、用户目标、问题详述、原因分析、解决方案”。
(4)重新设计
结合问题的详细情况给出解决方案,对界面和交互进行重新设计,记得更新后需要再次进行测试,已验证是否解决问题。
四、测试中的实际案例
案例1 观察用户的操作选择
在一次测试APP时,有这样一个取消订单的确认弹窗界面。我们当初在设计这个界面时,为了提示用户“不要取消订单”,将“否”按钮设计成视觉更醒目的深色,而将“是”按钮设计成更为弱化的浅色;同时将“不要取消”的按钮放在容易点击的右侧。
但在实际测试的过程中,发现这样的设计出现了问题。有40%左右的用户,会不小心选到相反的按钮。后来我们发现出现这样问题的原因是:设计的界面与用户通常的心智模型不一致,大部分用户习惯深色的按钮表示“肯定”的意思,而空心的浅色按钮表示“否定”的含义,同时用户更习惯在右侧点击“确定”。
因此为了减少误操作,我们将按钮调整为下面这种更贴近用户心智模型情况。
但实际测试的结果仍不能让人完全满意,仍有少部分用户选择错误,并且大部分用户在思考“哪一个才应该是我想选的选项”这个问题上花费了太长的时间。我们发现出现这样的问题是因为:这两个按钮视觉上较为相似,用户仍需要思考才能区分清楚。
为了增强辨识度,让用户更加轻松地做出正确选择,我们将弹窗修改成如下的样式。
这样的方式按钮之间辨识度较大,并且距离较远,用户可以轻易识别;同时“想关闭就去右上角叉掉”,“想确定就直接点击下方的唯一按钮”这样的方式也符合用户的心理预期。
但是当再一次测试时,仍然发现了问题。因为用户在该界面做“取消订单”的选择太容易,页面停留时间太短。这与我们“提示用户不要取消订单,提升订单存留率”的初衷相违背,因此我们在界面上增加了“选择取消订单原因”的功能。
如果用户不选择原因,则“取消订单”按钮为灰色。通过这种方式增加了用户在“我为什么要取消订单”这个问题上思考的时间,提升订单存留率。
案例2 不要忽视用户的任何细节
之前在测试一款APP的时候,有这样一个订单列表的界面。我们本意是希望用户通过点击“查看详情”按钮来跳转查看订单详情。
但在实际使用的过程中发现一部分用户更习惯点击整个卡片的任意位置来进入查看详情,因为这样会更加方便。
为了满足用户更简便的操作习惯,我们将触发区域由之前的单一按钮,扩大到了整个卡片。
同样在APP中,我们在某一界面上设计了2个按钮:“支付订单”和“查看历史”。点击“支付订单”按钮会跳转订单详情页,然后再在订单详情页上唤起支付。
我们的本意是用“支付订单”这种文字描述,告知客户去付款的位置;但实际测试时发现,大部分新用户不愿意直接点击“支付订单”按钮。他们会先尝试点击“查看历史”按钮,发现无法支付后,再返回来选择“支付订单”。
这个细节引起了我们的困惑,在通过和用户的交流后,我们才了解到用户最真实的想法:用户在决定进行付款之前,为了避免出错,通常必须仔细核对订单内容;同时对于新用户来讲,第一次进行支付的时候对产品的信任感很低。
而最初的界面设计,给新用户的印象是:“我还没有确认具体的订单信息,但是点击这个按钮后感觉马上就要给钱了,这让人非常不安。会不会是恶意扣费软件?会不会给错钱?”。正是因为不安全感,让用户直接忽略了这个按钮。
于是,在页面跳转逻辑已经确定的硬条件下,我们将按钮的提示语修改为“查看待支付订单”,这样“较安全”的提示,打消了用户的顾虑,同时也能体现支付入口的功能。
案例3 观察用户的微表情和肢体语言
用户在使用过程中“皱眉”、“手指漫无目的地不停滑动”、“微笑”、“语气变得不自信”等等微表情或动作,反映了用户的情绪,也代表了用户实际体验的满意程度。
在测试一个报错界面时,我们最初提供了四种不同的解决方案,原本是希望提供多一些解决方案,让用户更好地解决问题。
但是实际情况是,用户在遇到这个界面时,不仅都“眉头紧锁”,“动作变得迟疑”,有些测试者还会下意识地看着我,希望从我这里得到帮助。这些微表情和肢体动作都反映出这个界面对于用户来说十分困难复杂,让人困惑。
为了解决这个问题,我们将原先的四种解决方式,删减为用户操作最方便的一种,让用户不会感到“难以选择和理解”;并且配上了情感化插图,以缓和焦虑不安的氛围。
案例4 听用户的想法但不要照着做
用户往往会向我们讲述一些自己心中的期望。我们应该认真倾听和收集,但切记不要照着用户的说法直接做。
之前的一个项目,业务流程是:首先客户经理与用户聊天对接,然后客户通过小程序去支付,支付成功后再由公司的其他人员为用户提供服务。
当问到用户支付成功后还有什么需求和想法时,绝大部分的用户都提到:“希望马上告诉和自己对接的客户经理,已经支付成功了,请尽快提供服务”。
如果这个时候我们照着用户的说法去做一个新的“支付成功消息提醒”功能,不仅费时费力,还达不到应有的效果。因为提供服务的是另一个人,与客户经理没有任何关系,只是用户自己不清楚而已。
其实这个时候用户的根本诉求是“不清楚我方公司是否及时收到支付成功的信息,担心拖延太长时间才提供服务”。因此,我们在界面上加强了向客户的反馈,并增加显示了进度条,让用户清楚我们已经及时收到了信息,了解现在处在哪一步,缓解用户等待过程中的焦虑。
五、关于可用性测试的其他问题
(1)觉得太专业,太复杂,成本太高,所以干脆不做。
可用性测试对于提升产品的可用性来说,帮助非常大。在资源有限的情况下,可以用“轻量化”的测试代替。哪怕只是针对一两个不确定的小地方,找一两个用户进行简单的访谈,也收益颇丰。
(2)做得太晚,木已成舟。
另一个常见的问题是,开始可用性测试的时间太晚。比如在上线前一天才进行测试,这个时候再做大的调整已经非常困难了,成本会很高。
所以我们往往从项目初期开始,各个阶段都进行可用性测试。有时可以使用简单的原型Demo,手绘的草图,甚至类似的竞品。
推荐阅读
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
什么是可用性测试?有效性(Effectiveness)-- 用户完成特定任务和实现特定目标的正确性和完整性程度;效率(Efficiency)-- 用户完成任务的正确性和完整性程度与所用资源(如时间)之比;满意度(Satisfaction)-- 用户在使用产品时的主观满意度和接受程度。 2.如何获得可用性? 可以参考以下原则:Gould、Boies 和 Lewis(1991 年)为以用户为中心的设计定义了 4 个重要原则: 早期以用户为中心:设计者应在设计过程的早期就努力了解用户的需求。 综合设计:设计的所有方面都应同步发展,而不是按顺序进行。使产品的内部设计始终与用户界面的需求保持一致。 早期和持续测试:当今唯一可行的软件测试方法是经验主义方法,即如果实际用户认为设计可行,该设计就是可行的。通过在整个开发过程中引入可用性测试,用户就有机会在产品推出之前对设计提出反馈意见。 迭代设计:大问题往往掩盖了小问题的存在。设计人员和开发人员应在整个测试过程中对设计进行迭代。 3...什么是可用性测试? 可用性测试是根据可用性标准对图形用户界面进行的系统评估。 可用性测试是衡量用户与系统(网站、软件应用程序、移动技术或任何用户操作设备)交互时的体验质量。4.如何进行可用性测试? l 实验室实验
-
建筑设计可用性测试:如何进行系统可用性测试
-
如何通过可用性测试来指导设计
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
对话NGC蔡岩:从机制创新到价值沉淀,解析DeFi产品开发逻辑 |链捕手 - 真正的DeFi产品首先要有足够的安全性和稳定性,如果能在此基础上有一些功能创新,那就非常好了。像 Uniswap 这样逐渐成为 DeFi 基础架构的产品,可遇而不可求。 链式捕手:固定利率协议之前关注度比较高,但观察下来发现,大部分协议还是类似于传统金融CDO(抵押债务凭证)的玩法,风险系数很高,您如何理解这块业务的价值和风险? 蔡岩:确实有些定息协议类似CDO玩法,背后绑定一个债券,但并不是所有的定息协议都是这样的玩法,像这种CDO玩法的主要代表项目是88mph,背后绑定的是Aave、Compoud这样的借贷协议,在此基础上做定息和浮息债券;像APWine,背后同样是Aave,它会发行期货收益代币来锁定你的收益;Notional本身是做借贷市场的,在此基础上做定息协议。 非 CDO 的玩法,比如 Horizon,更像是一个利率撮合器,背后需要用户通过拍卖产生更合适的目标收益率;像 Saffron、BarnBridge 等是通过风险分级来定义不同的收益率。总的来说,创新还是挺多的。 价值层面是创新和想象力,因为在传统金融领域,比如银行做固定收益证券,或者评级机构给风险分级,这些业务都非常大,利润也很丰厚。而 DeFi 的对口业务给了类似业务很大的想象空间。尤其是固定利率协议的成熟产品不多,尝试各种微创新是很有意义的。 风险程度还是要具体到不同的玩法,比如,在 Aave、Compoud 等借贷协议的固定利率协议背后,如果这些借贷协议受到攻击,与之绑定的固定利率协议也会受损。 同样,如果自己做借贷市场,可能更需要更强的开发能力。再有,如果该程序的机制或参数设计不当,同样会导致协议运行不稳定,并可能造成大量用户清盘。 总的来说,风险在于固定利率协议的设计,这是一个非常复杂的过程,需要不断地尝试和出错。 链式捕捉器:刚刚提到背后是Aave/Compound的固定费率协议风险较大,您认为Aave最大的不确定性和创新点分在哪里? 蔡岩:其实爱钱进一直被认为是走在行业前列的项目,他们的迭代速度非常快,比如率先尝试闪贷、推出新的经济激励模式、推出目前业内首个安全模块、尝试L2解决方案等等。 而在主要的借贷业务上,他们又十分谨慎,比如在抵押率、清算系数等风险参数的设计上相对于其他借贷协议较为保守,并不会存在为了吸引更多借贷资金而降低风险的要求。 与许多 DeFi 项目一样,即使 Aave 进行了多次审计,也无法保证不存在漏洞。前段时间,Aave 刚进入 V2 阶段时,白帽黑客就指出了某个漏洞。 之前的创新点可能是闪电借贷,这是当时业内独一无二的新产品功能,也为 Aave 带来了不少收益。当然,也有人批评闪电贷只能方便黑客实现资金效益的最大化,但工具本身并没有错,未来闪电贷肯定会有更多的应用场景。 其次是安全模块的设计,这有点像项目本身的储备金库,保障项目的安全性,这也是爱维开创的先河。说实话,目前大多数项目都没有做到代币模式的良性或正向运营,也做不到像Aave一样的安全模块,这是一个不小的门槛。 Chaincatcher从某种程度上来说,挖矿模式是DeFi财富效应的根本支撑,但Aave的CEO却说挖矿机制带来的动力是不可持续的,您怎么看这个观点? 蔡岩:"挖矿机制 "不可能失效,因为它是一种激励机制,或者说是项目冷启动的一种方式。但流动性开采亚博体育手机客户端不会一直高涨。比如去年11月的流行性挖矿高APY持续了一两个月就崩盘了,导致DeFi市场大幅回调。 Aave、Uniswap、Synthetix等项目真正爆发进入市值前15名也是在今年2月,我更倾向于这是头部DeFi长期价值的体现。虽然大家都喜欢抢高APY的矿机,但我个人很少参与挖矿,所以我并不觉得流动性挖矿是DeFi的基本面支撑。
-
如何通过网站扫描和Fuzz测试来搜集敏感信息
-
Grid++Report 锐浪报表开发常见问题解答集锦-报表设计 问:怎样在设计时打印预览报表? 答:为了及时查看报表的设计效果,Grid++Report 报表设计应用程序提供了四种查看视图:普通视图、页面视图、预览视图与查询视图。通过窗口下边的 Tab 按钮可以在四种视图中任意切换。在预览视图中查看报表的打印预览效果,在查询视图中查看报表的查询显示效果。如果在报表的记录集提供了数据源连接串与查询 SQL,在进入预览视图与查询视图时会利用数据源连接串与查询 SQL 从数据源中自动取数,否则 Grid++Report 将自动生成模拟数据进行模拟打印预览与查询显示。注意:在预览视图与查询视图中看到的报表运行结果有可能与在你程序中的最终运行结果有差异,因为在报表的生成过程中我们可以在程序中对报表的生成行为进行一定的控制。 问:怎样用 Grid++Report 设计交叉表? 答:Grid++Report 没有提供专门实现交叉表的功能,其它的报表构件提供的交叉表功能一般也比较死板和功能有限。利用 Grid++Report 的编程接口可以做出灵活多变,功能丰富的交叉表。示例程序 CrossTab 就是一个实现交叉表的例子程序,认真领会此例子程序,你就可以做出自己想要各种交叉表,并能提取一些共用代码,便于重复使用。 问:怎样设置整个报表的缺省字体? 答:设置报表主对象的字体属性,也就是设置了整个报表的缺省字体。如果改变报表主对象的字体属性,则没有专门的设置字体属性的子对象的字体属性也跟随改变。同样每个报表节与明细网格也有字体属性,他们的字体属性也就是其拥有的子对象的缺省字体。 问:怎样在打印时限制一页的输出行数? 答:设定明细网格的内容行的‘每页行数(RowsPerPage)’属性即可。另外要注意‘调节行高(AdjustRowHeight)’属性值:为真时根据页面的输出高度自动调整行的高度,使整个页面的输出区域充满。为假时按设计时的高度输出行。 问:怎样显示中文大写金额? 答:将对象的“格式(Format)”属性设为 “$$” 及可,可以设置格式的对象有:字段(IGRField)、参数(IGRParameter)、系统变量(IGRSystemVarBox)与综合文字框(IGRMemoBox),其中综合文字框是在报表式上设格式。 问:能否实现自定义纸张与票据打印? 答:Grid++Report 完全支持自定义纸张的打印,只要在报表设定时在页面设置中选定自定义纸张,并指定准确的纸张尺寸。当然要在最终输出时得道合适的打印结果,输出打印机必须支持自定义纸张打印。Windows2000/XP/2003 操作系统上可以在打印机上定义自定义纸张,也可以采用这种方式实现自定义纸张打印。 问:怎样实现 0 值不打印? 答:直接设置格式串就可以,在“数字格式”设置对话框中选定“0 不显示”,就会得到合适的格式串。也可以通过直接录入格式串来指定 0 不显示,但格式串必须符合 Grid++Report 的规定格式。另一种实现办法是在报表获取明细记录数据时,在 BeforePostRecord 事件中将值为零的字段设为空,调用字段的 Clear 方法将字段置为空。 问:怎样实现多栏报表? 答:在明细网格上设‘页栏数(PageColumnCount)’属性值大于 1 即可。通过 Grid++Report 的“页栏输出顺序”还可以指定多栏报表的输出顺序是“先从上到下”还是“先从左到右”。 问:如何实现票据套打? 答:Grid++Report 为实现票据套打做了很多专门的安排:报表设计器提供了页面设计模式,按照设定的纸张尺寸显示设计面板,如果将空白票据的扫描图设为设计背景图,在定位报表内容的输出位置会非常方便。报表部件可以设定打印类别,非套打输出的内容在套打打印模式下就不会输出。 问:Grid++Report 有没有横向分页功能? 答:回答是肯定的,在列的总宽度超过打印页面的输出宽度时,Grid++Report 可以另起新页输出剩余的列,如果左边存在锁定列,锁定列可以在后面的新页中重复输出,这样可以保证关键数据列在每一页都有输出。仔细体会 Grid++Report 提供的多种打印适应策略,选用最合适的方式。Grid++Report 的多种打印适应策略为开发动态报表提供了很好的支持。 问:怎样实现报表本页小计功能? 答:定义一个报表分组,将本分组定义为页分组,在本分组的分组头与分组尾上定义统计。页分组就是在每页产生一个分组项,在每页的上端与下端都会分别显示页分组的分组头与分组尾,页分组不用定义分组依据字段。 报表运行 问:怎样与数据库建立连接? 答:如果在设计报表时指定了数据集的数据源连接串与查询 SQL 语句,Grid++Report 采用拉模式直接从数据源取得报表数据,Grid++Report 利用 OLE DB 从数据源取数,OLE DB 提供了广泛的数据源操作能力。如果 Grid++Report 的数据来源采用推模式,即 Grid++Report 不直接与数据库建立连接,各种编程语言/平台都提供了很好的数据库连接方式,并且易于操作,应用程序在报表主对象(IGridppReport)的 FetchRecord 事件中将数据传入,例子程序提供了各种编程语言填入数据的通用方法,对C++Builder 和 Delphi 还进行了专门的包装,直接关联 TDataSet 对象也可以将 TDataSet 对象中的数据传给报表。 问:打印时能否对打印纸张进行自适应?支持表格的折行打印吗? 答:Grid++Report 在打印时采用多种适应策略,通过设置明细网格(IGRDetailGrid)的‘打印策略(PrintAdaptMethod)’属性指定打印策略。(1)丢弃:按设计时列的宽度输出,超出范围的内容不显示。(2)绕行:按设计时列的宽度输出,如果在当前行不能完整输出,则另起新行进行输出。(3)缩放适应:对所有列的输出宽度进行按比例地缩放,使总宽度等于页面的输出宽度。(4)缩小适应:如果列的总宽度小于页面的输出宽度,对所有列的输出宽度进行按比例地缩小,使总宽度等于页面的输出宽度。(5)横向分页:超范围的列在新页中输出。(6)横向分页并重复锁定列。 问:如何改变缺省打印预览窗口的窗口标题? 答:改变报表主对象的‘标题(Title)’属性即可。 问:利用集合对象的编程接口取子对象的接口引用,但不是自己期望的结果。 答:Grid++Report中所有集合对象的下标索引都是从 1 开始,另按对象的名称查找对象的接口引用时,名称字符是不区分大小写的。 问:怎样在运行时控制报表中各个对象的可见性?即怎样在运行时显示或隐藏对象? 答:在报表主对象(GridppReport)的 SectionFormat 事件中设定相应报表子对象的可见(Visible)属性即可。 问:报表主对象重新载入数据,设计器中为什么没有反映新载入的数据? 答:应调用 IGRDesigner 的 Reload 方法。 问:怎样实现不进入打印预览界面,直接将报表打印出来?