人生倒计时
- 今日已经过去小时
- 这周已经过去天
- 本月已经过去天
- 今年已经过去个月
twitterui(twitterui设计分析)
常用的UI框架有哪些?
常用的UI框架有哪些?推荐6种常用的UI框架。接下来昌平电脑培训为大家分享一下UI专业设计师在日常工作中常用的几种框架,希望能够帮到你!
Bootstrap
说到流行的UI框架,那么Bootstrap是一定会出现在榜单上的。它是由twitter推出的Web前端UI框架,它由Twitter的设计师MarkOtto和JacobThornton合作开发。Bootstrap通过它优秀的栅栏系统,很好的实现了响应式布局。Bootstrap还提供了时尚的排版样式,表单,buttons,表格,轮播等等。
Bootstrap提供了优雅的HTML和CSS规范,它是由动态CSS语言Less写成。Bootstrap一经推出后颇受欢迎,一直是GitHub上的热门开源项目,包括NASA的MSNBC(微软全国广播公司)的BreakingNews都使用了该项目。国内一些移动开发者较为熟悉的框架,如WeX5前端开源框架等,也是基于Bootstrap源码进行性能优化而来。
jQueryUI
jQueryUI是建立在jQueryJavaScript库上的一组用户界面交互、特效、小部件及主题。无论是创建高度交互的Web应用程序还是仅仅向窗体控件添加一个日期选择器,jQueryUI都是一个完美的选择。
jQueryUI包含了许多维持状态的小部件(Widget),因此,它与典型的jQuery插件使用模式略有不同。所有的jQueryUI小部件(Widget)使用相同的模式,这样就大大的降低了学习成本。
jQueryUI继承jQuery简易使用特性,提供高度抽象接口,短期改善网站易用性。同时,jQueryUI采用MITGPL双协议授权,轻松满足自由产品至企业产品各种授权需求。jQueryUI另一大有点是兼容各主流桌面浏览器。包括IE6+、Firefox2+、Safari3+、Opera9+、Chrome1+。而且,jQueryUI有完全汉化的版本,开发包内置包含中文在内的40多种语言包。
PureCSS
Pure也是一款很出色的CSS框架,Pure是来自雅虎的。尽管从UI界面效果上来说,Pure没有Bootstrap那样精美,但Pure是纯CSS实现的,因此非常小巧,整个框架压缩后只有5.7k左右。
最大的特点就是框架基于纯CSS,无任何JavaScript代码,渲染速度比较快。由Yahoo出品,技术上应该不存在太大问题。组件也很丰富,包括表格、表单、按钮、表、导航等。CSS类的标识十分简单,因此在使用Pure的过程中代码会比较友好。
SemanticUI
SemanticUI最大的优点就在它的名字里--语义化。Semantic-UI比Bootstrap更语义化,使用了更容易理解的标签名称:导航的是nav,主要内容的是main,class名也很明确。
而且SemanticUI的modules预制了很多美观的动画,同时也非常简单好用。比如视图(Views)中的评论(Comment)和动态信息(Feed)。

