Gutenberg: wp-admin中的小部件阻止屏幕

当前的窗口小部件视图绝对是在考虑侧栏的情况下设计的，但是窗口小部件区域（现在是块区域）也可以是页脚，页眉等。我认为这是更新此页面时应考虑的一件事。

在单个页面上具有所有小部件/块区域可编辑的感觉很奇怪。 我认为此屏幕应该更像自定义程序中的小部件区域编辑器。 值得注意的是，当前wp-admin小部件页面的一个优点是您可以将小部件从一个小部件区域拖放到另一个小部件区域。 我不确定如果“小部件”屏幕变得更像“定制器”，那么您将如何复制此功能。 也许小部件区域将显示为顶部栏或侧边栏中的标签，并且在这些标签上拖动一个块会将视图切换到该块区域...有点像您如何将文本/图像从一个标签拖动到另一个在网络浏览器中或在大多数操作系统中从一个应用程序转移到另一个应用程序。

并且不要忘记无效的窗口小部件区域...这如何适合所有这些？ 我了解它的目的，但是在Gutenberg修饰的Widgets屏幕的背景下感觉很奇怪。

此外，左侧的块选择似乎有些奇怪。 我认为应该将其更改为帖子编辑器中的块插入器和Customizer小部件插入器的混合。 说到这，这似乎是将拖放插入添加到块插入器的好机会。 wp-admin和Customizer中的当前小部件区域编辑器都具有拖放插入功能，但post编辑器中的块插入器当前没有。 参见＃1511。

另外，此模型似乎未考虑块检查器。 就像在帖子编辑器中一样，它应该出现在屏幕的右侧。

通常， wp-admin的“窗口小部件”页面感觉很奇怪，在当前的模型中甚至感觉很奇怪。

我们要混合使用小部件和块还是实质上不赞成使用小部件？

我认为他们想用“小部件块”替换小部件-在小块和小部件之间。
也许用gutenberg pagebuilder工具替换主题，时间就会证明...

@nicholasio我认为当前的计划是将小部件区域变成块区域，并且将有一个“旧式小部件”块，可让您将任何旧的小部件嵌入到块区域中。 （大概，您可以在任何地方使用“旧版窗口小部件”块，这意味着您实际上可以在帖子和页面中使用窗口小部件……以前不可能的事情。）大多数（如果不是全部）WordPress核心小部件将被弃用并替换为新块等效项。

因此，从本质上讲，小部件已被弃用，但您仍然可以将其与块一起使用。

当前的窗口小部件视图绝对是在侧边栏设计的，但是窗口小部件区域（现在是块区域）也可以是页脚，页眉等。

我想知道我们是否可以探索这些“区域”如何在页面本身上显示。 即。 如果是侧边栏区域，则显示为现在，但是如果是页脚或页眉，则显示在页眉/页脚所在的位置。 因此，它成为页面本身的粗略布局。 我会模拟的。

此外，左侧的块选择似乎有些奇怪。

作为手风琴，它很可能会崩溃并且不会那么令人不堪重负。

另外，此模型似乎未考虑块检查器。 就像在帖子编辑器中一样，它应该出现在屏幕的右侧。

我想你就在这里。 我会准备一些样机，以进行更多的对话。

此外，左侧的块选择似乎有些奇怪。

作为手风琴，它很可能会崩溃并且不会那么令人不堪重负。

令我困扰的是，它看起来不像帖子编辑器中的插入器。 为什么插入器应该是“窗口小部件”页面上始终可见的侧边栏，而应该是帖子编辑器中的弹出窗口？ 另一方面，也许帖子编辑器应该像小部件库侧边栏一样可停靠在一边？ 无论如何，我认为在不同上下文中出现块插入器的方式必须保持一致。

同样重要的是要注意，与帖子编辑器的插入样式相比，小部件/块库设计在移动设备上不能很好地工作。 也许停靠的侧边栏插入器应该在移动设备上变成弹出式插入器？

我尝试使用Figma做一些原型制作。 这是我提出的一个概念。 我想看看是否还有另一种方式可以在上下文中显示“小部件区域”，而不是将它们堆叠在一起。 这将替换wp-admin中的/widgets.php。

原型

https://www.figma.com/proto/O6SyONtxLjcUxsHq59EfStPs/integration-widgets?node-id=0%3A1&scaling=min-zoom

视频

有什么想法吗？

@mapk我不确定如何在实践中实现该模型。 小部件区域可能会出现在不同的位置，具体取决于页面模板，当然，某些小部件区域只会出现在某些页面模板中。 除非您只想一次显示一个页面模板的布局（具有在它们之间进行切换的能力），否则很难以一种有意义的方式将所有窗口小部件区域装配到一个屏幕上。

似乎要听取小部件屏幕上“使用实时预览管理”按钮的建议会更有成效。 该链接是弃用管理屏幕的第一步，转而使用带有实时预览的定制程序版本。 窗口小部件管理屏幕与窗口小部件区域实际工作的方式有根本的区别-不同的区域显示在屏幕的不同部分，也可能显示在站点的不同部分。

很难以用户能够理解的方式在此屏幕上清楚反映前端页面结构。 在定制器中尝试使用上下文方法来获得这种体验，为解决该基本问题提供了许多机会。 从已经存在于核心中的可见编辑快捷方式开始，可以在前端（自定义预览）上或在与特定屏幕上的显示更直接相关的叠加层中直接编辑经过修改的小部件。 可以在自定义预览中导航到站点的不同部分的功能解决了该屏幕永远无法解决的问题。

我建议放弃该建议，并以＃13205结尾解决此问题。

试图以一种有意义的方式将所有小部件区域装配到单个屏幕上，将很难实现

同意我认为原型对我来说是一种蒸馏的方式。

窗口小部件管理屏幕与窗口小部件区域实际工作的方式有根本的区别

这是事实，也是上面进行探索的原因。 我完全同意！

我建议放弃该建议，并以＃13205结尾解决此问题。

该屏幕是第2阶段的

尽管此屏幕最终将在未来被弃用，尤其是随着更多站点在Gutenberg中建立，这是使我们大家团结在一起的必要“婴儿步骤”。 也许最好的办法是保留现有布局，但是只允许使用手风琴内容区域内的所有块？ 这将使我们在此特定部分上的资源和投资降至最低，仅对初始文章中的模型进行了一些建议的调整。 它还将使我们能够更快地移至定制器。

我建议放弃该建议，并以＃13205结尾解决此问题。

对于“菜单”屏幕已经进行了相同的考虑，请参阅https://github.com/WordPress/gutenberg/issues/13206#issuecomment -455452477。 定制器不能完全访问。 管理员窗口小部件屏幕是唯一具有可访问性需求的人有机会管理窗口小部件而不必面对巨大的可访问性障碍的地方。

我还想提醒大家，“小部件”屏幕具有另一种“辅助功能模式”（只需单击右上角的链接）。 如果新的管理屏幕从一开始就考虑到可访问性，那么我将完全赞成删除可访问性模式。 首先，这意味着：不要花哨的事情，请使其尽可能简单。

在开始任何可视化模型之前，开始解决可访问性的一个好方法是首先设计信息体系结构。 在此屏幕上将其视为空白文档，在该文档中，需要使用标题来组织信息以标识主要部分和任务，将逻辑相关的控件组合在一起，并确保以线性方式浏览内容时感知到的信息有意义。

