Priorizar el Contenido Sobre los Componentes

Hola. Gracias por asistir a mi charla, Priorizar el Contenido sobre los Componentes. Mi nombre es Simeon Griggs, y soy de sanity.io, y principalmente quiero hablar hoy sobre sitios web con contenido editable. Y antes de entrar en eso, echemos un vistazo a una breve historia del contenido editable cuando funciona en computadoras.

Así que aquí hay un procesador de texto muy antiguo, quizás el primero en Windows 3.11. Microsoft Word, podrías haberlo usado en su momento. También tenemos Pagemaker. Esta es una de las primeras herramientas de publicación de escritorio en computadoras. Usé Quark Express en mi primer trabajo. Así de viejo soy. Pero la publicación de escritorio siempre se ha preocupado por cómo se ve el contenido, no necesariamente por lo que es. Y repetimos esto cuando llegamos a la publicación web también.

Así que los sitios web con contenido editable originalmente usando WordPress se veían así, y luego WordPress evolucionó para verse así. Y ahora se ve así. Y a medida que ha evolucionado más y más, todavía se ha centrado mucho en cómo se ve el contenido, no necesariamente en lo que el contenido es. Así que el CMS, Content Management System Backed Web, está muy preocupado por cómo se ve el contenido.

Ahora, en la segunda sección, quiero hablar sobre cuando miramos una página web, podríamos querer hacer la pregunta, ¿cuál es el modelo de contenido de esta página? Y esta es quizás una pregunta que no estamos acostumbrados a hacernos, pero es realmente importante también. Así que si yo estuviera construyendo una página web como esta, y probablemente hayas construido páginas web como esta, si me hubieran preguntado una vez, ¿cuál es el modelo de contenido de esta página? Diría, ¿qué quieres decir es una página? Y realmente no pensaría mucho más en ello. O ahora estamos en una era impulsada por componentes para el diseño y desarrollo web. Probablemente diría, bueno, es un encabezado y un héroe y un contenido y una barra lateral. Pero si volvemos a mirar esta página web en particular, y realmente miramos cuál es el texto real en la página? ¿Cuál es su significado? ¿Cuál es su intención? Realmente podemos desglosar esto. Y los datos son en realidad el nombre de una persona, es un presentador. Tenemos una etiqueta para el texto aquí. Tenemos un título de lección y un título de curso. Tenemos datos de idioma. El modelo de contenido está realmente compuesto por muchas pequeñas piezas individuales que se representan en una página web. Y separar el contenido de su presentación es realmente la idea clave detrás de esta charla aquí. Así que cuando tenemos un enfoque de diseño en lo que estamos haciendo versus un enfoque de contenido en lo que estamos haciendo, nuestro lenguaje de enfoque de diseño sería esta es una plantilla de página de lección.

Pero si estamos mirando el contenido en sí, y eso es en lo que nos estamos enfocando, en realidad nos estamos enfocando en lo que son esas cosas, no en lo que se convierten al ser renderizadas en este momento. Es una lección, es un curso, y es un presentador. Estos son datos con los que estamos tratando, no solo páginas web en presentación o componentes en presentación. Así que dime si esto te suena familiar en tu carrera en este momento.

Paso uno, necesitas reconstruir un sitio web. ¿Cuál es el paso dos a menudo cuando es un sitio web respaldado por contenido? Es que necesitas reconstruir el CMS porque el CMS fue desarrollado localmente en el diseño anterior solo para coincidir con ese diseño en ese momento. El sistema de gestión de contenido no se utilizó para albergar datos por lo que son. Se utilizó para albergar datos por su apariencia. Así que rompamos ese ciclo. Ese es el resultado de esta charla de hoy.

Así que en el paso tres aquí, curación explícita frente a experiencias impulsadas por el contenido. Nuevamente, quizás algunas palabras grandes que necesitan ser desglosadas. Así que veámoslo. Aquí hay un modelo de cómo podría ser el próximo sitio web. Si aplicamos una lente de curación explícita, podríamos decir este es el bloque héroe porque yo lo hice así. Puse el héroe en la parte superior de la página. Escribí cosas en él. Eso es lo que quiero que esté allí. Así que eso es lo que es. ¿Y qué pasa si tenemos una página web que en realidad debería ser más dinámica? ¿Qué pasa si queremos personalizar lo que vemos en cualquier momento porque es más relevante para el usuario? Si estoy en una parte del mundo donde actualmente es verano, lo cual no estoy, quizás sería mejor poner eso en el héroe. ¿Qué pasa si estaba cerca de una nueva ubicación que está abriendo? Sería mejor si eso fuera el héroe. Así que ese pensamiento de tener una curación explícita, como poner el héroe, lo que es, porque lo puse allí en este momento, en realidad es perjudicial para tus usuarios que podrían beneficiarse más al ver el contenido correcto en lugar de tu diseño preferido en este momento.

Así que una aplicación impulsada por el contenido dice que este es el héroe porque es lo más relevante. Así que eso está en la parte superior de la página porque es el mejor contenido para que ese usuario lo vea en ese momento. Y nunca lograremos esto al 100%. Pero lo que espero que te lleves de esto hoy es que queremos alejarnos lo más posible, solo un poco más a la derecha aquí en este diagrama, alejándonos de las experiencias explícitamente curadas y hacia las experiencias impulsadas por el contenido. Y siempre te van a pedir al final del día, pero quiero agregar un carrusel de reproducción automática y un video y agregar esas cosas. Y vas a tener que hacer eso en alguna pequeña medida, pero lo que sea que puedas hacer en tus aplicaciones web para hacerlas impulsadas por el contenido en lugar de explícitamente curadas, como una fina pieza de Lego que tienes que encajar cada pieza en su lugar, tanto como puedas hacer que eso sea impulsado por el contenido y dinámico, mejor y más larga vida tendrá esa aplicación.

