No pierdas la cabeza: evaluación de personas sin cabeza

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Storyblok, un CMS sin interfaz amigable con un editor visual, componentes anidados y bloques de contenido personalizables para sitios web y aplicaciones. ¡Gracias!

Con muchas opciones vienen muchas decisiones, y es fácil ahogarse en todos los muchos y variados beneficios declarados de los diferentes sistemas. Entonces, ¿cómo aborda la evaluación de estas opciones? Hace dos semanas, Aaron Hans arrojó luz sobre los casos de uso de quedarse sin cabeza y para qué sirve aquí en Smashing Magazine. Hoy, le daré un poco de información básica sobre el panorama de CMS, así como algunas preguntas para ayudarlo a tomar una decisión.

¿Sin cabeza? ¿Qué?

La gestión de contenido sin cabeza es la práctica de desacoplar su sistema de gestión de contenido (CMS) de su front-end. A diferencia de los sistemas tradicionales (o "monolíticos"), el CMS no es directamente responsable de impulsar el front-end web. En su lugar, el contenido se envía al front-end desde un sistema remoto a través de una API, y el front-end consume estos datos para representar sus páginas. Esto puede ocurrir en tiempo de ejecución (cuando un usuario llega a su sitio web) o en tiempo de construcción (el contenido se renderiza y genera por adelantado), pero el concepto importante aquí es la separación entre el contenido y las capas de presentación.

Si planea crear un sitio usando Jamstack, terminará dirigiéndose en esta dirección de forma predeterminada, pero el enfoque es igualmente válido para otros tipos de proyectos, utilizando lenguajes del lado del servidor como PHP, . Neto o Rubí.

Pero, ¿por qué es esto incluso una cosa?

Headless surgió originalmente como una forma de administrar contenido para Jamstack (antes de que Jamstack obtuviera su nombre elegante), pero el enfoque ha ganado fanáticos por muchas razones. La gestión de contenido sin cabeza nos permite implementar contenido en diferentes plataformas, por lo que puede usar el contenido de su sitio web en una aplicación móvil nativa, por ejemplo.

Headless también nos permite reparar las deficiencias de otros sistemas. Por ejemplo, Shopify. Si bien es excelente en lo que hace, no es el sistema más flexible cuando se trata de administrar el contenido de su tienda en línea. Usando un CMS sin cabeza, podemos administrar de forma remota contenido adicional para un sitio de Shopify y brindar más poder y flexibilidad de lo que tendríamos de forma predeterminada.

Hace poco trabajé en un proyecto que hacía exactamente esto: ampliar el contenido que ofrece Shopify con contenido adicional más rico de un CMS sin encabezado (usamos Contentful para este proyecto en particular, pero cualquier CMS sin encabezado podría hacer este trabajo). El uso de una solución de gestión de contenido sin cabeza nos permitió crear estructuras de datos personalizadas que podíamos adaptar a nuestras necesidades. Por ejemplo, el cliente quería resaltar los ingredientes que usaba en la elaboración de sus productos, y Shopify realmente no proporciona una buena manera de manejar esto. Creamos un nuevo tipo de contenido en Shopify y permitimos que se agregara a una página de producto personalizada llena de otros tipos de contenido que creamos.

El contenido de Shopify se extrajo y se sincronizó con Contentful, y esto se convirtió en el principal controlador de datos para el sitio, con las API de Shopify solo involucradas en las comprobaciones del nivel de existencias y la creación de cestas. Poder agregar este tipo de datos enriquecidos a un sitio de comercio electrónico basado en SaaS fue increíblemente poderoso.

Logramos este resultado usando Nuxt para construir el sitio, pero igualmente podríamos haber elegido integrar datos del CMS directamente dentro de las plantillas de Shopify. Jamstack fue elegido como el mejor enfoque aquí, pero headless es lo suficientemente flexible como para que se pueda usar en casi cualquier lugar. Siempre que tenga acceso a algún tipo de secuencias de comandos a través de JavaScript o un lenguaje de fondo más tradicional como PHP o .Net, puede integrarlo en su flujo de trabajo.

