Gutenberg: Aprimore as ferramentas para selecionar blocos filho / pai

Eu gosto da ideia do pão ralado. (Na verdade, sugeri algo muito semelhante em # 6459 em abril.) O que aconteceria com a localização atual quando a Barra de Ferramentas Unificada fosse ativada?

Eu também acho que a ideia de click-through também é boa e já é usada em dispositivos móveis, então adiciona consistência. Não estou tão certo sobre a ideia do passthrough, entretanto; Imagino que isso possa causar confusão devido aos diferentes comportamentos entre os blocos.

Eu gosto da localização atual, mas também gosto da barra de ferramentas unificada. Podemos encontrar outra posição para a localização atual :)

Além disso, eu pessoalmente não gosto das bordas ao redor do bloco pai. Mas se os mantivermos, como tratamos a multisseleção :). Devemos mostrar bordas ao redor do pai dos blocos multisselecionados?

Eu gosto da opção click-through. Isso exigirá algum trabalho adicional no bloco de 'passagem' (para que cada "coluna" individual não seja considerada uma camada para clicar, por exemplo), mas acho que faz muito sentido.

O que aconteceria com a localização atual quando a Barra de Ferramentas Unificada estiver ativada?
Eu gosto da localização atual, mas também gosto da barra de ferramentas unificada. Podemos encontrar outra posição para a localização atual :)

Boa pergunta. Maquete rápida e suja:

Sim, vejo o desafio do ícone duplicado para o switcher. Acho bom ficar pensando nisso. Observe também como esse design omite o contorno do documento, que está bloqueado no nº 4287.

Além disso, eu pessoalmente não gosto das bordas ao redor do bloco pai. Mas se os mantivermos, como tratamos a multisseleção :). Devemos mostrar bordas ao redor do pai dos blocos multisselecionados?

Acho que é importante mostrá-los como uma indicação de que os blocos internos fazem parte do grupo pai. Eles _ancor_ os blocos internos.

No momento, é assim que a seleção múltipla funciona:

E isso é o que acontece quando você apenas seleciona dois blocos filhos:

Em outras palavras, no master nós meio que já temos a borda pai, _e_ nós a escondemos quando selecionamos vários blocos filhos. Na verdade, acho que mostrar a borda pai sempre, mesmo na seleção múltipla, faz sentido _quando você está selecionando apenas blocos filhos_. Mas talvez devêssemos tornar a multisseleção diferente quando o bloco _parent_ for multisseleção. Então, em vez de destacar cada bloco filho com efeitos de camada aditivos, nós _apenas_ destacamos o bloco pai. Isso funcionaria?

Eu gosto da opção click-through. Isso exigirá algum trabalho adicional no bloco de 'passagem' (para que cada "coluna" individual não seja considerada uma camada para clicar, por exemplo), mas acho que faz muito sentido.

Sim, agora o bloco filho _column_ está apresentando alguns desafios de IU. Por exemplo, você não pode inserir um bloco antes dele, então por que você pode selecioná-lo? É um desafio técnico extremamente difícil, porém, e eu entendo os desafios que envolve. Portanto, não estou sugerindo que isso seja fácil.

Enquanto eu estava trabalhando em https://github.com/WordPress/gutenberg/pull/9653 , percebi que a navegação por tecla de seta que já apresentamos para navegar na hierarquia (use a tecla de seta para cima quando uma coluna for selecionada para selecionar o pai , ou seja, o bloco de colunas) está funcionando muito bem. Tão bem na verdade, que talvez simplesmente exibir esse recurso como um botão "para cima", semelhante a "ir para a pasta pai" no explorador de arquivos do Windows, poderia ser suficiente em vez de migalhas de pão completas.

Veja como isso poderia parecer. Barra de ferramentas superior:

Barra de ferramentas de bloco:

CC: @youknowriad

Alguns pensamentos

Migalhas de pão

Eu gosto da solução de breadcrumb, mas ela sofre de ambigüidade, uma interface apenas de ícone pode ser problemática e eu posso me ver pairando sobre os ícones para ver o que eles são, ou confundindo os breadcrumbs com uma barra de ferramentas de opções ao invés de breadcrumbs.

Portanto, talvez a barra de ferramentas superior não seja o melhor lugar para mostrá-la e talvez algumas sugestões de migalhas de pão em outro lugar ajudem. Por exemplo, a barra de ferramentas de hierarquia no PHPStorm que mostra o arquivo -> classe -> método / função em que você está atualmente, ou a barra de ferramentas da pasta no MacOS Finder e no Windows Explorer?

Clique através

Clicar seria uma IU oculta, posso ver muitos mal-entendidos e confusão, pois as pessoas esperam selecionar um bloco de imagem apenas para descobrir que o bloco de coluna que o contém está selecionado. Normalmente, clicar na interface do usuário no software Adobe é confuso, pois apresenta modos e é difícil dizer onde você está e como sair dele, especialmente se houver aninhamento. Por exemplo, se você clicar duas vezes para entrar em um bloco filho, como você volta ao bloco pai e como a IU indica que você está dentro de um bloco?

Existem muitas pesquisas e orientações sobre os modos, e algo não deve ser considerado bom porque está presente no Illustrator ou Photoshop, muito mais trabalho precisa ser feito do que apenas clicar antes de se tornar uma solução adequada.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

Isso é ignorar todos os fatores de acessibilidade com os quais isso também mexe.

O botão para cima

