Gostaríamos de configurar o editor para que o Markdown não seja uma opção disponível. Os usuários não devem poder selecionar diferentes tipos de editores, e o texto rico deve ser definido como padrão.
Agora tenho direitos de administrador. Qual é a melhor maneira de configurar as coisas?
Alternativamente, você poderia simplesmente ocultar o botão alternador do editor com CSS. Imagino que isso seja um pouco mais simples do que usar um MutationObserver.
O editor de rich text está disponível em todos os sites, e você pode usar a configuração modo de composição padrão para determinar o que seus membros verão quando abrirem o compositor pela primeira vez. Ele é definido como rich text por padrão.
Os membros, no entanto, podem decidir usar o alternador do compositor para voltar ao modo Markdown. O compositor então se lembrará disso como seu modo preferido, portanto, ele será reaberto no modo Markdown até que eles voltem para o rich text.
A ideia aqui é que queremos permitir que os membros escrevam no compositor que funciona melhor para eles — os administradores conhecem suas comunidades e podem fazer uma escolha razoável sobre qual padrão faz mais sentido, mas os membros devem ser capazes de escolher um modo diferente se ele funcionar melhor para eles.
Acredito que isso possa parecer o comportamento razoável para a maioria dos fóruns. Eu uso meu fórum, no entanto, como um site de Perguntas e Respostas para meus alunos de matemática, estatística e ciência de dados. Aprender Markdown e LaTeX faz parte do objetivo.
Não tenho dúvidas de que muitos deles querem usar o editor rico. No entanto, eles realmente precisam usar o editor Markdown. Portanto, fico feliz em poder impor isso definindo o editor Markdown como padrão e ocultando o botão de alternância com CSS.
@mcmcclur Isso funcionou para mim para ocultar o switch. Obrigado!!
.composer-toggle-switch {
display: none;
}
Estou ficando tão assustado com as atualizações agora. Toda vez recentemente atualizar o discouse resulta em trabalho extra com essas substituições/alterações e adições forçadas.
Exatamente. Concordo, isso também deveria se aplicar aos proprietários de fóruns. Não pude decidir. Atualizei e, pronto… mudou para mim e com um problema de CSS não intencional.
Mas sim, trarei de volta assim que isso for resolvido. Mas não mudando para o editor de rich text para todos os usuários, mas sim informando que eles têm uma nova opção e podem decidir.
Entendo seu ponto de vista, mas deixe-me explicar por que acho que desabilitar este recurso (ou qualquer outro) pode ser útil, pelo menos até que seja testado por tempo suficiente para vermos que ele é estável e que poucos problemas são relatados, se houver.
Este recurso não afeta apenas o usuário que está escrevendo sua postagem, embora ele possa, de fato, corrigir quaisquer problemas antes de postar sua mensagem, assumindo que encontre uma solução para postá-la corretamente.
Acho que alguns usuários nem percebem que estão no modo Rich Text. Eu não percebi quando comecei a escrever meu relatório de bug anterior aqui. Não estou dizendo que não é perceptível, mas quando você não precisa de muita formatação, pode parecer qualquer texto. O caractere asterisco (*) pode ser confundido com um item de lista em um HTML renderizado em algumas telas, então os usuários trabalham em uma postagem longa, percebem que algo quebrou, mudam para Markdown e podem piorar as coisas (como notei ontem e mencionei em Rich Text editor in topics breaks white-space characters in multiple ways).
Então eles não querem gastar muito tempo corrigindo sua postagem, apenas a enviam esperando que seja compreensível.
Então moderadores e ajudantes trabalham mais para entender a pergunta, pedem aos usuários para corrigir suas postagens, explicam a eles que não devem usar o modo Rich Text ao compartilhar código. Isso significa muita comunicação e tempo extras em vez de ajudar, enquanto esperamos por blocos de código corrigidos. Isso importa em um fórum onde a maioria das postagens contém algum tipo de bloco de código ou, se não, deveriam conter, mas os usuários não estavam familiarizados com Markdown (o que foi surpreendente para mim, mas essa é a realidade ). Portanto, o editor Rich Text pode realmente ser uma ótima adição, e foi assim que o vimos primeiro, embora eu ainda prefira Markdown, mas por que não deixar outros usuários escolherem o que gostam. Então sim, concordo.
Mas em alguns casos, moderadores ou administradores precisam decidir se um recurso causa mais problemas do que resolve, então acredito que eles deveriam ser capazes de desativá-lo temporariamente até que o recurso esteja estável o suficiente para ser ativado novamente. Usuários que vêm em busca de ajuda não saberão necessariamente qual modo de editor é melhor para eles, quando não sabem sobre os bugs.
Agora eu não pensaria em tentar desativar os botões “negrito” ou “citação”, pois esses botões fazem muito pouco e é muito fácil notar se algo está errado. Mas vejo que houve vários relatos sobre o editor Rich Text. É um recurso potencialmente ótimo, mas também pode quebrar muitas coisas. As pessoas também tiveram problemas com MarkDown, mas tudo bem, já sabemos e podemos lidar com isso como fizemos antes.
Em alguns casos, os moderadores tentam ajudar com a formatação e não apenas vinculando um guia de formatação, mas também corrigindo a mensagem para eles. Isso pode ser útil, especialmente quando eles não teriam tempo de corrigir sua própria postagem como novos usuários ou o dia já passou desde que enviaram a mensagem. Se o modo Rich Text não for estável, posso imaginar editando a postagem deles e quebrando-a em vez de ajudar.
Então eu entendo totalmente a intenção de deixar os usuários decidirem o que querem usar para escrever sua postagem, mas há outro lado disso. O fato de os usuários poderem não saber qual editor eles querem ou quais problemas eles causarão, e eles apenas criam muito mais trabalho para os moderadores e também têm uma experiência ruim no fórum que poderia ter sido resolvida desativando temporariamente o recurso.
Li sobre a solução baseada em CSS. O problema é que, embora usemos CSS para personalização, também sei que o CSS também pode quebrar coisas, então tento não usar CSS, a menos que seja absolutamente necessário. Dessa forma, posso evitar que o recurso apareça novamente após uma atualização do Discourse ou quando alguém adiciona um CSS extra para algo não relacionado, sem perceber que isso quebra a desativação de um recurso.
Espero ter conseguido descrever isso com clareza suficiente
atualização:
Quando voltei após uma notificação, percebi que não escrevi sobre exatamente a mesma coisa que o OP, mas acredito que o ponto principal permanece o mesmo: posso imaginar que os administradores do fórum queiram desativar alguns recursos se isso causar muitos problemas. Se é MarkDown ou Rich Text ou a capacidade de alternar entre eles após iniciar uma postagem é menos importante.
Sem mencionar que várias funções ainda não funcionam, o que pode confundir algumas pessoas. Eu estava apenas tentando descobrir por que \[grid\] (uma função que eu nunca vi) aparentemente não estava mais funcionando para alguém, e descobri que simplesmente não funciona no Rich, apesar de não ser mencionado em lugar nenhum. Além disso, os botões padrão que simplesmente estão quebrados. Até que todas as funções realmente funcionem, na minha opinião, seria melhor como uma opção desativável. Eu pessoalmente não usaria, mas fica claro que alguns sites a quereriam.
Bem, a maioria teve muitos problemas com markdown, porque eles não sabem usá-lo. Essa é a principal razão pela qual o WYSIWYG era tão necessário. E você disse que até ferramentas básicas raramente são usadas (mas isso veio do fato de que até o negrito parecia muito assustador no editor).
Desse ponto de vista, a carga de trabalho dos administradores e moderadores é superestimada e não é importante. Eles são para os usuários, e os fóruns são para os usuários. Os fóruns não são feitos para tornar a vida da equipe mais confortável e, ao mesmo tempo, os usuários estão tendo um tempo mais difícil
Mas, novamente. Não ative isso até que o lado RTE esteja maduro o suficiente
Quais botões padrão estão simplesmente quebrados? Temos um relatório de bug para blocos de código, mas não estou ciente de outros problemas com os itens da barra de ferramentas do compositor padrão, então, a menos que sejam relatados (preferencialmente em tópicos separados), eles dificilmente serão corrigidos.
Moderadores não seriam moderadores se não quisessem trabalhar para os usuários. Moderadores podem passar todo o seu tempo livre ou uma quantidade significativa do seu tempo livre ajudando usuários e moderando, incluindo aceitar ou rejeitar posts, ler posts longos gerados por IA para descobrir se são gerados por IA para que possam garantir que apenas posts de usuários reais recebam a atenção merecida, e formatar posts para que outros usuários pelo menos tentem ajudar, mesmo que não consigam. Eles também ajudam os usuários para que, da próxima vez, eles possam escrever seus posts melhor. Portanto, está longe de ser uma tentativa de criar um ambiente confortável para moderadores, tornando as coisas mais difíceis para os usuários. Tudo o contrário. Mas eles só podem facilitar as coisas para os usuários se tiverem tempo e se tiverem ferramentas funcionando. Tornar as coisas mais difíceis para os moderadores, eventualmente, tornará as coisas mais difíceis para os usuários também.
Portanto, meu ponto é exatamente que os moderadores veem e entendem por que o WYSIWYG poderia ser um bom recurso, mas se o efeito geral for que os posts ficam quebrados, ilegíveis, e os ajudantes (incluindo moderadores) só podem pedir aos usuários que procuram ajuda para formatar seus posts porque só eles poderiam saber qual era o conteúdo original e eles têm o arquivo ou a saída do terminal de onde o copiaram, então as pessoas que administram o fórum têm que tomar decisões que tirarão o máximo proveito dos recursos e, pelo menos temporariamente, desativarão o que torna as coisas piores e mais difíceis para todos.
Usuários frequentemente fazem uma pergunta, e se eles veem que seu post foi quebrado e pedimos que eles o consertem porque só eles podem fazê-lo, eles vão para o StackOverflow ou para qualquer outro lugar.
Meu comentário sobre markdown que você citou foi apenas para dizer que foi o problema original que os moderadores poderiam continuar a lidar até que o editor Rich Text fosse corrigido, em vez de ter múltiplos novos problemas e ainda ter que lidar com o antigo, original, pois mesmo que as pessoas começassem com o Rich Text, eu vi sinais de que elas voltaram para o Markdown e isso quebrou o post.
Portanto, enquanto me concentrava em ajudar os usuários, estava falando sobre como isso pode ser feito e como às vezes os administradores podem precisar decidir o que é melhor para a comunidade. Da mesma forma, você não deixaria produtos em supermercados que deixam as pessoas doentes porque você quer dar a elas uma escolha. Você recolheria o produto e investigaria.
Eu não o fiz Ele é hospedado pelo Discourse e estava ativado.
Ativando o novo composer
O editor rico está ativado por padrão para todas as comunidades. Quando você ou seus membros abrirem o composer, você notará um alternador na barra de ferramentas. Isso permite alternar entre o modo clássico apenas com Markdown e o novo editor de texto rico.
Mas este caso específico não é importante. Ele pode ser discutido em seu próprio relatório de bug. Eu só queria compartilhar meus pensamentos sobre quando e por que tornar um recurso opcional pode ser útil em geral, mesmo que seja desativar Markdown ou Rich Text. Espero ter conseguido esclarecer, e me desculpe por ter confundido você no post original.