学习方法的分享

交互产品离不开表单，表单离不开提交，提交的边上经常会有预览和取消。提交表单后的结果我在细节思考：殊途同归还是哪儿来回哪儿去里面思考了一下，这里主要聊聊预览。我想这是个很细微的地方，也许不需要单独拿出来写一下，但我觉得里面还是有不少需要思考的地方的。

很多地方都对用户输入的内容都提供预览的功能，比如发一个帖子、写一篇博客、自定义一个模版。尤其那些带有复杂编辑器的产品，这些产品允许用户对输入的内容进行简单或是复杂的排版。这时候是否要提供预览的功能？提供什么样的预览功能？我觉得需要考虑几点：

1，编辑器的复杂程度
提供排版功能的复杂程度直接可以决定是否提供预览功能，如果你的编辑器只支持粗体、斜体、下划线等几个简单的方式，就没有必要提供预览功能。因为可视化的编辑器提供所见即所得的操作感受，使得这些简单的排版方式已经可见，并且实际效果和大家平时使用word时看到的效果几乎一样。但如果编辑器提供的功能相对复杂，比如可以插入多张图片并进行图文混排，可以插入音频、视频文件，或是可以做列表、表格、目录等稍微复杂一些的排版操作。这时候就比较需要预览功能了，总的来说提供排版的功能越复杂就越需要预览功能。

2，可视化程度
上面也提到了可视化程度，虽然现在大多数编辑器都提供所见即所得的操作感受，但还是会有细微的差别。而且在编辑器里面看到的效果毕竟不是最终的效果，毕竟会有偏差。因此为用户提供预览的功能确实能够帮助他们更好的操作。

3，编辑器过滤规则
我们经常会对编辑器的过滤规则进行严格的定义，或是在在存储的过程、或是在显示的过程对其进行了过滤。目的无非是希望用户提交的是尽量标准化的安全的数据，比如对某些html标签进行过滤，或是对某些特殊的字符串进行过滤。这就造成了用户在编辑器里面输入的内容会和最终结果不一样，有可能某些内容会被过滤掉，或是不会按照用户自己定义的形式显示。从这块看也有必要为用户提供预览的功能。

4，自定义模版或是其他操作
对于自定义模版类的操作，显而易见的是非常需要预览功能。比如修改了底色、字号、边框颜色后是什么样子、什么效果？先保存再修改就太麻烦了，如果提供预览的功能、或是干脆自动预览，就会方便很多。类似的操作还有自定义皮肤、对上传的头像进行处理等。

5，会不会被用？
这点就比较有意思了，上面3点最终的结论好像是应该为用户提供预览的功能，因为预览对他们很有帮助。但实际上当我们提供了预览这个功能的时候它会不会被用呢？或是被用的概率是多大？比如写完一篇博客后，下面有3个按钮，分别是“发布”、“预览”、“取消”，这3个按钮最终被按的机会各是多少？如果有线上的产品可以分析我们应该分析一下，也许我们放上了预览的按钮，提供了预览的功能但最终没有用户用。下面的这些基本是从用户会不会用预览的角度思考的。

6，预览按钮用什么文案？
是叫“预览”，还是叫“先看看怎么样？”，还是叫别的什么名字？这给用户传达的信息是不一样的。

7，预览按钮什么样？
用超级链接还是用button？用模仿的假按钮还是用真按钮，用默认的样式还是自定义样式？多大？什么颜色？用不用图片？

8，预览按钮放在什么位置？
使用“发布、预览、取消”的顺序，还是使用“预览、发布、取消”的顺序，还是别的什么顺序？

9，操作方式不合适？
ctrl+enter是否直接提交？有快捷方式直接预览吗？

10，是否在提交前必须预览？
比如写了博客以后下面只有一个预览按钮，想发表必须先预览？

11，用户不明白什么是预览？

12，用户不知道点了预览后会发生什么？
比如写的东西会不会丢？点了以后会去哪里？还能不能回来？

13，用户不需要预览？
比如发布了以后可以方便的编辑，这时候预览的必要性就大打折扣。或是发布的内容实效性和正确性要求不高，可以随时修改。或是发布的信息很简单不需要预览，比如发布的内容只有一句话。

14，用户习惯不习惯先预览？
用户对发的信息的样式很在意吗？排版有点乱在意吗？

15，预览以后
点了预览按钮后本页跳转还是新弹出窗口显示还是弹出一个层显示预览页？
预览页一般包含保存（发布）和取消（再编辑）两个按钮，可以确认发布，也可以取消再编辑。这时候针对这两个按钮的操作和表现形式需要根据上面提到那些再次思考。并且还有本地预览还是服务器端预览的问题，比如这时候图片、内容是否上传？如果上传了之后没发布如何处理？