Gutenberg: 推进块接口

这很棒@mtias ，真的很有前瞻性。 👏👏

以下是我在阅读该问题时的一些注意事项：

1. 我很好奇这对“顶部工具栏”意味着什么。 你认为互动的哪些部分会在那里根深蒂固？

2. 最后一个屏幕截图引用了一种颜色 UX 模式。 烘焙一个易于实现的基础颜色体验对于积木来说真是太棒了！ 在标准化的区域设置中具有背景/文本颜色控件将导致应用颜色的非常需要的模式。

3. 我不确定它是否已经被探索过，但探索在嵌套块被编辑时工具栏在父块上保持静态可能会很有趣 - 控件根据选定的子块进行调整。

4. 方块图标右下角的小黑三角是什么意思？ 如果这意味着有一个带有其他控件的下拉列表？ 如果是这样，对齐/文本对齐控件也应该有它。

我想马蒂亚斯今天在飞机上，所以我会尽力代替他回答。 我敢肯定，如果我不在基地，他会插话的！

我很好奇这对“顶部工具栏”意味着什么。 你认为互动的哪些部分会在那里根深蒂固？

这是我们需要在实施中探索和解决的问题。 重点主要放在默认体验上，它对正在编辑的每个块具有最直接的视觉上下文，但顶部工具栏选项应该仍然是那些喜欢的人的选项。 无论这意味着始终显示移动控件，还是确保在不移动工具栏的情况下有空间显示它，这里都有选项。

最后一个屏幕截图引用了一种颜色 UX 模式。 烘焙一个易于实现的基础颜色体验对于积木来说真是太棒了！ 在标准化的区域设置中具有背景/文本颜色控件将导致应用颜色的非常需要的模式。

🙌

我不确定它是否已经被探索过，但探索在嵌套块被编辑时工具栏在父块上保持静态可能会很有趣 - 控件根据选定的子块进行调整。

我相信 #18440（解决 #17267）可能与您在这里建议的内容一致。 我碰巧同意你的看法，这对于至少一些容器块是必要的！

方块图标右下角的小黑三角是什么意思？ 如果这意味着有一个带有其他控件的下拉列表？ 如果是这样，对齐/文本对齐控件也应该有它。

工具栏中的下拉菜单可能越来越必要，不仅是为了缩放（理论上可以扩展到包含自定义 flexbox 对齐的对齐菜单），而且是为了更好地处理插件、响应式和嵌套上下文。

在本次探索中，下拉菜单没有额外的视觉指示器，这与 Block Library、Block Traversal 和 Ellipsis 菜单等弹出窗口一致。 对于各种用户来说，这对实现有多直观还有待观察，但其想法是减少和简化非常复杂的控件。 块项目的三角形反而成为块的锚点，指示所有其他扩展的工具栏段。

关于移动控件，这些更改将如何影响可访问性？ 工具栏控件的 Tab 键顺序是什么？ 仅在悬停块图标时才显示移动控件对可访问性是否不利？

好问题，泽布！ 找到动子控制的正确平衡非常重要。 一方面，它们提供了清晰的交互，可以以一种移动友好的方式轻松地交换两个块，而不是像拖放那样繁琐，这对于运动技能低下的人来说很重要。

同时，它是一个大控件，仅在_某些时候_有用。 与兄弟插入器相同 - 位于两个块之间的加号 - 这张票中概述的想法表明控件可以隐藏直到需要。

按 T​​ab 键顺序排列，这些控件的位置可能比以前更好，因为现在将有一个单独的块工具栏控件可以使用 Tab 键进入。 就像在悬停和焦点上都出现同级插入器一样，移动控件也是如此，它们将出现在工具栏中的其余控件之前。

正如我还向 Rich 指出的，移动控件是我们在代码中探索时需要改进的方面之一。 目的是在实用性和可访问性之间找到适当的平衡，我们可以采用几种方法。

我真的很高兴看到这些演变！

我记得我们面临的另一个挑战是通过各种悬停和选择让 UI 出现和消失。 虽然这种探索仍然允许这样做，但我相信将 UI 分组到一个有凝聚力的工具栏（如下所示）将有助于解决问题。 👍

强烈的对比是美丽的。 😍

还有更多的地方需要覆盖和探索。

我们绝对需要对此进行测试。 在以下情况下进行探索会很有趣：

