Krypton Solid

Contenido adaptable con WordPress

Contenido adaptable con WordPress

El diseño receptivo no solo desafía nuestras herramientas y enfoques para el diseño y desarrollo web, sino que también nos obliga a revisar nuestras formas de planificar y administrar el contenido. Los nuevos flujos de trabajo requieren las herramientas adecuadas. A primera vista, esto abre una oportunidad para sistemas de gestión de contenido (CMS) y plataformas de publicación completamente nuevos (y probablemente veremos muchos de ellos en un futuro próximo). Pero cualquiera que haya migrado de un CMS a otro sabe muy bien que el proceso no es sencillo. Entonces, ¿podemos adaptar un CMS conocido y popular como WordPress para ayudarnos a crear y administrar contenido adaptable?

Primero, necesitaremos aclarar las cosas. ¿Qué significa contenido adaptativo y por qué lo necesitamos en la era del diseño receptivo? También discutiremos las características y herramientas de WordPress que pueden ayudarnos a crear una plataforma de publicación amigable para el futuro. Nuestro objetivo es un objetivo alto: tener contenido que, una vez creado, se pueda presentar de manera flexible en diferentes dispositivos y en diferentes condiciones de visualización. Veamos qué tan cerca podemos llegar.

Contenido adaptable y por qué lo necesitamos

En su libro reciente Estrategia de contenido para dispositivos móviles, Especialista en UX y estrategia de contenido Karen MacGrane da una explicación detallada y bien argumentada de por qué necesitamos un nuevo enfoque para la gestión de contenido. Vamos más allá de la creación de sitios receptivos: estamos creando contenido que se puede publicar en diferentes plataformas y al que se puede acceder en varios dispositivos. ¿Qué pasa si mañana un refrigerador se convierte en la herramienta principal de alguien para consumir información? ¿Su sitio web está listo para un caso de uso de este tipo?

El diseño receptivo ha surgido principalmente de la necesidad de brindar a los usuarios móviles una experiencia adecuada. Honestamente, sin embargo, «móvil» es solo una parte de la imagen. Si pensamos en el futuro, podemos esperar fácilmente otras nuevas plataformas y dispositivos en los que aparecerá nuestro contenido: relojes, refrigeradores, anteojos, robots parlantes, cualquier cosa que uno pueda imaginar. ¿Significa esto que debemos crear una versión de «robot parlante» de nuestro sitio? Eso sería una locura. Entonces, ¿cuál es la solución? La solución es contenido adaptable: contenido que, una vez creado, se puede reutilizar en diferentes situaciones y escenarios. Suena genial, ¿no? Como lo logramos?

1. Contenido estructurado

Nuestro contenido ya no consta de «páginas». Consta de objetos, cada uno de los cuales debe considerarse un paquete de elementos predefinidos. Para cada componente estructural, un fragmento, el sistema de diseño daría cuenta de cómo debería mostrarse en todos los escenarios. Los fragmentos pueden presentarse en medios o formatos alternativos para diferentes casos de uso. Por ejemplo, si tenemos un video en nuestro objeto de contenido, podríamos tener un texto descriptivo o una transcripción para escenarios donde el video no se puede ver. O las anotaciones de un objeto pueden variar según el escenario, como cuando se comparten en las redes sociales, se incluyen en los resultados de búsqueda o se introducen en un sitio.

2. Contenido independiente de la presentación

Tenemos que dar el siguiente paso para separar el contenido de la presentación. En realidad, este es un principio importante de rediseño y una piedra angular de los estándares web. Pero tenemos que ir más allá y liberarnos de la mentalidad WYSIWYG. «Lo que ves» ya no es «lo que ven tus usuarios». Esa es una ilusión peligrosa. No deberíamos marcar nuestro texto con cursiva o insertar imágenes como HTML en el campo «contenido» de una «página». Solo debemos incluir una referencia a un objeto de contenido y dejar que nuestro sistema de diseño decida cómo presentar el objeto.

3. Metadatos

Cuanto más trabajo descarguemos a las herramientas del programa (después de todo, queremos que nuestro contenido se presente en varias plataformas automáticamente en función de escenarios predefinidos, ¿verdad?), Más información deberíamos proporcionar a esos sistemas sobre el contenido. Por ejemplo, en el pasado podíamos escribir en inglés simple que el autor de un texto era John Doe y marcar su nombre en negrita; ahora no podemos. Necesitamos un campo separado en nuestro CMS para ingresar el nombre y un conjunto de reglas sobre cómo presentarlo en diferentes escenarios.

4. Contenido reutilizable

Necesitamos una fuente única de contenido y un sistema de publicación basado en escenarios que pueda decidir cómo presentar el contenido solicitado a un usuario según su entorno (dispositivo, resolución de pantalla, velocidad de conexión, etc.).

