这些概念在很大程度上受以下因素影响：

• 原子块
• WordPress.com
• 设计库

我认为为此交互标准化UX流将使Gutenberg和用户受益。

我们对此提供支持，但只有按帖子类型，并且模板会在加载时应用，其逻辑如下：

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

不过，我认为这没有太多价值，并且希望拥有您刚刚描述的内容。

我更喜欢叠加方法，因为它具有更多的屏幕空间来展示可用的图案。

此功能将平行于任何块区域工作。 可能有为帖子制作的图案，也有为模板或任何其他块区域制作的图案。 例如，模板模式可用于快速将单个帖子模板更改为带有侧栏的布局。

Gutenberg不应该定义默认主题，但是默认主题绝对应该随它们一起提供。

我最初的想法是，此添加的块模式不会替换页面上的任何内容，而只是将块追加到底部。 这样，可以在内容的构造/写入过程中随时添加块模式。 这与原子块的流程类似，但是我希望没有一个包含所有其他块的块。

是的，出于您所说的相同原因，我也更喜欢这种方式。

从该插件中可能还会学到一些有趣的东西。 https://wordpress.org/plugins/full-site-editing/ @obenland插件当前是否最新？

它缺少我们在过去几周中添加的块预览工作，但在其他方面却可以正常工作。

这是当前迭代的样子，使用blockPreview进行大型右侧模板预览：

@epiqueras写道：

我们对此提供支持，但只有按帖子类型，并且模板会在加载时应用，其逻辑如下：

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

不过，我认为这没有太多价值，并且希望拥有您刚刚描述的内容。

在任何人对使用此功能替换块模板有任何想法之前，我只想指出此功能非常重要。 它允许开发人员专门定义给定帖子类型的组成。 我们在@meredithcorp中广泛使用了此功能，其中许多内容类型都经过严格组织。

我认为此“阻止模式”功能是一个很棒的主意，但想确保将其视为“补充”，而不是对当前帖子类型阻止模板功能的完全替代。

下一步：

1. @melchoyce也传达她的探索
2. 分歧：探讨wpcom在做什么以及行业中的其他示例（例如Squarespace等）
3. 融合：将更强大的模式整合到一个统一的模型和UX流中。
4. Figma中的样机和原型。

去年，我探索了一些古腾堡页面布局的原型。 我的探索有两个方面：

• 扩展布局以在页面上工作，而不仅仅是CPT。
• 为主题作者创建一种“声明”多个模板的方法。
• 创建主题作者对这些模板进行分类的方法。
• 创建用于选择布局的UI。

桌面

查看原型

_注意：此原型是我尝试过的较早的一轮设计，其中一些元素已过时。

移动

查看原型

细目

布局选择器与Gutenberg中的所有其他内容一样，都是一个障碍。 它由几个元素组成：

• 块标题/描述。
• 用于对布局类型进行分类的选项卡（在块插入器之后设置样式）。
  
  
  
  • 这些是主题定义的。
  
  
  • 当您只有几个布局时（例如<5），这些选项卡不会出现。
  
  
  • 如果没有任何分类的布局，则不会显示选项卡。
  
  
• 可用页面布局的列表。
  
  
  
  • 布局图形应根据其中包含的块自动生成。
  
  
  • 图像是灰色框，文本是深灰色线，按钮是蓝色，等等。我们应该将所有内容抽象为简单的形状。
  
  
• 最后，布局本身。
  
  
  
  • 在这些模型中，您可以看到应用于Gutenberg的主题样式。 如果未声明主题样式，则块将退回到通用的古腾堡样式。
  
  
  • 您可能还会注意到页面上的全局元素-在这种情况下，是站点徽标，导航和页脚。 这些是为了演示而存在的，但是在此第一个版本的布局中不可编辑。 它们无法编辑，并以40％的不透明度显示。
  
  

更改布局

我研究了流程的外观：

查看原型

细目

所以等等，我可以有多个页面布局吗？
对！ 您可以根据需要将它们堆叠并组合在一起。

那不会变得荒谬吗？
是的，可以。 不过，在大多数情况下可能不会。 对覆盖或附加进行明确说明意味着人们不太可能丢失内容。 删除块很容易，因此，如果要追加块并希望摆脱较旧的块，只需单击一两下即可。

如果他们不打算覆盖自己的内容怎么办？
让我们请支持“撤消”。

特定于页面的元素（例如“功能图像”和“页面标题”）如何？
如果要添加布局，则应将任何特定于页面的元素转换为其最接近的通用等价物。 例如：

• 特色图片→图片
• 页面标题→页眉

重复的块怎么样？
如果重复了一个特定的块（例如“最新帖子”），我们应该允许这样做-人们可能希望显示其他类别的帖子块。

通用块可以复制到您的心脏。

将其他布局附加到布局后，我们将其称为什么？
我们应该称其为“自定义布局”，然后根据所做的更改重新渲染预览图像。

这些模拟已经有一年多了，所以它们中有很多过时的东西，但是我们也许可以重用一些概念。

很棒的讨论，谢谢您的开始。 我非常强烈地认为这可以使页面布局更简单，而且我迫不及待地等待着陆。

我也强烈认为我们不应在块库旁边添加其他按钮，因为：

• 它会将块库稀释并分段，作为在页面上插入任何内容的唯一位置
• 它添加了用于插入和学习的其他UI，以使其可在移动设备和台式机上访问和使用
• 它被添加到一个已经很拥挤的地方，可以说应该减少而不是添加到
• 它可以将“模式”与“块”分开，从而有效地创建了不同类型的内容（如果可以说可能是相同的）

_一旦学习了块UI，就学习了如何做_，这从一开始就是一个指导原则，尽管应该对其进行完善，但它的扩展性相对较好。 就在昨天，我们讨论了将_site本身_当作一个块（＃16998）会如何有益，因为它重新使用了现有UI。 如果不是将“块模式”视为新功能，而是将其视为“ _恰好是另一个预先设计好的并且内部包含子块的块”，突然这不是新功能，而是对现有功能的“改进”。就范围而言，这似乎既务实又明智。

