微信取消 iOS 打赏功能一二三

事件原委:

4月19日下午,微信官方通过其公众号发布了一片公告,其核心内容为“iOS版微信公众平台赞赏功能将从4月19日下午17:00开始被关闭,安卓等其他版本微信赞赏功能不受影响。”微信表示仍然可以通过二维码转账的方式对公众号表示支持,但次日凌晨微信又发布官方通知,宣布紧急对昨天(19日)下午上线的 iOS 版微信公众平台文章个人转账功能进行关闭,意味着二维码转账也不能用了。

根据微信团队的说法,做出这次改动的原因主要在于苹果公司一方。声明中写道:“2016年6月13日,苹果更新了3.1.1条款,更严格要求App 不得包含指引客户使用非 IAP 机制进行购买的按钮、外部链接或其他行动号召用语。”腾讯方面与苹果公司长期沟通未果,最终只能够在 iOS 系统上取消了打赏功能。

苹果方面已经针对此事做出回应,表示微信可以选择提供App内购买让用户赞赏他们喜爱的公众号运营者,微信只需正确使用App内购买体系进行开发即可。并强调“如同我们提供这一选择给所有的开发者一样”。

App Store 审核指南 ( https://developer.apple.com/app-store/review/guidelines/cn/#in-app-purchase )

3.1.1 App 内购买:

  • 如果您想要在 app 内解锁特性或功能(解锁方式有:订阅、游戏内货币、游戏关卡、优质内容的访问权限或解锁完整版等),则必须使用 App 内购买。App 不得包含指引客户使用非 IAP 机制进行购买的按钮、外部链接或其他行动号召用语。
  • 通过 IAP 购买的所有点数和游戏货币必须在 app 内使用且不得过期,并且您应确保为所有可恢复的“App 内购买”设计一套恢复机制。
  • 请务必指定正确的可购买类型,否则您的 app 将被拒绝。
  • App 不得直接或间接地将 IAP 内容、功能或消耗品赠予他人。
  • 通过 Mac App Store 分发的 app 可托管基于非 App Store 机制的插件或扩展功能。

后续事件:腾讯某高管在其公号上发布文章《腾讯高管:为了更自由的用微信,我打算重新买部安卓手机》评论此事,表示自己打算重新买部安卓手机,“虽然可能性不大,但我希望未来苹果公司的股价和在华销量能够告诉它,这种逼迫 App 应用与安卓平台产生功能性差异化的平台政策,是得不偿失的。”

列表式评论:

一、关于公众号:

  • 开设公众号需要提交身份证明付费审核,文章内容在微信管理下,『不适』内容随时可能被删除。
  • 公众号的文章数据完全储存在微信服务器上,微信制定了一系列规则限定公众号的行为。
  • 外链(跳转其它网站)必须有企业资质,个人开号只能链接到微信内其它文章,完全出不了微信。
  • 基于此,苹果认为公众号文章就是微信的功能之一,微信认为是独立个人行为。
  • 微信认为『打赏』是用户间转帐,而苹果觉得这是购买应用内功能。
  • 双方争议在于『公众号文章』是否属于应用本身部分功能。
  • 双方争议还在于打赏功能是否有『解锁』行为。
  • 公众号文章算不算,你自己判断。
  • 你自己判断也不算,苹果说了算。

二、关于 App Store:

  • App Store 内,免费获得,也被定义为一种购买行为,只是价格为零。
  • App Store 内,不改变任何 App 功能甚至连界面都不变的 IAP (应用内购买,简称内购)是存在的。
  • 比如 Doodle God 就有 Thanks to developers 的内购,即打赏。
  • 可以认为,事前付费事后付费,付不付费,都不是定义内购的必要条件。
  • 可以认为苹果觉得没有跳出 APP 范围的非实物付费都属于内购,而微信严格规范下的公众号文章属于此类。
  • 各直播平台 iOS 版的打赏功能确实是用内购充值平台代币的,当然你也可以通过网站或安卓版 APP 充。
  • iOS 充值获得的代币大约就是网页/安卓版的 70%,差额就是 App Store 分成。
  • 苹果的审核标准并不一致,确实有大量开发者抱怨。
  • 2016 年 6 月的标准,到现在才开始怼,苹果在打自己脸。

三、关于事件

  • 微信并没有否认苹果『一视同仁』的声明,而是抛了个暧昧的高官『个人』文章作为回应。
  • 微信沟通大半年并非为达成一致意见,而是想要特权。
  • 商业合作的事,不能叫要特权,应该叫利益分配。
  • 如果按苹果要求开发,至少公众号运营者能拿到 iOS 用户打赏的 70%。
  • 现在微信不干了,公众号运营者的这部分收益降为零。
  • 从这个角度来说,吃相难看的是微信,为跟苹果要特权牺牲作者群利益。
  • 高管 个人 对对方公司股价和销量的言辞,直如街市泼妇。
  • 个人 两字我用了加粗,表强调,显然他不能代表公司立场。
  • 显然 两字也应该用加粗的,我忘了。
  • 即使如此,事件影响到的只有公众号运营者的一部分收益。
  • 所以这事本来就是公说公有理,婆说婆有理。
  • 吃你的瓜。

四、升华主题

  • 微信不会下架 iOS,也不会再有 3Q 大战二选一,都是成年人。
  • iOS 版和安卓版的功能已经有很多区别,以后会更多,这次事件未来回头看,只会是过程中的寻常一节。
  • 当然炒一炒还是可以成为热点的。
  • App Store 优点之一就是严格审核,统一规范带来的体系信赖。
  • 苹果限制多,不全是对用户有利的限制。
  • 安卓更自由,也未必是对用户有利的自由。
  • 苹果只占手机市场份额 20%,App Store 同样只占软件市场 20%,谈不上垄断。
  • 利润份额和利润率不是垄断的指标,但是商业谈判时的优势。
  • 在商言商,本不须谈及道义。然而腾讯某高管似乎忘了自己是怎么对付淘宝、网易云音乐、快的、虾米等的。
  • 同是争取利益,苹果偏执的『一视同仁』,在托辞选择上比微信还是好一些。

五、实用建议

  • 手机号目前依然是别人找你的最好方法。
  • 电话比文字直接,快速,准确,有时也更温暖。
  • 文字比电话含蓄、有存档、有时会误解,会错过时机。
  • 你的相对价值决定了是你担心找不到别人,还是别人担心找不到你。
  • 最有经济能力换手机的人,也最不用担心上不了微信别人找不到他,当然也最不需换手机。
  • 屁股决定脑袋的某高管除外,当然,其实他也不用担心。
  • 强行假设一个对立困境并为之争吵,即使在脑残粉中也是最愚蠢的行为之一。
  • 有人换手机难,有人换 APP 难,苹果害怕失去用户,微信也害怕失去用户。
  • 你是用户,你怕啥。用到不想用,换哪一个都行。

Excel 计算缺陷与大数计算

Excel 很多时候可以当作一个简易的数学计算程序,代替 Mathematica 或者 Matlab 之类的专业软件进行一些不算太复杂的数值运算。但 Excel 的数据处理存在很多弱项,在遇到时需要相应作一些处理。

问题一:有效位数大约只有 15-16 位,更多的位数只会用 0 填充了。

1

精确计算的 2n 的尾数不会是 0,始终是 2→4→8→6→2…… 的循环,但从截图上可以看到,Excel 在计算 250 时,就遇到了有效位数问题,使得末尾出现了数字0。

关于问题一的应对:

从例子中可以看到,Excel 提供了 15 位的精度,这意味在在『千万亿』这个级别上 Excel 依然可以进行精确的计算。相当于以小数点后 4 位精度,即 0.0001 元 = 0.01 分 的精度下,处理九千亿人民币以下的财务数据。处理全国 GDP 的数据也可以精确到分,以米为精度可以让光跑一个月,以毫秒为精度覆盖三万多年。

但是如果你真觉得不够,就需要自己用公式实现进位,使用多个单元格作为『数字段』,来确保每个单元格内的数字长度不超过 15 位。

以 2为例,其计算由两部分组成:

最右一列公式为:

其中,Right 函数保证每个单元格只取结果的最右 12 位,让精度始终符合 15 位上限的要求。而 Text() 函数则保证当截取 12 位数字时,不会将原来在中间位置的 0 因为截取而成为首位 0 消失掉。例如,263 =  461,1686,0092,1369,3952,当截取 12 位时,会获得0092,1369,3952,如果不通过 Text() 函数保存首位的 0,则最后合并回去时就会产生错误。

左边每一列的公式均为:

这个公式同时适用于左边任意多列,使得只要电脑性能过关,尽可用尽 Excel  的所有列(一共 16384 列)。

公式略复杂,以 Y2 为例:

最外层 Text() 依然是为了保留首位 0。Value(Left()) 用于提取右边列的进位数字,即当前列的右侧列如果出现超过 12 位的数字时,则截取头部进到本列。Iferror() 用于检测是否进位。将进位数字和本列上一行数据乘二的结果相加后,再检测是否本列也多于 12 位,如果多则截取。公式引用关系如下:

I9N46D5M6%U}E@8IXWXS8CU