¿Se pueden lograr todos estos aspectos con WordPress? MacGrane culpa a WordPress y otros programas de blogs por no apoyar a los editores como una herramienta para el contenido adaptable. Específicamente, todavía tenemos un editor WYSIWYG en WordPress, con un área de texto única para ingresar a nuestra «publicación». Desafortunadamente, esta es la situación a la que se enfrenta un diseñador que utiliza la versión sencilla y lista para usar de WordPress. Afortunadamente, WordPress es un poco más que un simple «software de blogs». Se ha convertido en una plataforma de desarrollo, un marco con el que un desarrollador puede proporcionar a los clientes una experiencia verdaderamente moderna y preparada para el futuro.

Transformando WordPress en una plataforma de publicación adaptable

Veamos qué herramientas tenemos como desarrolladores y cómo implementarlas para transformar WordPress en una plataforma de publicación adaptable para nuestros clientes.

WordPress comenzó su movimiento para convertirse en un CMS completo con la introducción de tipos de publicaciones personalizadas y taxonomías personalizadas. Otra característica poderosa que se puede utilizar en combinación con estos son los denominados campos personalizados. Este nombre simple se refiere a la GUI; de hecho, estos campos personalizados representan el conjunto de metadatos que se pueden asociar con cualquier objeto en WordPress. WordPress nos brinda la capacidad de crear una interfaz de usuario altamente personalizable para metadatos y una API flexible para almacenarlos y acceder a ellos.

¿Por qué es útil esto? Con los tipos de publicaciones personalizadas, ya no estamos encerrados en el concepto de «página». Podemos crear un tipo de publicación para cualquier objeto que necesitemos (como noticias, eventos, socios, lo que queramos) y podemos definir la estructura del objeto a través de este conjunto de metadatos. También podemos crear una interfaz de usuario separada para administrar los metadatos. Todo esto le da más estructura a nuestro contenido. Tan pronto como WordPress nos permitió crear metadatos de cualquier tipo, podríamos usarlos para almacenar alternativas para bloques de contenido integrados, como títulos y descripciones. (Por ejemplo, podríamos ver complementos de SEO que permiten un título y una descripción únicos orientados a SEO para cada objeto de contenido).

Cuales son sus limites? WordPress es muy criticado por no proporcionar constantemente una API para almacenar metadatos. Específicamente, podemos tener metadatos para publicaciones (y tipos de publicaciones personalizadas) y usuarios, pero no para taxonomías (un se necesita complemento para eso). Crear una interfaz de usuario personalizada en la pantalla de edición para una publicación no es tan fácil como podría ser. Faltan funciones y estándares predefinidos (razón por la cual los diferentes complementos lo hacen de manera diferente, dejándonos con un desastre, en lugar de un sistema). Pero los cambios recientes que ayudan a unificar y optimizar el panel de WordPress nos dan esperanza.

Otra gran característica de WordPress es que permite varias instancias del editor de texto enriquecido en una página. Esto se puede implementar con el wp_editor , que no solo crea el marcado de área de texto correspondiente, sino que también le asigna una funcionalidad de edición enriquecida y a los botones de selección de medios.

¿Por qué es útil esto? Con esta función, podemos dividir un solo campo de contenido en varios de acuerdo con la estructura de un objeto. Al hacerlo, agregamos un componente estructural a nuestros objetos. Además, cada área editable tendrá una GUI unificada y familiar que ayudará a los editores a insertar fácilmente el marcado necesario en los campos apropiados, incluidos los códigos cortos.

Cuales son sus limites? Deberíamos almacenar los datos ingresados ​​en áreas de edición enriquecida como los metadatos, y eso significa más llamadas a la base de datos, etc. Por lo tanto, este enfoque requerirá más atención a la optimización del sitio, como el almacenamiento en caché. No hay una función incorporada para representar estos datos en plantillas, por lo que tendremos que crearla.

Con este enfoque, la pantalla familiar de posedición se transformaría por completo:

Las herramientas de WordPress discutidas anteriormente nos permiten hacer que nuestro contenido sea más estructurado al definir objetos y reemplazar una sola gota de contenido con un conjunto de campos que almacenan las diversas partes y metadatos del contenido.

Ahora veamos qué herramientas tenemos para separar el significado y la presentación. En realidad, solo hay dos reglas básicas:

  1. Deshazte del editor visual.
  2. Evite el uso de HTML simple en los campos de contenido tanto como sea posible.

La primera regla es fácil de seguir. Con un filtro simple, podemos eliminar el editor visual para todos los usuarios.

add_filter('user_can_richedit', '__return_false');