回复：左侧的方块选择：

作为手风琴，它很可能会崩溃并且不会那么令人不堪重负。

左侧的整个部分是否确实需要？ 我倾向于认为与＃13206中“菜单”屏幕中提出的设计的一致性很重要。 也许我缺少了一些东西，但是只有带有插入器的Widget区域会大大简化用户界面。 它还将消除左右部分之间的拖放，这将是可访问性的胜利。

就是说，据我所知，所有核心小部件都是块。 但是，插件和主题添加的自定义小部件会怎样？ 并非所有这些都将立即更新为块。 是否需要某种向后兼容机制，例如在元框的情况下？ /抄送@youknowriad

就是说，据我所知，所有核心小部件都是块。 但是，插件和主题添加的自定义小部件会怎样？

这个想法是建立一个经典的小部件块，能够渲染任何小部件的编辑和预览（像现在一样） https://github.com/WordPress/gutenberg/issues/4770

它还将消除左右部分之间的拖放，这将是可访问性的胜利。

从技术上讲，不支持拖放也将更加容易/快捷，因为现在，我们不能有一个针对多个编辑器的插入器。

这个想法是建立一个经典的widget块，能够渲染任何widget的编辑和预览（像现在一样）＃4770

+100
这正是我们所需要的。 感谢您已经记住了这一点！

还可以尝试在网站的不同部分上以不同方式显示窗口小部件的方式吗？ 我在https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2/#comment -35058上提到了一些搜索用例

这篇文章还显示了一些用例，其中根据用户所在页面的类型，布局会有所不同：主页，单个页面或单个帖子。 我认为存档页面，404等也都是重要情况。

在单个页面上具有所有小部件/块区域可编辑的感觉很奇怪。

这是它相对于定制器的最大优势之一。 您可以一次看到分配给所有区域的所有小部件。 对于我来说，定制器是非常有限的。

当前wp-admin窗口小部件页面的一个优点是，您可以将窗口小部件从一个窗口小部件区域拖放到另一窗口小部件区域。

我不想失去这种能力！ 我经常使用它，而我写的主题基于这样做的难易程度。 这包括不活动的小部件。 如果您使用手风琴或隐藏某些小部件区域，则将限制可调整性，如“定制程序”中一样。

并且不要忘记无效的小部件区域

请不要摆脱这一点。 这对于以编程方式进行的主题切换很重要。 但是对于能够检索使用其他主题时可能输入的信息也很重要。 对于小部件使用定制程序，最大的问题是无法访问不活动的小部件。

为什么小部件必须更改为块？ 它们不是已经成为一种类型的块，而新的块才刚刚赶上它们吗？ 为什么要摆脱已经根深蒂固的API？ 当我们已经有小部件区域和内容时，为什么要切换到定义“内容区域”？ 当新孩子可以轻松地与现有孩子融为一体时，为什么要为“新孩子”重做一切？

为什么小部件必须更改为块？ 它们不是已经成为一种类型的块，而新的块才刚刚赶上它们吗？

你是对的，@ joyously。 小部件已经有点像块。 但是，无法在页面上的任何位置轻松添加它们，尤其是在古腾堡中。 将它们转换为块可以解决此问题。 现在，小部件块可与其他块同等对待，并且可以在古腾堡内的任何位置添加。 wp-admin中的窗口小部件屏幕正在更改以反映这一点，并帮助每个人了解块的范例。

这是此屏幕的原型。 请及时反馈。

1. 将单词从“窗口小部件”更改为“窗口小部件块”以帮助传达变化。
2. 保留当前窗口小部件屏幕的功能。
3. 在吹出的面板中使用古腾堡块插入器。 我保持这种白色，以便进行明显的更改，并且还模仿了古腾堡的嵌块插入器。
4. 窗口小部件块区域仍会照常显示，但与古腾堡编辑器类似，会反映_blocks_。 实际上，它们就像迷你的古登堡（Gutenbergs）。 😉
5. 我从这些中缺少检查员（Gutenberg侧边栏），应该仔细考虑一下。 如果窗口小部件屏幕将包括Gutenberg与块（工具栏，插入器，检查器）进行交互的所有内容，则可能会变成更大的Gutenberg屏幕，以允许所有这些操作。

原型：

https://wp.invisionapp.com/share/VYQ6PWPWTH3

原型视频：

辅助功能

我想对这些想法进行一次回顾。 古腾堡的块插入器是否满足所有需求？ 如果是这样，那么此原型是否适用于a11y？ 用户现在应该可以直接从窗口小部件区域插入新的块。

为什么要将小部件块与块混合？
我认为他们应该分开...

像段落或标题一样-不是小部件块...
为什么不制作一个文本编辑器或Gutenberg Editor小部件块，使其内部包含所有这些块呢？

为什么要将小部件块与块混合？

这真是太好了！ 随着越来越多的WordPress在Gutenberg界面中变得可编辑，您将可以在所需的任何位置添加块。 我使用的是“ widget-blocks”一词，目的是帮助实现这一目标。 最终，术语“小部件”根本不会被使用，因为一切都会成为障碍。 不过这是一个出路。

但是也许这样说可能引起更多的混乱？

为什么不制作一个文本编辑器或Gutenberg Editor小部件块，使其内部包含所有这些块呢？

我不确定我是否遵循，但是正在开发一个Classic Widget块（＃4770），它将像一个块一样工作（可以在Gutenberg界面中的任何位置添加），但是包含尚未转换为块的小部件。

您的模型的背景是什么？ （由于没有预览，因此我假设它是管理页面。）当前在管理页面上，不需要配置的小部件可立即在前端查看。 那是您的模型中正在发生的事情吗？ 如果没有，“保存”按钮在哪里？ 当前，每个小部件都有一个“保存”按钮。

不活动的小部件在哪里？ 您可以将小部件从一个区域移动到另一个区域吗？

可以为小部件定义的描述在哪里？

当您在左侧栏中单击时，为什么该块会转到第一个窗口小部件区域？ 有两个打开的小部件区域，您如何知道它的去向？ +仅适用于GB块吗？ 还是只适合左边的人？

保存按钮在哪里？ 当前，每个小部件都有一个“保存”按钮。

这将自动保存，类似于Gutenberg。 我意识到小部件具有保存按钮，但是请记住，这些不再是小部件，它们是块，并且将与古腾堡中的块一样工作。

不活动的小部件在哪里？ 您可以将小部件从一个区域移动到另一个区域吗？

接得好。 无效的窗口小部件仍然需要思考。 我们要如何显示这些窗口小部件以及尚未转换为块的任何其他窗口小部件？ 也许有一个包含此内容的部分？

可以为小部件定义的描述在哪里？

尽管这些是块而不是窗口小部件，但是描述可能会在检查器中定义，就像现在在Gutenberg中一样。 我在这里的＃5中提到了检查员。

当您在左侧栏中单击时，为什么该块会转到第一个窗口小部件区域？ 有两个打开的小部件区域，您如何知道它的去向？

我不知道如何在原型软件中创建拖放接口。 因此，我仅使用“点击”引用来尝试和传达操作。 这并不完美，但是当我提到“保留当前小部件屏幕的功能”时，我真的希望每个人都能半途而废

+仅用于GB块吗？ 还是只适合左边的人？

左侧的所有内容都是一个街区。 如前所述，阶段2的重点之一是将小部件转换为块。

我希望解释能有所帮助。