Desacoplar su contenido de su capa de presentación puede ser realmente poderoso. Permitir que su contenido se conecte a diferentes plataformas y capas de presentación ayuda a mantener su contenido consistente en sus puntos de contacto y ayuda a garantizar que su contenido no se fragmente en un montón de sistemas diferentes administrados por diferentes equipos.

Imagina que tienes un producto del que quieres hablar en tu sitio web, en una aplicación móvil y también en anuncios programáticos. Con headless, podría tener un repositorio de contenido central e implementar el mismo contenido (o aspectos del mismo) en todas estas plataformas y más. Con una administración de contenido más tradicional, necesitaría administrar el contenido para diferentes plataformas por separado.

¡Esto suena genial! Entonces, ¿es Headless adecuado para mí?

Hay un montón de cosas a considerar al elegir su enfoque. Hay beneficios de quedarse sin cabeza, pero también hay costos. Aquí hay algunas preguntas que debe hacerse al considerar el enfoque sin cabeza:

¿Se siente cómodo con los requisitos de conocimiento para hacer la división?

Mucha gente piensa que cambiar a headless puede "eliminar" la necesidad de desarrolladores de back-end, pero la verdad es que la mentalidad para estructurar datos de manera efectiva y crear modelos de contenido que funcionen y se escalen bien sigue siendo muy diferente de la mentalidad necesitaba ser un gran desarrollador front-end la mayor parte del tiempo. Todavía hay una brecha de conocimiento y eso todavía tendrá que ser llenado.

Si está lidiando con un proyecto de escala significativa, probablemente querrá que algunos desarrolladores se centren en las áreas de "back-end" y otros en el "front-end". Las divisiones son más finas y más maleables en la tierra descabezada, pero no trabaje bajo la falsa suposición de que puede reducir a la mitad su fuerza laboral de desarrollo simplemente decapitando.

¿Conoce el costo total de propiedad?

Mientras que headless a menudo puede resultar más barato que un monolito, la naturaleza SaaS de la mayoría de estos sistemas puede significar que para grandes conjuntos de datos que cambian rápidamente o equipos muy grandes, los costos pueden no sumarse. Siempre verifique cómo se escalan los costos y en qué se basa esa escala. Algunos proveedores escalan según el volumen de datos , algunos según la cantidad de solicitudes de API y otros según la cantidad de colaboradores que editan su contenido. La combinación de estos puede tener un efecto dramático en cómo crecen sus costos con la escala.

Es probable que también deba mirar varias plataformas diferentes para formular una idea de su costo total de propiedad. Si no obtiene la búsqueda "lista para usar", deberá considerar cuánto le costará agregar esa función. Por lo general, puede predecir cómo escalarán estos costos y, a menudo, puede comenzar de a poco, pero vale la pena ser consciente de lo que estas cosas pueden costarle a largo plazo.

También vigile de cerca sus minutos de compilación si elige quedarse sin cabeza: estos pueden acumularse rápidamente, especialmente en las fases de desarrollo y población de contenido. Tenga en cuenta que, si elige generar su sitio de forma estática, necesitará una compilación después de cada acción de publicación desde el CMS. Con sitios grandes, estas compilaciones pueden llevar un tiempo, por lo que vale la pena tener en cuenta que será necesario mantenerlas bajo control. Muchos de los servicios de alojamiento estático populares (como Netlify y Vercel) admiten el almacenamiento en caché de activos de compilación y, en combinación con marcos modernos que permiten compilaciones incrementales, esto puede ayudar a mitigar este costo creciente, pero aún debe vigilarlo y hacer su investiga para asegurarte de que no te atrapen.

¿Se lo ha explicado lo suficientemente bien a su cliente?

Es posible que le encante la experiencia de desarrollador de trabajar con Jamstack y sin cabeza, pero al realizar estas evaluaciones, debe tener en cuenta que los clientes son los que tienen que usar y vivir con las soluciones que crea, por lo que querrá tratar de hacerles la vida lo más fácil posible.