对我而言，块库似乎是此接口的明显位置。 我们可以对其进行哪些更改，以更好地适应块模式？ 它已经包含了可重用的块，可以说是这些模式的先驱，而我们所做的任何改进也可能使它们受益。 有“块模式”选项卡吗？ 块库是否更宽-与块库和新的预览窗格一样宽？ 块模式是否需要单独的预览窗口，还是我们可以利用该预览窗格的额外空间？

另一个练习是反驳这个问题：今天存在的关于块库的什么说明我们需要一个用于块模式的新UI？

梅尔（Mel）非常优雅地谈到了另一个界面，就是进入占位符界面。 默认情况下，如果“网站”块允许您选择基本模板怎么办？

毫无疑问，以下内容不是一个经过深思熟虑的想法，而只是一个快速草图，显示了如果我们在块库中添加“类型选择器”下拉列表时的外观，可以让您一起搜索块和块模式：

对我而言，块库似乎是此接口的明显位置。 我们可以对其进行哪些更改，以更好地适应块模式？

感谢您潜水，@ jasmussen！ 弄清楚这个问题是关键。 最近，幸福工程师分享了一些用户甚至没有滚动块库来查找前端和中心之外的其他块的信息。 这是另一个问题，但是在向这个非常小的接口添加其他内容时要考虑一些问题。

当今存在的关于块库的内容说明我们需要一个新的UI用于块模式吗？

我要说的是，块库的大小使得在其中添加全页块模式变得困难。 现在，用户可以查看块图标和该块的小预览。 之所以有效，是因为它只是页面的一小部分。 当用户可以看到页面的_most_以及这些块如何一起存在时，块模式会更好地工作。 图书馆的规模使这一工作变得困难。

“站点阻止”的概念听起来很有趣。 许多块都具有占位符，因此Site块也可能也可以具有带有布局选项的占位符。 这个想法适用于新页面，但不适用于具有现有内容的页面。 但是无论如何，这里有一个快速的样机。

块占位符（供参考）：

Site Block占位符：

这真的与上面的@melchoyce的样机

好主意，谢谢。

最近，幸福工程师分享了一些用户甚至没有滚动块库来查找前端和中心之外的其他块的信息。

这是一个很好的见解，而且还有更多的理由来改进模块库以及我们为模块模式所做的任何改进设计。

我要说的是，块库的大小使在其中添加全页块模式变得困难

那是真的。 我花了一些时间尝试根据该反馈进行一些模拟，但是将其与单个块库的思想结合在一起。 不要在这个模型的高保真度上过分强调，部分是我的舒适区，部分是使它“真实”的一种方式。 因此，仅因为它看起来是_done_，并不意味着它不能基于进一步的反馈而被拒绝：

您在此处看到的是与您按下(+) Add Block按钮相同的单个块库。 每当您创建新段落或寻找同级插入器时，都可以在文档末尾的编辑器栏中使用它。

用户界面基于现有功能，但除了搜索字段外还添加了两个标签：

• “阻止”选项卡是默认选项卡，其内容就是我们今天所拥有的
• “块模式”选项卡位于其旁边，该视图没有单独的预览窗格，而是将渲染的预览显示为块模式缩略图本身。
  
  
  
  • 有一个_category dropdown_，这是插件将其产品分类的好方法。
  
  
  • 缩略图具有固定的宽度（2列），但是高度不同，以砖石结构形式出现。
  
  
  • 整个弹出窗口都变大了，通过不显示预览窗格，我们得到了更多的空间。 我们甚至可以探索响应技巧，根据可用的屏幕空间来确定下拉菜单的大小。
  
  
• 搜索时，将同时搜索块和块模式。
  
  
  
  • 屏蔽结果分别分组，并首先显示
  
  
  • 块模式结果显示在下面
  
  

同样，尽管这看起来很高逼真度，但不应将其视为福音。 旨在简化对话。 我受到@shaunandrews进行全站编辑工作的启发，我相信他也有想法要分享。

希望这可以帮助！ 有什么想法吗？

好吧，因此，基于以上探索，我看到我们将其分解为两个任务：

1. 创建新页面时预览并选择页面布局
2. 之后，通过插入器添加新的块模式

@jasmussen在https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480中有一些出色的插入器探索，我们可以对其进行迭代。

@shaunandrews还与我分享了他正在为WordPress.com工作的想法：

创建新页面时，系统会为您提供选择布局的选项。 预览是一个不错的补充， @ mapk和我都没有

我们应该仔细考虑一个问题：页面是否应该完整布局而不是帖子？

应该只为页面而非页面发布完整的页面布局吗？

一个方面是我们默认设置，另一方面是技术上的区别。 也就是说，从技术上讲，这很可能是琐碎的，因为它在引擎盖下是相同的，因此仅是决定我们允许的问题。 在任何地方都可以使用它的好处是，可预测的流程在任何地方都一样。 缺点是：我们可能不希望您创建使用Blog主页模板的新帖子。

模板在注册后，也许自己决定应允许使用哪种分类法？

模板在注册后，也许自己决定应允许使用哪种分类法？

好主意-然后模板也可以用于类别/标签和CPT。

（分类页面上的模板选择器可能很酷！）

切向相关的块模式 - 内容部分 - 朋友共享上的同级插入一些想法，在加上上块之间出现徘徊，并指出这是选择的块时，总是看见会比较有用。 现在不是这种情况的原因是，这与只想单击要编辑的文本以及与Spacer和Cover块上的调整大小控件冲突。 这里的关键是_everything是block_。

共享了GoDaddy网站构建器的几个屏幕快照，其中存在相似的界面，并且在选择后永久可见。 主要区别在于此UI区分小块（文本，图像）和较大部分，并仅在后者上显示此控件：

随着我们继续讨论块模式，思考一下这个概念是否会为更大的部分增加功能，从而为进一步简化基础UI开辟大门。

@jasmussen我可以为https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480抓取您的文件吗？

当然是。 我把它很快地整理成了一个杂乱的Figma文件，所以我在这里复制了它：

https://www.figma.com/file/VaSKQJDS70ov87XY1alOVs/Block-Library-w.-Block-Patterns?node-id=0%3A1

谢谢！

玩弄一些想法：

我从下拉菜单的想法开始，尝试了一个列表块：

与此同时，我尝试了两列和一列模式，使用缩略图作为列表中的模式：