支付宝、App Store、推特的图标为什么都是蓝色的?
天空的颜色是蓝色的,大海的颜色是蓝色的,支付宝和饿了么的 app 图标颜色也是蓝色的。为什么蓝色这么好看?为什么那么多 app 的主色调是蓝色?这篇文章,带你进入蓝色世界,了解蓝色背后的故事。
你有没有发现,很多图标都是蓝色的,比如支付宝、饿了么、App Store、Safari、LinkedIn 等等。毫无疑问,蓝色是 UI 设计中最重要、使用最频繁的颜色之一。
那么问题来了,为什么蓝色如此受欢迎?
其实原因有很多,Nick Babich罗列 7主要个原因:
一、用户就是喜欢蓝色
根据调查数据显示,大多数人都喜欢蓝色。在全球范围内来讲,蓝色也是最安全的颜色。
“颜色喜好”是视觉体验缓解中不可或缺的一部分
不同国家和地区人们眼中的颜色喜好
二、蓝色与大自然和谐相融
看到蓝色,我们总能不由自主地联想到清澈的湖水和明朗的天空。我们都是喜欢大自然的,所以喜欢蓝色也不需要理由。
没有落霞与孤鹜,秋水长天仍然其美侃侃,奇景融融。
三、UI设计师的“第一颜色”
从 UI 设计师的角度来说,蓝色除了有用还是有用。设计师工具盒中的很多颜色,比如红色、橙色和绿色,都已经被贴上了既定标签——它们代表激情、活力和安全。所以蓝色成为设计师的「宠儿」,也不足为奇。
四、给人创新感
通常,蓝色备受各类公司青睐,原因也在于蓝色让人联想到科技与创新。
五、给人安全感
在旅游行业,无论是在线网站还是 app,蓝色都非常常见。蓝色代表着可靠度,这对这个行业的公司来说,益处多多。
达美航空官网
六、让产品更值得信赖
做产品,往往都需要去说服用户,让用户信赖你的产品。在产品中加入蓝色,就是向用户证实产品信赖度的第一步。
像戴尔、IBM、ATT 以及 PayPal 这类科技公司都充分利用了蓝色,向用户传达产品可信度的信息。它们的产品,谁用谁都说好。
蓝色给人一种平衡感,也带有沉稳的特性。因此,不少财务领域的公司也都用蓝色。
七、对弱“视”群体毫无压力
主要的弱「视」群体(红色盲和绿色盲)都能轻松识别蓝色。如果用了红色或绿色,那酸爽,谁用谁知道 。
弱「视」群体看颜色。上图为正常情况下的颜色显示,下图为弱「视」群体眼中的颜色。
蓝色也是 Facebook 的主色调(偷偷八卦一下,其创始人马克·扎克伯格就分不清红绿色,但这丝毫不影响他竞选美国总统啊)。扎克伯格还说:「对我而言,蓝色是最丰富、最饱满的颜色,它在我面前真的是一丝不挂。」
结束语
希望通过这篇文章,你们能了解到蓝色在设计圈如此受欢迎的原因。但如果你现在就想把你的 app 或者网站主色调改为蓝色,这可不在我这篇文章的目的范围内。
蓝色,并非世间最好看的颜色。毕竟,这世间本没有最好看的颜色。
在这个网站或者 app 上好看,也许放在其它地方并不一定好看。安全起见,还是根据目标用户的喜好去选定颜色吧。
毕竟,设计中最恰当的颜色,还是要看用户喜欢什么颜色。
via:36kr
author:Nick Babich
ARPG编年史(完结):
1、80年代:ARPG的起源
2、90年代上:群星璀璨
3、90年代下:经典、仿制与遗珠
4、00年代上:创新与Diablo的克隆体
5、00年代下,第三部等于有生之年?
6、10年代,飞向浩瀚的未来
十万个“是什么”?
1、我们常说的SLG游戏是什么?
游戏开发者之言:
1、MOBA类游戏浅析:Dota、LOL、农药的那些异同
有哪些值得推荐的类似 jQuery UI 或者 Bootstrap 这样的 UI 框架
现在用的最多的就是bootstrap。
1、
BootStrap
(响应式)
时髦、直观并且强大的前端框架,让Web开发变得更加容易。
2.
Foundation
(MIT;响应式)
最先进的响应式前端框架。
3.
960gs(GPLMIT;响应式)
960gs提供了一个简单的网格系统,适合快速开发。
4.
Skeleton(MIT;响应式)
非常漂亮的Web模板,适合响应式、移动友好的开发。
5.
99lime
HTML
KickStart(Free)
适合网站快速开发的极简HTML构建模块。
6.
Kube(Free;响应式)
面向专业人员的CSS框架。
7.
Less
Framework(MIT;响应式)
自适应的CSS网格系统。
8.
Flameinwork(Free)
适合懒人开发者的前端微框架。
9.
G5
Framework(Free)
(x)HTML5、CSS、PHP前端开发框架。
10.
Easy
Framework(Free)
Easy
Framework是一个一体化前端解决方案,分structural、
presentational、interactive三层。
11.
Blueprint(Free)
一个旨在减少开发时间的前端框架。
12.
YAML(Creative
Commons)
(x)HTML+CSS框架,适合开发现代化浮动布局。
13.
BlueTrip(Free)
一个功能全面、并且美丽的CSS框架,适合于Blueprint搭配使用。
14.
YUI3:Grids
CSS(BSD)
YUI
Grids
CSS是最著名的CSS框架之一,是由Yahoo开发小组开发而成。
YUI
Grids
CSS为开发者提供了预先设置的四种不同页面宽度,六种不同的模板。
15.
52framework(Creative
Commons)
对HTML5支持非常好,简单易用。
16.
elastiCSS(MIT)
一个基于Web接口和印刷布局的简单CSS框架。
17.
Emastic(Free)
一个与众不同的CSS框架。
18.
Fluid
960
Gride
System(GPL/MIT)
Fluid
960
Grid
System的模版是根据Nathan
Smith之前的作品而创建的。即960
Grid
System:传承了MooTools和jQuery
JavaScript
libraries的效果。
19.
xCSS(MIT)
一个面向对象的CSS框架,能让你的工作流更加简洁。xCSS基于CSS,可以在开发复杂样式时,提供面向对象的工作流。
20.
EM
CSS
Framework(MIT/GPL)
EM
CSS
Framework提供了一个960px宽
+
12
列网格系统
+
CSS的通用样式。
前端ui框架好看的有哪些
推荐几个精致的web UI框架!
1.Aliceui
Aliceui是支付宝的样式解决方案,是一套精选的基于 spm 生态圈的样式模块集合,是 Arale 的子集,也是一套模块化的样式命名和组织规范,是写 CSS 的更好方式。
2.Amazeui
Amaze UI 是一个轻量级、 Mobile first 的前端框架, 基于开源社区流行前端框架编写的。
3.sui
SUI是一套基于bootstrap开发的前端组件库,同时她也是一套设计规范。
通过SUI,可以非常方便的设计和实现精美的页面。
同时sui还有移动端版本msui,msui是阿里巴巴共享业务事业部UED团队的作品。目的是为了手机H5页面提供一个常用的组件库,减少重复工作。
4.FrozeUI
Frozen UI是一个开源的简单易用,轻量快捷的移动端UI框架。基于手Q样式规范,选取最常用的组件,做成手Q公用离线包减少请求,升级方式友好,文档完善,目前全面应用在腾讯手Q增值业务中。
5.uiKit
uiKit是一款轻量级、模块化的前端框架,可快速构建强大的web前端界面。
6.H-ui
H-ui是轻量级前端框架,简单免费,兼容性好,适用于中国网站。
7.Weui
weUI 是一套同微信原生视觉体验一致的基础样式库,由微信官方设计团队为微信 Web 开发量身设计,可以令用户的使用感知更加统一。包含button、cell、dialog、 progress、 toast、article、actionsheet、icon等各式元素。
8.layui
Layui 诞生于2016年金秋,是一款带着浓烈情怀的国产前端UI框架,她追求极简,又不失丰盈的内在,说她是史上最轻量的结晶,似乎并不为过。一切都源自于她对原生态的执着,对前端社区的那些噪杂声音的过滤,以及她本身的精心雕琢。
9.YDUI Touch
YDUI Touch 专为移动端打造,在技术实现、交互设计上兼容主流移动设备,保证代码轻、性能高;使用 Flex 技术,灵活自如地对齐、收缩、扩展元素,轻松搞定移动页面布局;实现强大的屏幕适配布局,等比例适配所有屏幕。什么?用得不开心?轻松切换 px;自定义Javascript组件、Less文件、Less变量,定制一份属于自己的YDUI;
10、后台UI开发框架 MuseUI
一款基于bootstrap风格,兼容于主流浏览器(包括IE6)的后端UI开发组件。
移动端ui框架的设计要求有哪些?
1、移动端ui框架的设计要求——关注用户体验
可穿戴设备的增长已经放缓了一段时间,但仍在稳步前进。数据显示,全球每10个智能手机用户中就有一个拥有可穿戴设备。随着移动设备的快速扩张,用户对用户体验的要求也越来越高。最重要的需求之一是“个性化的用户体验”。用户体验设计师的成长是可以预见的。用户体验甚至可能成为一个独立的业务,甚至是一个完全独立的职业方向,不同于产品设计、开发、营销、界面设计师等相关岗位。
正是这种需求和意识导致大量应用程序设计人员和开发人员选择关注越来越不重要的特性,并提供频繁的更新,以提供不断增长和逐步优化的用户体验。正是在这种背景下,真正伟大的应用内广告体验和独特高效的导航模式开始出现。
此外,设计师Rehanna Kumari在她的博客中指出,安全仍然是当今设计师和开发人员面临的主要挑战之一。所以在2016年,设计师和开发人员需要处理安全问题和入侵者以及用户体验。
2、移动端ui框架的设计要求——使用模糊背景
模糊背景是过去一年里许多网页设计师的最佳选择。它并不是一种特别新的web设计技术,但随着Twitter的传播,它在应用程序设计中越来越流行。
模糊的背景符合流行的平面和现代风格设计,赏心悦目,并能与鬼影按钮等流行元素很好的搭配,提升用户体验。从设计的角度来看,它不仅容易实现,帮助设计避免复杂的设计,并降低设计成本。
以上便是关于移动端ui框架的设计要求介绍了,正是在这种期望和需求下,越来越多的应用程序诞生了。如果您想了解更多关于ui设计的相关设计技巧及素材等,也可以点击本站的其他文章进行学习。
【译】关于乐观UI的真实谎言
最近在一些致力于前端开发和UX的会议上讨论心理性能优化的时候,我非常惊讶地发现,大家都不怎么谈论乐观UI设计这个主题,实际上,这个名词都未被明确定义。在这篇文章中,我们会讨论它背后的概念,举一些例子,也会探讨它后面的心理学。然后我们将探讨它的概念、要点,和怎样运用。
但正式开始前,我要说,乐观UI并不是一个单独的东西,应该说它是一个界面执行过程背后的心理模型,它有自己的由来和理由。
很久以前,当 tweet 这个词还只指鸟叫、苹果公司还处于破产边缘、人们在名片上还会放传真号码的时候,网络界面是非常禁欲的,大多数看上去都没有一点乐观。
比如,当你点击一个按钮,会这样:
这在2016年可能看起来效率低下,然而令人惊讶的是,相同的情景仍然在许多网页和应用中发生,并且仍然是许多产品交互过程的一部分,因为它可预测和易错:用户知道请求已经被发送到服务器(按钮的禁用状态暗示了这个),服务器一旦响应,页面会刷新,从而清楚地指示了这个交互过程的结束。
这种交互方案的弊病是显而易见的:
首先,用户必须等待,现在我们知道即使最短的服务器延迟都会让用户对整个品牌(而不仅是这个特定页面)产生消极的评价;
另外,每次用户得到的反馈都会以一种非常打扰的方式出现——比如加载一个新的页面,而不是在当前页面上刷新。这会打断用户的任务和心流。尽管我们不必非要讨论多任务,但在这种情况下,任何心理状态的转换都是不让人愉快的。所以如果用户不是本来就要转换心理的话(比如在线付款就是一个转换心理很自然的例子),转换就是一件非常不友好的事情。
之后 Web 2.0 到来,提供了一种新的交互模式。核心技术是 XMLHttpRequest 和 AJAX.
这些新交互模式是用来补充“spinner”(旋转的圈圈)的,一种最简单的进度指示器,唯一作用就是告诉用户系统很忙。现在我们不需要在得到服务器响应后重加载整个页面,我们只需要刷新渲染好的页面的一部分。这让网页更加的动态,让用户的整个操作流更加顺滑和愉悦。
现在点击按钮是像下面这样:
这个新的交互模式解决了上面提到的一个弊病——页面的更新不再是破坏式的,能很好地保留用户的心流。
这种新的交互模式已经广泛应用于各种数字媒体,但它仍有一个问题,用户必须等待服务器响应。是的,我们可以用一些手段让我们的服务器响应得更快,但无论我们怎么加速,用户仍然必须等待。我再说一次,用户不喜欢等待。有研究表明,78%的消费者曾因为网速慢或感觉不可靠而对网站产生了负面情绪。此外,根据 Harris Interactive 的调研,在在线交易遇到问题的时候,23%的用户承认他们诅咒过手机,11%的人对手机尖叫,还有4%的人摔了手机,延迟是其中的一个问题。
即使你在用户等待的时候给他们显示了某种进度指示器,除非你的指示器非常有创意,不然远远不够。在大多数情况下,用户已经习惯了旋转的圈圈表示系统很慢,但是圈圈暗示了一种纯消极等待——这个用户没有任何其他的选择,只能等服务器响应,或者干脆点关闭。
所以现在让我们前进一步,来看看乐观UI的概念吧!
如前所说乐观UI只是一种处理人机交互的方式。为了理解背后的理念,还是拿用户点击按钮的例子来说明——但是原则是通用的,可以用在任何你想要它变得乐观的交互过程中。
让我们从“对未来充满信心”这部分说起。
你认为你的服务器返回错误的概率是多少?例如,当用户点击按钮时你的 API 会经常出错吗?或者,当他们点击链接时?坦白说,我认为错误率很低。当然,数据会随着 API、服务器负载、错误处理级别,以及其他一些前端工程师和 UX 专家都不愿意卷入的因素不同而不同。但只要 API 是稳定的可预测的,前端正确地处理了动作,反馈给用户“出错了”的概率就应该很低,我会说他们不应该超过1%到3%。这意味着在97%到99%的情况下,用户点击一个按钮后,服务器返回的应该是成功,而不是失败。
想想吧,如果我们对服务器返回成功响应有97%到99%的确定,那我们就应该对未来充满信心,嗯,好吧,至少应该比对薛定谔的猫更确定。
我们可以写一个崭新的故事:
就这么简单!至少从用户的角度看没有更多了,没有等待,不用盯着一个禁用的按钮,或者另一个讨厌的圈圈,交互是无缝的,不会有任何粗暴的提示。
从开发者的角度是这样的:
让我们看一些例子吧!你可能很熟悉喜欢(like)按钮,就像 Facebook 和 Twitter 上的那种。我们先来看看 Twitter 的。
用户点击红心后,红心马上变为成功状态。
让我们打开浏览器开发者工具的“网络”,来看看发生了什么。
向服务器发出的请求还在进行中,红心右边的数字也没有更新,但是随着红心变色,用户很明确地知道:成功了——在得到服务器响应以前。
服务器传回成功响应之后,红心右边的数字更新了,但是这个变化幅度明显比红心变色这种形式要小。这让用户的体验非常的顺滑流畅,不被打扰,没有任何等的感觉。
另一个例子是 Facebook 的,情景是相似的,除了 Facebook 不仅立即变换了颜色,而且更新了数字。
需要指出的是,如果我们去看服务器响应时间会发现超过了1秒,考虑到 RAIL 模型推荐的一次简单交互最佳服务器响应时间——100毫秒,1秒显得太长了,但是,因为我们用了乐观UI,所以用户根本没感觉到慢。好极了,这就是另一个心理性能优化的例子。
但是让我们面对现实,仍然有1%到3%的几率,服务器会返回一个错误,或者,用户离线了,或者,更可能服务器返回了一个成功响应,但是响应中包含着需要客户端处理的进一步信息,这种情况下,用户不会得到一个失败提示,但是也不能说这就是成功。为了处理这些情况,我们需要首先知道乐观UI是为什么和怎么样在心理上作用于用户的。
至今我还没有听到过任何主流社交网络上关于乐观UI的抱怨,所以,乐观UI能起作用。但是为什么它们能起作用?简单地来说,是因为人们讨厌等待,好了,你可以跳过这节剩下的部分了。
但如果你愿意继续读下去,你可能会对原因感兴趣。所以让我们探索一下这背后的心理学。
乐观UI有两个值得心理学分析的组成部分:
当我们谈论乐观UI时,我们谈论的是人机交互的最佳响应时间。早在1968年,Robert B. Miller 就发表了一篇影响深远的文章——《论人机交互中的响应时间》,他定义了一个用户可能从计算机得到的多达17种不同类型的响应。其中有一种叫做“对控制激活的响应(response to control activation)”,指的是用户按下一个键到得到视觉反馈之间的延迟,就算在1968年也不应超过0.1到0.2秒。是的,RAIL模型不是第一个这么提的,这个建议早在五十年前就出现了。Robert 写道,这么短的延迟对于一些熟练用户来说都还是显得太长了,理想情况下,用户得到反馈不应超过100毫秒。这是考虑到人类可以执行的最快无意识动作之一——眨眼的时间,100毫秒间隔通常被感知为即时的。伦敦大学学院神经病学研究所的 Davina Bristow 说:“大多数人每分钟眨眼15次,眨眼平均持续100到150毫秒。”他补充道:“这意味着我们每年至少要花9天时间眨眼。”
因为它的视觉上立即反馈的特性(甚至在实际请求完成之前),乐观UI是早期心理性能优化的手段之一。但我们真的不必惊讶于人们喜欢在一次眨眼之间得到反馈这个事实,而且这也不难做到。早在之前,我们就在用户点击之后把按钮立即变为禁用状态来告诉用户他点击了。但是,禁用状态仅仅表示一种消极等待,用户不能做任何事情,也无法控制进程,这会让用户非常沮丧。这就是为什么我们在乐观UI设计中完全跳过禁用状态,我们只传达积极结果,而不是让用户等待。
让我们进入第二个有趣的心理学部分,处理潜在失败。有大量的信息和文章指点我们如何以最好的方式处理UI错误,但在我们讲具体实现方法之前,最重要的并不是如何处理错误,而是,我们什么时候处理。
人类自然地把他们的活动组织成块,以目的或子目的的完结为块的结束。有时候我们把这些块称作“思路(train of thought)”、“思想流(flow of thought)”或简单地称作“心流(flow)”。心流状态以巅峰快感(peak enjoyment)、精力集中和创造力集中为特点。用户在心流状态下完全沉浸于活动中。
在网上,块与块的间隔时间要短得多。让我们回顾一下 Robert 的工作,响应类型包括:
他认为不管是哪种查询,用户得到相应结果的用时都不应该超过2秒。这个间隔时间也取决于一个人的工作记忆(指一个人可以保持一定量的信息在其脑海中,更重要的是,能够运用它们的时间跨度)。对我们开发人员和UX专家来说,这意味着,与元素交互的2秒内,用户处于心流中,并且专注于他们期望获得的回应。如果服务器在此期间返回了错误,用户会保持在与界面的对话中。有点像两个人对话,一个人说了点什么,然后另一个人温和地表示不同意。想象一下,如果另一个人点了很长一段时间的头(就像我们在UI中提供的成功状态),但是最后突然说“不”。很奇怪,对吧?所以一个乐观UI设计,必须要在2秒心流内向用户传达失败。
终于,有了如何在乐观UI设计中处理失败的心理学,让我们来看看那些1%到3%的失败请求吧。
目前我听到的最常见的说法是,乐观UI是一种黑色模式——欺骗,如果你要这么说的话。采用这种设计,我们对用户的交互结果撒了谎。任何法院可能都会这么判呢。不过,我把这种技术视为一种预测或希望。还记得关于乐观的定义吗?现在我们来到了“希望”的部分。“说谎”和“预测”之间的区别,在于如何处理这些1%到3%的失败请求,让我们来看看 Twitter 的乐观的喜欢按钮在离线状态下的表现。
首先,根据乐观UI设计模式,按钮在被点击后立即切换到成功状态,完全与用户在线时的行为一样。
但由于用户离线了,请求失败。
因此错误尽可能快地在心流时间内传递给用户。通常是2秒内。Twitter 以最可能简单的形式做——直接恢复按钮的状态。
这里有些好心读者可能会说,这种错误处理还可以更进一步,告诉用户请求不能被发送,或者发生了错误。这可以让系统尽可能透明。但是这会产生一个,或者说一系列的问题:
好了,现在我们都同意这变得有点复杂了。虽然这种错误处理方法对于像网站上的大型表单来说是合理的,但是对于像点击一个喜欢按钮这样的简单操作来说,无论考虑到开发还是用户的工作记忆,都有点过度了。
我们对于乐观UI中出现的错误应该要保持开放态度,我们应尽可能快地通知用户,让它不成为一个谎言。但要根据内容的轻重来做。对一个失败的喜欢,轻轻地把按钮变回以前的状态就足够了,除非这个喜欢对用户来说特别重要——而那时,点喜欢最好总是有效。
还有一个问题,如果用户在看到成功反馈之后,服务器返回响应之前,关闭了浏览器选项卡,会发生什么?最不愉快的情况是,在用户的请求被发送到服务器之前就关闭了选项卡。但除非用户非常灵活,或有减慢时间的能力,否则这几乎是不可能的。
如果一个乐观UI被正确地实现了,并且只适用于那些服务器响应时间少于2秒的元素,这个用户就不得不在2秒内关闭选项卡。2秒对一次按键来说可能不是特别困难,但是就像我们说过的,有97%到99%的用户请求都是成功的,不管选项卡是开着还是关着,只是回应没有被传回到客户端而已。
所以这个问题。可能只出现在那些1%到3%的用户身上,但是又有多少人会急急忙忙地在2秒内关闭一个选项卡呢?除非他们是在一个关闭选项卡竞速比赛上。我不认为这个数量会很多。但是如果你认为这会影响你的特殊项目或者造成任何负面后果,那么可以用工具做一些用户行为分析,如果出现这种情况的概率足够高,那就把乐观交互限制在那些非关键性元素上。
我故意没有提到请求被人为延迟的例子。这些不是通常的乐观UI设计讨论的范畴。此外,我们已经花了足够多的时间在悲观面了,最后让我们来总结一下实现一个乐观UI的要点。
我真诚希望本文帮助你了解乐观UI设计背后的一些主要概念。也许你有兴趣在你的下一个项目中尝试这种方法。如果是这样,在开始之前,请注意以下几点:
正如我们所看到的,乐观UI设计在网络上并不是一个新东西,也不是一种特别先进的技术,它只是另一种方法,另一种心理模型,以帮助你管理产品的感知性能。基于人机交互的心理知识,聪明地运用乐观UI设计方法,可以帮助你在网络上构建更好、更无缝的体验,而且也不费什么事。但是,为了使模式真正有效,不让它变成谎言,我们必须了解乐观UI设计的背后机制。

