Seria possível exibir uma contagem numérica das tags adicionadas após a adição de 1 ou mais tags, ao lado do ícone? Isso parece melhor do que ter o ícone da tag preenchido agora (é muito sutil).
Acho que o Canapin levantou isso: o título parece bastante cortado por alguma razão; pode ter a ver com o botão flutuante no caminho.
Não vi nenhum erro, mas posso tentar testar novamente. Primeiro, tentei configurá-lo para grupos específicos: Staff, Guide.
Quando testei o editor, ele estava inalterado. Então, tentei a opção apenas para Staff, com o mesmo efeito. Só quando habilitei para todos é que o editor redesenhado apareceu no mobile.
Ainda não testei no desktop. Peço desculpas por ter esquecido de adicionar detalhes extras.
Mobile no Google Pixel 9 XL.
EDIT acabei de tentar novamente essas configurações. Está funcionando agora! Talvez estivesse vendo o fórum em cache? Eu até tentei atualizar a página. Mas está tudo certo agora.
É meio chamativo e pisca em azul ao expandir devido ao destaque azul característico do Chromium(?).
Além disso, preciso pressionar o botão de menos duas vezes para minimizar quando o teclado é aberto. (nota: não ocorre no design antigo) Isso pode ser causado por esse erro neste frame do vídeo (visto após pressionar o botão de menos pela primeira vez), onde a barra de URL salta para a posição do botão de menos por uma razão desconhecida:
Perguntei à IA e o flash azul pode ser corrigido adicionando -webkit-tap-highlight-color: transparent ao elemento em questão. Recomendo fazer isso para o elemento do editor, pois quando ele ocupa a tela inteira ao expandir, resulta em um flash em tela cheia, o que não proporciona uma boa experiência visual.
Acho que o design sem bordas é significativamente menos intuitivo:
O título parece fazer parte do corpo do editor de postagem. Tudo bem. Mas se eu digitar o título e depois pressionar a tecla Enter, o cursor não vai para a próxima linha. Parece que estou preso na primeira linha da postagem, sem nenhuma maneira de prosseguir. Não acho que o usuário entenderá intuitivamente que deve clicar na próxima linha ou pressionar Tab para continuar. Se você quer que a entrada do título faça parte do corpo do editor de postagem, então ela deve funcionar exatamente como qualquer outra linha no editor. Se vai continuar sendo tratada como um campo de entrada separado, então volte ao design antigo, onde essa natureza era visualmente comunicada ao usuário.
A falta de uma borda entre o editor de postagem e a pré-visualização (quando o compositor está no modo de editor de Markdown) é muito confusa. Estas são duas painéis separados. Esse fato deve ser visualmente comunicado ao usuário por uma borda entre os dois.
Eu esperaria que ele tivesse uma margem semelhante à que vemos na lateral esquerda do editor, como vemos quando o editor está no “modo editor de texto rico”:
Se for assim, deveria também funcionar no sentido inverso? Se o cursor estiver no início da área de texto, pressionar o botão de voltar deveria levar ao campo de título, certo?
Como se trata de campos distintos, eu acharia esse comportamento todo (do título para a área de texto e vice-versa) estranho, mas talvez mudasse de ideia depois de usar.
Apenas para informação, e talvez seja cedo demais e já seja do conhecimento de todos, mas a barra de ferramentas está completamente ausente quando usando mobile/iPhone no DiscourseHub
Edição
Não tem nada a ver com o DiscourseHub. Ela segue o status de visibilidade da barra de ferramentas do compositor original.
Se a barra de ferramentas estiver oculta por meio do botão de alternância e, em seguida, o novo compositor for ativado, a barra de ferramentas não será visível e, que eu saiba, não há como exibi-la. E vice-versa. Se o original tiver a barra de ferramentas visível, a mudança para o novo compositor oferece a barra de ferramentas.
Olá a todos e obrigado por todo o feedback até agora.
Algumas coisas que implementei/consertei: (mesclagem pendente)
Reformatei o título de volta para uma seção separada parecida com entrada. Talvez revisite mais tarde.
Trabalhando agora em:
Vou continuar acompanhando este tópico – ainda pensando em alguns dos outros feedbacks.
Sim, percebi que este era o problema – não deve ser um problema uma vez que o redesign seja implementado corretamente (ou seja, a alternância não é mais funcional)
Um pouco fora do assunto, já que isso também acontece no “antigo” compositor, mas notei que, quando arrasto o compositor para cima e para baixo, ele segue o mouse com atraso e a animação fica mais travada.
Assista em 0,25× de velocidade para ver melhor do que estou falando.
Suspeito que seja uma limitação do JS/navegador e que nada possa ser facilmente otimizado?
Eu adoraria ver os elementos da interface reagindo quase instantaneamente e sendo animados a 60 fps.
Além disso, após usar o novo compositor por alguns dias, ele é simplesmente melhor. Tem alguns “defeitos” nos quais as pessoas concordam (separação entre markdown/visualização, título…), mas, no geral, é uma melhoria muito boa em algo que acho difícil de melhorar. Então, ótimo trabalho
O novo editor ocupa muito espaço vertical. Agora preciso aumentar seu tamanho ao criar um novo tópico. Isso é menos problemático (ou não é problema nenhum) ao responder a uma publicação.
Para sua informação
Usando o editor Markdown, Firefox no Win11
Usamos o plugin mermaid para exibir fluxos do Node-RED. Isso não funciona neste novo editor de texto rico nem no anterior. O código é exibido como texto de console:
Anteriormente, podíamos contornar isso alternando o compositor de volta para a variante antiga, não rica em texto. Este botão de seleção não funciona mais.
Atualização de informações: Isso ainda ocorre com o teclado Sogou personalizado para Xiaomi, mas não com o teclado Fcitx. De qualquer forma, estou abandonando o Sogou peculiar, então não vou considerar esse teclado como prioridade