观看该GIF图像时，我强烈希望进行拖放操作，此外，不清楚单击该块时将添加到哪个侧边栏。 我确实喜欢左侧的高度

最初的描述是：

第2阶段的第一步将涉及升级小部件UI，以合并一个现代的块编辑器，该编辑器与您在Gutenberg中编辑页面和帖子的方式一致

我认为这是误导的。 首先，当任务非常不同时，使所有内容看起来都一样会令人困惑。 小部件与编辑帖子或页面不同。 它看起来应该有所不同，更像是已经存在。
其次，您尚未解决基础架构。 如果要更改小部件的完成方式，是否要更改其存储方式？ 您是否正在更改它们的书写方式？ 您是否正在更改主题的输出方式？
核心小部件已经成为块。 块不必成为小部件。
真正的目标是什么？ 如果您只想使小部件页面看起来像编辑器页面，那么我认为这是个坏主意。 如果您只是为了使事情有所不同而想重新安排事情，我认为这不是对资源的良好利用。 如果阶段2的确更多地与定制程序有关，那么也许该窗口小部件页面应该被单独放置，而定制程序中新界面的设计应该是目标……但是它引出了同样的问题。

古腾堡的块插入器是否满足所有需求？

有点。 古腾堡（Gutenberg）用户界面是许多权衡取舍的结果，这些权衡并没有带来很好的可访问性。

如果小部件区域将要使用插入器，则不确定我为什么仍要保留整个左列。 对我来说，似乎是重复的UI。

我还建议考虑不要盲目地重用Gutenberg中使用的某些模式，因为它们对可访问性不是特别好。 在古腾堡（Gutenberg）中，存在许多折衷方案，这主要是因为UI某些部分的空间非常有限。

相反，在此屏幕中，由于没有空间而没有限制。 具体来说，作为初步考虑：

• 仅使用图标的按钮是有问题的：在此屏幕中没有理由使用“ +”按钮，没有足够的空间来使用带有文本的按钮
• 如果左列保留：在搜索字段中，请勿使用占位符

另外：顶部的“使用实时预览进行管理”总是会伤害我的感觉-也许这将是一个重新思考它的好机会。

今天早上花了几分钟思考这个问题，我想分享另一个混合模型以进行更多讨论：

原型
https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen?node-id=14%3A297&viewport=-818%2C1575%2C0.5&scaling=min-zoom

GIF

_如果有人想扩展这个想法，这里是Figma链接。_

• 它使Gutenberg的顶部工具栏和边栏始终存在，因此熟悉添加和编辑块。 我们还可以包括通常的古腾堡自动保存指示等。
• 尽管编辑框架非常古腾堡（Gutenberg-ey），但您却像每个人一样在小部件容器中进行编辑。
• 我没有使用标准的微小块插入器按钮，而是在每个容器内添加了一个更大，更明显的[ + Add block ]按钮（受图像画廊中的Add按钮启发）。
• 它还包括一个无效的窗口小部件区域。

@kjellr我认为样机非常好。 这是我要添加/更改的一些内容：

检查器的“窗口小部件区域”部分到底将用于什么？ 如果有的话，我可能希望有一个“窗口小部件区域”选项卡，而不是一次所有窗口小部件区域的选项卡。

根据我刚才指出的内容，我希望每个小部件/块区域都单独进行编辑。 这样，可以调整内容宽度以匹配每个块区域，从而提供更多的所见即所得体验。 块的流向（侧栏为垂直，页眉和页脚为水平）也可以自定义。

仍然可以在底部显示不活动的块，类似于在帖子编辑器的底部显示元框的方式。 但是，我质疑在古腾堡环境中不活动的小部件/块功能的有用性。 可重复使用的块系统已经可以充当预配置块的存储，因此，应该重新评估整个非活动小部件的想法。

我认为，如果可以将插入程序作为全高侧边栏停靠在桌面的一侧，并像在当前“窗口小部件”屏幕中的窗口小部件库一样使用它，那就太好了。 （当然，这种对接功能也应存在于帖子编辑器中。）

此外，如@afercia所述，插入器中的搜索栏（无论它是否可停靠，始终是侧边栏或始终是弹出窗口），应确实使用标签代替占位符。 也许可以将标签的样式设置为最初看起来像占位符，但是当搜索栏处于焦点位置时，它会向上移动到输入区域上方，就像Google的登录UI中的输入字段如何工作一样？

我认为“添加块”占位符/按钮太大了。 “添加块”可以缩写为“添加块”，并移动到图标的右侧。 实际上，我认为帖子编辑器中的非段落块附加器应与最终在新的Widgets UI中使用的附加器设计共享相同的设计。

在顶部栏中，插入器图标（未在模型中显示，但可能会出现在其旁边）应在其旁边带有标签。 实际上，那里的所有按钮都应该带有标签，在“选项”模式中有一个选项可以显示/隐藏标签。 （当然，帖子编辑器也应该存在。）

此外，如@afercia所述，插入器中的搜索栏（无论它是否可停靠，始终是侧边栏或始终是弹出窗口），应确实使用标签代替占位符。 也许可以将标签的样式设置为最初看起来像占位符，但是当搜索栏处于焦点位置时，它会向上移动到输入区域上方，就像Google的登录UI中的输入字段如何工作一样？

这有问题吗？ 听起来这是我们需要在全球范围内解决的问题，而不是在这里。

在顶部栏中，插入器图标（未在模型中显示，但可能会出现在其旁边）应在其旁边带有标签。 实际上，那里的所有按钮都应该带有标签，在“选项”模式中有一个选项可以显示/隐藏标签。 （当然，帖子编辑器也应该存在。）

同样的问题。

检查器的“窗口小部件区域”部分到底将用于什么？ 如果有的话，我可能希望有一个“窗口小部件区域”选项卡，而不是一次所有窗口小部件区域的选项卡。

我不太确定！ 也许只是所有小部件区域的可单击列表（以防它们不适合屏幕显示）。 我现在包括它的主要原因是为了反映我们在帖子/页面编辑器中使用的层次结构：文档/块。

我认为“添加块”占位符/按钮太大了。 “添加块”可以缩写为“添加块”，并移动到图标的右侧。 实际上，我认为帖子编辑器中的非段落块附加器应与最终在新的Widgets UI中使用的附加器设计共享相同的设计。

肯定会反复进行。 一般的想法是拥有一个非基于文本的插入器，因为（我推断）人们会在这里添加不同类型的内容的可能性更大。

无论如何，如果我们确实在这里使用其他类型的插入器，则需要有充分的理由，并且我们需要提出明确的准则来使用一个或另一个插入器以防止滥用。

也许可以将标签的样式设置为最初看起来像占位符，但是当搜索栏处于焦点位置时，它会向上移动到输入区域上方，就像Google的登录UI中的输入字段如何工作一样？

我建议反对。 “浮动标签”动画令人迷惑并且出乎意料，特别是对于具有辅助功能需求的用户而言。 另外，此模式不会节省任何垂直空间：仍然需要在字段顶部保留一些空间。 它基本上没有达到其主要目的。

一些资源（赞成和反对）：

• https://medium.com/simple-human/floating-labels-are-a-bad-idea-82edb64220f6
• https://medium.com/@mds/are -float-labels-really-that-problematic-after-all-da7ffe7d5417
• https://joshuawinn.com/ux-input-placeholders-are-not-labels/
• https://feedbackguru.com/articles/form-without-labels-dont-use-placeholder-text/

