Editores de texto de los CMS

La edición de contenidos es realmente importante en un gestor de contenidos web. En realidad es el lugar en el que los periodistas o creadores de contenido pasan la mayor parte de su tiempo componiendo sus informaciones. Los editores de contenido, aunque eso está cambiando, como veremos posteriormente, suelen ser programas habitualmente realizados en JavaScript que facilitan mucho la labor al periodista, quienes pueden componer documentos en HTML sin conocer este lenguaje de programación.

En este capítulo abordaremos única y exclusivamente la edición de lo que es habitualmente el cuerpo del texto de la noticia. Esta edición está íntimamente relacionado con el modelo de contenidos así como todo el tema de las plantillas, del frontend, que abordamos en otros capítulos. Dependiendo, por ejemplo, del modelo de contenidos puede haber ciertas plantilla a disposición de los editores, con diferentes campos editables, que se corresponden con los géneros periodísticos y que pueden tener un diseño y unos colores específicos (Por ejemplo, el diseño de los artículos de la sección de sociedad serán muy diferentes a los de deportes y a los de nacional). El periodista deberá en cuenta el diseño de la página a la hora de trabajar la información en el editor de texto si este le da una gran libertad audiovisual.

Habitualmente el periodista tiene control total sobre diversos aspectos de su composición, como el titular, la entradilla y el cuerpo del texto, pero habitualmente no tiene acceso a otras partes de la página, como la cabecera o el pie, y puede que tampoco tenga acceso en ese momento a las barras laterales, que suelen contener publicidad y otros elementos como las noticias más vistas de esa sección por ejemplo.

Evolución de los editores de contenido

La edición de textos en los gestores de contenidos, si bien en muchos CMS se mantiene intacta desde hace mucho tiempo, también ha ido evolucionando. En los albores de Internet era habitual componer las noticias en editores de HTML externos al CMS como el extinto Homesite y muchos otros. El archivo final se subía por FTP al servidor y no había buena previsualización, es decir, se comprobaba directamente en producción.

Poco a poco los editores de contenidos se fueron integrando en los CMS y los periodistas comenzamos a ver campos para introducir texto y dejamos de ver código. La edición de textos hacía mucho que ya se venía realizando en programas como MS Word, por lo que no extrañó que los editores de texto de los gestores de contenido tomaran prestada su interfaz, reproduciendo sus botones más conocidos. En esos momentos esta interfaz era perfecta, puesto que era de sobra conocida, facilitaba mucho una maquetación sencilla y además en esa época no se solían incluir muchos elementos audiovisuales a excepción de la imagen de cabecera.

Con más o menos botones o opciones, esta forma de introducir la información de los CMS se ha mantenido estable durante largo tiempo, pero esto está cambiando ahora con la introducción de los editores de bloques. Este tipo de edición de contenidos es cada vez más popular (y ya está por defecto en WordPress) porque enriquece la maquetación al considerar cada elemento de las noticias como un ente independiente con su propia naturaleza y opciones de personalización. Así, es más fácil insertar elementos como sumarios, citas, ladillos, galerías de fotos y un largo etcétera. Poco a poco se tiende, por tanto, a la atomización máxima, a dividir los contenidos en las partes más pequeñas posibles y a editarlas de forma separada, no todo el texto junto en un solo bloque. En la práctica, ahora no solo tenemos un campo editable, el cuerpo del texto, sino tantos campos editables como párrafos, sumarios y elementos tenga cualquier información.

El editor clásico WYSIWYG