• 嵌套块——在视觉上将嵌套块与父块相关联是否重要？
• 右对齐的内容 - 工具栏看起来是否过于分离？
• 边框——似乎某些块有边框（即按钮和图像），但其他块没有（即段落）？

基本上探索这个新工具栏如何与这里解决的问题相关（其中一些已经完成）：

随着时间的推移，界面已经发展到可以处理越来越复杂的需求，例如嵌套块结构、移动、选择、面包屑、导航器、轮廓等。

这将有助于让我们专注于整体。

我很好奇这对“顶部工具栏”意味着什么。 你认为互动的哪些部分会在那里根深蒂固？

这是个好问题。 顶部工具栏大多位于一个不错的位置，因为它不会遇到画布内工具栏的许多问题。 我希望它会继承一些主要的改进（下拉菜单的清晰性、上下文工具、省略号菜单的区分——标题有两个——、焦点状态等）。

标题区域存在一些挑战，我认为我们需要更全面地看待这些挑战，尤其是全站点编辑，这可能会在有限的空间内带来更多控件。 例如，我可以看到顶部工具栏没有将控件添加到标题，而是在它的正下方，如果我们可以解决看起来不可怕的双堆叠:)

在标准化的区域设置中具有背景/文本颜色控件将导致应用颜色的非常需要的模式。

同意！ 我认为我们已经到了 UI 工作可以帮助我们解决 #7553 和 #9534 之类的问题的地步。

方块图标右下角的小黑三角是什么意思？

@jasmussen所说的。 它还旨在强调下拉列表并为块类型添加一个层次结构，它已经吸收了更多的交互（转换、样式、选择，可能更多）。

例如，我可以看到顶部工具栏没有将控件添加到标题，而是在它的正下方，如果我们可以解决看起来不可怕的双堆叠:)

我认为从长远来看，这样的事情是不可避免的。 从语义上讲，将通用工具栏与块工具栏结合起来似乎很奇怪，并且将两者放在单独的行上将允许为两者的控件提供可选的内联标签（参见 #10524），而不会变得非常局促。

我对这次迭代感到兴奋，并感谢它从提炼回块开始。 我想深入探讨一下，想到一些想法。 首先是注意到这一年是多么重要。 至关重要的是，界面要进化、响应和适应当今的空间和未来的空间。 一路上我们都学到了很多东西，可以为这次迭代提供动力。 我认为还值得指出的是，这本身应该是一个迭代，未来还会有更多。

当前的一个大问题是随着嵌套块和内容的界面变得更加复杂，当前的情况无法扩展。 这感觉是回到街区并重新检查的根源。 我认为，例如移动块移动器的建议解决了很大一部分问题。 对我来说，工具栏建议作为一个整体，本能地感觉像是向前迈出的重要一步。 还值得注意的是，仅仅拥有更大的命中空间就可以带来可用性方面的一些好处； 即使可以缓解认知负荷，也可以打开界面。

我非常热衷于引入一个网格，并认为随着整个体验的传播，这将减少视觉混乱和理解整个体验的空间。

当我查看示例时，寻路似乎更自然； 这是今天的重大改进和摩擦之一。 随着网站编辑的兴起，能够看到您正在做什么以及何时进行变得更加重要。 虽然在这些示例中它没有在复杂的内容中被可视化，但我可以看到这至少比我们目前拥有的更容易关注。

作为本次迭代的一部分，不仅探索视觉语言，而且探索交互语言，这将是很棒的。 我们可以讲述什么故事，我们可以通过动画、拖动和弹跳来增强什么？ 从来没有时间将其制作成故事弧，节奏。 同样，花时间审核我们的互动似乎是正确的。 通过设置交互语言，体验将随着所有其他建议的改进而显着改善。 在显示的示例中，我对这是工作的一部分感到乐观。

是否有我们可以玩的原型，甚至是 Figma 中的静态原型，以更好地了解整个系统？

我们会将其中一些探索收集并整理到一个文件中供所有人使用。

@mtias 、 @jasmussen 、 @pablohoneyhoney绝对令人惊叹的作品！ 真是太令人兴奋了😍

由于我们非常注重体验，我认为确保交互感觉非常好非常重要。 帖子中的 GIF 帮助演示了其中的一些交互。

正如@melchoyce 所提到的，我认为拥有一个交互式原型会非常有帮助。 您可以单击、戳、拖动和玩的东西。