En un puesto anterior, participé en un lanzamiento a un fabricante de automóviles que dijo que quería un rendimiento líder en la industria como una prioridad principal, pero finalmente optó por otra agencia que ofrecía una solución más tradicional. Esto puede suceder por varias razones. (Lo más probable es que no hicimos un buen trabajo al vender los beneficios de nuestro enfoque, pero quedarse sin cabeza también puede parecer bastante aterrador para los editores de contenido, especialmente cuando se compara con algunos de los sistemas "empresariales" tradicionales que tienen talento para haciendo que parezca que todo "simplemente funciona".)

Cuando se quede sin cabeza, reunirá herramientas individuales diseñadas para ser muy buenas en una cosa en particular, en lugar de tener un gran sistema que pueda hacer todas estas cosas en un solo lugar. Eso puede ser bastante intimidante de manejar a menos que pueda hacer que sea lo más fácil posible para su cliente.

¿Está teniendo en cuenta el tiempo de desarrollo adicional?

Todo el poder potencial y la flexibilidad de headless no es gratis. Una de las desventajas de que todo sea personalizado es que esto significa que todo debe desarrollarse desde cero . Con muchas de las opciones en este espacio, no existe un esquema de documento "predeterminado" real; de hecho, están configurados deliberadamente para no tener ningún valor predeterminado como ese. Esto es excelente, por un lado, porque significa que obtiene modelos de documentos perfectamente personalizados que se ajustan con precisión a sus necesidades.

Sin embargo, por otro lado, significa que alguien necesita definir estos modelos de documentos y luego alguien necesita crearlos para el sistema que está utilizando. Luego, debido a que el frontend y el backend están desacoplados, alguien generalmente necesitará crear un motor para permitir la vista previa del borrador del contenido ; muchos marcos modernos incluyen un sistema para permitir la vista previa del contenido del borrador, pero universalmente requieren una configuración adicional para funcionar, y algunos requerirán un nivel de código personalizado. Por supuesto, el front-end no está vinculado al contenido, por lo que también se debe realizar cualquier asignación de datos a los componentes del front-end. Por lo general, tendrá que hacer al menos algo de esto incluso con un CMS estrechamente acoplado, pero el hecho de que probablemente tenga que asignar tiempo a todas estas cosas puede ser costoso.

¿Usted o su cliente se sienten cómodos con los datos que no viven en su propia infraestructura?

Si bien muchos de los que trabajan con sistemas CMS sin cabeza y otros proveedores de SaaS con frecuencia consideran que esto es positivo, hay situaciones en las que el hecho de que sus datos estén fuera de su propia infraestructura podría ser menos que deseable, por ejemplo, cuando se trata de productos confidenciales o datos de producción no públicos. La seguridad para estas empresas suele ser bastante buena, pero siempre hay riesgos.

Asegúrese de sopesar los beneficios relativos de tener su contenido alojado en un servidor AWS anónimo en alguna parte. Hemos visto antes que incluso el poderoso AWS puede tener cortes y, para los sistemas críticos para el negocio, estos pueden ser extremadamente costosos. La diferencia aquí entre SaaS en AWS o usar su propia infraestructura es que si tiene una interrupción o una violación de la seguridad en su propia infraestructura, es probable que se deba a su propio producto o código, pero en un entorno SaaS/AWS, las interrupciones son más probable que sea causado por factores no relacionados con su negocio. Estos casos son raros, pero suceden y es importante que esto se tenga en cuenta al tomar estas decisiones.

Vale genial. ¿Entonces cuales son mis opciones?

La cantidad de soluciones de administración de contenido sin cabeza y con capacidad sin cabeza disponibles en 2021 es asombrosa y crece constantemente. En lugar de tratar de cubrir todas las opciones aquí, quiero dar solo una breve introducción a algunas de las opciones más conocidas. Si está buscando una lista más completa, puede consultar Headless CMS o CMS Comparison.

con contenido

Contentful es una de las opciones de CMS sin cabeza más establecidas, ya que se fundó en 2016 y disfrutó de varias rondas de inversión inicial exitosas, y se describe a sí mismo como "una plataforma de contenido API-first para ofrecer experiencias digitales".

