“诱惑“用户-提高用户使用黏性的方法

“诱惑“用户-提高用户使用黏性的方法:

还记得和爱人难忘的约会情境么？出门前花时间打扮让自己看起来更动人；见面时做出各种有趣的行为来与对方交流：互相调侃在适当的时候送上美丽的笑容,问卖萌的问题,“意外地”擦到对方的手。这些信号传达着“我对你的感觉不错，和我在一起吧，你一定会开心的”,那么我们的设计呢？

如何诱惑用户，让你的设计对用户更具有吸引力，也同样需要一些手段的，让我们来一起探讨下吧。

手段1.差异化设计

例如：Clear

这款应用将“简洁”设计理念实现得恰到好处。吸引用户群体去追寻那份最初使用的心动感，通过创新理念为用户塑造了专属的个性，才会在众多同类产品中脱颖而出。

Clear最大的特点就是没有一个按钮，通过单指和双指的不同手势实现任务条拖曳、添加删除线、添加新任务、上下级界面等等，几乎所有的操作都可以用手势来完成，这种交互形式成为亮点。使用渐变色让人感受眼前一亮，让颜色作为重要性排序的标记，在主题选项里面还可以改变任务界面的颜色，在这里视觉设计不是仅凭设计师的喜好，更是起到了功能的作用。

手段2.情趣化设计

例如：比邻

这款社区化应用从开始的引导体验到注册时加入诙谐的幽默语言，让用户感觉到与产品间的交流，积极地愿意去完善资料。虽然用户有时清楚这是产品玩的小把戏，但是在如此具有带入感的前戏台词面前，多数用户会觉得非常有趣，正面情绪完全被调动起来。这样的文案比起简单枯燥的提示更易让用户接受。

如果你的设计无法吸引用户，存在着无法让用户觉得有意义或印象深刻的风险。那么加一点幽默吧，它能使交互更人性化，引导用户产生许多积极的心理效应。

手段3.设置奖励机制

稳定性和可控感固然是是用户界面的关键原则，不过出乎意料的事物也能带来好处。因为当用户不知道将面对什么的时候，他们的渴望也必然会增强。

说到这不得不再次提起clear这款应用：

用户清空条目之后，提示语会发生变化，这里引用的是一段励志名言。它们出现在用户不可预知的时候，是出乎用户意料之外的。但是它的意图又不是要加强一种特定行为，而是为用户带来喜悦。

惊喜另一种表现为奖励，就像微博它是一种把奖励带入惊奇中的产品：

话说我们为什么会经常沉迷在微博中，原因很简单：如果我因为某个目的关注某人的消息，等待其发布最新的我关注的消息。而这些有用的微博消息中通常会参杂一些不相干的内容，但可能接下来会发两条我真正关注的话题。如此让人着迷的原因就是如果我不继续跟踪信息，我可能会错过一些有用的信息。这种可变奖励真得很管用，或者对个人来说很重要，让人很难从无穷无尽的微博信息流中抽身。

手段4.制造兴奋点

在消除游戏当中，我们乐于在混沌中找寻模式，实际上通过解决问题，我们大脑得到一种短暂的快感。

将一种新想法与你已经形成的关于这个世界的心理模型关联起来时也是这样。例如：你可以利用肢体模式的能力去为你的设计制造兴奋点。

例如：Bump

其实通过碰撞以外的途径也是可以传输信息，图片的。但这并不是产品真正的目的，目的是让你能够体验碰撞的兴奋感，花更多时间去使用这款产品所具有的特色功能，让用户独自攻破所获得的喜悦能创造出更好的体验。

手段5.鼓励用户探索

信息分已知和未知，我们重视体验清晰度。我们将不确定因素从用户界面中删除，但是一旦按某种套路去掉了所有可用性陷阱，我们又如何将神秘感重新引入用户的操作中去？简单来说“因为在我所知道和我想知道的东西之间存在空缺，设计中可巧用这个空缺给用户制造神秘感，你要设法将已知的信息转换能某种谜题，鼓励人们去进行探索。

例如：北京西单大悦城的网站-畅游大悦城页面

鼓励人们通过点击楼层，鼠标划过楼层去发现和寻找各个店铺的名称。而不是将所有的楼层信息全部展现，用户需要去查找想知道的未知的信息，必然会积极去体验这种查找的过程。

再例如:

用图形暗示或信息直接制造神秘的感觉，为用户承诺一些有价值的信息—并说明获得这些信息用户需要付出的代价