使用类似思想,可以精确进行一次数值变化不超过 1014 的大部分大数计算。需要注意的是,假如一次数值变化较大,则每单元格所能保留的位数就相应变小,不一定是 12 位了。

应对问题一的要点有二, 一是自行实行截取与进位,二是利用 Text() 公式特性,保留截断后的首位 0 不丢失。我通常把这种处理办法称为『大数多列化处理』。

 

 

问题二:数值上限大约在 21024-1,由于有效位数限制,实际上限更小一点,大约在 21023+21022+……+2971 ≈ 1.7977e308 左右。

2

这与问题一不同点在于,这个问题不关注精确展开,而更关注公式计算过程中的上限值。当然,使用问题一中的办法也能解决本问题中的部分情况,但对于更大的数字,例如用尽 Excel 所有列(16384列)也写不下的数字,大约 1016384*14 = 10229376,问题一中精确展开的解法就无能为力了。况且在实际展开中,在装满 Excel 前就早早会遇到内存和 CPU 瓶颈了。问题二的解法注重于在有限的计算资源下计算尽可能大的数字。

我们以计算 361 的阶乘为例,如果使用 Excel 公式直接输入 =Fact(361) 则只会得到一个 #NUM! 的结果。意即该计算的值或者计算过程中已经出现了超过 Excel 单元格所能容纳的最大值。

