Idéia interessante @melchoyce.

Minha primeira reação foi como movê-los para o fundo tornava o bloco mais 'em bloco' - o que é uma coisa estranha de se dizer, mas algo que me faz sentir. A borda é exibida ao clicar ou ao passar o mouse? Acho que tenho menos problemas com ele ao clicar do que ao passar o mouse. Outro visual interessante faz com que pelo menos seus exemplos pareçam uma imagem Polaroid, super interessante como meu cérebro foi para lá.

Essa é minha primeira reação, porém, cavando um pouco mais, acho que há mérito em explorar uma posição diferente para os ícones de interação em um bloco. Acho que o que ela ganhou é absolutamente uma maneira que funciona melhor em todas as telas, que devemos ter como um guia conforme novas explorações acontecem.

Acho que perdemos algum contexto para as interações. Por exemplo, um bloco com um espaço reservado mais alto não teria essas interações diretamente visíveis. Acho que isso será um obstáculo que pode resultar em menos descoberta.

Dito tudo isso, absolutamente não estou dizendo que o que temos agora deve ser o caminho a seguir. Você está pronto para iterar e talvez explorar mais? Eu realmente espero que você esteja.

Eu acho que visualmente isso é bom. É essencialmente a IU móvel, no ponto de interrupção da área de trabalho, e é algo que considerei um plano B se a IU lateral não funcionar ou talvez para contextos aninhados.

Desde então, nós dois progredimos com a interface do usuário lateral, mais recentemente em https://github.com/WordPress/gutenberg/pull/6141 , e conseguimos que funcionasse decentemente bem em contextos aninhados também, embora aspecto ainda precisa de algum amor.

Embora não seja tão bonito, os principais benefícios de ter esta IU ao lado, são,

1. que podem aparecer ao passar o mouse
2. eles não expandem a pegada do bloco

1 é especialmente importante, pois desde o início tem sido uma meta explícita garantir que arrastar e soltar seja _aditivo_, e não a forma primária de interação com a colocação, reordenação e classificação de blocos. Se os colocarmos abaixo do bloco, presumivelmente eles apareceriam ao clicar, o que os tornaria secundários ao arrastar e soltar, o que sempre funcionaria ao pairar.

2 pode ser importante, dependendo de como lidamos com a interface do usuário lateral em contextos aninhados. No momento, estamos enfrentando alguns desafios em https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863 e, embora tenha certeza de que seremos capazes de resolvê-los, o fato de que a pegada não 't mudar ajuda.

Tudo isso não quer dizer "não pode funcionar" - pode muito bem funcionar. Uma maquete muito antiga tinha esta IU como uma sobreposição no canto:

Portanto, em suma, boas ideias, e bom mantê-las no macarrão como caminhos que podem ser explorados dependendo do feedback que recebermos lançamento para lançamento!

A borda é exibida ao clicar ou ao passar o mouse?

Basta clicar. Hover seria semelhante a como funciona agora.

Você está pronto para iterar e talvez explorar mais? Eu realmente espero que você esteja.

Sempre 👍

eles não expandem a pegada do bloco

Sim, definitivamente um problema com essa ideia. Mesmo neste protótipo, você pode ver alguns pulos por causa da mudança de tamanho.

Portanto, em suma, boas ideias, e bom mantê-las no macarrão como caminhos que podem ser explorados dependendo do feedback que recebermos lançamento para lançamento!

👍 👍

Acho que perdemos algum contexto para as interações. Por exemplo, um bloco com um espaço reservado mais alto não teria essas interações diretamente visíveis. Acho que isso será um obstáculo que pode resultar em menos descoberta.

Embora não seja tão bonito, os principais benefícios de ter esta IU ao lado, são,

1. que podem aparecer ao passar o mouse
2. eles não expandem a pegada do bloco

Acho que uma maneira de resolver esses problemas seria fazer com que a barra de ferramentas de blocos apareça no topo dos blocos abaixo e não aumentar o espaço que o bloco realmente ocupa no editor. Quanto à capacidade de descoberta com blocos altos, a barra de ferramentas pode ser fixada de forma que, se você rolar para cima, a barra de ferramentas não saia da tela. (Ele ainda desaparece quando não está pairando sobre o bloco, é claro, e talvez só possa aparecer ao pairar sobre a parte inferior do bloco que está visível no momento, semelhante à forma como os controles laterais funcionam atualmente.) Também pode apenas assumir como tanto espaço quanto necessário para mostrar todos os botões, e não ocupar uma linha inteira de espaço vazio entre 2 conjuntos de controles, como faz na maquete no post principal desta edição.

1 Apenas para observar que isso também pode ajudar a melhorar a ordem das guias dos controles da IU em torno dos blocos. Conforme mencionado em https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531, a IU móvel tem os "controles laterais" colocados de uma forma mais lógica. Veja o GIF animado que ilustra a ordem das guias, você pode comparar com o GIF anterior com a ordem das guias na visualização da área de trabalho em um comentário anterior https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

Também deve ser levado em consideração:

3976 propõe uma terceira opção para colocar a barra de ferramentas de bloco (a barra de ferramentas de formatação) abaixo do bloco; seria ótimo considerar um design com a barra de ferramentas do bloco _e_ os controles laterais colocados abaixo do bloco para ver se isso funcionaria.

1934 como um problema geral sobre a consistência da ordem das guias

Isso também pode ter um impacto na solução de alguns dos problemas levantados em # 6272.

Quanto à capacidade de descoberta com blocos altos, a barra de ferramentas pode ser fixada de forma que, se você rolar para cima, a barra de ferramentas não saia da tela.

Sim, isso é o que também acontece com a barra de ferramentas de formatação superior:

Lendo todos os comentários incríveis aqui, parece que isso resolve uma série de problemas no futuro e hoje com acessibilidade. Com isso em mente, acho que deveríamos trabalhar em algumas iterações aqui e então passar para um protótipo de PR. Você gostaria de fazer isso @melchoyce?

Sim, posso dar outra olhada.

+10 por experimentar isso.

É assim que a IU do bloco se parece quando reduzo a largura da janela do meu navegador. (Se eu reduzi-la um pouco mais, a barra de ferramentas do bloco se moverá abaixo do bloco, mas isso não é relevante para o que estou sugerindo.)

Notei que o insersor de bloco aparece próximo aos controles de movimento para cima / para baixo. Se esse tipo de IU fosse usado para todos os tamanhos de tela como este problema está propondo, talvez o anexador de bloco atual pudesse ser removido dos contextos de bloco aninhados, fazendo com que o editor parecesse mais com o front-end, removendo o espaço extra sempre presente adicionado por cada appender de bloco para cada nível de aninhamento. (Eu também sugeri uma solução alternativa para o problema do appender-eating-up-space no # 6834.)

Além disso, esta é apenas uma observação lateral, mas o botão Remover deveria estar à direita do botão Mais opções ou deveria estar à esquerda? Na maioria dos designs de IU, os menus de reticências são colocados na extremidade direita.

Outra ideia:

Mostrar esses controles de bloco na parte inferior ao passar o mouse, mas neste estado, eles não ocupam nenhum espaço na página e, em vez disso, aparecem no topo de tudo o que está abaixo do bloco focado (assim como a barra de ferramentas de bloco faz para os blocos acima do atual um) ou talvez no topo do bloco pairado. Os controles de bloco na parte inferior também não devem ser uma barra branca ininterrupta ao pairar, mas 2 barras menores de cada lado, semelhantes à barra de ferramentas do bloco, a fim de fazer os controles ocuparem menos espaço e não cobrir tanto.

Quando você selecionaria um bloco, os controles de bloco na parte inferior ocupariam espaço, aumentando a pegada visual do bloco e empurrando os blocos abaixo para fora do caminho, como quando você seleciona um bloco de imagem o marcador de posição da legenda aparece. Isso tornaria mais fácil selecionar o bloco abaixo se fosse um bloco verticalmente curto, como um bloco de parágrafo de linha única.

Esta abordagem permitiria que você mantivesse os benefícios dos controles atuais ao passar o mouse, permitindo que você mova / exclua blocos facilmente sem primeiro selecioná-los, ao mesmo tempo que garante que os controles não encobram nada quando o bloco está sendo editado, tornando-o mais fácil então selecionar um bloco diferente.

Mais uma ideia:

Permita que toda a barra de controles do bloco (e a barra de ferramentas do bloco) funcione como uma alça de arrasto (incluindo os botões, como funcionam as barras de cabeçalho GTK). Eu acho que isso resolveria o problema de descoberta de arrastar e soltar, especialmente no contexto de blocos selecionados, onde a barra de controles inferior parece que faz parte do bloco nas maquetes na postagem inicial e, portanto, os usuários provavelmente é mais provável que pense em tentar usá-lo como uma alça de arrasto.

Compare isso com a situação atual em que os lados do bloco não parecem fazer parte do bloco e, portanto, não é tão óbvio que possam atuar como alças de arrasto, e há também o problema em que o parágrafo de linha única bloqueia dificilmente tem qualquer espaço vazio em seus lados para arrastar. (E como os botões de controle lateral não podem ser usados ​​atualmente como alças de arrasto, a menos que estejam desativados, o problema é ainda pior.)

Muita discussão incrível em torno disso, vamos ver se posso dar algum feedback resumido para, com sorte, dar a vocês algo para mover para a iteração com @melchoyce.

No geral, acho que preciso sentir isso em um protótipo e muitos dos meus pensamentos podem ser facilitados com isso. No entanto, existem algumas considerações que gostaria de trabalhar em uma simulação:

• Uma solução para blocos altos.
• Uma sensação menos 'bloqueada': isso pode ser apenas mostrar os estados do espaço reservado em uma simulação, estou lendo como mais óbvio com essas mudanças.
• Mostrando como isso funciona com aninhamento.

Eu adoraria ver como isso também se adapta a diferentes dispositivos, meu pensamento é que há menos variação e isso pode ser ótimo.

@SuperGeniusZeb alguns pensamentos interessantes que você tem aí. Eu gostaria de ver onde Mel chega com as iterações acima. Acho que dobrar a interface do usuário para arrastar alças é algo que deve ser evitado por enquanto, há mudanças de aninhamento sendo trabalhadas que eu gostaria de fazer. Não estou dizendo que não iteraremos, mas esta IU não é especificamente para isso. Eu também acho que você pode inferir a pertença sem ser explícito visualmente e onde se torna muito explícito é onde o sentimento negativo de bloqueios entra - parece próximo e muito limitador.

Eu estava pensando em # 7211 e no contexto desse trabalho descobri # 7646, e isso me trouxe de volta a essa ideia, que realmente parece ser a melhor solução para um monte de problemas.

Este tíquete iria, direta ou indiretamente, consertar um monte de coisas:

• # 7646 → com os controles posicionados acima / abaixo, você não precisa se preocupar em acomodar a IU lateral
• # 7182 → controles como os das maquetes neste tíquete são conectados diretamente ao bloco e teriam uma interface do usuário consistente, independentemente do nível de aninhamento
• # 6451 → se as barras de ferramentas superior / inferior tiverem um fundo sólido, você não precisa se preocupar em descobrir como tornar os controles visíveis em fundos escuros
• # 7114 / # 6265 → Se você usar uma barra de ferramentas de largura total como em alguns dos modelos acima, você pode usar a área vazia para arrastar / soltar

Tudo isso para dizer que, se ainda houver uma chance de uma mudança tão grande acontecer em Gutenberg, acho que pode resolver muitos problemas e tornar muitas coisas mais fáceis :) Vou me divertir e trabalhar alguns modelos / conceitos, espero que neste fim de semana.