Contentful ha hecho grandes avances en los últimos años para admitir mejor el contenido traducido y transcreado, y tiene un buen soporte para múltiples "entornos" de contenido, lo que permite realizar cambios fuera de sus datos de producción y migrarlos más tarde.

Contentful tiene un conjunto de integraciones con otras aplicaciones SaaS, por lo que es fácil de integrar con Shopify o CommerceLayer para comercio electrónico, o Cloudinary para alojamiento y procesamiento de activos.

Mejor para:

Aquellos que buscan la solución mejor establecida en el espacio sin cabeza.

Storyblok

Storyblok es la única de las primeras opciones sin cabeza aquí que en realidad se describe a sí misma como un CMS, y presenta un editor de contenido visual realmente agradable que le permite crear y editar su contenido aparentemente in situ con una maravillosa interfaz WYSIWYG. Esta es una de las debilidades tradicionales de separar el CMS del sitio web, por lo que ver que Storyblok crea este tipo de entorno de edición es un gran paso adelante y el equipo debería estar orgulloso de impulsar el mercado en este sentido.

Storyblok también tiene la capacidad de usar su API para generar esquemas de contenido que permiten que estas cosas vivan como y con su código, lo cual es excelente para la capacidad de mantenimiento. Los permisos basados ​​en roles y las capacidades de traducción/transcreación hacen que los equipos distribuidos trabajen felizmente en sitios multilingües. En general, Storyblok se siente como una oferta extremadamente pulida y bien pensada, y es probable que los equipos de contenido, en particular, sean fanáticos.

Mejor para:

Aquellos que buscan la mejor solución de edición de contenido WYSIWYG de su clase desde un CMS sin cabeza.

Cordura

Sanity es uno de los chicos más nuevos en el bloque en este espacio, pero ha estado llamando la atención rápidamente. Se describen a sí mismos como "la plataforma de contenido definitiva que ayuda a los equipos a soñar en grande y entregar resultados rápidamente".

Sanity hace las cosas de manera un poco diferente a las otras opciones aquí, ya que todos sus modelos de configuración y contenido se realizan como código que, para los desarrolladores, es un lugar cómodo para guardar cosas. Al permitir una cantidad casi ilimitada de creatividad con modelos de documentos y tipos de campos personalizados, Sanity permite a los desarrolladores crear estructuras de contenido ricas y profundas para todo tipo de cosas, no solo contenido web.

El paquete de edición de Sanity es limpio y simple, personalizable, de código abierto y está basado en React. Puede implementar el estudio de edición en cualquier host que desee o elegir usar un subdominio de Sanity para alojarlo en su infraestructura.

Mejor para:

Aquellos que necesitan un control absoluto sobre casi todos los aspectos de la implementación, desde estructuras de datos personalizadas hasta componentes de entrada.

Prismático

Prismic es realmente el viejo personaje de la sala en el espacio sin cabeza, existiendo desde 2013, pero eso no les ha impedido innovar en el espacio. Apenas el año pasado, presentaron SliceMachine, cuyo objetivo es cerrar la brecha entre los desarrolladores front-end que crean componentes y los autores de contenido mediante la creación de una relación 1:1 entre los bloques de contenido (o "rebanadas") y los componentes front-end, lo que hace que la creación de nuevos las páginas y las secciones de contenido son muy sencillas para los editores.

La suite de edición de Prismic es encantadora y parece que han reparado algunos agujeros que solían existir en su selección de campo, por lo que ofrece una experiencia completa.

Mejor para:

Aquellos que buscan minimizar la fricción para los editores de contenido.

¿Qué pasa si quiero algo un poco más tradicional?

WordPress

Wordpress sigue siendo enorme en 2021. A pesar de todo el alboroto en torno a otras plataformas, WordPress todavía impulsa alrededor del 40% de Internet y no irá a ninguna parte. Los desarrolladores están ayudando a asegurarse de esto mejorando sus capacidades sin cabeza y centrándose más en su compatibilidad con API. Las nuevas herramientas de edición también hacen que la experiencia de escribir en WordPress sea más agradable, y algunas de las ventajas inherentes de trabajar con WordPress se han mejorado enormemente en los últimos años.

