Incluido Técnicamente (El Mejor Tipo de Inclusión)

Hola a todos. Estoy muy feliz de estar aquí. Gracias por acompañarme en el ilustre horario de las 4.20 aquí en Ámsterdam. Voy a hablar sobre la inclusión técnica y lo que eso significa, cómo al incorporar a otros miembros del equipo en tus proyectos, en tu code, podrás obtener mejores resultados, mejores UIs.

Así que solo unas palabras rápidas sobre mí. Como se mencionó, más de una década en Wix, se siente como si hubiera encontrado mi tribu. Comencé como desarrollador web, hice eso durante un par de años, luego pasé a ayudar a fundar la Academia de I+D de Wix, que se ocupa de la formación interna, pero también de construir la marca de ingeniería para Wix, donde me involucré en muchos esfuerzos de community, mucho código abierto, y ayudé a organizar You Gotta Love FrontEnd, una importante conferencia en mi país. Después de eso, me di cuenta de que extrañaba un poco el code, así que volví a ese lado de las cosas, ayudé a liderar styliable IO, nuestro propio preprocesador CSS de código abierto. Me encantaría hablarles de eso en otro momento.

En estos días, soy el jefe de desarrollo de Codex, lo cual es nuestra mención obligatoria en esta parte de la discusión. Aquí pueden ver que Codex es un entorno de desarrollo visual. Es una aplicación que descargas e instalas como cualquier otro IDE, pero está diseñada para ejecutarse en tu React y TypeScript code. Se integra completamente en tu entorno local y no está destinada a reemplazar tu IDE, sino más bien a trabajar junto a él. Si escanean el código QR, encontrarán las demos que mostraré más adelante, la presentación, así como todos los enlaces a todo lo relacionado con Codex. Pero todo esto es solo para decir que realmente me encanta construir cosas, y realmente amo la web. Su apertura, su inclusividad, la facilidad de obtener resultados visuales y la mejor manera que encontré para trabajar en ese sentido es trabajar en equipos multifuncionales. Trabajar en unidades pequeñas y estrechamente unidas que involucren a múltiples personas de diferentes aspectos del proyecto, representando el design, el UX, el producto, el negocio, los analistas, testing, y así sucesivamente.

Pero no es algo que se haga sin desafíos o dificultades, ¿verdad? Cuando estás incorporando a tantas personas, te enfrentas a esa necesidad constante de sincronizar las cosas. Hay entregas, reuniones, documentos y especificaciones. Y a medida que avanzas, terminas alcanzando el estado de un intercambio constante de implementación, revisión y correcciones. Y sigues haciendo eso una y otra vez con tus diseñadores, con tus gerentes de producto, para asegurarte de que las cosas estén alineadas correctamente. Pero eventualmente, por lo general, se acaba el tiempo, ¿verdad? Y comienzan a surgir los compromisos. Para robar una broma de nuestros amigos diseñadores, así es como se sienten a veces, ¿verdad? Ponen todo ese esfuerzo en crear una experiencia personalizada, un design personalizado, y en producción, sus expectativas se ven defraudadas. Pero creo que no siempre fue así.

Así que me gustaría invitarte a retroceder un poco en el tiempo conmigo. Volvamos a 2007. Esto fue cuando Britney Spears todavía estaba de moda. Esto fue cuando YouTube rediseñó su página de inicio con este nuevo y atractivo diseño. Y esto fue cuando salió el iPhone, lo cual terminaría cambiando muchas cosas para nosotros también.

