El modelo de contenidos en los gestores de contenidos o CMS

Los gestores de contenidos fundamentalmente gestionan contenidos de distinto tipo. Es evidente de para realizarlo adecuadamente, el sistema debe conocer ciertas características del contenido para poder reflejarlas, como sus diferentes elementos. Es decir, de alguna manera todos los tipos de contenidos deben tener reflejo en el CMS.

Es bastante común que los gestores de contenidos más sencillos e incluso el mismísimo WordPress apenas cuenten con tipos de contenidos y que en este sentido apenas ofrezcan profundidad en su modelo de contenidos. En estos casos basta con una página estática que se utilizará para contenidos muy simples y “entradas” que se componen de titular y cuerpo del texto. Este modelo de contenidos es aceptable cuando estamos hablando de blogs o Wiki.

Si bien esto puede ser acertado para muchos tipos de publicaciones, dada la sencillez de la aproximación del gestor de contenidos y/o la simplicidad en los requerimientos por parte del usuario, lo cierto es que lo mejor es delimitar bien los tipos de contenidos que se van a utilizar en el proyecto editorial. Es decir, deberíamos poder delimitar qué tipos de contenidos vamos a usar y realizar diferentes plantillas en función del tipo de contenido, que puede ser, por poner algunos ejemplos, opinión, entrevista, noticia normal, reportaje, noticia con vídeo de apertura, etc. Y dentro de cada género podemos contar con subgéneros, ya que el reportaje corto no es igual que el reportaje en profundidad.

Es bueno que el gestor de contenidos ofrezca la posibilidad, tal y como lo hace por ejemplo Drupal, de poder construir dentro del mismo CMS y sin ayuda adicional por parte de ningún equipo, los diferentes tipos de contenidos. Es conveniente que el modelo de contenido se defina antes de hacer la configuración inicial del gestor de contenidos, pero posteriormente esta configuración puede variar y es importante poder hacerlo dentro del propio gestor de contenidos para mayor flexibilidad e independencia.

Si bien los CMS mas potentes te permiten crear tu propio modelo de contenidos, éstos suelen tener una desventaja, y es que una vez creados los primeros contenidos que utilicen este modelo, la plantilla ya no se puede cambiar fácilmente, por lo que es necesaria una buena planificación inicial de la misma.

Actualmente se tiende a la atomización, de forma que los contenidos se dividen en las partes más pequeñas posibles para poder tratarlas individualmente de la mejor manera. Si en un extremo tenemos la típica entrada tradicional de WordPress con editor tinyMCE tradicional que cuenta con un cuerpo de noticia en el que podemos embeber cualquier material multimedia o red social, los editores modernos tienen a posibilitar la edición por bloques, en la que mezclaremos bloques de texto, con imágenes, galerías de fotos, vídeos, etc.

Esta atomización también es buena de cara a almacenar la información. Hacerlo en pequeñas “piezas” (titular, foto de listado, foto de apertura, etc) permite posteriormente reutilizar esa información, de forma que el gestor de contenidos podría realizar automaticamente una galería de fotos de imágenes del día usando las fotos de apertura de las noticias, por poner un ejemplo, o construir una “newsletter” diario con el titular y la entradilla de las mismas.

Estructurar demasiado el contenido o dar libertad total al editor de componer la noticia como mejor le parezca: a priori ambos extremos se deben evitar. Encorsetar la información demasiado es tan perjudicial como ofrecer libertad total a los editores si estos no tienen conocimientos avanzados de usabilidad y diseño. Ambos extremos pueden dañar la experiencia editorial. La línea ha de establecerse en cada caso en función de la redacción, de la experiencia de los redactores y la confianza que se pueda tener en sus capacidades.

Algunos gestores de contenidos, como WordPress o Joomla, han puesto de moda además los “custom fields”, que son campos en los que almacenar cierto tipo de información para poder luego visualizarla de cierta manera en el frontend. Por ejemplo podemos almacenar en estos campos la información de directores y actores de una película, o bien la plataforma de juego y el género si nos estamos refiriendo a un videojuego.

Como ya vimos a la hora de ordenar los gestores de contenidos, los gestores de contenidos más utilizados, los de código libre y gratuitos, suelen contar con un modelo de contenidos muy sencillo y enfocado a la realización de noticias y blogs. De esta forma, estos CMS se han lanzado a resolver los problemas más comunes con la intención de agrandar su base de usuarios lo más posible, dejando de lado las necesidades más minoritarias, que deben ser cubiertas con extensiones, si las hubiera, o bien realizando uno mismo el gestor de contenidos.

Separar contenido y presentación

