Video Summary and Transcription
La charla aborda la necesidad de un producto revolucionario que cambiará la forma en que las personas editan sitios web. Destaca los desafíos enfrentados en la edición visual y las limitaciones de los CMS existentes. La charla también enfatiza los beneficios de los CMS headless para los desarrolladores, pero reconoce el sacrificio de la edición visual. En última instancia, se busca una solución que satisfaga tanto a los editores de contenido como a los desarrolladores.
1. La Evolución de la Gestión de Contenido
Soy Matteo Frana, fundador de React Bricks. Permíteme mostrarte por qué necesitamos un producto revolucionario que cambiará la forma en que las personas editan sitios web. En 1996, crear sitios web era un proceso diferente. Se introdujeron Frontpage y CGI, pero se perdió la edición visual. CMS como Joomla! y WordPress trajeron de vuelta la edición visual, pero aún enfrentamos desafíos. Wix y Webflow ofrecen una gran experiencia de usuario para la edición visual, pero no son adecuados para sitios web corporativos. Necesitamos una solución que proporcione una imagen corporativa perfecta en píxeles y restricciones para los editores de contenido.
Hola a todos. Bienvenidos a mi charla. Soy Matteo Frana, fundador de React Bricks, y les contaré la historia de la gestión de contenido desde el principio. Así que prepárense y les mostraré por qué necesitamos hoy un producto revolucionario que cambiará la forma en que las personas editan sitios web.
Regresemos a 1996 cuando comencé a crear sitios web, usabas una herramienta como esta para escribir HTML que enviarías a un servidor a través de FTP, ¿y fue un dolor? No. Fue genial, tenía 17 años y tenía clientes que me pagaban por escribir este extraño código, pero la verdad es que esas páginas nunca cambiaron. Así que comencemos nuestro viaje desde HTML.
Cuando surgió la necesidad de editar páginas, apareció Frontpage. En el CD decía sitios web profesionales sin programación. Microsoft ya había agregado GPT, ¿no? Pero podías editar de forma visual con la ventaja adicional de tener temas hermosos pero inutilizables. Así que teníamos edición visual, pero el código que se creaba era un desastre. Por cada cosa que tocabas, agregabas cuatro niveles de tablas anidadas dentro de tablas. Y luego, los clientes querían editar el contenido por sí mismos. Pero si les dabas Frontpage, destruirían el sitio web antes de que pudieras decir Frontpage. Y así llegó CGI. Escribías programas en Perl, ejecutados en el servidor, que escribirían el código HTML por ti. Así que podías crear una interfaz hermosa para permitir que los clientes editaran el contenido en una database y luego leer de esta database y crear HTML, lo cual es poderoso. Y ASP y PHP lo hicieron aún más fácil con el lenguaje de plantillas.
Pero como ves, se perdió la edición visual de Frontpage. Y había otro problema. Estábamos reinventando la rueda cada vez. Así que se crearon CMS, Joomla!, luego WordPress, y volvimos a tener edición visual. Básicamente, HTML guardado en una database, y los usuarios podían escribir el título grande en comic sans verde sobre un fondo rojo. Así que agregamos campos personalizados a WordPress para recuperar nuestros queridos formularios grises. Toda la estructura, todo bien. Y perdimos la edición visual una vez más. Pero la necesidad de edición visual está ahí, por lo que Wix y Webflow la satisfacen con una gran experiencia de usuario. El problema es que no son adecuados para sitios web corporativos porque no necesitamos una plantilla que nos guste, sino la imagen corporativa perfecta en píxeles. Y también necesitamos buenas restricciones para los editores de contenido para asegurarnos de que el design no se pueda romper. Tan pronto como los editores entienden cómo modificar los márgenes y rellenos en Webflow, pueden usar su creatividad para romper el design.
2. El Desafío de los CMS sin Cabeza
Los CMS sin cabeza brindan libertad a los desarrolladores en el frontend y datos estructurados en el backend. Sin embargo, se sacrifica la edición visual, lo que lo convierte en una pesadilla para los editores. Necesitamos una solución que beneficie tanto a los editores de contenido como a los desarrolladores.
Así que tenemos una gran edición visual, pero necesitamos alejarnos de ella. Y así llegamos a los CMS sin cabeza, un sueño para los desarrolladores porque somos libres de hacer lo que queramos en el frontend y tenemos datos estructurados en el backend. Pero adivina qué? Volvemos a tener grandes formularios y adiós a la edición visual. Oh sí, tenemos la vista previa instantánea que es como escribir un documento de Word o Pages en un formulario de barra lateral y ver la vista previa en la página. ¿Crees que es una gran experiencia de usuario? Bueno, si esto es un sueño para los desarrolladores, seguramente es una pesadilla para los editores. Por eso necesitamos algo nuevo que sea finalmente bueno tanto para los editores de contenido como para los desarrolladores. Bienvenidos a React Bricks. Creas bloques de contenido como un componente React y los haces editable visualmente usando los componentes de React Bricks como ImageText, ReachText, Repeater y obtienes una edición visual en línea. Y para las otras props que necesitas, por ejemplo, cambiar el padding o elegir el color de fondo, puedes asignar props a controles cibernéticos, solo las props que deseas con los valores que deseas y que forman parte del sistema de diseño. Para cada texto, solo las funciones de renderización de ReachText que deseas habilitar para cada estilo, y tienes JSON estructurado guardado en esa bahía. Los editores de contenido utilizan tus bloques de contenido tipo Lego, lo cual es divertido y no pueden romper el diseño, y no se pierden entre entidades y relaciones abstractas, ven páginas, crean páginas, este es un concepto simple y claro. Entonces, los editores no necesitan nuestro apoyo porque es fácil, tiene Word o Pages, ya saben cómo usarlo. Y no nos olvidamos de incluir funciones de colaboración, multilingüismo, permisos detallados, capacidad para reutilizar contenido en páginas cruzadas, usar datos de fuentes externas como Shopify y mucho más. Pero no me creas a mí, aquí tienes a Giulio Michelon, fundador de la agencia digital Belka. Soy Giulio, el fundador de Belka. En Belka, desarrollamos productos digitales para otras empresas y recientemente tuvimos el placer de trabajar con uno de los principales bancos italianos. Evaluamos diferentes herramientas como Headless o Puerto, pero al final decidimos quedarnos con Reactbricks por un par de razones. La primera es la conformidad con el GDPR, una plataforma completamente europea y la segunda ha sido la facilidad de uso de la herramienta. No esperábamos que fuera tan fácil de adoptar. Tenemos buena experiencia con React, lo cual ayudó, pero al final, el equipo de soporte al cliente fue de gran ayuda para adoptar esta nueva solución. El equipo de marketing de nuestros clientes también está muy contento debido a la facilidad de uso de la herramienta. Es realmente fácil componer páginas, así que al final puedo recomendar realmente Reactbricks como una herramienta para desarrollar nuevos sitios web. Bien, se acabó el tiempo. Estás a solo un minuto de probar Reactbricks. Solo necesitas una cuenta gratuita y ejecutar el comando CLI npx create Reactbricks app en la última versión, y en el sitio web encontrarás un tutorial paso a paso con gamificación para convertirte en un experto de Reactbricks en un par de horas. Por último, acabamos de abrir nuestro programa de socios para agencias, así que contáctame, por favor. Gracias. Gracias. ¡Hagamos que la edición de contenido sea divertida de nuevo!
Comments