A ideia do botão para cima é boa. Minha preocupação seria que isso implica que, se você pressioná-lo, um botão para baixo aparecerá e o bloco se moverá para cima, é ambíguo e sofre os mesmos problemas que o bloco de breadcrumbs

O Padrão de Blocos Reutilizáveis

No momento, os blocos reutilizáveis ​​já têm um padrão de IU que adiciona cromo à interface do bloco que não é visível no front-end. As colunas não poderiam fazer o mesmo?

Ou uma super maquete lixo do que quero dizer

Assim, o cromo do bloco de colunas seria o que seria usado para selecioná-lo e forneceria algo visual para apontar o mouse.

Um possível padrão de UX que poderíamos usar aqui que se encaixaria em nosso modelo de barra de ferramentas é o botão de passagem de pasta do OS X: https://cld.wthms.co/avtQLO

Eu observaria que acho que os usuários esperam poder selecionar blocos filho / pai visualmente por meio de cliques e seleção, mas obviamente há muita complexidade em fazer isso da maneira certa. O padrão de travessia acima pode ser um bom primeiro passo e poderíamos nos aprofundar no desenvolvimento de uma solução mais elegante na fase 2.

Eu _adoro_ esse conceito, Alexis, principalmente pelos blocos mais complexos que você mencionou. Eu amo tanto que imediatamente corri com ele e remixou alguns dos mockups para ilustrar sua ideia.

Nenhuma seleção:

Bloco selecionado:

Bloco aninhado dentro do selecionado:

O popout do botão de passagem de pasta é aberto:

☝️ Estou meio que apaixonado por esse conceito, parece que ele funde todas as ideias e feedbacks compartilhados neste tópico, criando uma linha de base _sólida_ para iterar. Muito obrigado por trazer essa nova perspectiva!

Adoro a lista suspensa com a árvore visual, parte de mim acha que ver o documento inteiro neste formato também seria útil e até mesmo forneceria uma maneira útil de reordenar as coisas.

No entanto, pensando melhor, fui lembrado de que já temos um mecanismo de seleção como este e um esboço do documento no painel de informações:

Isso poderia ser aprimorado com o estilo de sua maquete e servir como um significante de seleção adicional. No momento ele mostra apenas títulos, mas uma versão com uma árvore de bloco completo e um indicador de seleção seria muito útil

Minha única preocupação é com o próprio ícone da barra de ferramentas. é mais um ícone misterioso com uma seta e é um botão que não está no Finder no MacOS por padrão, a menos que você personalize a barra de ferramentas. Para aqueles de nós que não enxergam os ícones e não conseguem distingui-los facilmente, é problemático

Com o rótulo de texto é mais claro, mas sem ele a maioria não saberia o que fazia sem clicar nele:

Parece bom :) Podemos tentar simplificar um pouco o ícone para melhor legibilidade? Talvez 3 linhas com um pouco mais de espaçamento em vez de 4?

Com o rótulo de texto é mais claro, mas sem ele a maioria não saberia o que fazia sem clicar nele.

Haverá uma dica de ferramenta também.

No comentário re: @tomjn , também acho que valeria a pena explorar se isso pudesse ser integrado à árvore geral do documento em vez de criar um local separado. O desafio aí é manter a simplicidade e a capacidade de digitalização da árvore enquanto acomoda muito mais níveis de coisas. Mas talvez isso possa se tornar mais parecido com o painel de camadas no Sketch ou no Photoshop (em funcionalidade, não em design!), Onde é a única fonte de verdade para toda a estrutura da página. Difícil de fazer bem, mas talvez valha a pena explorar?

Novamente, é provável que isso seja algo em que iteramos, então qual é o MVP mais útil que pode se transformar em algo mais sofisticado?

Haverá uma dica de ferramenta também.

Não acho que isso seja suficiente, mas acho que esta é uma discussão separada e uma solicitação de recurso. Vou abrir um novo tíquete

Podemos tentar simplificar um pouco o ícone para melhor legibilidade? Talvez 3 linhas com um pouco mais de espaçamento em vez de 4?

Eu gosto disso:

No entanto, pensando melhor, fui lembrado de que já temos um mecanismo de seleção como este e um esboço do documento no painel de informações:

Também acho que valeria a pena explorar se isso pudesse ser integrado à árvore geral do documento, em vez de criar um local separado.