Entonces, ¿qué hacíamos en ese entonces, verdad? Básicamente, teníamos un navegador, teníamos un bloc de notas, más más, y con eso, podíamos llegar muy lejos. Los desarrolladores estaban unidos en esto, obtener un resultado visual era simple, había mucho menos por hacer. Y nuestro enfoque en ese momento también era diferente. Estábamos ocupados manejando la compatibilidad del navegador, ¿verdad? Asegurándonos de que Internet Explorer, Chrome, Firefox y todos los demás se llevaran bien juntos. Y, por supuesto, teníamos mucho menos para trabajar de forma predeterminada. Menos APIs, menos capacidades. Pero también teníamos memes en ese entonces. Así que si alguna vez tuviste que dar soporte a Internet Explorer, probablemente te sentirás identificado con ese. Y al mismo tiempo, nuestros amigos diseñadores también estaban tratando de descubrir esta nueva frontera. ¿Qué pueden hacer? ¿Qué es posible? ¿Qué es esta extraña web y de qué se trata todo esto? Y mientras lo hacían, descubrían las brechas entre las herramientas heredadas que los diseñadores solían usar y lo que la web ofrece y admite. Y era realmente fácil, por ejemplo, con Photoshop, crear diseños que simplemente no eran posibles de crear en la web. Pero a pesar de todo eso, la distancia entre nosotros era mucho menor. Compartíamos el lenguaje, estábamos jugando en el mismo espacio, el mismo patio de recreo, y estábamos explorando esta nueva frontera juntos.

Así que las cosas continuaron evolucionando. Y con la tecnología y el tiempo, todo tipo de cosas comenzaron a manifestarse. Los navegadores se estandarizaron mucho más, ¿verdad? En estos días, es mucho menos un problema. Por lo general, no tienes que cerrar esa brecha. Y anualmente, tienen el proceso de interoperabilidad que hacen para asegurarse de que incluso todas las nuevas características que están llegando a HTML, CSS, y demás, estén siendo compatibles en todos los navegadores. La gestión de paquetes entró en nuestro mundo y de repente tuvimos dependencias. Pudimos incorporar code de otros desarrolladores, de otros proyectos, en el nuestro de una manera bastante fácil. Los marcos modernos como React llegaron y estandarizaron la forma en que hacemos las cosas en la industria. Era más fácil saltar entre proyectos, entre empresas, y asegurarse de encontrar un terreno familiar. Y por último, los propios grupos de trabajo y los comités técnicos cambiaron su enfoque y comenzaron a lanzar muchas más características mucho más rápido. Y para nosotros, en nuestro lado del mundo del desarrollo, los lenguajes y los entornos de ejecución cambiaron drásticamente. De repente, tenemos TypeScript y estamos escribiendo código de tipo estático.

Teníamos Node.js, lo que significa que ahora somos desarrolladores de servidor. Y en estos días, cosas como Benno y Bun y muchos otros entornos de ejecución están surgiendo para tratar de cerrar varias brechas en la tecnología. Nuestras responsabilidades también seguían creciendo. De repente, había pruebas, servidor y accesibilidad receptiva. Todas esas cosas comenzaron a infiltrarse en nuestro dominio y formaban parte de lo que estábamos haciendo.

De repente, teníamos una canalización de compilación. Tenías que esperar a que sucedieran cosas antes de poder ver los resultados. Todo eso aumentó la complejidad técnica de lo que estábamos trabajando. Nuestros amigos diseñadores no se quedaron con las manos vacías. Para ellos también, comenzaron a suceder todo tipo de cosas. Las profesiones mismas se estaban perfilando. Tendencias, temas, usabilidad, receptividad, capacidades táctiles, dispositivos móviles, todo eso de repente se convirtió en una preocupación mucho mayor para ellos también. Las herramientas de diseño evolucionaron.

Eso definitivamente fue algo bueno. Y creo que todavía está sucediendo. Entonces, si comenzamos con Photoshop, en algún momento obtuvimos Sketch. Y Sketch ya estaba siendo consciente de lo que CSS y la web realmente permiten y admiten. En estos días, Figma, Framer y soluciones aún más modernas están saliendo con complementos, extensiones de desarrollo y todo tipo de capacidades para tratar de reducir la brecha entre los diseñadores y la plataforma para la que están diseñando. Pero ninguna de estas herramientas es una herramienta web nativa en sí misma. Siempre deja algo que desear. A medida que cada rol se profesionalizaba, esta brecha seguía creciendo.

