|
|
1
15
如果你的用户能处理所见即所得,我会同意的。
我在大多数用户身上看到的是,他们很难在文档中表达自己想要的内容。他们不认为“这是一个标题”,他们认为“这应该更大、更大胆”。不能认为“这是一个标题”的人无法处理所见即所得,否则他们会觉得很难。
对我来说,理想的是所见即所得,但只有当你认为你的目标用户能够处理它时,你才能这样做,否则你就必须使用所见即所见。 |
|
|
2
10
我个人喜欢 WYSIWYM 机制。我尽可能多地把它用于自己的工作。我非常喜欢它,所以我试着让别人也尝试一下。 天哪,这就像穿着太空服放屁一样。 我愤世嫉俗的自己认为这意味着大多数人都被Word这样的工具毁了。每个人 知道 制作一份有意义的文件。他们也 知道 。如果它看起来不像那样,那么工具就错了!实际情况是,这些文档生产者实际上并不知道他们的意思,并且习惯于用漂亮的边框和调整制表符来隐藏这一事实。 然而,我真正认为正在发生的是,这些抵制所见即所得的人是这样的,因为这是一种更难思考他们已经投入学习的东西的方式。这是比所见即所得更高的抽象级别,尽管不像用LaTeX或HTML等标记编写文档那样遥远。由于他们已经可以在一个不需要抽象的工具中创建任何类型的文档,所以很难推销。 话虽如此,我认为如果可行的话,你应该强制用户使用所见即所得。这有一些很好的理由
|
|
|
3
5
|
|
|
4
2
总的来说,尽管我有很多为各种CMS实现所见即所得编辑器的经验,但发现它们很有问题,因为客户经常喜欢一遍又一遍地格式化他们的内容,最终往往让编辑器生成质量差的HTML。这会导致各种布局问题,或者只是看起来非常混乱的页面,因为每个人都喜欢把自己想象成平面设计师。 如果做得好,所见即所得可以很好地工作,但要真正做到这一点需要更多的工作,尤其是在考虑CSS的情况下。大多数好的编辑器都可以很好地配置,并允许指定客户端对视觉格式的控制程度。 至于它们生成的代码的质量,例如 FCKEditor 和 TinyMCE 他们非常成熟,能很好地编辑掉源代码中不相关的污垢,但当他们的内容看起来不像他们想要的那样时,要准备好为使用所见即所得的客户提供支持。 由于WYSIWYM编辑器与WYSIWYG非常相似,具有结构格式而不是视觉格式,从哲学上讲,我认为它们更好,更不容易出现问题。因此,如果客户不需要对内容进行视觉格式化,我认为WYSIWYM一定会在未来减少麻烦。 Stack Overflow中使用的编辑器是约束所见即所得的一个很好的例子。您可以直观地格式化内容,但只能在一定程度上格式化。 |
|
|
5
1
如果你的用户精通技术,了解标记的基础知识,你认为他们使用所见即所得会感觉更有力量,那么就使用它。如果您的应用程序将用于技术知识很少的人,请使用所见即所得。 |
|
6
1
除非你正在使用打印布局工具(即Indesign或邮件列表打印工具),否则你最好坚持所见即所得。
|
|
|
7
0
根据我在MYSIWYM的经验,我被这个想法和外观所吸引,但后来我被欺骗了,知道编辑没有给我一种简单有效的方法来限制用户,例如用户可以在段落中插入图像。..我不想那样。..我想更多地控制用户可以做什么。 |
|
|
edluis97 · 所见即所得编辑器中的表问题 8 年前 |
|
|
A.S.J · ReactJS应用程序中的Froala:内联编辑 8 年前 |
|
|
tquill · Rails sanitize不允许rgb颜色 8 年前 |
|
|
Finglish · 带草稿。js是否可以使用类名创建自定义块跨度 8 年前 |
|
|
Tom K · Drupal:阅读更多所见即所得 10 年前 |