像许多视频类产品都会开发与之产品配合使用的加速器，下载前会为产品做一个卖点的宣传。实际就是先为用户建立预期：说明这款产品使用后可以获得什么什么样的体验，努力使信息与用户有直接关系，吊起用户的胃口，目前很多手机应用都会在开篇有用户引导画面也会运用这种方式。

手段6.让用户表现自己

我们出去旅游时乐于拍照片留下属于个人的标记，表明我来过这里，我做过这个或者这就是我。家里装饰成田园风格，日式风格…贴满贴纸的手机…我们喜欢表现自我的个性，感受和想法

例如:Path

这款应用是典型的用户表现型的产品

用户可以自定义个人主页的外观，这就是允许用户自我表现。通过发布自己喜欢的图片，音乐和电影，位置与朋友们分享，允许发表言论和评价，选择跟帖或使用表情符号，这都属于一种允许自我表现的方式。只要将这些评论与个人资料链接起来，用户就有机会在网上表现自己

人们如何才能在你的产品上表现自我？那么在你的设计中融入些支持这样自我表现的个性化服务吧， 找机会公布和赞美用户的独特评价，给予用户个性化推荐等等，使自我表现成为用户体验的一部分。

小结

最后想想我们收到的认为最难忘的礼物有什么特点？-个人的，惊喜的，有意义的，令人愉悦的！！！设计亦是如此， 多多激发我们的灵感，我们可以创造出许多令人愉悦和更具有诱惑的体验。




转载请注明出自”百度MUX”

谈谈 jQuery 中的防冲突（noConflict）机制

谈谈 jQuery 中的防冲突（noConflict）机制:
许多的 JS 框架类库都选择使用 $ 符号作为函数或变量名，jQuery 是其中最为典型的一个。在 jQuery 中，$ 符号只是 window.jQuery 对象的一个引用，因此即使 $ 被删除，window.jQuery 依然是保证整个类库完整性的坚强后盾。jQuery 的 API 设计充分考虑了多框架之间的引用冲突，我们可以使用 jQuery.noConflict 方法来轻松实现控制权的移交。
jQuery.noConflict 方法包含一个可选的布尔参数^[1]，用以决定移交 $ 引用的同时是否移交 jQuery 对象本身：

jQuery.noConflict([removeAll])

缺省情况下，执行 noConflict 会将变量 $ 的控制权移交给第一个产生 $ 的库；当 removeAll 设置为 true 时，执行 noConflict 则会将 $ 和 jQuery 对象本身的控制权全部移交给第一个产生他们的库。
例如在 KISSY 和 jQuery 混用，并且惯用 $ = KISSY 来简化 API 操作的时候，就能够通过这个方法解决命名冲突的问题。
那么这个机制是如何实现的呢？阅读 jQuery 源码开头^[2]，首先做的一件事情是这样的：

// Map over jQuery in case of overwrite
        _jQuery = window.jQuery,

        // Map over the $ in case of overwrite
        _$ = window.$,

容易理解的是，jQuery 通过两个私有变量映射了 window 环境下的 jQuery 和 $ 两个对象，以防止变量被强行覆盖。一旦 noConflict 方法被调用，则通过 _jQuery, _$, jQuery, $ 四者之间的差异，来决定控制权的移交方式，具体的代码如下：

noConflict: function( deep ) {
                if ( window.$ === jQuery ) {
                        window.$ = _$;
                }

                if ( deep && window.jQuery === jQuery ) {
                        window.jQuery = _jQuery;
                }

                return jQuery;
        }

再来看上面所说的参数设定问题，如果 deep 没有设置，_$ 覆盖 window.$，此时 jQuery 别名 $ 失效，但 jQuery 本身完好无损。如果有其他类库或代码重新定义了 $ 变量，它的控制权就完全交接出去了。反之如果 deep 设置为 true 的话，_jQuery 覆盖 window.jQuery，此时 $ 和 jQuery 都将失效。
这种操作的好处是，不管是框架混用还是 jQuery 多版本共存这种高度冲突的执行环境，由于 noConflict 方法提供的移交机制，以及本身返回未被覆盖的 jQuery 对象，完全能够通过变量映射的方式解决冲突。
但无法避免的事实是可能导致的插件失效等问题，当然通过简单修改上下文参数即可恢复 $ 别名：

var query = jQuery.noConflict(true);
(function ($) {

     // 插件或其他形式的代码，也可以将参数设为 jQuery

})(query);

[1] http://api.jquery.com/jQuery.noConflict/#jQuery-noConflict-removeAll

[2] https://github.com/jquery/jquery/blob/master/src/core.js

翻译：WebKit for Developers