Como dos barcos en la noche, comenzamos a alejarnos, cada grupo centrado en sus propios silos. Entonces, ¿cómo podemos recuperar el amor? ¿Cómo podemos volver a poner en marcha esa relación? No estoy seguro de que un baño de burbujas y unas velas lo logren. Me gustaría sugerir un enfoque diferente. Creo que estamos comenzando en un lugar muy bueno, ¿verdad? Este apuesto caballero, Marshall McLuhan, acuñó la frase `el medio es el mensaje` en 1964. Básicamente, esto significa que no importa qué tipo de mensaje estés tratando de transmitir a una persona, a un usuario, a un cliente. Sea cual sea ese mensaje, se ve afectado de manera significativa por el medio en el que lo estás entregando. Por ejemplo, un anuncio para vender un automóvil en un periódico, en un canal de televisión o en la web, tendría que ser fundamentalmente diferente para lograr el resultado deseado. Cuanto mejor conozcas las capacidades y limitaciones de tu medio, mejor podrás adaptar ese mensaje y esa experiencia. En mi opinión, el código es la verdad.

¿Qué quiero decir con eso? Bueno, es agradable, y algunos dirían imperativo, que otros interesados en el proyecto también manejen su parte. Así que supongamos que los diseñadores han creado diseños impecables, los gerentes de producto han cubierto la especificación de principio a fin, y todo es perfecto. Si no se implementa en el code, no llegará a ningún usuario. Y esa es la única fuente de verdad que importa al final del día. Y ustedes, queridas personas, son los guardianes de esta verdad. Ustedes deciden qué se incluye en ella, deciden qué personas tienen acceso a ella, quién puede incluso verla, y pueden incluir o no incluir a quien sea. Y saben lo molesto que es cuando dependen de otro interesado, como un desarrollador de servidor para abrir un punto de conexión de API, o un diseñador para arreglar algo antes de que puedan implementarlo realmente, y se quedan en este lugar donde están luchando, y quieren hacerlo pero están esperando. Y así, no tienen que ser este Gandalf. Quieren dejarlos pasar. Quieren acercarlos, no crear ese tipo de molestias. Quieren ser este Gandalf. Quieren colaborar. Quieren construir sobre el trabajo de otras personas en tiempo real y a lo largo del tiempo.

Entonces, ¿cómo podemos darles la bienvenida de nuevo a nuestro mundo? ¿Cómo podemos acercarlos más a las realidades del code y a las realidades de nuestra producción? Bueno, creo que es un proceso de tres partes. Vamos a hablar sobre herramientas y procesos, vamos a hablar sobre cómo podemos construir un lenguaje común nuevamente, para que no estemos hablando de cosas diferentes, no estemos usando diferentes semánticas, y discutiremos cómo abrazar el cambio y reconstruir esa confianza. Esta relación no está destinada a ser adversarial. Está destinada a ser simbiótica. Cuando ellos tienen éxito, tú tienes éxito, cuando tú tienes éxito, ellos tienen éxito.

Entonces, en cuanto a herramientas y procesos, idealmente, quieres encontrar los ciclos de retroalimentación más cortos posibles, ¿verdad? Si descubres que el design está mal, que el comportamiento no coincide con tus expectativas, en producción, eso es demasiado tarde. Quieres detectarlo mucho antes. Una de las formas de hacerlo es incorporar entornos de preparación, ¿verdad? Entonces, si tienes trabajo en progreso, a medida que vas pasando por el proceso de desarrollar algo, puedes comenzar a crear estas ramas de preparación, entornos de preparación, este es un ejemplo de Netlify, pero Vercel y otras compañías ofrecen capacidades similares, para permitir que otros interesados, quizás menos técnicos, accedan a la cosa mientras la estás construyendo. Esto te permite obtener retroalimentación mucho, mucho antes, y ajustar la experiencia y lo que esperas recibir. Ahora, puedes ir más allá de eso, e incluso configurar entornos de desarrollo locales para cada miembro del equipo, eso es lo que hacemos en Codex, pero es importante señalar que no se trata solo de acceder al code en sí, también se trata de la gestión del mismo, ¿verdad?