然后，我认为搜索处于混乱状态，然后退后了一步。 我尝试在搜索和搜索下方的标签旁边添加一个下拉列表：

使用搜索下方的标签，我还尝试以横向和纵向显示图案的缩略图。

我喜欢@joen对更有趣的模式布局所做的工作，因此我还尝试了一个快速的模型：

伟大的探索。 我认为选项卡作为一种模式可以更好地工作，因为搜索旁边的下拉菜单使这两个选项看起来像是绑在一起的-例如，我只能在模式或模板中进行搜索，而不能通过选择一个来更改视图。

我非常喜欢阅读本期杂志，这些想法读起来很不错！

我想标记相关的问题＃15623和＃17512，它们分别致力于提供必要的块类型和基础结构，以启用完整的站点编辑。

尽管此处讨论的块模式在两种情况下都是有意义的（个人帖子还是整个模板），但我认为我们需要区分两种类型的模板：

• 模板部分（例如，内部使用wp_template_part帖子类型实现，类似于“完整站点编辑”插件的实现方式）：
  
  
  
  • 模板部分应该能够在各个地方使用，并且应该有可能将它们附加到其他内容上（如前所述）。
  
  
• 模板（例如，内部使用wp_template帖子类型实现的模板，请参见＃17513）：
  
  
  
  • 模板应该代表_entire_模板，包括构成HTML文档的所有语义标记。 对于这些内容的放置方式需要有一些限制，例如完整模板在单独的帖子内容中没有意义，并且也不应该将完整模板附加到其他位置-完整模板应始终覆盖现有内容及其主要用例将是在使用Gutenberg创建新模板的一开始（即“选择您的起点”）。
  
  
  • 尽管我们仍然需要弄清楚如何（通过上述问题）总体上鼓励（强制执行）可靠的语义标记，但我认为我们在这里也应该考虑这种情况。
  
  

到目前为止，这个问题似乎主要集中在模板部分上，这是有道理的，但是如果我们也可以考虑将来如何将其扩展到完整模板，那就太好了。

到目前为止，这个问题似乎主要集中在模板部分上，这是有道理的，但是如果我们也可以考虑将来如何将其扩展到完整模板，那就太好了。

需要澄清的一点是，“块模式”设置与模板部分（在结构上有意义）有关的内容较少，而与由较小块组成的常规设计元素有关。 插入后，它们不会单独存储。 例如，“封面”图像结合了几个块以实现特定外观，否则将使用户花费一些工作来完成。 可以将其更多地看作是可以在任何地方添加而不必代表主题模板的可重用部分的设计集合。

快速而又肮脏的探索，接受@shaunandrews和@jasmussen的想法，并将它们应用于模式而不是弹出窗口：

我挖掘了选项卡和搜索布局，尽管我必须承认我个人总是使用块库中的搜索，所以作为一个数据点，我宁愿先搜索。

模态对话框插入器肯定会带来空间。 那很好。 但是，这也失去了光标所在位置/将插入块或块模式的位置的视觉上下文。 另外，它提出了一个问题，即这是否会成为块插入器的全局行为，或者例如只是使用兄弟插入器或上面建议的“节插入器”之类的变体时所看到的结果。 如果我们将行为分解，那好吗？

您在@melchoyce的探索确实

在一种情况下，模态传达了许多可用的块，这是人们现在正在努力探索的事情。 但是，另一方面，看到所有这些块变得有点不知所措。 模态感觉适合于模式，但不适用于单个块。 但是样机还显示了手风琴打开，因此，如果像我们默认情况下那样仅显示一个打开，则它可能会完全改变。

尽管我喜欢对话框版本所增加的空间，但是在它上面睡觉，这感觉不适合我。 它会从内容中删除所有上下文，并且在您插入诸如段落或图像之类的简单块时会感到不知所措。 对于预制块或块模式，我越来越有相同的感觉-它们只是块的集合，应该以相同的方式插入。

尽管https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480不一定是要走的路-类别开始变得毫无意义，而且还有很多事情要做-我确实认为_improving the block可以容纳复杂块的库_（并避免出现模态对话框）。

我确实认为，改进块库以适应复杂的块（并避免出现模态对话框）是可行的方法。

现在我们有了帮助面板，它在库中提供了更多的空间，我们可能可以使用它。 也许图案是与各个块分开的另一个选项卡，但是预览区域仍保留在“帮助”面板侧，必要时可以垂直滚动。

我喜欢“块模式”的想法（也许应该将其更改为“块布局？”），但我不喜欢使用对话框添加新块-太让人分心了！ （如果以这种方式添加块模式，我会满意的。）

我建议块插入器应保持较小的弹出框（如今天所坐），而块模式应完全是不同的组件-因为使用每种模式的上下文都可能非常不同：一个用于构建页面（模式） -另一个用于添加块/调整那些页面。

它可以在插入器中工作，但是我们可能会发现接口变得更加复杂和混乱-更不用说插入器了。 引入模式的微小预览可能不是最好的体验。 我们需要能够显示多个模式（以提供适当的上下文供用户选择），而且还需要使预览足够大以实际查看。

也许我们稍微调整一下工作方式。

只是在这里大声思考，但是如果我们今天有左上方的插入器，又在现有块之间引入新的UX模式，那人们会在其中添加块模式/布局（我们称之为它们）。 这将替换当前驻留在块之间的悬停块插入器（+），并保持可见（未悬停时不隐藏）。

这是一个屏幕截图（带有实际的古腾堡内容_），看起来像这样：

在这将要接管的确切位置背后需要进行一些思考。 会在每个街区之间吗？ 我不确定。

打开模式插入器将触发一个模式，用户可以从中选择一个新模式添加到他们的页面。 这是对模态的探索，使用了顶级分类选择，尽管在这里我不是100％会是什么样子。

这种模式（至少是部分模式）可以在GoDaddy的网站+营销产品以及SquareSpace（以及其他地方）上看到。 值得探索。

块和布局应不同。

布局应利用其使用的CSS框架。

布局示例：

• 列/行
• 格
• 滑块
• 一个容器
• 五线谱，手风琴

块是否可以存在于布局中。

模式可能是布局+块？

这是Blocs应用程序执行此操作的方式。 它使用更大的插入器。 只是分享更多的研究。