翻译：WebKit for Developers:
Paul Irish 大湿为我们带来了这篇开年大作，文章深入浅出的阐述了各 Webkit port 的迥异，文笔细腻，是一篇不可多得的 Webkit 入门开胃菜。为了让大家第一时间更好的品尝这道大菜，一丝特别邀请了几位 Webkit 专业开发人士作为本文的翻译顾问，在此表示由衷的感谢！
原文链接： http://paulirish.com/2013/webkit-for-developers/

原文作者：Paul Irish

翻译：金龙Along 

编译，校对：一丝 @jieorlin 

特别感谢：UC 的 roger2yi，heyfluke，百度的 JUSTICE，网易的 unbug
本文涉及到非常多的专业术语，我会尽量补充一些相关资料的链接，翻译不当之处，欢迎批评指正。

对于许多开发者而言，WebKit 是一个黑盒子。我们把 HTML, CSS, JS 和一堆资源放进去，然后 WebKit 以某种方式，奇妙地变出一个中看又中用「美观而实用」的网页。事实上，如同我同事 Ilya Grigorik 所说 …

WebKit 它不是一个黑盒子，而是一个白盒子，并且是一个开放的白盒子。

那么让我们花一点时间来理清一些东西：

    WebKit 是什么？

    WebKit 不是什么？

    基于 WebKit 的浏览器使如何运用 WebKit ？

    为什么所有的 WebKit 并不一样「呢」？

虽然现在我们已经有了很多 Webkit 浏览器了，特别是有消息称 Opera 也已经转移到 WebKit 了，但是想要理解他们的相同点和不同点还是挺难的。下面我将侧重讲这方面，你将能更好的分辨浏览器的差异，在合适的 bug 跟踪系统提交 bug，并了解如何更加高效的针对特定的浏览器进行开发。 标准的 Web 浏览器组件 让我们看一下现代 web 浏览器的几个组件：

• 解析（HTML, XML, CSS, JavaScript）
• 排版（Layout）
• 文字和图像渲染
• 图像解码
• GPU 交互
• 网络接入
• 硬件加速

那么哪些是基于 WebKit 的浏览器所共享的呢？ 几乎只有前两项。
其它的由各自的 WebKit port 负责。让我们回顾下这意味着什么？ WebKit Port 虽然 Webkit 有不同的  ”port”，但请允许我引用来自 Sencha 的 WebKit hacker 兼 eng 主管— Ariya Hidayat 解释一下 ：

WebKit 最常见的参考实现是 Apple 自己的运行在 Mac OS X 上的WebKit 实现（这也是最早最原始的 WebKit 库）。正如你所知，在 Mac OS X 上各种接口的实现使用不同的本地库，大多集中在 CoreFoundation 。比如，你定义了一个带有特别的圆角的平面彩色按钮，那么 WebKit 会知道在哪里以及如何画绘制这个按钮。可是，最终实际画绘制按钮的职责（作为用户显示器上的像素）还是落到了 CoreGraphics  身上。

如上所述，只有 Apple 自己在 Mac 上的实现是使用 CG。Chrome 在 Mac 上的实现使用的是 Skia。

随着时间推移，WebKit 被移植到不同的平台，包括桌面和移动端。这种做法通常被称作“一个 WebKit port”。对于 Safari 浏览器的 Windows 版本，Apple 也把自己的 WebKit 移植到 Windows 上，同时使用 Windows 版（阉割版）的 CoreFoundation 库。

尽管 Windows 版 Safari 现在挂了 。

此外，还有许多其他的”port”（查看全部的列表）。Google 创建了一个持续维护的 Chromium port。还有，这是基于 GTK + 的 WebKitGtk。Nokia（通过它收购的 Trolltech 公司）维护 Qt 的 WebKit 移植版本，一般叫做QtWebKit 模块。（译者注：后来又便宜卖了，现在 Qt 属于 Digia 公司）

一些 WebKit port

• Safari
  
  • OS X 版和 Windows 版的 Safari 是两个不同的 port
  • 用于 Safari 的 WebKit nightly 将会慢慢成为一个边缘化的版本……
• Mobile Safari
  
  • 一开始在内部的私有分支上维护，不过最近代码也合并回主干（being upstreamed）。（译者注：upstream 是开源项目的术语，指其它人或者公司从主干代码开出来的私有分支的代码重新提交回主干）
  • iOS 版的 Chrome（使用 Apple 的 WebView；后面有更多关于它的不同之处）
• Chrome (Chromium)
  
  • 安卓版 Chrome （直接使用 Chromium port）
  • Chromium 也驱动 Yandex 浏览器 ，360 浏览器 ，搜狗浏览器 （译者注：其实国内的壳浏览器太多了，你懂的）等，以及将来的 Opera。