Acho que pode funcionar. Eu sugeri anteriormente que o item poderia ser reescrito como um plugin para que ele apareça à direita (consulte # 4287). Mas sou um fã de reaproveitar isso para a árvore de documentos.

Em relação a um rótulo, gosto de rótulos, mas a opção de encaixar a barra de ferramentas do bloco na parte superior precisa ser considerada sob essa luz.

Esta discussão me lembra de # 9053 (CC: @westonruter) - Acho que você pode gostar da proposta de Alexis, conforme mostrado em https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989.

Ótimo ver isso evoluindo e obrigado pelo conceito @alexislloyd. @jasmussen Eu realmente gosto dessas simulações e acho que temos um ótimo ponto a partir do qual podemos iterar.

então qual é o MVP mais útil que pode se transformar em algo mais sofisticado?

Eu diria que construir isso como um controle de passagem mais simples e ver mais tarde se faz sentido combinar com a caixa de conteúdo do documento com base na seleção.

De acordo com a discussão em # 10767, reabrindo para iterar.

Veja também ideias adicionais sugeridas em # 11159.

Uma ideia adicional para tornar mais fácil trabalhar com blocos complexos é lembrar que _o bloco não selecionado é uma visualização_, e o _bloco selecionado pode mostrar controles de edição adicionais_.

Podemos alavancar essa ideia para facilitar a seleção dos elementos de um bloco de colunas. Por exemplo, quando um bloco de colunas, ou qualquer filho dele, é selecionado, o preenchimento no contêiner é animado para abrir espaço para selecionar os elementos filho. Isso também tornaria a interface do usuário lateral acessível. Gostaríamos de mostrar uma borda ao redor do bloco pai - aquele com preenchimento expandido - por exemplo, uma linha tracejada.

Parece que seria relativamente trivial implementar, se restaurássemos a classe .is-selected no bloco de nível superior, mesmo quando um filho é selecionado. Fizemos isso usando um suporte hasSelectedInnerBlocks há algum tempo.

Isso é o que vemos quando passamos o mouse sobre uma célula em um bloco de colunas:

Passe o mouse sobre uma célula no bloco Mídia e Texto.

Vê-se o bloco interno e o bloco externo.
Como Coluna -> Parágrafo. Coluna -> YouTube. Mídia e texto -> YouTube

Seria bom tornar clicáveis ​​as informações de breadcrumbs (blocos internos e externos) nas informações de foco. Clique em Coluna para selecionar o pai ou clique em Parágrafo para selecionar o filho.

Tentando fazer isso agora, uma coisa que percebi é que a maneira mais simples de selecionar um bloco de coluna pai é utilizar a área extra invisível que oferecemos à direita / esquerda do bloco pai:

Essa área de acerto adicional não está disponível na parte superior e inferior do bloco, o que torna muito mais difícil selecionar dessa forma.

Uma idéia adicional para tornar mais fácil trabalhar com blocos complexos é lembrar que o bloco não selecionado é uma prévia e o bloco selecionado pode mostrar controles de edição adicionais

Podemos alavancar essa ideia para facilitar a seleção dos elementos de um bloco de colunas. Por exemplo, quando um bloco de colunas, ou qualquer filho dele, é selecionado, o preenchimento no contêiner é animado para abrir espaço para selecionar os elementos filho. Isso também tornaria a interface do usuário lateral acessível. Gostaríamos de mostrar uma borda ao redor do bloco pai - aquele com preenchimento expandido - por exemplo, uma linha tracejada.

Não estou 100% certo se é isso que @jasmussen está sugerindo acima, mas adicionar um pouco de preenchimento + um indicador visual do bloco pai durante o modo de edição pode ser uma grande ajuda aqui. Dessa forma, há uma indicação clara de onde você deve clicar se quiser selecionar o pai:

Quando alguém sai do bloco, esse preenchimento extra pode desaparecer para mostrar uma representação mais precisa do bloco.

Essa área de acerto adicional não está disponível na parte superior e inferior do bloco, o que torna muito mais difícil selecionar dessa forma.

Eu poderia JURAR que havia uma multa em torno desse problema, que está relacionada a como o insersor de irmão funciona também. Não consigo encontrar agora, mas acredito que o problema deve ser corrigido. @aduth disse alguma coisa, posso jurar que você estava nos comentários?

Não estou 100% certo se é isso que @jasmussen está sugerindo acima, mas adicionar um pouco de preenchimento + um indicador visual do bloco pai durante o modo de edição pode ser uma grande ajuda aqui. Dessa forma, há uma indicação clara de onde você deve clicar se quiser selecionar o pai:

Isso é mais ou menos exatamente o que eu quis dizer, só que mais bem visualizado do que eu poderia.

Aqui está um esboço de giz adicional para ilustrar o que quero dizer. Bloco de colunas:

Essencialmente o que você tem, Kjell - talvez com a linha tracejada um pouco mais escura. Além disso, dependendo de como for o desenvolvimento do bloco de colunas, lembre-se de que também existem blocos de _coluna_. Ou seja, a hierarquia atualmente é _Colunas → Coluna → Imagem_. Estamos usando magia CSS feroz para tornar o segundo nível mais ou menos invisível, mas no caso de você querer selecionar isso no futuro para, digamos, aplicar uma classe CSS a ele ou quaisquer outras opções que possamos precisar para colunas individuais, isso é Vale a pena considerar.

Bloco de apresentação de slides:

Para ser claro: nenhum bloco de apresentação de slides está planejado. Isso é puramente rabiscado para ilustrar um ponto em que os modos de visualização e edição de um bloco podem ser _bastamente_ diferentes. É tão fácil e surpreendentemente não perturbador alternar entre os dois modos simplesmente selecionando e desmarcando os blocos, que devemos nos permitir inclinar-nos e ser criativos sobre as oportunidades.

No caso de um bloco de apresentação de slides, quase por definição, o conteúdo ficará invisível fora da tela / bloco. Mas não precisa ser quando você estiver editando. Basta selecionar o bloco para ver as miniaturas com legendas editáveis. Em seguida, desmarque o bloco para visualizar o resultado.

Eu poderia JURAR que havia uma multa em torno desse problema, que está relacionada a como o insersor de irmão funciona também. Não consigo encontrar agora, mas acredito que o problema deve ser corrigido. @aduth disse alguma coisa, posso jurar que você estava nos comentários?

Acho que a coisa mais próxima pode ser # 8883, # 8881, # 5180?

Embora a árvore do documento seja útil, ela ainda exige que eu mude o foco do que estou tentando manipular. Eu realmente gostaria de uma maneira melhor de clicar diretamente nos blocos reais e nos blocos aninhados. Acho que vale a pena explorar mais o método click-through descrito acima por @jasmussen .

Este é o problema que eu normalmente enfrento:

Como usuário, lutarei contra isso por pelo menos um minuto antes de encontrar outra solução localizada em outro lugar na tela. 😉

* _Quando adicionei esse comentário, vários outros comentários apareceram. Pode não ser tão relevante agora, mas estou mantendo-o aqui para documentar a luta._

mas adicionar um pouco de preenchimento + um indicador visual do bloco pai durante o modo de edição pode ser uma grande ajuda aqui. Dessa forma, há uma indicação clara de onde você deve clicar se quiser selecionar o pai:

Minha preocupação com esta solução é como o preenchimento funciona em relação aos blocos circundantes:

1. O preenchimento do bloco principal é refletido no front-end? Ou apenas mais preenchimento no editor?

2. O preenchimento é adicionado dinamicamente quando o bloco é selecionado, como este?

1. Ou talvez o pai acolchoado apareça acima dos blocos ao redor, assim?

Só estou tentando me aprofundar nesse conceito. Adoraria algumas idéias sobre isso.

Obrigado @aduth , você me fez encontrar pelo menos uma passagem que vai na direção certa. O GIF em # 9229 explica o problema: a área amarela nesse GIF é "reservada" para o insersor irmão. Isso é o que está impedindo você de selecionar o bloco clicando no preenchimento acima ou abaixo do bloco. Essa é a resposta ao comentário de @kjellr :

Essa área de acerto adicional não está disponível na parte superior e inferior do bloco, o que torna muito mais difícil selecionar dessa forma.

Para esclarecer ainda mais, essa área amarela existe apenas para tornar o botão de inserção do irmão VISÍVEL. Portanto, tudo o que precisamos interceptar, na verdade, é a ação _hover_. Seria bom se um clique ainda pudesse se propagar por essa barra amarela e permitir que você selecione o bloco abaixo.

Embora a árvore do documento seja útil, ela ainda exige que eu mude o foco do que estou tentando manipular. Eu realmente gostaria de uma maneira melhor de clicar diretamente nos blocos reais e nos blocos aninhados. Acho que vale a pena explorar mais o método click-through descrito acima por @jasmussen .

Você pode realmente testar isso agora, mesmo se a implementação atual estiver um pouco malfeita.

• Execute Gutenberg, qualquer versão.
• Insira um bloco de colunas com conteúdo.
• Redimensione a janela abaixo do ponto de interrupção de 600px e selecione.

Isso é implementado para dispositivos móveis, em outras palavras, para permitir que você selecione o bloco pai com mais facilidade.

GIF:

O problema com a implementação agora é que o "estado" é redefinido assim que você atinge o nível mais profundo. Portanto, é Colunas> Coluna> Parágrafo, Colunas> Coluna> Parágrafo, mesmo que você esteja apenas selecionando o mesmo parágrafo duas vezes. A solução óbvia para esse problema é tentar fazer com que, depois de "aprofundar" no nível desejado, você _fique_ nesse nível até desmarcar o bloqueio novamente. Ou seja, Colunas> Coluna> Parágrafo, Parágrafo, Parágrafo, desmarcar, retroceder, etc.

Também acredito que para _alguns_ blocos, esse método de clique será extremamente importante. Especialmente quando começamos a olhar os modelos de página que podem incluir todos os tipos de conteúdo aninhado.

A inspiração de como o clique pode funcionar quando é incrível também pode ser experimentada no Keynote. Insira algumas formas e você poderá clicar nelas diretamente. Assim que você _grupo_ duas formas, elas se tornam uma nova forma fácil de mover. Mas para editar o conteúdo do grupo, você precisa clicar duas vezes.

Para responder às suas boas perguntas em https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172:

O preenchimento do bloco principal é refletido no front-end? Ou apenas mais preenchimento no editor?

Não, este preenchimento está apenas no editor e apenas quando o _bloco é selecionado_. Isso se baseia no princípio do bloco é a interface , que afirma que no editor:

• um bloco não selecionado é uma prévia. Deve ser o mais parecido possível com o front-end
• um bloco selecionado é essencialmente "modo de edição de bloco", e o bloco pode gerar controles adicionais e até mesmo parecer totalmente diferente neste estado.

Isso é o que eu tentei destacar com o exemplo de doodle de bloco de apresentação de slides acima: quando o bloco de apresentação de slides não está selecionado, é uma apresentação de slides. Quando selecionado, você está no _modo de edição de apresentação de slides_ e vê uma grade de miniaturas de cada slide, para que possa editar legendas, reorganizar, etc.

O preenchimento é adicionado dinamicamente quando o bloco é selecionado, como este?

Sim, mais ou menos.

Acho que vale a pena fazer um protótipo para explicar melhor e ter uma ideia.

Em última análise, esse recurso provavelmente deve ser um suporte no próprio bloco, algo que um bloco pode optar por usar. Um blockquote com parágrafos aninhados, por exemplo, provavelmente não deveria usar esta interface - mas ao editar colunas, pode ser perfeito.

Aqui está um protótipo de codepen rápido: https://codepen.io/joen/pen/exmMQv?editors=1100

É meio estático, mas espero que ele transmita o ponto.

Aqui está um protótipo de codepen rápido: https://codepen.io/joen/pen/exmMQv?editors=1100

É meio estático, mas espero que ele transmita o ponto.

Isso realmente ajuda a entender. Fiz uma pequena edição para que possamos ver como essas bordas tracejadas podem aparecer ao clicar:

https://codepen.io/kjellr/pen/jdEJQb?editors=0110

Isso é perfeito, obrigado Kjell! Isso é exatamente o que quero dizer. Acredito que provavelmente iremos querer ajustar alguns dos aspectos na implementação e abordar como fica quando o pai imediato (coluna singular) é aquele que recebe preenchimento. Mas isso é legal! Acho que pode funcionar.

Eu realmente gosto disso.
Devemos passar a criar um PR para teste com mais blocos e conteúdo?
Precisamos identificar quais bloqueios isso afetará?

Eu também gosto disso.

Provavelmente podemos prototipar isso no bloco de colunas por enquanto, mas para pousar, provavelmente precisaríamos que este _método_ fosse genérico, então outros blocos (como você diz) podem usar isso, mas também um suporte para que um bloco escolha optar por isso. Provavelmente será perturbador para o bloco Quote ter isso, uma vez que recebe blocos aninhados.

@gziolo alguma opinião? Nomeadamente na abordagem desenhada por Kjell em https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415

@gziolo alguma opinião? Notavelmente na abordagem rabiscada por Kjell em # 9628 (comentário)

Parece ótimo. Isso tornaria finalmente possível selecionar facilmente o bloco pai quando necessário. Minha única pergunta é como você se sentiria em tornar a largura da coluna mais próxima do tamanho original ao custo de tornar as outras colunas mais estreitas. No momento, todas as colunas são reduzidas quando uma delas é selecionada, o que pode ser uma experiência abaixo do ideal quando se tem mais de 3 colunas. @jasmussen , você tem alguma outra pergunta, devo responder?

Minha única pergunta é como você se sentiria em tornar a largura da coluna mais próxima do tamanho original ao custo de tornar as outras colunas mais estreitas.

Eu tenderia a concordar que isso é algo que devemos ajustar e equilibrar, provavelmente na implementação. Também podemos expandir a largura / altura do pai, para não reduzir o tamanho do filho, embora isso seja tecnicamente mais desafiador.

você tem alguma outra pergunta, devo responder?

Basicamente, a interface que estamos discutindo aqui é: adicionar preenchimento ao bloco pai quando o bloco filho for selecionado, para torná-lo mais fácil de selecionar . Isso _sente_ bem no protótipo de Kjell para o bloco de colunas. Provavelmente será muito bem-vindo em outros blocos, como blocos de seção ou muitos outros blocos onde o conteúdo filho provavelmente preencherá todo o espaço disponível dentro. Mas provavelmente não seria tão bom para algo como o bloco Quote, que reconhecidamente não usa aninhamento ainda, mas provavelmente o fará no futuro.

Portanto, seria bom construir essa interface selecione o pai de uma maneira que fosse _genérica_ a todos os blocos, _desligada por padrão_, mas algo que um bloco pudesse optar por usar um prop.

Você tem alguma sugestão de como abordar isso da melhor forma?

Todos os blocos que contêm blocos aninhados (colunas, mídia e texto no momento) renderizam este InnerBlocks componente que renderiza .editor-inner-blocks classe:
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
Isso pode ajudar a encontrar uma solução geral que funcione com todos os blocos aninhados. No entanto, pode ser complicado, pois .is-selected é aplicado em um dos elementos descendentes.

Edit: Se não funcionar exclusivamente com CSS. Sempre podemos encontrar uma maneira de atualizar o estado do pai para expor ali a informação de que um dos blocos aninhados está selecionado. @jorgefilipecosta e @aduth podem ter mais insights sobre isso, pois passaram muito tempo com blocos aninhados :)