En los albores de la Red, presentación y contenido siempre iban juntos. La principal forma de maquetar era usando tablas y el contenido iba habitualmente dentro. Hoy en día es impensable que esto pueda ocurrir. Mediante el lenguaje HTML se construye el armazón de la página, que aloja el contenido, pero el diseño se realiza mediante CSS. Estas instrucciones suelen estar en la hoja de estilo, que se encuentra en un archivo muy distinto de cada página, y contiene instrucciones de estilo que pueden ser usadas por gran parte de las páginas del proyecto para mantener una coherencia estética.

De la misma forma, en los CMS cada vez más se tiende a separar contenido de continente. Tradicionalmente el CMS se encargaba de componer y publicar el contenido, del backend, pero también generaba un frontend, o parte pública, que contiene un solo diseño para todos los dispositivos, generalmente “responsive”.

Aunque esto sigue siendo así en un gran número de casos, la tendencia actual es a desacoplar backend y frontend, de forma que el CMS genera los contenidos y, posteriormente, esos contenidos se “reempaquetan” en función del dispositivo que esté solicitando la información, siendo el diseño extremadamente diferente si la página la pide un ordenador de escritorio o un reloj inteligente.

Hoy en día es muy común “reempaquetar” los contenidos de mil y una formas, ya sea para enviarlas a Google en formato AMP, o para ser consumidas en Facebook o en los correos electrónicos, o en redes sociales. Esto solo es posible si separamos contenido de su diseño, de su presentación.

De nuevo, almacenar la información y los contenidos en las piezas más pequeñas posibles es beneficioso, porque permite personalizar su presentación así como realizar cambios en lote, siempre y cuando esas piezas de contenido estén etiquetadas de una determinada manera.

A la hora de evaluar un gestor de contenidos, es bueno cerciorarse de si éste está orientado a mostrar páginas completas o bien trata el contenido como partes independientes que se pueden reutilizar. No siempre esta última opción es la ideal, depende del proyecto, ya que si no es necesario reutilizar contenidos, tampoco tiene mucho sentido trocear y etiquetar dichos contenidos. E incluso tratando el contenido como páginas completa, esto no supone que no se puedan reusar contenidos vía RSS, XML, JSON, APIs u otros formatos.

Por otro lado, siempre hay que tener claro qué tipos de contenidos deben contar con url propia y cuáles no. Estos últimos están pensados para formar parte de otros tipos de contenidos que sí tienen entidad propia y, por lo tanto, url. Estoy hablando por ejemplo de los carruseles de diapositivas, por ejemplo.

En ocasiones, un tipo de contenidos puede ser mixto, es decir, por un lado puede formar url propio y, por otra, ser embebido. Un claro ejemplo pueden ser las coberturas minuto a minuto, esos directos que narran lo que ocurre en un partido de fútbol sin señal de vídeo en directo. En ocasiones estos tipos de contenido pueden llegar a tener entidad propia y en otras ocasiones el editor puede querer embeberlos en el cuerpo de una noticia.

Definir un modelo de contenido

Un modelo de contenido se define por tres elementos:

1. Tipos de contenido
2. Atributos
3. Relaciones

1) Tipos de contenido

Los tipos de contenido se deben definir en la fase de planificación o configuración del CMS y deben trabajarse con lo editores o redactores. Una vez acordados los tipos de contenidos, la estructura de cada uno, entonces se pueden configurar en el gestor de contenidos de la forma correcta. Cada tipo de contenido – noticia, página de producto, ficha de película- cuenta con sus propios campos o elementos que le definen y que probablemente son muy diferentes del tipo de contenido más simple, que suele ser la página básica.

Un tipo de contenido es como una plantilla para ese tipo específico de contenido. Cada vez que queramos hacer un artículo de opinión utilizaremos esta plantilla del CMS, que nos ofrecerá una serie de campos para rellenar, algunos de ellos obligatorios y otros, opcionales. De esta plantilla o tipo de contenido podríamos generar infinitos artículos de opinión. Cada tipo de contenido debe ser personalizado en función de las necesidades de cada tipo de contenido, es decir, cada tipo de contenido cuenta con diferentes atributos. Los atributos de una receta serán muy diferentes de los de una ficha de un videojuego, muchos de los campos serán específicos de cada tipo de contenido.

