Búsqueda y enlace de temas en línea, por ejemplo, enlaces entre corchetes tipo Roam

Creo que es hora de que Discourse cuente con una forma más rápida de crear enlaces a otros temas en un foro determinado. Obviamente, ya existe el botón de enlace y el atajo en el editor, y si eres realmente brillante y conoces la URL exacta de un tema, incluso puedes hacerlo sin usar el cuadro de diálogo de enlace. Sin embargo, otras aplicaciones muestran que puede haber una manera mejor, más rápida y más sencilla: invocar un cuadro de diálogo de búsqueda y enlace en línea.

Ya existe un precedente para esto en Discourse con el comportamiento de búsqueda y enlace mediante @ para perfiles, así como con # para hashtags. Por lo tanto, simplemente sugiero que se añada la búsqueda y enlace para temas. Esto adoptaría un enfoque muy minimalista, muy similar a la búsqueda de usuarios con @, con una ventana emergente rápida de búsqueda de temas en línea basada en el texto que escribas en el editor, y no tendría ningún campo para el título ni otros controles. Funcionaría exactamente igual que la búsqueda con @, pero para enlaces. Utilizarías el teclado para confirmar el enlace, y la primera opción estaría resaltada automáticamente.

Una sintaxis recientemente popularizada para esto son los “enlaces entre corchetes”, es decir, [[enlace-al-tema]]. Escribes [[ y se invoca una búsqueda de títulos de temas, al igual que en las búsquedas de usuarios o hashtags. Otro enfoque común es el menú con barra (/), aunque por lo general se utiliza para múltiples funciones. Sin importar cómo se invoque, haría que crear enlaces entre temas fuera súper rápido y sencillo, algo que personalmente considero positivo, ya que fomenta que las personas hagan referencia a otro contenido existente y relacionado.

El principal problema que veo con esta sintaxis en particular es que es diferente, pero también similar, a la sintaxis wiki actualmente soportada. Sin embargo, la sintaxis de enlaces wiki se utiliza realmente en sistemas que también admiten la sintaxis de doble corchete [], pero específicamente para enlaces que requieren texto personalizado. Por lo tanto, una opción sería mantener esa misma distinción: usar dobles corchetes para un enlace a un tema que utiliza el título del tema como texto del enlace, o un enlace wiki tradicional para un título personalizado. Otra sería cambiar la sintaxis de enlaces en general, lo cual dudo que sea atractivo. Una tercera opción sería elegir alguna otra sintaxis de enlace en línea, es decir, un conjunto diferente de caracteres que invoquen la búsqueda de enlaces.

No me importa exactamente cómo se implemente; solo quiero poder buscar y enlazar en línea. Creo que sería un gran complemento para el ya excelente editor de Discourse y sus funciones generales de conveniencia. :slight_smile:

Dicho esto, soy consciente de que las funciones actuales del editor son bastante buenas y que esto es solo una característica de conveniencia, argumentablemente para un cierto subconjunto de usuarios. Definitivamente es de baja prioridad, incluso si hay acuerdo en que sería útil.

6 Me gusta

Existe algo similar cuando seleccionas y mueves publicaciones a un tema nuevo o existente. Hablando francamente, en su forma actual es una molestia:

  • La búsqueda tarda mucho tiempo.
  • Incluso si conoces el título del tema y lo escribes exactamente como está escrito (con la capitalización correcta, etc.), la búsqueda no encuentra el tema que quieres.
  • La búsqueda lo encuentra, lo seleccionas y luego la búsqueda continúa antes de que tengas la oportunidad de confirmar tu selección. Tu selección desaparece; la búsqueda ni siquiera lista el tema que seleccionaste.

Mi experiencia es justo lo contrario de eso, como se ve arriba.
Soy más rápido encontrando el tema correcto cuando uso la función de búsqueda estándar.

1 me gusta

Hola Oshyan, :slightly_smiling_face:

Me encanta la idea, pero…

El título del tema no es único, por lo que ahora, al buscar un tema, tienes información adicional como etiquetas y categorías para ayudar a identificarlo mejor. Sin embargo, la opción en línea podría ser demasiado abarrotada y, a veces, hay demasiados temas que coinciden con tu búsqueda para filtrarlos directamente en la línea.

Otra cosa:
Cuando usas este panel para insertar un enlace, debes confirmar tu elección con un clic en un botón, lo cual creo que es muy útil.

En la opción en línea, si no seleccionas el tema correcto, tendrás que borrar demasiado y quizás habrá más enlaces con formato roto que ahora.

Quizás exista una buena manera de hacerlo simple y rápido, pero por ahora creo que la solución del panel es más rápida y más amigable para el usuario.

1 me gusta

Todo esto suena como el resultado de fallos en la interfaz de usuario (UI/UX) o en las funciones de búsqueda, no como un problema con la idea del enlace en línea en sí mismo. Si aún no lo has hecho, te sugiero que abras un tema para discutir mejoras o correcciones al comportamiento existente de “mover publicaciones/fusionar”, dadas las experiencias que describes. Pero, suponiendo que ese tipo de problemas no ocurrieran en el contexto de mi enfoque de enlace propuesto, ¿lo encontrarías útil entonces?

¿Por qué asumes que la búsqueda en línea funcionaría de manera diferente a la búsqueda basada en la barra de herramientas? En cuanto al comportamiento de búsqueda y visualización, debería funcionar exactamente igual y, por lo tanto, tendría el mismo nivel de facilidad y utilidad en términos de encontrar y seleccionar el tema correcto. Mi preferencia sería que se diferenciara del cuadro de diálogo de enlace existente y se centrara en la velocidad y la facilidad de uso, funcionando de manera muy similar a la búsqueda de @ existente que muestra una pequeña lista contextual de resultados. La lista de resultados podría verse exactamente igual que la del cuadro de diálogo de enlace, pero no quiero un campo de título del tema, un botón de Aceptar/Cancelar, etc. Ya existe un atajo que lo abre.

Realmente no sé por qué habría más enlaces rotos. Todavía necesitas presionar Enter para confirmar el tema que seleccionaste de la búsqueda.

Bueno, definitivamente no es “más rápido”. Puede que sea más amigable para el usuario, seguro, pero mi sugerencia no es reemplazar el enlace de la barra de herramientas existente, sino agregar una forma más rápida de enlazar para usuarios más experimentados.

Supongo que Ctrl-K (atajo) es una buena alternativa y ya existe, por supuesto. Solo me gusta la capacidad de usar la sintaxis en línea para activar cosas útiles, y es algo que Discourse ya adopta con @ y #. Ambos también podrían ser accesibles solo con atajos de teclado o escritura manual sin búsqueda, pero, por supuesto, hay un valor agregado en cómo funcionan ahora. Estoy proponiendo que el enlace podría ganar un valor similar con este enfoque.

2 Me gusta

¡Ah, ok, entiendo! Gracias por la aclaración.
Esto sería una función avanzada y mantendría el panel de búsqueda original.
Me parece una buena idea. :slightly_smiling_face:

1 me gusta

Solo para mayor claridad, lo que tenemos hoy es:

CTRLALTf
buscar algo
ABAJO
a

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

El problema es que es extremadamente difícil explicarlo, aunque ofrece (según algunos) un conjunto de funciones más amplio que la propuesta de [[.

5 Me gusta

¡Oh, eso es muy interesante y bueno de saber! Sin embargo, creo que existe una diferencia valiosa entre la acción desde la sintaxis en línea y la acción desde un comando de teclado. La descubribilidad es una, la velocidad es otra.

Es cierto que, una vez que lo aprendes, usar esa secuencia es razonablemente rápido, pero al acabarlo de probar varias veces para hacer pruebas, definitivamente se siente más lento y menos fluido que mi experiencia en el (creciente número de) aplicaciones que soportan enlaces con corchetes []. Quizás esto se deba en parte a que implica un cambio de atención/visión, además del atajo de teclado nuevo y ligeramente incómodo. Este último podría superarse parcialmente con el tiempo (aunque mi geometría básica de la mano ve algunos límites en ese potencial), pero el cambio de atención siempre tendrá un costo al redactar un mensaje.

Resulta interesante para mí que tuvieras suficiente deseo de enlazar rápido como para crear esta secuencia de atajo de teclado algo inusual (sin duda porque muchos otros ya estaban en uso). Eso me sugiere un poco que quizás veas algún valor en la idea de los enlaces en línea en general… Pero tengo la impresión de que, por ahora, no hay mucho apoyo para mi sugerencia. Aun así, me gustaría saber al menos si hay algún obstáculo claro para ello, por ejemplo: «Usamos los corchetes para otra cosa», «no podemos añadir otro manejador en línea o ralentizará todas las consultas de la base de datos un 30 %» o lo que sea. :grinning_face_with_smiling_eyes:

De todos modos, espero que esto haya despertado al menos el interés de alguien. Me encantaría tener esto disponible, y me imagino que, una vez que otros usuarios tengan la oportunidad de probarlo, también les encantará (¿hay usuarios de Roam por aquí? ¿De Obsidian? ¿De Logseq?). Pero al menos espero haber despertado cierto interés en la idea de búsqueda y enlace en línea, y quizás en el futuro algo concrete esa idea. :folded_hands:

1 me gusta

Veo que [[ la búsqueda mágica es viable en un componente de tema hoy en día.

La única salvedad es que la autocompletación eliminaría [[ y lo reemplazaría con un enlace; no estoy seguro de cómo podría funcionar de otra manera. Esto hace que ]] sea un poco inútil, sin embargo.

Ten en cuenta que mantener la autocompletación abierta más allá de un límite de espacio puede resultar algo confuso.

2 Me gusta

¡Eso es bueno saberlo! Como no-programador, no tengo muy claro hasta qué punto es posible en los componentes de temas (parece que mucho, lo cual es una de las muchas cosas que adoro de Discourse). Así que eso es bastante genial.

Es cierto que en otros softwares el [[ se conserva y mantiene cierto valor incluso después de agregar el enlace. O mejor dicho, debería decir que la búsqueda con [[ no completa automáticamente un enlace tradicional, sino una referencia interna especializada. Dado que varias aplicaciones admiten ese formato de referencia, es portable en una variante de Markdown, lo cual es bastante útil.

Pero, en cualquier caso, en el contexto de Discourse, [[ es simplemente un atajo en línea familiar que, por suerte, es poco probable que se active accidentalmente. Estaría encantado con cualquier otro método basado en texto para invocar la búsqueda en línea que cumpla criterios similares, pero a pesar de las diferencias en cómo funcionaría en Discourse frente a, por ejemplo, Roam, sí veo cierto valor en que al menos la sintaxis sea la misma. Como dije, es algo así como un estándar de facto en crecimiento. :thinking:

Otra cosa que se me ocurre es que Discourse ya tiene su propia equivalente de enlaces internos que se renderizan de manera especial: ¡así funciona la citación! Así que “post:10, topic:200454” obviamente enlaza a tu respuesta a mi mensaje aquí. Dado que esta función de enlace está destinada específicamente a temas internos, podría simplemente usarla y mostrarla automáticamente como un enlace al tema en el momento del renderizado. No puedo decidir si esto está más o menos en línea con la forma en que funciona Discourse… :grinning_face_with_smiling_eyes:

Por un lado, ya existe esta forma de enlazar; esto solo sería una manera diferente de invocar la búsqueda y selección de enlaces, y es muy similar a las búsquedas existentes con @ y # como mencioné. Por otro lado, se aparta del comportamiento de enlace existente invocado por Ctrl+K, la barra de herramientas y otros atajos. Sin embargo, creo que el tipo de enlace “post:10” es más similar al concepto de enlace [[ utilizado en otras aplicaciones, así que me inclinaría ligeramente hacia esa opción… si tuviera algo de peso en el asunto. :wink: Por supuesto, sé que esto es más bien territorio de componentes de temas, ¡así que quizás sí lo tenga! ¿Podrías opinar sobre si el enlace estilo “post:10” podría implementarse desde una búsqueda emergente en un componente de tema?

Acabo de probar Roam para contexto.

@codinghorror ha mencionado en varias ocasiones en el pasado su gran preocupación por lo ineficaz que puede ser una búsqueda en línea al usar el editor, aunque supongo que en el contexto de la documentación y categorías específicas donde el contenido está más delimitado, podría ser útil.

En el pasado tuvimos discusiones sobre introducir una sintaxis del tipo #784, que suena muy similar a esta conversación.

Así es como funciona Roam:

  1. Escribes [[
  2. Automáticamente añade ]] y coloca el cursor en su interior.
  3. A medida que escribes dentro de [[ ]], realiza una búsqueda con autocompletado. Por ejemplo:

  1. Cuando finalmente decides el enlace, utiliza el título completo, por ejemplo: [[13 de agosto de 2021]]

  2. Maneja los cambios de nombre del documento original actualizando automáticamente el marcado en los documentos que enlazan.

Cualquier cosa similar a este comportamiento requeriría un plugin bastante extenso para Discourse, integrándose en puntos donde se renombran los temas, el motor de Markdown y más. Yo lo clasificaría en la categoría de varias semanas de trabajo complejo.

Actualmente tenemos:

4 Me gusta

Para una implementación interesante que vale la pena mencionar, te recomiendo echar un vistazo a https://obsidian.md. Utilizan esta sintaxis en archivos Markdown y parece ser similar a la especificación que @sam describió.

1 me gusta

OK, así que aquí es donde empezar a usar Roam como ejemplo comienza a fallar si se toma demasiado literalmente. :grinning_face_with_smiling_eyes: En realidad, dejé de usar Roam hace bastante tiempo, en parte porque su búsqueda en línea es completamente terrible. Obsidian es un mejor ejemplo y es lo que uso a tiempo completo ahora, pero requiere una descarga para probarlo, mientras que Roam (o Logseq) no lo hacen.

Antes de seguir adelante, gracias @sam por involucrarte tanto con esta idea, de la cual soy consciente puede parecer un poco descabellada. Y especialmente por darme una estimación aproximada del trabajo que crees que podría tomar, al menos de la manera en que has descrito que funcionaría.

Dicho esto, quiero enfatizar que mi sugerencia está inspirada en Roam y aplicaciones similares que utilizan esta sintaxis, pero no tengo interés en intentar replicar completamente todo sobre cómo funciona.

  • No necesita autocompletar el corchete porque el corchete no se mantendrá en el resultado en markdown (en Roam sí se mantiene, igual que en Obsidian).
  • La búsqueda de Discourse, ejemplificada por la búsqueda de enlaces con Ctrl-K o Ctrl-Alt-F, es mejor que la de Roam y, si se implementa en línea, probablemente me permitiría encontrar un tema de interés en un tiempo razonablemente corto (es decir, si crees que la búsqueda es útil en absoluto, entonces cumpliría con la necesidad descrita aquí tal como está).
  • El enlace usaría el título completo, tal como si copiaras/pegaras un enlace a un tema de Discourse en ese mismo foro dentro de un mensaje.
  • El cambio de nombre se manejaría de la misma manera en que Discourse ya lo hace para los enlaces internos.

Así que, para resumir, Roam es solo un ejemplo para demostrar el concepto y parte de la experiencia del usuario. Lo que realmente estoy sugiriendo es:

  • Un conjunto de caracteres poco comunes pero rápidos de escribir que puedan activar una búsqueda de temas en línea.
  • Búsqueda de temas en línea con Enter para seleccionar automáticamente el primer resultado.
  • Manejo regular de enlaces de Discourse en todos los demás aspectos.
  • Implementación de la manera que mejor se ajuste al enfoque de Discourse hacia estas cosas.

El resto de lo que he dicho son solo reflexiones sobre lo que podría tener más sentido o posibles enfoques para el problema.

Entonces, con todo esto en mente, ¿cambia eso la estimación del trabajo requerido? Si no es así, ¿qué exactamente sobre la solicitud de característica la hace mucho más complicada que, por ejemplo, Ctrl-Alt-F + A? Lo pregunto porque eso podría ayudarme a entender si puedo reducir el alcance de la solicitud para hacer los costos razonables, o si simplemente no vale la pena el tiempo necesario.

¡Gracias de nuevo!

4 Me gusta

Para mí, cuanto menos compatible sea Discourse con el Markdown estándar, más difícil se volverán algunas otras cosas, como mover contenido entre Discourse y otras herramientas que usan Markdown. (Mis sitios y documentación generalmente usan Markdown o MDX.)

Si se agrega alguna característica como esta, una idea alternativa para su implementación sería usar un sistema similar al de Confluence o Notion, donde el carácter / (barra) abre un menú.

Así es en Confluence:

Así es en Notion:

Si una característica similar estuviera en Discourse, una barra podría abrir un menú que incluya “Enlace” como opción. Si se selecciona “Enlace”, el usuario podría buscar otros posts y se insertaría un enlace Markdown normal en el editor.

No estoy solicitando la función, solo mencionando una idea alternativa de implementación que no haría que el contenido raw se alejara aún más del Markdown estándar. :slight_smile:

3 Me gusta

Si mantienes el contenido dentro de las estructuras existentes, un componente de tema puede funcionar perfectamente y la cantidad de trabajo no es enorme. El [[ es en realidad útil a nivel de implementación porque te proporciona un buen punto de referencia para detener la autocompletación.

Un ejemplo completo del flujo de trabajo podría ser:

  1. El usuario escribe: [[
  2. El editor completa con ]] y el cursor queda entre los corchetes.
  3. El usuario escribe el término de búsqueda, por ejemplo: [[tema en línea]]
  4. A medida que el usuario escribe, se realiza la búsqueda y los resultados se muestran en una lista de autocompletado similar a las @menciones.
  5. Usa las teclas arriba/abajo/enter para seleccionar.
  6. Una vez seleccionado, [[tema en línea]] se reemplaza con https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454.
  7. Si el usuario simplemente mueve el cursor más allá de ]], el autocompletado se cierra y [[tema en línea]] permanece tal cual en el markdown.

En general, construir algo así es totalmente factible en un componente de tema, no requiere modificar nada del lado del servidor y sería bastante sencillo de implementar. Diría que un experto podría hacerlo en un día o dos, mientras que a alguien con nivel intermedio probablemente le tomaría una semana más o menos.

5 Me gusta

Sí, los menús de barra son definitivamente un enfoque interesante y genial que me gusta y uso en muchas aplicaciones. Creo que no se me ocurrió como la forma de implementar lo que quería en este caso, porque ese enfoque implica invocar todo un conjunto de funcionalidades. En otras palabras, creo que sería extraño/impredecible, para quienes están acostumbrados a los menús de barra, que uno solo invoque una búsqueda de enlaces. Y aunque tener muchas otras funciones en un menú / sería algo con lo que estaría de acuerdo, suena como una solicitud de función notablemente más grande para mí.

Fantástico, ¡gracias por pensarlo detenidamente y darme una idea de la complejidad y el tiempo de desarrollo! Eso es extremadamente útil. Tendré que pensar si puedo aportar parte de mi propio dinero para ello, ya que tengo otras solicitudes quizás más importantes que probablemente necesito financiar para el desarrollo. Y ahora que sé más sobre los atajos de teclado, este es más una comodidad que una necesidad de todos modos.

2 Me gusta

Esto sería aún más interesante si se admitiera “crear un enlace con nombre” al añadir el enlace a través de a al texto seleccionado. Me encantaría que esta acción diera como resultado [texto seleccionado](enlace).

Desafortunadamente, parece que no se añade al búfer de deshacer.

2 Me gusta

Otros buenos ejemplos de flujos de escritura (trabajo) con / y [[ ]] de los que uno puede inspirarse son proporcionados por

y

3 Me gusta

Este sistema de gestión de conocimiento personal + concepto de foro es realmente vanguardista y potencialmente muy poderoso. No es “nuevo” (por ejemplo, véase “Bliki”, de 2003), pero no tiene por qué serlo. El contexto es nuevo y, por lo tanto, también lo es la idea. El mercado de PKM está creciendo muy rápido porque todo el mundo quiere algo parecido a lo que describes, pero no existe. Dicho esto, no creo que los wikilinks fueran la solución correcta; las funciones de “enlazar a resaltado” integradas en Discourse (como una mejora/variante de la funcionalidad actual de Cita) lo serían. El botón “Compartir” que aparece al resaltar texto dentro de una publicación debería proporcionar una URL, así como una opción para crear un nuevo tema dentro del foro utilizando la cita (esta última función está oculta a tres clics de distancia y no funciona del todo bien). Pero puedo ver cómo podría ser útil crear wikilinks a temas que aún no existen, que luego se convierten en publicaciones wiki cuando alguien hace clic y las crea.

Creo que tu Garden es una prueba de concepto fantástica, y en gran medida limitada por haber sido creada a partir de Discourse (¿crees que funcionaría mejor como wiki, zettelkasten o instancia de Circle/Notion?). Un PKM compartido puede desmoronarse fácilmente si la calidad de las publicaciones no se controla estrictamente: el contenido profundo pero inútil puede afianzarse sin una forma de discernir la calidad del contenido antes de hacer clic. Los foros manejan la producción de conocimiento colaborativo abierto mucho mejor que los PKM convencionales. Aquí tienes un ejemplo intermedio interesante: LessWrong tiene un sistema de “blog comunitario”, que en realidad es una bifurcación de Reddit, y funciona brillantemente para sus propósitos. Les permite eliminar el desafío de requerir que todos los colaboradores sean buenos en lo que hacen desde el principio; las contribuciones de los usuarios (publicaciones y colecciones de publicaciones tipo lista de reproducción) no son canónicas (en contraste con el hecho de que normalmente solo hay un artículo por tema en una wiki).

3 Me gusta

Algunas cosas serían mejores, pero otras notablemente peores. Definitivamente estoy limitado por Discourse en algunos aspectos importantes para mis propósitos, pero creo que uno de los principales es simplemente la navegación, que parece semi-fácil de abordar si existe la voluntad y, por lo tanto, los recursos de desarrollo. Tengo una idea que propondré (con algo de financiación) pronto y que espero que ayude.

También creo que es valioso pensar en la idea de extender el concepto de Moderador en contextos particulares de generación de conocimiento para que sea más parecido a un “Curador”. La generación de conocimiento en solitario combina roles/actividades de generador y curador. Pero la generación de conocimiento colectivo probablemente requiere, o al menos se beneficiaría significativamente de, personas de confianza cuyo rol o parte de su enfoque sea citar, promover, organizar, pulir y, de lo contrario, destacar el contenido, las ideas, etc. que otros generan, y hacerlo más accesible a quienes podrían beneficiarse de ello. En teoría, la funcionalidad wiki en Discourse podría ser parte de la solución aquí, pero necesitaría algunos ajustes.

También hay muchas cosas interesantes que pensar en términos de generación de conocimiento colaborativo, “jardinería digital”, etc. ¿El objetivo es terminar con documentos singulares que representen una perspectiva y comprensión colectivas? ¿O representar múltiples perspectivas simultáneamente? ¿O alguna combinación de ambas? Puedo ver muchos enfoques posibles para abordar estas y otras preguntas.

En última instancia, el desafío es que a CDCK probablemente no le interesan estos usos para Discourse (lo cual puedo entender, su utilidad y, por lo tanto, su potencial de ingresos son mucho más incipientes y poco claros en este momento). Y mientras tanto, pocas plataformas, si es que alguna, que se centran en la generación de conocimiento, por ejemplo, Wikipedia/MediaWiki, abordan realmente bien los aspectos conversacionales y de discusión, y especialmente la interacción entre ambos. En un mundo perfecto, la discusión de alta calidad durante largos períodos de tiempo podría agregar incrementalmente a un resultado destilado de conocimiento, ideas, perspectiva(s), de manera fácil y fluida, manteniendo la atribución y al mismo tiempo permitiendo una salida de “documento”/artefacto bien formateada y consistente que realmente sería agradable de leer. Wikipedia es nuevamente un buen ejemplo del modelo actual que funciona, pero es muy imperfecto y se necesitan herramientas y métodos más nuevos para ir más allá de simplemente documentar el conocimiento para realmente generar ideas, explorar nuevas ideas, etc.

Discourse se puede utilizar para estas cosas ahora, en algunos aspectos más fácilmente que en otros. Pero se puede hacer, tiene la mayor parte de lo que se necesita…

4 Me gusta