IfDesignedLikeThis。红包口令

　　对于微信的全面封杀，15年2月红包口令的推出，让支付宝在2015年与微信的红包战役中扳回一城。配以接龙红包、逗比红包有趣儿的红包玩法（可馒头还是不知为何今年突然下线），支付宝创造了一种围绕红包的互动新模式。
　　又是一年，今年的支付宝红包口令推出使用户的参与感、存在感更强的自定义口令模式（俗称“定制口令”）。
　　不知，各位少侠对支付宝定制口令的看法如何？
　　
　　某天，馒头混迹的群，某君提出这样一个问题：为何支付宝的定制口令这一步骤是置后的？
　　什么意思？来，画个简易的流程解释下这里的“置后”是什么概念。
　　主流程：a。打开支付宝，包群红包（金额个数）b。支付验证c。生成群红包d。用户自定义定制口令（可选）
　　不知大家看完上述我画的较挫流程后，是否明白了“置后”的概念。
　　就是说，其实c的过程，这个群红包已经生成了，并不是说用户自定义完中文口令后这个群红包才生成。所以这里的讲的前后概念就是说c和d哪一步骤在先。这里请大家注意，虽然d步骤我标注了是“可选”步骤，但仅适用于这个群红包分享到支付宝的朋友、生活圈或钉钉的阿里系app。如果你想分享到微信，口令这步一定是必选的，否则是没有一个媒介渠道去分享的。至于为什么？想想支付宝红包口令推出的背景就懂了。
　　插个话题。有的少侠就问了，我不想用中文口令，太麻烦。我就想用数字口令，可以不？
　　行！当然行！只是支付宝在这块故意弱化数字口令的入口，对于视力不太好的同学来说，几乎是隐藏掉的，不注意看，根本看不到。啥？不信！喏见下图：
　　怎么说呢其实绝大多数家公司每当有新的东西出来时，肯定是大力推动（因为大力出奇迹嘛，哈哈哈），弱化可能吸引用户注意力的地方（说不定支付宝下线接龙红包、逗比红包，来全力支持男神女神红包、定制红包口令也是这方面的原因，不过纯属馒头yy）。当然，这不能说不好，可能在某些少侠眼里这就是QJ（不懂的同学，请自行百度“QJ”）用户，但是如果弱化甚至隐藏的点绝大多数用户并不在意，或者就是觉得新推出的功能更有趣儿，这未尝不是一件好事。既有利于公司战略的推进，也减少了一切可能干扰用户关注点的东西来优化体验。不过，以上一定是基于精确的判断。当然，产品经理的使命就是让正确的事情相继发生，对吧！（温馨提示：一旦少侠你毅然决然地选择生成了数字口令，可就不能再对该红包自定义中文口令了）
　　
　　回到主题上来，为什么定制口令是置后的？哼！我就觉得置前是最优的。即当我定义好一个口令后，再去生成群红包，不挺好的么？
　　再谈这个问题前，说下“口令”。其实，15年的数字红包口令的生成也是置后的，只不过相对来说无感知罢了。再往深了点说，口令就是一个攻破敌城防御从而进行有效传播的媒介。你见过微信红包有口令么？没有！为啥，因为人家在自己家里玩的好好的，也不会到外面撒欢儿。
　　换句话说，今天微信你能屏蔽我支付宝来自阿里域名的分享链接，但是一张附带数字口令序列号的图片（图片只是一个传输媒介，不用在意。为啥？不用图片直接在朋友圈发串口令数字也可以）你屏蔽不来，也屏蔽不起。
　　其实，今天的问题只是从中文口令切入，当然你也可以问数字口令为什么都是系统生成的，而不支持自定义输入呢？
　　我们设想一下，假如真的支持用户先自定义口令，再去生成群红包，可不可以？
　　举个最简单的例子。小A搞了一个群红包，定义口令“summer专属红包”，可大洋彼岸的另一头，小B也搞了一个群红包，也定义口令为“summer专属红包”。虽然，这两个看似口令一致的红包，但背后的id一定是不同的。为什么？因为这个id包含了一个重要信息，就是谁是这个群红包的主人？也就是告诉你抢的应该是谁的红包。可这个id一定是保密的，如果放出来，说不定哪个心思大大的坏的同学能够破译这个id来知道你的支付宝账户和密码，那可麻烦大了！所以需要生成一个外部id（即口令）来与这个内部id（即保密id）形成映射关系，也就是只有我们的系统可以通过外部id找到内部id是啥。
　　但这个时候令人蒙b的事情出现了，当馒头在支付宝红包输入口令“summer专属红包”时，我该抢谁的红包？对不起，系统无法识别！
　　那怎么办，有两种解决办法！一种是让用户来定义口令，但我系统要校验（置前）；另一种是不让用户来干预口令的定制，由我系统说了算（置后）。
　　什么意思？
　　要么我支持你先定义好口令再生成红包（称心如意了吧？），但这个时候开发同学一定要写一串代码告诉系统，大致意思就是说“当用户自定义口令后，去跑一遍口令数据库去做唯一性校验，if一旦数据库里有相同的口令，拦截并提示用户该口令已存在，请重新输入其他口令；else，通过”。但这个问题太大了！先不谈系统去run一遍口令数据库累不累？即便跑得动，需不需要时间？好，如果这个过程需要时间，用户需不需要等待，哪怕用户耐心好等得起，等你个无感知的几毫秒或者无所谓的几秒又如何，但是一旦跑完了，用户等也等了，你突然告诉他“对不起，口令已存在了呢您得再想一个口令试试看”。我勒个槽，用户不得喷死你丫的。好，即便这个用户超级nice（耐撕），一次不行我来两次，两次不行我来三次，那假如10次，100次，1000次呢？用户真的有耐心么？几次不行人家就不陪你玩了，这么麻烦不如发微信红包。另外，这里还有一个隐性问题也很重要，也就是我系统run完了，发现没有重复口令，执行“通过”把这个口令推上去再告诉前端可以把这个口令给用户看了。这是个过程，但有过程一定需要时间。问题就出在这里，一旦这个微乎其微的时间段有人输入一摸一样的口令了，但此时唯一性校验已经做完了，同样避免不了最开始所说的那个问题，系统无法识别！你们可能会说这种情况可能性很小的，好吧！虽然可能性很小，但一旦有这样的情况出现，那可问题大了！所以，无论是从用户体验还是实现的可行性上考虑，这种方法都不现实！
　　那另外一种就是我只能先允许群红包生成后，让系统自动给你生成一个口令，你拿去耍。不过这里开发同学也要写一串代码告诉系统，大致意思就是“生成的红包数字口令要保证唯一，千万不能有重复的，否则削死你丫的”。所以也就不难解释为什么15年春节时，大家都在吐槽8位数的支付宝口令，根本就记不下来！因为数字再怎么组合也是有限的，既然数字09不能改变了，所以我只能通过增加口令位数来创造更多不重样的组合口令咯（所以这个时候可能中文口令的出现也算是挽救了未来可能出现生涩难记的9位、10位支付宝口令）。否则，你叫我怎么玩。不过，这个方案就好很多了，让系统做掉“不让重复口令出现”这件事，而不是让用户输入一个再去拿给系统审查下okay不，而且相比第一种方法工作量小的太多了。但不好的地方就在于系统不是人，即便是人也没办法知道每个用户最想要、最好记忆的数字口令，比如说8个8，多好记、多吉利啊所以也就出现了“6位口令我能忍，8位口令去尼玛”的问题了。
　　但大家又会说了，现在群红包生成了，你再去自定义红包口令，不也会出现一样的问题么？还得做一次唯一性校验，看看是否有重复的口令。不过这样的情况要好很多了，为什么？一是用支付宝发红包的人未必全都是分享到微信的，这个时候口令就完全不需要，直接分享到支付宝群分掉就好了。二是即便用户输入了一遍遍口令都是重复的，但我支付宝留了退路啊！那不是有个系统可以自动生成不重复的数字口令入口嘛（虽然小且难以发现，但是我存在）另外，用户输入中文口令重复的可能性不会太高，我支付宝可以缩小口令唯一性校验的范围，只和“进行中”状态的红包口令作校验，已结束失效的群红包的就不做校验了，因为没意义。那操心的同学又会问了，那假如一个红包发出去大家一直不领，可怎么办，难道一直占着坑？明确告诉你不会的，无论是支付宝红包还是微信红包，都会设置一个相对有效期，一旦红包过了有效期，未领取完的红包余额会自动退回到你的账户上并置为失效状态的（如果我没记错，支付宝群红包的有效期是生成后的24小时内）。
　　所以，今天的ifdesignedlikethis，如果真的把“自定义口令置前”的设计看来不太可行
　　插个话题另外，关于支付宝的红包口令，还有一个槽点要讲一下：
　　既然支持用户自定义输入口令，还是要在口令屏蔽敏感词上做的好一点比如现在居然可以自定义并生成诸如“xxx去死吧去死吧”、”xxx你妈炸了”这样的口令，对此馒头也表示醉了。毕竟大过年的，这么不雅的口令还是不要让用户放出来吧
　　有槽点，当然也有亮点可言。今年的支付宝口令的背景图片支持肆意更改，也支持随意拖动口令以保证衬于背景图片上的口令清晰可见。这就像是一个情感容器，不过这种偏情感化的设计真是很讨喜的，用户会很买你的帐。不过馒头在这里还是要弱弱地提醒下支付宝的同学，既然支持用户随意更换口令的背景图片，对于违禁黄图这块的内容审核也是要好好做一下，否则你懂得！
　　哦对了，
　　我所说的，都是错的。