根据实际，可见的<label>元素而不是占位符的用法，请参阅相关Trac票证上链接的资源https://core.trac.wordpress.org/ticket/40331

我们能否继续将讨论集中在问题的目标上。 @kjellr似乎是朝正确方向迈出的重要一步。

真的很喜欢样机，@kjellr！ 感谢您对此进行仔细考虑。

1. 我喜欢古腾堡（Gutenberg）界面，并愿意在此屏幕上进行跳转，因为它紧密地包含了检查器（侧边栏）。 这是必要的举动。
2. 保持窗口小部件区域的堆叠方式类似于今天的使用方式，可以保持一定程度的熟悉度，我认为现在的现有用户也需要这种熟悉度。
3. 让我们从顶部栏中删除“窗口小部件”一词，也许现在，Inspector只是一个“块”检查器。 因此，我们从此处删除“窗口区域”。 在这一点上，我们正在以可视的方式向块过渡。
4. wp-admin导航是否仍保留“小部件”命名约定？ 我现在倾向于“是”。
5. 我喜欢块插入器。 我唯一的建议是，图库块中的插入器使用句子大小写，而不使用标题大小写。 也许，这个应该模仿吗？ “添加块”

@mapk

让我们从顶部栏中删除“窗口小部件”一词，也许现在，Inspector只是一个“块”检查器。 因此，我们从此处删除“窗口区域”。 在这一点上，我们正在以可视的方式向块过渡。

同意

wp-admin导航是否仍保留“小部件”命名约定？ 我现在倾向于“是”。

我想从长远来看，该页面应该重命名为“块区域”或其他名称？ 最初甚至在导航中将其称为“块区域（小部件）”。

让我们从顶部栏中删除“窗口小部件”一词，也许现在，Inspector只是一个“块”检查器。 因此，我们从此处删除“窗口区域”。 在这一点上，我们正在以可视的方式向块过渡。

我在顶部添加该标签的主要原因是在此处添加某种页面标题或H1。 我想我们可以把它放在其他地方。 可能在“小部件区域”上方，也可能在侧边栏中。

我喜欢块插入器。 我唯一的建议是，图库块中的插入器使用句子大小写，而不使用标题大小写。 也许，这个应该模仿吗？ “添加块”

是的在Figma文件/原型中对此进行了更新。 👍

它使古腾堡的顶部工具栏和边栏始终存在

正如古腾堡（Gutenberg）的可访问性团队报告所指出的那样，具有1）顶部栏2）内容区域3）侧栏的布局是主要的可访问性障碍之一，因为它使键盘导航极为困难。

为什么首先需要顶部栏？ 应该在那里？

在古腾堡（Gutenberg）开发的最初阶段，对保存/发布按钮的放置进行了冗长的讨论。 将其放在顶部对于辅助功能不是理想的选择。 对此没有共识，可惜，它过去了。 我不确定在此页面上重复一种不太理想的模式是前进的最佳途径。

内容线性化是一个好的信息体系结构的基本原理。

许多用户按照DOM中的顺序以线性方式感知内容。 所有键盘用户和屏幕阅读器用户都是如此。 以线性方式有意义的方式组织信息对于良好的可访问性至关重要。

自然，最明显的逻辑流程通常是：

• 做事情，填写字段等，设置设置等。
• 然后_保存

甚至不确定是否需要“保存”按钮，但是如果有的话，该按钮和任何其他“全局”控件应该位于线性化导航体验的结尾：位于页面底部。

值得注意的是，内容线性化也是控制移动用户界面的原理，用户的手在设备的底部the

侧边栏：不确定是否需要它。

“控件区域”选项卡中应包含哪些控件或设置？

“阻止”标签中有哪些控件？ 之前已经有关于侧边栏中的块设置的讨论：将块保持在“选定”状态，然后跳转到侧边栏以对放置在此处的块设置进行操作是非常困难的。 应不惜一切代价避免这种情况。

最后：标题。 它们仍然是用于在页面中主要机制。 标题允许辅助技术用户跳到页面的不同部分。 根据最终设计，需要使用标题来标识页面的主要部分。

我认为所有这些探索已经清楚地表明，无论如何都需要修改帖子编辑器。 将Widgets页面更改为类似于后期编辑器的大多数问题是在任何情况下与Gutenberg编辑器有关的问题，而不仅仅是窗口小部件/块区域。

我认为我们应该借此机会用一块石头杀死两只鸟，并修改当前的Gutenberg编辑器，以便它可以正常替换当前的Widgets屏幕，并且通常更易于使用/访问，因此更适合于帖子/页面编辑。

无论如何，我都使用@afercia ，因为我不想看到与帖子编辑器相同的问题被复制到“小部件”页面中。

在我看来，所有建议都只是破坏了一个完全可用的页面，没有任何好处。

对上面的方向进行

原型：

https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen-Exploration?node-id=14%3A297&viewport=2639%2C1532%2C0.5&scaling=min-zoom

GIF：

• 根据@mapk的注释，将“
• 我将页面标题移到了内容区域。
• 我为“块区域”保留了一个全局边栏，以解释它们的含义，并提供快速链接来编辑每个区域（以防它们滚动到屏幕之外，如原型中稍后所示）。
• 从＃8589开始采用@jasmussen的备用块附加器处理。

^另外，我可以很容易地将其转换为nav-menus.php 。

不错的模型，@ kjellr; 我认为，如果它基于当前的帖子编辑器用户界面，则看起来与新的“区块区域”页面看起来非常接近。 但是，如前所述，我认为在替换当前的Widgets页面之前，应该使Gutenberg编辑器更易于访问。

特别是，我认为以下绝对应该在Widgets页面大修之前解决：

• ＃3976
• ＃10519
• ＃10524
• ＃11581
• ＃12254
• ＃13309

此外，侧栏的“块区域”部分中的描述可能应阅读

（以前称为“窗口小部件区域”）

阐明它们不再称为窗口小部件区域。

另外...也许我们应该称它们为“全球禁区”，而不只是“禁区”？ 从技术上讲， post_content每个实例都是一个“块区域”，因此术语“全局”可以帮助弄清楚所指的是什么。

实际上，现在我考虑了……全局块区域与可重用块几乎不一样吗？ 想象一下：将来您可以在Gutenberg中使用页眉，页脚和侧栏的可重用块来构建页面模板。

这实际上与＃13519相关，不是吗？ 将来，（全局）块区域将只不过是可重用的块，根本就不会有“块区”页面，而只有一个包含可重用块列表的页面以及一个包含可重用块的页面。页面模板列表...所有这些都可以用Gutenberg进行编辑。

从长期来看，我什至不认为“（全局）块区域”页面将不存在，但是@kjellr的模型可能与短期内的情况接近，因为页面模板的创建/编辑仍在进行中遥遥无期。

我同意@ZebulanStanphill，我想看看其他任何视觉模型都首先考虑的其他问题，尤其是＃11581中概述的键盘可访问性计划。 这些建议是在古腾堡（Gutenberg）进行思考的，但此处也有一些要点。

但是，在使用任何特殊的键盘快捷键或特殊机制之前，请考虑使事情尽可能简单。 请考虑内容线性化，如先前评论中所述。

我非常感谢在此所做的努力和探索，但对于主要的可访问性问题，顶部栏和侧栏仍然不满意。 我想提醒大家，此页面将是_all users_可以管理窗口小部件的唯一位置，因为不能完全访问定制程序。

