Conversas significativas acontecem quando todos na sala ouviram os pensamentos uns dos outros, e uma linha do tempo plana e linear sempre foi a melhor maneira de tornar isso possível no Discourse. Mas o formato plano não serve para todas as comunidades. Em fóruns maiores e mais dinâmicos, milhares de respostas em uma única linha do tempo tornam impossível para qualquer pessoa acompanhar. É por isso que temos testado com cautela uma visualização de respostas totalmente aninhada este ano, e acreditamos que ela é ideal para comunidades que cresceram além do formato plano.
O que começou como um plugin experimental evoluiu para um projeto entregue diretamente no Discourse. Aqui está uma prévia de como fica um tópico aninhado no momento:
As configurações do site para ativar esse recurso estão disponíveis na interface de administração. Navegue até a seção “Respostas Aninhadas” para controlar o recurso, modos de classificação padrão, profundidade máxima e muito mais.
Roadmap
No momento da escrita, as respostas aninhadas estão em seus estágios iniciais. O roadmap ainda não está totalmente definido. Algumas coisas que sabemos que faremos:
Melhor experiência em dispositivos móveis
Repensar a linha do tempo do tópico para a visualização aninhada. No momento, não há linha do tempo em tópicos enquanto o modo de respostas aninhadas está ativo
Adicionar pelo menos um novo modo de ordenação para postagens com decaimento por idade, semelhante ao nosso “Quente” para listas de tópicos.
Limitações
Quando o aninhamento é ativado para uma categoria, os tópicos existentes permanecem no modo plano. Cada tópico pode ser alternado individualmente pela chave de fenda de administração, mas atualmente não há como converter uma categoria existente para o modo aninhado.
Adoraríamos receber seu feedback
Precisamos do seu feedback e da sua experiência ao usar esse recurso para ajudar a orientar seu desenvolvimento. Se isso parecer adequado para sua comunidade, experimente e nos diga o que você e seus usuários acham!
OMG, sim! O timing também é excelente. Estou migrando um fórum para um novo servidor com 2 containers hoje à noite e mal posso esperar para trocar este pelo novo quando a temporada regular e nossas ligas esportivas começarem em algumas semanas. Isso também deve ser um bom caso de teste.
Vai ser muito legal ter as opções de discussões planas e incorporadas — obrigado por isso, @markvanlan e equipe.
Apenas para registrar: quando há novas respostas em vários ramos da árvore, parece que a visualização de thread única mostrou apenas uma de cada vez. Eu precisei visitar várias vezes, com a contagem de não lidos diminuindo de um em cada visita.
Ok, não tenho certeza de quão viável seria o toggle em massa para categorias com dezenas de milhares de tópicos. Seriam jobs de conversão em lote/por lotes do Rails uma opção?
E isso é reversível? É possível converter um tópico em formato de thread de volta para um formato plano?
Sim, concordo com você. Isso é uma limitação por enquanto e algo que definitivamente continuaremos a considerar.
A principal razão pela qual optei por não converter tópicos históricos em uma categoria quando essa opção está habilitada é que os usuários provavelmente interagirão de forma diferente. No modo plano, os vários botões Responder não são tão importantes. A postagem será adicionada ao final do tópico. Não tenho certeza de que os usuários sempre pressionam intencionalmente o “correto” que corresponderia à visão aninhada.
Basicamente, me preocupo que administradores habilitarão essa opção para tópicos históricos e, de repente, a conversa ficará ilegível. Continuaremos a pensar sobre isso. A mudança mais simples que consigo imaginar é que, quando a configuração da categoria for alterada, exibamos um modal com a mensagem: “Deseja aplicar isso aos tópicos existentes?”
/* adicionar texto ao botão Responder para a postagem original (aka Tópico) */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Adicionando este conteúdo após Responder
content: " a este Tópico";
}
}
}
}
/* adicionar texto ao botão Responder para todas as postagens subsequentes (chamo de comentários) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Adicionando este conteúdo após Responder
content: " a este comentário";
}
}
}
}
/* adicionar texto ao botão Responder azul (ao Tópico) que aparece no final da página */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// Adicionando este conteúdo após Responder
content: " ao Tópico principal";
}
}
}
}
Isso sugere que deveríamos testar essa funcionalidade primeiro em nossas comunidades de forma isolada, antes de todos tomarmos a decisão de converter todos os tópicos existentes?
Isso funcionaria, desde que suportasse dezenas de milhares de tópicos.
Mas seria necessário deixar muito claro que não há como voltar atrás após isso
Essa funcionalidade será implementada primeiro aqui no meta ou em https://try.discourse.org, para que possamos testá-la fora de nossos ambientes de produção?
Se fosse minha comunidade, eu testaria em isolamento primeiro. Por outro lado, vocês obteriam feedback mais valioso mais rápido se habilitassem para toda a comunidade . Brincadeiras à parte, acho que testar em isolamento provavelmente é uma ideia inteligente, mas não há migrações de dados destrutivas aqui. Pode ser habilitado e desabilitado com segurança. Nenhuma decisão que você tomar aqui o trancará em nenhuma direção.
Acho que acabei de responder essa parte sem querer! Habilitar a aninhamento simplesmente cria um registro nested_topic para cada tópico no banco de dados e inicia um trabalho para calcular as contagens de respostas descendo pela árvore de ancestralidade. Desabilitar o aninhamento remove esse registro nested_topic e você volta ao formato plano, sem problemas.
Sinta-se à vontade para brincar com isso nesta categoria:
Há algum motivo para que isso só possa ser alternado por membros da equipe em vez de usuários normais? Quando vi que isso estava chegando ao Meta, imaginei que seria adicionado ao menu de tipos de postagem, mas a opção de alternar está oculta atrás do ícone de chave inglesa da equipe.
Não queremos que essa seja uma decisão ou preferência do usuário. Cabe aos administradores decidir como seu site deve funcionar. Os dois paradigmas são muito diferentes e os usuários não deveriam interagir de forma tão distinta com o mesmo conteúdo. Essa é, pelo menos, nossa opinião atual.
Os blocos de publicidades não funcionam bem nessa estrutura e a conversão de tópicos costuma gerar um bug onde os itens da tela somem e só é possível editar o titulo.
Ótima funcionalidade! No entanto estou mais curioso sobre a ordenação Top / Novo / Antigo do que sobre o próprio layout aninhado. Já implementei controles de ordenação semelhantes no meu aplicativo móvel (um cliente Discourse) e adoraria dar suporte a isso nativamente, em vez do meu método atual, embora funcione, como mostrarei abaixo.
Analisando o código-fonte, vejo que GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} retorna o tópico na visão aninhada, ordenado pelo modo escolhido. Minha pergunta: há interesse em expor apenas a ordenação através do endpoint existente /t/{slug}/{topic_id}.json (por exemplo, ?sort=top), para que clientes em visão plana também se beneficiem?
Se a ordenação estivesse disponível na visão plana, clientes de terceiros poderiam optar por usá-la sem adotar o modelo de renderização de visão aninhada.
Entendo que a estrutura de dados da visão aninhada (postagens raiz + filhos preguiçosos) é o que torna a ordenação no lado do servidor viável, e que a visão plana usa paginação diferente. Se uma ordenação completa na visão plana não for realista por motivos de desempenho, até mesmo um ?sort=top&limit=N opcional seria suficiente para impulsionar uma visão de “destaques”.
. Brincadeiras à parte, acho que testar em isolamento provavelmente é uma ideia inteligente, mas não há migrações de dados destrutivas aqui. Pode ser habilitado e desabilitado com segurança. Nenhuma decisão que você tomar aqui o trancará em nenhuma direção.