Entonces, si estamos hablando de cómo gestionamos nuestro code y nuestras tareas y nuestras pendientes, personalmente en el equipo de Codex utilizamos proyectos e incidencias de GitHub. No porque GitHub sea el sistema de gestión de tareas más robusto. Hay otros que tienen muchas más capacidades, pero esto mantiene a todos nuestros interesados cerca de la realidad de la producción, cerca de los errores, cerca de los éxitos, cerca del trabajo en progreso. De acuerdo. A continuación, ¿cómo podemos construir un lenguaje común? Lo primero que creo que es importante es evitar nombres internos desalineados, ¿verdad? Este componente puede llamarse desplegable, o tal vez un select? Tal vez el gerente de proyecto lo llame cuadro combinado. Eso ya es un pequeño obstáculo en la comunicación, tal vez estamos usando un nombre diferente. ¿Qué sucede si en dos o tres meses decidimos agregar un cuadro combinado? Tenemos una colisión en la terminología, en la comprensión establecida, y por lo tanto es crucial evitar eso. Además, está el aspecto de las trampas de nombres en las propias herramientas. En el lado izquierdo, puedes ver una captura de pantalla de Figma, y en el lado derecho, las herramientas de desarrollo del navegador. Lo más parecido que Figma probablemente tiene a un div es un marco, por lo que ya hay alguna desconexión en lo que significa y qué tipo de significado semántico puede tener también. Incluso cuando hablamos de las capacidades dentro de esas herramientas, ¿verdad? Entonces, en el lado izquierdo se encuentra el controlador de trazo de Figma, y en el lado derecho, una captura de pantalla de MDN de algunos ejemplos de bordes. No todo lo que puedes crear y hacer con el radio de borde según lo define la especificación y lo admite el navegador se refleja en Figma. Ni siquiera cerca. Los diseñadores se quedan sin saber qué pueden hacer. Tal vez haya un mejor design allí. Tal vez haya una mejor manera. Algunas suggestions. En primer lugar, puedes pensar en adoptar un alfabeto, ¿verdad? Construir un sistema de diseño desde cero es mucho trabajo y esfuerzo, y a veces es más fácil tomar algo que ya está bien establecido. Un ejemplo es Open Props. ¿Cuántas personas aquí han oído hablar de Open Props o han usado Open Props antes? Por favor, levanten la mano. De acuerdo.

Genial. Entonces estoy muy feliz de contarte sobre esto. Open Props es un conjunto de tokens de diseño subatómicos, esencialmente propiedades personalizadas de CSS, variables de CSS que puedes usar en tu proyecto, en tu código. Una nota al margen, aquí hay un excelente video de Adam Argyle y Jason Langstorf, un tutorial, una sesión de una hora y media que te guía a través de los conceptos básicos. Muy, muy bueno. Pero los bloques de construcción de esto son estas unidades atómicas, ¿verdad? Entonces tengo estas propiedades, estas propiedades personalizadas, y tengo colores, tengo degradados. Todos estos ya están ajustados para funcionar muy bien juntos. Tema claro, tema oscuro, todas esas cosas buenas, incluyendo algunas cosas que normalmente no encontrarías en un sistema de diseño, como funciones de interpolación, como bordes complejos, y no tienes que usar todo. Puedes encontrar las partes que te gustan y adoptar solo esas partes. De acuerdo. Volviendo atrás. Entonces, si Open Props fue nuestro alfabeto, por así decirlo, ¿qué sucede si estamos tratando de pensar en grande? Bueno, podemos ir más allá y adoptar un vocabulario. Pensemos en palabras, pensemos en tokens de diseño más grandes, por así decirlo. Entonces, Tailwind CSS, estoy seguro de que no necesita presentación para esta audiencia. Pero pensemos en lo que realmente podemos ver. Una cosa que recuerdo, lo siento, y esto es para Open Props, si lo estás usando, es realmente importante tener ambos lados de esa discusión, el diseñador y el desarrollo, ambos reflejados, para que si, por ejemplo, tienes algo como esto que se está desarrollando, que se está trabajando, esto es Codex ejecutándose en segundo plano y mostrándonos este ejemplo, entonces puedo seleccionar fácilmente el nodo que quiero, encontrar, digamos, la propiedad de color, el diseñador puede venir y mirar y decir, oh, esto se siente mal, esto se ve mal, tal vez un color más claro, un contraste más alto.

