作者文章: Fenng

登陆框的密码遮盖问题以及其他

几天前看到的这个关于密码遮盖（Password Masking) 问题的讨论，顺着链接有找到了一些讨论来看，继而发现相关文章已经有人翻译了(refer)，但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题，因为挑战的是习惯性的设计方式。放眼看去，所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见–用户的输入成了盲区，不知道自己输入的是否对，点击登录变成了变相的试错操作，产生比较多的再次登录操作，对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新，要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢，要从别人口中出来这个论断可能会被人笑话，而大牛就敢于挑战常规，弄个问题就给大家带来思考了–扯远了。

似乎多数人赞同添加一个额外的检查框（CheckBox），安全性要求不高的应用，默认不遮挡，用户输入完毕之后，再选择旁边的检查框对密码进行遮挡；对于安全性要求比较高的应用，默认密码遮挡，但可以选择显示一下密码明文一下，方便用户检查是否有拼写错误。

如果你用过苹果的产品，比如 iPhone 新 OS 3.0 的版本，你会发现密码的处理又进了一步，密码输入时是显示明文的，方便用户确认没有输错，在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)

(截图有点喧宾夺主，对付着看吧)

这个想法真的很让人欣赏，对于手持设备能够比较有效的防止了窥探(peeking over your shoulder)，也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说，窥探的可能性有多大？缺乏数据支持，很难说明。或许，这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ，否则的话，用户要的密码可能不是自己输入的，短时间内连续两次输入，出现键入错误的几率并非不存在。

好吧，现在开始审视一下自己的网站登录框设计以及注册页面吧…新的问题或许是，你有勇气做点修改麽?

如果觉得上面说的都是废话，那么不妨考虑这两个问题：

为什么我们之前就没考虑到这一点?
如何才能先于别人一步想到这一点?

–EOF–

延伸阅读：Better Password Inputs, iPhone Style

关于信息的五分钟问题

最近一直在考虑这个关于信息的”五分钟”的问题。搜索了一下，发现还很少有人考虑这个现象，思路还没有完全理顺，先抛几个观点等待大家的补充吧，期待能引发一些对信息处理的思考。

最早注意到这个现象是每次我 BLOG 更新之后，在大约 5 分钟左右，通过 Google 的 BlogSearch 就可以看到内容。这个倒很容易理解，因为我用的 Movable Type 在发布文章的时候会自动通知一下 Google 服务器。接到通知之后，Google 能够较快的把信息合并(Merge)到当前的索引中，但是应该还没加上非常严格的排序(Sort)，这是个很经典的处理技巧。

不过，Google 获得信息绝大部分是通过爬虫”抓取”，也就是”拉”(Pull)数据，只有少部分是用户”推送”(Push)的。这就导致 Google 在信息处理上节拍总要慢一点。Google 的目标是处理地球上的所有信息，无远弗届，但信息的及时性或许是最难解决的。

而 Facebook / Twitter / FriendFeed 等具备面向”实时信息流”(Real Time Lifestreaming)功能的网络应用，大部分信息都是用户”推送”上来的，所以也有天然的优势触及这五分钟之内的数据，并经过简单的局部计算之后呈现给用户。得到”即时”信息似乎是人的天性（另一个侧面的印证是人们无法摆脱手机而全部使用 IM 和电子邮件），所以五分钟之内的数据处理能力是对普通用户来说有着难以言明的吸引力。

“五分钟”只是个大致的说法，相信随着技术的发展，会缩短到三分钟，乃至更短。但这部分始终是 Google 无法完全覆盖的地方，技术没办法打败时间，这也是信息暗网的也无法解决的问题。最终我们发现，信息处理的巨人和信息处理的快刀手一起相处的比较融洽。

–EOF–

注：很明显，这个”五分钟”问题和我之前说的关于 I/O 的五分钟问题是不搭界的。

关于 IM 工具的”群”

在我看来，如果要评选一个IM 工具的功能「更影响沟通的有效性、更能浪费生产力」的话，恐怕非「群」莫属。

昨天在 Twitter 上发了一句对「群」这个玩意儿的牢骚，引来了不少朋友的回复，大部分朋友对「群」还是深恶痛绝的，云风随后写了一篇《关于「群」的那些破事》叙述网易泡泡的群功能出炉的来龙去脉。

经常看到有讨论技术的人会开很多 QQ 群，然后一大堆人加入，我最不屑这样的讨论技术的方式，我不相信有谁通过 IM 群学会了很多东西，当然，他们浪费了很多宝贵时间我倒是深信不疑的。所以不乏偏激的说：

喜欢用群的人都是喜欢用开会来消磨时间的。他们享受群，认为那东西理所当然的是「群」的沟通工具。我也赞同群里面90%都是一些垃圾信息的说法。小笑话、新闻链接、有趣的小图片占据了这 90% 的大部分内容。

这样的说法如果也在内部会议上提出的话，估计也要像 Tim Yang 那样遭受一片嘘声。（我不排除有人把「群」用的出神入化，比如昨天就有一位互联网大佬给我讲述他当年用群的功能做推广的案例，但这只是个例）。Twitter 上就有不少人不同意我的说法：

“吾之蜜糖彼之砒霜，QQ 群用的人那么多，凭什么说人家烂？不适合罢了”

也有朋友给出了建议:

建议用临时会话，说完正事就退出。(refer)
群的成员不应该是固定的。（refer)
做个Twitter进化的桌面IM…

现在的群，如果非要继续沿用的话，改进的余地还有很大。产品经理请注意，下面是可以给你带来业绩的地方：学习 Twitter 风格的对话模式，针对每一条信息有上下文，便于群内的参与者能够知道信息的指向(这是非常关键的一点，否则就是乱七八糟胡乱抢话筒的会议而已)。第二，设计一个可以将”会议”记录发送到指定电子邮件的功能(这应该并不复杂)。学学 Gtalk 的优点应该不难吧?

欣喜的看到网易已经用不许员工上班时间用群了，这是个伟大的决定。

–EOF–

（注：众多推友对此文亦有贡献)

关于 I/O 的五分钟法则(Five-Minute Rule)

去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个”五分钟法则”的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个”新的旧硬件”可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

–EOF–