La aparición orgánica de un Zettelkasten: Las ventajas de hacer de mi Second Brain un sistema más distribuido

Mejor aislar un Zettelkasten, que hacerlo encajar con sobreingeniería. Cómo estoy separando partes de mi Second Brain y haciéndolo más fluido.

La aparición orgánica de un Zettelkasten: Las ventajas de hacer de mi Second Brain un sistema más distribuido
Photo by Christa Dodoo / Unsplash

Mi sistema de Gestión del Conocimiento Personal se va llenando de contenido y surge la necesidad de revisar cómo está estructurado.
El error que cometí en muchas de mis implementaciones anteriores fue tratar de diseñar excesivamente desde el inicio. Excesiva arquitectura, demasiado diseño inicial del sistema, limita la posibilidad de que  emerja de forma orgánica: esto es, respondiendo a las necesidades reales que surgen de su propia evolución en lugar de querer anticipar todos los casos de uso.
En mi caso, la solución por la que voy a optar en este punto, es aislar un Zettelkasten como una pieza  separada de todo el resto de actividad que gestiono en Logseq.

Planteando el problema: mezclas de información, navegación y conexiones

La plétora de opciones a la hora de trabajar con las información en aplicaciones como Logseq, Roam Research u Obsidian conlleva, como todo gran poder, una gran responsabilidad. En este caso, la de no volverse loco haciendo mucha ingeniería para que las cosas encajen todas juntas.
Por la manera en la que estoy trabajando en Logseq, básicamente vuelco todas mis anotaciones diarias, reflexiones, diálogo interno, etc. Hago un uso muy intensivo del log diario (Journal) para capturar ideas, decisiones y más. Pero es que además, como Logseq es la aplicación cuyo sistema de enlazado, etiquetado y queries me hace sentir más cómodo, gestiono aquí todo mi sistema de lo que son "notas" en el sentido más Zettelkasten de la palabra.

Mi grafo estaba hasta ahora, eso sí, lejos de parecerse ligeramente a la limpieza de un Zettelkasten.

Mis notas permanentes están redactadas con bastante cuidado y de forma atómica, pero siguen viviendo dentro del mismo cajón que todo el resto de notas. En la misma instancia, la misma "carpeta" que notas bibliográficas, artículos escritos para el blog, notas temporales, etc.
Está claro, que todo esto se puede gestionar con un buen sistema de etiquetas, queries y demás, pero llegaré ahí en unos cuantos párrafos.
La razones para ver esto como un problema a resolver son algunas como una mezcla excesiva de resultados en búsquedas, poca claridad en la vista de grafo para visualizar conexiones (precisamente porque hay un exceso de conexiones), una sobrecarga de tipos de información al querer navegar, enlazar y consultar, etc.

Aislando un Zettelkasten y varios grafos de Logseq

Te explico cómo lo estoy resolviendo y más abajo, si te interesa, puedes leer otras opciones que he evaluado por si a ti te sirven o te parecen más adecuadas que la mía.
Esta no he querido hacer todo este diseño desde el inicio, sino dejar que el propio sistema me vaya mostrando el cuello siguiente de botella a resolver. Como dice David Allen en GTD y le escuché también a Tiago Forte sobre C.O.D.E., cada paso del proceso resuelve un problema pero, inevitablemente genera la necesidad de resolver uno nuevo.

Una mesa de trabajo, un Zettelkasten y un archivo

Recordé que Sönke Ahrens menciona en "El método Zettelkasten...", que Niklas Luhmann tenía en realidad, propiamente hablando, dos ficheros. Las notas bibliográficas no se guardaban en el mismo lugar que las notas permanentes. Y también que tus escritos se generan en el sistema, nacen de la conversación en él, pero no forman parte de él.
Todo esto me dio la idea de experimentar en esa línea.
Mi solución al problema se basa en la separación en tres grafos de Logseq que cumplen tres funciones: banco de trabajo, Zettelkasten y archivo de contenidos.

Grafo uno: Workbench (Banco de trabajo):