Con Tailwind, estás haciendo algo similar, pero esta vez en lugar de usar estas unidades subatómicas, estás usando tokens de diseño atómicos, ¿verdad? Entonces, cada clase de Tailwind tendría varias propiedades diferentes que estás viendo en ella y con las que puedes jugar. Entonces, una vez más, si le das acceso a tu diseñador desde el principio, pueden echar un vistazo a este componente y decir, sabes qué, esta parte aquí, no estoy tan seguro, algo sobre el contraste, algo sobre la apariencia, y pueden comenzar a jugar con eso, y tienen la documentación de Tailwind, sitios y ejemplos, todo eso, para que puedan decir, OK, tal vez ese tipo de tono, no, eso probablemente es demasiado oscuro, probemos algo intermedio, sí, y llegarían al resultado. Y la idea es dejar que ellos lo descubran. No quieres ser la persona que está moviendo píxeles en la pantalla solo para mover un botón cinco píxeles a la izquierda, cinco píxeles a la derecha, y que ese proceso se repita una y otra vez. Así que tráelos, acércalos, déjalos hacer eso por sí mismos. Entonces, si hemos adoptado un vocabulario, ahora podemos pensar aún más en grande. Tal vez frases enteras. Eso probablemente sería algo como una biblioteca de componentes, un sistema de diseño, completamente hecho, listo para usar, cosas como React Spectrum, Mui, Chakra, pero en este caso, hablemos de Fluent, un sistema de diseño de Microsoft. Puedes ver que desde el principio, están hablando contigo y con los diseñadores al mismo tiempo. Se aseguran de que ambos extremos de ese proceso tengan herramientas que puedan usar. Entonces, si, por ejemplo, entramos en este archivo de Figma y nos acercamos un poco para que puedas ver este bonito componente de mensaje aquí, entonces podemos, el diseñador ya tiene estos bloques de construcción, ¿verdad? Pueden tomarlos, pueden jugar con ellos y componerlos como quieran. Y luego, cuando llegas al código, ya no se sorprenden. Saben lo que esperan ver.

Ahora, los más observadores entre ustedes pueden haber notado que la versión que vemos aquí en el code y la versión que vemos aquí en Figma no son exactamente idénticas, y eso es la brecha a la que me referí anteriormente, ¿verdad? Siempre habrá alguna brecha si las herramientas de design no son nativas en sí mismas. Están imitando la web. Están tratando de copiar su comportamiento. Y así, aquí, el diseñador puede entrar fácilmente, jugar con las diversas interacciones, jugar con el comportamiento responsive y ver cómo se comportan las cosas y qué hacen. De acuerdo. Última parte, aceptar el cambio y construir confianza. Entonces, si nos hemos distanciado con el tiempo, creo que es crucial dedicar un esfuerzo para facilitar esa curva de aprendizaje, ¿verdad? Cada aprendizaje es una inversión. Aprendemos ahora para poder hacer algo con ello más adelante. Apoya a tus diseñadores. Anímalos. Guíalos. Permíteles ser parte de la discussion. Y no vienen por tu code. No te van a reemplazar. Ese componente de cuadrícula infinita súper complejo que estás desarrollando, se quedará contigo. Podrás centrarte en las cosas que quizás te atrajeron a esta profesión en primer lugar. La complejidad, la interactividad. Ellos vienen al code. Quieren ser parte de esta discussion técnica. Y has visto la evolución en las propias herramientas. Es hacia donde nos está llevando la industria. A medida que nos profesionalizamos, comenzamos a mezclarnos en la profesión del otro. Para resumir todo esto, te insto a que los incluyas técnicamente, de manera significativa, de una forma real. Invierte en sus habilidades técnicas. Ayúdalos a aprender. Facilita el acceso fácil para todos los miembros del equipo durante todo el proceso de desarrollo. No solo como un paso final. Trabajen juntos para establecer un lenguaje compartido, tanto en sus herramientas como en sus procesos, para evitar malentendidos, evitar errores y construir esa confianza entre ambos. Y por último, considera adoptar herramientas que ofrezcan soluciones interdisciplinarias que satisfagan las necesidades de ambos. Como se mencionó, si escaneas este código QR, verás todos los ejemplos, la presentación en sí, enlaces a Codex para que te intereses.

Tenemos una variedad de tutoriales en nuestro canal de YouTube para que los revises.

Muchas gracias por unirte hoy. Tenemos algunas preguntas que están llegando. Asegúrate de seguir enviando tus preguntas también.