更多地看别人在做什么。

Qubely使用“顶部工具栏”中的按钮打开模态。

马克，马克。

我会注意到Qubely方法是我应该避免的一种方法，并且它是许多其他block集合采用的方法。 该方法假定用户位于桌面屏幕上，并且未使用“顶部工具栏”选项，甚至未使用将来的“显示所有图标的标签”选项。 因此，如果要添加一个实际的单独按钮，则可能要在块插入器的直接上下文中添加它，并且我们可能应该研究如何减少该空间中存在的其他按钮。

这是SquareSpace的快照，它为页面架构和内容编辑提供我先前的评论提供了上下文。

这是我们在昨天的设计会议上讨论的持续对话（松弛） ：

我一直在思考模式交互与块交互。 移动模式是顶层“构建”交互，而块则是“添加/调整”交互。 当然，显然可以使用块构建“模式”，但这并不完全简单，需要更多的交互才能完成。 那么，如果页面架构和内容架构之间有明显的区别怎么办？

感谢您的分享，Rich。 似乎可以在两者之间取得平衡，这使用户可以轻松插入大量有用的内容部分，以在需要时快速构建页面，而在需要时可以轻松直观地访问各个块。

对我而言，Squarespace GIF的关键之处在于，尽管存在两个库之间的对偶性，但它受到_contextuality_的限制。 我不知道我们是否可以做得更好，以避免两个看起来完全不同的块库。 例如，当您插入_Navigation Menu_块时，直观的感觉是该块库成为仅在其中插入_Menu Items_的工具。 我们是否有类似的方式可以在编辑画布本身中利用上下文？

至于如何添加布局，也许在“文档”选项卡的“设置”区域中，可能会有一个布局列表，其中有一个图形向用户显示该布局的大致外观？

我们已经有一段时间在Atomic Blocks中有一个截面和布局模态了，我很乐意分享到目前为止我们所经历的。

要详细说明@mapk的问题：

1. 是的，块编辑器应具有专用的UI，用于处理块图案/节/布局或任何您想调用的样式。 各个块之后的下一个逻辑步骤是我们如何将它们组合起来以创建现代的，富有表现力的布局。 为此创建一个标准化的UI将使用户和开发人员享受凝聚力的体验，并避免重新发明轮子一百万次（已经开始）。 即使Atomic Blocks和其他几个模块已经具有专用的UI，我仍然更愿意为此使用标准（但可扩展）的UI。

核心是否提供块模式来填充此UI是另一个问题。 核心主题提供有目的的块模式以补充和扩展其设计也许是有道理的。

1. 这里提议的几个UI是一个很好的开始。 我特别喜欢从@shaunandrews和@melchoyce在这里看到的内容。 我同意@richtabor的观点，即块插入器对于这样的功能过于局限，我认为我们会很快淘汰它。 具有块模式的富有表现力的页面构建应拥有700px x 430px以上的界面。

我们在用户界面中区分了部分和布局之间的区别，其中部分是页面的一部分，而布局是完整的页面布局。 这是一个自以为是的决定，在我们当前的实现中很有意义，但是也可以使用类别或过滤接口来解决。

原子块还具有收藏夹功能，可让用户轻松收藏并重新访问其经常使用的部分和布局。 随着图案数量的快速增长，这种功能将是必需的。 授权用户的另一种方法是允许将白名单和黑名单模式控制在模式UI中的输出。

块编辑器的功能将最为明显，并在诸如块模板和块模式之类的功能中得到了验证，这些功能从根本上改变了我们在WordPress中构建网站的方式。 我们还有机会对自定义WordPress界面的狂野西部进行调查，并开始提供标准化方面更具凝聚力和可预测性的体验。

我今天要分享一些模型，以尝试解决过去的想法。 要详细说明这一挑战：用户可能不在乎块，图案或布局之间的区别，并且由于两者都可以插入任何位置，因此为每个对象创建不同的接口可能会造成混淆。

在下面的模型中，我尝试通过以下方式解决该问题：

• 选项卡式创建单个统一库界面
• 从编辑器栏打开该界面时，将其显示为全高而非模式的弹出窗口
• 从同级插入器打开时，将其显示为对话框，默认为“模式”选项卡

_请注意，此用户界面利用了＃18667中探讨的未完成的用户界面概念。_

在这种配置中，用户可以插入块或图案，而不必浏览不同的界面，但是我们承认，在插入较大的图案时，您可能需要更多的屏幕空间。

该界面还利用了此处建议的新类别词组。

• 从同级插入器打开时，将其显示为对话框，默认为“模式”选项卡

我认为我们正在这里做某事！

@jasmussen ，模式也会显示在/还是只是块？

这是一个很好的问题。 也许如果单独分类。 但是，也许大预览对于模式更必要吗？ “找到2个模式”可以调用该对话框吗？

@jasmussen ，模式也会显示在/还是只是块？

也许。 尽管没有预览，但我不确定将它们包含在/中将有多大用处-除非它们具有非常独特的名称（我怀疑情况会如此，例如“大约1”，“大约2”）或者用户是否可以根据自己的喜好为其添加标题（也不是100％对此表示肯定）。

如果我们实现了“收藏夹”功能（如@mikemcalister在此线程前面提到的那样），则也许只会显示喜欢的模式（只要可以清楚地识别出它们）。 如果我们允许它们，模式是否需要一个相应的图标（类似于块）？ 还是会有默认的“模式”图标对块模式进行分类？

大家好，我只是想跳进我的脑袋，说我爱这个地方。 最新的模型和思路非常棒。 当我正在考虑如何将其转换为本地移动式古腾堡时，我认为@lumberman的最后一个模型很好地组织了并且应该具有很好的可扩展性，但是我对层次结构和交互性有一个担忧。 如果我没有完整的历史背景，请原谅我，但我认为在这种情况下，移动角度将很有用。

关于手风琴/ Nav层次结构

我一直遇到的插入器问题之一是手风琴部分（最常用的部分，常见的块等）。 第一部分“最常用”足够清晰，因为它一开始总是打开的，但是它往往掩盖了其他部分并阻碍了可发现性，尤其是在移动设备上。