La segunda regla es mucho más difícil de seguir. Ciertamente, no vamos a buscar todas las etiquetas HTML en nuestro texto; las que representan elementos verdaderamente semánticos están absolutamente bien. Pero cuando empezamos a insertar <div> en un objeto de contenido, nos metemos en problemas. Como sabemos, una columna en un escenario puede ser algo completamente diferente en otro.

Otro enorme El problema surge de la forma en que WordPress inserta medios enriquecidos, en particular imágenes, en los campos de contenido. Actualmente, imprime HTML simple que codifica el enlace a la imagen, su tamaño y el marcado de envoltura. Es el peor escenario posible para un enfoque adaptativo. ¿Y si necesitáramos otra variante de una imagen para un caso de uso particular? ¿Qué pasa si hemos trasladado nuestra biblioteca de medios a otro dominio? ¿Qué pasa si hemos cambiado el diseño de un objeto y, por tanto, necesitamos la imagen en otro tamaño? ¿Qué pasa si estamos implementando una técnica receptiva que requiere que especifiquemos varias fuentes para una imagen? Todos estos casos de uso son absolutamente imposibles si no modificamos el comportamiento predeterminado de WordPress.

Y, sin embargo, WordPress tiene casi todo para hacer posible el cambio a un enfoque adaptativo:

  • Cada elemento multimedia de la biblioteca multimedia tiene su propia entrada en la base de datos que almacena toda la información relevante, incluidos los datos sobre el archivo de origen. Pero WordPress no almacena un enlace absoluto a un archivo; más bien, almacena el nombre del archivo y la ruta al uploads carpeta por separado, para que la ruta completa se pueda construir dinámicamente.
  • WordPress tiene una funcionalidad de código abreviado que le permite hacer referencia a cualquier marcado dentro de los campos de contenido y crear el marcado real de forma dinámica cuando el contenido se imprime en la interfaz.

Poniéndolo todo junto, podemos representar el marcado de los medios con un código corto que contiene el ID del elemento en la biblioteca de medios. Un ejemplo muy básico se vería así:

add_shortcode('frl_image', 'frl_image_screen');
function frl_image_screen($atts, $content=""){

    extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' => 'medium'), $atts ));

    $out="";              
    $id = intval($id);
    if($id == 0)
        return ''; // no attachment

    $out = "<figure class="image {$size}">";
    $args = array(
        'class' => 'frl-image',
        'title' => ''
    );

    $img = wp_get_attachment_image($id, $size, false, $args);

    /* linked image */
    if($link == 'none'){ //no link      
        $out .= $img;

    } elseif($link == 'file') { //link to file
        $url = wp_get_attachment_url($id);  
        $out .= "<a href="https://www.webdesignerdepot.com/2013/04/adaptive-content-with-wordpress/{$url}">{$img}</a>";

    } else { //custom url
        $url = esc_attr($link);     
        $out .= "<a href="https://www.webdesignerdepot.com/2013/04/adaptive-content-with-wordpress/{$url}">{$img}</a>";
    }

    if(!empty($content))
        $out .= "<figcaption>{$content}</figcaption>";

    $out .= "</figure>";

    return $out;
}

Conclusión

¿Por qué es útil esto? No nos obliga a codificar el marcado para medios (u otros elementos de contenido). Al almacenar la referencia al objeto, posponemos la decisión sobre el marcado real al sistema de diseño, en lugar de al autor del contenido.

Cuales son sus limites? Este enfoque no es compatible con el núcleo de WordPress, por lo que tendremos que modificar el comportamiento predeterminado de WordPress para lograrlo.

Actualmente, los códigos cortos separan casi por sí solos la estructura de la presentación en nuestros fragmentos de contenido. Tenemos que usarlos de manera responsable creando un sistema de códigos cortos significativo para que nuestros autores y administradores de contenido puedan aprenderlo y usarlo.

¿Qué pasa con el contenido reutilizable, es decir, contenido que se dirige a diferentes casos de uso? El sistema de plantillas de WordPress admite temas secundarios, lo que nos permite cambiar de tema de forma dinámica y asignar una plantilla a un objeto de contenido según la jerarquía, que es una buena base para la reutilización de contenido. Con un motor de contenido central, podemos crear diferentes escenarios de diseño y alternar entre ellos según las necesidades del usuario.

La «mejor» forma de aprovechar todas estas oportunidades se está desplegando ante nuestros ojos. Por ahora, tenemos ejemplos de temas de WordPress receptivos y temas de WordPress solo para dispositivos móviles; y, en términos generales, nada nos impide tener un tema de WordPress para robots parlantes.

¿Le gustaría tener una visión más detallada del tema? ¿Utiliza alguna de estas (u otras) herramientas en proyectos para hacer que el contenido sea más adaptable? Háznoslo saber en los comentarios.

Imagen destacada / miniatura, imagen adaptativa a través de Shutterstock.

Deja un comentario