由于此页面是为具有可访问性需求的用户管理窗口小部件的唯一机会，因此与当前页面相比，不应该存在可访问性下降。 相反，我们应该努力使它变得更好🙂

标题
主要的h1必须是主要内容中的第一件事，而不是页面中的其他任何内容。 我在上面的原型中看不到这一点。

保存
我仍然不清楚新的小部件是否会自动保存。 当前的窗口小部件需要一个一个地保存，这意味着应该将某个“保存”按钮放置在某个位置，并且出于可访问性的原因，它应该是“后”的块。 相反，如果有某种自动保存机制，则不需要任何“保存”按钮，而且我猜想即使是顶部也不需要。

在旁边
是否有人考虑过此页面中当前“帮助”面板的内容？ 那里有一些重要信息。 值得评估哪些部分需要保留而不是删除所有内容。

如果我可以从设计的角度提出建议：不要害怕在页面中添加一些文字well精心制作的版式很漂亮，并且页面中的一些文本信息也可以提供很大的帮助。

@afercia

对于主要的可访问性问题，我仍然不相信顶部栏和侧栏。

默认情况下，顶部栏可以放在底部并给定按钮标签，但是如何处理没有侧栏的块的检查器设置？ 您对块检查器设置的替代UI有任何想法吗？

我想提醒大家，该页面将是所有用户可以管理小部件的唯一位置，因为Customizer不能完全访问。

我很好奇：定制器的哪些部分无法正确访问？

由于此页面是为具有可访问性需求的用户管理窗口小部件的唯一机会，因此与当前页面相比，不应该存在可访问性下降。 相反，我们应该努力使它变得更好一点。

这一百次。 关于WordPress 5.0的处理方式，我最大的问题是，在经典编辑器中运行正常的几件事在不需要时就退回了古腾堡。 我真的不想看到同样的错误再次发生。

我仍然不清楚新的小部件是否会自动保存。 当前的窗口小部件需要一个一个地保存，这意味着应将某个“保存”按钮放置在某个位置，并且出于可访问性的原因，应将其放置在块之后。 相反，如果有某种自动保存机制，则不需要任何“保存”按钮，而且我猜想即使是顶部也不需要。

我认为，如果区块区域可以像帖子和页面那样进行撤消/重做，那将是非常好的。 但是，如果目前尚无法解决，那么我认为没有必要使用“保存”按钮。 实际上，当您执行撤消/重做操作时，是否还需要一个保存按钮？ 为什么帖子编辑器有一个“保存草稿”按钮？

当前模型的问题之一是帖子编辑器旨在一次编辑一个帖子，而不是多个。 撤消/重做按钮在栏中，但是在当前模型的上下文中，它们将必须跟踪对页面上任何块区域（而不只是一个块区域）所做的每次更改。 这就是为什么我希望每个块区域都像从可重复使用的块列表页面访问的可重复使用的块一样（或从字面上看）进行编辑的原因之一。

如果现在将所有块区域放在一页上，那么我认为将任何保存和/或撤消/重做按钮放在每个块区域手风琴的底部是最有意义的。

是否有人考虑过此页面中当前“帮助”面板的内容？ 那里有一些重要信息。 值得评估哪些部分需要保留而不是删除所有内容。

我同意。 我确实想知道它到底应该去哪里。 是否可以通过底部栏中的“帮助”按钮访问它？ 还是页面标题旁边或下方有一个“帮助”按钮？ 信息会显示在侧边栏还是弹出窗口中？

抱歉，此线程将变得很长且几乎无法管理。 也许我们应该尝试缩短时间，但在这一点上，我倾向于认为有关设计过程的专门会议是有价值的，以避免在第一阶段中犯同样的错误。

在任何视觉原型之前，都需要解决一些问题（例如，信息体系结构，内容的线性化），否则，与第一阶段的结果相比，恐怕不会有太大的进展。

@youknowriad等：如果有机会，请告诉我您的想法。

说：

顶部工具栏
“顶部”工具栏的内容应该是什么？ 我看到最后一个原型在其中放置了一些尚未定义的按钮。 与编辑帖子页面相比：

• “添加块”按钮没有多大意义，因为需要首先选择一个小部件区域
• “撤消”和“重做”不能像编辑文章中那样是“全局”的，它们必须是每个小部件。 正如@ZebulanStanphill指出的那样：“帖子编辑器旨在一次编辑一个帖子，而不是多个”
• 此页面的“内容结构”和“块导航”是否有意义？ 我觉得不是
• 保存/发布：尚不清楚（请参阅以前的评论）
• 我想不需要“设置”按钮来切换侧边栏
• 省略号“更多”按钮：不确定此页面是否会有“工具和选项”

最后一个原型缺少页面顶部的主要h1标题，以及页面中的其他标题。 在这方面，某些以前的原型更好。

侧边栏：

没有侧边栏的情况下，如何处理块的检查器设置

我想说的是应该先弄清楚哪些小部件需要设置，以及这些设置将是什么。
如果要像编辑器中的小部件块一样，请参见例如＃1464，＃1792，＃7941，
然后我们将重复在第1阶段中犯的相同错误。由于上一条注释和可访问性团队报告中所述的原因，重要的设置不应放在侧栏中。

我很好奇：定制器的哪些部分无法正确访问？

他们全部？ :)从文档结构开始，在Customizer UI中，所有内容都是一个列表，标题均为h3 。 滑动面板对于屏幕阅读器用户来说是一种糟糕的体验。 键盘交互通常是意料之外的，并且迫使向后跳动。 大量的仅图标控件。 许多其他事情。
定制器在设计时并没有考虑到可访问性。 随着时间的流逝，我们（可访问性团队）已经尝试修补最重要的可访问性障碍，但是要使定制器可访问性还有很长的路要走。 但是，这绝对超出了此问题的范围。

保存：
我倾向于自动保存小部件，因为它将使UI和交互更加简单。 但这应该通过可见和可听的反馈非常清楚地说明。 整个WordPress管理员的不一致之处之一是，您永远不确定要保存什么内容以及需要手动保存操作的内容。

在这个线程中有好的想法。

让我们退后一步，看看大图。 孤立地查看功能时，它倾向于忽略_destination_。 到达目的地的步骤和目的地本身都很重要，但后者应告知前者。

在这种情况下，阶段2的目标之一是扩展可以使用块的位置。 第1阶段的统一原则仍然存在：您必须学习的接口越少，越好，并且块可以将多个接口统一为一个。 这也适用于编辑器。 随着编辑器的不断发展，块可能会包含小部件所扮演的角色。 小部件区域可以映射到块区域，而小部件可以映射到块。

因此，使用窗口小部件屏幕的编辑器（如Kjell所探讨的那样），将使我们能够改进单个界​​面，而不必将精力分散在支持布局完全不同的两个屏幕上。

不管编辑器有什么问题，让我们为编辑器修复这些问题，并改进两个屏幕，而不是使自己陷入困境。 此外，随着我​​们继续探索直接在编辑器中显示其他块区域的情况，这两个界面可能会进一步融合，从而使编辑器中舒适的人在这两个界面中都能感到宾至如归。

@jasmussen谢谢，非常感谢您建议看大图。

无论编辑器有什么问题，让我们为编辑器修复这些问题并改进两个屏幕

