Últimamente le ando dando vueltas a la idea de si la forma en la que se mantienen los blogs de notas es la óptima. Me refiero a cuando publicas en tu blog o en tu propia web un mensaje de texto corto y plano que cabría perfectamente en un tweet, pero que publicas en tu blog para poseer el control de él y no regalárselo a un multimillonario cabrón. (También me vale en un post de Mastodon o en un skeet de Bluesky).
Parece que lo que más se lleva hoy en día es que cada post sea su propio artículo independiente, porque es lo más simple. En cierto modo, estoy de acuerdo, porque permite darle una URL a cada idea, que es algo que a mí me parece súper importante porque estoy a favor de que cada concepto sea una URL, ya que permite referenciar ese concepto de forma única mediante un localizador propio. Esto viene bien para enlazar a ideas en el futuro.
¿Qué problemas detecto?
El problema que le veo a esto es que generas muchas URLs y mucho ruido por defecto. Esto creo que ocurre porque la mayoría de software de blogs se basa en la misma mecánica, una que grabaron en piedra los softwares de blog más populares de hace 20 años (Blogger, WordPress y LiveJournal) y que por alguna razón ha sido replicada por prácticamente todos los generadores de sitio estático de los últimos 15 años (Jekyll, Hugo, 11ty): cada post es una página individual; porque cada post es un artículo con su título, su contenido, y sus metadatos.
Por lo tanto, si escribes muchos posts, acaba volviéndose difícil ponerse al día. Hay que hacer mucho scroll y además algunos sistemas como RSS simplemente no resultan cómodos cuando cada día entran 40 posts cortos, que en muchos casos ni siquiera tienen título.
Por no hablar de que nunca me ha parecido muy cómoda la forma en la que se estructura toda esa información ante los ojos de un crawler como el de Google, porque toma cada idea por separado como una URL, y eso provoca que al final realmente sean piezas de información sin contexto separadas entre sí que no ayudan a nadie en el buscador y que, de hecho, sería casi mejor que se excluyesen de la búsqueda.
Otro problema es el propio título. ¿Qué título le pones a un post de 30 palabras? ¿Tiene sentido realmente? En WordPress, por ejemplo, también te invita a darle un título a cualquier post aunque sea de tipo Estado. Sí, el tema puede configurarse para ocultarlo, pero va a estar ahí igualmente, y resulta absurdo a mi criterio. A la vez, muchos generadores de sitios web estáticos parece que heredan ese comportamiento y asumen que un post tiene título. Cuando usaba Jekyll para esta página, recuerdo que las plantillas que usaba generaban un título automáticamente precisamente a partir de la fecha y hora precisamente porque sin un título, el post no compila.
Solución rápida y mi solución
La opción rápida para evitar esto parece ser moderarse y publicar con menos frecuencia, por ejemplo, una o dos veces al día. Pero entonces, ¿cómo decides lo que es útil de publicar y lo que no? ¿es justo retener un pensamiento que quieres compartir con el mundo simplemente porque han pasado menos de 8 horas desde el anterior?
Cuando lo comparamos con cómo son las cosas, por ejemplo, en Mastodon, X, Bluesky, donde los posts tienen un tratamiento más efímero o más de usar y tirar, resulta injusto. Cada cosa se publica, y hoy en día el incremento de ruido se compensa porque hay algoritmos (en X) o feeds (en Bluesky) que se ocuparán de que lo que sea realmente relevante se eleve para la gente que mire con menos frecuencia.
Mi idea consiste en simplemente usar un único post por día y agregar cada cosa separada al final del mismo como si fuese una sección independiente, o un párrafo suelto. Así que acabarías teniendo entradas que se llaman 2024-10-25, 2024-10-26… donde hay una lista de puntos, de secciones, o simplemente párrafos sueltos, donde cada párrafo representa una nota como la que pondrías en un microblog o en posts de X, Mastodon o Bluesky.
De cara al RSS, no se exporta un stream de notas sueltas que resulta dificil de leer, sino que cada elemento del RSS representa un día. En teoría, un lector RSS bien hecho debería detectar que el campo updatedAt de un blog post ha cambiado y actualizar su contenido, incluso tal vez volverlo a marcar como no leído, por lo que si actualizas la entrada de blog varias veces al día a medida que vas agregando más cosas al final, el cambio debería reflejarse en el RSS.
Pero podría dejarse como feature en vez de como bug, que no se mande una página de diario al RSS hasta el día siguiente; así también da una oportunidad final de reorganizar la página antes de que acabe el día.
En cuanto a lo de darle una URL propia a cada concepto: cada párrafo o cada sección podría llevar su propia ancla HTML. Si la ancla se mantiene estable, en principio no debería haber problema en indicar que /2024-10-25#p1234 es una nota diferente que /2024-10-25#p1235.
Podría experimentar con esto
Podría levantar un subdominio y probar a hacer un MVP. No tiene por qué ser un WordPress, podría ser un servidor más sucio hecho en Express.js, o en Rails o en Laravel.
Sin embargo, indudablemente me interesaría a la larga integrarlo en la página web principal si me gusta el concepto. Y dado que en el sitio web principal uso WordPress para poder escribir artículos completos como este de vez en cuando, habría que recopilar mis conclusiones y portarlas a WordPress.
Y llegados a ese punto, se podría evaluar si mejor es usar un sistema híbrido que me permita seguir escribiendo cada cosa como un post separado, pero luego lo combine todo en la plantilla o en el RSS. Eso también facilitaría que cada nota siga mandándose por separado a través de la integración con el fediverso que tengo activa en mi página web.