我喜欢最后一个模型@lumberman中左侧边栏的布局方式。 您是否认为将这些部分添加为左侧导航栏中的列表项是否有意义？ 换句话说， Sections下的项目将是“最常用”，“标题”，“页脚”等（或最终以组命名的形式）？ 这可能解决了“埋葬部分”的问题，并可能使我们从本质上消除了对手风琴的需要，但是我知道这与历史上的块库有很大的不同，因此其他人可能不喜欢此建议。

关于“收藏夹”

所讨论的概念之一（最初我相信是@mikemcalister ）是“收藏夹”的概念。 这几乎就像我在本地移动GB上探索过的想法一样，您可以在加入GB的过程中选择喜欢的块来创建块的“我的库”，然后从那里着手这些主要是在仍然提供通往完整块库的明显路径的同时。 这样做的主要问题是可发现性，尽管我认为有解决方法。

在Block Library，Overwhelm，IA等上

总的来说，关于插入器，有一件事我会回头，随着我们变得更加强大，它变得更加清晰。 在移动Web可用性测试期间，我们（Automattic的移动团队）经常听到块库不堪重负。 有很多选择，并且分组还不清楚。 我认为这里提出的新UI想法会有所帮助，因为它们可以“呼吸”更多，但是块的数量仍然是压倒性的，并且只会随着引入另一个分组（块模式）而变得更糟。 我认为随着我们的扩大（我认为这是正确的方向，“喜欢的”类型能力可能会减轻这种情况。

值得一看的是Mobirise的页面布局方法。 它们在左侧提供了一个画布，在右侧提供了一个垂直面板选择滑块，该滑块被划分为自然的垂直页面元素...顶部栏，顶部菜单，然后是业务功能的主体面板的一些面板选择（取决于主题和页面类型（例如，地图面板，如果是“关于我们”页面，则为人形面板），然后是页脚，然后是页脚栏，您只需将面板从右向左拖放。

警告：如果您是古腾堡（Gutenberg）的撰稿人，请先阅读

您声明并保证不会：复制，修改，创建衍生作品，改编，逆向工程，模拟，迁移到另一个服务，翻译，编译，反编译或反汇编服务；

更好的是...根本不去他们的网站。

相反，您可以考虑只查看Mobirise YouTube视频。 我不知道有什么术语可以超出YouTube对内容上传者的许可范围，但请注意，Empeater Emptor ...我不是律师。

如果您认为观看YouTube视频对Gutenberg IP无风险，那么Mobirise Youtube频道位于https://www.youtube.com/channel/UCt_tncVAetpK5JeM8L-8jyw/featured。 您可以通过拖放面板来查看特定主题的页面构建。

@jasmussen ，您的模型在这里看起来很棒。 😍如果可能的话，我希望能在一个可行的原型中看到它们，也许可以回答我下面的一些问题。

如@richtabor所示，更改某人从工具栏添加一个块时的上下文而不是从同级插入器添加一个模式是有意义的。 我喜欢为模式提供模态的额外空间！

下一步

1. “预制块”一词有点尴尬。 我们可以在那里尝试“块模式”，还是同样尴尬？
2. 单击顶部工具栏中的插入器，然后单击“阻止模式”选项卡时，会是什么样？ 弹出窗口会转换为模式窗口吗？ 弹出框是否会更改大小，但仍将弹出框保持在相同位置？ 它是否保持相同的大小和位置，现在仅显示图案？
3. 单击编辑器中的同级插入器，然后单击“块”选项卡时，交互的效果如何？ 大小或位置的模态变化是否从这里开始还是保持模态？
   
   
   
   1. 创建一个回答这些问题的原型。 如果您可以将文件链接到我，我很乐意为您提供帮助。
   
   

@lumberman也感谢您的模型！ 我真的很喜欢他们如何利用现有的插入程序设计，并在此之上进行构建。 👍有没有办法减少手风琴的数量？ 感觉很多东西都可以滑开。 目前，可用性测试表明，人们并没有点击我们已经拥有的手风琴。

“预制块”一词有点尴尬。 我们可以在那里尝试“块模式”，还是同样尴尬？

是的，我们绝对可以尝试使用块模式。

我个人认为该术语比较尴尬，但是我也知道在设计聊天室和其他地方已经讨论过该术语，并且在插件中进行尝试的成本很小，因此没有理由不这样做！ 它可能感觉很完美，或者可能需要进行调整才能显示出来，我们将进行重新讨论。

单击顶部工具栏中的插入器，然后单击“阻止模式”选项卡时，会是什么样？ 弹出窗口会转换为模式窗口吗？ 弹出框是否会更改大小，但仍将弹出框保持在相同位置？ 它是否保持相同的大小和位置，现在仅显示图案？

不会发生任何变化。 它将与大模态相同，但空间更小/更紧凑。 也许那里只有一排块模式的空间。

但是我仍然认为值得，因为在两个位置都具有相同的UI以及块和模式。

单击编辑器中的同级插入器，然后单击“块”选项卡时，交互的效果如何？ 大小或位置的模态变化是否从这里开始还是保持模态？

PR /原型可能会回答一个好问题。 我想象零变化，就是有更多的空间来查看区块，有些人可能会更喜欢！

创建一个回答这些问题的原型。 如果您可以将文件链接到我，我很乐意为您提供帮助。

这是Figma文件： https : = 85%3A6975-有点混乱，但是如果您需要帮助，可以查我。

以下是基于大家共享的优秀创意的一些探索。 我故意限制自己在当前块插入器提供的空间内工作。 我这样做有两个原因：

1. 这将使我们更轻松地将此UI转换为小屏幕。
2. 对于平均屏幕尺寸，我觉得当前的插入器已经占用了足够的屏幕空间。 因此，我相信更大，居中的模式不会带来太多好处。

**以上是1200 x 800的屏幕截图。

鉴于我受到了块插入器的大小限制，我试图探索如何充分利用可用空间。 虽然“帮助”面板对于块来说可以正常工作，但是当我们尝试为块模式显示更大的缩略图时，它确实会妨碍您的工作。 因此，我尝试将其删除，而没有摆脱其内容。 这不仅为块模式提供了更多空间，而且为块提供了更多空间。 我也非常喜欢预览缩略图如何在此处共享的某些模型中查找块模式，并且由于我们已经在“帮助”面板上进行了块预览，所以尽管不尝试一下。

