变态输入框——再谈校验包容性（一）（2）

于是，纠结的恶梦从此开始了。

刚开始，我想得简单，写了几个case要求：

Case 1：B,C(A是前面的起订量，本文为了力求简单，忽略此项) 输入框都不填或清空时点击GO——页面刷新，执行在现有筛选条件上应用价格从0到无穷大的筛选。

Case2：B,C三个输入框中任何一个填写非数字及小数点的字符时——自动清空，不弹出任何提示。

注意：只清除非规范填写字符，保留符合要求的字符（数字和小数点）。举例，用户粘贴7a7到B或C输入框，自动清楚中间的a。

Case3：在B和C输入框里输入前大后小数字，点击GO，页面刷新后，输入框数字自动调整为前小后大。

Case4：B填写正常数字如100，C留空，点击GO——页面刷新，结果数为大于或等于100的结果。

Case5：B留空，C填写正常数字，如100，点击GO——页面刷新，结果数为小于或等于100的结果。

可是到了测试的阶段，才发现测试MM才是最变态的，她们总是能够找出更变态的Case，发现漏洞，于是，多亏了我们非常牛的前端工程师，体现了什么是见招拆招——Nothing is impossible～

补充了case：

Case6：B和C两个输入一样的数字（如100），前端自动转换为0到100，点击go后，提取价格小于或等于100的产品结果。

Case8: 输入框如果只输入小数点，执行同Case1.

某天，前端又提出一个问题：允许输入小数点，如果输入两个小数点怎么办？

继续咬牙补充：

小数位只允许输入2位，比如用户输入6.678，会自动清除8。

小数点若输入两个，自动保留第一个，清除第2个。比如输入6.6.，会清除第二个小数点——变成6.6。

测试MM又问了：如果粘贴6.6.6怎么办？是呀，粘贴怎么办呢？我都快要放弃了，咱还是整个弹出框警告一下用户吧。不过，那不就功亏一篑了吗？所以，后来变成了66.60。

最后，经过很多次的测试和各种变态的想法，此输入框终于检测通过。

背后则是前端工程师付出心血——代码，神奇的代码……将在续篇中由前端来继续揭秘。

作为交互设计师的心得：

其实开始想法挺简单的，就是想让校验亲和一些，不要动辄提示用户出错而是润物细无声，帮用户纠错完成任务。

随着项目的进行和更多人的加入，发现要想周全考虑各种情况，是很难的事情。

而且，自己也开始反思，这种强制替用户做主，是不是一件好事，或者本身就不该这么做。用户输入错了，就干脆提示他错了，让他自己有意识去修改，让出错显性和透明化，会不会更加好一些？

另外，这些变态的输入用户毕竟是极少数，为了这极少数的人太纠结，虽然是照顾到了设计的各个微笑的细节，但是如果考虑投入产出比，可能会有些因小失大。除非以后能够将这些已经开发出来的控件标准化，以应用到以后的项目里。