Entonces, comencemos con la primera pregunta. Hablaste sobre lenguajes compartidos y cómo gradualmente se llega a tener herramientas compartidas. Y una pregunta para Tom, ¿cómo lograste que los interesados se unieran a GitHub? Para ellos siempre es difícil, se integran y luego fallan y vuelven a JIRA. Entiendo tu dolor, quienquiera que seas, cuando vas a JIRA. Lo siento, lo sentí en el alma. Pero, ¿cuál fue tu experiencia? Yo también he sentido ese dolor. No comenzamos con GitHub. Pasamos por JIRA, pasamos por otras soluciones. Estábamos constantemente en esta búsqueda de la herramienta que mejor reflejara nuestro trabajo. Y a medida que probábamos varias soluciones, descubrimos que todas carecían de esa parte en particular. Todas carecían de la conexión con el code y con la realidad de producción. Y creo que si necesitas convencer a otros interesados dentro de tu proyecto de que eso es valioso, comienza con una especie de demostración, algún proyecto pequeño. No te lances directamente a la parte más grande y compleja de tu proyecto. Hazlo paso a paso. Y creo que, al igual que en nuestro caso, ellos verán el valor. Tendrás menos conversaciones sobre cosas. Estarán más actualizados y más conectados con la realidad.

Genial. Gracias. Solo tengo una pequeña solicitud para aquellos de ustedes en la parte de atrás. Si están cambiando de sala, está bien. ¿Les importaría mantener sus voces bajas para que todos, incluso algunas personas en la parte de atrás, puedan escuchar a los oradores mientras responden preguntas? Muy bien. Tenemos muchas preguntas sobre Kodaks. Preguntan sobre Kodaks, los productos. Voy a hacer una pausa. Vamos a responder algunas de las preguntas de design de tu charla.

Claro. Y luego te daremos tiempo para responder las preguntas sobre Kodaks.

Entonces, el siguiente se trata de Scrum. Todos conocemos un poco sobre los sprints o las metodologías que usamos. ¿Cómo incorporas a los diseñadores en ellos? Esta persona pregunta cómo encajarías a un diseñador en un sprint de Scrum. Creo que si los ayudas a superar esa barrera, esa fase de aprendizaje inicial se convierten en un socio. Se convierten en alguien que está nadando en tu carril y tratando de llegar al mismo objetivo. Y usamos HL hasta cierto punto. Hacemos sprints. Trabajamos con equipos de producto. Y nuestros diseñadores están abriendo solicitudes de extracción. Yo apruebo la corrección de un diseñador para una parte de Kodaks que estaba rota. Esto es increíble. Es muy divertido.

No, seguro. Claro. Y luego el siguiente también se trata de documentar un lenguaje compartido. ¿Cómo documentar un lenguaje compartido para que sea fácilmente accesible para las nuevas personas en los equipos? Hay muchas formas diferentes, creo. Puedes optar por una solución clásica de documentación, como DocuZero y similares. Así que solo tienes tu documentación, simple, indexada, buscable, ese tipo de cosas. Si estás tratando de satisfacer a los diseñadores que tienden a ser mucho más orientados visualmente, asegúrate de proporcionarles ese tipo de ejemplos. Y si estás usando algo como Kodaks, entonces pueden ingresar directamente e interactuar con las cosas ellos mismos, jugar y ver cómo se siente. Comprender ese comportamiento.

Increíble. De acuerdo. Ahora, pasemos a algunas de las preguntas específicas de Kodaks que a mucha gente le encantó en absoluto. La primera pregunta es, ¿Kodak admite React Native? Desafortunadamente, en este momento no. React Native, aunque comparte React y su nombre, todavía está bastante lejos en términos de funcionalidad, APIs y todo eso. Estamos investigando en segundo plano si hay alguna forma de lograrlo. Pero no hay promesas de que sea pronto. Increíble.