Portanto, seria bom construir essa interface selecione o pai de uma forma que fosse genérica para todos os blocos, desativada por padrão, mas algo que um bloco pudesse optar por usar um prop.

Quais blocos você considera para esta abordagem que não usam aninhamento? Isso me fez pensar por que eles não estão usando o aninhamento em primeiro lugar? Imagine que convertemos a Galeria em um contêiner com blocos de imagem aninhados. Obteríamos esse comportamento de graça, mas também classificaríamos como um bônus.

Quais blocos você considera para esta abordagem que não usam aninhamento?

A galeria é interessante.

Honestamente, estou pensando principalmente em blocos de layout mais avançados, como blocos de layout de grade ou blocos de Tabgroup ou outros blocos de "criação de página" semelhantes. Qualquer conteúdo específico provavelmente não deve usar esta interface.

Honestamente, estou pensando principalmente em blocos de layout mais avançados, como blocos de layout de grade ou blocos de Tabgroup ou outros blocos de "criação de página" semelhantes. Qualquer conteúdo específico provavelmente não deve usar esta interface.

Eu prevejo que todos eles se encaixam na categoria de blocos de contêiner, o que significa que eles devem usar InnerBlocks como detalhes de implementação, portanto, devem se encaixar nessa categoria. Ainda podemos oferecer opt-out semelhante ao que fazemos para outros recursos com o grupo supports na definição de bloco.