我在这里创建了一个非常简单的：
https://codesandbox.io/s/github/ItsJonQ/g2-prototypes/tree/master/

非代码视图，这里：
https://tz3ir.csb.app/#/

（原谅图标，哈哈。我很快就把这个放在一起了）

我们可以使用这个 CodeSandbox 进行原型设计、实验和优化交互。 不仅仅是新的工具栏，还有帖子中介绍的所有新概念:)。

编辑：更新 CodeSandbox 链接

在这个 GIF 中，“活跃”和“不活跃”是什么意思？

抱歉，如果不清楚@ZebulanStanphill ，_inactive_ 表示休息（例如，在打字时，但不与工具栏交互），_active_ 表示悬停、聚焦或按下工具栏。 为了进一步测试和强调，它被孤立地勾勒出考虑不同的推动者方法。

那好吧。 我不确定我是否同意隐藏内联格式控件，直到您悬停/聚焦工具栏。 模型的这一方面背后的原因是什么？

此外，导航到块检查器如何适应这种新的块工具栏设计？ 已经讨论过将检查器转换为由工具栏按钮打开的模式。

隐藏控件是一种双曲线探索，以讨论和演示 _contextuality_，为用户正在执行的给定操作显示最相关的 UI。 拥有更智能的 UI，可以显示最相关的控件，同时在任何给定点提供对它们的访问。 段落（通过富文本）将始终具有公开的格式控件。

回复：第二点，这将在整个环境的背景下进行探索，但这种方法应该可以访问检查员。 也许@jasmussen 对此有一些想法，因为他在https://github.com/WordPress/gutenberg/issues/13663#issuecomment -521917305 上进行了一些探讨

回复：第二点，这将在整个环境的背景下进行探索，但这种方法应该可以访问检查员。 也许@jasmussen 对此有一些想法，因为他在 #13663（评论）上进行了一些探索

是的。 我认为上下文块设置侧边栏的交互，以及如何最好地处理它和块之间的焦点，值得在 #13663 中继续讨论，这里的设计不一定需要以任何方式或其他。

不过我一直在思考。 这是关于在为高级用户提供有用的高级块设置和提供基线直观的标签界面之间取得适当的平衡。 需要更多考虑的一个想法是默认阻止在模式对话框中打开设置，但允许用户将侧边栏固定在右侧，就像将工具栏固定在顶部一样。

我认为这张票中有很多非常引人注目的想法！ 我没有很多东西要评论（因为我喜欢很多人所说的！）但我想观察的一件事是“悬停”动作的持续流行。

我最近切换到 iPad 作为我的主要计算设备，在这种环境下，根本不可能发生悬停事件。 iOS 13 中的 Safari 尽最大努力将触摸解释为悬停并适当地映射它，但它的工作不一致并且充其量是笨重的。 即使 iPadOS 在技术上支持鼠标，它也不允许跟踪悬停事件，因为鼠标指针被视为触摸输入的模拟。

我知道悬停事件也存在可访问性影响，尽管我不太愿意与这些事件交谈。 但更普遍的是，随着 iPad 和触摸设备变得越来越普遍（特别是成为越来越普遍的主要设备），最好从悬停被视为渐进增强的地方开始。

@chrisvanpatten我同意； 我想看看提议的新工具栏如何在移动设备上工作的模型。 也许点击块图标会导致移动器和变换/样式菜单出现？

我很好奇的另一件事是模型工具栏如何在块工具栏紧靠屏幕左侧的紧张情况下工作。 如果悬停控件总是向左滑出，如果它们离开屏幕，您应该如何使用它们？ 块工具栏是否总是位于离左边缘最小距离的位置，以确保有移动器出现的空间？

从用户的角度的一个小笔记。 我同意我们应该考虑触摸设备的观点，因为即使您将 iPad 与智能键盘一起使用以提高您的工作效率，目前在 iPad 上的体验也不是很好。 总的来说，我们达到了移动设备访问量大于台式机访问量的程度，因此我们应该确保在所有情况下都感觉良好。

确实。 演示文稿中的“悬停/焦点”通常可与触摸设备上的类似点击步骤互换，这需要正确定义。

我们在移动设备上为更实用的工具栏设置的最大拦截器最近已在 #18686 中得到解决。
使用建议的工具栏迭代，我想我们将能够呈现一些点击步骤，例如：

