Esses conceitos são amplamente influenciados por:

• Blocos atômicos
• WordPress.com
• Biblioteca de Design

Acredito que padronizar um fluxo de UX para essa interação beneficiaria Gutenberg e os usuários.

Temos suporte para isso, mas apenas por tipo de postagem e o modelo é aplicado no carregamento, com a seguinte lógica:

 * 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.

Não vejo muito valor nisso e adoraria ter algo como o que você acabou de descrever.

Eu gosto mais da abordagem de sobreposição porque tem mais espaço na tela para mostrar os padrões disponíveis.

Este recurso seria paralelo a qualquer trabalho de áreas de bloco. Pode haver padrões feitos para postes e padrões feitos para modelos ou qualquer outra área de bloco. Por exemplo, um padrão de modelo pode ser usado para alterar rapidamente o modelo de postagem única para um layout com uma barra lateral.

Gutenberg não deve definir padrões, mas os temas padrão definitivamente devem ser enviados com eles.

Meu pensamento inicial é que esse padrão de bloco adicionado NÃO substituiria nenhum conteúdo da página, mas apenas acrescentaria os blocos na parte inferior. Desta forma, o padrão de bloco pode ser adicionado a qualquer momento durante a construção / escrita do conteúdo. Este seria um fluxo semelhante aos blocos atômicos, mas espero que não haja um bloco que contenha todos os outros blocos enquanto eles o fazem.

Sim, gosto mais desse jeito também, pelos mesmos motivos que você declarou.

Pode haver algo interessante para aprender com este plugin também. https://wordpress.org/plugins/full-site-editing/ @obenland o plugin está atualizado atualmente?

Está faltando o trabalho de visualização do bloco que adicionamos nas últimas semanas, mas está funcional de outra forma.

Esta é a aparência da iteração atual, usando blockPreview para a grande visualização do modelo do lado direito:

@epiqueras escreveu:

Temos suporte para isso, mas apenas por tipo de postagem e o modelo é aplicado no carregamento, com a seguinte lógica:

 * 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.

Não vejo muito valor nisso e adoraria ter algo como o que você acabou de descrever.

Antes que alguém tenha alguma idéia sobre esse recurso substituir os modelos de bloco, quero apenas observar que esse recurso é _extremamente_ valioso. Ele permite que os desenvolvedores definam especificamente a composição de um determinado tipo de postagem. Fazemos uso extensivo dessa funcionalidade em @meredithcorp, onde muitos de nossos tipos de conteúdo são estritamente organizados.

Acho que esse recurso de "Padrões de bloco" é uma ideia incrível, mas quero ter certeza de que é considerado um "além de", não um substituto completo para a funcionalidade de modelo de bloco de tipo post atual.

Próximos passos:

1. @melchoyce para comunicar suas explorações também.
2. Diverge: Explore o que wpcom está fazendo junto com outros exemplos na indústria (ex. Squarespace, etc.)
3. Converge: reúna os padrões mais fortes em uma maquete coesa e fluxo de experiência do usuário.
4. Mockups e protótipo em Figma.

No ano passado, explorei alguns protótipos para layouts de página de Gutenberg. Minhas explorações tiveram algumas peças:

• Estenda layouts para trabalhar em páginas, não apenas em CPTs.
• Crie uma maneira para os autores do tema “declararem” vários modelos.
• Crie uma maneira para os autores do tema categorizarem esses modelos.
• Crie a IU para selecionar um layout.

Área de Trabalho

Ver Protótipo

_Observação: este protótipo era de uma rodada anterior que experimentei e alguns dos elementos estão desatualizados._

Móvel

Ver Protótipo

O colapso

O seletor de layout, como tudo em Gutenberg, é um bloco. Consiste em alguns elementos:

• Título / descrição do bloco.
• Guias para categorizar os tipos de layout (estilizados após o insersor de bloco).
  
  
  
  • Estes são definidos por tema.
  
  
  • Quando você tem apenas alguns layouts (digamos, <5), as guias não aparecem.
  
  
  • Se não houver nenhum layout categorizado, as guias não serão exibidas.
  
  
• Uma lista de layouts de página disponíveis.
  
  
  
  • Os gráficos de layout devem ser gerados automaticamente com base nos blocos incluídos nos mesmos.
  
  
  • As imagens são caixas cinzentas, o texto tem linhas cinzentas mais escuras, os botões são azuis, etc. Devemos abstrair tudo em formas simples.
  
  
• Finalmente, o próprio layout.
  
  
  
  • Nessas maquetes, você pode ver estilos de tema aplicados a Gutenberg. Se os estilos de tema não forem declarados, os blocos voltarão aos estilos genéricos de Gutenberg.
  
  
  • Você também pode notar os elementos globais na página - neste caso, o logotipo do site, navegação e rodapé. Eles existem para apresentação, mas não são editáveis ​​nesta primeira versão de layouts. Eles não são editáveis ​​e são exibidos com opacidade de 40%.
  
  

Mudando Layouts

Eu trabalhei em como o fluxo poderia ser:

Ver Protótipo

O colapso

Então espere, posso ter mais de um layout de página?
Sim! Você pode empilhá-los e combiná-los como quiser.

Isso não vai ficar ridículo?
Sim, poderia. Provavelmente não o fará na maioria dos casos. Ser explícito sobre sobrescrever ou anexar significa que as pessoas têm menos probabilidade de perder conteúdo. Excluir blocos é fácil, então se eles adicionarem e quiserem se livrar dos blocos mais antigos, basta um ou dois cliques de distância.

E se eles não pretendessem sobrescrever seu conteúdo?
Vamos, por favor, apoiar “desfazer”.

E os elementos específicos da página, como imagens de recursos e títulos de páginas?
Se adicionar layouts, devemos converter quaisquer elementos específicos da página em seu equivalente genérico mais próximo. Por exemplo:

• Imagem em destaque → Imagem
• Título da página → Cabeçalho

Que tal blocos duplicados?
Se um bloco específico (como as últimas postagens) for duplicado, devemos permitir isso - as pessoas podem querer exibir outro bloco de postagens de uma categoria diferente.

Os blocos genéricos podem ser duplicados ao seu conteúdo.

O que chamamos de layout depois de anexar outro layout a ele?
Devemos chamá-lo de “layout personalizado” e renderizar novamente a imagem de visualização com base no que foi alterado.

Há muitas coisas desatualizadas nessas simulações, já que têm mais de um ano, mas talvez possamos reutilizar alguns conceitos.

Grande discussão aqui, obrigado por começar. Acredito fortemente que isso pode ajudar a tornar os layouts de página ainda mais simples e mal posso esperar para que aconteça.

Também sinto fortemente que não devemos adicionar um botão adicional ao lado da biblioteca de blocos, porque:

• dilui e fragmenta a biblioteca de blocos como o lugar único para inserir qualquer coisa na página
• adiciona IU adicional para inserir e aprender, para tornar acessível e funcionar em dispositivos móveis e desktop
• é adicionado em um lugar que já está lotado e deve ser reduzido em vez de adicionado ao
• separa o "padrão" do "bloco", criando efetivamente um tipo diferente de conteúdo, quando pode ser indiscutivelmente o mesmo