Como ya hemos visto, después de una época sin editor de texto, pronto se popularizaron los editores clásicos tipo MS Word, también llamados, WYSIWYG (What You See Is What You Get (en español, «lo que ves es lo que obtienes»). Aún hoy siguen siendo los editores de muchos gestores de contenidos de gran calidad y no es de extrañar, porque son muy familiares para cualquier persona que deba componer un contenido sencillo.

Estos editores, muchos de ellos de código libre y gratuitos, permiten fácilmente cambiar la tipografía, tamaños de letra, alinear texto, insertar tables e incluso incluir algún elemento multimedia embebido entre los párrafos de texto. Algunos también permiten previsualización e incluyen corrector de textos, autoguardado y algunas otras características avanzadas si pasamos a la versión de pago, como veremos posteriormente.

Antes de la llegada del autoguardado, muchos periodistas componían sus noticias en un procesador de textos para posteriormente pegarla en el CMS justo antes de publicarla, habitualmente usando el botón de pegar en texto plano o desde Word. Esto era así porque no era infrecuente componer la noticia y después de un buen tiempo de trabajo, el software fallara y perdiéramos el texto completamente. Hoy en día los CMS no cuentan con este problema en su mayoría.

Los primeros editores eran tan sencillos que simplemente permitían introducir negritas o cursivas sin necesidad de saber cuál es la etiqueta HTML que lo permite. A partir de ahí fueron evolucionando hasta el día de hoy, en el que los principales editores de texto clásicos trabajan en diversas formas de posibilitar la edición de textos colaborativa dentro del propio editor, algo largamente pedido y esperado por los periodistas, pero que no es sencillo de resolver desde el punto de vista técnico.

Lo cierto es que estos editores de texto son ideales para webs del tipo blogs o wikis y por eso siguen siendo tan popular incluso ahora, en nuestros días, cuando la fiebre de las bitácoras personales ya ha pasado en gran medida. Los editores WYSIWYG más populares, principalmente porque son usados por los CMS de código libre más famosos, son:

1) TinyMCE. Hasta la llegada del editor de bloques Gutenberg, fue el editor de texto por defecto, por lo que es muy popular. Su versión gratuita, de código libre, puede ser utilizada gratis para la comunidad. Escrito en JavaScript, incluye español y se integra con gran facilidad en cualquier CMS. Las opciones avanzadas y los plugins ya pertenecen a la versión de pago.

2) JCE: Es muy similar al anterior, con la salvedad de que es el editor por defecto de Joomla. También permite no solo editar contenido, sino previsualizar, insertar tablas y un largo etcétera. La versión gratuita el también plenamente funcional.

3) CkEditor: Es el editor elegido por Drupal y sigue exactamente la misma senda que los anteriores. En Drupal se pueden configurar distintos tipos de editores de texto y asignar a distintos roles, de forma que los editores avanzados, aquellos con mas conocimiento técnico, pueden disfrutar de editores de texto con más características que el resto de la redacción, como puede ser el acceso al HTML para editar código e insertar embebidos. Esta característica avanzada es bastante valiosa para evitar problemas.

Es más que recomendable que en las redacciones existan los llamados “power editor” o editores avanzados, un un buen conocimiento no solo de periodismo, sino de lenguajes de programación web que puedan ayudar a sus compañeros con problemas técnicos sencillos y tengan acceso y conocimiento a características avanzadas. Estos editores avanzados están a mitad de camino del periodismo y el ingeniero informático.

Hay que recordar que el trabajo del periodista es conocer y publicar las historias más interesantes posibles así como construir audiencias y para realizar este trabajo no necesariamente deben tener conocimientos de lenguajes de programación. De hecho, la función de los mejores CMS es que el editor se olvide del código, que no sepa ni que existe.

Editores por bloques

La moda, en el momento de escribir estas páginas, son los editores por bloques. Como ya hemos comentado, existe una tendencia actual a dividir las piezas periodísticas en los elementos más pequeños posibles para poder así darles un formato individualizado a cada uno y mejorar así su aspecto visual. Pasamos así de editar un solo campo que contiene toda la noticia, a editar tantos bloques como elementos tenga. Es decir, que si pegamos un texto desde Libre Office a una editor de texto tipo Gutenberg, ahora editor por defecto de WordPress, éste último creará tantos bloques como párrafos tenga ese texto, y lo mismo ocurrirá con el resto de elementos como sumarios, fotos, etc.