• Android 浏览器
  
  • 使用目前最新的 WebKit 代码
• 还有很多 port ：Amazon Silk（亚马逊 Silk 浏览器）， Dolphin（海豚浏览器），Blackberry（黑莓浏览器），QtWebKit，WebKitGTK+，EFL port (Tizen)，wxWebKit，WebKitWinCE 等等。

不同的 port 可以有不同的侧重点。Mac port 关注的是浏览器内核和操作系统相关的实现部分的分离，它通过 Obj-C 和 C++ 代码把（WebKit）渲染引擎嵌入到本地应用中。 ​Chromium 则更多关注浏览器本身。而 QtWebKit 则把它的 WebKit 实现作为一个运行时的库或者渲染引擎，同其跨平台 GUI 应用程序框架一起提供给其它应用使用​。​​
哪些是所有 WebKit 浏览器所共享的？
首先，让我们回顾一下所有 WebKit port 的共同点。

这很有趣，我试着写了几次。每次都会被 Chrome 团队成员斧正，正如你将会看到的……

1. 首先，WebKit 以同样的方式解析 HTML 。好吧，除了 Chromium，它是迄今为止唯一支持 threaded HTML 解析的 port（译者注：Last week in WebKit: Threaded HTML parser and background blending）。
2.然而一经解析，DOM 树构造依然相同。所以，实际上只有在 Chromium port 中 Shadow DOM 被打开的情况下， DOM 结构才会改变。当然这同样适用于自定义元素。
3. WebKit 都会创建了一个 window 对象和 document 对象。使得通过它暴露出来的属性和构造器（译者注：某种函数）可以在 feature flags 选择打开。
4.CSS解析基本是一样的，把你的 CSS 文件解析成（内部的）CSS 对象模式还是一个比较标准的过程。是的，尽管 Chrome 仅接受 -webkit- 前缀，然而 Apple 和其它的 port 接受遗留前缀像 -khtml- 和 -apple-。
5.排版，定位？好吧，也来点面包和黄油吧！Sub-pixel layout 和 saturated layout （译者注：已经添加链接）算法是 WebKit 的一部分，但是各 port 之间存在差异。
6. 好极了。
所以，事情很复杂。
就像 Flickr  和 Github 通过 flags 标识实现特性，WebKit 也是这么做的。允许 port 通过 WebKit 的编译特性标识 ， 启用或禁用各种功能。这些特性可以作为运行时标识被暴露，也可以通过命令行开关（Chromium 是这样）  ，或者通过配置 about:flags 。
好吧，让我们重新归纳下各 WebKit 的共同点……
WebKit port 的共同点

• DOM，window, document
  
  • 大致相同
• CSSOM
• CSS 解析，属性/值处理
  
  • 无供应商前缀处理
• HTML 解析和 DOM 结构
  
  • 如果我们只考虑 Web 组件，它是相同的
• 所有的布局和定位
  
  • Flexbox，浮动，块级格式化上下文… 所有这些是共享的
• Chrome DevTools （ WebKit Inspector） 的 UI 和各种工具
  
  • 尽管去年4月以来，Safari 为 Safari Inspector 放弃了自有的非 Webkit 的闭源 UI
• contenteditable， pushState，File API，大部分的 SVG，CSS Transform 公式， Web Audio API，localStorage
  
  • 特性尽管后端不同。每一个 port 的 localStorage 可能使用不同的存储层，Web Audio API 可能使用不同的 audio API
• 大量其它的特性和功能

哪些是 WebKit port 不共享的

• 运行在 GPU 上的
  
  • 3D变换
  • WebGL
  • 视频解码
• 屏幕上的 2D 绘图
  
  • 抗锯齿方法
  • SVG & CSS 渐变渲染
• 文字渲染&断字
• 网络堆栈（SPDY，预渲染，WebSocket 传输）
• JavaScript 引擎
  
  • JavaScriptCore 在 WebKit repo. 它和 V8 绑定在 WebKit 里
• 表单控件渲染
• <video> & <audio> 元素行为（以及编解码器支持）
• 图像解码
• 导航 前进/后退
  
  • pushState() 的导航部分
• SSL 特性像严格传输安全性（Strict Transport Security）和公钥

看下面这些： 2D 图形方面依赖于不同的 port ，我们用完全不同的库把它绘制到屏幕上：