看起来像这样：

当您聚焦/悬停一个块时，底部“带”的提示内容将相应更改：

基本上，我只是在四处移动：

区块预览实际上并不会占用比当前按钮更多的空间，我们现在每行可以显示3个以上的空间。

我也尝试显示较小的缩略图，但我觉得预览更难阅读：

通过以上所有步骤，“块模式”选项卡可能看起来像这样：

我们可以对块和块模式都有一个熟悉的UI，以充分利用插入器中的可用空间。

感谢您对此Enrique的研究！

我故意限制自己在当前块插入器提供的空间内工作。 我这样做有两个原因：

• 这将使我们更轻松地将此UI转换为小屏幕。
• 对于平均屏幕尺寸，我觉得当前的插入器已经占用了足够的屏幕空间。 因此，我相信更大，居中的模式不会带来太多好处。

我不同意这一点。 我们有很好的方法将模式转换为电话（全屏），并且可以显示一列模式，而不是两列和三列。

我说这是在探索与您自己的设计

我意识到，如果我们要显示巨大的甜美的块状图案，我们需要我们能获得的所有空间。 这是将Mark和Rich概述的点连接起来的问题，从而产生了这些模型（ Figma文件）。

我在一块占用所有可用垂直空间的块库中刺了一下，删除了帮助文本，并分离了＃19836中的预览窗口。 它可以作为整体构想的原型。

恩里克（Enrique），我很乐意与您合作，将您的一些技巧带到前面显示的高大的垂直模型中。 这是Figma文件： https : = 85%3A6975-显然，它在桌面断点上运行良好，但移动断点尚未充实。 如果有帮助的话，我也会随时聊天。

嘿@jasmussen！ 👋

这是将您的高大垂直模型与一些块模式预览结合在一起的快速模型：

我喜欢。 在这种尺寸下，大型预览版感觉不错。 我遇到的一个问题是，当预览如此大时，我不确定手风琴类别是否能很好地用于导航和可发现性。

我花了一些时间探讨将类别放在侧面的想法：

我认为这样可以更轻松地扫描可用的类别，但是可以将“块模式”的类别向下推，我不确定我是否认为这是正确的。

让我知道你的想法。

这是将您的高大垂直模型与一些块模式预览结合在一起的快速模型：

这是恒星！ 值得注意的是，在垂直界面中看到模式非常有启发性，并且比我想象的要好一些。

侧面的类别也不错，尽管我想知道在左上方的弹出框版本中是否可以将它们更好地用作下拉菜单，但是它们在同级插入器打开的对话框版本中是否可以很好地工作？

这次真是万分感谢！ 我也会让其他人鸣叫。

以下是对最近的模型进行迭代的更多探索：

1.块选项卡和块模式+类别列表

2.块和块模式的选项卡+类别的下拉菜单

我认为1感觉不错。 我喜欢类别列表如何完全可见（更好的可发现性），并且我认为这应该很好地扩展。

虽然2听起来比较整洁，但我担心类别列表隐藏在单击后，从而影响了可发现性。

@jasmussen @mapk @shaunandrews你怎么看？

我认为1感觉不错。 我喜欢类别列表如何完全可见（更好的可发现性），并且我认为这应该很好地扩展。

虽然2听起来比较整洁，但我担心类别列表隐藏在单击后，从而影响了可发现性。

看起来不错@enriquesanchez！ 排名第一的感觉也不错。

一些想法：

一种。 我们需要找出一种机制，如果碰巧有一个很长的类别列表，该怎么办。

b。 类别应如何排序？ 是否有优先主题，然后是插件？ 按字母顺序？ 还是组合？

C。 如果主题注册了用于不同类别的模式，那么这些模式是否会出现在“来自主题”类别以及每个模式的指定类别中？

回应里奇的评论和问题，精彩的摘要。 干得好！

要考虑的一件事是，根据当前的论文，从同级插入器打开时，库显示为一个大对话框，而从左上方打开时，库则显示为较小的对话框。 我们_可以默认为旁边的类别，并在响应性挑战要求时将其折叠为下拉列表。

b。 类别应如何排序？ 是否有优先主题，然后是插件？ 按字母顺序？ 还是组合？

可能最终是顶部几个“祝福”的组合，然后按字母顺序排列。 直到插件将其类别命名__Sweet Blocks或1. Sweet Blocks为止。 看来我们现在可能会冒险考虑其中的一件事，并且由于很容易进行调整，我们不妨采用最简单的解决方案，并在必要时进行调整。

@richtabor @jasmussen感谢您的出色反馈。

一种。 我们需要找出一种机制，如果碰巧有一个很长的类别列表，该怎么办。

同意对于块库是否需要类似的东西以及我们是否可以从中学习，我并不陌生。

b。 类别应如何排序？ 是否有优先主题，然后是插件？ 按字母顺序？ 还是组合？

我赞同乔恩的建议。 需要建立一些初始顺序，并在系统崩溃时/在迭代时进行查看。

C。 如果主题注册了用于不同类别的模式，那么这些模式是否会出现在“来自主题”类别以及每个模式的指定类别中？

我最初的反应是。 我希望某些模式会出现在不同的类别下。 我认为可以。 拥有“来自主题”类别的想法绝不是最终的决定，但我认为这将是帮助人们使其网站“看起来像演示”的简便方法。

我将继续对此进行迭代。 我将研究一些原型，以更好地了解库的外观和感觉。

我发现移动方法在该领域很实用。 它们具有两个块面板选择列...一个将块面板缩略图归到常见页面类别（页眉，菜单，内容，页脚等）下，并带有相邻的类别索引，因此您可以查看所有类别并直接跳转到兴趣类别。

不将其作为“ THE”解决方案。 我只是认为您可能会觉得它很有用，然后将您喜欢/不喜欢的内容转换为所需的设计。

只是一个建议:-)

感谢您再试一次，@ enriquesanchez！

我也赞成第一名。 显示列表可以防止用户不得不跳过一系列单击来获得所需的结果。 如Joen建议的那样，让它崩溃以响应屏幕听起来很有趣。

我不知道Gutenberg中目前有什么机制可以处理长列表，因此需要深思熟虑。 通过使用选项卡将块与模式分开已经有所帮助。 在那一个荣誉！

