目前，这些理由大多基于未被明确表述的范式。它源于直觉以及与客户的交流。这种策略在很大程度上可以避免回归问题和灾难性后果，例如客户流失。但它也有局限性。缺乏一个清晰的标尺来衡量进展。因此，像“有多少用户抱怨或赞扬了这项变更？”以及“是否实现了次要目标，如性能提升等？”这类务实的关键绩效指标（KPI）将决定一项变更是否成功。
问题在于：潜在用户和潜在客户无法提出抱怨。
用户界面就像一门语言。我们理解这门语言的能力受到我们所社会化文化的制约。如果我们不将创建这些用户界面时所采用的底层范式明确表述出来，我们就将自身文化嵌入到这些系统中。这意味着它们对我们这样的人来说易于使用，但不一定对所有人都如此。
从抽象角度来看，设计系统可能带来的好处：
一致的外观和交互，保持用户对系统的熟悉感，可以降低学习难度、认知和操作成本，并提高工作效率。
source
如果拥有明确定义的用户界面组件类别，那么“数据显示”组件与用户操作（例如可能使用按钮的情况）之间的混淆就不会发生。如果存在像这样的页面，列出所有不同的用户界面组件及其用途，就可以进行理性的讨论。此外，最好将这些讨论公开进行，而不仅仅通过 Git 提交信息来传达。
3 个赞
pmusaraj
(Penar Musaraj)
24
我刚刚添加了一个类似的提示，但没有放在占位符中。考虑到 Discourse 被翻译成多种语言，占位符中的长字符串有被截断的风险。此外，一旦开始输入，占位符就会消失。因此，我选择在“搜索所有主题/帖子”行中使用右对齐的提示：
此问题已修复，同时修复了其他几个小错误。
我将为这一用例开发更好的解决方案，这已列入我的待办事项清单。
10 个赞
我在 Meta 上当前的“话题内搜索”体验感觉非常奇怪，似乎存在故障。
当我想在网页内搜索时，我的习惯是按下 Ctrl+F，输入关键词，然后按回车。我理解 Discourse 需要拦截或增强这一操作以应对长话题。
现在，当我在 Meta 上按下 Ctrl+F 并在搜索框中输入“theme”时，会发生以下情况：
- 它向我展示了一堆用户（什么鬼？）或标签（还算有用）。
- 如果我按回车，它会展示一堆其他话题（什么鬼？我明明是想在当前话题内搜索）。
- 如果我点击“更多”，我完全失去了当前话题的上下文。
我的结论是：你们完全违背了用户对网页内搜索功能的既定预期。
建议：
(1) 如果用户通过 Ctrl+F 触发搜索，默认执行话题内搜索；但当通过其他全局导航方式触发搜索时，默认执行全站搜索。
(2) 默认不要显示用户，因为大多数人搜索的是话题。
说实话，我不明白你们为什么要用大锤砸坚果；我本以为逐字符搜索的性能影响可以通过在触发搜索前增加 500 毫秒的延迟来处理。
7 个赞
sam
(Sam Saffron)
26
很抱歉，我将此话题关闭两周，依据如下：
请就新范式下的新改进提出建设性反馈，并开启新话题。
本讨论已偏离正轨。
6 个赞
我一直在努力适应这个新的搜索功能，我不得不同意 OP 的观点——这并不是一个进步。它更难使用，而且用户界面令人困惑。
3 个赞
oshyan
(Oshyan Greene)
30
我也有同感，不过我也想明确一点，我理解团队关于其原因的观点，并且我认识到这次更改还有其他显著的好处。所以似乎只是一个如何做得更好的问题，希望能在新的设计上进一步完善。遗憾的是，我现在没有具体的改进想法，否则我会开一个主题来讨论……
话虽如此，我也有同样的看法：
虽然团队不一定有义务回答，但我还是希望他们会回答。
不过这似乎不值得开一个单独的主题。
2 个赞