扩展到：

甚至可能会显示“移动到”，以便您可以点击，滚动到您想要移动块的位置，然后再次点击以放置块：

漂亮的移动模型。

我想知道的其他事情：为什么移动者应该在块图标的左侧？ 如果块图标是工具栏的“锚点”，我认为它应该是你第一个进入的东西，因此移动器应该出现在它之后。

:wave: 你好！！ 我有一个关于设计会议期间提出的“G2”推进块 UI 的原型更新。

我在这里记录了我的原型的演练：
https://www.loom.com/share/f27357393abc49bca2d070cdbc9a7633

链接到代码和东西！
代码沙盒：
https://codesandbox.io/s/github/ItsJonQ/g2-prototypes/tree/master/

原型预览：
https://tz3ir.csb.app/#/

Github 仓库：
https://github.com/ItsJonQ/g2-prototypes/tree/master/

太棒了，@ItsJonQ！ 感谢您的出色工作！

我注意到的第一件事是，有运动障碍的人或任何使用鼠标有困难的人可能会遇到崩溃效应。

我会说这会在一定程度上影响任何人。

消除坍塌效应可能对此有所帮助。

@diegohaz感谢您的反馈！

我自己也注意到了一些交互挑战。 而且我认为我的运动技能还可以。 所以我可以想象其他人可能面临的挑战。

根据您的反馈以及其他人的反馈，我添加了一个选项来查看您的鼠标轨迹。

我认为这将有助于直观地展示交互的难易程度：

我认为这个工具可以帮助我们完善一些交互/用户体验的想法:)

消除坍塌效应可能对此有所帮助。

我会试试的！

👋 你好！

x-posted from https://github.com/WordPress/gutenberg/pull/18685#issuecomment -562676154

玩了一会后...

我有一个替代交互模式的想法，试图减轻 UI re: movers。

（我不知道这是否以前尝试过）。

这个想法来自玩弄Notion （尽管他们不在他们的推动者中使用箭头）。

这些是我的初步想法+观察

@diegohaz我添加了去抖动功能：D
https://tz3ir.csb.app/#/toolbar -base

引用@afercia 的评论：

许多用户（例如键盘用户、屏幕阅读器用户）以线性化方式浏览内容。 当他们降落在一个区块中时，他们会在最终降落在区块内容上之前找到几个属于该区块 UI 的控件。 插入器、移动器、块工具栏：它们都在源顺序中位于块主要内容之前。 这使得这些用户的体验远非理想。

理想情况下，用户应该首先找到块主要内容。 之后，控制其他操作：移动、格式化、添加。 这也将复制最合乎逻辑的工作流程，每个人都希望

• 先添加内容
• 然后格式化内容，移动内容，找到其他选项，最后找到插入器以添加新块
  与可访问性一样，UI 控件的逻辑顺序和分组是最重要的。 值得注意的是，可访问性团队多次询问是否可以选择在块之后移动块工具栏。

出于这个原因，我认为最好将移动控件合并到块工具栏中，因为将其与在块下方显示工具栏的选项相结合将提供比我们现在更好的键盘体验。

我不喜欢在悬停块图标时让移动器滑出。 这对我来说太隐蔽了。 我认为更好的解决方案是在始终可见的块图标右侧放置一个拖动手柄。 悬停或点击拖动手柄会导致它展开并显示箭头控件。 插入它也会导致它扩展，焦点会跳转到箭头控件（因为拖动手柄对键盘用户没用）。

要记住的另一件事是键盘用户如何访问移动控件（如果它是单个可拖动按钮）。

一种选择是通过按Enter或Space来激活它，然后使用箭头键来移动块。 当它发生变化时，应该通知屏幕阅读器用户新的块位置（可能使用 aria-live 区域）。

用户可以按Escape退出此模式，然后再次使用箭头键在工具栏项目之间移动。

也许即使对于视力正常的用户来说，这也是一个更好的用户体验？ 在我看来，当前行为的用户体验非常差。 当您使用可拖动手柄时，很难找到放置它的正确位置。 由于位置变化，随后对箭头按钮的点击速度很慢（虽然您可以在聚焦箭头按钮的同时多次按下Enter键，但这感觉不够直观）。

相关 #6289