Trabajar con una empresa de WordPress como servicio como Nestify le quita de las manos gran parte de la ansiedad y los dolores de cabeza de la seguridad como desarrollador, pero tenga en cuenta que, como la plataforma más grande en Internet, WordPress todavía presenta una muy tentadora blanco para aquellos con intenciones maliciosas.

Mejor para:

Aquellos que buscan apegarse a una plataforma de contenido cómoda y familiar, mientras actualizan la tecnología.

Núcleo del sitio

Como uno de los gigantes de la administración de contenido empresarial, Sitecore es quizás uno de los nombres que menos esperaría ver en esta lista, pero han logrado grandes avances en la compatibilidad con el lanzamiento de Sitecore JSS para permitir que los proyectos de Jamstack interactúen con los datos de Sitecore.

La gran dificultad de trabajar con Sitecore u otros sistemas CMS empresariales de manera autónoma siempre ha sido poner en marcha la personalización, pero ese problema lo resolvió la gente de Uniform, que en realidad comenzó a trabajar con Sitecore para habilitar este tipo de funcionalidad. .

Sitecore es una gran bestia y no será adecuado para muchos proyectos (el costo por sí solo lo coloca fuera del alcance de todos los clientes, excepto los de nivel empresarial), pero vale la pena incluirlo aquí, junto con AEM, porque todavía hay mucha gente piensa que la gestión de contenido sin cabeza es solo para sitios web pequeños.

Mejor para:

Aquellos que buscan un proyecto empresarial con un cliente que no necesariamente quiere "participar" en la nueva tecnología.

Administrador de experiencias de Adobe

Adobe Experience Manager (o AEM) es otro de los principales actores en el ámbito empresarial. Es enorme y muy caro, como la mayoría de sus competidores, pero Adobe es otro proveedor que ha hecho grandes esfuerzos para que su oferta sea más amigable para aquellos que quieren separar su contenido de la presentación de su sitio web.

AEM ahora admite un par de métodos diferentes para solicitar datos fuera de su plataforma y Adobe ahora comercializa AEM como un "CMS híbrido", lo que significa que combina bajo un mismo capó operaciones autónomas y más tradicionales, específicas del canal. Esto puede ser una gran ventaja para los equipos de marketing que necesitan trabajar en diversas plataformas y necesitan un control detallado del contenido entre estas plataformas, pero aquellos que desean participar en la "una plataforma para gobernarlos a todos" de Adobe necesitarán mucho dinero para comenzar.

Mejor para:

¡Aquellos que buscan el extremo superior de una empresa, con bolsillos profundos! AEM hace mucho (más de lo que podríamos mencionar aquí), pero es costoso.

Ahora tengo una idea de mis opciones, pero ¿cómo puedo esperar elegir entre ellas?

Ahora hay tantas opciones en el espacio sin cabeza que puede terminar fácilmente en parálisis de opciones. Sin embargo, hay algunas preguntas que puede usar para ayudar a formar una opinión inicial o al menos reducir el campo:

¿Cuánto tiempo te llevará ponerte al día?

Los diferentes sistemas tienen diferentes curvas de aprendizaje y diferentes formas de apoyar a los desarrolladores. Todos los sistemas enumerados aquí tienen una comunidad de desarrolladores creada a su alrededor, pero no todas las comunidades son iguales. ¿El proveedor proporciona documentación detallada? ¿Proyectos de arranque? Todo esto puede tener un gran impacto en el tiempo de giro.

¿Qué tipo de modelo de soporte necesitará?

Los modelos de soporte suelen ser los más importantes para los clientes y, a menudo, descubre que para acceder a las líneas de soporte más directas, debe pagar los paquetes "empresariales", lo que podría hacer que su inversión sea mayor de lo que podría esperar considerando su uso.

¿Qué tan bien establecido está el vendedor?

