@david 也许在新页面加载并显示旧内容时，我们可以禁用所有点击操作？这看起来是个边缘情况，但确实合理。
@awesomerobot 你对桌面端滑块的粗细满意吗？我们部门内部意见不一，打算先这样上线运行几天。在移动端，我觉得我们已经达到了理想的平衡。
7 个赞
这取决于你的目标。如果你的主要目标之一是“（几乎）与互联网其他部分运作方式完全一致”，那你可能不想这样做。在“普通”网站上，如果我点击第一个链接后很快又点击第二个链接，第二个链接的内容会被加载。
8 个赞
我非常喜欢这个改动，尤其是后续的优化……我如此喜爱它，以至于迫切希望将其发布到测试版中，以获取更多反馈。
我们什么时候可以将此功能合并到核心代码中？@david
9 个赞
嗯，我想你是对的……我想我支持就按现在的样子直接并入核心。
我们可以在过程中不断完善，但目前的功能已经相当成熟，运行效果也非常出色。
8 个赞
以目前的厚度来看，我觉得没问题。如果收到反馈说不够明显，那时我们再增加 1px。很期待它进入核心版本！
7 个赞
听起来很棒！还有一些渲染问题需要解决（例如 这个），不过一旦修复好，我们就可以将其加入核心功能。不过，我仍然倾向于先在 Meta 上多测试一段时间。当前的实现上线才 24 小时。
再看看其他一些流行的 PWA：
| 服务 | 立即整页更新 | 滑块 | 加载动画 | 自定义占位符 |
|---|---|---|---|---|
 |
|
|||
|
|
|||
| （部分页面） | |
|||
| YouTube |  |
|
||
| GitHub | |
|
||
 旧版 Discourse |
|
|
||
| 带滑块的 Discourse |
|
|
因此，这一改动会使我们更接近 YouTube 和 GitHub，而在我看来，它们给人的感觉更像网站而非应用。这是否是我们想要的发展方向？
15 个赞
我认为是的，这与“极简/类网页”的默认主题理念相契合。如果我们想尝试，随时可以提供一个用于加载动画或自定义占位符的主题组件。
我特别喜欢这一点：该变更减少了屏幕上发生变化的像素数量。
我认为 Gmail 也采用了类似的模式（它先渲染一个方形的加载状态，然后翻转显示内容）。
8 个赞
我们的滑块设置如下（见下文）。这纯属个人喜好，但我认为在移动端 4px 比 3px 更美观；不过 3px 也没问题，完全可以接受。然而，在大尺寸桌面屏幕上，主观来说 6px 效果更好；不过我个人更喜欢 7px，因为我希望用户无论页面加载时主题背景色如何，都能清楚地看到滑块及其相对进度；但如果在桌面大屏幕上将其降至 6px，也完全没问题。在 27 英寸和 34 英寸的大屏幕上，如果小于 6px，在某些背景主题色下几乎难以察觉；既然滑块用于指示“加载中”，我认为宁可让它更明显一些更稳妥；当然，这终究是非常主观的。
height: 4px;
@media only screen and (min-width: 960px) {
height: 7px;
}
8 个赞
我对这个功能的（迟来的）反馈：
在我查看这个话题之前，我甚至没注意到这个变化，这……很好！在我看来，优秀的功能应该是能自然融入现有体验的。
在稍微关注了这个功能后，我同意减少屏幕闪烁确实比之前的行为在视觉上更具吸引力。
恭喜团队为这次变更所付出的精心设计和思考！
13 个赞
也许我的报告在混乱中遗失了（或者他们只是还没来得及查看）。
3 个赞
感谢 @cosdesign 和 @seanblue —— 修复工作仍在我的关注范围内。我已在本文开头（OP）创建了一份“已知问题”列表，以便我们追踪待办事项。
10 个赞
下拉菜单问题现已解决：
8 个赞
我非常喜欢这个组件，我刚刚也在我的 Discourse 论坛上安装了它。谢谢！
一个建议：是否可以在页面加载时显示骨架屏？在页面可能需要一点时间加载的情况下，这有助于表明点击已生效。这只是我注意到的一个小细节，有时我会因为一开始没看到加载条而双击主题标题，而加载动画则是直接显示的。
4 个赞
这是我们在此做出的折中方案：除非屏幕内容已停留超过 2 秒且无新内容可展示，否则我们不会更改屏幕上的内容。
我想我们可以提供一个开关，将 2 秒的阈值降低到 1 秒，但我觉得我们已经找到了合适的平衡点。
7 个赞
我离开几天后刚回来，首先注意到的是这里现在感觉变慢了。
我意识到 Google Groups 也推出了类似的功能，但我觉得我们没必要照搬他们的做法。在我看来，加载动画（spinner）更适合 Discourse，它响应迅速，甚至有助于打破"Ruby 应用总是很慢”的迷思。我很喜欢它，也喜欢 Discourse 因此展现出的快速体验。遗憾的是，我觉得这个滑动条是一个很大的倒退（向所有参与开发的人致歉，我知道这可能不是你们想听到的——但我相信我们都希望 Discourse 变得更好，所以希望你不介意我分享对此的感受）。
2 个赞
当我们在核心中发布此功能时，将提供一个组件以支持旧的过渡模式。
我们听到了您的反馈，但您属于极少数用户，大多数用户更偏好新的过渡风格。新风格意味着屏幕上变化的内容更少。
旧版
点击 → 白屏 → 内容
新版
点击 → 内容
我理解有些人可能喜欢带有加载器的白屏，但这只是少数人的观点。
11 个赞
这无关乎是否喜欢白色屏幕，Sam，关键在于速度感。
我一直认为，Discourse 的速度（以及体验）是其最令人印象深刻的特性之一。我甚至知道，那些原本对 Ruby 颇有微词的人，也对你们在 Discourse 上取得的成就感到惊叹。
此外，我认为这种速度感如今比以往任何时候都更为重要，因为我们一直在与 Twitter 和 Discord 这样的大型网站竞争。我认为，哪怕是一丝迟滞感都可能产生影响——即便这种影响是潜意识的。
很高兴将会有一个组件支持旧的过渡模式，但我担心这可能会引入额外的开销，导致速度变慢（哪怕只是轻微的），从而抵消旧方式/加载转圈的优势。如果不会出现这种情况，那我自然乐意接受……但我仍然认为，这一举措将对其他所有 Discourse 站点产生不利影响。
4 个赞
我完全同意关于速度感知的看法。
如果加载动画在屏幕上停留过久，那确实表明存在问题（尽管问题本身并非加载动画），而且在这种情况下，它可能不如进度条具有信息量。
进度条往往暗示着底层处理缓慢。它们让我想起旧版 Windows 的进度条（预计剩余时间：6 天 23 小时）。一旦注意到它们，我就会觉得速度肯定有问题，它们的存在似乎只是为了缓解我的急躁情绪。这个进度条似乎总是在大约 80% 的位置稍作停顿，每次都会让我觉得出了差错。
如果论坛运行迅速，那么使用进度条并不是一个好主意。
4 个赞
我越使用 Meta，就越觉得更喜欢旧的加载动画。滑块不够明显，让网站感觉没有响应。
2 个赞