但是，似乎您没有意识到编辑器的总体布局具有基本的可访问性问题，需要重新思考一些才能解决。 _October_上的辅助功能团队报告对此进行了很好的解释。 没有技巧，没有特殊的键盘快捷键或其他工具可以替代良好的文档结构和信息体系结构。

恐怕由于上述原因，“小部件”页面中的可访问性回归将不可接受。 如果此页面将采用现在的编辑器布局，则将存在回归。

正如Word所宣布的那样，第2阶段的目标之一也是使WordPress中的各个团队更好地合作。 设计，可访问性等都是从第一天开始就应该集成的所有元素。

有鉴于此，我希望自新功能设计流程开始以来就考虑可访问性团队的建议。 在进行任何设计之前，都需要设计一些东西things

我绝对同意改进两个屏幕。 这将需要每个人都保持开放的态度，而不是假设我们现在的现状无法改变。 正如您所说的，“目的地”还包括一个设计过程，该过程从一开始就可以解决可访问性。

我不确定在这里继续进行一般性讨论是最合适的地方，这就是为什么我提议召开专门会议的原因。

问题：假设小部件设置将像在编辑器中一样在补充工具栏中显示（注意：恕我直言，如上所述，这不是一个好主意），例如：

＃1594上的最近帖子块的屏幕截图（那里有很多设置...）

当前最新评论块的屏幕截图：

然后：所有这些设置都将存在于定制程序中？ 那里没有设置侧边栏，我真的希望不要看到其他的“滑动侧边栏”。 相关问题＃13205的屏幕截图

我强烈建议考虑使窗口小部件块在窗口小部件内具有有限的“就地”设置。

抱歉，此线程将变得很长且几乎无法管理。 也许我们应该尽量缩短时间

我在这里完全同意。 可以帮助您解决的问题之一就是让所有评论都与问题直接相关。

对于主要的可访问性问题，我仍然不相信顶部栏和侧栏。

也许这里的解决方案是从该屏幕上完全删除顶部栏？ 此屏幕是否需要顶部栏？ 我看到其目的的主要原因是为了自动保存。 可以在检查器中处理吗？ 也许现在每个块一个块？ 我不确定这是我们要介绍的模式，但是值得探索，特别是对帮助a11y。

我想说的是应该先弄清楚哪些小部件需要设置，以及这些设置将是什么。

我不同意这里。 该屏幕是关于将块集成到以前的小部件内容区域中的。 所有块都将通过此界面访问，因此设置自然是其中的一部分。

由于上一条注释和可访问性团队报告中所述的原因，重要的设置不应放在侧边栏中。

这是与特定块相关的注释，应真正委托给那些特定于块的问题。

定制器在设计时并没有考虑到可访问性。

与小部件/块相关的任何定制程序注释也应委派给该特定问题[＃13205]。

@afercia我并不是要针对您的意见，我非常感谢您提出的问题，并将竭尽全力寻找一个合理的解决方案，以确保A）符合a11y标准或至少使我们步入正轨，以及B）与古腾堡（Gutenberg）设计模式保持一致。 让我们竭尽所能，通过专门针对此问题的评论使此问题尽可能易于管理。

从@kjellr的原型开始，我进行了一些编辑。
清除了顶部的栏，因此a11y仅需要一个H1和一个Save按钮，该按钮可以保存所有小部件区域...并指示自动保存。

我相信，这是一种新的顶吧模式，所以我很想听听一些想法。 它仍然对古腾堡（Gutenberg）还是很熟悉，但是我认为由于这是迈向全面站点编辑体验的中间步骤，所以可以。

Figma原型

https://www.figma.com/proto/R0KYBQGGpdCsqgW2EWFDtK/Gutenberg-Widgets-Admin-Screen-Exploration-v2?node-id=14%3A297&scaling=min-zoom

我决定创建一些快速的模型，以探索我看到“小部件”页面的块化的两种方式...

第一种是在单个页面上显示所有块区域：

我已将顶部栏移至底部以改善辅助功能。 它几乎没有内容，因为大多数按钮通常仅在编辑单个块区域（而不是多个块区域）的情况下才有意义。

我还为栏中的按钮添加了标签，以实现更好的可访问性。 大概，这些标签只会出现在宽屏幕上，并且按照＃10524的规定，可以切换显示所有标签。

该模型还假定所有块区域都自动保存，因此缺少“发布”按钮（当应用于多个块区域时，它的意义也较小）。

大概，诸如“聚光灯模式”和“全屏模式”之类的选项将位于“更多选项”菜单中，就像在帖子编辑器中一样。

我更喜欢第二个模型：每个块区域都像帖子/页面一样被单独编辑。 现有Widgets屏幕的用户可能不太熟悉，但是帖子编辑器的用户将会更熟悉：

可以从阻止区域列表页面（实际上是/wp-admin/edit.php?post_type=block_area ）访问不同的阻止区域。 主题将照常控制内容的宽度，因此页眉/页脚可能会变宽，而侧边栏会变短。

我从这个模型中省略了文档大纲，因为我认为在全局块区域的上下文中它没有多大意义，并且也应该实现为插件侧边栏/模式（因此可以隐藏在“更多选项”中）菜单）。

我不确定两个样机中的“帮助”按钮会做什么。 我猜想会出现一个弹出模式，显示与当前“窗口小部件”页面中的“帮助”按钮相同的信息。

“帮助”按钮也可能属于底部的栏中（与“使用实时预览管理”按钮相同）...我不确定两者都属于哪个。

我看到一次只显示一个小部件区域的几个问题。

• 很难将事物从一个区域转移到另一个区域。
• 当您一次只能看到一个网站时，很难了解该网站上已有的内容。
• 看起来太像编辑页面（用户混乱）。

是否需要呈现内容？ 我认为拥有站点配置非常好，因为它当前位于小部件页面上。 我可以轻松查看所有小部件并重新排列它们。 我不必为它们的实际内容所困扰，而这些内容阻碍了配置视图。 如果我想查看它们的渲染方式，可以使用Custimzer，在我准备好更改之前不发布更改，并且每次只能将其限制在一个小部件区域，并且不能在区域之间移动小部件。

我看到一次只显示一个小部件区域的几个问题。

• 很难将事物从一个区域转移到另一个区域。
• 当您一次只能看到一个网站时，很难了解该网站上已有的内容。
• 看起来太像编辑页面（用户混乱）。

好点，@ joyously。 我认为短期内前进的最佳方法的确是在单个页面上编辑了所有块区域。

将来，我认为同样的事情仍然可能实现，但并非完全相同。 您应该能够通过页面模板编辑来编辑全部显示在同一页面模板上的多个块区域...这些块区域将是可重用的块，可以在此处进行编辑（如果需要，也可以在独立的编辑器实例中进行编辑） ，就像可重复使用的块已经起作用一样。 这将解决上述所有问题，同时还保留了古腾堡（Gutenberg）编辑器的所见即所得的优点。 此时，将不需要像当前的“小部件”页面那样的页面。 但是显然，我们离这一点还很遥远。

是否需要呈现内容？ 我认为拥有站点配置非常好，因为它当前位于小部件页面上。 我可以轻松查看所有小部件并重新排列它们。 我不必为它们的实际内容所困扰，而这些内容阻碍了配置视图。