Y luego hay otra pregunta, que se trata de la generación de código semiautomático a partir del diseño. Así que estamos incorporando a los diseñadores en estas herramientas, y muchas de estas herramientas dicen, oh, puedes arrastrar cosas. Prometieron un sueño que Dreamweaver intentó venderme cuando comencé mi viaje de desarrollo web. ¿Pero qué piensas de estas herramientas de generación de código semiautomático? Comenzaré con Dreamweaver, porque fue un punto muy interesante en ese momento. Conozco a muchas personas que comenzaron en el desarrollo front-end usando Dreamweaver. Y sí, si mirabas bajo el capó del código que se generaba, no era agradable de ver. Pero aún así estaba lo suficientemente cerca de la experiencia web como para poder comprender algunos conceptos. Ahora, en cuanto al aspecto generativo, estaba tratando de evitar la IA en esta charla, pero supongo que no se puede evitar. Ofrecen grandes soluciones. Por ejemplo, en Figma, tienes cosas como Locify, tienes varios complementos que te permiten exportar variables CSS e incluso HTML. Esas son excelentes para permitir que los diseñadores y las partes interesadas menos técnicas puedan desarrollar sus ideas. No necesariamente será el código de producción, y no reemplazará tu implementación. Pero si están tratando de transmitir una idea, o si están tratando de hacer una prueba de concepto, esas herramientas pueden llevarte muy, muy lejos. Increíble. Y luego también tenemos otra pregunta, que se trata de las pruebas. Es genial que los productos y el diseño se acerquen al código, pero ¿qué sucede cuando se trata de probar estos cambios? ¿Es algo que solo recae en manos de los desarrolladores? Creo que eso depende de cómo esté estructurado tu equipo. A veces serán los desarrolladores, a veces será más en el lado de QA y tal vez en el lado de la automatización. Nuevamente, al hablar con los diseñadores, creo que las pruebas visuales son una gran ventaja, ¿verdad? Porque quieres entender cuando has ido demasiado lejos, o cuando sucede algo inesperado. Creo que eso puede ayudar a cerrar esa brecha. Pero las pruebas siguen siendo fundamentalmente técnicas en su naturaleza. Así que al menos por ahora, hasta que implementemos algún tipo de prueba visual en CodeX, eso se queda con nosotros. Increíble. Increíble. Ahora, sé que CodeX, hay algunas otras herramientas por ahí, y tal vez algunas personas estén familiarizadas con otras herramientas que permiten visualizar algunos de estos componentes y cosas. ¿Qué es algo que CodeX, que distingue a CodeX de tener tal vez un storybook u otra cosa con la que los diseñadores puedan interactuar? En primer lugar, CodeX es un entorno de edición, ¿verdad? Vimos esto. Estaba haciendo cambios en tiempo real, viste que el escenario se actualizaba. Y esos cambios no eran solo seleccionar entre un conjunto de propiedades o controladores predefinidos que he conectado.

Es solo el code en sí mismo. CodeX está completamente sincronizado con el mismo proyecto que tienes abierto en tu IDE, de modo que cualquier cambio que realices en CodeX se verá en tu IDE y cualquier cambio que realices en tu IDE se verá en CodeX. En ambos sentidos, en tiempo real.

Increíble. Muy bien, responderemos nuestra última pregunta antes de la divertida que he guardado para el final. Pero alguien ha preguntado, colaboración versus la brecha de comunicación y el desarrollo impulsado por el comportamiento promete solucionarlo, promete resolverlo. ¿Tienes alguna experiencia o alguna idea sobre el desarrollo impulsado por el comportamiento? Creo que hemos realizado bastante testing utilizando metodologías impulsadas por el comportamiento, incluso dentro de CodeX mismo, y eso definitivamente ha dado buenos resultados. Creo que esos resultados aún están, dentro del mundo de las testing, más orientados hacia los desarrolladores, los ingenieros de QA, los ingenieros de producción, y así sucesivamente. Pero eso sigue siendo bastante. Si quieres llevarlo quizás un paso más allá en el establecimiento de ese lenguaje compartido, puedes explorar el diseño impulsado por el dominio, donde realmente llegas a definir estrictamente los contratos, los comportamientos, el lenguaje de cómo se va a configurar tu proyecto.

Increíble. Muy bien, por último pero no menos importante, tienes 20 segundos para responder esto. Los desarrolladores y los diseñadores están en una fiesta de D&D. ¿Qué clase es el desarrollador? ¿Qué clase es el diseñador? Voy a contigo. El desarrollador definitivamente es el bárbaro en esa relación. El diseñador, no sé, tal vez esté entre un clérigo y un bardo, algo así. Muy espiritual, muy creativo. Lo veo. Lo veo seguro. ¡Amigos, podemos aplaudir a Tom en grande? Gracias.