10 Febrero 2017

8 pifias a evitar al desarrollar modelos de contenido en Drupal

Hace poco escribimos un post sobre las diferencias entre tipos de contenidos, taxonomías y entidades en Drupal, y cómo se debe usar cada uno. Incluso teniendo claros estos conceptos y cómo usarlos aun hay muchas posibilidades de meter la pata al desarrollar un modelo de contenido en Drupal. Aquí os dejamos 8 lecciones que hemos aprendido en nuestro tiempo como desarrolladores Drupal.

1. Usar tipos de contenido para representar activos de contenido (content assets)

Un error muy común en Drupal es usar un tipo de contenido para representar cosas como fotos, vídeos, etc que están asociados con otro tipo de contenidos. Esto se deriva de la pobre gestión de medios que estuvo disponible al principio dentro del sistema. Los desarrolladores tuvieron que dar acceso directo a un directorio de archivos en el servidor para que los administradores de sitios web cargaran y administraran imágenes y videos, lo cual era un método muy poco elegante.

La alternativa a esto fue crear tipos de contenidos para las fotos, vídeos,... y usar los campos de referencia del nodo para permitir a los usuarios añadir esos activos a un nodo. La desventaja de hacerlo así es que ahora tienes cientos, si no miles, de nodos individuales que representan lo que debería estar representado dentro de un campo en un tipo de contenido. ¡Vamos, otra pequeña chapuza!

Con la salida de las entidades y el lanzamiento del módulo Media, la administración de los archivos multimedia ha mejorado bastante. Por defecto usamos el módulo Media porque elimina todo el desorden de tener nodos que representan activos dentro de la pantalla de administración de contenido y además crea una interfaz agradable donde los administradores de sitios web pueden ver, editar y eliminar archivos multimedia.

2. Usar taxonomías para representar contenidos

Las taxonomías están hechas para categorizar contenidos, no para representar contenidos. Esto parece muy claro pero nos hemos topado con sitios en los que se usaban taxonomías para crear tipos de contenidos.

Una buena regla es si los términos de tu vocabulario no se utilizan repetidamente en múltiples partes de tus contenidos, o si la asociación de metadatos en los términos de vocabulario es lo que esperas que tus lectores se involucren más que el término en sí, probablemente esto debería ser un tipo de contenido.

3. Usar tipos de contenidos para organizar otros tipos de contenidos

A menos que estés creando una jerarquía en tu contenido (cómo incluir artículos en un newsletter), los tipos de contenido no se deben usar para organizar el contenido. Se pueden añadir campos a las taxonomías si por lo que sea necesitas añadir metadata al vocabulario de una web. Nosotros, en la medida de lo posible, tratamos de aprovechar las taxonomías sobre los tipos de contenido para poder mejorar el flujo de trabajo de los editores de contenido.

4. Crear nuevos campos para representar el mismo tipo de datos que los campos existentes

Drupal crea múltiples tablas en tu base de datos por cada campo que creas en tus tipos de contenido. Tu base de datos puede hincharse rápidamente y las consultas de contenido pueden comenzar a afectar el rendimiento.

Drupal permite reutilizar estos campos que ya has creado en el sistema en múltiples tipos de contenido. Por ejemplo, si tu estas usando una imagen en un post y en un evento puedes fácilmente reutilizar el mismo campo para ambos contenidos. Esto mejorará el rendimiento y te ahorrará tiempo construyendo tus tipos de contenido.

5. Crear demasiados tipos de contenido

Es muy sencillo caer en la trampa de crear un tipo de contenido para todas las cosas de tu website. Nos hemos encontrado con webs que tenían más de veinte contenidos, con varios de ellos representando el mismo tipo de contenido.

Piensa largo y tendido a la hora de crear contenidos. Quizás no necesites dos tipos contenidos para tu blog, uno para tu blog de animales y otro para tu blog de política. Incluso si estos tipos de posts no son exactamente iguales,  piensa que puedes aprovechar campos condicionales o taxonomías para clasificar este tipo de contenido de modo que le dará al editor los campos que necesitan para crear contenido y te permite mostrar ese contenido en diferentes lugares de tu sitio web.

6. Crear tipos de contenidos que los gestores/editores no tienen capacidad de producir

Es fácil escuchar a tus clientes y crear los tipos de contenido que te piden crear. Pero hay que preguntarse: ¿tiene mi cliente la capacidad o los recursos para trabajar con el tipo de contenido que me está pidiendo? Muchas veces la respuesta es no. La decisión es tuya como desarrollador que eres.

Los sistemas de gestión de contenido son como cuando vas a un buffet libre, piensas que podrás comerte los 5 platos distintos de comida hasta que le has dado 3 bocados a uno. Entonces descubres tu error. No puedes. Pues lo mismo ocurre con los tipos de contenido, los clientes quieren todos los tipos de contenido posibles pensando que podrán manejarlos, pero la realidad es que no.

Tómate tu tiempo en comprender las formas en que tus clientes generan contenido y cuánto pueden producir realmente para cumplir con sus objetivos deseados. Además, realiza investigaciones sobre el contenido que su público realmente quiere y mantén una conversación con tu cliente sobre la eliminación de cualquier tipo de contenido que no sea necesario para satisfacer las necesidades de sus usuarios.

7. Permitir a los administradores dar formato al contenido dentro del editor WYSIWYG cuando no es necesario

No vamos en entrar muy a fondo en este tema para evitar acalorados debates en los comentarios. Si observamos esto desde un punto de vista de la experiencia editorial, puede ser más fácil para los creadores de contenido rellenar campos en lugar de tener que dar formato al contenido dentro de un campo WYSIWYG.

8. Usar campos para administrar la presentación de contenido

Los campos de los tipos de contenido no se deben utilizar para administrar cómo se muestra el contenido al usuario final. la gente usa campos para, por ejemplo, asignar clases a campos de contenido, asignar nodos a regiones de una página e incluso ordenar nodos dentro de una lista. Puede haber algunos casos en los que hacer esto tiene sentido, pero es más apropiado aprovechar las herramientas de Drupal para administrar la presentación de contenido, como paneles, vistas, …

Estas son sólo algunas de las pifias más comunes que se nos han ocurrido. ¿Se te ocurren otros fallos? ¡Dejalos en los comentarios!