Eu prevejo que todos eles se encaixam na categoria de blocos de contêiner, o que significa que eles devem usar InnerBlocks como detalhes de implementação, portanto, devem se encaixar nesta categoria

Mas o bloco Quote também não usaria blocos internos se / quando recebesse recursos de aninhamento?

Mas o bloco Quote também não usaria blocos internos se / quando recebesse recursos de aninhamento?

Sim, citação, lista, capa - aqueles 3 foram considerados transformados em blocos aninhados no passado.

Uma preocupação (que não deve bloquear a experimentação, mas apenas vale a pena notar!) É que já existem alguns problemas com os blocos de colunas em termos de quão estreitos eles podem ser e como isso afeta as ferramentas do modo de edição. Esta proposta tornará efetivamente as colunas ainda _mais estreitas_ durante a edição de interações, o que poderia ressurgir esses problemas de estreiteza.

Ele também vai além de uma paridade de edição / visualização de 1 para 1, o que pode ou não ser uma preocupação. Reconheço que já faço algo semelhante a isso (preenchimento extra na seleção) em um bloco personalizado com InnerBlocks, e funciona bem - mas significa que a visualização de edição não é muito precisa.

Portanto, seria bom construir essa interface selecione o pai de uma forma que fosse genérica para todos os blocos, desativada por padrão, mas algo que um bloco pudesse optar por usar um prop.