或者更微观一点，最近的新特性：CSS.supports()  除了 win 和 wincairo， 所有的 port 都可用 ，同时它们没有启用 css3 conditional （css3 特性检测）特性。
既然我们了解了这些，是时候更加深入一些了。事实上以上的叙述是不正确的。 WebCore 是共享的，WebCore 是一个针对 HTML 和 SVG 的排版、渲染和文档对象模型（DOM）的库，它就是人们通常所说的 WebKit 。实际上“WebKit ”是 WebCore 和 port 的绑定层，尽管在扯淡时这种区别是不重要的。
下图应该有所帮助：

WebKit 里面许多的组件是可交换的（上图灰色区域）。
举个例子，起初，WebKit 的默认 JavaScript 引擎是 JavaScriptCore 。（它基于最初的 KJS （源于 KDE），WebKit 开始只是 KHTML 的一个 fork 分支）。后来，Chromium port 替换为 V8，然后使用独立的 DOM 绑定机制映射上去就完事了。
字体和文本渲染占一个平台的很大一部分。WebKit  有2个单独的文本路径：快速（Fast）和复杂（Complex）。两者都需要平台特定（port-side）的支持，但快速仅需要知道如何 blit glyphs （传输符号）（WebKit  为平台做了缓存），复杂确实需要转换整个字符串到平台层然后说“请绘制这个”。

WebKit  像一个三明治。尽管在 Chromium  中更像墨西哥玉米卷。一个美味的 web 平台玉米卷。”——Dimitri Glazkov，Chrome WebKit hacker，Web 组件和 Shadow DOM 的拥护者。

现在，让我们放大镜头看看一些 port 和一些子系统。下面是 WebKit  的5个 port；尽管它们共享WebCore 的大部分，但它们的 stacks 是不同的。

* iOS 版 Chrome 注解：你可能知道它使用 UIWebView，由于 UIWebView 的能力意味着它只能使用像移动版 Safari 那样的渲染层，JavaScriptCore （替代 V8），单进程模式。尽管如此，大量的 Chromium 代码起衔接作用 ，例如网络层，同步和书签基础设施，地址栏，度量和崩溃报告。（同时，更重要的是，JavaScript 很少成为移动端的瓶颈，缺乏 JIT 编译器（译者注：详细资料）只有很小的影响。）
好吧，那么我们该怎么办？ 现在所有 WebKit 完全不同了，我弱弱的表示害怕。
没必要！WebKit  的 layoutTests 覆盖面非常广（最新统计是28,000  个 layoutTests），不仅针对已存在的特性，而且针对任何发现的回归。实际上，每当你探索一些新的或难懂的 DOM/CSS/HTML5 特性时，layoutTests 常常已经有了奇妙的最小化的示例。
此外，W3C 正在努力研究一致性测试套件 。这意味着我们可以期待不同的 WebKit port 和所有浏览器使用同样的测试套件测试，带来更少的怪癖模式和更彼此协作的网络。所有参加过 Test The Web Forward 大会（译者注：比如去年在北京的分会场） 为此做出努力的人们，谢谢你们。
Opera 刚刚转移到 WebKit了。有何影响呢？
Robert Nyman 和 Rob Hawkes 也谈到了这个 ，但是我将补充一些：Opera 公告的一个明显的部分是 Opera 将采用 Chromium。这意味着 WebGL，Canvas，HTML5 表单，2D 图像实现——所有这些 Chrome 和 Opera 将保持一致。同样的 APIs，同样的后端实现。由于 Opera 是基于 Chromium，你可以深感自信，你未来的工作可以同时兼容 Chrome 和 Opera 。
我也应该指出所有的 Opera 浏览器 将采用 Chromium。因此 Windows，Mac 和 Linux 版 Opera，以及 Opera Mobile（完全成熟的移动浏览器）。甚至 Opera  Mini 轻客户端，将使用基于 Chromium 的渲染替换当前的基于 Presto 的服务器端渲染。
WebKit Nightly，是什么？
它是 WebKit 的一个 mac port ，内部运行跟 Safari 一样的二进制文件（尽管会替换一些底层库）。因此它的行为和特性跟 Safari 全一样。如果你想回到从前，可以考虑它……总之，WebKit Nightly 面向 Safari ， Chromium 面向 Chrome 。 Chrome Canary 包含最进一两天之内的 WebKit 资源。
告诉我更多 WebKit 的内幕。
你已经得到了，同学。

延伸阅读：

• WebKit internals technical articles | webkit.org
• WebKit: An Objective View | Robert Nyman & Rob Hawkes
• your webkit port is special (just like every other port) | Ariya Hidayat
• Getting Started With the WebKit Layout Code | Adobe Web Platform Blog
• WebKit Documentation Overview | Arun Patole
• Rendering in WebKit, by Eric Seidel | YouTube
• web performance for the curious | Ilya Grigorik