_Uma vez que você aprende a IU do bloco, você aprende como fazer tudo_, foi um princípio orientador desde o início, e embora deva ser refinado ainda, ele foi escalado relativamente bem. Ainda ontem, discutimos como tratar o _site_ como um bloco (# 16998) pode ser benéfico, pois ele reutiliza a interface do usuário existente. Se, em vez de tratar um "padrão de bloco" como um novo recurso, mas tratá-lo como _só outro bloco que por acaso é pré-projetado e tem blocos filhos dentro_, de repente não é um novo recurso, é um _refinamento de um recurso existente_ o que parece pragmático e sensato, em termos de escopo.

Para mim, a Biblioteca de Blocos parece o local óbvio para esta interface. Que mudanças podemos fazer para acomodar melhor os padrões de blocos? Ele já contém blocos reutilizáveis, possivelmente precursores de padrões como esses, e quaisquer melhorias que fizermos provavelmente irão beneficiá-los também. Existe uma guia Block Patterns? A biblioteca de blocos é mais ampla - tão ampla quanto a biblioteca de blocos e o novo painel de visualização juntos? Os padrões de bloco precisam de uma janela de visualização separada ou podemos aproveitar o espaço extra desse painel de visualização?

Outro exercício é virar a questão de cabeça para baixo: o que há na biblioteca de blocos como existe hoje que sugere que precisamos de uma nova IU para padrões de blocos?

Outra interface, e Mel a aborda de maneira muito elegante, é acessar a interface de espaço reservado. E se o bloco de site, por padrão, permitir que você escolha o modelo básico?

O que se segue é, como é sem dúvida evidente, não uma ideia excepcionalmente considerada, mas apenas um esboço rápido mostrando como ficaria se adicionássemos um menu suspenso "seletor de tipo" à biblioteca de blocos, permitindo a você pesquisar blocos e padrões de blocos juntos :

Para mim, a Biblioteca de Blocos parece o local óbvio para esta interface. Que mudanças podemos fazer para acomodar melhor os padrões de blocos?

Obrigado por mergulhar, @jasmussen! Descobrir essa questão é fundamental. Recentemente, os Engenheiros da Felicidade compartilharam que alguns usuários nem mesmo rolam a Biblioteca de Blocos para encontrar outros blocos fora do que está na frente e no centro. Este é outro problema, mas algo a ser considerado em relação à adição de qualquer outra coisa a essa interface muito pequena.

o que há na biblioteca de blocos que existe hoje que sugere que precisamos de uma nova IU para padrões de blocos?

Eu diria que é o próprio tamanho da Biblioteca de Blocos que torna difícil adicionar padrões de bloco de página inteira lá. Neste momento, o usuário visualiza um ícone de bloco e uma pequena visualização do bloco. Funciona porque é uma pequena área da página que está em foco. Os padrões de bloco funcionam muito melhor quando o usuário pode ver _ a maior parte_ da página e como esses blocos existem juntos. O tamanho da Biblioteca torna isso difícil.

O conceito de "bloco de site" parece bastante interessante. Muitos blocos têm um espaço reservado, portanto, um bloco de site pode também ter um espaço reservado com opções de layout. Essa ideia funciona bem para novas páginas, mas não tanto para páginas com conteúdo existente. Mas aqui está uma maquete rápida em torno disso de qualquer maneira.

Marcador de posição de bloco (para referência):

Marcador de bloco de site:

Isso realmente combina com os modelos de

Boas ideias, obrigado.

Recentemente, os Engenheiros da Felicidade compartilharam que alguns usuários nem mesmo rolam a Biblioteca de Blocos para encontrar outros blocos fora do que está na frente e no centro.

Esse é um bom insight e mais uma razão para melhorar a biblioteca de blocos junto com quaisquer designs aprimorados que fizermos para padrões de blocos.

Eu diria que é o próprio tamanho da Biblioteca de Bloco que torna difícil adicionar padrões de bloco de página inteira lá

Isso soa verdadeiro. Levei um pouco de tempo para tentar fazer uma simulação com base nesse feedback, mas combinando isso com a ideia de uma biblioteca de bloco singular. Não coloque muito peso na alta fidelidade desta maquete, em parte esta é a minha zona de conforto, em parte é uma forma de fazer "parecer real". Então, só porque parece _concluído_, não significa que não possa ser rejeitado com base em feedback posterior:

O que você vê aqui é a mesma biblioteca de bloco singular em que você pressiona o botão (+) Add Block . Isso o disponibiliza na barra do editor, no final do documento, sempre que você fizer um novo parágrafo, ou se procurar pelo insersor irmão.

A IU se baseia no que temos, mas adiciona duas guias além do campo de pesquisa:

• A guia Blocos é o padrão, e o conteúdo é o que temos hoje
• A guia Block Patterns fica próxima a ela e, em vez de ter um painel de visualização separado, este mostra visualizações renderizadas como as próprias miniaturas do padrão de bloco.
  
  
  
  • Há uma _categoria suspensa_, que é uma boa maneira para os plug-ins categorizarem suas ofertas.
  
  
  • As miniaturas têm larguras fixas (2 colunas), mas alturas variadas, estilo alvenaria.
  
  
  • A janela popout inteira ficou maior e, ao não exibir um painel de visualização, obtemos ainda mais espaço. Podemos até explorar truques responsivos para dimensionar a lista suspensa de acordo com o espaço disponível na tela.
  
  
• Ao pesquisar, você pesquisa tanto em blocos quanto em padrões de blocos.
  
  
  
  • Os resultados dos blocos são agrupados separadamente e aparecem primeiro
  
  
  • Os resultados do padrão de bloco aparecem abaixo disso
  
  

Novamente, embora pareça alta fidelidade, não deve ser considerado um evangelho. A intenção é simplesmente promover a conversa. Fui inspirado por alguns dos trabalhos de @shaunandrews para Full Site Editing e tenho certeza de que ele também terá ideias para compartilhar.

Espero que isto ajude! Pensamentos?

Tudo bem, com base nas explorações acima, vejo que estamos dividindo isso em duas tarefas:

1. Visualizar e escolher um layout de página ao criar uma nova página
2. Adicionar novos padrões de bloco posteriormente, por meio do insersor

@jasmussen tem algumas explorações de inserção excelentes em https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480 que podemos iterar para o dispositivo de inserção.

@shaunandrews também compartilhou

Ao criar uma nova página, você terá a opção de selecionar um layout. A visualização é uma boa adição que nem @mapk nem eu exploramos ainda.

Devemos pensar sobre uma questão: os layouts de página inteira _just_ devem acontecer para páginas, não para postagens?

os layouts de página inteira devem acontecer apenas para páginas, não para postagens?

Um aspecto é o nosso padrão, outro é a distinção técnica. Ou seja, é muito provavelmente tecnicamente trivial, uma vez que é o mesmo por baixo do capô, portanto, é apenas uma questão de decidir o que _permitimos_. A vantagem de permitir isso em todos os lugares é que é um fluxo previsível e igual em todos os lugares. A desvantagem é: provavelmente não queremos que você crie uma nova postagem que use o modelo da página inicial do blog.

Talvez o template, ao ser registrado, decida por si mesmo em quais taxonomias deve ser permitido?

Talvez o template, ao ser registrado, decida por si mesmo em quais taxonomias deve ser permitido?

Boa ideia - então, os modelos também podem ser usados ​​para categorias / tags e CPTs.

(Um selecionador de modelo nas páginas de taxonomia pode ser legal!)

Tangencialmente relacionado aos padrões de blocos - seções de conteúdo - um amigo compartilhou algumas idéias sobre o insersor irmão, o sinal de mais que aparece ao passar o mouse entre os blocos, observando que seria mais utilizável quando sempre visível quando o bloco foi selecionado. A razão pela qual este não é o caso agora é porque isso entra em conflito com apenas querer clicar no texto para editar e com os controles de redimensionamento presentes nos blocos Espaçador e Cobertura. A chave aqui é que _tudo é um bloco_.

Algumas capturas de tela do construtor de sites GoDaddy foram compartilhadas, onde uma interface semelhante existe e é permanentemente visível na seleção. A principal diferença é que esta IU diferencia entre pequenos blocos (texto, imagens) e seções maiores, e mostra este controle apenas no último:

À medida que continuamos nos padrões de bloco, seria interessante pensar se esse conceito abre as portas para uma maior simplificação da IU de base com a adição de recursos às seções maiores.

@jasmussen Posso pegar seu arquivo para https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480?

Sim, claro. Eu coloquei tudo rapidamente junto em uma espécie de arquivo Figma bagunçado, então copiei aqui:

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

Obrigado!

Estou brincando com algumas ideias:

Comecei com a ideia de um menu suspenso e tentei uma única lista de blocos:

Junto com isso, tentei duas colunas e uma única coluna para padrões, usando miniaturas para os padrões na lista:

Então decidi que a busca estava em um ponto confuso e dei um passo para trás. Tentei adicionar uma lista suspensa ao lado da pesquisa e as guias abaixo da pesquisa:

Com as guias abaixo da pesquisa, também tentei mostrar miniaturas de padrões na orientação paisagem e retrato.

Eu gosto do que @joen fez com o layout de padrões mais interessante, então também tentei uma maquete rápida com isso:

Ótimas explorações. Acho que as guias funcionam um pouco melhor como um padrão, porque a lista suspensa ao lado da pesquisa faz com que pareça que os dois estão ligados - como, eu só posso pesquisar dentro de padrões ou modelos, não posso mudar minha visão selecionando um.

Gostei muito de ler esta edição, as ideias foram lidas e estão ótimas!

Eu gostaria de sinalizar os problemas relacionados # 15623 e # 17512 que se concentram em fornecer os tipos de bloco e infraestrutura necessários, respectivamente, para permitir a edição completa do site.

Embora os padrões de bloco, conforme discutido aqui, façam sentido em ambos os contextos (postagem individual versus modelo inteiro), acho que precisamos diferenciar entre dois tipos de modelos:

• Partes do modelo (por exemplo, para serem implementadas com um tipo de postagem wp_template_part internamente, semelhante a como o plug -
  
  
  
  • As partes do modelo devem poder ser usadas em vários lugares e deve ser possível anexá-las a outro conteúdo (como discutido aqui antes).
  
  
• Modelos (por exemplo, para serem implementados com um tipo de postagem wp_template internamente, consulte # 17513):
  
  
  
  • Os modelos devem representar os modelos _entire_, incluindo toda a marcação semântica que constitui um documento HTML. Deve haver algumas restrições sobre como eles podem ser colocados, por exemplo, modelos completos não fazem sentido no conteúdo de uma postagem individual, e também não deve ser possível anexar um modelo completo em outro lugar - um modelo completo deve sempre substituir o conteúdo existente, e seu principal caso de uso seria no início da criação de um novo modelo com Gutenberg (ou seja, "Selecione seu ponto de partida").
  
  
  • Embora ainda precisemos descobrir como geralmente encorajar (aplicar?) Marcação semântica sólida (por meio dos problemas mencionados acima), acredito que também devemos considerar esse cenário aqui.
  
  

Até agora, este problema parece estar focado principalmente nas partes do modelo, e isso faz sentido, mas seria ótimo se pudéssemos também pensar em como expandir isso para modelos completos no futuro.

Até agora, este problema parece estar focado principalmente nas partes do modelo, e isso faz sentido, mas seria ótimo se pudéssemos também pensar em como expandir isso para modelos completos no futuro.

Um esclarecimento - a configuração de "padrões de bloco" é menos sobre as partes do modelo (que são estruturalmente significativas) e mais sobre os elementos de design gerais feitos de blocos menores. Depois de inseridos, eles não são armazenados separadamente. Por exemplo, uma imagem de "capa" que combina alguns blocos para obter uma aparência específica que, de outra forma, exigiria trabalho dos usuários. Pense nisso mais como uma coleção de designs que podem ser adicionados em qualquer lugar sem necessariamente representar uma parte reutilizável de um modelo de tema.

Uma exploração rápida e suja, pegando as ideias de @jasmussen e aplicando-as a um modal em vez de um popover:

Eu aprecio as guias e o layout de pesquisa, embora deva admitir que pessoalmente _sempre_ uso a pesquisa na biblioteca de blocos, então, como ponto de dados de um, prefiro pesquisar primeiro.

O insersor de diálogo modal definitivamente traz o espaço. Isso é bom. Mas também perde um pouco do contexto visual de onde o seu cursor está / onde o bloco ou padrão de bloco será inserido. Além disso, ele abre a questão de saber se este se torna o comportamento global para o insersor de bloco ou, por exemplo, apenas o que você vê quando usa o insersor irmão ou uma variante como o "insersor de seção" sugerido acima. E se nós _do_ fragmentarmos o comportamento, isso é bom?

Sua exploração lá, @melchoyce , realmente ajuda! Obrigado! Eu tenho algumas idéias sobre isso.

Em um caso, o modal comunica os muitos blocos disponíveis, algo que as pessoas lutam para explorar agora. Mas, por outro lado, ver todos esses bloqueios como esse se torna um pouco opressor. Um modal parece certo para os padrões, mas não para blocos individuais. Mas a maquete também mostra os acordeões abertos, por isso pode mudar completamente se apenas mostrar um aberto como fazemos no padrão.

Por mais que eu goste do espaço adicional da versão em diálogo, dormindo sobre ela, não parece ser a abordagem certa para mim. Ele remove todo o contexto do conteúdo e parece opressor ao inserir blocos simples como parágrafos ou imagens. Cada vez mais me sinto da mesma forma em relação aos blocos pré-fabricados, ou padrões de bloco - eles são apenas coleções de blocos e devem ser inseridos da mesma forma.

Embora https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480 não seja necessariamente o caminho a percorrer - as categorias começam a parecer inúteis e há muita coisa acontecendo - eu sinto que _melhorar o bloqueio biblioteca para acomodar blocos complexos (e evitar um diálogo modal) é o caminho a percorrer.

Eu realmente sinto que melhorar a biblioteca de blocos para acomodar blocos complexos (e evitar um diálogo modal) é o caminho a percorrer.

Agora que temos o Painel de Ajuda, que oferece mais espaço na biblioteca, provavelmente podemos trabalhar um pouco com ele. Talvez os padrões sejam outra guia para separar dos blocos individuais, mas a área de visualização ainda permanece no lado do painel de Ajuda que pode ser rolado verticalmente, se necessário.

Eu gosto da ideia de "Block Patterns" (talvez devesse ser alterado para "Block Layouts?"), Mas não gosto de adicionar um novo bloco usando uma caixa de diálogo - é muito perturbador! (Se os padrões de bloco fossem adicionados desta forma, eu estaria bem com isso.)

Eu sugiro que o Block Inserter deve permanecer um pequeno popover (como está hoje), enquanto os padrões de bloco devem ser um componente completamente diferente - já que o contexto em que cada um é usado _poderia_ muito bem ser diferente: um para construir páginas (padrões) - o outro para adicionar blocos / ajustar essas páginas.

Ele _poderia_ funcionar dentro do dispositivo de inserção, mas podemos descobrir que a interface se torna mais complicada e confusa - e sem falar que o dispositivo de inserção é bem pequeno. Trazer pequenas visualizações de padrões pode não ser a melhor experiência. Precisamos ser capazes de mostrar mais de um padrão (para fornecer o contexto adequado para o usuário escolher), mas também tornar as visualizações grandes o suficiente para realmente ver.

Talvez possamos ajustar um pouco a forma como estamos fazendo as coisas.

Apenas pensando em voz alta aqui, mas e se tivéssemos o Inserter no canto superior esquerdo, como está hoje, e introduzíssemos um novo padrão de UX entre os blocos existentes - onde as pessoas podem adicionar padrões / layouts de bloco (como os chamamos). Isso substituiria o dispositivo de inserção de bloco ao focalizar (+) que atualmente reside entre os blocos e permaneceria visível (não se esconderia quando não passasse o mouse).

Aqui está uma captura de tela (_com conteúdo real de Gutenberg_) sobre como poderia ser:

Precisaria haver algum pensamento por trás de onde exatamente isso aconteceria. Seria entre cada bloco? Não tenho certeza.

Abrir o insersor de padrão dispararia um modal a partir do qual o usuário pode selecionar um novo padrão para adicionar à sua página. Aqui está uma exploração do modal, usando uma seleção categórica de nível superior, embora eu não esteja 100% aqui sobre como isso seria.

Esse padrão (ou partes dele, pelo menos) é visto na oferta Site + Marketing do GoDaddy, bem como no SquareSpace (e possivelmente em outros lugares). Vale a pena explorar.

Um bloco e um layout devem ser DIFERENTES.

Um layout deve aproveitar a estrutura css que está usando.

Exemplos de layout:

• Coluna / linha
• Rede
• Um controle deslizante
• Um container
• Abas, acordeões

Um bloco pode viver dentro de um layout ou não.

Um padrão pode ser um layout + blocos?

Veja como o aplicativo Blocs faz isso. Ele usa um Inserter muito maior. Apenas compartilhando mais pesquisas.

Mais olhando o que os outros estão fazendo lá fora.

Qubely usa um botão na barra de ferramentas superior para abrir um modal.

Ótimas ações, Mark.

Eu observaria que a abordagem Qubely é aquela que eu acho que devemos evitar, e é uma abordagem que várias outras coleções de blocos usam. A abordagem assume que o usuário está em uma tela de desktop e não está usando a opção "Barra de ferramentas superior", ou mesmo a opção futura "mostrar rótulos para todos os ícones". Portanto, se fossemos adicionar um botão separado real, provavelmente quereríamos adicioná-lo no contexto direto do insersor de bloco, e provavelmente deveríamos ver como poderíamos reduzir os outros botões presentes naquele espaço.

E aqui está um instantâneo de como o SquareSpace tem uma interação separada para arquitetura de página e edição de conteúdo , fornecendo contexto para meu comentário anterior .

E aqui está uma conversa contínua (Slack) que discutimos durante a reunião de design de ontem:

Tenho pensado muito sobre uma interação de padrão versus uma interação de bloco. Movendo padrões como a interação de "construção" de nível superior, enquanto mantém os blocos como a interação de "adição / ajuste". Claro que alguém poderia construir "padrões" com blocos obviamente, mas não é exatamente simples e requer muito mais interações para ser realizado. E se houvesse uma diferença distinta entre a arquitetura de página e a arquitetura de conteúdo?

Obrigado por compartilhar isso, Rich. Parece que o equilíbrio a ser percorrido é tornar trivial para os usuários a inserção de grandes seções úteis de conteúdo para criar páginas rapidamente quando pretendem, mas ter acesso intuitivo trivial a blocos individuais quando é disso que precisam.

Para mim, a principal lição do Squarespace GIF é que, embora a dualidade entre duas bibliotecas exista, ela é temperada pela _contextualidade_. Eu me pergunto se podemos fazer ainda melhor, para evitar duas bibliotecas de blocos de aparência completamente diferente. Por exemplo, ao inserir um bloco de _Menu de navegação_, parece intuitivo que a biblioteca de blocos se torne uma ferramenta para inserir apenas _Itens de menu_ dentro dele. Existe uma maneira semelhante de aproveitar o contexto na própria tela de edição?

Quanto a como adicionar um layout, talvez na área Configurações da guia Documentos, poderia haver uma lista de layouts com um gráfico mostrando ao usuário a aparência do layout?

Já há algum tempo que temos uma seção e layout modal em Atomic Blocks e estou feliz em compartilhar o que experimentamos até agora.

Para elaborar as perguntas de @mapk :

1. Sim, o editor de bloco deve ter uma IU dedicada para trabalhar com padrões / seções / layouts de bloco ou como você quiser chamá-los. A próxima etapa lógica após os blocos individuais é como combiná-los para criar layouts modernos e expressivos. Criar uma IU padronizada para isso permitirá que usuários e desenvolvedores aproveitem uma experiência coesa e evitem reinventar a roda um milhão de vezes (o que já começou). Mesmo que o Atomic Blocks e vários outros já tenham uma IU dedicada, eu ainda preferiria adotar uma IU padrão (mas extensível) para isso.

Se o núcleo fornece ou não padrões de bloco para preencher esta IU é outra questão. Talvez faça sentido que os temas centrais forneçam padrões de blocos opinativos para complementar e estender seus designs.

1. Várias das IUs propostas aqui são um ótimo começo. Gosto particularmente do que vejo de @shaunandrews e @melchoyce aqui . Compartilho a opinião de @richtabor sobre o insersor de bloco ser muito limitante para um recurso como este e acho que iremos superá-lo rapidamente. A construção de páginas expressivas com padrões de blocos merece mais do que uma interface de 700px x 430px.

Nós distinguimos uma diferença entre seções e layouts em nossa IU, com seções sendo partes de uma página e layouts sendo um layout de página inteira. Esta é uma decisão opinativa e faz sentido em nossa implementação atual, mas também pode ser tratada com uma categoria ou interface de filtragem.

O Atomic Blocks também possui um recurso de favoritos para permitir que os usuários adicionem e revisitem suas seções e layouts usados ​​com frequência. Esse tipo de recurso será necessário porque a quantidade de padrões aumentará rapidamente. Outra forma de capacitar o usuário seria permitir que os padrões de lista branca e lista negra controlem a saída na IU do padrão.

O poder do editor de blocos será mais aparente e validado em recursos como modelos de blocos e padrões de blocos, que mudam fundamentalmente a maneira como construímos sites no WordPress. Também temos a oportunidade de encurralar o oeste selvagem das interfaces personalizadas do WordPress e começar a oferecer uma experiência mais coesa e previsível com padronização.

Tenho alguns modelos para compartilhar hoje que tentam abordar uma ideia passada . Para elaborar o desafio: um usuário pode não se importar com a diferença entre um Bloco, um Padrão ou um Layout e, uma vez que qualquer um pode ser inserido em qualquer local, criar interfaces diferentes para cada um pode causar confusão.

No seguinte mockup, tentei resolver isso:

• Criação de uma interface de biblioteca unificada única, com guias
• Mostrar esta interface como um popover, de altura total, mas não modal, quando aberta na Barra do Editor
• Mostre-o como uma caixa de diálogo, padronizando para a guia Padrões, quando aberto a partir do insersor irmão

_ Observe que esta IU aproveita os conceitos de IU inacabados que estão sendo explorados em # 18667._

Nesta configuração, os usuários podem inserir um bloco ou um padrão sem ter que olhar através de interfaces diferentes, mas reconhecemos que você pode querer mais espaço na tela ao inserir os padrões maiores.

Essa interface também aproveita as novas frases de categoria sugeridas aqui .

• Mostre-o como uma caixa de diálogo, padronizando para a guia Padrões, quando aberto a partir do insersor irmão

Acho que temos algo aqui!

@jasmussen , os padrões também apareceriam em / ou apenas em blocos?

Essa é uma excelente pergunta. Talvez se categorizado separadamente. Mas talvez a grande visualização seja mais necessária para os padrões? "2 padrões encontrados" podem chamar a caixa de diálogo?

@jasmussen , os padrões também apareceriam em / ou apenas em blocos?

Possivelmente. Embora sem as visualizações, não tenho certeza de como seria útil tê-los dentro de / - a menos que eles tivessem um nome exclusivo (o que eu duvido que seja o caso, por exemplo, "Cerca de 1", "Cerca de 2") ou se os usuários poderiam intitulá-los como eles considerassem adequado (não 100% certo sobre isso também).

Se implementarmos um recurso de "favoritos", como @mikemcalister menciona anteriormente neste tópico, talvez apenas os padrões favoritos sejam exibidos (desde que sejam claramente identificáveis). E se permitirmos, os padrões precisariam de um ícone correspondente (semelhante aos blocos)? Ou haveria um ícone de "padrão" padrão para classificar os padrões de bloco?

Ei todos, eu só queria colocar minha cabeça e dizer que amo onde isso vai levar. As últimas maquetes e linhas de pensamento são maravilhosas. Enquanto estou pensando em como isso se traduziria em Gutenberg móvel nativo, acho que o último mockup de @lumberman é bem organizado e deve ser bem escalável, mas tenho uma preocupação com relação à hierarquia e interação. Perdoe-me se não tenho o contexto histórico completo, mas acho que a perspectiva móvel seria útil neste contexto.

Em Acordeões / Hierarquia de Nav

Um problema que sempre tive com o aplicador são as seções de acordeão (mais usadas, blocos comuns, etc). A primeira seção "Mais usado" é clara o suficiente porque está sempre aberta inicialmente, mas tende a enterrar as seções adicionais e dificultar a localização, especialmente em dispositivos móveis.

Eu sou um fã de como a barra lateral esquerda está disposta em sua última maquete, @lumberman. Você acha que faria sentido adicionar as seções como itens de lista na hierarquia de navegação da barra lateral esquerda? Em outras palavras, os itens em Sections seriam "Mais usados", "Cabeçalhos", "Rodapés" etc. (ou qualquer que seja o nome do grupo)? Isso pode resolver a preocupação das "seções enterradas" e, potencialmente, nos permitir remover essencialmente a necessidade dos acordeões, mas eu entendo que esta seja uma grande divergência da biblioteca de blocos historicamente, então outros podem não gostar desta sugestão

Em "Favoritos"

Um dos conceitos que está sendo discutido (por @mikemcalister inicialmente eu acredito) é o de "favoritos". Isso é quase exatamente como uma ideia que explorei um tempo atrás no GB móvel nativo , onde você escolheria os blocos favoritos para criar "Minha Biblioteca" de blocos durante o processo de integração em GB e, a partir daí, a biblioteca de blocos se concentraria em aqueles principalmente enquanto ainda fornecem um caminho óbvio para a biblioteca de bloco completo. O principal problema com isso era a descoberta, embora se eu acho que há maneiras de resolver isso.

Na Biblioteca de Blocos, Sobrecarga, IA, etc.

Há uma coisa que sempre volto em relação ao insersor em geral, que se torna ainda mais claro à medida que o tornamos mais robusto. Durante os testes de usabilidade da web móvel, nós (a equipe móvel da Automattic) ouvimos muitas vezes que a biblioteca de blocos é esmagadora. Existem muitas opções e os agrupamentos não são imediatamente claros. Acho que as novas ideias de IU propostas aqui ajudam porque "respiram" um pouco mais, mas o número de blocos ainda é esmagador e só vai piorar com a introdução de outro agrupamento (Padrões de Bloco). Eu acho que conforme aumentamos isso (o que eu acho que é a direção certa, a habilidade do tipo "favoritos" pode atenuar isso.

Vale a pena dar uma olhada na abordagem do Mobirise para layouts de página. Eles fornecem uma tela à esquerda e um controle deslizante de seleção do painel vertical à direita segmentado nos elementos verticais naturais da página ... algumas opções de painel para a barra superior, menu superior e painéis corporais por função de negócios (dependendo do tema e tipo de página (por exemplo, painel de mapa, painel de pessoas se esta for uma página Sobre nós), rodapé e barra de rodapé. Basta arrastar e soltar os painéis da direita para a esquerda.

AVISO: Se você é um contribuidor do Gutenberg, leia os termos do

Você declara e garante que não irá: copiar, modificar, criar trabalhos derivados, adaptar, fazer engenharia reversa, emular, migrar para outro serviço, traduzir, compilar, descompilar ou desmontar Serviços;

Melhor ainda ... não vá ao site deles.

Em vez disso, você pode considerar apenas assistir aos vídeos do Mobirise no YouTube. Não estou ciente de qualquer extensão de termo que se estenda além da licença que o YouTube exige dos uploaders de conteúdo, mas Caveat Emptor ... Eu não sou advogado.

Se você acredita que assistir a vídeos do YouTube não representa risco para o IP do Gutenberg, o canal do Mobirise no Youtube está em https://www.youtube.com/channel/UCt_tncVAetpK5JeM8L-8jyw/featured. Você pode ver a construção de uma página específica do tema arrastando e soltando os painéis em ação.

@jasmussen , suas maquetes aqui estão ótimas. 😍 Adoraria vê-los em um protótipo funcional, se possível, que possa responder a algumas das minhas perguntas abaixo.

Conforme indicado por @richtabor , faz sentido alterar contextos para quando alguém está adicionando um bloco da barra de ferramentas em vez de adicionar um padrão do insersor irmão. Eu gosto que o espaço extra seja dado em um modal para os padrões!

Próximos passos

1. O termo "blocos pré-fabricados" parece um pouco estranho. Podemos tentar "Block Patterns" aí, ou essa sensação é igualmente estranha?
2. Qual é a aparência quando clico no insersor na barra de ferramentas superior e clico na guia "Padrão de bloco"? O popover muda para modal? O popover muda de tamanho, mas permanece um popover na mesma posição? Ele mantém o mesmo tamanho e posição e agora mostra apenas os padrões?
3. Qual é a aparência da interação ao clicar no insersor irmão dentro do editor e, em seguida, clicar na guia "Blocos"? O modal muda de tamanho ou posição a partir daqui ou permanece um modal?
   
   
   
   1. Crie um protótipo que responda a essas perguntas. Fico feliz em ajudar aqui se você puder vincular o arquivo.
   
   

@lumberman, obrigado pelas maquetes também! Eu realmente gosto de como eles utilizam o projeto de inserção existente e constroem sobre ele. 👍 Existe uma maneira de reduzir a quantidade de acordeões? Parece que muitas coisas podem se abrir. No momento, testes de usabilidade revelaram que as pessoas não estão clicando nos acordeões que já temos.

O termo "blocos pré-fabricados" parece um pouco estranho. Podemos tentar "Block Patterns" aí, ou essa sensação é igualmente estranha?

Sim, vamos definitivamente tentar os padrões de bloco.

Pessoalmente, acho que esse termo é mais estranho, no entanto, também estou ciente de que foi discutido nos chats de design e em outros lugares, e o custo de experimentá-lo no plugin é muito pequeno, então não há razão para não fazer isso! Pode parecer perfeito ou pode revelar-se que precisa de ajustes e iremos revisitar.

Qual é a aparência quando clico no insersor na barra de ferramentas superior e clico na guia "Padrão de bloco"? O popover muda para modal? O popover muda de tamanho, mas permanece um popover na mesma posição? Ele mantém o mesmo tamanho e posição e agora mostra apenas os padrões?

Nenhuma mudança aconteceria. Seria igual ao modal grande, mas em um espaço menor / mais apertado. Talvez haja apenas espaço para uma única coluna de padrões de bloco ali.

Mas ainda acho que vale a pena, ter a mesma IU e os blocos e padrões, disponíveis nos dois locais.

Qual é a aparência da interação ao clicar no insersor irmão dentro do editor e, em seguida, clicar na guia "Blocos"? O modal muda de tamanho ou posição a partir daqui ou permanece um modal?

Uma boa pergunta que um PR / protótipo pode responder. Eu imagino mudança zero, que há apenas mais espaço para olhar os blocos, o que alguns podem preferir!

Crie um protótipo que responda a essas perguntas. Fico feliz em ajudar aqui se você puder vincular o arquivo.

Aqui está o arquivo Figma: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 - está um pouco bagunçado, mas você pode enviar um ping se precisar de ajuda.

Aqui estão algumas explorações baseadas nas excelentes idéias que vocês têm compartilhado. Limitei-me propositalmente a trabalhar dentro do espaço fornecido pelo insersor de bloco atual. Eu fiz isso por dois motivos:

1. Isso tornará mais fácil para nós traduzir esta IU para telas pequenas.
2. Para o tamanho médio da tela, acho que o insersor atual já ocupa espaço suficiente na tela. Então eu acredito que um modal maior e centrado não trará muito benefício.

** A imagem acima é uma captura de tela de 1200 x 800.

Dado que tenho as restrições de tamanho do insersor de bloco, tentei explorar como poderíamos aproveitar o máximo possível o espaço disponível. Embora o painel de Ajuda funcione bem para blocos, ele atrapalha quando tentamos exibir miniaturas maiores para padrões de bloco. Então tentei removê-lo, sem me desfazer de seu conteúdo . Isso nos dá mais espaço, não apenas para padrões de blocos, mas também para blocos. Eu também gosto muito de como as miniaturas de visualização procuram por padrões de bloco em alguns dos modelos compartilhados aqui, e como já estamos fazendo visualizações de bloco no painel Ajuda, pensei, por que não tentar?

É mais ou menos assim:

Quando você focaliza / passa o mouse sobre um bloco, o conteúdo da "faixa" de dicas na parte inferior muda de acordo:

Basicamente, estou apenas mudando as coisas:

As visualizações de bloco realmente não ocupam muito mais espaço do que os botões atuais, e agora podemos mostrar mais de 3 por linha.

Também tentei exibir miniaturas menores, mas acho que as visualizações são mais difíceis de ler:

Com todos os itens acima, a guia de padrões de bloco pode ser parecida com esta:

Podemos ter uma interface do usuário familiar para blocos e padrões de bloco que aproveita ao máximo o espaço disponível no insersor.

Obrigado por trabalhar neste Enrique!

Limitei-me propositalmente a trabalhar dentro do espaço fornecido pelo insersor de bloco atual. Eu fiz isso por dois motivos:

• Isso tornará mais fácil para nós traduzir esta IU para telas pequenas.
• Para o tamanho médio da tela, acho que o insersor atual já ocupa espaço suficiente na tela. Então eu acredito que um modal maior e centrado não trará muito benefício.

Eu discordo disso. Temos boas maneiras de traduzir um modal para telefones (tela inteira) e podemos mostrar uma coluna de padrões em vez de duas e três.

Digo isso tendo explorado designs não muito diferentes dos seus , então também estou discordando do meu eu anterior.

O que percebi foi que, se quisermos mostrar padrões de blocos volumosos, precisamos de todo o espaço possível. Tratava-se de conectar os pontos delineados por Mark e Rich , resultando nessas maquetes ( arquivo Figma ).

Fiz uma tentativa em uma biblioteca de blocos que ocupa todo o espaço vertical disponível, remove o texto de ajuda e desanexa a janela de visualização em # 19836. Ele pode servir como um protótipo para a ideia geral.

Enrique, eu adoraria trabalhar com você para trazer um pouco de sua sutileza para as maquetes verticais altas mostradas anteriormente. Aqui está o arquivo Figma: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 - notavelmente, ele funciona bem no ponto de interrupção do desktop, mas os pontos de interrupção móveis ainda não foram elaborados . Também estou sempre pronto para um bate-papo, se isso for útil.

hey @jasmussen! 👋

Aqui está uma maquete rápida combinando suas maquetes verticais altas com algumas visualizações de padrão de bloco:

Eu gosto disso. As grandes visualizações parecem boas neste tamanho. Um problema que estou tendo é que não tenho certeza se as categorias de acordeão funcionam bem para navegação e descoberta quando as visualizações são tão grandes.

Passei algum tempo explorando a ideia de ter as categorias ao lado:

Acho que isso torna mais fácil verificar as categorias disponíveis, mas empurra as categorias para padrões de bloco para baixo e não tenho certeza se acho que isso está certo.

Diz-me o que pensas.

Aqui está uma maquete rápida combinando suas maquetes verticais altas com algumas visualizações de padrão de bloco:

Isso é estelar! Notavelmente, ver padrões na interface vertical é muito esclarecedor e funciona um pouco melhor do que eu imaginava.

As categorias laterais também não são ruins, embora eu me pergunte se elas funcionam melhor como uma lista suspensa quando na versão popover superior esquerda, mas podem funcionar bem na versão de diálogo aberta pelo insersor irmão.

Obrigado por isso! Vou deixar que outros interfiram também.

Aqui estão mais algumas explorações iterando nos modelos recentes:

1. Abas para blocos e padrões de blocos + lista para categorias

2. Abas para blocos e padrões de blocos + lista suspensa para categorias

Eu acho que 1 se sente bem. Gosto de como a lista de categorias é totalmente visível (melhor para descoberta) e acho que deve ser escalonada bem.

Embora 2 pareça mais organizado, estou preocupado que a lista de categorias esteja escondida atrás de um clique e, portanto, afetando a descoberta.

@jasmussen @mapk @shaunandrews o que você acha?

Eu acho que 1 se sente bem. Gosto de como a lista de categorias é totalmente visível (melhor para descoberta) e acho que deve ser escalonada bem.

Embora 2 pareça mais organizado, estou preocupado que a lista de categorias esteja escondida atrás de um clique e, portanto, afetando a descoberta.

Parece bom @enriquesanchez! O número 1 também parece certo.

Algumas idéias:

uma. Precisamos descobrir um mecanismo para o que acontecerá se houver uma lista loooooonga de categorias.

b. Como as categorias devem ser ordenadas? Existe uma prioridade por meio do tema e do plugin? Em ordem alfabética? Ou uma combinação?

c. Se o tema registrar padrões para categorias diferentes, os padrões aparecem na categoria "Do tema", bem como na categoria especificada de cada padrão?

Um eco para os comentários e perguntas de Rich, um resumo maravilhoso. Bom trabalho!

Uma coisa a se considerar é que, de acordo com a tese atual, a biblioteca aparece como um grande diálogo quando aberta a partir do insersor irmão e, inversamente, é menor quando aberta do canto superior esquerdo. Nós _podemos_ usar como padrão as categorias laterais e _colhê-las em uma lista suspensa_ quando os desafios responsivos assim o exigirem.

b. Como as categorias devem ser ordenadas? Existe uma prioridade por meio do tema e do plugin? Em ordem alfabética? Ou uma combinação?

Provavelmente acabará sendo uma combinação de alguns "abençoados" no topo e depois em ordem alfabética. Até um ponto em que os plugins nomeiam suas categorias __Sweet Blocks ou 1. Sweet Blocks . Parece uma daquelas coisas que podemos arriscar pensar demais _agora_, e como é fácil ajustar no futuro, podemos muito bem ir com a solução mais simples e ajustar quando necessário.

@richtabor @jasmussen obrigado pelo excelente feedback.

uma. Precisamos descobrir um mecanismo para o que acontecerá se houver uma lista loooooonga de categorias.

Acordado. Não estou familiarizado se algo semelhante foi necessário para a biblioteca de blocos e se poderíamos aprender com isso.

b. Como as categorias devem ser ordenadas? Existe uma prioridade por meio do tema e do plugin? Em ordem alfabética? Ou uma combinação?

Eu concordo com a sugestão de Joen. Alguma ordem inicial precisa ser estabelecida e observar a iteração quando / se o sistema for interrompido.

c. Se o tema registrar padrões para categorias diferentes, os padrões aparecem na categoria "Do tema", bem como na categoria especificada de cada padrão?

Minha reação inicial é sim. Espero que alguns padrões apareçam em diferentes categorias. Acho que está tudo bem. A ideia de ter uma categoria "Do tema" não é de forma alguma definitiva, mas achei que seria uma maneira fácil de ajudar as pessoas a fazerem com que seu site "parecesse com a demonstração".

Vou continuar iterando sobre isso. Trabalharei em alguns protótipos para ter uma noção melhor de como a biblioteca será exibida.

Achei a abordagem de mobirise prática no campo. Eles têm duas colunas de seleção de painel de bloco ... uma agrupando miniaturas de painéis de bloco sob as categorias de página comuns (cabeçalho, menus, conteúdo, rodapé, etc) com um índice de categoria adjacente para que você possa ver todas as categorias e pular diretamente para um categoria de interesse.

Não empurrando isso como "A" solução. Achei que você poderia achar útil como um exemplo e, em seguida, traduzir o que você gosta / não gosta nele para o design que deseja.

Apenas uma sugestão :-)

Obrigado por tentar novamente, @enriquesanchez!

Também sou a favor do número 1. A exibição da lista evita que o usuário tenha que passar por uma série de cliques para chegar ao resultado desejado. Tê-lo em colapso como Joen sugeriu para telas responsivas parece muito interessante.

Não conheço nenhum mecanismo atualmente em Gutenberg que lida com listas longas, então isso é algo que precisa ser pensado. Separar os blocos dos padrões através do uso de guias já ajuda. Parabéns por isso!

"Do tema" parece um pouco estranho. Talvez "Padrões de tema" ou apenas "Tema" ou mesmo "Tema: [nome do tema]". Talvez eles devam ser priorizados no topo? Posso mantê-los juntos na categoria "tema" E também em expô-los nas categorias relevantes. Talvez isso se torne algo como uma "coleção"? https://github.com/WordPress/gutenberg/issues/19873

Percebi na maquete que, embora a guia "Padrões" esteja destacada, o campo de pesquisa diz que você pode pesquisar blocos e padrões. Isto está certo? Ou devo me limitar a bloquear padrões enquanto estiver na guia Padrão?

Aqui está uma mistura do wireframe que Obenland compartilhou:
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -536109796

e a sugestão de wireframe número 1 de Enrique:
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -582673937

Aqui está a área de Blocos existente mais opções adicionais:

Ao selecionar a guia Block Variations, ela pode mudar para algo assim:

Editar: Usar a interface existente, mas estendê-la para opções adicionais, manteria uma consistência em como selecionamos os blocos hoje. Alguém ainda iria para a mesma área de inserção para selecionar blocos. Mas desta vez também é possível escolher entre Blocos (blocos individuais) -> Variações de bloco (blocos múltiplos) -> Layouts de página (modelos) -> Seções do site (cabeçalho, rodapé, etc.).

Uma coisa a se considerar é a localização da caixa de pesquisa e o que isso implica. Com seus designs mais recentes @enriquesanchez, a caixa de pesquisa seria repetida para cada uma das guias superiores (blocos e padrões), o que me faz pensar que só posso pesquisar um grupo por vez. Minha esperança inicial aqui era que pudéssemos ter uma única entrada para permitir a pesquisa em ambos os blocos _e_ padrões.

Talvez seja uma esperança equivocada ou talvez eu não esteja entendendo como a entrada de pesquisa funciona.

Percebi na maquete que, embora a guia "Padrões" esteja destacada, o campo de pesquisa diz que você pode pesquisar blocos e padrões. Isto está certo? Ou devo me limitar a bloquear padrões enquanto estiver na guia Padrão?

Com seus designs mais recentes @enriquesanchez, a caixa de pesquisa seria repetida para cada uma das guias superiores (blocos e padrões), o que me faz pensar que só posso pesquisar um grupo por vez.

@mapk @shaunandrews Obrigado pelo feedback! Não sei por que, mas em algum lugar ao longo do caminho, mudei a caixa de pesquisa porque inicialmente a tinha no topo das guias (consulte https://github.com/WordPress/gutenberg/issues/17335#issuecomment-575835877).

Eu concordo com @shaunandrews , acho que a entrada de pesquisa deve ser o primeiro elemento no insersor (como é atualmente). É a primeira coisa que foca depois de abrir o inserter, é eficiente e global.

Acho que a entrada de pesquisa deve ser o primeiro elemento no insersor (como é atualmente). É a primeira coisa que foca depois de abrir o inserter, é eficiente e global.

Você também pode explorar como isso pode ser? Quando uma consulta de pesquisa retorna resultados em blocos e padrões, como isso se parece?

Passei algum tempo observando como os blocos serão exibidos se apresentarmos um modal maior para a biblioteca de blocos, como já foi explorado neste assunto.

Eu sempre tento ter uma lista do lado esquerdo para as categorias, como o primeiro exemplo deste comentário anterior.

E daí se seguíssemos o mesmo padrão, mas para os blocos? Isso significa que deixaríamos de usar acordeões como fazemos atualmente. Isso também significa que, para a maioria das categorias, haveria MUITO espaço não utilizado:

Obviamente, isso não é o ideal.

Outra iteração me levou à ideia de ter uma lista contínua de todas as categorias de bloco, e ter os links na lista do lado esquerdo para rolar para o local correspondente. Algo assim:

Eu imagino que se eu for em frente e começar a rolar (em vez de clicar em um dos links), o estado ativo na lista do lado esquerdo será atualizado de acordo para comunicar a posição.

Essa solução faz um uso muito melhor do espaço, e mantemos algumas coisas que gosto:

1. A lista de todas as categorias está sempre visível, o que significa que a descoberta e a exploração se beneficiam.
2. Não precisamos mais clicar para abrir um acordeão de categoria e, como a lista de todos os blocos agora pode ser rolada, a navegação se torna mais fácil.

O que vocês acham?

@enriquesanchez Eu amo essa exploração.

1. Nós nos livraríamos das visualizações nesse tipo de cenário? (Não sou necessariamente contra isso, apenas curioso)
2. O que aconteceria se uma categoria fosse muito longa? (Exemplo: https://d.pr/i/DSsHTW). Seria apenas uma nova linha? Nesse caso, gostaria apenas de garantir que as categorias tenham mais espaço entre elas para que não haja confusão.
3. Eu amo a rolagem contínua em vez de acordeões.

Parece bom. Porém, pergunta. Precisamos esclarecer " Bloco " em " Padrões de bloco "?

Obrigado pelo feedback @jwold e @richtabor 👍

Nós nos livraríamos das visualizações nesse tipo de cenário?

Estou inclinado para isso, mas apenas por blocos. A visualização parece ser muito útil para padrões. Também gosto da distinção visual entre os dois: blocos = ícones pequenos, padrões = miniaturas maiores

O que aconteceria se uma categoria fosse muito longa?

Eu concordo, eles embrulhariam, algo assim:

Eu amo a rolagem contínua em vez de acordeões.

🙌

Porém, pergunta. Precisamos esclarecer "Bloco" em "Padrões de bloco"?

@richtabor Essa é uma boa pergunta. Então você sugere que usemos "Blocos" e "Padrões"?

A propósito, acho que os padrões foram renomeados para variações.

A propósito, acho que os padrões foram renomeados para variações.

Variações não estão relacionadas a padrões - é uma parte técnica dos blocos de construção e não é exposta na IU como um termo.

Eu explorei diferentes variações da biblioteca de blocos quando chamada de um insersor irmão (em algum lugar no meio do documento).

1. Popover

Isso é muito semelhante ao que temos atualmente, apenas um pouco maior:

2. Grande modal

Deve facilitar a navegação pelos padrões. Não tenho certeza se gosto do fato de que abrange o conteúdo por trás dele.

3. Painel deslizante

Sugerido por @mapk. Muito semelhante a https://github.com/WordPress/gutenberg/issues/17335#issuecomment -585425675 em termos de tamanho e posicionamento. Faz-me perguntar se o slide-in pode ser o padrão para os insersores da barra de ferramentas superior e irmão 🤔

Aqui está um protótipo simples de click-through Figma que reúne tudo.

Tente abrir a biblioteca de blocos na barra de ferramentas superior, alternando entre as guias de blocos e padrões de bloco e procurando. Finalmente, tente abrir a biblioteca de blocos do irmão ou do meio do insersor de documentos.

❗️ _Nota: a inserção de blocos e padrões ainda não está disponível no protótipo._

Ei Enrique @enriquesanchez

Ter um protótipo Figma simples realmente faz uma grande diferença. Porque realmente dá uma ideia de como seria uma versão final.

A tela de blocos realmente oferece uma visão geral melhor do que existe hoje. Pode-se ver facilmente os blocos disponíveis sem ter que abrir acordeões para ver quais blocos eles contêm. Também há mais espaço disponível.

Um exercício de olho e mente na manhã de sábado ... :)
A mente / olhos se movem observando a área de blocos mais usados ​​e comuns que contém simetria e equilíbrio.

Quando os olhos vagam para a esquerda, ele vê uma lista descendo, começando com Mais usados ​​e terminando com Incorporados.

Mais usado é em azul. Acima está outra cor azul, uma linha abaixo do texto em negrito do Blocks (a mente não sabe por que a linha azul está lá, pois está tão longe da palavra Blocks que parece separada. Lógico, eu sei por quê.). Para os Padrões de Bloco à direita, não em negrito e nenhuma linha abaixo. Abaixo está um texto Mais usado em negrito. Mais acima, minha mente vê o contorno da borda de uma caixa e o texto de pesquisa dentro dela e é capaz de relaxar mais uma vez.

Isso significa olhar para cada pequeno elemento e como eles se relacionam com o que está por perto e a área geral em que está.

Oi.

Deve haver espaço para uma apresentação baseada em texto do padrão de bloco.
Nem todos os usuários serão ajudados por uma imagem de visualização.

Obrigado pelo feedback @paaljoachim e @carolinan! 🙏

Deve haver espaço para uma apresentação baseada em texto do padrão de bloco.

Eu concordo com você. Estarei adicionando mais fidelidade ao protótipo, incluindo descrições de blocos / padrões ao pairar, precisamos garantir que essas descrições sejam comunicadas à AT.

2. Grande modal

Deve facilitar a navegação pelos padrões. Não tenho certeza se gosto do fato de que abrange o conteúdo por trás dele.

Para o insersor irmão, isso _sente_ o mais natural, embora uma maquete de alta fidelidade possa nos ajudar a decidir melhor. Talvez fazer o fundo escuro modal central ajudará a trazer o foco para o modal (foto abaixo).

Fornece espaço de visualização suficiente para o usuário distinguir adequadamente os padrões individuais - dando a eles uma ideia mais clara do que será adicionado à página. Poderíamos até manter os padrões em duas colunas de largura - garantindo que eles sejam devidamente visualizados.

3. Painel deslizante

Sugerido por @mapk. Muito semelhante a # 17335 (comentário) em termos de tamanho e posicionamento. Faz-me perguntar se o slide-in pode ser o padrão para os insersores da barra de ferramentas superior e irmão 🤔

Isso é interessante, embora eu ache que ficará muito desconectado do insersor irmão. E se estivermos bloqueando a visualização do conteúdo / site por trás dele de qualquer maneira, eu diria que escolher um modal completo faz melhor uso do espaço. Nossa atenção deve ser dedicada aos padrões / inseridor neste ponto.

Além disso, não serão capturas de tela - mas "exemplos", assim como as variações de estilo suportam exemplos - correto?

Exemplo de exemplo:

@richtabor Essa é uma boa pergunta. Então você sugere que usemos "Blocos" e "Padrões"?

Eu diria que sim.

Comecei a decompor isso em pequenas iterações e adicionei uma lista de tarefas à descrição do problema. Esta não é uma lista exaustiva e provavelmente iremos descobrir coisas à medida que avançamos com a implementação. Alguns desses itens podem não ser implementados como parte deste problema.

Se valer a pena, seria muito útil editar o comentário original para definir sucintamente
o que é exatamente um padrão de bloco e como eles são diferentes dos modelos de bloco.

Isso seria útil para acelerar o processo de integração de contribuidores em potencial;
e lembrar os membros principais que estão procurando se atualizar e se atualizar nesta área; e certificar-se de que todos os colaboradores estão na mesma página (trocadilhos).

Tem havido alguma confusão entre os membros principais existentes (leia também os comentários que seguem imediatamente o comentário vinculado) sobre o uso conflitante de terminologia com modelos.

Ao ler os primeiros comentários, não tive certeza de como os "padrões de bloco" são diferentes dos modelos internos (que podem ser reutilizados em vários tipos de postagem, não precisam ser vinculados a uma parte específica de uma página).

Pelo que eu recolhi; padrões de blocos série de blocos que são layout; mas o conteúdo dentro dos blocos ainda não foi definido pelo usuário e se o conteúdo é o mesmo
e eles pretendem substituir os arquivos template.php?
(é complicado que um modelo no WordPress possa representar quase toda a página ou pode ser abstraído para consistentemente de 3-4 arquivos de modelo adicionais (modelos internos)

Um padrão de bloco estaria resolvendo um caso de uso de "Preciso de um bloco de texto explicativo que consistisse em vários blocos: um título (cujo nível de título eu poderia personalizar com base na semântica)?
um bloco de parágrafo e um link para se registrar em um evento ")?

Visualizações de padrão

Eu vi isso outro dia. É um exemplo de como a visualização segue a posição vertical do cursor. Se seguirmos o caminho de uma visualização separada, pode valer a pena explorar.

um exemplo de como a visualização segue a posição vertical do cursor. Se seguirmos o caminho de uma visualização separada, pode valer a pena explorar.

Na verdade, acho que ter a visualização em uma posição fixa pode tornar mais fácil _scrub_ itens na lista - você pode manter seus olhos no mesmo espaço.

Só uma pergunta. Os padrões de bloco permitirão definir áreas bloqueadas, de forma que os usuários não possam alterar a estrutura básica em um padrão de bloco? Por exemplo, seremos capazes de bloquear o número de áreas de recurso no padrão de bloco anexado, para que nenhuma possa ser adicionada ou excluída? Você está considerando este caso de uso?

oi @mrleemon!

Não consideramos esse cenário. A partir de agora, os padrões de bloco devem ser seções que os usuários podem adicionar e editar conforme necessário. Isso também significa adaptar o conteúdo às suas necessidades.

Você se importaria de elaborar um pouco mais sobre o caso de uso que você compartilhou? Quando ou por que seria útil tê-lo?

@enriquesanchez

Estou pensando em um design de uma página com uma série de blocos de grupos em uma ordem específica, permitindo que os usuários (com a função de editor, por exemplo) modifiquem o conteúdo desses blocos, mas não os excluam ou alterem sua ordem, então o as âncoras de menu na parte superior da página continuam correspondendo à estrutura da página.

Você se importaria de elaborar um pouco mais sobre o caso de uso que você compartilhou? Quando ou por que seria útil tê-lo?

De trabalhos anteriores de clientes, também ouvi essa solicitação, geralmente de organizações maiores com fluxos de trabalho editoriais específicos. Normalmente eles desejam fornecer um layout aprovado para um tipo específico de conteúdo e, em seguida, ter autores que possam editar o conteúdo (imagens, vídeos, texto, etc.) dentro do layout, mas não alterar o próprio layout. O raciocínio por trás disso geralmente é manter um design e uma marca consistentes para o conteúdo do (s) site (s), mesmo quando muitas pessoas diferentes estão gerando e editando conteúdo.

ter autores que podem editar o conteúdo (imagens, vídeos, texto, etc) dentro do layout, mas não alterar o próprio layout

Sim, basicamente, ter a capacidade de bloquear blocos do tipo layout (grupos, colunas, etc.) seria ótimo.

Eu sei que isso já aconteceu antes, e eu poderia jurar que havia algum aspecto de bloqueio nos modelos que permitiria que você fizesse isso, mas me escapa. Em qualquer caso, o caso de uso parece legítimo e interessante de resolver.

Isso está definitivamente disponível ao criar modelos. Por ser uma API de nível inferior, ainda não está acessível no nível de criação de padrão.

Aqui está uma sugestão baseada no mais novo modelo do @richtabor de Rich
Grande modal 2. https://github.com/WordPress/gutenberg/issues/17335#issuecomment -587951100

Módulo grande vs módulo pequeno. Talvez possa haver um ícone em algum lugar para diminuir a tela de inserção. Um clica no ícone menor e o insersor de bloco torna-se pequeno para que se possa focar no padrão que está pensando em usar em relação ao conteúdo do layout.

Eu continuei a maquete de Rich e adicionei Use and Edit e um ícone de cadeado.
Isso significa que o usuário pode editar um padrão ou bloco reutilizável.
A edição não está disponível onde o administrador bloqueou o padrão.
O usuário pode clicar em Usar, Título do padrão ou o próprio padrão para usar / inserir diretamente no layout. Também movi o sublinhado azul para mais perto da área selecionada.

Alternativo.
Use um gir de Configurações para criar um menu suspenso que mostra Editar (se o objeto puder ser editado), em seguida, Importar e Exportar etc.

Clicar em Editar. Área focada apenas para edição de um padrão / bloco reutilizável.

A versão inicial disso está pronta. Ainda há algumas tarefas de acompanhamento aqui (pesquisa, categorias ...). Vou encerrar este problema, pois temos este número 21080 com uma boa lista de acompanhamentos.