古腾堡（Gutenberg）的设计原则之一是未选择的块显示的预览应该看起来像前端，并且应该对所选的块进行优化以进行编辑。 因此，理想情况下，内容不应阻塞配置。 不幸的是，现有小部件的等效块几乎是_not_要做的事情的完美示例。

与“段落”或“标题”块不同，您无需直接编辑“最新帖子”块之类的内容。 不幸的是，这导致检查器中抛出了大多数重要控件，这些控件是为辅助/高级选项设计的。 我认为像它会阻止应当修改选择时，或者选择了块时预览应该完全消失，以显示在内容预览上重叠的重要控制。 从技术上讲，没有什么可以阻止选定的，可编辑的块形式看起来与未选择的形式完全不同。

另外，为了使对块的重新排序更加容易，我认为应该将“块导航”菜单重新实现为插件侧边栏，并允许从其UI中对块进行拖放重新排序（甚至可能删除）。 参见＃11408。

也许这里的解决方案是从该屏幕上完全删除顶部栏？

我可以想象将来主要由编辑器本身管理小部件的未来。 通过保持顶部，我们都保持了编辑器的可识别性（您学习一个界面），并且这迫使我们从根本上查看任何可访问性问题并“全盘”修复，而不是逐个屏幕修复，碎片化接口体系结构。

非常感谢您添加该样机@ZebulanStanphill！ 绝对可以帮助我形象化。

我要指出的一件事是，我们在先前的用户测试（第23页）中发现，如果发布栏位于屏幕底部，那么人们不会注意到它。 即使被提醒，人们也忘记了它在那里。 有人认为它看起来像浏览器镶边。 我看到在移动网络上，这个问题日益严重，因为对接广告的底数很多。

我们在先前的用户测试中找到（第23页）

抱歉，不愿意争论，但这是一个事实，即用户测试不包括具有辅助功能需求的人员，例如键盘用户，屏幕阅读器用户和视野有限的用户。

几个月前已经讨论过古腾堡（Gutenberg）中“保存”按钮的位置，但尚未达成共识。 我意识到，_visually_一些用户更喜欢顶部的按钮。 但是，在线性化的导航体验中，当前按钮位置不理想，因为它迫使用户在整个界面中向后移动。

即使在古腾堡之前，这也是一个已知的问题，因为在定制程序中使用了相同的模式。

在逻辑流程中，在任何Web应用程序中，保存操作都在流程的末尾。 我并不是说底部的发布栏是一个解决方案，但这仍然是一个问题，需要为所有用户提供良好的解决方案。

通过保持顶部，我们都保持了编辑器的可识别性（您学习一个界面），并且这迫使我们从根本上查看任何可访问性问题并进行整体修复，而不是逐个屏幕地进行修复，碎片化接口体系结构。

@jasmussen这很公平，我同意对a11y采取整体方法。 我希望我们不会在此屏幕上花费太多时间，而这可能会在以后淘汰。 并且顶部栏周围的a11y肯定应该分配了一个问题。

我的确在原型中加入了顶部栏，但只是消除了许多可能无法在此屏幕上使用的功能。 您认为这是一个很好的解决方案，还是您觉得被淘汰的其他部分在这里有用吗？

我的确在原型中加入了顶部栏，但只是消除了许多可能无法在此屏幕上使用的功能。 您认为这是一个很好的解决方案，还是您觉得被淘汰的其他部分在这里有用吗？

可以肯定的是，我们应该绝对删除那里所有对于小部件屏幕没有意义的按钮。

@melchoyce
除了@afercia所说的以外，我想说的是Crazyhorse演示底部栏的部分问题是，它确实确实看起来像弹出窗口或浏览器镶边：

它使用的背景色与编辑器的其余部分冲突，甚至覆盖了左侧的导航。 两者都暗示它根本不是编辑器的一部分，因此不相关。 它肯定也很高。 与此相对应的是古腾堡（Gutenberg）当前的顶部栏，绝对感觉与编辑器的其余部分相连。

我看到在移动网络上，这个问题日益严重，因为对接广告的底数很多。

我真的认为这不是问题。 许多应用程序将控件放在屏幕底部的栏中，例如Spotify，Twitter和Instagram。 甚至Gutenberg Mobile也已经将其几个控件置于底部：

考虑到Crazyhorse Demo和Gutenberg之间的巨大差异，我想说两者几乎没有可比性。 但是，感谢您指出该老用户仍然在进行测试； 我以前不知道它的存在。

@mapk

...我同意对a11y采取整体方法。 我希望我们不会在此屏幕上花费太多时间，而这可能会在以后淘汰。

这是大问题。 我们无法将块放入现有的“小部件”页面设计中。 我们不应该仅为新的“块区域”页面进行单独的UI设计。 但是，由于帖子编辑器仍然存在一些重大缺陷，因此我们也不能仅重复使用它。 因此，最终，小部件页面大修被需要改进的帖子编辑器所阻止。

并且顶部栏周围的a11y肯定应该分配了一个问题。

我同意。

@jasmussen

可以肯定的是，我们应该绝对删除那里所有对于小部件屏幕没有意义的按钮。

对于一次显示多个块区域的页面，顶部栏中的大多数控件不再有意义。 仅“设置”侧边栏和“更多选项”菜单仍然有意义。 此外，Yoast SEO之类的插件在应用于具有多个块区域的屏幕时可能不再起作用，因此也许插件必须选择加入以支持“块区域”页面？

如果我们更新了块区域以支持草稿，计划的更新以及撤消/重做，则“撤消”，“重做”，“另存为草稿”和“更新”按钮可能会出现在每个块区域下方。 但是从长远来看，当页面模板出现时，“块区域”页面可能会完全不存在，因此我不确定是否值得实现这种额外功能。

另外，我认为应该以任何方式添加单独编辑块区域的功能，以允许使用备用方法来编辑块区域，如果需要，可以使用仅在单个块区域编辑器中有意义的插件（例如Yoast SEO） 。

这是大问题。 我们无法将块放入现有的“小部件”页面设计中。 我们不应该仅为新的“块区域”页面进行单独的UI设计。 但是，由于帖子编辑器仍然存在一些重大缺陷，因此我们也不能仅重复使用它。 因此，最终，小部件页面大修被需要改进的帖子编辑器所阻止。

我了解您的担忧，并同意这里的所有内容。 但是，随着我们进一步努力改善topbar和Inspector中的a11y，我相信我们仍然可以同时开发此注释中列出的原型：

https://github.com/WordPress/gutenberg/issues/13204#issuecomment -459175233

@youknowriad ，您认为我们可以围绕此展开开发工作吗？

尚未，此PR＃13088是这里的要求，着陆后我们将立即开始探索。

还想指出的是，已经创建了一个问题[＃13663]来处理此处讨论的所有问题。

我主要关心的是单个保存按钮和单个草稿/发布功能。 窗口小部件区域分布在站点上的许多不同页面上，并具有许多不同的关注点。 能够将更改单独部署到他们身上似乎更具逻辑性。

重新设计窗口小部件区域将是一个很好的时机，可以将它们适当隔离，以使用户可以分别安排对每个窗口小部件区域的更改。

我只是在支持论坛中回答一个问题，即在主题切换后（如何使用iPad）如何更好地将非活动窗口小部件移动到侧边栏，我意识到此窗口小部件页面具有可访问性模式的屏幕选项。 使用它，它一次只显示一个小部件，但提供了选择将其放入侧边栏的选择，类似于您在没有辅助功能模式的情况下单击新小部件时所获得的内容。
我想确保其他人意识到了这一点，因此在重新设计中不会丢失它。

