Pesquisa e vinculação de tópicos in-line, por exemplo, links entre colchetes no estilo Roam

Contribuir Funcionalidade
1

Acho que é hora de o Discourse ter uma maneira mais rápida de criar links para outros tópicos em um fórum específico. Obviamente, já existe o botão de link e o atalho no editor, e, se você for realmente brilhante e souber a URL exata de um tópico, pode até fazer isso sem usar o diálogo de link. Mas existem outros aplicativos que mostram que pode haver uma maneira melhor, mais rápida e mais fácil: invocar um diálogo de busca e link diretamente na linha.

Já existe um precedente para isso no Discourse com o comportamento de link/busca usando @ para perfis, bem como o comportamento de link/busca usando # para hashtags. Portanto, estou simplesmente sugerindo que seja adicionada a funcionalidade de busca e link para tópicos. Isso adotaria uma abordagem muito minimalista, bastante semelhante à busca de usuários com @, com uma rápida pesquisa de tópicos em linha baseada no texto que você digita no editor, e não teria campos para Título ou quaisquer outros controles. Funcionaria exatamente como a busca com @, exceto para links. Você usaria o teclado para confirmar o link, e a primeira opção seria destacada automaticamente.

Uma sintaxe recentemente popularizada para isso são os “links entre colchetes”, ou seja, [[link-ao-topico]]. Você digita [[ e uma busca pelos títulos dos tópicos é acionada, assim como nas buscas de usuários ou hashtags. Outra abordagem comum é o menu de barra /, embora geralmente seja usado para múltiplas funções. Seja como for que seja acionado, isso tornaria super rápido e fácil criar links entre tópicos, o que, pessoalmente, considero algo positivo, pois incentiva as pessoas a referenciar outros conteúdos existentes e relacionados.

O principal problema que vejo com essa sintaxe específica é que ela é diferente, mas também semelhante, à sintaxe de wiki atualmente suportada. No entanto, a sintaxe de link de wiki é realmente usada em sistemas que também suportam a sintaxe de colchetes duplos [], mas especificamente para links que precisam de texto personalizado. Assim, uma opção seria usar a mesma distinção: colchetes duplos para um link a um tópico que usa o título do tópico como texto do link, ou um link de wiki tradicional para um título personalizado. Outra seria alterar a sintaxe de link como um todo, o que duvido que seja atraente. Uma terceira opção seria escolher outra sintaxe de link em linha, ou seja, um conjunto diferente de caracteres que acionam a busca de links.

Não me importo realmente com a forma exata como será implementado; quero apenas poder fazer busca e link em linha! Acredito que seria uma ótima adição ao já excelente editor do Discourse e às funcionalidades gerais de conveniência. :slight_smile:

Dito isso, percebo que as funções atuais do Editor são bastante boas e isso é apenas um recurso de conveniência, argumentavelmente para um certo subconjunto de usuários. Definitivamente é uma baixa prioridade, mesmo que haja concordância de que seria útil.

6 curtidas
Discourse Wikilinks Plugin
2

Algo semelhante existe quando você seleciona e move postagens para um tópico novo ou existente. Falando francamente, é um incômodo na sua forma atual:

  • a pesquisa demora muito
  • mesmo que você conheça o título do tópico e o digite exatamente como está escrito (com a capitalização correta, etc.), a pesquisa não encontra o tópico que você quer
  • a pesquisa o encontra, você o seleciona, e então a pesquisa continua antes mesmo de você ter a chance de confirmar sua seleção. Sua seleção desaparece, e a pesquisa nem mesmo lista mais o tópico que você selecionou

Minha experiência é justamente o oposto disso, veja acima.
Sou mais rápido em encontrar o tópico correto quando uso a função de pesquisa padrão.

1 curtida
3

Oi Oshyan, :slightly_smiling_face:

Eu realmente gosto da ideia, mas…

O título do tópico não é único, então agora, quando você pesquisa um tópico, você tem informações adicionais, como tags e categorias, para ajudar a reconhecê-lo melhor. No entanto, a abordagem inline pode ficar muito congestionada e, às vezes, há muitos tópicos correspondentes à sua pesquisa para filtrar diretamente na linha.

Outra coisa:
Quando você usa este painel para inserir um link, precisa confirmar sua escolha com um clique no botão, o que acho super útil.

Screenshot_20210815_093116_com.android.chrome
Screenshot_20210815_093116_com.android.chrome1080×2240 168 KB

Na abordagem inline, se você perder o tópico correto, terá que apagar muito, e talvez haja mais links com formatação quebrada do que atualmente.

Talvez exista uma boa maneira de tornar isso simples e rápido, mas agora acho que a solução com painel é mais rápida e mais amigável para o usuário.

1 curtida
4

Tudo isso parece ser resultado de falhas na UI/UX ou nas funções de pesquisa, e não um problema com a ideia de vinculação em si. Se você ainda não o fez, sugiro abrir um tópico para discutir melhorias/correções no comportamento existente de “mover postagens/fundir”, dadas as experiências que você descreve. Mas, supondo que esse tipo de problema não ocorresse no contexto da minha abordagem de vinculação proposta, você então a acharia útil?

Por que você está assumindo que a pesquisa em linha funcionaria de maneira diferente da pesquisa baseada na barra de ferramentas? Quanto ao comportamento de pesquisa e exibição, deve funcionar exatamente da mesma forma, oferecendo o mesmo nível de facilidade e utilidade para encontrar e selecionar o tópico correto. Minha preferência seria que ela se diferenciasse do diálogo de vinculação existente e focasse na velocidade e facilidade de uso, funcionando de forma muito semelhante à pesquisa @ existente, que exibe uma pequena lista de resultados contextuais. A lista de resultados poderia ser idêntica à do diálogo de vínculo, mas eu não quero um campo de título do tópico, botões de OK/cancelar, etc. Já existe um atalho que abre essa funcionalidade.

Realmente não sei por que haveria mais links quebrados. Você ainda precisa pressionar Enter para confirmar o tópico selecionado na pesquisa.

Bem, definitivamente não é “mais rápida”. Pode ser mais amigável ao usuário, claro, mas minha sugestão não é substituir a vinculação existente na barra de ferramentas, apenas adicionar uma maneira mais rápida de vincular para usuários mais experientes.

Suponho que Ctrl-K (atalho) seja uma alternativa perfeita e já existe, é claro. Eu apenas gosto da capacidade de usar sintaxe em linha para acionar coisas úteis, e isso é algo que o Discourse já adota com @ e #. Ambos também poderiam ser acessados apenas com atalhos de teclado ou digitação manual sem pesquisa, mas, é claro, há valor agregado em como eles funcionam agora. Estou propondo que a vinculação possa ganhar valor similar com essa abordagem.

2 curtidas
5

Ah, ok, entendi! Obrigado pela esclarecimento!
Isso seria um recurso avançado e manteria o painel de pesquisa original.
Parece uma boa ideia para mim. :slightly_smiling_face:

1 curtida
8

Apenas para deixar o contexto claro, o que temos hoje é:

CTRLALTf
buscar por algo
SETA PARA BAIXO
a

Por exemplo: In-line topic search-and-linking, e.g. Roam-like bracket links

O problema é que é extremamente difícil ensinar sobre isso, mas oferece (pode-se argumentar) um conjunto de recursos maior do que a proposta [[.

5 curtidas
9

Ah, isso é muito interessante e bom de saber! No entanto, acho que há uma diferença valiosa entre ação a partir da sintaxe em linha e ação a partir de comando de teclado. A descoberta é uma delas, a velocidade é outra.

É verdade que, uma vez aprendido, usar essa sequência é razoavelmente rápido, mas, ao tentar várias vezes para testar, definitivamente parece mais lento e menos fluido do que minha experiência com (crescente número de) aplicativos que suportam links com colchetes []. Talvez isso se deva parcialmente à necessidade de deslocar a atenção/olhar, além do atalho de teclado novo e um pouco desconfortável. O último pode ser parcialmente superado com o tempo (embora a geometria básica das minhas mãos veja alguns limites a esse potencial), mas o deslocamento de atenção sempre terá um custo durante a composição de uma mensagem.

É realmente interessante para mim que você tenha tido desejo suficiente de vincular rapidamente para criar essa sequência de atalho de teclado um tanto incomum (sem dúvida porque muitos outros foram usados). Isso sugere um pouco para mim que você pode ver algum valor na ideia de vinculação em linha em geral… Mas tenho a impressão de que não há muito apoio à minha sugestão por enquanto. Mesmo assim, tenho curiosidade em saber se há algum bloqueio claro para isso, como “Usamos colchetes para outra coisa”, “não podemos adicionar outro manipulador em linha ou isso deixará todas as consultas ao banco de dados 30% mais lentas” ou o que for. :grinning_face_with_smiling_eyes:

De qualquer forma, espero que isso tenha pelo menos despertado o interesse de alguém. Ainda adoraria ter isso disponível, e imagino que, uma vez que outros usuários tenham a chance de experimentar, eles também podem adorá-lo (há usuários do Roam aqui? Obsidian? Logseq?). Mas, pelo menos, espero ter despertado algum interesse na ideia de busca e vínculo em linha, e talvez algo se consolide em torno disso no futuro. :folded_hands:

1 curtida
10

Vejo que uma [[ busca mágica é viável em um componente de tema hoje.

A única ressalva é que a conclusão automática removeria [[ e substituiria por um link; não sei como mais isso poderia funcionar. Isso torna o ]] meio inútil, no entanto.

Lembre-se de que manter a conclusão automática aberta além de um limite de espaço pode ser um pouco confuso.

2 curtidas
11

Isso é bom de saber! Como não sou programador, não tenho muita ideia de até onde é possível ir com componentes de tema (muito, ao que parece, o que é uma das muitas coisas que adoro no Discourse). Então, isso é bem legal.

É verdade que, em outros softwares, o [[ é mantido e mantém algum valor mesmo após a adição do link. Ou melhor, eu deveria dizer que a busca [[ não preenche automaticamente um link tradicional, mas uma referência interna especializada. Como vários aplicativos suportam esse formato de referência, ele é portátil em uma variante do Markdown, o que é bem útil.

Mas, enfim, no caso do Discourse, o [[ é apenas um atalho em linha familiar, que, felizmente, dificilmente é acionado acidentalmente. Eu ficaria feliz com qualquer outra maneira baseada em texto para invocar a busca em linha que atendesse a critérios semelhantes, mas, apesar das diferenças na forma como funcionaria no Discourse versus, por exemplo, no Roam, vejo algum valor em pelo menos manter a mesma sintaxe. Como disse, é algo de um padrão de facto em crescimento. :thinking:

Outra coisa que me ocorre é que o Discourse já possui seu próprio equivalente de links internos que são renderizados de formas especiais: é assim que funciona a citação! Então, “post:10, topic:200454” certamente criará um link para sua resposta a mim aqui. Como essa função de link é destinada especificamente a tópicos internos, poderia simplesmente usá-la e exibi-la automaticamente como um link para o tópico no momento da renderização. Não consigo decidir se isso está mais ou menos alinhado com a forma como o Discourse faz as coisas… :grinning_face_with_smiling_eyes:

De um lado, já existe essa maneira de criar links; isso seria apenas uma forma diferente de invocar a busca e seleção de links, e é muito semelhante às buscas existentes com @ e #, como já mencionei. Por outro lado, isso se afasta do comportamento de link existente invocado por Ctrl+K, pela barra de ferramentas e por outros atalhos. Acredito, no entanto, que o tipo de link “post:10” é mais semelhante ao conceito de link [[ usado em outros aplicativos, então eu tenderia um pouco nessa direção… se eu tivesse alguma influência no assunto. :wink: Sei, claro, que isso é mais território de componente de tema, então talvez eu tenha! Talvez você possa opinar se o link no estilo “post:10” poderia ser feito a partir de uma busca em pop-up em um componente de tema?

12

Acabei de testar o Roam para contexto.

@codinghorror mencionou algumas vezes no passado que está muito preocupado com a ineficiência de uma pesquisa inline ao usar o compositor, embora eu imagine que, no contexto de documentação e categorias específicas onde o escopo é mais restrito, isso possa ser útil.

Tivemos discussões no passado sobre a introdução de uma sintaxe do tipo #784, que soa muito semelhante a esta discussão.

O modo como o Roam funciona:

  1. Você digita [[
  2. Ele insere magicamente ]] e posiciona o cursor dentro.
  3. Conforme você digita dentro de [[ ]], ele executa uma pesquisa com autocompletar. Por exemplo:

image
image783×281 14.2 KB

  1. Quando você finalmente decide pelo link, ele usa o título completo, por exemplo: [[13 de agosto de 2021]]

  2. Ele lida com renomeações do documento original atualizando automaticamente a marcação nos documentos que fazem link.

Qualquer coisa semelhante a esse comportamento exigiria um plugin bastante extenso para o Discourse, integrando-se a pontos onde tópicos são renomeados, ao motor de Markdown e mais. Eu colocaria isso na categoria de várias semanas de trabalho complexo.

Atualmente, temos:

4 curtidas
13

Para uma implementação interessante para observar, recomendo conferir https://obsidian.md. Eles usam essa sintaxe em arquivos Markdown e parece ser semelhante à especificação que @sam descreveu.

1 curtida
14

Ok, então é aqui que o meu uso do Roam como exemplo começa a falhar se for levado muito literalmente. :grinning_face_with_smiling_eyes: Na verdade, parei de usar o Roam há bastante tempo, em parte porque a pesquisa em linha dele é completamente horrível. O Obsidian é um exemplo melhor e é o que uso em tempo integral agora, mas requer um download para testar, enquanto o Roam (ou o Logseq) não.

Antes de continuar, obrigado @sam por se envolver tanto com essa ideia, que eu sei que pode parecer um pouco fora do comum. E especialmente por me dar uma estimativa do trabalho que você acha que pode ser necessário, pelo menos da maneira como você descreveu que funcionaria.

Dito isso, quero enfatizar que minha sugestão é inspirada no Roam e em aplicativos semelhantes que usam essa sintaxe, mas não tenho interesse em tentar replicar totalmente tudo sobre como ele funciona.

  • Não é necessário completar automaticamente o colchete, porque o colchete não será mantido no markdown resultante (no Roam ele é mantido, o mesmo no Obsidian)
  • A pesquisa do Discourse, exemplificada pela pesquisa de links com Ctrl-K ou Ctrl-Alt-F, é melhor que a do Roam e, se implementada em linha, provavelmente me permitiria encontrar um tópico de interesse em um tempo razoavelmente curto (ou seja, se você acha que a pesquisa é útil de forma alguma, então ela atenderia à necessidade descrita aqui como está)
  • O link usaria o título completo, assim como se você copiasse/colasse um link para um tópico do Discourse naquele mesmo fórum em uma mensagem
  • A renomeação seria tratada da mesma forma que o Discourse já trata isso para links internos

Então, para resumir, o Roam é apenas um exemplo para demonstrar o conceito e parte da experiência do usuário. O que estou realmente sugerindo é:

  • Um conjunto de caracteres incomuns, mas de digitação rápida, que possam acionar uma pesquisa de tópico em linha
  • Pesquisa de tópico em linha com Enter para selecionar automaticamente o primeiro resultado
  • Tratamento normal de links do Discourse em todos os outros aspectos
  • Implementação da maneira que melhor se alinhe com a abordagem do Discourse para as coisas

O resto do que eu disse são apenas reflexões sobre o que faria mais sentido ou possíveis abordagens para o problema.

Então, com tudo isso em mente, isso muda a estimativa de trabalho necessário? Se não, o que exatamente na solicitação de recurso está tornando tudo tão mais complicado do que, por exemplo, Ctrl-Alt-F + A? Pergunto porque isso pode me ajudar a entender se posso reduzir o escopo da solicitação para tornar os custos razoáveis ou se simplesmente não vale a pena o tempo necessário.

Obrigado novamente!

4 curtidas
15

Para mim, quanto menos o Discourse for compatível com o markdown padrão, mais difícil se tornarão outras coisas, como mover conteúdo entre o Discourse e outras ferramentas que usam markdown. (Meus sites e documentação geralmente usam markdown ou MDX.)

Se algum recurso como esse for adicionado, uma ideia alternativa de implementação seria usar um sistema semelhante ao do Confluence ou do Notion, onde o caractere / (barra) abre um menu.

Aqui está o Confluence:

Confluence slash commands
Confluence slash commands641×705 37.2 KB

Aqui está o Notion:

Notion slash commands
Notion slash commands480×436 28.1 KB

Se um recurso semelhante fosse implementado no Discourse, uma barra poderia abrir um menu que incluiria “Link” como uma opção. Se “Link” for selecionado, o usuário poderá pesquisar outras postagens e um link markdown normal será inserido no editor.

Não estou solicitando o recurso, apenas mencionando uma ideia alternativa de implementação que não faria o conteúdo raw divergir ainda mais do markdown padrão. :slight_smile:

3 curtidas
16

Se você mantiver as coisas dentro das estruturas existentes, um componente de tema pode funcionar perfeitamente e a quantidade de trabalho não é enorme. O [[ é realmente útil em termos de implementação, pois fornece uma boa âncora de onde parar com a conclusão automática.

Um exemplo completo de fluxo de trabalho poderia ser:

  1. O usuário digita: [[
  2. O editor preenche com ]], e o cursor fica entre os colchetes.
  3. O usuário digita um termo de busca, por exemplo: [[tópico em linha]]
  4. Enquanto o usuário digita, a busca é realizada e os resultados são exibidos em uma conclusão automática semelhante a @menções.
  5. Use as setas para cima/baixo ou Enter para selecionar.
  6. Uma vez selecionado, [[tópico em linha]] é substituído por https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454.
  7. Se o usuário apenas mover o cursor além de ]], a conclusão automática é fechada e [[tópico em linha]] permanece no markdown.

No geral, construir algo assim é totalmente viável em um componente de tema, não requer alterações no lado do servidor e seria bastante simples de implementar. Eu diria que um especialista poderia fazer algo em um ou dois dias, enquanto alguém com nível intermediário provavelmente levaria cerca de uma semana.

5 curtidas
17

Sim, menus com barra são definitivamente uma abordagem interessante e legal que eu gosto e uso em muitos aplicativos. Acho que não me ocorreu como a maneira de implementar o que eu queria neste caso, porque essa abordagem implica um conjunto inteiro de funcionalidades a serem invocadas. Em outras palavras, acho que seria estranho/imprevisível, para quem está acostumado com menus de barra, que um deles apenas invoque uma busca por links. E embora ter muitas outras funções em um menu / seja certamente algo que eu apoie, parece ser uma solicitação de recurso consideravelmente maior para mim.

Fantástico, obrigado por pensar nisso e me dar uma ideia da complexidade e do tempo de desenvolvimento! Isso é extremamente útil. Vou ter que pensar se consigo colocar um pouco do meu próprio dinheiro nisso, já que tenho outras solicitações talvez mais importantes que provavelmente preciso financiar para o desenvolvimento. E agora que sei mais sobre os atalhos de teclado, este aqui é mais uma conveniência do que uma necessidade, de qualquer forma.

2 curtidas
18

Isso seria ainda mais interessante se fosse suportado “criar um link nomeado” ao adicionar o link via a ao texto selecionado. Gostaria que essa ação resultasse em [texto selecionado](link).

Infelizmente, parece que ele não se adiciona ao buffer de desfazer.

2 curtidas
19

Outros bons exemplos de fluxos de digitação (trabalho) com / e [[ ]] dos quais se pode tirar inspiração são fornecidos por

e

3 curtidas
20

Este sistema de gerenciamento de conhecimento pessoal + conceito de fórum é realmente visionário e potencialmente muito poderoso. Não é “novo” (por exemplo, veja “Bliki”, de 2003), mas não precisa ser. O contexto é novo e, portanto, a ideia também é. O mercado de PKM está crescendo muito rápido porque todo mundo quer algo parecido com o que você descreve, mas isso não existe. Dito isso, não acho que wikilinks seriam a solução correta; recursos de “link para destaque” integrados ao Discourse (como uma melhoria/variante da funcionalidade atual de Citação) seriam. O botão “Compartilhar” que aparece ao destacar texto em uma postagem deve fornecer um URL, bem como uma opção para criar um novo tópico no fórum usando a citação (esta última funcionalidade está oculta a três cliques de distância e não funciona muito bem). Mas posso ver como seria útil criar wikilinks para tópicos que ainda não existem, que então se tornam postagens wiki quando alguém clica e as cria.

Acho que seu Garden é uma prova de conceito fantástica e, em grande parte, limitada por ter sido montada a partir do Discourse (você acha que funcionaria melhor como um wiki, um zettelkasten ou uma instância Circle/Notion?). Um PKM compartilhado pode facilmente desmoronar se a qualidade das postagens não for rigorosamente controlada: conteúdo profundo, mas inútil pode se tornar entrincheirado sem uma maneira de discernir a qualidade do conteúdo antes de clicar. Fóruns lidam com a produção de conhecimento colaborativo em aberto muito melhor do que PKMs convencionais. Aqui está um exemplo intermediário interessante: LessWrong tem um sistema de “blog da comunidade”, que na verdade é um fork do Reddit, e funciona brilhantemente para seus propósitos. Isso permite que eles eliminem o desafio de exigir que todos os contribuidores sejam bons no que fazem desde o início; as contribuições dos usuários (postagens e coleções de postagens semelhantes a playlists) não são canônicas (em contraste com o fato de geralmente haver apenas um artigo por tópico em um wiki).

3 curtidas
21

Algumas coisas seriam melhores, mas outras notavelmente piores. Eu sou definitivamente limitado pelo Discourse em algumas maneiras importantes para meus propósitos, mas acho que uma das principais é simplesmente a navegação, que parece semi-fácil de resolver se houver a vontade e, portanto, os recursos de desenvolvimento. Tenho uma ideia que estarei propondo (com algum financiamento) em breve que espero que ajude.

Também acho que é valioso pensar na ideia de estender o conceito de Moderador em contextos particulares de geração de conhecimento para ser algo mais como um “Curador”. A geração de conhecimento solo combina papéis/atividades de gerador e curador. Mas a geração de conhecimento coletivo provavelmente requer - ou pelo menos se beneficiaria significativamente de - pessoas confiáveis cujo papel ou parte de seu foco é citar, promover, organizar, polir e, de outra forma, destacar conteúdo, ideias, etc. que outros geram, e torná-lo mais acessível para aqueles que poderiam se beneficiar dele. Em teoria, a funcionalidade wiki no Discourse poderia ser parte da solução aqui, mas precisaria de alguns ajustes.

Há também muitas coisas interessantes para pensar em termos de geração de conhecimento colaborativo, “jardinagem digital”, etc. O objetivo é acabar com documentos singulares que representam uma perspectiva e compreensão coletivas? Ou representar múltiplas perspectivas simultaneamente? Ou alguma combinação dos dois. Posso ver muitas abordagens possíveis para lidar com essas e outras questões.

Em última análise, o desafio é que a CDCK provavelmente não está tão interessada nesses usos para o Discourse (o que posso entender, sua utilidade e, portanto, potencial de receita são muito mais incipientes e incertos neste momento). E, enquanto isso, poucas - se alguma - outras plataformas que se concentram na geração de conhecimento, por exemplo, Wikipedia/MediaWiki, realmente abordam os aspectos conversacionais e de discussão bem o suficiente, e especialmente a interação entre os dois. Em um mundo perfeito, discussões de alta qualidade ao longo de longos períodos de tempo poderiam adicionar incrementalmente a um resultado destilado de conhecimento, ideias, perspectiva(s), de forma fácil e fluida, mantendo a atribuição e, ao mesmo tempo, permitindo um resultado de “documento”/artefato bem formatado e consistente que seria realmente agradável de ler. A Wikipedia é novamente um bom exemplo do modelo atual que funciona, mas é altamente imperfeito e novas ferramentas e métodos são necessários para ir além de simplesmente documentar conhecimento para realmente gerar insights, explorar novas ideias, etc.

O Discourse pode ser usado para essas coisas agora, de algumas maneiras mais facilmente do que outras. Mas pode ser feito, tem a maior parte do que é necessário…

4 curtidas