@chrisvanpatten apenas para adicionar perspectiva, esse problema é sobre os controles, não a barra de ferramentas, sendo movida para a parte inferior. Isso causaria muito mais problemas de usabilidade. Apenas verificando como alguns problemas que você vincula parecem estar em torno das barras de ferramentas.

Eu seria totalmente a favor de tentar isso, pois melhora muito a ordem das guias. Uma atualização rápida: o botão remover "lixo" foi movido dentro do menu de reticências. Também sugiro tentar atender ao princípio de proximidade dos controles e colocar o botão de reticências imediatamente à direita dos movimentadores. Não sei por que deveria ficar tão longe à direita:

@afercia como são controles diferentes, acho que fazer reticências à direita faz sentido. Vamos explorar isso como um passo. Precisamos nos concentrar em explorar o seguinte:

Uma solução para blocos altos.
Uma sensação menos 'bloqueada': isso pode ser apenas mostrar os estados do espaço reservado em uma simulação, estou lendo como mais óbvio com essas mudanças.
Mostrando como isso funciona com aninhamento.

Esses pontos precisam ser explorados para determinar a rota a partir desse ponto promissor.

@karmatosed Eu estava usando uma linguagem confusa - eu quis dizer controles, não barras de ferramentas. As barras de ferramentas já estão no topo - nada para mudar lá :)

Acabei de fazer alguns modelos de como eu imagino que as ferramentas de bloco ficariam se colocadas sob o bloco. Observe que, nessas maquetes, as ferramentas de bloco nunca ocupam espaço, agindo apenas como sobreposições, como as barras de ferramentas de bloco na área de trabalho. Os blocos também são selecionados nessas maquetes. Se apenas pairasse sobre um bloco, as barras de ferramentas do bloco no topo não seriam mostradas. Além disso, lembre-se de que os controles da parte inferior ainda podem aparecer apenas quando você passa o mouse perto deles, como os controles laterais atuais.

Normal:

Quando a parte inferior de um bloco está fora da tela:

(Nota lateral: a barra de ferramentas do bloco de imagens não corresponde àquela dessas maquetes, pois tem opções diferentes em sua barra de ferramentas de bloco.)

Dados os problemas com as ferramentas de bloco nas laterais e os vários benefícios de tê-las na parte inferior, agora estou convencido de que tê-las na parte inferior é o caminho a percorrer.

@SuperGeniusZeb Isso é basicamente exatamente o que eu estava pensando, exceto que iria posicionar o botão de mais opções com a seta para cima / para baixo em vez de para a direita, como uma barra de ferramentas combinada.

@chrisvanpatten Sim, eu não me importaria de qualquer maneira se os controles fossem separados ou não.

Aqui estão mais alguns modelos:

Flutuar:

Selecionado com uma barra de largura total que ocupa espaço (em vez de ser apenas uma sobreposição) como no celular e pode funcionar como uma alça de arrasto:

Eu tenho que dizer que acho que corremos o risco de isso ficar muito bloqueado ... essa é uma maneira estranha de descrever isso, mas continuar :) Por exemplo, o foco mostrado na última simulação é bastante intenso. Acho que temos que ver isso ir mais para o que Mel mostrou na primeira imagem que tem uma borda a menos e realmente ajuda não ter isso.

Eu fiz as primeiras simulações e removi a lata de lixo para conseguir o que acho que seria melhor para o progresso:

Não precisamos das bordas extras e não precisamos do peso adicionado. Desta forma, permite arrastar facilmente sem os contornos flutuantes incomuns.

@karmatosed Modifiquei sua maquete para mostrar como ficaria quando você

E aqui está com o bloco selecionado e a barra de ferramentas do bloco exibida:

(Eu também atualizei o espaço reservado para o bloco de imagens para corresponder ao atual em Gutenberg.)

Algo que me confunde por não haver borda superior nos controles: os controles ainda estão com um fundo branco? Isso significa que todo o bloco tem um fundo branco atrás dele? Parece que isso causaria problemas em contextos aninhados em que um bloco é aninhado em um contêiner com um fundo escuro, pois selecionar (e / ou pairar) faria com que o fundo do bloco mudasse, o que pareceria bastante chocante.

Algo que me confunde por não haver borda superior nos controles: os controles ainda estão com um fundo branco? Isso significa que todo o bloco tem um fundo branco atrás dele?

Sim, mas os controles têm alvos. Acho que vale a pena mostrar e evita o bloqueio visual sem problemas. Isso absolutamente precisa ser explorado no aninhamento, no entanto, sem o fundo ficaria ainda pior no aninhamento visualmente.

Sim, mas os controles têm alvos. Acho que vale a pena mostrar e evita o bloqueio visual sem problemas. Isso absolutamente precisa ser explorado no aninhamento, no entanto, sem o fundo ficaria ainda pior no aninhamento visualmente.

Concordo, e ter o fundo também resolve # 6451.

Eu não gosto de ter aquela grande barra vazia mostrada pairando nas últimas maquetes. O ideal é cobrir o mínimo possível dos blocos ao redor ao pairar, mas isso cobre grande parte do bloco abaixo. Que tal algo como isso?