关于问题二的应对:

我们在 Excel 中准备三列数字,A 列为从 1-361 的展开。C1 公式为 =FLOOR.MATH(LOG10(A1)),B1 公式为 =A1/10^C1。

从 C2 起公式为:

从 B2 起公式为:

于是形成如下形式:

1~P8Q1T0%@[@S4J1CS4Y`U9

即 B C 两列形成了类似科学计数法的 b × 10 c 的数列。但不同之处在于,C 列的所有值全部相加,才是整个计算过程的最终解,如图:

EXWL~KE6X(5_2I4BLEN}%E5

即:361! = B361 × 10 SUM(C1:C361) = 1.43792325888489 × 10768,和上一篇博客对照一下,结果还是很精确的。

仔细观察 B、C 两列数值,其实原理就是每当一个新的 A 乘进来,都对结果作一次科学计数法处理,形成 b × 10 c 结构,确保每一次都有 1<b<10,然后把乘方 c 扔在一边最后再相加。

这一解法的关键在于在计算的每一步都即时处理,避免单元格数字过大而『爆掉』。通过这种方法,Excel 的可计算数域范围从大约 10308 变大到了大约 101,0000,0000,0000,0000,更大的数字则会产生 10 ~1000 倍甚至更大的误差。但如果对 C 列的数字再作问题一解法中的多列化处理,则可计算数上限大约会变成 1010229348 ,这里被迫用了幂的幂。这个数字相当大,并且实际不可能用到。早在这个极限之前,你的电脑内存估计就会挂掉。

 

 

当然,因为有 VBA,Excel 理论上也可以做复杂大数字计算,但考虑到学习成本和应用场景,不如学习 Mathematica 来得方便了。一般使用 Excel 做计算,都仅限于操作单元格和自带公式可以解决的问题。

Excel 自动打印表格份数/序号

#Update:

改进了。现在的样式如下:

0

第一步,先做一张报销单:

从自动化的角度来说,尽量采用公式帮助计算、限定单元格可输入的内容、以及设置单元格格式。在这张单据里,编号单元格为 K1

公式:

对于报销单而言,使用 =SUM() 和 =VLOOKUP() 通常就足够了,至多再加个 =SUMIF()、=COUNTIF() 就足以做出挺复杂的报销单了。

单元格格式:

选定单元格后 『右键→设置单元格格式』。标准的可以选择第三类货币格式,复杂的可以自行定义格式,使用#代表一个数位,使用0代表『当这个数位是最高位但为0时依然显示』。

step1-2

限定填充序列:

选定单元格后菜单栏选择『 数据→数据验证→数据验证』。允许序列,来源直接写入需要的内容,用英文逗号分隔。

step1-3

第二步,添加 Excel 的开发工具菜单:

依次点击菜单上的 『文件→选项→(跳出 Excel 选项窗口)→自定义功能区→☑开发工具』打钩。

step2

第三步,设置打印宏:

点击菜单上的 『开发工具→Visual Basic』,打开 VBA 面板,左侧双击 『ThisWorkbook』,把以下代码粘贴到出现的窗口内,然后关闭窗口

注意 K1 为这篇文章中的编号位置,其它表单需要相应调整。

step3

第四步,添加宏按钮:

点击『开发工具→插入→按钮(窗体按钮)』。

step4

然后用鼠标在 Excel 空白处拖出一个方块,当松开鼠标时,会自动跳出『指定宏』窗口,选择窗口内的『ThisWorkbook.PrintWithNumber』,然后确定。

step4-2

右键点击该按钮,选择『编辑文字』,修改为『打印报销单』。

step4-3

第五步,设置打印区域:

这一步是为了防止把按钮本身也打印出来。

全选需要打印的区域,选择菜单 『页面布局→打印区域→设置打印区域』。

step5

第六步,另存为 xlsm:

由于使用了 vba,必须把文件存为 xlsm 格式。(启用宏的 Excel 格式)

完工。


今天接到一个小任务,寥寥一记。

在 Excel 中,常见的一种需求是打印带份数号码的各种表单,例如报销单、外出单等。通常财务都会提供模板给员工自行填写,再由财务按入帐顺序统一写上序号。但当某人一次性要写几十份,或者说类似的需求,需要一次性打印 N 份时,有没有办法让打印的表格上自动带上序号?

解决办法需要依赖 Excel 中的宏程序,在 Excel 中按 Alt+F11 可以直接打开宏编辑器。或需要先通过『视图』→『宏』→『录制宏』,再经由编辑宏的办法来打开。

核心宏程序如下,一目了然:

E1 为需要填序号的单元格。程序先定义一个变量用来作为页码,然后不断用它替换指定单元格中的值,每替换一次就打印一张。这一方法硬要说有什么缺点的话,大概也就是打印任务数比较多,可能在几千份时会占用不少内存。

更完整的模板还需要在界面上做个按钮和两个输入框,以便让完全没有宏能力的财务也能定义起始和结束页码并打印。但今天这需求仅仅是帮助打印而不是做个新模版,所以这任务也就完成了不再搞复杂了。

样例下载 模板-日常费用报销表

Chrome 44 拼写检查的浏览器性能 bug

Chrome 在更新到 44.0.2403.125 m 后,存在一个由拼写检查导致的性能低下 bug,该 bug 只在 win 版 Chrome 下呈现,同时影响 32 位和 64 位版本。

chrome-44-about

就是这货

具体表现
将上面这段代码另存为 html 网页,在 Chrome 44 (win) 版本下打开。

用文本编辑器制造 10000 行会被触发单词拼写识别的文本,比如使用 Excel 连续生成 10000 行『AKB0048』。复制粘贴到橙色 Textarea 框中,然后用鼠标点击灰色 Input 框……

你会发现,非常的卡,光标在三个输入框中切换,每次切换都需要花费很长时间,对于性能不佳的电脑,和彻底进入死循环没区别了。

刷新页面重置数据后,再将这 10000 行粘贴到 Contenteditable DIV 的蓝色框里,第一次粘贴也略有卡顿,毕竟数据量比较大。但等卡顿过后,鼠标再在三个框中反复切换,就非常顺畅毫无迟滞感了。

10000linta10000lindiv

这就是这个 bug 的真身了:

在 Textarea 有大量会触发拼写检查的内容时,Chrome 44 的 Spellcheck 功能会极大消耗计算机资源,使得整台电脑近乎死机。

解决办法

由于这是浏览器 bug,前端程序员对此几乎无能为力,只能绕过这个 bug。

通常来说,HTML5 已经提出了 Textarea 的一些标准属性,比如 spellcheck=”false” 可以强制浏览器不检查内容,webkit 内核支持这一属性。正常来说,这似乎是很容易解决的一个兼容性问题。

但偏偏 Chrome 却强制忽略了这一设置,就像它强制忽略 font-size < 10 时那样。禁用拼写检查只在用户手动输入时有效,而对于 Ctrl+V 进来的内容,拼写检查依然正常运行,搞死你机。

即使你把相关属性全部列全:

也是然并卵,在别的浏览器一切正常,而 Chrome 下依然故我。并没有解决问题。

解决方法一:

你可以通过 JS 检查当前浏览器是否是 Chrome,在需要粘贴大量内容的 textarea 上提示用户去关闭 SpellCheck 功能,具体位置为:

Chrome 菜单 → 设置 → (最下方)显示高级设置 → 语言和输入设置 → 启用拼写检查。

但这并不是一个好方法,尤其是需要用户主动去对 Chrome 进行设置。

解决方法二:

使用 JS,将一次的粘贴行为,模拟为连续字符添加的行为。比如当用户 Paste 后得到 Text 值,立刻删除该 Textarea 元素再重建一个。然后根据 text.length 使用 JQuery 插件 Jquery.Caret 不断循环插入字符。

这一方法缺点更多,首先是作为 walkaround 的方案,引入了太多并非用户参与的互动。其次,这一 bug 本来就是在大文本量 paste 下才会出现,如果再使用额外的一重循环,并不会使得体验有太多改善。最后,假如 Chrome 的再次升级把 JS 插入字符也纳入拼写检查的话,就会导致页面更 n 倍重的卡顿,到时候大概是再高性能的电脑都扛不住了。

解决方法三:

使用带 contenteditable=’true’ 属性的 DIV 元素代替 Textarea,并使用 innerText 或者 $.text() 来获取用户填写的文本内容。

这也是这篇博客所写的内容,这样的方法是最合法且绕过 Chrome 44 拼写检查 Bug 的方法。完全相当于是『有两种实现方法选择了另一种』。contenteditable = ‘true’ 属性的 DIV 往往也是很多 JS 版所见即所得编辑器的常用办法。比如 WordPress。这一方法不需要用户操作,也只需要少量 JS 代码。最后,即使这个 BUG 的影响范围继续蔓延,也不过是和现有的情况一样,不会更坏。

关于 MAC 版 Chrome:

Mac 下无此 bug,是因为暂时还没有拼写检查功能。

深一步理解客户需求

年前发过一个微信状态:

事实上,用户要求,有时并不是用户需求。随口一提不费钱,或者别有意图不能直说。说没某功能就不买的,有了也不会买。说买去是干嘛的,改进了有时也起反作用。这很容易理解,如果你是学校对面小旅馆老板,因为每天少男少女们来开房『找个安静地方学习』夜夜爆满,会把旅馆改造成自习室?
__tdrd.org_att.php_s.51.42974.596.jpg_唱得好....

这是例行搞笑的。但用户需求却确实是件需要仔细琢磨的一件事情。他们说出口的,常是谎言。

 

一,不好意思说真实原因的。

这个是最常见的。上面的笑话是一例,生活中还有更多例子,大家可以自行琢磨一下。我这里先举个不那么常规的。

日本动漫里的热门人物角色往往也会被制造成各种小人玩偶,做工相当精细,称之为『手办』。有些更会备有大量同比例可更换的衣服。手办通常都是价格不菲的,一个 30cm 高的手办有时就价值 RMB 数千甚至数万元,所以这一开始就是很小众的东西,也只在少数日本动漫专营店放着,作为店长的个人收藏品,兼『镇店之宝』。

这些玩具店是要做生意的,而大部分生意都是几十块钱一件的大路货,卖得最好的通常也是卡片纸、印刷品之类。

于是总有妈妈带着小孩来店里逛的,于是总有小孩眼尖发现了这个镇店之宝的,于是总有缠着妈妈要的,然后就有如下的对话了。

『这个多少钱啊?』

『抱歉,这个不卖的。』

『不卖?』

『嗯,不卖的,放着看的。』

『你家的东西放店里还有不卖的啊,孩子要你就卖他呗。』

『这位妈妈这个真的不卖的。』

『奇了怪了,咋了怕我买不起啊。』

『真不是这意思,这位妈妈,这是花了大价钱专门弄回来的限量版,就是吸引人气用的,真不卖。(真就是这个意思,太贵了你买不起)』

『你不就说贵么,多少钱。你再进一个不就行了,三百顶多了吧。四百?五百?你说你这人摇什么头啊你倒是说清楚啊当我傻逼是不是?』

『阿姨,这东西光每星期保养费就不止四百。我弄来就花了一万多。』

『……』

『…………』

『………………』

『你坑傻子啊,就这东西一万多?就这做工……(发现做工确实挺好)……手脚根本就不能动!哟!这姿势那么撩骚,这是要当鸡的样子啊。你开个玩具店放这么淫秽的东西还放小孩子进来?我要去举报你,趁早倒闭吧你个黑店!』

or

『你这东西还要每星期保养啊?哦哦,钱不是问题,但我家孩子玩劲大爱拆东西,玩两天就要买新的了,算了吧。看你也不是正经做生意的,以后不来了这种黑店。』

你看,很常见吧,买不起时,就找一大堆理由,证明某样东西不值这个价,并试图向围观群众说明,她不是买不起,只是这个东西不符合她的需求,尽管可能旁边连个人都没有。她只是要找个理由说服自己,甚至要依靠打倒对方的人格、名誉,来证明自己『不选择』的正确性。

在这过程中提出来的所有需求,都不是真正的需求。

 

二,为了获得愉悦感。

常见的无非是讨价还价的各种奇葩理由。

我小时候,经常看大人们默契地合演一出戏。这边问多少钱,那边说多少钱,这边说好贵这么小,那边说这可新鲜了,这边说旁边那家店一样的才卖多少,那边说我这足斤足两,这边说多少钱,那边说真卖不了,这边转头走,那边喊回来回来,这边喜滋滋掏钱算着省了多少钱,那边装苦脸心里暗爽多赚了多少钱。

完美配合演绎鸡同鸭讲+欲擒故纵+双簧。演出费两人各……两毛。

虽然钱不多,但是开心呀。

所以那一串理由都不是理由。买东西当然是需求,但讨价还价背后却不止于东西本身了。客户需要的还包括近身白刃搏杀后胜利的愉悦感。

码农们有时就理解不了商务那边的兜兜转转。他们总觉得报个一口价就完了,为什么要扯那么半天皮呢。但在砍价这事上,固然有节约成本的因素,但也有砍杀以后的愉悦。如果你直接一步让到位,不但自己吃亏了,客户那边也没有享受到愉悦。他势必会继续往下砍,直到获得足够的愉悦感为止。

扯会皮,满足了客户,自己也能多赚点,为什么不呢?

 

三、他需要感觉到你的努力。

这是比较隐形的需求了。

首先,客户需要某种特性,是真需。比如需要产品能防水,那是真要。他需要在狂风骤雨的户外使用。因此防水是必须的。

但仅仅有防水,很多时候还是不够。原因在于人的感知与认同。事实上,利用现在的纳米拒水材料,完全可以做出带很多细微网眼的防水材料,足以让产品放入水下依然能见到盒子内部漂亮而脆弱的电路,却如出水芙蓉,滴水不沾。

透光不透水,见干不见湿,要逼格有逼格,要高端有高端。

但是在防水设计上,未来很长一段时间都不可能用这种方案。原因就在于,你的客户并不这么想,而你却没有机会向他演示以改变他的观念。即使演示了,也会被认为是障眼法。或者用一个完全无法反驳的理由回绝:『现在不出问题,怎么保证以后不出问题。』

正常来说,用一个带严实的橡胶密封圈的盒子,用卡扣紧紧卡上,发出的『啪』的一声,才能为客户带来足够的安全感。这比任何高科技都有效。如果说防水的成本有 5 块钱,大约有 3-4 块钱都是花费在让用户感觉上的。

 

四、他需要感觉到自己的妥协,但希望选妥协尽可能小的。

没有成本的东西不足以让人认真对待。别提互联网免费策略,这里的成本可不一定指钱。

我们有两款产品,A 款非常美观,但缺乏某个特性。B 款拥有这个特性,价格还便宜将近一半,但美观性稍差一点。事实上 B 款的出现,也是因为所有的客户几乎都在抱怨 A 款缺乏的那个特性。但结果是,自从有了 B 款以后,A 款的销量反而更好了。

如果你不理解,我再举一个《经济学人》杂志的例子。

《经济学人》有三种定价,电子版 59 美元,印刷版 125 美元,电子版 + 印刷版 125 美元。印刷版的定价让人感到莫名其妙。便宜一点有 59 美元的电子版,付出同样代价又可以同时拥有电子版 + 印刷版,125 美元光购买印刷版,又是何必呢?

看上去《经济学人》提供了一个无意义的产品和定价。但印刷版的定价起到了诱导消费者心理和行为的作用。丹·艾瑞里当时为了验证《经济学人》定价的作用,把学生分为两组人,进行对比测试。结果发现,如果没有125 美元只购买印刷版的选项,84% 的人会选择购买 59 美元的电子版,只有 16% 的人购买 125 美元的电子版 + 印刷版。而如果价格表里,出现了 125 美元印刷版的选项,消费者的购买行为就发生了有趣的变化,只有 32% 的人选择购买电子版,而足足有 68% 的人购买了电子版 + 印刷版。

当进行消费的时候,除非是这个领域的专业人士,否则一个东西应该值多少钱,其实我们不是很清楚的。这时候我们判断的依据就是做一个笼统的测试,粗陋的横向比较,根据结果来决定自己应该买哪个。第二个方案放在这里,它的用途是让第三个方案感觉超值。

虽然产品设计可能和最后定价略有区别,但本质上,定价也是产品的一部分。

 

五、他需要克服自己对你的不信任感,需要安全感。

其实在商务中有很有意思的一点:一个客户对你的质问越多,往往就越愿意选择你的产品。

原因其实也很简单,他作为一个非专业人者,如何去判断产品本身的价值?如何去判断产品是否有看不出来的偷工减料?他是没办法判断的。那么他就会转而通过其它外部信息作出判断,例如品牌、广告、其它人的使用评价等。

很多东西都会指向企业的实力,而实力一定程度上代表着品质。在央视砸了几亿做广告,结果做出来的产品很烂,没人买,这损失可就大了。而街边小摊,顶多城管查抄了,也损失不到哪里去。这就是选择建立信任感的某种方式。

而用户很多让码农觉得麻烦的行为,也正是因为建立双方信任感的需求。其中之一,就是将销售问到无言以对,或者问到自己问不出来。这时,他并不是追求愉悦感,而是追求安全感。他面对的销售有多深的知识积累,就意味着这个产品有多专业,从而产生多大的信任感。买过汽车的同学们可能感受会深一点,卖过汽车的大概已经在微笑了。

而更日常化的最终用户的产品,信任感由更多地来自于品牌宣传、口碑、负面新闻等。因此除了对品控的高要求以外,大型品牌也都愿意每年花费巨资去经营、监测、预警网络上关于品牌的各种消息。舆情监测行业也早已是个水深如谷的行业了。

 

六、人们需要的不是趁手工具,而是被赞美。

少数 Geek 向的玩具,粗糙的质感与不完善的结构,反而可能引发那一小部分人的好奇心。但大多数产品,对大多数人而言,都不过是获得赞美的工具。所以人们才会用各种顶级品牌去标榜自己的品味,用各种先进工具去装饰自己的能力,用各种奇趣玩艺证明自己的知趣广博,用 PHP 去写世界上最好的程序。所以产品设计,要不能为人博得赞美,要不能为人带来赞美。前者靠的是优秀的做工、设计,后者靠的是巨大的人气与流量,比如社交软件。

企业客户在这点上其实也没什么区别。企业客户,往细了分无非也就是建议者、决策者、执行者一系列角色。无论是哪一类,都希望自己做的事情是正确的,能获得上级的肯定,平辈的艳羡,下级的赞美的。这些,则是由内在的可靠性、优雅的外观、良好的服务、精心设计的流程和用户的充分参与,来一步一步完成的。

 

七、用户不懒,只是缺乏动机。

有些产品经理说的用户很懒,其实是不对的。你根本想不到很多人会为了装一个逼能做出多么匪夷所思的行为,根本不理解很多人会为了朋友圈向领导暗示勤奋有多么的勾心斗角,根本不懂得人们心底的欲望可以驱动他们去做多么奇葩的事情。

啊,或许你能理解。

以前我觉得学上网实在是太难了,但后来我发现网上可以下载免费 A 片,瞬间我就学会了。

为了获得赞美,人们无所不用其极。苹果的 Keynote 用的是 『影院效果,彻底迷倒观众』。相比之下,微软用的『做出非凡演示,节约时间,随处访问』就差上一截了。

我真的不在乎节约时间,更讨厌随处都得做 PPT,你再好用有毛用,我在家就想休息不想再碰什么 PPT 了。但如果观众们能惊叹,我能装个逼,那再难用的软件我倒也认了。

————开开心声。

我不认为微软的文案是傻逼,大企业内部的人际历练,对人心的洞察一点不少。但也是同样的原因,让他们在做文案的时候,选择的是讨好公司自己的文化,而不是讨好用户。

用户不懒,只是缺乏动机。

 

结束

用户需求不是『我认为』如何的。每个人处于不同的环境,基于不同的利益,都有不同的诉求。生活中的,工作中的,个人的,家庭的,集体的。同一个人都会有诸多变化。

甚至也不是数据分析能得出来结果的,诚然,数据分析有助于你发现问题,但揣摩背后的意思,还是需要有一颗又能正经又能变态的心。

我品过甜美,也咽过苦涩,但依然觉得那些随口说出的谎言,包括自己的谎言,是世界上最美丽的声音之一。

产品经理为什么需要学习打架

通常情况下,做技术的,尤其是做程序开发的,最期望的事情就是写完一套代码,能一直高效率地用很长时间。“用很长时间”包括两种情况,一是全然不动的,二是只需要小修小补的。而最害怕的,就是今天刚按产品经理的要求写完代码,明天他过来说,“嗳哎唉~~,还需要添加什么什么功能”,甚至是“我们要推倒重来”。

比如说,你是一个工匠,一位顾客过来,想要一个家用烤面包箱。于是你发挥自己的才能,按顾客的家庭人口、住宅大小、生活习惯等设计了个完美的烤面包箱。它不大,因而不占空间且易于清洗;它火力适中,能耗少而依然有足够的热力;它外观精美,与其它家俱协调一致。

等到你在交付时,顾客突然说:“等等我还要拿这个烤蛋糕。”

你满腹牢骚,考虑到自己的工匠名声与招牌技艺,答应了。

然后你重新打造了一个更大的烤箱,兼具烤面包与蛋糕的功能,可以设定两种不同的温度与时间,分别适应两种需求。为了外观你绞尽脑汁,拆掉并抛弃原来的外壳,重新制作更大的外壁隔热材料——由于更大的火力使得原来的隔热材料已经无法胜任存在火灾隐患,你不得不费了巨大的精力去重新选择合适的材料,更大的箱子已经没法放在原来那个地方了,配套的管道也要切割移动。而这次工期变得非常紧……

终于,你还是完成了顾客需要的东西,不负工匠之名。粗粗算来,这个烤箱几乎有一大半的东西都重新制作了,尽管如此,你只是默默地交付了结果,而没有向顾客作任何的抱怨。在顾客看来,你似乎只是很简单地,花了几天时间,把箱子扩大了一圈。

于是顾客提出了新要求:“那你再顺便帮我加个功能,让它能烧水吧”

你考虑到板材需要重新制作,以提供密封防水蒸汽能力。又不能完全密封得留口泄气以防爆炸,于是结构也需要重新设计。为防水烧干,你需要增加一个探测水沸而后停止加热的阀门。这个阀门需要自动控制系统,所以需要一个复杂结构。阀门与输热管道连通,于是管道也需要防水。……

……你回忆起你的家族,历代均以精湛的手艺自豪,家族几代人通过智慧与勤劳,赢得了无数的声名与赞誉,获得了乡坊的认同,终于在这片土地扎根。每一代人,都恪守制作每一件精品的家训,从未改变过。……太多的历史,太多的荣耀,推动着你不断地往更快、更高、更强的道路上前进。你知道,在工匠的道路上,你永不放弃!

于是你胖揍了他一顿。事情就解决了~

 

附此文的更新:

http://kaikai.info/thanks-note/

XAMPP 和 VMWare 的冲突……

确切地说,是对 443 端口的占用。

 

21:51:59  [Apache]     Attempting to start Apache app…
21:52:03  [Apache]     Problem detected!
21:52:03  [Apache]     Port 443 in use by “”C:\Program Files (x86)\VMware\VMware Workstation\vmware-hostd.exe” -u “C:\ProgramData\VMware\hostd\config.xml”” with PID 3304!
21:52:03  [Apache]     Apache WILL NOT start without the configured ports free!
21:52:03  [Apache]     You need to uninstall/disable/reconfigure the blocking application
21:52:03  [Apache]     or reconfigure Apache and the Control Panel to listen on a different port

 

XAMPP 的原因给得很清楚,就是 VMWare 的 hostd 占用了 443 端口。

443 端口是 HTTPS 服务所使用的端口。所以第一反应是去编辑提示给出的 config.xml,希望能修改默认的 443 到其它指定端口上。结果发现不可行,Config.xml 中的内容很多,直接搜索 443 也搜不到。

于是转换思路,从 VMWare 的产品设计思想入手,为什么 VMWare 要给这么一个系统启动就会自启动的服务去占用 443 端口。按照这个思路,果然发现了原因:

image

VMWare 有一个功能是 Shared VM,就是基于网络的共享虚拟机,换成人话就是,真实机器不在你身边,架在真实机上的各虚拟机当然也不在你身边,但肯定又有操作虚拟机的需求。于是就提供了一个远程操作虚拟机的功能,这个功能当然需要加密连接,安全啊。

所以就占用了 443 端口。

当然,我是本机安装所以用不到这个功能,Disable 掉就行了。然后 XAMPP 就正确启动了。