Organizar de esta manera los contenidos tiene diferentes ventajas. En primer lugar ofrece al redactor una experiencia “sobre raíles” con una interfaz específica para cada tipo de contenido y en la que sabe los campos que hay que rellenar de forma obligatoria para que ese contenido sea mostrado de forma correcta a los usuarios. Esto asegura un mínimo de usabilidad y de calidad. Organizar los contenidos por tipos también sirve para poder almacenarlos de esta manera para, por ejemplo, mostrar todas las entrevistas en un solo listado de forma automática tomando el tipo de contenido como criterio de clasificación. Otra ventaja es que se podrá restringir el acceso a ciertos tipos de contenidos a miembros del equipo que no lo necesitan. Por último, y no menos importante, esta organización por tipos de contenidos permite estructurar el contenido de forma que el redactor solo tenga que rellenar ciertos campos y no tenga que preocuparse mucho por el diseño. No hay que olvidar que un redactor no tiene por qué tener conocimientos avanzados de diseño y/o usabilidad.

Tal y como ocurre, por ejemplo, en Drupal, cambiar un tipo de contenido una vez que ya se han comenzado a elaborar contenidos sobre esa determinada plantilla suele ser problemático. Cuando esto ocurre, no es sencillo cambiar el tipo de contenido y, de hecho, en muchos CMS no quedará más alternativa que crear un nuevo tipo de contenido que albergue los nuevos atributos, lo que puede resultar confuso en el backend. Es por eso muy importante planificar bien los tipos de contenidos antes de comenzar a usarlos.

Si este desajuste llegara a ocurrir, los CMS más avanzados permiten que se hereden los tipos de contenidos. Es decir, que si necesitamos un tipo de contenido que varíe muy poco con respecto a otro en uso, se pueden crear una nueva plantilla que herede todos los atributos de la original y se pueda modificar. Esto también es útil cuando se piden ciertos atributos que posteriormente se dejan de utilizar. Tampoco es muy común, aunque existe, la posibilidad de crear tipos de contenidos a partir de algunos atributos reutilizables. Aunque es bastante rara, esta particularidad es muy útil para manejar los diferentes tipos de contenidos, sobre todo si son muy complejos.

2) Atributos

Son muchos los CMS que trabajan con la dicotomía valor – atributo. A la hora de crear un tipo de contenido, podemos añadir diferentes pares valor – atributo según nos interese. Por ejemplo, a la hora de realizar un tipo de contenido de crítica musical, se pueden habilitar los valores nombre del grupo, nombre del álbum, nombre de la canción, fecha del álbum y un largo etcétera. El atributo es la información específica de esta ficha de contenido, es decir, cada respuesta a cada valor es un atributo.

Los valores pueden ser de diferentes tipos: de texto largo, texto corto, fecha, número, checklist, etc. Dependiendo de la complejidad del CMS, éste puede permitirnos crear valores de todo tipo. Esto también tiene algunas ventajas como que podemos validar la información de muchos valores, de forma que en un campo de número de teléfono podemos controlar que ese número tenga las dimensiones correctas, y lo mismo con un número SKU, por poner otro ejemplo. Esto no sucede en los CMS que simplemente cuentan con título y cuerpo del texto donde se puede indicar lo que se desee sin ningún tipo de verificación.

Existen muchas formas de validar datos, ya sea contra ciertos unos intervalos o formatos de valor o mediante algún tipo de método personalizado o plantilla. Estas validaciones pueden ser múltiples, de forma que se valide si un elemento es un número o no, y si lo es comprobar si su extensión es correcta y, posteriormente, comprobar contra una base de datos si ese número existe o no, por poner un ejemplo.

Cuando se compone una noticia por bloques, como Gutenberg en WordPress o con los Paragraphs de Thunder, los contenidos se componen de pequeñas piezas o bloques, que pueden ser fotos, galerías de fotos, incrustados de redes sociales o bloques de texto. Es habitual que estos atributos nos permitan a su vez personalizar su contenido de diversas formas. Por ejemplo es habitual que cada bloque de texto nos permita, mediante un editor WYSIWYG (What you see is what you get, en sus siglas en inglés) dar formato a ese contenido.

Descomponer los contenidos en pequeñas piezas o atributos nos permite a su vez, como ya hemos indicado antes, usarlos para realizar diferentes clasificaciones e incluso reutilizarlas si fuera necesario.

Los CMS más avanzados los permiten insertar gran cantidad de atributos, mientras que los en los más simples se ha impuesta la práctica de los “custom fields” o valores personalizados, en los que se pueden almacenar pequeñas porciones de información que luego se pueden mostrar en el frontend de formas muy diferentes.