Como sugerido antes, os deslocadores de seta e reticências podem funcionar como alças de arrastar e / ou o título flutuante pode ser uma alça de arrastar. (Veja # 7114.)

@SuperGeniusZeb embora eu entenda seus pontos, neste caso, ter os blocos delineados realmente não é muito bom visualmente. Vamos continuar com o mock que fiz com base no trabalho incrível de Mel para vê-lo em protótipo.

Algo que acabei de perceber sobre ter um fundo branco aparecendo atrás dos blocos selecionados: e os blocos com uma cor de texto branca (ou de outra cor clara) que devem ser vistos em uma área escura (fornecida por algo como o bloco Container)? Ter um fundo branco para todo o bloco não funcionaria neste caso.

O fundo está ao redor da barra de ferramentas que sempre terá esses controles.

@SuperGeniusZeb Sim, não vejo o fundo branco impactando o próprio bloco, apenas os controles. Praticamente poderia ser algo assim:

Ou o preenchimento poderia ser removido (eu realmente gosto dessa abordagem, mas é obviamente uma questão maior que tem implicações com arrastar e soltar. Ainda acho que vale a pena considerar):

@chrisvanpatten Eu gosto dessa última maquete. Não acho que arrastar e soltar seria um problema, já que a barra inferior poderia ser uma alça de arrastar (e, potencialmente, os botões na barra também funcionariam como um). Você pode até adicionar um ícone de alça de arrastar à barra inferior ao pairar ou apenas ter um lá para indicar que você pode arrastar o bloco usando-o.

Com essa abordagem, não vejo razão para manter a área arrastável perto das bordas do bloco. A remoção desse preenchimento também pode ajudar a fazer os contornos do bloco pairando / selecionados ficarem mais próximos das bordas reais do bloco, uma vez que eles não teriam mais que levar em consideração o espaço de arrasto e apenas teriam que ajustar para ser maior do que o bloco real em casos de aninhamento para facilitar a seleção de blocos pai. (Selecionar blocos pais seria menos problemático se coisas como a maquete neste comentário em # 6459 fossem implementadas.)

@SuperGeniusZeb

Você pode até adicionar um ícone de alça de arrastar à barra inferior ao pairar ou apenas ter um lá para indicar que você pode arrastar o bloco usando-o.

Ótima ideia 💡

Acho que vamos deixar a área arrastável de lado e implementar isso. É importante se concentrar em resolver primeiro o que isso está resolvendo. Devo dizer que não tenho certeza se um ícone é a abordagem certa, isso diz, vamos revisitar assim que tivermos implementado sem isso.

@karmatosed

Acho que vamos deixar a área arrastável de lado e implementar isso.

Não tenho certeza do que isso significa. Qual lado?

Fico feliz em ver que isso vai acontecer. Apenas um rápido lembrete de que não se trata apenas de posicionamento visual. Para a11y, a ordem visual e a ordem das guias (ordem DOM) devem corresponder, de modo que essas "ferramentas de bloco" devem realmente ser movidas após a área editável do bloco na marcação.

Um bom benefício de alternar para os controles abaixo do bloco é que abre o espaço lateral para permitir que o insersor irmão seja redesenhado para algo como os do Squarespace se o design atual tiver problemas. Os controles laterais atuais teriam se sobreposto a esse tipo de insersor e ficariam desorganizados, mas com os controles movidos para a parte inferior, isso não é mais um problema.

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-points

Acabei de comentar sobre isso em # 7500. Eu estava me perguntando como os parágrafos sucessivos ficariam com este design? Acho que ter a barra na parte inferior resultaria em um grande intervalo entre os parágrafos.

@talldan Citando-me de # 7500:

Os controles de bloco não ocupariam espaço ao pairar (assim como eles e a barra de ferramentas do bloco não ocupam espaço agora) e, pelo que eu posso dizer, ainda não está decidido se eles ocuparão espaço em um bloco selecionado. E, claro, os controles seriam mostrados apenas para blocos que estão selecionados ou sobre os quais o mouse está passando. A distância padrão entre os blocos não deve ser afetada pela mudança; apenas o bloco selecionado pode ser afetado.

Parece muito bom, sou totalmente a favor.

Uma coisa a considerar nisso que não tínhamos antes. E quanto a blocos longos? O que acontece com eles e a parte inferior da tela do editor com blocos?

Você quer dizer quando o bloco é tão longo que sai de vista? Eu diria que antes que isso aconteça, as pessoas terão visto como funciona e saberão onde encontrá-lo. Teríamos apenas que testar se isso fica irritante se você escrever muitos parágrafos longos em uma tela minúscula. Mas eu gosto que espelha melhor a experiência móvel. Que preocupações você tem com o último bloco de uma postagem?

Como eles veriam se o primeiro bloco era realmente longo?

Devíamos pelo menos adicionar uma dica NUX sobre isso;) mas o que você está preocupado é o caso de alguém abrir uma postagem existente que talvez seja um parágrafo longo ou não tenha convertido em blocos corretamente? É possível ... Se eles começarem uma nova postagem, quase certamente verão no primeiro bloco de espaço reservado, certo?

Pensando nisso, não vejo uma exploração aqui de colocar os controles no topo do bloco, o que poderia ser uma opção. Fiz uma maquete rápida para isso. ( Combinar as barras também é mencionado aqui )

Se um bloco for muito alto, os controles inferiores não ficarão presos na parte inferior da tela, como a forma como os controles superiores ficam presos na parte superior ou como funciona no celular?

@hedgefield Gosto muito disso, mas não funciona bem em contextos estreitos (como um bloco de colunas) ou com barras de ferramentas longas.

@hedgefield @chrisvanpatten Talvez os controles de seta / reticências possam se mover para baixo (ou para cima) dos controles de formatação em casos de larguras mais finas?

@karmatosed, eu diria que os controles podem ser pegajosos e permanecer visíveis na parte inferior da tela. No entanto, isso causa o problema dos controles cobrindo a linha que você está tentando escrever em um parágrafo toda vez que começa a escrever (presumivelmente, eles ficariam ocultos durante a digitação, como funciona agora). Mas de qualquer maneira essa solução parece questionável.

Voltando ao mockup de @hedgefield , no entanto, isso poderia permitir que os controles fossem atrapalhar . Claro, a barra de ferramentas teria que ser responsiva e os movedores de setas e reticências deveriam se mover para baixo / acima / em algum lugar para blocos finos.

Existe também a preocupação com a acessibilidade. O mockup de @hedgefield tem todos os controles que vêm antes do bloco visualmente. Idealmente, eles deveriam vir após o bloco na marcação. Teoricamente, você poderia usar CSS para permitir que os controles venham após o bloco na marcação, mas apareçam visualmente acima dele. No entanto, não tenho certeza de como isso é difícil de implementar na prática e não sei se uma inconsistência entre a aparência visual e a ordem da fonte deve acontecer. Eu pessoalmente não me importo com isso, já que ter todos os controles de bloco aparecendo após o bloco na marcação torna a localização dos controles por meio do teclado muito mais intuitiva, já que você pode avançar para eles em vez de ter que voltar.

e eu não sei se uma inconsistência entre a aparência visual e a ordem da fonte deve acontecer é desejável

Não é desejável que haja um Critério de Sucesso WCAG específico para isso:
https://www.w3.org/TR/WCAG21/#focus -order

Eu diria que os controles podem ser pegajosos e permanecer visíveis na parte inferior da tela. No entanto, isso causa o problema dos controles cobrindo a linha que você está tentando escrever em um parágrafo toda vez que começa a escrever (presumivelmente, eles ficariam ocultos durante a digitação, como funciona agora). Mas de qualquer maneira essa solução parece questionável.

Na verdade, pensando mais um pouco, os controles não cobririam a última linha de um parágrafo, a menos que o parágrafo estivesse bem próximo à parte inferior da tela, então # 353 poderia tornar isso um problema. E mesmo sem o # 353, você ainda pode rolar para baixo (que é o que a maioria das pessoas faz de qualquer maneira) e, como mencionado antes, os controles também só apareceriam quando você movesse o mouse. Eu mudei de idéia. Isso pode funcionar!

Qual seria a aparência de blocos largos:

Qual seria a aparência de blocos finos:

Mesmo blocos mais finos (pense em 8 colunas ou algo assim):

Acho que estou realmente começando a gostar desse design. Para blocos mais largos, não tenho certeza se os controles de movimentação de seta devem ir para a esquerda dos controles de formatação ou para a direita, no entanto.

Obrigado pelas explorações, no entanto, combinar tudo em uma linha é mesclar diferentes ações em um só lugar. Não tenho certeza se isso faz sentido. Também consideramos o que acontece quando alguém coloca uma barra de ferramentas no topo - eles estão optando por não ter algo 'no lugar' e agora os controles estão. Isso parece menos do que experiência, pois não podemos ter controles de bloqueio na barra de ferramentas - isso seria muito estranho de experimentar.

entretanto, combinar tudo em uma linha é mesclar diferentes ações em um só lugar.

Brincar de advogado do diabo não é, por definição, o propósito de uma barra de ferramentas?

Para adicionar mais, embora eu possa entender a ideia por trás da separação de certos controles, não tenho certeza se há um argumento convincente o suficiente para isso neste caso. Uma barra de ferramentas é uma barra de ferramentas; colocar todos os controles de um determinado bloco em um local faz sentido lógico, em vez de apresentar razões confusas de por que certas ferramentas pertencem a determinados locais, enquanto outras ferramentas pertencem a outros locais que os plug-ins inevitavelmente ignorarão de qualquer maneira.

@karmatosed Que tal separar os controles por cores?

@SuperGeniusZeb infelizmente isso não resolve meus outros pontos não e não tenho certeza se funciona.

Eu realmente acho que neste caso é o caso de tentar encaixar um design que funcione em vez de encontrar aquele que funcionará. Que tal dar um passo para trás e considerar os outros pontos que levantei?

@chrisvanpatten uma barra de ferramentas não é, por definição, um lugar para colocar tudo; para ser útil, uma barra de ferramentas precisa ter contexto e ordem. Você deve, como usuário, esperar que haja as opções certas. Embora possamos debater o significado de uma palavra no singular por um tempo - é divertido fazer isso - não podemos perder de vista o fato de que combina muitas coisas de uma vez e seria um problema para mais pessoas.

@karmatosed Ok então. Vamos voltar a ter a barra de ferramentas de edição no topo:

(Não tenho certeza se a linha azul acima da barra deve estar lá ou não.)

Há algo de errado com este design? A barra de ferramentas de edição pode aparecer após o bloco na ordem de origem para acessibilidade; não é o ideal, mas como colocar a barra de ferramentas de edição abaixo do bloco não parece ser uma opção viável, parece ser a única coisa que podemos fazer.

Além disso, acabei de ter uma ideia: e se a barra na parte inferior ficasse parcialmente transparente ao passar o mouse? Isso faria com que parecesse mais leve?

@SuperGeniusZeb apenas para obter visualizações, posso sugerir que façamos simulações menos coloridas? Eu entendo o que está sendo sugerido, mas deixar a interface independente seria mais fácil sem a complexidade visual.

Apenas para obter o próximo passo simulado. @SuperGeniusZeb como item acima no contexto de uma tela (tamanho normal da área de trabalho) e um bloco muito longo? Como fica também com um bloco bem embaixo? O ideal é estacionar um pouco a transparência e considerar meu comentário sobre focar na interface do usuário, não nas cores desta vez, isso deve nos ajudar a avaliar.

Alguns modelos:

Com borda no topo da barra de controle

Sem borda no topo da barra de controles

Observe que a barra de ferramentas não ocupa nenhum espaço ao passar o mouse, mas ocupa quando o bloco é selecionado.

Ao fazer essas maquetes, percebi algo: o que deve ser feito em situações como essa?

Há um conflito aqui entre mostrar a barra de ferramentas de formatação do bloco selecionado e os controles inferiores do bloco em foco. Se a barra de ferramentas de formatação estivesse na parte inferior (ou se os controles de bloco estivessem todos na parte superior), isso não seria um problema, mas aqui a combinação dos controles mostrados abaixo e os controles mostrados acima dos blocos cria um problema.

A melhor solução que posso pensar seria fazer com que o bloco em foco e sua barra de ferramentas tenham um índice z maior e apareçam no topo do bloco abaixo e sua barra de ferramentas de formatação. Não tenho certeza se essa é a abordagem certa, no entanto. Aqui está uma maquete de como seria:

E, novamente, sem a fronteira entre a barra inferior e o conteúdo do bloco:

Eu realmente não gosto da ideia do bloco pairado sobrepondo-se ao selecionado, mas caso contrário, não vejo nenhuma maneira de usar as barras inferiores dos blocos pairados diretamente acima dos selecionados. Tem certeza de que não seria melhor apenas ter todos os controles em uma única barra na parte superior ou inferior, pelo menos no desktop? Certamente evitaria problemas como este.

@SuperGeniusZeb De alguma forma, eu não tinha percebido essas maquetes. Obrigado por fazê-los!

Esse é um ponto muito bom que eu não tinha pensado (pairando sobre o bloco acima do bloco selecionado). Isso é definitivamente um problema. Como especialista em construtor de páginas residente, existem outros padrões semelhantes em outros construtores de páginas, com barras de ferramentas em camadas como esta?

Além disso, pelo que vale a pena, acho que as barras de ferramentas devem estar sempre pairando, selecionadas ou não. Tê-lo _às vezes_ ocupando espaço levará a um conteúdo instável, o que é uma experiência geral mais estranha.

@chrisvanpatten Todos os construtores de página que eu vi têm apenas controles (exceto talvez um insersor irmão) mostrado na parte superior de um módulo / widget. Divi é um dos melhores exemplos, na minha opinião:

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

Não exibida no vídeo, a barra de ferramentas de formatação no Divi aparece quando você clica no texto em um módulo e aparece em um pequeno pop-up acima da linha que você está escrevendo.

Elementor faz quase a mesma coisa.

No Beaver Builder, clicar no texto em um widget fará com que a barra de ferramentas de controles de bloco seja substituída pela barra de ferramentas de formatação até que o mouse se mova para fora das bordas do widget, o que fará com que os controles de bloco padrão apareçam na próxima vez que você passar o mouse sobre o widget , embora você ainda possa digitar no widget. Clicar no texto novamente fará com que a barra de ferramentas de formatação substitua a barra de ferramentas padrão novamente.

Além disso, pelo que vale a pena, acho que as barras de ferramentas devem estar sempre pairando, selecionadas ou não. Às vezes, ocupar espaço pode levar a um conteúdo instável, o que é uma experiência geral mais estranha.

É verdade, mas me preocupo com as implicações que isso tem para ter uma IU limpa. Se você tiver a barra de ferramentas de formatação sobrepondo parte do conteúdo acima, tudo bem. Mas então, se você adicionar uma barra de largura total na parte inferior do bloco, agora você estará sobrepondo muitos outros conteúdos.

Idealmente, você deseja que todos os controles estejam na parte superior ou inferior do bloco. Isso evitaria que as barras de ferramentas se sobreponham na maioria dos casos. Por razões de acessibilidade, colocar os controles na parte inferior seria o ideal. No entanto, você pode encontrar problemas em que as barras de ferramentas se sobreponham ao conteúdo que você está escrevendo em algo como um bloco de parágrafo. Deve-se notar, no entanto, que apenas a barra de ferramentas de formatação é realmente necessária para estar visível o tempo todo, uma vez que os movimentos de seta e reticências não são algo que seria usado com tanta freqüência. Além disso, se a parte do conteúdo de um bloco que está sendo editado no momento for mantida longe o suficiente da parte inferior da tela, a barra de ferramentas de formatação não terá que se sobrepor.

Se colocar os controles na parte inferior parece muito estranho, então parece que a próxima melhor opção é colocá-los todos na parte superior. Claro, existe o problema potencial de os controles parecerem estranhos para blocos finos.

Em casos de desktop versus celular, geralmente você pode se safar mudando a posição das barras de ferramentas. No momento, a barra de ferramentas de formatação e outros controles são mostrados abaixo do bloco atualmente selecionado e ocupam espaço no celular.

Em casos de blocos largos versus blocos finos, no entanto, mover os controles para os blocos mais finos pode parecer estranho. A aparência mais consistente pode ser ter a barra de ferramentas de formatação na parte superior e os outros controles na parte inferior. Mas isso nos traz de volta à questão das barras de ferramentas sobrepostas e o aumento da quantidade de sobreposição de conteúdo.

Gutenberg foi projetado em torno da ideia de que a aparência do bloco selecionado é otimizada para edição, então eu acho que ter as barras de ferramentas ocupando espaço físico não é tão ruim, contanto que você faça com que a seleção do bloco apenas mova coisas ao redor do bloco, e não mova o próprio bloco selecionado.

No final, acho que essas maquetes ainda são uma boa opção. Não é perfeito, mas faz sentido do ponto de vista da acessibilidade, não parece muito estranho, é consistente com dispositivos móveis e raramente deve resultar em barras de ferramentas sobrepostas.

Algumas notas sobre como isso funcionaria:

Os controles não ocupam espaço ao pairar, mas ocupam espaço quando o bloco é selecionado. Ao passar o mouse sobre um bloco, apenas as setas e reticências são mostradas, mas a seleção do bloco faz com que a barra de ferramentas de formatação apareça, o que empurra os outros controles para baixo. Este é provavelmente o maior problema com este design. Eu acho que para tornar este trabalho melhor, você gostaria que o conteúdo do bloco fosse empurrado para cima ao selecionar um bloco clicando na barra de ferramentas de movers / reticências, mas você gostaria que as barras de ferramentas se movessem se você selecionasse o bloco clicando na área de conteúdo.

Quando um bloco se estende abaixo da área de conteúdo, as setas moventes e reticências ficarão fora da tela, mas a barra de ferramentas de formatação permanecerá visível, colada na parte inferior da tela (ou área do editor de conteúdo).

Se esta não for a melhor solução, então eu optaria basicamente pela mesma coisa, mas com os controles todos na parte superior, com os movers / ellipsis aparecendo acima da barra de ferramentas de formatação para blocos finos, e talvez à esquerda dos controles de formatação para blocos largos. O celular ainda pode ter a aparência que tem agora.

Outro pensamento: você poderia se livrar do problema de deslocamento dos controles e do problema das barras de ferramentas que se sobrepõem, se simplesmente não mostrasse nenhum controle ao pairar. Isso tornaria a exibição de barras de ferramentas na parte superior e inferior dos blocos muito menos problemática. Mas é claro, você perde os benefícios de ter os controles mostrados ao pairar. Não tenho certeza se essa é a direção que alguém deseja seguir, mas estou começando a me perguntar se é necessário.

Devo dizer que a ideia da sobreposição do bloco pairado também não é algo que eu goste. Isso precisa de um pouco mais de reflexão, eu acho. A ideia de controles ocupando um espaço diferente potencialmente durante o pairar parece um pouco estranha.

Os controles não ocupam espaço ao pairar, mas ocupam espaço quando o bloco é selecionado. Ao passar o mouse sobre um bloco, apenas as setas e reticências são mostradas, mas a seleção do bloco faz com que a barra de ferramentas de formatação apareça, o que empurra os outros controles para baixo. Este é provavelmente o maior problema com este design.

Eu acho que este é um grande problema com os mocks. O que mais pode acontecer?

Embora olhar para os construtores de páginas seja um aspecto, o que dizer de outros aplicativos e produtos? Isso está resolvido em outro lugar?

@karmatosed

Embora olhar para os construtores de páginas seja um aspecto, o que dizer de outros aplicativos e produtos? Isso está resolvido em outro lugar?

Tentar encontrar exemplos análogos de IU que Gutenberg pudesse usar é difícil, porque quase nada precisa ser responsável por todas as coisas que Gutenberg faz.

Muitos plug-ins construtores de páginas mais simples / antigos não precisam se preocupar em encobrir o conteúdo de seu equivalente de um bloco, porque toda a edição de conteúdo é feita em um modal ou barra lateral. Isso os libera para permitir que seus controles de módulo se sobreponham ao conteúdo.

Mesmo em casos como Divi ou Beaver Builder, onde você pode editar o texto sem abrir um modal / barra lateral, o modal / barra lateral ainda é a principal forma de edição. Divi e Beaver Builder mostram o que é essencialmente uma réplica perfeita do front-end, sem ter que se preocupar em ter que otimizar coisas como usá-los como um editor de texto ou garantir que a maior parte do conteúdo do bloco principal possa ser editado inline em o bloco.

Além disso, tanto em construtores de página quanto em outras IUs do tipo construtor, o aninhamento tende a ser muito menos problemático devido às restrições sobre o que pode ser aninhado. Divi tem uma seção → Linha estrita (com colunas incorporadas) → Configuração do módulo (embora com algumas Seções de especialidade criadas para algumas situações de coluna aninhadas comuns). O Beaver Builder permite apenas que colunas sejam aninhadas em colunas, assim como o Elementor. Eles controlam o único tipo de objeto que pode ter várias camadas de aninhamento. Tudo está em uma seção com uma única linha por padrão. Não há camadas ilimitadas de blocos aninhados com potencial para qualquer combinação de blocos personalizados que usam aninhamento para vários fins e vários estilos, como o que Gutenberg permite.

Divi pode codificar com cores seus controles para seções, linhas e módulos porque tem uma estrutura rígida e não pode haver nenhum módulo personalizado que atue em uma seção ou linha. (Isso também permite que ele mostre vários botões de inserção na mesma linha, mas com cores diferentes para distinguir o que cada um fará.) Na maioria dos construtores, os módulos são separados dos elementos de layout. O Beaver Builder pode fazer coisas semelhantes devido à separação de módulos e elementos de layout.

Se você olhar para coisas que não são construtores de páginas, como editores de texto, poderá ver que eles não precisam se preocupar com todas as coisas com as quais os construtores de páginas precisam lidar. Se você observar a maioria dos construtores de páginas, eles não lidam com o material do editor de texto por meio de controles WYSIWYG embutidos diretos.

O que Gutenberg está tentando fazer é único. Ele está tentando ser um construtor de páginas WYSIWYG-exceto-para-o-bloco-selecionado-que-é-otimizado-para-edição que também é um editor textual completo, e tudo, desde seções a colunas e widgets são todos do mesmo tipo de objeto: blocos.

Basicamente, esta é uma questão complicada porque Gutenberg está tentando fazer várias coisas diferentes ao mesmo tempo que aparentemente nada mais tenta fazer. : stick_out_tongue:

De qualquer forma, aqui está uma lista de coisas que podem ser examinadas para ver como lidam com a IU do bloco / módulo / widget:

Plugins / temas WordPress

• Avada (Fusion Builder)
• BeTheme (Construtor de Muffin)
• Beaver Builder
• Divi (Divi Builder)
• Elementor
• Oxigênio
• SiteOrigin Page Builder
• Thrive Architect
• Visual Composer
• X & Pro da Themeco

Construtores de sites fora do WordPress

• Drupal
• Squarespace
• Weebly
• Wix

Coisas que não são construtores de páginas, mas são semelhantes a um

• MailChimp
• Noção

Isso é tudo que eu sei agora.

Há um problema com o insersor irmão: ele sempre se sobrepõe ao conteúdo do bloco selecionado. Este problema fica ainda pior quando você tenta se livrar de coisas como as margens automáticas em cada bloco para tornar Gutenberg mais WYSIWYG.

A solução? Bem, se vamos adicionar uma barra na parte inferior dos blocos, por que não simplesmente jogar o insersor irmão nessa barra também?

Além disso, acabei de descobrir uma maneira de fazer a borda da variante pairada parecer um pouco menos chocante. Basta mudar a cor da borda que divide o conteúdo do bloco da barra inferior!

Os benefícios incluem:

• O insersor irmão nunca se sobrepõe ao conteúdo do bloco selecionado. Isso significa que agora não deve haver nenhuma IU que jamais se sobreponha ao conteúdo do bloco selecionado, exceto para a barra de ferramentas de formatação fixa, que não cobre o conteúdo se você apenas rolar para cima ou estiver apenas digitando sem mover o mouse.
• O insersor irmão agora aparece na mesma ordem que a ordem da guia HTML, o que é bom para acessibilidade.
• O insersor irmão agora aparece abaixo dos blocos em vez de acima. Isso faz mais sentido, na minha opinião.
• O insersor irmão está sempre visível para o bloco selecionado (exceto talvez ao digitar, se os controles ainda estiverem invisíveis como estão agora)
• Consistência com a interface do usuário móvel.
• Todas as margens e preenchimento interno dos blocos podem ser removidos e as bordas do bloco podem ser alteradas de volta para o tamanho real do bloco, tudo sem que a IU do bloco atrapalhe o conteúdo do bloco.

Pontos de bônus se o insersor irmão for alterado para abrir o menu de inserção diretamente (como discutido em # 7271) em vez de inserir um bloco de parágrafo vazio.

Claro, a questão do que acontece quando você passa o mouse sobre o bloco selecionado ainda é um problema. No entanto, não acho que isso realmente me incomode tanto. Tudo que você precisa fazer é clicar no bloco para selecioná-lo e ver os controles, e se os controles de foco forem mostrados abaixo do bloco atualmente selecionado, está tudo bem, já que o bloco selecionado deve ser o foco.

Acho que é um bom design para seguir em frente. Acho que todos os pontos positivos superam os negativos e acho que é definitivamente melhor do que o que existe agora. O que vocês acham, pessoal?

Fiz uma simulação de como isso ficaria se as barras de ferramentas superior e inferior se sobrepusessem e como ficaria se o bloco em foco sempre tivesse o índice z mais alto sobre um bloco selecionado.

Eu gosto muito disso, mas tem um pequeno problema ... os blocos de uma linha não dão sorte, porque eles ficarão quase completamente escondidos embaixo da barra de controle inferior.

@chrisvanpatten Eu estava pensando que a barra inferior iria ocupar espaço quando o bloco fosse selecionado. Acho que isso resolveria o problema do bloco de linha única. Você poderia fazer uma maquete para mostrar como é isso? Além disso, como é se o bloco focado não se sobrepõe ao bloco selecionado?

Além disso, talvez deva haver uma sombra abaixo da barra inferior quando ela se sobrepõe a algo.

@SuperGeniusZeb Eu realmente me oponho fortemente a que a barra inferior ocupe espaço - isso leva a pular a interface do usuário. Os blocos reutilizáveis ​​fazem isso agora, quando você os seleciona, e isso me deixa louco.

(EDITAR: para elaborar, torna as coisas realmente difíceis para os usuários do mouse, porque você não pode realmente confiar que as coisas estejam no mesmo lugar de um momento para outro. Isso causa muita estranheza.)

@chrisvanpatten

Estou pensando principalmente que, no contexto de escrever postagens, você provavelmente não gostaria de cobrir o parágrafo abaixo daquele que está digitando. No momento, parece que o bloco de parágrafo abaixo do selecionado está faltando a primeira linha. Acho que prefiro que os blocos ao redor pulem um pouco quando você seleciona um a não conseguir ver o topo do bloco depois do que estou editando no momento. Pessoalmente, pular não me incomoda muito.

É bastante comum em Gutenberg que algo mude de tamanho quando você o seleciona: marcadores de posição de legenda de imagem, marcadores de posição de citação de citação, o marcador de posição / inserção na Galeria e os blocos reutilizáveis, como você mencionou. Gutenberg é geralmente projetado em torno da ideia de que a aparência de um bloco deve ser otimizada para edição quando for selecionado. Eu diria que é normal fazer a altura do bloco ficar mais alta devido à barra inferior ocupando espaço.

Alternativamente, talvez a barra inferior pudesse ser feita semitransparente para deixar um pouco mais claro que há um bloco abaixo dela. Como isso soa? Acho que posso ficar bem com isso.

O único problema é que a transparência não é usada em nenhum outro lugar na IU do Gutenberg. Isso não quer dizer que não deva ser usado ... apenas que não existem exemplos disso, então poderíamos estar introduzindo uma inconsistência de design de IU.

Há também a ideia de se livrar do espaço vazio entre os controles à esquerda e à direita, mas isso foi derrubado no início do tíquete por fazer a interface do usuário parecer muito "em bloco".

@chrisvanpatten Dito isso, acho que ainda prefiro sua maquete ao que existe agora . O problema da primeira linha do bloco seguinte parece desaparecer é menor em comparação com todas as coisas que qualquer uma de nossas maquetes consertaria.

@SuperGeniusZeb Acho que o que o torna particularmente estranho neste caso é que os controles estão lá quando você passa o mouse. Com todos os outros exemplos de controles de salto, pelo menos eles não estão lá quando você passa o mouse, eles estão lá apenas na seleção.

Não acho que valha a pena abandonar isso por causa dos problemas de pairar / selecionar / pular / parágrafo de linha única, mas definitivamente precisa pensar um pouco mais.

Ainda estou confiante de que há uma solução aqui em algum lugar ... apenas tenho que continuar iterando!

@chrisvanpatten

Acho que o que o torna particularmente estranho neste caso é que os controles estão lá quando você passa o mouse. Com todos os outros exemplos de controles de salto, pelo menos eles não estão lá quando você passa o mouse, eles estão lá apenas na seleção.

Bem ... você _poderia_ não ter nenhum controle mostrado ao pairar, mas acho que é seguro presumir que ninguém realmente quer isso. Eu sei que certamente gosto dos controles que estão disponíveis ao pairar.

Enfim, que tal transparência?

E se você quiser sonhar um pouco e desejar que backdrop-filter seja implementado em todos os principais navegadores, pode adicionar um pouco de desfoque:

A propósito, isso é 60% de opacidade.

Opacidade definitivamente ajuda, mas não tenho certeza sobre como introduzir opacidade na equação. Parece um pouco como trapaça.

@chrisvanpatten Na verdade, parece um pouco como uma trapaça ... mas que outras opções temos?

Não podemos colocar os controles de lado, daí este problema existir em primeiro lugar.

Não podemos colocar os controles dentro do bloco, porque isso encobriria o conteúdo.

Não podemos colocar os controles no topo porque a barra de formatação já existe e os problemas que seriam causados ​​por blocos finos.

Colocar os controles na parte inferior faz mais sentido, pois funciona melhor para acessibilidade, fornece um local conveniente para inserir o insersor irmão e arrastar a alça e resolver problemas relacionados a eles, é mais consistente com dispositivos móveis e funciona melhor para thin blocos.

Para reduzir o espaço ocupado pela barra inferior, existem apenas algumas coisas que podemos fazer:

• Diminua a altura da barra.
• Remova o espaço vazio entre a alça de inserção / movimentadores / arrastar e as reticências.
• Empurre a elipse para a esquerda e remova o espaço extra à direita.
• Faça com que ele ocupe espaço quando selecionado. (Mas você não quer isso.)

Fora isso, tudo o que pode ser feito é torná-lo semitransparente para torná-lo visualmente mais leve e tornar mais fácil ver o que está abaixo dele.

Outro pensamento: talvez a coisa da transparência não parecesse trapaça se _both_ as barras de ferramentas fossem transparentes em vez de apenas a inferior.

Fiz mais alguns mockups para experimentar algumas das coisas mencionadas acima.

Barras de ferramentas transparentes:

Sem transparência:

Acho que prefiro sem transparência. O que você acha? Acho que diminuir a largura da barra inferior resolveu o problema de sobreposição do início do próximo bloco. Claro, isso ainda vai acontecer em larguras menores ... mas isso já acontece com a barra de ferramentas de formatação de qualquer maneira, então não acho que seja realmente um problema aqui.

Observe também que deixei um pequeno espaço para uma alça de arrastar. Ele pode ter pequenos pontos acinzentados que são freqüentemente usados ​​em aplicativos para representar alças de arrasto, ou pode ter um ícone de arrasto mostrado ao passar o mouse ou o tempo todo. Ou pode simplesmente permanecer em branco. Também poderia ser tecnicamente um pouco mais fino, mas deixei a largura de um botão para maior conforto.

Pode ser isso? Esta poderia ser a iteração boa o suficiente para substituir a atual? _ (Por favor, diga "sim".: Hung_out_tongue:) _

Obrigado a todos por todas as explorações feitas aqui. Pulando apenas para adicionar mais uma razão pela qual a semitransparência não é o ideal: a relação de contraste dos ícones com o fundo deve ser de 4,5: 1. Usar a semitransparência tornaria isso impossível, basta pensar em uma imagem com cores escuras predominantes, ou um parágrafo com fundo escuro, ou um tema com fundo escuro:

Obrigado a todos pela excelente discussão aqui. É encorajador e delicioso ver a paixão com que este desafio é enfrentado.

Tenho observado um pouco de longe, tendo desenhado a configuração inicial do bloco - com uma barra de ferramentas encaixada, as setas para cima / para baixo na lateral e, eventualmente, as reticências à direita. Eu adicionei os ingredientes porque achei que seria muito útil dar aos movimentadores um terreno de primeira linha como uma alternativa para arrastar e soltar, o que costuma ser complicado e sujeito a erros, enquanto os movimentadores são sempre previsíveis em seu comportamento.

Eu reconheço completamente os desafios que isso representa para os blocos aninhados e pensei por um longo tempo qual seria a melhor solução. O que está no mestre - sobrepor à esquerda e à direita, mesmo se aninhado - funciona, mas também não é ótimo, reconheço isso. Outra opção é usar a IU móvel - mostrar a IU abaixo do bloco quando selecionado, que é meio que simulado em várias variantes aqui, funciona especialmente para dispositivos móveis. Mas no desktop isso pode se tornar muito perturbador e saltitante quando você apenas deseja selecionar um parágrafo para fazer uma pequena edição e tudo salta ao redor. Da mesma forma, se a barra de ferramentas for sobreposta como na versão mais recente, parece que está se afastando muito da experiência de escrita, para a experiência de layout. Este é o equilíbrio constante que tentamos alcançar.

Uma segunda opção é voltar às maquetes muito antigas que eu tinha, esta aqui:

Talvez com alguns ajustes, poderia ser este:

Mas eu não amo isso. E _ou_ isso tornaria os movers visíveis apenas quando o bloco fosse pairado, ou gostaríamos de ajustar um pouco o tratamento. Isso também torna as áreas de toque do botão vários pixels menores, o que não é ótimo para usabilidade.

Como tal, essas variantes não foram consideradas até agora porque não pareciam superiores ao que tínhamos. No entanto, postar aqui independentemente se eles podem inspirar tratamentos para fazer o trabalho.

O maior problema que vejo em combinar as ferramentas de bloco com o rótulo flutuante é que isso cria uma inconsistência entre um bloco selecionado e outro suspenso, a menos que você queira começar a mostrar o rótulo para os blocos selecionados também. E se você fizer isso, o rótulo não deve estar dentro das bordas do bloco, mas sim fora dela.

Mas, mesmo se você fizer isso, terá de enfrentar os problemas de ter muitos controles no topo do bloco e ter que descobrir como fazer isso ser consistente para blocos largos e finos.

Acredito firmemente que, com exceção das barras de ferramentas fixas que permanecem na tela, nenhuma IU do bloco selecionado padrão deve cobrir qualquer parte desse bloco.

Ter as ferramentas de bloqueio na parte inferior fornece um bom local para colocar o insersor irmão, o que ajuda a atingir o objetivo de não sobreposição acima, ao mesmo tempo que torna o insersor irmão mais visível e resolve seus próprios problemas de sobreposição. (Eu acho que a atualização dos blocos aninhados para o bloco Quote ainda não aconteceu devido aos insersores irmãos sobrepostos.)

Devido ao insersor irmão e aos benefícios de acessibilidade, acho que ficar abaixo do bloco é o melhor lugar possível para colocar as ferramentas de bloco.

Bem, eu não pensei que tornar os controles muito menores estava na mesa, já que torná-los menores pode torná-los mais difíceis de usar, é claro. No entanto, já que você não parece ser contra, por que não tentar?

Como é isso?

Os botões na barra inferior (mas não os ícones) foram reduzidos em tamanho de 38px para 32px, e eu consertei uma inconsistência no espaçamento entre os controles de movimentação dos modelos anteriores. Observe que você poderia torná-lo um pouco menor horizontalmente se o botão de reticências fosse mais fino do que os outros (como o da barra superior do editor).

Você também pode diminuir o tamanho da área vazia da alça de arrasto para fazer a barra ocupar ainda menos espaço. Isso seria ainda mais viável se todos os controles na barra funcionassem como alças de arrastar, como funcionam as barras superiores das janelas do GNOME.

Observe que, no celular, os controles provavelmente seriam quase exatamente iguais aos de master , onde as barras ocupam espaço e, portanto, torná-las maiores não é um problema. Essa redução de tamanho deve afetar apenas os usuários de desktop, e os controles ainda podem ser usados ​​por toque neste tamanho.

Eu também fiz uma pequena exploração ao mover os controles para uma barra de ferramentas superior, que resolve um conjunto de problemas ... mas quando você seleciona o bloco, você volta a ter uma barra de ferramentas de tudo que não funciona em contextos estreitos, que era um razão significativa para esta exploração em primeiro lugar.

Ainda estou tentando descobrir como me sinto sobre as últimas maquetes. Os controles pendurados na parte inferior parecem meio estranhos para mim. Não tenho certeza se tenho uma ideia melhor, só que ela nos leva de volta àquela sensação de bloco / fragmentado que @karmatosed queria evitar.

Obrigado a todos por todo o trabalho aqui. Vou tentar dar algum feedback, mas tenho que dizer agora que não sinto que esteja pronto para passar para o protótipo. Eu ainda acho que há problemas com o aninhamento e também diferentes dispositivos para resolver, mas como mencionei nos comentários anteriores, não acho que a faixa atual esteja certa. Sinto que também estamos voltando sim ao território que já sugeri que evitássemos nisso.

Não quero desencorajar a exploração, mas agora eu sugiro considerar pensar em sugestões alternativas. O grande problema é que adicionar meias guias na parte inferior está aumentando a densidade visual sem ganho. Vamos pensar sobre o que estamos tentando resolver aqui:

• O que acontece em diferentes dispositivos.
• Inserção de irmãos (embora isso possa ser corrigido em outras questões) ou pelo menos como ele interage.
• Visibilidade de aninhamento e facilidade de interação.

O principal impulso em tudo isso foi como ele respondeu e se aninhando.

Vamos considerar no que criamos se estamos aumentando ou diminuindo a usabilidade. Por exemplo, usar coisas como transparências e camadas, embora sejam aceitáveis ​​para alguém com visão normal, para muitas outras pessoas não o tornam melhor. Pense em layouts complexos, com vídeos e muitas imagens. Nessa densa estrutura de informação, o que está sendo sugerido não se sustenta.

Pense em layouts complexos, com vídeos e muitas imagens. Nessa densa estrutura de informação, o que está sendo sugerido não se sustenta.

Sim, acho que este é o ponto principal, e eu adicionaria essa densidade realmente _compõe_ em espaços menores que é outra parte do desafio. Os blocos aninhados geralmente precisam dos mesmos controles que os blocos não aninhados precisam, mas eles precisam fazer isso com uma fração do espaço e, idealmente, de uma maneira não exclusiva (por exemplo, os blocos aninhados geralmente devem ser semelhantes aos blocos não aninhados; geração de consistência usabilidade).

De volta à prancheta ... 🙂

Por que acho que minha maquete é melhor do que a IU atual

Eu entendo o desejo de evitar um visual em blocos, mas ainda não encontrei nada que não seja em blocos, mas ainda assim tão funcional. O problema é que você precisa conhecer as bordas do bloco em que está trabalhando e deseja que os controles não encobram o conteúdo do bloco, bem como cubram o menos fora do bloco. Isso praticamente garante uma aparência um tanto quadrada.

Apenas olhando para a captura de tela no topo deste problema, você pode ver como Gutenberg em um ponto tinha uma IU de bloco sem bloqueios. Mas o problema com aquela IU era que era difícil dizer onde estavam as bordas de um bloco. É por isso que temos a IU que temos agora.

E quando você joga os problemas com o insersor de irmão, você percebe que precisa fazer com que o botão de insersor de irmão fique fora da borda de conteúdo do bloco. Combine isso com o ponto que você geralmente deseja inserir blocos após o atual (ao invés de antes) e também o desejo de maior acessibilidade, e você acabará tendo que ter algo como meu último maquete.

Pessoalmente, eu prefiro essa IU em blocos em vez de algo que se pareça com os primeiros modelos. Essas primeiras maquetes parecem confusas devido à falta de fronteira entre o conteúdo e os controles, e as barras ocupam muito espaço desnecessário. Como não queremos pular a interface do usuário, a barra inferior deve ser uma sobreposição sobre o conteúdo fora do bloco selecionado e, portanto, deve ser o menor possível.

Além disso, acho que meu modelo é definitivamente melhor em contextos aninhados do que o atual. Como explicarei abaixo, as barras de ferramentas / situações de conteúdo sobrepostas são melhores com esta IU do que com a anterior. E em contextos aninhados, você precisa conhecer ainda mais as bordas de um bloco, então uma aparência um tanto em blocos realmente ajuda nessa situação.

Barras de ferramentas sobrepostas são menos confusas e menos propensas a ser um problema, já que os blocos têm menos probabilidade de serem verticalmente pequenos em telas pequenas , em comparação com a probabilidade de serem horizontalmente pequenos em telas pequenas, o que causou problemas com coisas como o bloco de colunas . Quando um bloco de texto fica mais fino, seu texto quebra e fica mais alto.

Em contextos aninhados, pairar sobre o bloco acima do atual quase nunca cobrirá todo o conteúdo do bloco abaixo, porque ou o bloco será largo o suficiente para a barra inferior não cobrir tudo, ou então o bloco seria bastante alto e assim ainda teria espaço para selecioná-lo.

Além disso, a barra inferior de um bloco deve aparecer apenas quando você passa o mouse sobre o bloco, e não apenas quando o mouse está perto dele. Devido às alças de arrasto estranhas e invisíveis nas laterais dos blocos, esse não é o caso com a IU atual.

Para adicionar ao ponto acima, é apenas o bloco acima do atual que pode cobrir qualquer coisa no bloco selecionado. Os outros 3 lados estão completamente bem, uma vez que pairar um bloco adjacente horizontalmente não cobrirá nada no bloco atual e os blocos pairados não têm IU acima deles, então pairar o bloco abaixo do selecionado também é adequado.

Além disso, você poderia simplesmente escolher não fazer com que os blocos pairados nunca cobrissem o atualmente selecionado, e isso resultaria em literalmente zero problemas de sobreposição com o bloco selecionado em contextos aninhados. Como os blocos pairados têm apenas uma barra na parte inferior, a que está abaixo da atual nunca se sobrepõe à selecionada. A única coisa que você desiste nessa situação é a capacidade de acessar as ferramentas de bloqueio para o bloco acima do atual, a menos que você o selecione.

Ainda outra ideia: a barra inferior pode ser ocultada automaticamente quando você passa o cursor sobre outro bloco. Não voltaria até que o cursor se movesse para as bordas do bloco novamente. Isso pode ajudar ainda mais em contextos aninhados.

Além de tudo isso, se você ainda quiser menos problemas de sobreposição em contextos aninhados, pode encaixar a barra de ferramentas de formatação na barra superior do editor. (Isso não tem efeito no celular, mas no celular as barras ocupam espaço e não se sobrepõem, portanto, não há problemas de sobreposição em primeiro lugar.)

No geral, acho que há mais situações melhoradas com meu último modelo do que situações que pioraram.

Do jeito que está, acho que algo como minha maquete (ou perto disso) resolve muito mais problemas do que cria. Além do acima, os benefícios incluem:

• Funciona para todas as larguras de bloco.
• Melhor acessibilidade para insersor irmão, controles de movimento e reticências.
• Melhor visibilidade e capacidade de descoberta para insersor irmão e alça de arrasto.
• As áreas de arrasto na lateral do bloco podem ser removidas e o rótulo flutuante não precisa se tornar uma alça de arrasto (de qualquer forma, é meio pequeno).
• O insersor irmão está abaixo dos blocos, que é onde você normalmente deseja usá-lo (em oposição ao acima).
• Não há necessidade de interface de inserção de irmão separada, reduzindo a complexidade.
• Insersor irmão não tem mais problemas de sobreposição em contextos aninhados. (Acho que é por isso que o número 6520 ainda não aconteceu.)
• A IU do bloco em torno de um bloco nunca se sobrepõe ao conteúdo desse bloco.
• As margens automáticas dos blocos podem ser removidas e um bloco não pode ter nenhum preenchimento interno, e as bordas da IU do bloco podem ser alteradas de volta para as bordas do conteúdo real, e ainda nada no conteúdo do bloco seria sobreposto por quaisquer controles. Esses tipos de casos extremos acontecerão com blocos personalizados, portanto, é bom considerá-los.
• Todas as ferramentas de bloco estão bastante próximas umas das outras, tornando mais fácil alcançá-las e descobri-las todas, em comparação com a situação anterior das elipses e movimentadores de flechas estarem em lados opostos do bloco.
• É muito claro a qual bloco os controles estão anexados, em comparação com a confusão que você costuma obter com os controles atuais em contextos aninhados.
• Os controles são mais consistentes com dispositivos móveis.

Então, sim, acho que minha maquete realmente funciona melhor em contextos aninhados, e acho que a IU em blocos dificilmente é importante em comparação com o que você ganha. O que você acha? Se você discordar, pode apontar situações em que a maquete seria significativamente pior do que a IU atual e nenhuma das sugestões mencionadas anteriormente resolveria isso?

Existe ... outra ideia ... ~ Skywalker ~

Se tudo mais falhar, tenho uma ideia que resolveria tecnicamente todos os principais problemas. E se a barra de ferramentas de formatação estivesse sempre encaixada na parte superior como no Gutenberg 1.6, mas desta vez os controles de movimento e reticências seriam mostrados acima dos blocos em vez de nas laterais? (Você pode ainda tê-los na parte inferior, como minha maquete.)

Neste conceito, o insersor irmão não existiria, porque o insersor na barra superior do editor teria a mesma função e, neste contexto, estaria mais próximo do alcance, pois a barra de ferramentas de formatação estaria na mesma área.

A interface do usuário móvel seria exatamente a mesma que é agora. Esta mudança afetaria apenas usuários de desktop (e talvez tablet).

Mas espere, tem mais!

Na verdade, se você parar para pensar, qual é a diferença entre essa ideia e apenas ter minha maquete e habilitar Fix Toolbar to Top ? A única coisa que você ganha removendo as barras de ferramentas de formatação em linha inteiramente do celular é a capacidade de ter os controles de movimento e reticências mostrados acima dos blocos em vez de abaixo. E, tecnicamente, isso poderia ser apenas parte da opção Fix Toolbar to Top .

Compare com a IU atual, onde Fix Toolbar to Top não se livra de todos os problemas de controle sobrepostos, uma vez que a IU lateral ainda está dividida entre os dois lados e as confusas alças invisíveis de arrastar ainda estão lá, e os insersores irmãos ainda se sobrepõem em contextos aninhados, e etc.

Está definitivamente estabelecido para o futuro que cada parágrafo de texto seja um bloco separado? Nesse caso, a exibição das ferramentas de bloco teria que levar em consideração a seleção de vários blocos de texto (o que acredito que ocorrerá em algum momento).

@padraigobeirn Esse é um bom ponto que eu havia esquecido.

Notavelmente, os controles na UI atual não levam em consideração longas seleções. Os controles de movimento e as reticências ficam na parte superior esquerda e direita do primeiro bloco da seleção. Mesmo a barra de ferramentas de formatação é aderente apenas para o primeiro bloco da seleção. Veja # 7962.

Para a barra inferior em minhas maquetes, você poderia teoricamente fazê-la funcionar com várias seleções, mantendo-a fixa na parte inferior da tela quando você rola para cima. Esse comportamento aderente pode ser desejável apenas para o (s) bloco (s) selecionado (s).

Sabe, estou realmente começando a pensar que Fix Toolbar to Top deveria estar ativado por padrão.

Do jeito que está, não há realmente muito que você possa fazer para ajustar tantos controles em torno de um bloco e, mesmo com meus modelos mais recentes, ainda há casos em que a IU pode parecer lotada. Há também a preocupação de a IU parecer muito bloqueada.

Para resolver esses problemas, acho que encaixar a barra de ferramentas de formatação na parte superior deve ser o padrão. Ele economiza espaço ao redor de grande parte do bloco e reduz drasticamente a quantidade de sobreposição de controles possíveis.

Acho que ainda prefiro que os controles de movimento e reticências fiquem na parte inferior, mas eles também podem ser movidos para a parte superior quando a barra de ferramentas de formatação está encaixada. Não ter a barra de ferramentas de formatação anexada ao bloco permitiria que a barra de ferramentas do bloco fosse colocada na parte inferior direita ou superior direita, sem parecer estranha ou ocupar muito espaço.

No entanto, acho que preferiria o canto inferior esquerdo ou o canto inferior direito. Dessa forma, os controles vêm depois do bloco visualmente e em ordem de guias, o que faz mais sentido para mim. Colocar o insersor irmão lá depois de um bloco faz mais sentido do que fazer com que ele apareça antes de um bloco.

Nota lateral: recentemente notei que o criador de e-mail em Infusionsoft realmente tem seu próprio conceito de "bloco" e tem ferramentas de bloco (duplicar e excluir) mostradas acima dos blocos no canto superior direito. Os controles de formatação aparecem em uma barra na parte superior do editor quando o cursor entra em uma área de texto.

Recentemente, notei que o construtor de email em Infusionsoft realmente tem seu próprio conceito de "bloco" e tem ferramentas de bloco (duplicar e excluir) mostradas acima dos blocos no canto superior direito. Os controles de formatação aparecem em uma barra na parte superior do editor quando o cursor entra em uma área de texto.

Você poderia fazer algumas capturas de tela dessa interface @SuperGeniusZeb?

Quando comecei a usar o Gutenberg, eu era definitivamente uma pessoa do tipo "consertar a barra de ferramentas no topo", mas depois de usá-lo por um tempo, não tenho certeza se gostaria de voltar. Eu reconheço totalmente que a barra de ferramentas, de muitas maneiras, é a causa de todos esses problemas - é a mais provável que haja um monte de coisas que são cortadas em contextos aninhados e ocupam espaço que você poderia usar para os controles laterais - mas tendo isso emparelhado com o bloco é tão bom. Ele mantém tudo o que você precisa em um só lugar, evita muitos movimentos dos olhos e do mouse, etc. Estou surpreso em dizer isso agora, mas acho que é algo sem o qual eu não seria capaz de viver.

Você poderia fazer algumas capturas de tela dessa interface @SuperGeniusZeb?

@chrisvanpatten Não, só tive acesso temporário enquanto ajudava alguém.

Eu realmente não acredito muito em barras de ferramentas de formatação fixas / não fixas, mas gostaria de usar fixas, pois ajudaria a reduzir a confusão visual em torno dos blocos. Com base no feedback do usuário, o que outras pessoas preferem e por quê?

@chrisvanpatten Encontrou um artigo onde alguém fala sobre o criador de e-mail em Infusionsoft e tem um vídeo dele:

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh, acabei de verificar e parece que o vídeo está desatualizado ... parece que naquela época a barra de ferramentas de formatação estava anexada a blocos, como o que Gutenberg faz agora. Interessante que eles mudaram, no entanto.

Alguns pensamentos:

Se você vai inserir um bloco no meio de uma postagem, geralmente deseja fazê-lo _depois_ daquele que selecionou, certo? Normalmente, você não deseja inserir _antes_ do bloco selecionado. Inserir depois de um bloco também faz sentido do ponto de vista da acessibilidade. Alguém discorda disso? Para mim, este parece ser um forte argumento a favor de ter insersores irmãos em algum lugar próximo ao final de um bloco.

Insersores irmãos não devem se sobrepor ao conteúdo do bloco selecionado. Nada deve se sobrepor permanentemente ao conteúdo do bloco selecionado. Alguém discorda disso? Isso me leva a acreditar que os insersores irmãos devem ser posicionados fora do conteúdo do bloco selecionado.

Eu aponto isso porque acho que independentemente de onde os controles de movimento e reticências devem ir, o insersor irmão parece ter que aparecer em uma espécie de barra de ferramentas abaixo do bloco selecionado, mesmo que seja sozinho e / ou a barra de ferramentas tenha sem borda / fundo. Eu acho que poderia ser quase exatamente como é agora, mas mudou para baixo e mudou para aparecer abaixo dos blocos, em vez de acima deles.

Outro pensamento: seria uma melhoria em relação a master colocar as reticências do mesmo lado que as setas de movimento ou vice-versa? Isso poderia resolver muitos dos problemas com controles sobrepostos em contextos aninhados, ao custo de ter uma quantidade maior de IU de bloco no lado esquerdo (ou direito) de um bloco.

Acabei de experimentar o # 8836. Acho que, se fosse mesclado, poderia ajudar a reduzir os problemas de interface do usuário pesados ​​/ bloqueados que muitos designs de interface do usuário neste tíquete parecem ter.

Nos tickets # 9074 e # 9075, estou sugerindo dois pequenos passos, inspirados nesta discussão, para mitigar e melhorar a situação. No primeiro, a sugestão é mover o botão Reticências / Mais para a barra de ferramentas, de modo que temos apenas uma parte da IU lateral (movimentadores) e, na outra, há uma proposta para deixar a barra de ferramentas de bloco recolher as configurações para melhor caber contextos finos.

Apenas para mantê-los atualizados, atualizei meus maquetes para levar em conta as alterações propostas pelos tíquetes de

Na verdade, mover os movedores de seta abaixo dos blocos pode nem ser mais necessário se os # 9074 e # 9075 forem implementados. Pode ser que não haja problema se eles ficarem na lateral do bloco, já que as reticências dos blocos adjacentes não mais os sobreporiam em coisas como colunas. Se as soluções para # 8880, # 8881 e # 8883 acontecerem, e se # 8836 e # 8920 forem implementados, talvez a IU já seja adequada para contextos aninhados. Estou começando a me inclinar para que as setas para cima / para baixo fiquem no lado esquerdo do bloco.

Dito isso, ainda acho que o insersor irmão definitivamente pertence abaixo dos blocos , embora você pudesse definitivamente fazer com que o insersor irmão apareça sozinho abaixo dos blocos. Talvez pudesse ser centralizado como o insersor irmão atual, mas agir e se parecer com os controles de movimento para cima / para baixo, aparecendo como um botão flutuante abaixo dos blocos quando você estiver pairando dentro da parte inferior de um bloco.

Vamos nos concentrar em obter as iterações em @jasmussen nas

Graças aos números 9074 e 9075 mencionados acima, bem como a outros problemas e PRs como os números 8920 e 9197, decidi que mover os acionadores de seta abaixo do bloco não traz mais muitos benefícios.

Em vez disso, estou propondo agora que apenas o insersor irmão seja movido para baixo do bloco, agindo e aparecendo como um controle flutuante semelhante aos motores para cima / para baixo. Veja # 9202.

Vamos fechar este agora, pois muitas melhorias surgiram a partir desta e de outras discussões. Os últimos ajustes a serem feitos são em torno do insersor posterior.