Cumple la función de ser el inbox apunto todo sobre ideas, toma de decisiones, el log diario, etc. Respecto a la parte del método Zettelkasten, aquí es donde se generan las notas temporales (fleeting notes), que no hace falta realmente conservar para nada y donde se guardan mis notas bibliográficas.**
Me gusta porque aquí no hay que pulir tanto las cosas. Como es un banco de trabajo se pueden sacar herramientas, quitar y poner, ensuciar y probar de todo. A este nivel, estoy bastante contento con cómo tengo todo configurado, mi flujo de trabajo. Pero además, en este grafo, como trabajo muy basado el los Journals de Logseq, puedo hacer más el loco, apuntar cosa que luego no voy a rescatar, etc. Un buen sistema de etiquetas, convenciones y flujos y listo.
Ojo, no hablo de recolectar sin ton ni son ni apilar información que no tenga sentido, sino de poder rápidamente acceder a las cosas y decidir procesar o descartar, permitiéndose licencias, más divagación, etc.

Grafo dos: Zettelkasten

Aquí va lo que hemos leído y entendemos como el archivo de notas como tal, el slip box. Aquí van las notas permanentes y los posibles índices.
A nivel de diseño del sistema en cuanto a convención de plantillas, uso de etiquetas y cosas así, es realmente fácil de mantener porque todo sigue un único estándar. Una vista de grafo super limpia y fácil de navegar, una búsqueda en la app que sólo de resultados de notas permanentes, etc.
Si además, en algún momento decidiese cambiar de idea y reintegrar esto a una sola instancia, hablamos de una carpeta llena de archivos en Markdown enlazados. Sería extremadamente fácil devolverlo al sistema principal o a otra aplicación.

Grafo tres: Archivo de trabajos

Para almacenar los artículos del blog y otros posibles trabajos finales nacidos del Zettelkaten como hilos de Twitter, Newsletters o cosas así.
Los aíslo por lo que he explicado antes y, la razón por la que lo mantengo también en Logseq y no lo paso a otra aplicación como Google Docs, por ejemplo, es por pragmatismo. Ya que todo el proceso, hasta este punto habrá ocurrido usando Markdown (y en Markdown va también al blog), tiene sentido no cambiar de formato. Como añadido a eso, la destreza en el uso de la aplicación, reduce casi a cero la inversión en gestionar la transferencia de textos de un grafo a otro o cualquier modificación posterior.

Otras soluciones de diseño y por qué las he descartado

Etiquetas y filtros

Con la sofisticación de los sistemas actuales, sería bastante viable solucionar todo el problema que planteo a través de un sistema robusto de plantillas, filtros y etiquetas. Sin embargo, hay algo que no hay que pasar por algo: la carga cognitiva y la fricción.
Me gusta moverme por el sistema de manera súper fluida. No quiero, en pleno proceso creativos, andar gestionando filtros para incluir o excluir tipos de contenidos de una búsqueda o tener que recurrir a listados enormes generados por una query embebida en una página. Que todo se pueda gestionar junto, no significa que se deba ni que sea necesario. Uso este tipo de soluciones en Logseq pero para otras partes del proceso, en el workbench.

Uso de más de una aplicación o cambio a otra

También lo he considerado. Conozco bien Obsidian, por ejemplo. Pasé unos mese usándolo y sé que su sistema de filtros en la vista de grafo y su búsqueda son, a día de hoy más potentes. Pero de nuevo hablamos de pragmatismo; en este caso en forma de querer ser eficiente.
Soy un firme defensor de ser maestro en las herramientas que uso, no en balde fui usuario de Vim durante bastante tiempo.

Cada atajo de teclado, cada segundo ahorrado cambiando de app, cada expansión de texto automatizada y cada acción que se deja a cargo de la memoria muscular bien pulida es una liberación para el proceso creativo.  Cuando se trabaja en aclarar pensamientos, tomar notas en una reunión o hacer el esquema de ideas para un artículo, esos pequeños momentos de fricción suponen realmente una gran diferencia.

Logseq me funciona realmente muy bien, así que más o menos las mismas razones que aplican para no usar dos aplicaciones diferentes, aplican para no cambiar de app. Considero que no estoy resolviendo un problema con la aplicación, sino adaptando el diseño del sistema a una necesidad y estado actual del desarrollo del mismo.
Cuidado con la trampa de ir saltando de app en app cada poco tiempo para que otra resuelva alguna carencia. A medida que tu sistema avance volverías a topar con algún momento de evolución de tu sistema, o limitación de la app y vuelta a empezar el ciclo.


Este es ahora mismo, el siguiente punto de inflexión de mi sistema de Gestión del Conocimiento pero seguiré documentando y aprendiendo en público.
Me gustaría saber si tú te has encontrado en algún momento con una necesidad similar y cómo la has resuelto en tu caso. Me puedes dar un toque en Twitter y me encantará intercambiar enfoques.