SCI Editorial Blocks nació de algo bastante cotidiano: pasar muchas horas escribiendo, editando y publicando en WordPress.
Con el tiempo empezamos a notar que ciertas decisiones se repetían demasiado. Cómo ayudar al lector a ubicarse dentro de un artículo largo, cómo destacar una idea importante sin romper la lectura, cómo mostrar contenido relacionado, cómo dar contexto rápidamente o cómo mantener una estructura editorial consistente sin reconstruirla cada vez desde cero.
Al principio resolvíamos cada necesidad de manera independiente. Un bloque por aquí, una clase CSS por allá, algún elemento copiado de una publicación anterior. Nada especialmente grave. Pero cuando publicas de forma constante, esas pequeñas fricciones empiezan a acumularse.
Y ahí apareció la pregunta que terminó dando origen al proyecto: si estas cosas forman parte de nuestra manera habitual de publicar, ¿por qué no convertirlas en herramientas propias dentro de Gutenberg?
Así empezó SCI Editorial Blocks.
Lo más leído: ayudar a que una buena lectura lleve a otra
Uno de los primeros problemas que queríamos resolver no estaba dentro del artículo, sino justo después de él.
Cuando alguien termina de leer una publicación, muchas veces ese es el mejor momento para ofrecerle otro contenido relacionado con los temas que ya le interesan. Sin embargo, hacerlo manualmente implica decidir enlaces, actualizar bloques y mantener esas recomendaciones con el tiempo. De ahí nació Lo más leído.
La idea es sencilla: aprovechar el propio contenido del sitio para darle continuidad a la lectura sin que cada artículo tenga que construirse como una pequeña landing page.
Para nosotros esto también forma parte de la experiencia editorial. Un buen artículo no debería sentirse como un callejón sin salida. Si alguien llegó buscando información sobre WordPress, infraestructura o seguridad, probablemente haya otras publicaciones que puedan resultarle útiles.
La navegación interna deja entonces de ser solamente un tema de SEO y empieza a ser parte de la experiencia del lector.
En este articulo: orientarse antes de empezar a leer
A medida que los artículos de SCI fueron creciendo apareció otro problema muy natural.
No todo el mundo lee de principio a fin. Algunas personas quieren entender primero de qué trata el contenido. Otras llegan buscando una sección concreta. Y cuando un artículo tiene varios subtítulos, desplazarse por él hasta encontrar lo importante no siempre es la mejor experiencia. Por eso incorporamos En este articulo, nuestro TOC o tabla de contenidos.
La intención no era llenar la página de navegación, sino ofrecer una pequeña brújula.
El lector puede ver rápidamente cómo está estructurada la publicación y saltar hacia la parte que le interesa. Y para quien decide leerla completa, sirve simplemente para entender el recorrido antes de comenzar.
Durante el desarrollo también aprendimos algo importante: el bloque no tenía por qué imponer su propio diseño.
Si Gutenberg ya permite controlar fondos, grupos y composiciones, preferíamos que “En este artículo” pudiera integrarse con ellos en lugar de comportarse como un elemento aislado.
Ese tipo de decisiones fueron definiendo bastante la filosofía del plugin.
Callout: cuando una idea necesita detener la lectura por un momento
También había otro patrón que repetíamos constantemente.
Dentro de un artículo técnico hay momentos donde una idea necesita un poco más de espacio. Puede ser una advertencia, una conclusión, una recomendación práctica o un dato que cambia la forma de interpretar lo que viene después.
- Podíamos usar negritas.
- Podíamos poner una cita.
- Podíamos crear una caja manualmente.
Pero ninguna de esas soluciones expresaba exactamente lo que queríamos hacer. Así apareció el Callout.
No queríamos algo estridente. La intención era mucho más editorial: crear una pausa. Un pequeño momento dentro del artículo donde el lector entiende que vale la pena detenerse unos segundos antes de continuar.
De hecho, esta propia publicación es una buena forma de ver cómo funciona. Preferimos mostrar los bloques dentro del contexto para el que fueron creados antes que diseñar una página de demostración artificial.
En resumen: entender primero, profundizar después
Otro elemento que usamos bastante en SCI es el resumen inicial. Hay artículos donde la respuesta principal puede explicarse en pocas líneas, aunque después necesitemos varios párrafos para desarrollar contexto, matices y ejemplos.
Ahí entra En resumen.
La idea es sencilla: permitir que quien llega buscando una respuesta rápida pueda encontrarla sin obligarlo a recorrer toda la publicación. Pero durante el desarrollo apareció una segunda cuestión. WordPress ya tiene un extracto. Entonces, si ese extracto ya explica correctamente el contenido, ¿por qué volver a escribir lo mismo?
Eso nos llevó a trabajar en la posibilidad de reutilizar el excerpt del artículo dentro del propio bloque.
Es una de esas mejoras que parecen pequeñas hasta que empiezas a publicar constantemente. Eliminar una tarea repetitiva aquí y otra allá termina haciendo que todo el proceso sea bastante más agradable.
Los subtítulos también forman parte del producto
Una de las cosas que hemos aprendido publicando durante estos años es que los subtítulos no son simplemente elementos de formato. Son descansos.
Especialmente cuando escribimos para gerentes, responsables de TI o personas que probablemente estén leyendo entre reuniones, correos y otras tareas.
Un artículo puede contener información muy buena y aun así resultar pesado si se presenta como una pared continua de texto. Por eso SCI Editorial Blocks también parte de una idea más amplia: utilizar la estructura del documento como parte de la experiencia.
Los subtítulos permiten anticipar el contenido, volver a encontrar una idea después y, junto con el TOC, transformar artículos extensos en textos mucho más fáciles de recorrer. No queremos hacer que los artículos parezcan más cortos. Queremos hacer que se sientan más fáciles de leer.
No queríamos otro constructor de páginas
Conforme aparecían nuevas posibilidades hubo un momento donde tuvimos que decidir hasta dónde queríamos llegar. Porque desarrollar bloques es tentador. Una vez que tienes uno, empiezas a imaginar controles adicionales, variantes, colores, bordes, iconos, espaciados y decenas de configuraciones.
Y antes de darte cuenta estás construyendo otro page builder. No era nuestro objetivo. Fue entonces cuando decidimos que SCI Editorial Blocks debía seguir siendo una herramienta editorial. Por eso fue que adoptamos una regla bastante simple: reuse first.
- Si WordPress ya sabe hacerlo, intentamos utilizarlo.
- Si Gutenberg ya ofrece un control, no necesitamos inventar otro.
- Si un Grupo puede controlar un fondo, no tiene sentido obligar al bloque a hacerlo.
Eso también nos permite reducir otra cosa que habíamos ido acumulando con el tiempo: CSS personalizado.
Menos CSS, más intención
Como ocurre en muchos sitios WordPress que evolucionan durante años, SciWebHosting había ido acumulando pequeñas reglas de CSS. Cada una resolvía algo. El problema aparecía después, cuando intentábamos recordar por qué existía.
Mover determinados patrones hacia bloques nos permite darles un propósito claro. El Callout es un Callout. El TOC es el TOC. “Lo más leído” tiene una función concreta. Ya no son simplemente estilos dispersos dentro del sitio. Son componentes.
Y eso hace que sea mucho más fácil mantenerlos, evolucionarlos y saber dónde tocar cuando queremos cambiar algo.
Este artículo también es parte de la demostración
Quizá la mejor forma de explicar SCI Editorial Blocks sea esta misma publicación.
Aquí puedes ver la lógica que estamos intentando construir: subtítulos que dan ritmo a la lectura, navegación mediante “En este artículo”, bloques de resumen, Callouts para destacar ideas y elementos que permiten continuar explorando contenido después de terminar. No desarrollamos estos bloques para una demo. Los desarrollamos porque queríamos utilizarlos nosotros. Esa diferencia nos parece importante.
Cuando una herramienta nace del uso cotidiano, sus prioridades suelen ser distintas. No intenta tener cien opciones. Intenta eliminar diez pequeñas molestias que encuentras todos los días.
Y el código está en GitHub
También quisimos que SCI Editorial Blocks pudiera verse por dentro. El código del proyecto está disponible en GitHub, donde se puede revisar su estructura, seguir su evolución y entender cómo hemos ido resolviendo cada una de estas necesidades dentro de Gutenberg.
Para nosotros tiene sentido hacerlo así. SciWebHosting siempre ha sido un espacio para compartir cosas que aprendemos trabajando con tecnología. A veces hablamos de infraestructura, otras de seguridad, hosting o WordPress. Esta vez la experiencia terminó convirtiéndose en software. Y en lugar de limitarnos a enseñar el resultado, también queremos enseñar cómo lo construimos.
Lo que empezó como pequeñas molestias cambió nuestra forma de publicar
Mirando hacia atrás, quizá lo más interesante de SCI Editorial Blocks no sean los bloques.
Es el proceso. Empezamos intentando eliminar pequeñas fricciones al publicar. Eso nos obligó a revisar cómo escribíamos, cómo organizábamos la información y qué cosas realmente necesitaba un lector dentro de un artículo.
De ahí aparecieron Lo más leído, En este artículo, En resumen, Callout y los distintos recursos para destacar ideas y puntos clave. No porque quisiéramos llenar Gutenberg de funcionalidades. Sino porque cada uno resolvía algo que habíamos encontrado utilizando nuestro propio sitio. Y esa sigue siendo probablemente la regla más importante para todo lo que estamos construyendo alrededor de SCI: primero usamos. Después observamos qué molesta. Y recién entonces decidimos si vale la pena convertirlo en software.
Deja una respuesta