如何在模态框（与古腾堡中使用的模态代码相同）中打开块设置？
它会使可访问性复杂化很多。

我个人认为，如果您尝试为小部件复制设计和纯Post编辑屏幕外观，您将犯下巨大错误。 将来您会为自己带来很多问题。

作为参考，我是否应该在第二阶段中将这个UI融入Frontenberg？ :)

是的， @tomjn ，这是UI： https :

没关系，只需确保管理页面本身良好且模块化即可，因此在前端运行不是梦a，那样您就可以随意做而不必重写每个版本

在此处添加注释，提出了追踪票，指出了当不同用户同时编辑小部件并提出锁定系统时的问题：
https://core.trac.wordpress.org/ticket/12722

确保新的窗口小部件屏幕支持锁定解决方案可能更可取。

在此处添加注释，提出了追踪票，指出了当不同用户同时编辑小部件并提出锁定系统时的问题：

值得一提的是，尽管以下内容是关于使用WebRTC进行协作编辑的，但仍有许多构想和设计已进入流程，其概念是相同的：将块锁定在用户可以对其进行编辑的位置。 因此，可能值得参考该UI以获得参考思想：
https://github.com/WordPress/gutenberg/issues/1930#issuecomment -333455412

我正在分享一个简单的注释，总结了要获取小部件区域的块编辑器的主要剩余任务的PR：

• 最高优先级PR：将小部件区域抽象为块的其余端点的实现。 https://github.com/WordPress/gutenberg/pull/15015
  -（进行中）近期审核的一些更新正在等待中，但PR仍可以从审核中受益。
• 优先级最高的第二个PR：将小部件端点连接到小部件屏幕中的块编辑器。
  https://github.com/WordPress/gutenberg/pull/15074
  -取决于https://github.com/WordPress/gutenberg/pull/15015。
  -（进行中）审核中。
• 渲染在网站前端引用post_id的小部件区域。
  -https://github.com/WordPress/gutenberg/pull/15074。
  -（进行中）审核中。

将三个相互引用的PR合并成一个链，可以使我们获得小部件屏幕的块编辑器的首尾演示。

在Parallel中，我们需要其他改进以使块按预期在小部件屏幕中工作。

从核心块中删除wordpress / editor的用法（小部件屏幕中不可用wordpress / editor）。

• https://github.com/WordPress/gutenberg/pull/15635
• https://github.com/WordPress/gutenberg/pull/15572
• https://github.com/WordPress/gutenberg/pull/15521

修复使屏幕无法按预期工作或使屏幕体验不佳的UI问题。

• https://github.com/WordPress/gutenberg/pull/15472
• https://github.com/WordPress/gutenberg/pull/15470

其他UI问题正在影响窗口小部件屏幕，对此尚未实现解决方案。 主要问题是：

• 块弹出窗口没有出现在正确的位置。
• 块检查器仍然不可用。
• 我们没有等效于全局插入器的东西，我们只能使用同级插入器和“ /”自动完成插入器插入块。 也许每个小部件区域都应该有一个全局插入器？

鉴于自上次小部件工作更新以来已过去了一段时间，我将共享一个包含自上次更新以来的开发情况的新项目。
将窗口小部件端点与窗口小部件屏幕连接的PR被合并，并且在网站的前窗口小部件区域中渲染块的PR也被合并。
屏幕仍然提供次佳的体验，并且正在进行许多改进。

合并的PR（与主屏幕工作有关）： https : //github.com/WordPress/gutenberg/pull/15074，https : //github.com / WordPress /古腾堡/拉/ 15651

提出了允许旧式窗口小部件块引用现有窗口小部件的PR，网址为

旧版小部件仍然无法在小部件屏幕上正常运行，因为我们需要确保可以在该屏幕上放置用户服务器端渲染组件https://github.com/WordPress/gutenberg/pull/15635 ，我们需要公关先前引用了https://github.com/WordPress/gutenberg/pull/15801。 两个PR都在等待审核/重新审核。

关于从核心模块中删除wordpress / editor用法的工作：
https://github.com/WordPress/gutenberg/pull/15572已合并。 https://github.com/WordPress/gutenberg/pull/15635正在等待重新审核，我将尽快更新https://github.com/WordPress/gutenberg/pull/15521以解决这些评论。

关于修复导致屏幕无法正常运行或使屏幕体验不佳的UI问题的工作： https :
https://github.com/WordPress/gutenberg/pull/15470正在讨论中，尚待决定。

我主要关心的是单个保存按钮和单个草稿/发布功能。

这绝对是一个越来越令人担忧的问题。 我将对此进行更多探讨，并研究将其按钮更改为特定于块区域（即将推出的样机）。 我认为没有必要移至实际的区块。

另一个更新。
短期项目委员会位于https://github.com/WordPress/gutenberg/projects/27。

我们合并了另外两个重要PR的https://github.com/WordPress/gutenberg/pull/15521 ， https://github.com/WordPress/gutenberg/pull/15396

需要审查的公关

下一个具有更高优先级的PR
https://github.com/WordPress/gutenberg/pull/15801 ，合并后将允许在窗口小部件屏幕中使用旧式窗口小部件。

https://github.com/WordPress/gutenberg/pull/15548实际上已经准备就绪，需要最终批准。

https://github.com/WordPress/gutenberg/pull/15948已更新，也需要最终批准。

在PHP代码中发现了一些问题/潜在的增强功能，并提交了两个PR。 还会有一些额外的关注：
https://github.com/WordPress/gutenberg/pull/15981
https://github.com/WordPress/gutenberg/pull/15983

@TimothyBJacobs的支柱对其中一个公关进行了初步审查。

待更新/讨论中

讨论了https://github.com/WordPress/gutenberg/pull/15635 ，看来我们已经找到了可能的解决方案。 我喜欢@gziolo提供的关于拥有

https://github.com/WordPress/gutenberg/pull/15470 @aduth提供了一个替代的想法，它公开了一个新组件，该组件不仅包括BlockEditorProvider，还包括一些来自块编辑器的构件，例如编写流程。 我想如果没有人关心这种方法，最好的途径就是实现该组件并更新https://github.com/WordPress/gutenberg/pull/15470以使用它。

其他更新

https://github.com/WordPress/gutenberg/pull/15988通过@aduth提出将解锁构件屏幕上酥料饼的位置问题，我会检讨它在接下来的几个小时。

这个问题一年没有活跃了。 小部件屏幕是否还有另一个概述问题？

我不这么认为，@ ellatrix。 如果您想关闭此窗口，我们的项目委员会也将列出一系列问题。

保留此旧问题很好，因为它也链接到项目委员会。 当某人有时间再次回到此问题时，也可以更新它。

好的，由于项目板上没有动静，并且在此问题上也没有动静，我将其从WP 5.5板上删除。

@ellatrix我不清楚此功能的状态。 还有计划将小工具侧边栏内容转换为使用古腾堡块吗？

这里提到的所有PR乔治都是： https :
已合并。

嗨，阿斯兰。 @jcklpe

该功能的状态是长时间没有人在wp-admin的Widgets屏幕上工作，因此将其从WP 5.5项目板上删除。 这并不意味着它不会继续工作，只是它不是5.5的优先事项。

我将结束这个大问题，因为今天它仅代表历史性文档。