Hasta ahora hemos hablado de atributos explícitos, pero también existen los no explícitos. En muchos CMS cada elemento o pieza de contenido se almacena junto a un número de identificador único que no tiene por qué mostrarse en ninguna parte, ni siquiera en la url. No fue hasta el advenimiento de Google Noticias cuando este sistema exigió un ID único en la url y en la mayoría de los medios de comunicación comenzó a mostrarse. Aún hoy muchos, pese a que Google Noticias ya no opera en España, sigue usando este id en las urls. No solo la pieza entera de contenido puede identificarse, también otros elementos menores dentro de éstos, como el titular o el cuerpo del texto. Identificar todos los titulares nos serviría, por ejemplo, para enviar un boletín de noticias automático con todas las noticias del día. Estos atributos pueden servir también para mantener el orden administrativo dentro del CMS o para poner metadatos.

Contenidos Embebidos

Los elementos incrustados o embebidos cada vez tienen más importancia. De hecho, son la fuente de muchas noticias y artículos y deben ser correctamente reflejados en ellos. En este sentido se pueden insertar mediante bloques o widgets generalmente, aunque en los sistemas más sencillos hay que directamente pegar el código que provee la red social en el código fuente de la noticia.

Otros embebidos pueden tener origen en el propio CMS. Podemos realizar una galería de fotos y querer que esa galería ilustre una noticia, es decir, forme parte del cuerpo de la noticia como un elemento más. Paralelamente, estas galerías de fotos pueden tener también entidad y url propia si se necesita, pero no todos los embebidos deben tener entidad propia.

Para reusar los embebidos, muchos CMS utilizan “shortcodes”, pequeños códigos que insertados entre el texto son interpretados por el gestor de contenidos y reflejan su contenido. De esta forma por ejemplo en Joomla podemos embeber módulos dentro del cuerpo de las noticias, entre otras cosas.

Otros sistemas modernos, como WordPress con el editor de bloques Gutenberg, contienen bloques específicos para los incrustados. Al insertar una url de una red social, la interpretan y la reflejan en los tipos de contenidos con su formato adecuado. Cada red social o fuente de vídeo tiene su propio bloque de forma que para los editores es muy sencillo intercalarlos entre el texto.

Aunque tradicionalmente se han usado editores WYSIWYG en los que los redactores podían componer sus noticias como si estuvieran trabajando en Microsoft Word, hoy en día se tiende más a un modelo por bloques, y en esos bloques es donde encajan los incrustados. Antes de lanzar es bueno definir qué incrustados van a tener entidad propia (url) y cuáles no.

3) Relaciones

El modelo de contenido tiene dos variedades básicas:

• Independiente: Un tipo de contenido se describe a sí mismo.
• Relacional: Se describe por cómo se relaciona con otro contenido. Cuando un atributo es una referencia

Conclusiones

No existe un modelo de contenidos perfecto para todo el mundo. El modelo de contenidos debe tener en cuenta a los editores y, en general, a todas las personas que van a manejar el CMS y su nivel. En este sentido debe tener un buen equilibrio entre complejidad y flexibilidad adaptado a los recursos humanos. Desde los modelos de contenidos más sencillos a los más complejos, cada uno tiene sus ventajas y desventajas y usar uno u otro, sus consecuencias, que deben ser conocidas y aceptadas por el equipo.

Es bueno tener tipos de contenidos perfectamente acotados para determinados fines, pero los editores deben conocerlos y saber en qué casos son apropiados. Estos tipos de contenidos deben ser bien diferentes unos de otros; si son demasiado similares habría que plantearse eliminar uno de ellos.

De la misma manera, los tipos de contenidos deben ser los mínimos indispensables en aras de una mayor simplicidad. Más y más tipos de contenidos significa más documentación, más training y, a la larga, los editores suelen acabar utilizando una y otra vez los mismos.

El modelo de contenidos debe ser fijado antes del lanzamiento siguiendo criterios editoriales, por lo que la redacción, y concretamente los estrategas de contenido, debe tener un papel primordial en su elaboración. Los editores deben poder comunicar todos los tipos de contenidos que necesitan para que estén disponibles en el CMS, pero su papel no acaba aquí: deberían también aclarar otros temas como barra de navegación, secciones, taxonomía en general y un largo etcétera.

Aunque los tipos de contenidos queden bien fijados, en aras de una mayor flexibilidad, puede ser interesante que haya un tipo de contenido “comodín” con el que llegar a componer cualquier tipo de contenido usando trozos de html y CSS en el cuerpo del texto del contenido. En ocasiones, es lo más recomendable, sobre todo para páginas de un solo uso que no vayan a necesitar un tipo de contenido, como pueden ser las páginas realizadas por el departamento de ventas para ciertos anunciantes. Eso sí, no se debe usar este tipo de contenidos salvo en contadas excepciones.

• 
  Vulnerabilidad crítica encontrada en Jetpack de WordPress que fuerza actualización
• 
  Symfony 6.3 lanzado con grandes novedades
• 
  Jooma lanza la actualización 4.3.2