鉴于上述评论和想法，这里对推动者进行一些进一步的探索。 我希望捕捉集体情绪和个人细微差别，我们都可以在打开的 figma 文件中继续探索： https : = 85%3A6975

我们还可以在交互模型@ItsJonQ 中翻译这些内容，以查看它们的实际效果。
不同的选项有不同的细节和权衡。

选项 1：上下文，当相关时推动者出现。

选项 2：默认可见，而 _block type_ 失去了作为锚点的性质。

选项 3：移动器位于工具栏的右侧。

选项 4：依赖拖动行为，而这对于所有类型的用户来说都是一项困难的运动技能，即使在桌面上也是如此。

@pablohoneyhoney 😍太棒了！！ 我会尽量模拟这些。 戳他们会很有趣

关于块移动器的想法

我认为无论我们采用什么设计，都必须保留用于向上/向下（或向左/向右）移动块的各个按钮。 依赖拖动手柄不利于可访问性，无论如何，箭头按钮通常更快更容易使用。 拖放应该是次要的增强。

我也强烈建议不要让箭头按钮太小。 它们应该很容易在所有（不仅仅是移动）视口宽度的触摸屏上点击。

https://github.com/WordPress/gutenberg/pull/18685#issuecomment -564025483 目前将移动器实现为两个单独的箭头按钮，它们兼作拖动手柄，从而减小移动器的大小，同时增加拖动手柄的大小。

仍然可以使移动器仅在悬停工具栏或单击某些内容（可能是单击时扩展为完整移动器的按钮）后才出现，但在设计中的某处需要有 2 个正常大小的箭头按钮。

关于移动器应该在工具栏中的哪个位置，从键盘导航的角度考虑它可能会有所帮助。 当使用 Tab 键进入块工具栏时，控件的什么 Tab 键顺序最有意义？ 无论答案是什么，它都应该作为视觉顺序的基础。

对块工具栏结构的总体思考

目前，块工具栏的顺序似乎是将块级控件放在左侧，将内联控件放在右侧。 块转换器/切换器影响整个块（并且在某些情况下会改变块类型），块对齐下拉列表影响整个块，然后内联格式化工具只影响块的一部分。

但是，此规则有一个例外：“更多选项”菜单。 此菜单仅包含影响整个块的选项，但它位于工具栏的右侧。

现在考虑一下：块切换器/变压器放置在带有块图标的按钮下。 乍一看，这个按钮应该打开块的常规设置菜单。 在某种程度上，这是正确的，转换/样式放置在那里。 但是，其余的常规选项都在省略号菜单中。

我注意到这个模型几乎将块图标按钮变成了另一个下拉菜单：

样式被放入子菜单中，从技术上讲，转换也可以放入一个子菜单中。 （也许他们应该，考虑到像 Paragraph 块这样的一些块的大量转换。）或者，两者都可以变成按钮，打开一个模态，为可用选项提供更多的喘息空间（包括更多的预览空间）。

为什么不更进一步，将块图标菜单与省略号菜单结合起来呢？

或者，如果块图标按钮接管了省略号菜单当前服务的角色，并且块样式和/或转换被移动到工具栏上的单独按钮中怎么办？

@pablohoneyhoney更新！ 添加了一些更新的 Mover 原型！
https://tz3ir.csb.app/#/toolbar -movers

为什么不更进一步，将块图标菜单与省略号菜单结合起来呢？

这是一个值得探索的有趣想法。 最大的问题是我们不应该隐藏转换，因为它是基本格式的一个非常重要的交互。

然而，我们选择公开转换，设计需要考虑大量可用的转换。 现在在我的网站上，Paragraph 块的可用转换如下所示：

我之前评论中的模型中显示的简单列表可能无法很好地扩展这么多选项。

从我最初的阅读开始，我很兴奋。 正在提议的更改感觉就像是界面的新鲜空气。 脑海中浮现的话语简单而平静。

使事情与块更相关也是有道理的。 我不确定最初是否将移动器带入工具栏，但了解如何在上下文中将它们转换为水平会更有用。 此外，我看到有人在讨论它们是否始终可见。 这是我自己不确定的事情。

Mapk：强烈的对比是美丽的。 😍

同意！ 看着那个新的对比，感觉很放松。

Karmatosed：我们可以讲述什么故事，我们可以通过动画、拖动和弹跳来增强什么？