“来自主题”感觉有些奇怪。 也许是“主题模式”，或者只是“主题”，甚至是“主题：[主题名称]”。 也许这些应该放在顶部？ 我可以将它们放在“主题”类别下并在相关类别下进行展示。 也许这有点像“收藏”？ https://github.com/WordPress/gutenberg/issues/19873

我在样机中注意到，即使突出显示了“模式”选项卡，搜索字段仍显示您可以搜索块和模式。 这是正确的吗？ 还是应该在“模式”选项卡下仅限于阻止模式？

这是Obenland分享的线框的混合：
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -536109796

和恩里克的第一线框建议：
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -582673937

这是现有的“区块”区域以及其他选项：

选择“块变体”选项卡时，它可以更改为以下内容：

编辑：使用现有接口，但将其扩展为其他选项，将使我们今天选择块的方式保持一致。 人们仍然会去同一个插入器区域来选择块。 但是这一次，您还可以从块（单个块）->块变体（多个块）->页面布局（模板）->站点部分（页眉，页脚等）中进行选择。

要考虑的一件事是搜索框的位置及其含义。 使用最新的设计@enriquesanchez ，将对每个顶部选项卡（块和样式）重复搜索框，这使我认为我一次只能搜索一组。 我最初的希望是，我们可以有一个输入，以允许跨两个块_和_模式进行搜索。

也许这是一个误导的希望，或者我不了解搜索输入的工作方式。

我在样机中注意到，即使突出显示了“模式”选项卡，搜索字段仍显示您可以搜索块和模式。 这是正确的吗？ 还是应该在“模式”选项卡下仅限于阻止模式？

使用最新的设计@enriquesanchez ，将对每个顶部选项卡（块和样式）重复搜索框，这使我认为我一次只能搜索一组。

@mapk @shaunandrews感谢您的反馈！ 不知道为什么，但是在我移动搜索框的过程中的某个地方，因为我最初将其放在选项卡顶部（请参阅https://github.com/WordPress/gutenberg/issues/17335#issuecomment-575835877）。

我同意@shaunandrews ，我认为搜索输入应该是插入程序中的第一个元素（目前如此）。 打开插件后，这是第一件事，它高效且具有全局性。

我认为搜索输入应该是插入程序中的第一个元素（目前如此）。 打开插件后，这是第一件事，它高效且具有全局性。

您还能探索一下它的外观吗？ 当搜索查询以块和模式返回结果时，它们看起来如何？

我花了一些时间来研究如果我们为块库提供更大的模态，将如何显示块，因为对此问题已经进行了探讨。

我一直倾向于在类别的左侧列出清单，就像之前的注释中的第一个示例一样。

那么，如果我们遵循相同的模式而不是块呢？ 这意味着我们将不再像现在那样使用手风琴。 这也意味着对于大多数类别，将有很多未使用的空间：

显然，这是不理想的。

另一个迭代使我想到了一个连续的所有块类别列表的想法，并在左侧列表上具有链接以将您滚动到相应的位置。 像这样：

我想如果我继续滚动并开始滚动（而不是单击链接之一），左侧列表中的活动状态将相应地更新以传达位置。

该解决方案可以更好地利用空间，我们保留了一些我喜欢的东西：

1. 所有类别的列表始终可见，这意味着可发现性和勘探优势。
2. 我们不再需要单击以打开类别手风琴，并且由于所有块的列表现在都可以滚动，因此导航变得更加容易。

你们怎么想？

@enriquesanchez我喜欢这个探索。

1. 我们会在这种情况下摆脱预览吗？ （我不一定反对，只是好奇）
2. 如果类别太长会怎样？ （例如：https：//d.pr/i/DSsHTW）。 它会换行吗？ 在那种情况下，我只是要确保类别之间有更多的空间，这样就不会造成混淆。
3. 我喜欢连续滚动而不是手风琴。

看起来不错。 问题。 我们是否需要在“块模式”中阐明“块”？

感谢您的反馈@jwold和@ richtabor👍

我们会在这种情况下摆脱预览吗？

我倾向于这样做，但仅限于块状。 预览对于模式似乎非常有用。 我也喜欢两者之间的视觉区别：块=小图标，图案=大缩略图

如果类别太长会怎样？

我同意，他们会包装成这样：

我喜欢连续滚动而不是手风琴。

🙌

问题。 我们是否需要在“块模式”中阐明“块”？

@richtabor这是一个好问题。 所以您建议我们使用“块”和“模式”？

顺便说一句，我认为模式已重命名为“变体”。

顺便说一句，我认为模式已重命名为“变体”。

差异与模式无关-它是构建块的技术部分，因此在UI中并未公开。

从同级插入器（在文档中间的某个地方）调用时，我探索了块库的不同变体。

1.弹出框

这与我们目前拥有的非常相似，只是稍大一点：

2.大模态

应该使导航模式更加容易。 我不确定我是否喜欢它涵盖了其背后的内容。

3.滑入式面板

由@mapk建议。 在大小和位置方面与https://github.com/WordPress/gutenberg/issues/17335#issuecomment -585425675非常相似。 让我想知道滑入式是否可以作为顶部工具栏和同级插入器的默认模式🤔

这是一个简单的点击式Figma原型，将它们整合在一起。

尝试从顶部工具栏打开块库，在块和块模式选项卡之间切换，然后搜索。 最后，尝试从文档插入器的同级或中间打开块库。

❗️_注意：原型中尚无法插入块和模式。

嘿恩里克@enriquesanchez

拥有一个简单的Figma原型确实有很大的不同。 因为它确实给人一种成品版的感觉。

“块”屏幕确实可以更好地概述当今的状况。 无需打开手风琴就可以看到可用的块，而不必查看它们包含哪些块。 还有更多可用空间。

周六早上的身心训练... :)
头脑/眼睛四处走动，注意包含对称和平衡的“最常用”和“常用”块区域。

当眼睛向左移动时，会看到一个列表从下到下开始，以“最常用”开始，以“嵌入”结束。