Esta tendencia es perfectamente razonable. Existe una gran necesidad de maquetar cada vez páginas más y más atractivas y el número de embebidos y elementos audiovisuales cada vez es mayor en los artículos periodísticos, sobre todo desde que las redes sociales se convirtieron en una gran fuente de información. Pero también cada vez más son necesarios diferentes formatos para mostrar imágenes, galeríos de fotos o vídeo, audio y muchos otros elementos que no son texto.

El gran espaldarazo a los editores por bloques fue la decisión de adoptar Gutenberg por parte de WordPress como editor por defecto, no sin gran polémica y alboroto por parte de millones de usuarios contentos con el editor clásico. Pero este espaldarazo no surgió de la nada: fue allanado por “page builders” o editores de páginas que se hicieron tremendamente populares como Divi o Elementor. Actualmente, por la elección de Gutenberg, que cada vez es más y más potente y fiable, estos últimos editores deben decidir su futuro, que probablemente será independizarse de WordPress y formar sus propios CMS clonando el modelo de negocio de Wix o Squarespace.

Siguendo la estela del editor clásico, en el editor por bloques, el periodiste no ve en ningún momento código, simplemente elige el tipo de bloque que desea a elegir entre una larga lista, y luego lo configura a su gusto dentro de los límites de personalización que tenga a su disposición. Siempre se puede añadir un ID a cada bloque para realizarle cambios vía CSS. Todos estos bloques, independientes entre sí, pueden moverse en cualquier momento y algunos de ellos se pueden convertir en reutilizables, de forma que podamos insertar el mismo en diferentes informaciones.

Para los más nostálgicos, en el editor de bloques se puede configurar también un bloque especial que clone la experiencia de edición del editor clásico, de forma que éste pueda ser añadido a la noticia como un bloque más.

No es tarea de este capítulos repasar los detalles de las implicaciones de la llegada de Gutenberg, pero sí se puede comentar que ha supuesto todo un tsunami en los gestores de contenidos por diversos motivos, incluyendo el cambio de lenguaje de programación con el que está hecho el editor por bloques y que puede afectar mucho en el futuro teniendo en cuenta la popularidad de WordPress.

En los grandes medios de comunicación ya hemos visto cómo se tiende a no dejar demasiada libertar a los periodistas, puesto que éstos no tienen por qué saber de UX y diseño. En este caso es probable que solo se ponga a sus disposición un número limitado de módulos y con solo las características necesarias para cumplir su función y a la vez seguir la línea de diseño del diario. Otra opción puede ser poner a la disposición de los periodistas plantilla preformateadas, una por cada tipo de contenido, con todas las opciones aceptables disponibles. Dejar que un periodista libere toda su creatividad en cuanto a diseño no suele ser la opción más recomendable.

Futuro de los editores en los CMS

Ya hemos adelantado que los principales editores de textos están trabajando duro para perfeccionar la edición colaborativa, emulando de alguna manera la edición de texto en Google Drive. En general los editores de texto clásico tienden a ser cada vez más sofisticados y ofreciendo en su versión premium, es decir, de pago, características avanzadas y plugins que hagan la experiencia de edición más completa y profunda. De esta forma intentan conseguir un ecosistema de código libre sostenible.

Por otro lado tenemos a los editores por bloques. Hemos hablado de Gutenberg, pero en Drupal también disponemos de Paragraphs, un plugin que emula, aunque a cierta distancia en cuanto a tipos de bloques y características, la experiencia de Gutenberg. Esto quiere decir que no será extraño que el editor por bloques se generalice.

Algunos CMS son en sí editores de bloques y algunos de ellos están teniendo gran éxito para un tipo de público que quiere buenos resultados en cuanto a diseño en poco tiempo, con una experiencia “drag and drop” sencilla y asequible. Estamos hablando de CMS como Wix o Squarespace, que actualmente tienen la misma cuota de mercado que Drupal, según W3techs.com. Esto da buena cuenta de lo importante que es un buen editor de contenido: puede ser la clave para que un CMS triunfe.

Artículos relacionados: