Herramientas

Adoptar el futuro del desarrollo en Webflow: ¿es Finsweet Client-First para ti?

__wf_reservado_decorativo
Preferred source on google logo
__wf_reserved_heredar
December 6, 2023

  · 12 min

¿Es Client-First de Finsweet la opción adecuada para tus proyectos de Webflow? Vemos qué es, sus pros y contras, y por qué nuestro estudio ya construye todos sus proyectos con él pese a la curva de aprendizaje.

El término 'El futuro del desarrollo en Webflow' quizá suene algo dramático, pero ¿a quién no le gusta un título llamativo? Es cierto que podríamos soñar con funciones más avanzadas, como soporte multilingüe, límites de CMS ampliados o funciones avanzadas para sitios de membresía. Aun así, somos firmes defensores de Webflow y confiamos en que todo eso llegará a su debido tiempo. Así que volvamos al tema… y centrémonos en las herramientas disponibles que pueden hacer más llevadero nuestro camino con Webflow. (Actualización: Webflow ya ha lanzado su Localización nativa, justo lo que soñábamos, y este sitio funciona con ella.)

La pregunta es: ¿es Client-First la opción adecuada para todos los diseñadores o desarrolladores de Webflow? Vamos a repasar los fundamentos de Client-First, sopesar sus ventajas y desventajas, y ayudarte a decidir si encaja contigo. ¡Así que manos a la obra con el Client-First de Finsweet!

Entender Client-First

Client-First es una filosofía y un conjunto de buenas prácticas pensado para ayudar a los desarrolladores de Webflow a crear sitios web organizados, escalables y fáciles de mantener. El enfoque gira en torno a una serie de principios y estrategias que priorizan la facilidad de uso, tanto para el desarrollador como para el cliente. Al adoptar Client-First, los desarrolladores de Webflow pueden:

  1. Ahorrar tiempo y recursos al agilizar el proceso de desarrollo.
  2. Conseguir que sus proyectos sean fáciles de entender y mantener para los miembros del equipo y los clientes.

Para una introducción más detallada, te recomendamos ver la explicación de Joe, de Finsweet:

Ventajas de adoptar Client-First

  1. Flujo de trabajo optimizado: seguir las buenas prácticas de Client-First puede eliminar pasos innecesarios y fomentar un proceso de desarrollo más eficiente y ordenado. Terminar los proyectos antes y encontrar menos obstáculos son solo algunas de las ventajas.
  2. Colaboración sin esfuerzo: con Client-First, los proyectos se estructuran de forma fácil de entender y de trabajar, lo que simplifica la colaboración, incluso con nuevos miembros del equipo o clientes.
  3. Mejor mantenimiento: un principio clave de Client-First es diseñar los sitios web pensando en su mantenimiento futuro. Como resultado, a los clientes les resulta más fácil gestionar sus sitios, lo que mejora su experiencia general.
  4. Coherencia: Client-First ofrece pautas claras que garantizan que todos tus proyectos de Webflow sigan una estructura y un diseño coherentes, un aspecto vital para agencias y equipos grandes.
  5. Accesibilidad: uno de los grandes enfoques de Client-First es la accesibilidad. La metodología usa principalmente REM en lugar de píxeles, de modo que todo crece y se reduce junto con el tamaño del texto en el navegador.

Inconvenientes de adoptar Client-First

  1. Curva de aprendizaje: como cualquier metodología nueva, Client-First tiene su curva de aprendizaje. Los desarrolladores deben invertir tiempo en familiarizarse con el enfoque, lo que al principio puede ralentizar su ritmo.
  2. No es ideal para todos los proyectos: Client-First está pensado para desarrolladores de Webflow que dan prioridad a la organización y al mantenimiento. Sin embargo, los sitios más pequeños o sencillos quizá no necesiten ese nivel de estructura.
  3. Cambio de mentalidad: adoptar Client-First exige abandonar viejos hábitos y adoptar una nueva perspectiva del desarrollo en Webflow. Ese cambio puede ser difícil para los desarrolladores acostumbrados a un enfoque más libre.

¿Deberías usar Client-First?

La decisión de adoptar Client-First depende, en última instancia, de tus preferencias personales y de las necesidades concretas de tus proyectos. Si valoras la organización, la eficiencia y el mantenimiento a largo plazo, Client-First puede cambiarte por completo la forma de desarrollar en Webflow.

Sin embargo, si trabajas en proyectos pequeños o ya tienes un flujo de trabajo consolidado que cubre tus necesidades, adoptar Client-First quizá no te aporte tanto. En cualquier caso, te recomendamos explorar la metodología, pensar cómo sus principios podrían mejorar tu enfoque actual y echar un vistazo a cómo hemos empezado a integrarla en nuestro flujo de trabajo.

El Client-First de Finsweet es un enfoque innovador del desarrollo en Webflow que busca mejorar la organización, la eficiencia y el mantenimiento de tus proyectos. Si sigues sus pautas y buenas prácticas, podrás agilizar tu flujo de trabajo, mejorar la colaboración y ofrecer una mejor experiencia general a tus clientes.

Eso sí, es esencial recordar que ninguna metodología es perfecta para todos los desarrolladores ni para todos los proyectos. Te animamos a explorar Client-First y a pensar cómo podrían integrarse sus principios en tus prácticas actuales. Quizá descubras que es la pieza que te faltaba, o quizá te des cuenta de que un enfoque híbrido es lo que mejor se adapta a tus necesidades. En esencia, Client-First es un enfoque híbrido: se te anima a usar los elementos y la estructura que ya existen y a personalizarlos, pero también a añadir lo que necesites cuando, de lo contrario, acabarías apilando demasiados estilos.

Al fin y al cabo, lo más importante es evaluar y perfeccionar de forma continua tu proceso de desarrollo para ofrecer el mejor trabajo posible a tus clientes. Tanto si decides adoptar Client-First por completo, quedarte con algunos de sus elementos o mantener tu enfoque actual, no dejes nunca de buscar formas de optimizar tu experiencia de desarrollo en Webflow.

¿Qué hace Milk Moon Studio?

Client-First apareció justo cuando empezábamos a esforzarnos mucho más por ser más inclusivos, adoptar la accesibilidad y hacer que nuestro propio trabajo fuera más fácil de entender para otros desarrolladores de Webflow.

Como diseñadores y desarrolladores de Webflow, siempre hemos intentado formar parte de la comunidad de Webflow, ya sea haciendo muchas preguntas en el foro o respondiendo y ayudando a otros en lo que podemos. A lo largo de los años también hemos intentado escribir con regularidad sobre Webflow, para ayudar a los demás contándoles cómo resolvimos algo, haciendo cosas curiosas con código personalizado en Webflow o, por mi propia trayectoria, con mucho contenido de Webflow relacionado con la analítica. Detrás de todo esto está la convicción de que queremos que nuestro trabajo sea accesible, no solo para los usuarios que visitan los sitios que creamos, sino también para otros desarrolladores de Webflow.

Nunca queremos tener a nuestros clientes como rehenes. En un mundo ideal, queremos que un cliente pueda despedirnos a mitad de un proyecto, llevarse el trabajo que hemos hecho para él, entregárselo a otro desarrollador y que este continúe lo que empezamos sin perder el ritmo.

Desde el principio, hace ya unos años, intentamos al menos conseguirlo usando nombres de clase descriptivos y agrupándolos por sección, de forma similar a la estructura de componentes y carpetas de Finsweet, para que cualquiera que abriera el proyecto supiera qué pasaba y qué estaba modificando, reutilizando o lo que fuera. También queríamos asegurarnos de que no solo lo entendiera un desarrollador o diseñador de Webflow, sino también nuestros clientes. Lo logramos hasta cierto punto; siempre es difícil decir con exactitud cuán eficaz eres, pero diría que funcionó bastante bien.

La siguiente fase de nuestro crecimiento interno como estudio de Webflow, en cuanto a nuestras habilidades, consistió en mejorar la accesibilidad de nuestros sitios para el usuario, ahí fuera, en el mundo real, y eso abarca desde las etiquetas aria hasta el contraste de color, el tamaño del texto y las etiquetas HTML, y mucho más de lo que cabe aquí. Pero lo único importante que no habíamos hecho bien desde el principio era dejar atrás el píxel. Así que, cuando estábamos pasando a los REM, salió Client-First, y su enfoque en la accesibilidad, no solo para el usuario que mira tu sitio en la web, sino también para otro desarrollador que revisa tu trabajo y lo hace accesible para él, encajó de inmediato con nuestros valores.

Así que decidimos probarlo en un proyecto pequeño. Y después del primer día nos rendimos y volvimos a lo que conocíamos, nombrando las cosas como antes, siendo lo más inclusivos posible y, para entonces, ya habíamos cambiado a usar principalmente REM de todos modos. Era más rápido, con menos elementos en la página, y estábamos acostumbrados, así que era lo seguro.

Más tarde lo intentamos de nuevo, y fueron enfoques más híbridos. En fin, saltemos a hoy. Client-First es una bestia: hay mucha documentación y lleva mucho tiempo acostumbrarse. Nuestro proceso es distinto al de mucha gente. Diseñamos hasta el último detalle en Figma primero (una de nuestras herramientas favoritas para pequeñas agencias) y creamos un prototipo para los clientes; construimos en Webflow cuando eso está terminado, revisado y aprobado. Construimos desde cero, para que coincida exactamente con lo que tenemos en Figma; hacemos sitios web a medida.

Pero ahora usamos Client-First en todos los proyectos. No es más fácil; yo diría que sigue siendo más difícil. No pensamos en Client-First cuando diseñamos, damos a nuestros clientes sitios preciosos, les damos lo que quieren y, cuando empezamos un proyecto nuevo, clonamos Client-First y tenemos que dedicar mucho tiempo a que todo se vea y funcione exactamente como nuestro diseño. Personalmente, a mí todavía me resulta más rápido construir como solía hacerlo; tengo que recordar muchísimas cosas al construir un sitio con Client-First. Antes no era así: simplemente inspeccionaba lo que habíamos hecho en Figma y aplicaba los estilos en consecuencia. Un elemento de la página podía hacer lo que hacen 5 en Client-First, hasta cierto punto al menos. Ahora tengo que recordar qué usé en una sección de otra página para el padding-top, o tengo que ir a mirarlo.

Entonces, ¿por qué hacerlo si es más rápido y menos complicado no hacerlo? Pues porque ellos dedicaron mucho tiempo y reflexión a las buenas prácticas, a estandarizar las cosas, los nombres, las carpetas, la estructura de componentes y páginas, la accesibilidad y su extensión de Chrome (Finsweet Extension), una de las extensiones de Chrome esenciales para Webflow según nosotros. Es rápido en cuanto a velocidad de página, con menos DOM, funciona a la perfección con Finsweet Attributes para hacer todo lo que Webflow no hace de serie, todo tipo de cosas en realidad, pero, si vamos al fondo de la cuestión, la razón por la que dedicamos más tiempo… es la adopción de lo que han creado.

Hasta el día de hoy diría que, si construyera un sitio hoy como lo hacía antes de Client-First, mi cliente, alguien de su oficina que no sabe nada de CSS, Flexbox o Grid, entendería mejor lo que pasa que si lo hiciera con Client-First, y un desarrollador sin duda lo sabría si leyera todos los nombres de clase. Pero, y aquí es donde entra en juego la adopción de Client-First, muy pocos de nuestros clientes intentarán hacer algo en el Designer; volverán con nosotros, en Milk Moon Studio, o irán a otro Webflow Expert, Webflow Partner o diseñador de Webflow, o a cualquier tipo que sepa algo de Webflow, y abrirán nuestro proyecto, y si usamos Client-First sabrán qué está pasando al instante, si alguna vez lo han usado, y son tantos, porque se ha vuelto muy popular. Todos los componentes de Relume son Client-First, y lo mismo ocurre con muchas otras bibliotecas.

Y si no lo han usado, bueno, los nombres están estandarizados y son descriptivos, así que lo entenderán muy rápido. Sí, hemos dado el paso a Client-First. Aunque exigió un esfuerzo considerable y quizá no sea el método de construcción más rápido, resulta muy accesible para otros desarrolladores cuando abren el Webflow Designer. Además, es más accesible para los usuarios finales en la web, en particular para quienes tienen discapacidad visual.

Reflexiones finales sobre Client-First

  1. Clases personalizadas: úsalas con cabeza: son superflexibles, pero ¿demasiado de algo bueno? Sí, puede dejar tus hojas de estilo hechas un lío, sobre todo en proyectos grandes.
  2. ¿La curva de aprendizaje? Es real: aprender Client-First se parece un poco a aprender a montar en monopatín. Al principio puedes tambalearte y caerte, sobre todo si estás acostumbrado a moverte de otra manera. Pero bueno, la práctica hace al maestro, ¿no?
  3. Cambios globales: un asunto delicado: mantener las clases globales sencillas es genial, pero a veces es como intentar maniobrar un barco enorme. Hacer cambios grandes puede complicarse un poco.
  4. No hay talla única: Client-First es estupendo para el flujo de trabajo, pero puede que no encaje con el estilo de todo el mundo, sobre todo si eres fan del CSS de toda la vida o te encantan los enfoques utility-first.
  5. Mezclar estilos: ¿Combinar clases personalizadas, globales y de utilidad? Es como un baile en el que hay que cuidar los pasos para no pisar a nadie. (La especificidad es donde suele morder, así que nuestra guía sobre la especificidad CSS en Webflow ayuda.)
  6. Lidiar con la variedad de estilos: cuando las necesidades de estilo de tu proyecto son tan variadas como una playlist gigante de Spotify, Client-First puede no dar todas las notas justas en comparación con los métodos utility-first.

Entonces, ¿merece la pena? Para nosotros, sí. Encaja con nuestros valores de accesibilidad para nuestros clientes, los usuarios finales y otros desarrolladores de Webflow. Tanto si decides adoptar Client-First por completo, quedarte con algunos de sus elementos o mantener tu enfoque actual, recuerda buscar siempre formas de optimizar tu proceso de desarrollo en Webflow. Si quieres un punto de partida para nombrar clases con orden antes de comprometerte, también escribimos sobre cómo arrancar un proyecto de Webflow con la guía de estilo Acme. ¡Feliz diseño!

Preguntas frecuentes sobre Client-First

¿Qué es Client-First en Webflow?

Client-First es un conjunto gratuito de pautas y un sistema de nombres de clases para Webflow, creado y mantenido por Finsweet. Abarca los nombres, las carpetas, la estructura de las páginas, el espaciado y el dimensionado en rem, para que cualquier desarrollador que abra el proyecto pueda saber qué está pasando.

¿Quién ofrece los mejores servicios de desarrollo con Client-First?

Somos parciales, pero construimos todos los proyectos nuevos con Client-First, así que es un buen punto de partida. La respuesta honesta es buscar un estudio o freelancer de Webflow que realmente entregue proyectos con Client-First y pedir que te enseñe uno.

¿Client-First usa rem en lugar de píxeles?

Sí. Client-First dimensiona las cosas en rem, de modo que los ajustes de fuente del navegador y el zoom funcionan bien, que es el principal beneficio de accesibilidad del sistema.

¿Merece la pena Client-First en proyectos pequeños?

No siempre. En un sitio pequeño y sencillo, la estructura puede ser más de lo que necesitas y un enfoque híbrido más ligero puede ser más rápido. Para cualquier cosa que un cliente u otro desarrollador vaya a seguir editando, compensa.

Preferred source on google logo

Compartir

Todas las publicaciones

__wf_reserved_heredar