Así que pongamos esto en práctica. Construyamos un sitio web.

Aquí tienes un sitio web. Probablemente has construido sitios web como este antes. Y quizás tu primera intención como diseñador o desarrollador es dividir esto en componentes. Y los componentes no son malos, pero solo necesitamos pensar en las props que se les asignan a esos componentes. Así que podríamos desglosarlo como un héroe, un banner, un llamado a la acción y una etiqueta. Y estos son razonables. Así que luego construimos nuestro código aquí, y aquí tenemos nuestro diseño y héroe, banner, llamado a la acción y etiqueta.

Y construimos esos componentes TSX y los ponemos en orden y los estilizamos con clases. Y luego necesitamos inyectarlos con algunos datos. Así que aquí en el lado izquierdo, tengo mis datos y coinciden con esos componentes. Y aquí es realmente donde comienza el problema, porque tengo mi héroe y banner y llamado a la acción, pero ¿qué va a pasar después? He tomado mis datos, los he puesto en props. Esos componentes se renderizan tal como están en el lado derecho. Y quizás tomamos esa estructura de datos y la ponemos en un sistema de gestión de contenido. Y así termina algo como esto. Y esto es genial. Tus autores pueden modificar el texto según lo necesiten. Pero ¿cuál es la siguiente cosa que absolutamente va a suceder? Te garantizo que sucederá el día después, tal vez el día del lanzamiento de este sitio web, alguien pedirá un cambio. En realidad, la distancia no tiene sentido allá abajo. ¿Podemos ponerlo en el subtítulo? Y en realidad, ¿podemos mover el subtítulo luego a la leyenda de la imagen, y la fecha en realidad necesita estar por encima de los pliegues. Necesitamos mover eso. Y ahora, estamos moviendo las props alrededor y nuestras partes editables de contenido ya no coinciden con lo que era la intención inicial de esas props. Y ahora todo funciona, y podemos modificar y hacer esos cambios en el front end según lo solicitado, pero el modelo de datos ahora no tiene sentido en comparación con el front end. Ahora, estás editando este campo llamado leyenda, y eso resulta estar editando el subtítulo en su lugar. Este no es un buen lugar para estar, y la razón por la que tenemos este problema, y aquí está la solución, lo hicimos funcionar, pero la razón por la que tengo este problema es porque hemos modificado esto, o hemos configurado esta estructura de contenido más bien, para modelar cómo se veía en lugar de lo que todo este contenido era. Así que vamos a corregir todos estos errores, porque esta no es manera de vivir.

El problema no eran los componentes. El problema era en realidad el contenido.

Estas claves son el problema. No deberíamos estar modelando un hero o un banner o un call to action, porque no sabemos realmente qué significan esas cosas sin los valores, pero si en su lugar modelamos un evento, que es lo que realmente estábamos viendo, y modelamos el título y el subtítulo, la distancia de ese evento, entonces realmente no importa dónde pongamos esas cosas en el front end, y la experiencia de edición de contenido siempre tendrá sentido, porque no estoy editando un hero subtítulo. Estoy realmente modificando el subtítulo de la cosa, y no importa dónde se va a renderizar en el front end, porque siempre será el subtítulo de un evento.

Y así, la conclusión principal que me gustaría que tomes de esta charla hoy, es que cuando tenemos un hero title, o un event title, estas son las dos estructuras de datos que podríamos tener. En el lado izquierdo, esa es nuestra presentación como datos. Hemos modelado cómo se ve esta cosa en este componente, en este diseño, en este momento. El contenido es desconocido. Un hero title podría ser literalmente cualquier pieza de texto, y no lo sabemos. La visualización es rígida. Si no estás renderizando la estructura de datos hero.title en el hero title, tienes una desconexión completa entre tus desarrolladores y tus autores, y el significado está implícito, pero no es explícito.

Así que si en su lugar, en el lado derecho, estamos pensando en el contenido por lo que es, en lugar de lo que parece, esto se llama contenido como datos. La presentación es ilimitada. Podemos renderizar el event title en el h1. También podríamos renderizarlo en una barra lateral, donde tenga sentido, y realmente no importa, porque siempre será el event title. La visualización es flexible. El significado es explícito, y así esa experiencia de autoría de contenido es mucho más comprensible para los autores de contenido, y el front end aún puede ser renderizado como necesitas que sea.

Así que en resumen, considera qué es algo, no cómo se ve. He dicho eso varias veces en los últimos minutos, así que realmente no necesitamos seguir con eso. Trata tu sitio web como solo una salida para tu contenido. Si no pensamos solo en este diseño en este momento, y pensamos en las muchas otras aplicaciones para esa misma pieza de contenido, se vuelve mucho más fácil razonar sobre, bueno, ¿cómo deberíamos estructurar este contenido de una manera que realmente otras aplicaciones puedan consumir este contenido, también, otras aplicaciones que no conocen el diseño de nuestra página web hoy. Los diseños impulsados por contenido son mucho más duraderos que los diseños curados. Si podemos construir una experiencia impulsada por contenido, es mucho más fácil adaptarla sin tener que reconstruir todo una y otra vez.