¿Qué tan bien establecido está el vendedor? ¿Cómo se financian? Nuevamente, estas son generalmente consideraciones del cliente en lugar de las del desarrollador, pero vale la pena poder decirle al cliente desde el principio que el proveedor que está recomendando es estable, ha existido durante X años y que tiene suficiente respaldo financiero para asegúrese de que no vayan a ir a ninguna parte en el corto plazo. ¡Lo último con lo que cualquier cliente quiere tener que lidiar es una nueva plataforma forzada porque su proveedor actual está cancelando su producto mientras el cliente está a la mitad de su compromiso!

¿Cómo es la experiencia de edición?

Es probable que la experiencia de edición sea muy importante para varias personas del lado del cliente de cualquier proyecto. Estas son las personas que trabajarán con cualquier CMS que elija día tras día . Si el CMS es una pesadilla para usar, lo dirán, mucho. Confía en mí, he estado en muchos lanzamientos y reuniones de seguimiento en las que se ha pasado una cantidad significativa de tiempo con el cliente enumerando las muchas frustraciones que tienen con su sistema existente.

"¿Pueden los sistemas que está buscando proporcionar edición en contexto o vistas previas de borradores en vivo?"

"¿Cuánto esfuerzo es configurar esto?"

"¿Qué tan rápido o lento se ejecuta el editor en sí?"

"¿Está el usuario bombardeado con opciones y botones desconocidos o las cosas están bien organizadas?"

Todas estas preguntas alimentan la facilidad general de uso del sistema. Algunas soluciones, como Storyblok, han hecho todo lo posible para que la edición de contenido sea una experiencia rica y fluida , pero generalmente no se considera una fortaleza en el panorama sin cabeza en su conjunto, por lo que definitivamente vale la pena incluir una demostración a pequeña escala. frente a sus editores de contenido y ver cómo se sienten acerca de las soluciones que tiene en mente.

¿Qué tan fácil es sacar sus datos de la plataforma?

He perdido la cuenta de la cantidad de reuniones de lanzamiento en las que me he sentado y me han dicho que probablemente tendremos que comenzar desde cero o escribir un raspador personalizado para el contenido porque el contenido del cliente está completamente atado a un sistema de gestión de contenido patentado. y no pueden exportar fácilmente sus datos.

No importa cuán genial parezca el CMS de su elección, asegúrese absolutamente de que haya una manera fácil de sacar todo su contenido del sistema en algún momento. Lamentablemente, ningún sistema es para siempre, y el cliente eventualmente querrá cambiar su sitio y su infraestructura con él. Cualquier cosa que pueda hacer para hacerles la vida más fácil en ese momento será muy positivo.

En general, esto es más fácil con las soluciones de CMS sin cabeza porque son compatibles con API en su núcleo, pero aún requiere un examen más detenido para asegurarse de que no va a causar un gran dolor de cabeza dentro de unos años.

Resumiendo

Elegir un enfoque y una plataforma para la gestión de contenido es una gran elección en cualquier proyecto digital. La administración de contenido sin periféricos es poderosa y flexible, pero tiene algunos costos y no es ideal para todas las situaciones.

Tenga en cuenta que el precio que ve por adelantado del proveedor rara vez es el costo total final de la solución, y asegúrese de no caer en la trampa de pensar que puede reducir los costos de desarrollo eliminando los costos tradicionales -fin” desarrolladores.

Asegúrese de que todos se sientan cómodos con la realidad de trabajar con un CMS autónomo en lugar de una configuración más tradicional, y asegúrese de traer editores de contenido para el viaje porque son las personas que trabajarán con el sistema que configure más. frecuentemente.

Con suerte, esta guía al menos ha ayudado a dar un poco de contexto a la exageración y puede ayudarlo a tomar una decisión con la que usted y su cliente puedan sentirse cómodos. Ahora puede construir casi cualquier cosa que desee con headless en su centro , pero siempre pregúntese si está buscando una solución porque le resulta familiar o promocionada, o si realmente es la mejor solución para sus circunstancias.