【解构ui】表单
之前我们讲了UI中不少的控件，今天我们试着将这些控件组合起来，这就变成了我们经常要设计的表单了。 表单只是帮助用户完成任务的一个方式，应该尽量帮助用户减少困惑，快速有效的完成。
表单的组成部分
- 结构(Structure): 表单包含了许多元素，需要有逻辑性的去组合他们。
- 输入区域(Input fields): 包含了文本输入框，密码输入框，复选框，单选按钮，滑动条等。
- 文字标签(Field labels): 各个输入控件说明，告诉用户每个控件的作用
- 动作按钮(Action button):当用户填写完毕后提交数据时的按钮。
- 反馈(Feedback): 用户通过视觉等反馈来确认自己有输入成功，大部分的应用会通过文字来告诉用户是否有提交成功，或者有什么地方需要修改。
- 辅助性文字(Assistance):提供帮助解释说明输入控件的作用
- 验证性(Validaition):自动检测确保用户输入正确信息。
结构（Structure)
表单是一种同用户的对话，因此在布局上一定要符合逻辑。
-
只填写需要填写的内容
确保在表单上列出来的填写问题都是你真正需要用户去填写。添加任何不必要的元素或者问题都会影响到交流的顺畅性，要不断的确认你让用户填写的这些信息是否真的是你所需的。
-
有逻辑性的去设计表单
在表单上问题的排不上，要有逻辑的去设计，并且这种逻辑是用户逻辑而不是计算机逻辑。
-
将相关联的信息组合在一起
将有逻辑关系的内容组合起来，一组一组的排布问题，能使得表单一目了然。
单栏排布vs多栏排布
表单不应该出现有多列的情况， 多栏表单使你的用户可能会认为这些内容是不相关的。 如果是多栏的，用户就得Z字型扫视，这会减慢他们的浏览速度，以及对表单的理解，难以分清表单的结束在哪。 如果只有一列，那么显而易见的，只要直接看下去就行了。
输入区域 (input fields)
输入控件的数量
尽量将输入控件的数量减少。 将多个输入控件合并
必选项 vs 选填项 (Mandatory vs Optional)
试着不要在表单里加上选填项， 如果要加以区分， 那必须有所区别。 常见是的在表单的输入控件附近加上星号键。
研究显示，其实用户愿意填写更多的信息，但是如果你标了必填和选填，那用户只会填写必填的，因此只要将选填的说明就行了。
预设选项
如果没有90%的把握所有的用户都会选择某个选项，那就不要预设，这会导致用户漏看，然后他们就会觉得自己已经填写过。
但是明智的预设应该帮助用户更好更快的完成表单。 例如预设用户的国家地区。 但还是要注意要让用户有余地去选择其他的地点。这一点我在【拆分ui】复选框vs.开关按钮vs.单选按钮vs.下拉选单谈到下拉选项的时候有提到。
桌面端支持键盘tab键
重度用户善于使用键盘完成所有操作， 因此应该帮助他们能够用tab键就完成所有的输入。
自动聚焦(Autofocusing)
自动聚焦告诉用户从哪里开始。 应该用明确的视觉反馈告诉用户哪里是起点。 比如通过颜色的改变， 箭头的闪烁。
在手机端-将键盘符合输入框内容的性质。
意思就是如果输入的是电话号码之类的数字，就自动显示数字键盘。 避免让用户自行切换键盘。
文字标签（Field Label)
清晰的文字标签能够更好的帮助用户理解表单。
控制字数
文字标签不是帮助性文字，不要写的很长，控制字数清晰的告知用户该控件需要的内容。
首字母大写 vs. 全大写 (Sentence Case vs Title Case）
在英语中，应当尽量避免全大写，因为全大写在识别上较为困难。
文字标签的为止（左对齐，右对齐，控件上放）
有研究指出，如果文字在控件的上面， 那完成起来的速度及那个更快。 用户扫视起来的速度也更快。
接下来我们来逐一分析一下这几种排布方式：
- 将标签置于控件上方
长短不同的文本标签都能很好的放入，非常适合手机端。
- 左对齐
完成速度较慢，可能是因为文本标签和控件之间的距离。但是完成速度慢也不一定是坏事，对于需要输入特别重要的数据的时候很合适。
- 右对齐
右对齐能使得文本标签和控件之间有视觉连续性。 因为就近原则， 对于较短的表单，用这种方式排列完成时间较短。 短处是看起来不舒服因为左侧没有对齐。
综上我们可以看出，如果你想让用户快速填写就将文本标签放在上面， 想要让他们慢一点就可以放在左侧。
将文本标签放置在文本框内
这种方式非常适合于输入用户名和密码的时候。
将文本标签放在文本框里面的确很好看，但是一旦用户开始输入的时候这些文字就消失了， 用户可能就没法确定他们在写的是什么。 还有就是当用户看到文本框里面有文本的时候他们就以为已经填写过了。
一个好的解决方式就是将文本标签上浮（Floating Label),也就是当用户输入的时候，文本标签自动往上，提醒用户填写的内容。
动作按钮(Action Button)
点击此类按钮的时候，会触发动作，比如点击提交表格。
主按钮 vs 次级按钮
主按钮和次按钮在视觉上如不加以区别，就会造成一定的错误的点击。 可以试着减少次按钮的视觉重要性，帮助用户做出正确的选择。
按钮位置
复杂的表格通常会需要一个返回按钮， 如果这个返回按钮是放在输入框的下面， 那会造成用户不小心点击错误而返回。
如下图，作为次按钮，back按钮应该放在不那么容易触及的地方。
按钮的命名
不要用太笼统的命名，比如某些情况下使用“提交”作为动作按钮， 应该使用说明这个按钮具体做了什么动作的文本。
个人认为还是要做A/B test才能更好的确定到底哪个文本更加合适，因为“提交”这个文本现在以及随处可见，用户也已经习以为常了，而且它也暗示着任务已经完成了。可以接下去做另外一件事了。如果用“创建用户”这类的文本标签的话，可能会让用户停下来去想一想是否真的要做出这个决定。
多个动作按钮
如果一个页面提供多个动作按钮会让用户分不清重点。
重设按钮
不要使用重设按钮，因为这个按钮对用户几乎没有什么帮助
视觉表现
确保按钮要做的像按钮。 比如有凸起的表现， 这样他们看起来会比较像可以点击的。 这个在之前的【拆分ui】 按钮一文中有具体的讨论。
视觉反馈。
在点击提交按钮之后， 你要给用户一种正在处理的反馈。 这会避免用户再次提交。
辅助性文字（Assistance and help)
你应该永远也不要像用户解释如何填写表格。 你的表格应该是可自证的。如果表格填起来太复杂，那你就得考虑重新设计。
表格辅助性文字(Text to accompany form)
表格的辅助解释性文字(accompanying text) 应该在真正需要的情况下才使用。 不要将说明超过100字。
- 不熟悉的信息(Unfamiliar data)
如果你让用户填写一些他们不是很熟悉很理解的信息， 那就得像用户解释。
比如上图中，用户可能不是很知道哪里可以找到barcode，这时候输入框旁边的帮助文字就起到了作用
- 特殊信息
有时候有些涉及到隐私的问题用户可能会感到不舒服，不知道为什么你需要知道这些信息。
因此如果你询问用户一些隐私的问题，会引起他们的警觉，因此要告诉他们你并不会将这些信息同其他人分享。
- 有帮助性的文本信息
有时候你需要一些提示的语来解释并帮助用户顺利完成表格。
比如说在计划日子的时候， 用户会喜欢应用能够自动识别出周几而不用用户离开应用去看日历。 这也会减少用户被其他事情吸引的风险。
帮助性文字的多样性(Dynamic help)
如果帮助文字很长很多， 就会把表格弄得看上去很复杂。 因此这时候就要考虑换一种方式来呈现(dynamic contextual help)
- Automatic Inline help
当用户点击输入框的时候， 自动帮助文本会自动跳出来， 通常会有比较强的视觉表现， 表现其同文本框有联系。
但问题是， 这些自动隐藏的文本只有在用户点击的时候才会出来， 之前他们并不提供任何的帮助提示。
- 用户自主触发的帮助说明(User-activated in line exposure)
用户自主触发的帮助说明可以让用户自己灵活的点击查看信息，当他们需要的时候。 通常会用i来表示这里有提示信息。
好处:
1. 只有在用户需要的时候， 点击就能查看
2. 提示的图标通常会放在离所填内容很近的地方， 相比之下比说明文字还要近， 显而易见。
3. 对于新手很老手都是很熟悉的图标。
缺点：
- 视觉干扰(visual noise) ： 这样设计可能造成的一个缺点是弹出的说明框会遮住下方的文字。 比如下图中第三部分就被全部遮住了。
验证反馈 （Validation & Feedback）
验证是表格和用户之间的对话，用来帮助用户完成表格，告知用户填写是否正确。最主要的是当用户犯错的是时候，帮助用户改正，通常来说一个好的验证应该包含以下四个元素：
• 在正确时间，通知用户填写的内容正确与否(Right time)
• 正确的位置 (Right place)
• 使用正确的颜色提示(Right Color)
• 清晰的提示语(Clear language)
正确的时间
在正确的时间告知用户他们是否输入正确，没有人喜欢当你全部写完信息后，在告诉他他写错了。 正确告知用户填写是否正确的时间是在用户输入完后，实时的反馈检测(real time inline validation)，能帮助用户更快的填写完成。
验证结果不应该只告诉用户他们哪里写错了，也应告诉他们是否填写正确，这让他们能够更好的完成表格。 但是不要在用户的光标还停留在输入框的时候就告知他们输入正确与否，应该在用户完成输入后再告知。
这类提示特别适用于输入用户名和密码的表单上。
正确的位置 (Right Place)
验证反馈的出现的位置也很重要，通常根据就近原则，放在输入框的旁边。
正确的颜色
在设计验证反馈的时候，颜色是很好的工具 。因为红色有错误的含义， 黄色表示警告，绿色通常表示正确。
清晰的文本
使用用户语言，告知哪里出错了。
• 哪里错了， 为什么
• 下一步是什么，怎么修正。
不要使用技术语言。 因为如果使用用户不了解的语言， 会加重用户的认知困难。
比如在告知用户email输入有误的时候， 没有告诉用户为什么， 要用直接的清晰的语言告诉用户他们哪里错了。 以避免用户的困惑。
也可以试着在验证之前，提示用户。
不如输入密码的时候，告知密码长度等需求。
可以试着在用户完成输入的时候，给他们一个在提交之前可以检查的机会，如果必要，也可以让他们返回修改错误
参考文章
Designing more efficient forms - structure, inputs, labels and actions