Poder optar por algo como isso teria sido ótimo ao construir o bloco Jetpack Form.

Ele também vai além de uma paridade de edição / visualização de 1 para 1, o que pode ou não ser uma preocupação.

Acho que não há problema em ter algumas mudanças entre os estados selecionados e não selecionados , especialmente se isso estiver melhorando a UX ... embora isso possa ser discutido em relação aos blocos internos agora.

Além disso, o que acontece quando tenho blocos aninhados em 3 profundidades? A opção de preenchimento se estende ao segundo nível se o segundo nível também for um bloco pai?

@mapk

Além disso, o que acontece quando tenho blocos aninhados em 3 profundidades? A opção de preenchimento se estende ao segundo nível se o segundo nível também for um bloco pai?

O preenchimento de todos os níveis de aninhamentos afetados parece que pode acabar causando grandes aumentos e diminuições ao selecionar blocos profundamente aninhados, por exemplo, um parágrafo em uma citação em uma coluna em uma linha em uma seção. Idealmente, a seleção de um bloco não deve alterar drasticamente a aparência de todos os outros blocos, portanto, apenas alterar o espaçamento de seu pai imediato parece suficiente para mim.

Contanto que você possa selecionar o pai imediato, você será capaz de subir na hierarquia, uma vez que selecionar o pai tornará o pai facilmente selecionável e assim por diante. O menu Block Navigation pode ser usado para um acesso mais rápido e, como alguns sugeriram antes, pode ser transformado em uma barra lateral fixável para que possa ser acessado rapidamente. (Consulte # 11408 e # 11688.)

Eu sugeriria que a qualquer momento a mudança de preenchimento deveria afetar SOMENTE o bloco selecionado e descendentes diretos.

Caso isso afete este trabalho, posso rapidamente descobrir que o trabalho que espero realizar para adicionar Alinhamento vertical ao bloco de colunas torna as colunas _individual_ selecionáveis ​​(anteriormente, não eram selecionáveis)

https://github.com/WordPress/gutenberg/pull/13899

o trabalho que espero conseguir para adicionar alinhamento vertical ao bloco de colunas torna as colunas _individual_ selecionáveis ​​(anteriormente, elas não eram selecionáveis)

Obrigado por notar isso aqui. Essa é mais uma razão para organizar essa interação mais cedo ou mais tarde.

Só queria compartilhar algo que discuti com @jasmussen hoje, sobre bordas de bloco.

Isso aparece um pouco em alguns dos modelos acima , mas vale a pena mencionar explicitamente: Além do preenchimento adicionado que estamos discutindo aqui, acho que a navegação + seleção do bloco interno será muito mais fácil se formos claros sobre a estrutura do blocos em geral. Para esse fim, acho que adotar alguns níveis de hierarquia de fronteira seria excelente. Por exemplo:

Neste exemplo, estou usando uma borda escura para o estado de foco. Se o bloco for pai ou filho, incluí uma borda clara pontilhada (bem como algum preenchimento adicional) ao redor dos outros itens relacionados. Isso ajuda os usuários a visualizar claramente onde estão na hierarquia de blocos, ao mesmo tempo que lhes dá uma noção clara de onde podem clicar para selecionar outros blocos aninhados.

@kjellr Eu realmente gosto disso. Isso deixa muito claro qual é a estrutura.

No entanto ... acho que novamente teríamos um problema com contraste na linha pontilhada. Não posso dizer com certeza, mas suspeito que a introdução da linha pontilhada significa que ela precisa seguir critérios de acessibilidade. E acho que aumentar o contraste provavelmente causará algum peso visual que pode anular os benefícios ...

Só estou pensando um pouco alto. Gosto muito da aparência de um usuário com boa visão, mas ficaria curioso para ouvir todos os comentários, pois meu gosto não é suficiente :)

Na minha tela, eu nem mesmo vi a linha pontilhada no início. Parece praticamente invisível se minha tela estiver um pouco inclinada.

Não há necessidade de diminuir tanto o contraste se isso o tornasse menos acessível. Contanto que seja um _pouco_ isqueiro e use um border-style , acho que funcionaria bem.

Desculpe - deveria ter sido mais claro no meu comentário original: Eu criei aquela maquete em apenas alguns minutos enquanto conversava com Joen. Acho que escolhi aleatoriamente a cor de alguns tons de cinza que estavam na minha tela no momento. 😄 Os tons exatos não significam uma solução final, apenas uma abordagem geral.

