当允许用户在我的网站上输入富文本时,我应该考虑什么标准?

发布于 2024-08-16 07:40:47 字数 668 浏览 7 评论 0原文

我曾使用过几种不同类型的“用户生成的内容”网站:维基、留言板、博客...这些系统可能有很大不同:博客文章编辑器比评论可以更好地控制呈现方式 博客文章中,wiki 主题编辑器鼓励 wiki 链接而不是原始 URL 等。

但是,每个人都有一个共同的关键设计决策:我应该为用户提供一种简化的标记语言,例如 Wikitext、Markdown 或 BBCode,强迫用户学习这一点,或者我应该给他们一个所见即所得的编辑器,如 CKEdit 或 TinyMCE,并在幕后过滤或转换生成的 HTML?

曾经有一段时间,我认为这只是确定我的目标受众的简单问题:有技术头脑的用户获得标记,非技术用户获得所见即所得。在实践中,这并没有那么好,偶尔用户会在标记方面遇到困难,所见即所得编辑器最多为底层 HTML 提供了一个有漏洞的抽象。

因此,在我最初的信心彻底崩溃的情况下,我开始寻求建议:

  • 在做出这个决定时我应该考虑哪些因素?
  • 简单的标记系统是否变得足够普遍,以至于我可以相信大多数用户至少对它们有一定程度的熟悉?
  • ...或者我应该将它们视为过去的遗物而抛弃它们,并努力寻找使所见即所得更有效地工作的方法...?

我不想回去毁掉我已经做过的事情。无论好坏,这些系统都在运行,他们的少数用户现在感到舒适或至少有能力。但在整合未来的设计时,如果能有一些更好的指导方针那就太好了。

I've worked with several different types of "user-generated content" sites: wikis, a message board, blogs... These systems can differ greatly: a blog post editor allows more control over presentation than that for comments on the blog post, a wiki topic editor encourages wiki links over raw URLs, etc.

However, one key design decision is common to each: should I provide the user with a simplified markup language such as Wikitext, Markdown or BBCode, forcing users to learn that, or should I give them a WYSIWYG editor like CKEdit or TinyMCE and filter or transform the resulting HTML behind the scenes?

There was a time when I thought this was a simple matter of identifying my intended audience: tech-minded users get markup, non-technical get WYSIWYG. In practice, this hasn't worked out all that well, occasional users struggling with markup and the WYSIWYG editors providing at best a leaky abstraction for the underlying HTML.

So with my initial confidence throughly crushed, I come looking for advice:

  • What factors should I be taking into account when making this decision?
  • Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?
  • ...Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?

I'm not looking to go back and tear apart what I've already done. For better or worse, these systems are working, their few users comfortable or at least competent by now. But it would be nice to have some better guidelines when putting together future designs.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

凉月流沐 2024-08-23 07:40:47

一种似乎效果相当好的方法是使用 Markdown,就像这里在 SO 上所做的那样。愚蠢和/或懒惰的人(向所有愚蠢和/或懒惰的人表示歉意)可以简单地将文本放入框中;它看起来很混乱,但大部分都在那里并且可读。关心文本外观的人可以做一些简单的事情,这些事情在大多数情况下几乎是直观的(例如在段落之间留空行,在列表项之前添加星号或数字),并且它 Just Works™

This is Good Enough™ 适合很多人应用程序和人员。一些华丽的网站,例如 Google 博客,让您可以选择(只需单击按钮即可更改)编辑原始 HTML 或使用所见即所得编辑器(该编辑器经常失败,因此我通常选择原始 HTML)。理论上,你甚至可以给用户 3 种选择,比如 Markdown、HTML 和 WYSIWYG;但有时你会想知道为什么你要这么麻烦。有些用户总是会对界面的某些方面感到困惑,他们会责怪你。我相信找到一个快乐的媒介,而不是费心去让每个人都快乐。

从我的角度来看,最重要的考虑因素是安全性。如果您允许原始 HTML,您的用户就可以插入垃圾邮件和恶意软件,并基本上劫持您的网站以达到他们的目的;所以你必须仔细限制允许的内容。另一个考虑因素是,如果您允许,例如 H1 标题,人们可能会占用大量的空间和注意力来发布那些真正应该是从属的帖子。如果您允许 CSS(包括 HTML 标记中的 style 属性),那么同样有办法破坏您的“真实”内容。另一个大问题源于未封闭或不匹配的标签。这些都是真正严重的问题,您应该宁可采取严格的措施,以避免出现更严重的问题。

One approach that seems to work fairly well is the use of Markdown as done here on SO. Stupid and/or lazy people (with apologies to all who are) can simply throw text in the box; it comes out looking as messy but it's mostly there and readable. People who care about how their text looks can do some simple things that are for the most part almost intuitive (like leaving blank lines between paragraphs, putting asterisks or numbers before list items) and it Just Works™

This is Good Enough™ for a lot of applications and people. Some of the glitzier sites, such as Google Blogs, give you your choice (changeable at the click of a button) of editing raw HTML or using a WYSIWYG editor (that fails just often enough that I usually opt for raw HTML). In theory, you could even give your users 3 alternatives, such as Markdown, HTML and WYSIWYG; but at some point you'll be wondering why you even bothered. Some users will always struggle with some aspect of the interface and they'll blame you. I believe in finding a happy medium and not bothering to make everybody happy.

From my point of view, the most important considerations are those of security. If you allow raw HTML, your users can insert spam and malware and basically hijack your site for their purposes; so you have to carefully limit what's allowed. Another consideration is that if you allow, e.g. H1 headers, people can take up a lot of space and attention with posts that should really be subordinate. If you allow CSS (including style attributes in HTML tags) then again there are ways to deface your "real" content. Another big problem stems from unclosed or unmatched tags. These are the really serious problems, and you want to err on the side of strictness to avoid more serious problems.

謌踐踏愛綪 2024-08-23 07:40:47

“做出这个决定时我应该考虑哪些因素?”您的客户想要什么?您能否拥有一种“回退”类型的系统,在需要原始标记的附加功能之前可以使用“简化的”所见即所得?大多数用户最常使用什么类型的东西?哪些功能使用频率较低,但在需要时却是客户离不开的?

“简单的标记系统是否变得足够普遍,以至于我可以相信大多数用户至少对它们有一定的熟悉程度?”对于使用维基和博客的人来说,我认为答案是肯定的。即使博客上的评论者在某种程度上也是为了最简单的事情,但同样,我认为如果他们能够(或一些常见的标记子集),您应该让他们进行内联标记,并且如果他们需要的话可以选择更强大的功能。

“……或者我应该把它们当作过去的遗迹而抛弃,并努力寻找让所见即所得更有效地工作的方法……?”我不会一下子接受这一切。从坚实的功能核心开始工作,逐步发展成为一个完整的系统。

"What factors should I be taking into account when making this decision?" What do your customers want? Can you not have a 'fall back' kind of system where the 'simplified' WYSIWYG can be used until they need the added features of raw markup? What kinds of things do the most users use most often? What features are used less often but, when they are needed, you customers cannot live without?

"Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?" For people using wikis and blogs, I think the answer is yes. Even commenters on blogs to some extent for the simplest things but again, I think you should let them do markup in-line if they are able (or some common sub set of markup) and have the option of more power if they need it.

"..Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?" I would not take this all on at once. Work from a solid kernel of functionality and work outward to a complete system.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文