最常用的是蓝色。 在它上面的另一种蓝色是在Blocks粗体文本下方的一行（请注意，蓝线与Blocks词相距甚远，看起来似乎是分开的。为什么我会看到蓝线。逻辑上我知道为什么。）。 在右侧，“块模式”不以粗体显示，其下无行。 以下是最常用的粗体文本。 在我的脑海上方，可以看到一个框的边框轮廓以及其中的“搜索”文本，并且可以再次放松。

这意味着要查看每个小元素，以及它们与附近的事物及其所在区域之间的关系。

你好

块模式的基于文本的呈现必须有空间。
并非所有用户都会得到预览图像的帮助。

感谢您的反馈@paaljoachim和@carolinan！ 🙏

块模式的基于文本的呈现必须有空间。

我同意你的看法。 我将为原型添加更多保真度，包括悬停时的块/模式描述，我们需要确保将这些描述传达给AT。

2.大模态

应该使导航模式更加容易。 我不确定我是否喜欢它涵盖了其背后的内容。

对于兄弟姐妹插入器来说，这是最自然的选择，尽管高保真模型可以帮助我们做出更好的决定。 也许进行核心模态黑暗背景将有助于将注意力集中到模态（如下图所示）。

为用户提供足够的查看空间，以正确识别出各个样式-使他们对要添加到页面的内容有更清晰的了解。 我们甚至可以将模式保留为两列宽-确保可以正确看到它们。

3.滑入式面板

由@mapk建议。 在大小和位置上与＃17335（评论）非常相似。 让我想知道滑入式是否可以作为顶部工具栏和同级插入器的默认模式🤔

这很有趣，尽管我觉得它会与兄弟插入器断开连接。 而且，如果无论如何我们要阻止其背后的内容/站点的视图，我想说的是，使用完整模式可以更好地利用空间。 在这一点上，我们的注意力应该放在图案/插入物上。

另外，这些不是屏幕截图-而是“示例”，就像样式变体如何支持示例一样-对吗？

示例示例：

@richtabor这是一个好问题。 所以您建议我们使用“块”和“模式”？

我会这样说。

我开始将其分解为小迭代，并在问题描述中添加了待办事项列表。 这不是一个详尽的清单，随着我们逐步实施，我们很可能会发现一些问题。 其中某些项目可能不会作为此问题的一部分实施。

对于它的价值，编辑原始注释以简洁地定义将非常有帮助
块模式到底是什么

这将有助于加快潜在贡献者的入职过程；
并提醒希望在该领域重新学习的核心成员； 并确保所有贡献者都在同一页面上（双关语意）。

现有核心成员之间存在一些关于模板使用术语冲突的

通过阅读前几条评论，我不确定“块模式”与内部模板有何不同（内部模板可以在多种帖子类型中重复使用，不需要绑定到页面的特定部分）。

从我聚集的块模式布局的一系列块; 但用户尚未定义块内的内容，并且内容相同
他们是否打算替换template.php文件？
（很复杂，WordPress中的模板可以代表几乎所有页面，或者可以将其抽象为3-4个其他模板文件（内部模板）的一致性。

块模式是否可以解决以下用例：“我需要一个包含多个块的标注块：标题（我可以根据语义自定义其标题级别）
一个段落块，以及一个注册事件的链接“）？

模式预览

前几天我看到了。 这是预览如何跟随光标的垂直位置的一个示例。 如果我们采用独立预览的方式，则可能值得探索。

预览如何跟随光标的垂直位置的示例。 如果我们采用独立预览的方式，则可能值得探索。

我实际上认为，将预览固定在固定位置可能会更容易_scrub_列表中的项目-您可以将视线停留在相同的空间。

就一个问题。 块模式是否可以定义锁定区域，因此用户无法更改块模式的基本结构？ 例如，我们是否能够锁定附加块模式中的特征区域数，从而不能添加或删除它们？ 您在考虑这个用例吗？

嗨@mrleemon！

我们没有考虑过这种情况。 到目前为止，块模式旨在成为用户可以根据需要添加和编辑的部分。 这也意味着根据他们的需求调整内容。

您介意详细介绍您共享的用例吗？ 什么时候或为什么会有用？

@enriquesanchez

我正在考虑一个页面设计，该页面具有按特定顺序的一系列分组块，允许用户（例如，具有编辑角色）修改那些块的内容，但不能删除它们或更改其顺序，因此页面顶部的菜单锚点继续匹配页面结构。

您介意详细介绍您共享的用例吗？ 什么时候或为什么会有用？

从过去的客户工作中，我也听到了这个请求，通常是来自具有特定编辑工作流程的大型组织。 通常，他们希望为特定类型的内容提供经过批准的布局，然后让作者可以编辑布局中的内容（图像，视频，文本等），但不能更改布局本身。 其背后的原因通常是，即使许多不同的人正在生成和编辑内容，也要在整个站点上保持内容的一致设计和品牌。

具有可以编辑布局中的内容（图像，视频，文本等），但不能更改布局本身的作者

是的，基本上具有锁定布局类型的块（组，列等）的能力会很棒。

我知道一个事实已经出现过了，我可以发誓模板上有一些锁定方面，可以让您完成此任务，但是我却逃不过来。 无论如何，用例看起来都是合法的，并且有趣。

创建模板时绝对可用。 由于它是较低级别的API，因此尚无法从模式创建级别进行访问。

这是基于Rich的@richtabor的最新模型的建议
大模态2. https://github.com/WordPress/gutenberg/issues/17335#issuecomment -587951100

大模数与小模数。 某处可能会有一个图标，以使插入器屏幕变小。 只要单击一下较小的图标，Block插入程序就会变小，这样您就可以专注于一种人们正在考虑使用的与布局内容相关的图案。

我继续了Rich的模型，并添加了Use and Edit和一个锁图标。
这意味着用户可以编辑图案或可重复使用的块。
在管理员已锁定模式的地方，“编辑”不可用。
用户可以单击使用，图案标题或图案本身直接使用/插入布局。 我也将蓝色下划线移到了所选区域附近。

另类。
使用“设置”对话框创建一个下拉菜单，显示“编辑”（如果可以编辑对象），然后显示“导入和导出”等。

单击编辑。 聚焦区域，仅用于编辑图案/可重复使用的块。

初始版本已完成。 这里仍然有一些后续任务（搜索，类别...），我将结束此问题，因为我们有一个＃21080，其中包含大量的后续任务。