变态输入框——再谈校验包容性（一）
揭秘一个普通的输入框背后惊人的秘密。
某月某日，某项目某页面，需要一个价格区间筛选功能，需求合理，所以设计做上去。
这是一个无比普通的输入框。在以往的项目中，一般都会直接由工程师和前端直接应有现有的校验框架，即由产品经理来规定这个输入框里“不规范的字段类型”，然后一旦用户输入不规范的字段类型后，若是后台页面，就会在输入框下方出现红色的提示。如果是前台的页面，就会弹出一个alert box——这个输入框如果这样处理，也没什么。
可是，这个页面是非常重要的前台页面，我是不希望弹出alert box的，如果使用页面提示，也会影响页面结构。
——当然，我也考虑过单纯改进一下提醒的样式，比如将alert box改成一个浮出层（是ppt简单示意一下）：
可是我当时想，这个前台的页面，要体验好一些，能不能包容性一些，比如用户输入前大后小，能不能不提示出错，而自动转换为前小后大呢？若两个输入框一个留空，能不能也继续执行呢？若用户输入字母，能不能自动清除呢？若用户输入了多个小数位，能不能自动四舍五入呢？
于是，纠结的恶梦从此开始了。
刚开始，我想得简单，写了几个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。
最后，经过很多次的测试和各种变态的想法，此输入框终于检测通过。
背后则是前端工程师付出心血——代码，神奇的代码……将在续篇中由前端来继续揭秘。
作为交互设计师的心得：
其实开始想法挺简单的，就是想让校验亲和一些，不要动辄提示用户出错而是润物细无声，帮用户纠错完成任务。
随着项目的进行和更多人的加入，发现要想周全考虑各种情况，是很难的事情。
而且，自己也开始反思，这种强制替用户做主，是不是一件好事，或者本身就不该这么做。用户输入错了，就干脆提示他错了，让他自己有意识去修改，让出错显性和透明化，会不会更加好一些？
另外，这些变态的输入用户毕竟是极少数，为了这极少数的人太纠结，虽然是照顾到了设计的各个微笑的细节，但是如果考虑投入产出比，可能会有些因小失大。除非以后能够将这些已经开发出来的控件标准化，以应用到以后的项目里。
也想听听大家的讨论。
相关的文章:面对无理取闹的用户：https://heidixie.blog.sohu.com/117779486.html