很想看看我们可以在哪里探索运动！

在#19344 Riad 和我正在慢慢开始在实践中尝试这个 UI。 该分支仍在进行中，要全面评估还为时过早。 但是，这是对某些想法进行测试的好方法。

例如，强调在块足迹上的焦点轮廓而不是开始块边界而不管焦点似乎工作得很好：

此轮廓与块选择共享 DNA，无论是在视觉上还是在块具有此蓝色轮廓时，您都可以按 Delete 直观地删除块：

它还有助于统一普通块和浮动块的外观和行为，使浮动块感觉更直观：

最后一个 GIF 还展示了 Image 块的一个有趣方面，因为 _caption_ 字段是块的一部分，因此在选择块时突出显示（并且可以使用 Delete 键删除）：

只要您按 Tab 键进入标题字段，或向后进入工具栏，焦点就会移动到那里。 如上所示，标题字段在焦点轮廓附近有点紧凑，这在技术上是块 _footprint_ 的准确预览。 但是有没有一种通用的方法来更优雅地处理这个问题？

但是有没有一种通用的方法来更优雅地处理这个问题？

在我看来和小经验:)，试图变得太聪明通常不是最好的方法。 由于这是重点元素的准确表示，我想知道是否最好将其保留原样，即使在设计方面，它并不完美。

我真的很喜欢这些变化让一切变得更加一致。 终于有意义的浮动轮廓特别好。 就我个人而言，我不介意图像块标题周围的紧凑轮廓，因为它是实际块大小的准确表示。

设计从来都不是完美的 :) 但我们也可以继续探索以避免：

从概念上讲，界面似乎不尊重用户的内容。

@pablohoneyhoney看起来轮廓需要移动以触摸但不与块足迹的边缘重叠。

@ZebulanStanphill我相信它因为占位符而被移动到重叠以避免“双边框”问题（占位符有黑色边框）。

感谢您的反馈，我想我基本上同意所有这些，但主要是它给了我一些探索的想法，我会回来的！

移动到占位符的框阴影（加上 Windows 高对比度模式的透明轮廓），以及用于焦点/选择的完全开始而不是 1px 重叠边框改进了很多东西：

它仍然很紧，但肯定比以前好。

今天在

对于订阅此线程或登陆这里的人来说，#19344 中的一个分支接近稳定点。 获得有关该分支的进一步想法和反馈会很棒，但否则，如果您能够查看并尝试该分支，那么这是查看此线程中概述的一些想法在行动中的好方法。

再一次问好！ 在 #19348 中，我致力于在编辑画布之外扩展这张票中概述的一些 UI，包括给顶部工具栏一些爱，正如这里所讨论的：

请随时继续尝试分支，非常感谢您的评论想法。

看起来不错@jasmussen。 我很好奇 - 是否有理由在工具栏/导航器控件中有两个不同的focus边框半径值？

应该只有一个统一的半径，在这种情况下绝对是 2px。 目前有几种非常特殊的情况，其中边界半径实际上变成了一个更大的像素，因为所讨论的项目已经有一个边界，并且初始焦点样式因此将最外层半径增加了 1px。 我认为可能有一两种情况可以调整，但目标绝对是一个半径。

关于这个模型，我想知道一些事情：

这将如何在移动设备上运行？

在我的所有帖子中使用 Gutenberg，我最想说的是，我发现识别菜单中的图标比识别文本更快，而且我不认为删除图标有任何改进。 提高对古腾堡的接受度和使用率，也是为了让它对新用户友好。 删除被认为“不必要”的友好图标对此无济于事..（纯粹是我的意见 - 没有用户测试来支持该声明）

我只想评论@oldrup 的图标评论
我们可以通过图像或文本在视觉上识别某些东西。 在文本旁边放置图标确实有助于更好地识别我们正在查看的内容。 使用一个图标，我们会逐渐建立一种认知，当我们在另一个位置看到这个图标时，我们会自动理解它代表什么。

这里还剩下什么吗？ :)

这里还剩下什么吗？ :)

是的！ 很多！ 有菜单的重新排列，在侧边栏中有很多工作要做以减少和对齐到网格，而且工作永远不会结束。

我不反对关闭此票证，因为解决了刷新的主要问题，并且可以单独创建可操作的后续问题。

他重新调整菜单是否存在跟踪问题？ 进入5.5会很好。