Em resposta às preocupações sobre a adição de preenchimento ao bloco pai, fazendo com que os blocos internos se tornem inconsistentes com o front-end (# 14148 # 14169), trabalhei em outra ideia.

Isso exigirá mais desenvolvimento, mas pode ser uma boa opção.

Basicamente, ao clicar no bloco pai, ele se expande (fica maior do que os blocos normais) para fornecer o preenchimento necessário para facilitar as seleções filho / pai. Isso mantém o visual dos blocos internos consistente com o frontend.

Screencast

Protótipo InVision

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

PRÓS

1. Os blocos internos permanecem com a largura adequada.
2. Os blocos internos permanecem visualmente consistentes com o frontend.
3. Um bloco selecionado que muda de tamanho é um padrão já usado.

CONTRAS

1. Expandir a seleção de bloco (largura) além das seleções de bloco normais é um novo padrão.
2. Não tenho certeza de como isso funcionará quando os blocos são configurados para largura total.

Basicamente, ao clicar no bloco pai, ele se expande (fica maior do que os blocos normais) para fornecer o preenchimento necessário para facilitar as seleções filho / pai. Isso mantém o visual dos blocos internos consistente com o frontend.

Cave isso. Eu adoraria que a barra de ferramentas de bloco ficasse alinhada com a borda esquerda, mas isso é um detalhe de implementação.

Será um desafio em telas menores quando não puder realmente crescer, mas isso também parece algo solucionável.

Notavelmente, parece que essa abordagem pode ser dimensionada para _qualquer_ bloco que tenha blocos internos, até mesmo o bloco Quote, que é um bloco de texto tão básico que a seleção deve ser o mais desimpedida possível.

Realmente, realmente cave seu trabalho, Kjell - não só poderia funcionar invisivelmente com a ideia de Mark, mas também ajuda a destacar a estrutura do documento, _quando você precisa_, mas não interrompe o fluxo quando você apenas deseja escrever. Parece uma direção sólida, e o que precisamos é de um desenvolvedor forte neste próximo.

Em uma nota de implementação - o pai tracejada _poderia_ teoricamente ter a mesma cor que o bloco selecionado, mas em virtude de ser tracejada, ainda pareceria secundário. Ao pairar o cursor sobre o pai, o contorno pode se tornar sólido, e podemos até mesmo fazer o _criança_ (o que você selecionou ao pairar) ficar pontilhado, para ajudar a indicar o que está para acontecer quando você clicar.

Em uma nota de implementação - o pai tracejada _poderia_ teoricamente ter a mesma cor que o bloco selecionado, mas em virtude de ser tracejada, ainda pareceria secundário. Ao pairar o cursor sobre o pai, o contorno pode se tornar sólido, e podemos até mesmo fazer o _criança_ (o que você selecionou ao pairar) ficar pontilhado, para ajudar a indicar o que está para acontecer quando você clicar.

Sim! Eu acho que poderia funcionar totalmente também. Vamos ver o que acontece com o # 14145 e, a partir daí, descobrir um tratamento. 👍

Também mexi nas bordas quando tornei colunas simples selecionáveis, mas removi como fora do escopo do meu PR. Definitivamente parecia uma melhoria de UX. Amando o jeito que isso está indo!

Apenas um aviso: estou transformando a ideia acima em uma edição separada e concisa para exploração. Acompanhe aqui:

https://github.com/WordPress/gutenberg/issues/14935

Se alguém puder contribuir para adicionar uma classe has-child-selected aos blocos de pais quando seu filho for selecionado, esse é o único bloqueador para começar.

Um problema relacionado que encontrei testando o bloco de grupo recém-introduzido:

O que é confuso no momento é que, quando você insere o bloco de grupo, o que você realmente vê é o bloco de parágrafo:

Podemos pelo menos fazer algo como:

ou o que @mtias sugeriu em nosso chat privado com a reutilização dos bits do recurso Block Navigation:

_Essas não são propostas de design finais de forma alguma 😃_

@gziolo, esse problema deve ser resolvido por # 14241. Eu concordo com você, então seria ótimo enviar esse logo :)

@gziolo, esse problema deve ser resolvido por # 14241. Eu concordo com você, então seria ótimo enviar esse logo :)

Bem, eu diria parcialmente. Quando você insere um parágrafo usando este novo insersor personalizado, estamos de volta à estaca zero 🤷‍♂️

Acho que o # 14935 também vai ajudar aqui. Devemos também explorar algumas opções na barra lateral para ter mais maneiras de garantir que o bloco atualmente selecionado seja aninhado.

Ah sim. Tenho pensado em ressuscitar as migalhas de pão na barra lateral, como fizemos aqui:

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

Simples e relativamente elegante, e também ajudaria neste problema (9628).

Jogando fora uma iteração em algumas das ideias acima:

E se movêssemos as transformações / estilos de bloco em seus próprios itens dedicados e tornássemos o ícone do bloco em seu próprio painel "Árvore de blocos"?

Acho que isso pode aumentar a visibilidade das transformações / estilos de bloco, ao mesmo tempo que ajuda as pessoas a navegar para outros blocos aninhados com um pouco mais de clareza. Aqui está uma maquete de um exemplo mais complicado:

(Ambos os comps também usam os contornos / preenchimento de # 14961)

Isso parece muito interessante, Kjell! Em seguida, seria vinculado à área de navegação do bloco criando consistência entre eles. Conforme se aprende a usar a Navegação em Bloco, o mesmo aprendizado pode continuar selecionando blocos aninhados.

Eu realmente gosto do mockup em um nível conceitual, mas algo sobre a execução parece um pouco denso. Não sei se necessariamente tenho uma ideia melhor, mas me pergunto se há uma maneira de tornar isso um pouco mais leve?

Eu sei que tive dificuldade em encontrar um esboço rápido da minha estrutura de blocos, então este conceito é uma ótima ideia para resolver isso.

Minha preocupação aqui imita a de @chrisvanpatten . Embora seja bem pensado, parece muito.

1. Em alguns blocos em certos contextos, existem várias maneiras de mostrar menus suspensos.

Acho que adicionar outro chevron à mistura (embora seja cinza e voltado para a direita) pode adicionar mais dificuldade de análise.

1. A outra preocupação é que a barra de ferramentas está ficando mais longa. Talvez isso não seja grande coisa, mas pode ser quando incluímos rótulos para os ícones https://github.com/WordPress/gutenberg/issues/10524 e https://github.com/WordPress/gutenberg/issues/ 15311.

Apenas alguns pensamentos para ponderar enquanto explora isso. Essa pode ser a abordagem mais simples que comunica o que está acontecendo.

Eu me pergunto se há uma maneira de tornar isso um pouco mais leve?

Sim, acho que tem algo a ver com a falta de hierarquia lá. O primeiro item da barra de ferramentas deve se parecer um pouco mais com o elemento de aterramento e os outros devem se sentir como opções secundárias para o bloco. É necessário algum tipo de separação. Esta não é a solução certa, mas apenas por uma questão de conversa, acho que isso ajuda um pouco:

Em alguns blocos em certos contextos, existem várias maneiras de mostrar menus suspensos. Acho que adicionar outro chevron à mistura (embora seja cinza e voltado para a direita) pode adicionar mais dificuldade de análise.

Isso pode ser. Provavelmente há outra maneira de representar isso na qual também não estou pensando. Honestamente, poderia até ser um ícone extra de "bloco de árvore" mais direto na barra de ferramentas, adicionado automaticamente para qualquer elemento pai ou filho:

A outra preocupação é que a barra de ferramentas está ficando mais longa. Talvez isso não seja grande coisa, mas pode ser quando incluímos rótulos para os ícones # 10524 e # 15311.

Acordado. Seja esta a direção ou não, precisaremos encontrar uma solução para barras de ferramentas extra longas de qualquer maneira. Acho que esforços como https://github.com/WordPress/gutenberg/pull/16557 ajudam um pouco com isso, assim como repensas mais abrangentes da hierarquia da barra de ferramentas como https://github.com/WordPress/gutenberg/issues/ 15096.

Uma coisa que me impressiona sobre a ideia de uma árvore de blocos como um botão da barra de ferramentas é que ela é única por ser um item da barra de ferramentas de bloco que não se refere a nada intrínseco sobre o próprio bloco, e sim sobre como o bloco se relaciona com o resto do documento.

Isso é mais uma reflexão do que qualquer outra coisa, mas para usar uma analogia de aplicativos gráficos, esse tipo de IU de "camadas" e "agrupamento" normalmente (tenho certeza de que há exemplos que provam que estou errado) existem apenas em um nível de _documento_ em vez de ser acessível no nível do bloco.

Eu sei que existem vários problemas de acessibilidade em torno da "lacuna" entre o bloco e as ferramentas de nível de documento, e tê-lo no nível de bloco pode facilitar a navegação.

Isso é mais uma reflexão do que qualquer outra coisa ... algo sobre esta ferramenta parece muito diferente das outras ferramentas disponíveis na barra de ferramentas em termos de como ela relaciona o bloco a outros contextos.

Isso é mais uma reflexão do que qualquer outra coisa ... algo sobre esta ferramenta parece muito diferente das outras ferramentas disponíveis na barra de ferramentas em termos de como ela relaciona o bloco a outros contextos.

Sim, tenho a mesma sensação.

Temos esse controle na barra de ferramentas superior agora, que parece muito distante do próprio bloco. Talvez a barra lateral seja realmente o melhor lugar para isso? O controle quase parece que deveria ser associado ao bloco, mas como sua própria barra de ferramentas separada, mas definitivamente não queremos adicionar outra dessas. 😄

Temos esse controle na barra de ferramentas superior agora, que parece muito distante do próprio bloco.

Eu também acrescentaria que isso só é verdade nas configurações padrão de Gutenberg. Se alguém tivesse que selecionar a opção Barra de ferramentas superior para mover todas as barras de ferramentas de bloco para a barra de ferramentas superior, definitivamente não seria o caso. Dito isso, duvido que a maioria dos usuários altere essa configuração.

Em outra nota, eu realmente gostaria de ver como as pessoas reagiriam se a configuração da Barra de Ferramentas Superior fosse a configuração padrão em Gutenberg. Ele se alinharia melhor com o editor Clássico, fornecendo mais familiaridade para novos usuários do Gutenberg.

Esta configuração da barra de ferramentas foi muito explorada e o melhor padrão foi definido após alguns testes. Você pode ler mais sobre explorações aqui: https://github.com/WordPress/gutenberg/issues/2983.

Duvido que a maioria dos usuários altere essa configuração.

Acontece que a posição de uma barra de ferramentas é um cenário incrivelmente pessoal. Durante a fase um do teste, aconteceu que aqueles que estavam começando a usar o WordPress preferiam o bloco, aqueles que tinham experiência no topo. A barra de ferramentas foi padronizada em ambos os lugares e isso que temos agora são as melhores opções. Além disso, é provavelmente por isso que parece mais alinhado ao editor clássico. Eu pessoalmente recomendo que não alteremos o padrão.

@jasmussen Devemos encerrar em favor de # 17088

Sim, acho que podemos. Este tíquete foi explorado de maneira divergente, enquanto o outro agora refina algumas das ideias. Este ingresso ainda poderá ser encontrado se você seguir a referência do novo ingresso Obrigado Riad.