Visualizando React: Metáforas, Modelos y Medios Espaciales

♪♪ ♪♪ ♪♪ ¡Hola! Estoy realmente contenta de no poder veros a todos debido a la luz cegadora que es realmente útil pero esto va a ir bien. Bueno, sí, estamos arriba. Esta charla se llama Una Imagen Vale por Mil Programas y va a tratar sobre hacer imágenes, y específicamente sobre hacer imágenes de programas, y esperemos que sobre hacer imágenes que valgan por mil programas, como dice el refrán tradicional.

Así que, antes de empezar, quiero presentarme rápidamente y haceros saber que estoy aquí en el escenario hablando con vosotros sobre programas pictóricos. Así que, me llamo Maggie. Soy diseñadora, directora de arte, ilustradora, nerd de las metáforas y tangencialmente también construyo cosas con React. Pasé los últimos cinco años trabajando como directora de arte en Egghead.io que es una plataforma educativa para desarrolladores web pero a partir de la próxima semana, me mudaré a un nuevo rol, liderando el diseño en Hash.ai. Pero he pasado toda mi carrera hasta ahora creando representaciones visuales de programas. Durante mi tiempo en Egghead, hice cientos de ilustraciones de portada para los cursos que enseñamos. Cada una de estas empezaría con un concepto de programación abstracto y yo tenía que encontrar una forma de representarlo visualmente en una sola imagen. Aprendí a confiar mucho en las metáforas visuales para estas y estilizar CSS se convirtió en pintar una casa y organizar tipos se convirtió en trajes en una baraja de cartas. He hecho muchos diagramas ilustrados para explicar cómo funciona la herencia de prototipos de JavaScript o qué pasa cuando aplanas un array. Uno que se hizo popular fue un ensayo visual sobre qué son las APIs y cómo funcionan que se contaba a través de pequeños camareros robóticos que te traen los datos que pides. El objetivo era hacer que los temas técnicos complejos fueran más relacionables y fáciles de entender. También colaboré recientemente en un proyecto llamado Just JavaScript con Dan Abramov. Es un curso de JavaScript que enseña los modelos mentales centrales del lenguaje a través de diagramas visuales y animaciones. Así que trabajamos juntos para desarrollar todo este lenguaje visual que era un poco más formal que algunas de las otras ilustraciones que mostré. Cada pieza de sintaxis se correlaciona con una forma visual específica y usamos el sistema para explicar conceptos como asignar propiedades o mutación de objetos. No estoy repasando todo este trabajo para presumir, sólo quería daros contexto sobre el tipo de visuales de programación que he hecho en el pasado para que tengáis una idea de lo que quiero decir cuando digo imágenes de programación.

Así que en este proceso de transformar conceptos de programación en imágenes visuales cientos de veces, me he visto obligada a pensar mucho en la forma en que representamos y comunicamos ideas de programación complejas y he llegado a creer que las representaciones visuales tienen mucho que ofrecernos aquí en la tierra del código. En esta charla voy a mostraros cómo los visuales pueden hacer que los conceptos de programación sean menos abstractos, más fáciles de entender y más accesibles para más personas. También voy a mostraros por qué los visuales son tan especiales y resulta ser relativamente simple y es porque los visuales traen los invisibles conceptos abstractos de programación al mundo corpóreo. El mundo corpóreo es donde tú y yo vivimos. Todos los que están viendo esta charla tienen un cuerpo y lo usan para interactuar con objetos físicos a su alrededor y moverse por el espacio y experimentar eventos a lo largo del tiempo. Todo lo que sabes sobre el mundo está mediado por tu cuerpo y este hecho es tan fundamental que a veces lo olvidamos completamente. Y los conceptos de programación son ideas abstractas que no viven aquí en el mundo corpóreo con nosotros. Son objetos imaginarios y funciones que existen en el espacio liminal que parece que no obedece las mismas leyes de la física que nosotros. Y sólo podemos interactuar con ellos a través de esta experiencia desencarnada de teclear caracteres de texto lineales en un editor de código. Esto es precisamente lo que hace que la programación sea tan difícil. Estamos tratando de razonar y trabajar con cosas que no podemos ver ni tocar cuando somos criaturas que están evolutivamente adaptadas para funcionar en un mundo altamente visual, espacial y físico..

Y creo que los visuales son una gran parte de cerrar esa brecha entre nuestro mundo humano encarnado y el mundo de la máquina desencarnada en el que estamos tratando de programar. Entonces, aquí está el plan. Vamos a explorar este tema a través de tres preguntas.

Primero vamos a preguntar qué está mal con el texto, luego exploraremos qué pueden hacer los visuales que el texto no puede hacer, y finalmente haremos un breve recorrido histórico para averiguar por qué ya hemos intentado esto? Después de todo, no hay ideas nuevas bajo el sol y muchas, muchas personas en el pasado han explorado formas de hacer la programación más visual. Vamos a ver qué se ha intentado ya y qué oportunidades aún quedan por delante.

Entonces, primero, ¿qué está mal con el texto? Esta es una pregunta importante que hacer porque todo lo que hacemos en la programación se expresa en texto. Cada aplicación en la que has trabajado se ve así, ¿verdad? Es texto dispuesto en líneas que van de izquierda a derecha y de arriba a abajo. Aquí está cada sitio web de documentation que has usado. Aquí está cada entrada de blog que has leído. Todos nuestros lenguajes, herramientas y documentation de programación actuales son abrumadoramente centrados en el texto. A veces te encuentras con diagramas aquí y allá, pero son realmente escasos. Si tuviera que adivinar el equilibrio entre texto y visuales en nuestra industria, apostaría a que estamos en un 98% de texto y un 2% de visuales. Esto no se basa en una encuesta oficial y no pude encontrar a nadie que haya hecho una encuesta oficial, así que esto se basa simplemente en mi experiencia personal en la community de web development. Pero si te tomas un minuto y piensas en todo el code y la documentation con los que interactúas a diario, apuesto a que vas a llegar a una estimación similar.

Si miramos la historia de la programación, está bastante claro cómo terminamos en un mundo tan cargado de texto. Este es un ordenador, circa 1970. Notarás la falta de pantalla. Tenías un teclado y un montón de tarjetas perforadas, y lo único que podías hacer era escribir texto lineal para crear programas. Esta restricción de design significaba que todos nuestros primeros lenguajes de programación eran basados en texto, y una vez que estableces el texto como el paradigma principal de un campo, se vuelve realmente difícil alejarse de él. Especialmente en una industria donde confiamos tanto en las abstracciones de nivel inferior creadas por todos los programadores que nos precedieron. También hay muchas razones lógicas por las que confiamos tanto en el texto en la programación. Las palabras escritas y la sintaxis son un medio ideal para expresar la lógica abstracta. Es rápido de crear, es flexible, y es fácil de mover entre aplicaciones a través de copiar y pegar sin preocuparse por la compatibilidad. Puedes empaquetar una gran cantidad de información en un espacio muy pequeño, y puedes ser muy específico sobre lo que quieres decir, lo cual obviamente importa cuando estamos hablando con ordenadores que no tienen sentido de la sutileza.

Hasta ahora, el texto ha funcionado muy bien para nosotros en la programación. Pero algunas de las mayores fortalezas del texto también son sus mayores debilidades. La naturaleza abstracta del texto es lo que lo aleja de nuestras experiencias encarnadas en el espacio y el tiempo. Cuando hacemos code, estamos escribiendo un conjunto de instrucciones hipotéticas para ejecutar en la máquina de otra persona en algún momento en el futuro en un tiempo y lugar que nunca conoceremos. Este nivel de abstracción elimina las cualidades físicas, espaciales y encarnadas que los humanos dependen para entender el mundo que nos rodea. Esto puede ser bueno en algunos aspectos, ¿verdad? Si queremos escribir una función como fetch user data, no tenemos que definir el tamaño, la forma, o el color de la misma.

Es solo una simple función flotando en la tierra de la máquina. Si ya sabes qué es esta función y cómo funciona y dónde está ubicada, este nivel de brevedad es genial. Pero imagina a alguien nuevo en la programación que nunca ha escrito una función para fetch user data y no tiene un modelo mental preexistente de cómo podría funcionar. Una de las formas más fáciles y efectivas de hacerlo comprensible para ellos es explicar en términos familiares utilizando cualidades físicas que ya entienden como el tamaño, la forma, el color y las relaciones espaciales. Lo cual podría darnos algo como esto para ayudar a explicar qué hace una función fetch user data. El visual no tiene que ser locamente complejo o hermoso. Las cajas y flechas funcionan muy bien. Ciertamente estamos permitidos a usar etiquetas de texto para hacer la imagen clara. Visuales como este nos permiten usar nuestro conocimiento encarnado preexistente para mostrar cómo funcionan los programas de una manera que el texto lineal no puede.

Así que acabo de empezar a insinuar la pregunta que vamos a examinar en la segunda parte, que es ¿qué pueden ofrecernos los visuales que no podemos obtener del texto lineal? Creo que los visuales revelan tres aspectos de la programación que no podemos ver en el texto lineal. Revelan metáforas fundamentales incrustadas en nuestros lenguajes de programación. Revelan mapeos espaciales que usamos para razonar sobre cómo están estructurados nuestros programas y cómo se mueven los data a través de ellos, y revelan cómo se comportan nuestros programas y data a lo largo del tiempo. Estas cosas están todas implícitas en los programas que escribimos pero no se muestran explícitamente en el medio del texto lineal. Así que comencemos con las metáforas. Solo para asegurarnos de que todos estamos en la misma página, establezcamos que las metáforas son herramientas de pensamiento que nos permiten entender una cosa en términos de otra. Así que digamos que tenemos la cosa A aquí, que entendemos, y la cosa B, que no entendemos. Mapeamos las cualidades de la cosa A sobre ella. Si decimos que la corrupción es una enfermedad, entendemos que la corrupción se propaga, es difícil de superar, y si se deja sin controlar, puede matar. De manera similar decimos que la vida es un viaje. Hay muchos caminos que nuestra vida podría tomar y varían en longitud y todos tienen un comienzo y un destino final. Cuando hablo de metáfora en el contexto de la programación, no me refiero a las metáforas creativas fantasiosas que encuentras en la poesía como tomar el camino menos transitado y vagar solitario como una cloud. Esas se llaman metáforas figurativas o poéticas y son el tipo que a menudo se nos advierte que no usemos en tutoriales técnicos ya que las metáforas elaboradas y mal elegidas pueden ser más confusas que útiles. Estoy hablando de un tipo de metáfora mucho más fundamental que está en el corazón de todo el pensamiento abstracto incluyendo la programación. Estas se llaman metáforas cognitivas ya que permiten la cognición en un nivel mucho más profundo. Estas metáforas cognitivas se basan en nuestras experiencias encarnadas del mundo. Tenemos todas estas cosas no físicas que necesitamos comunicar entre nosotros como emociones y pensamientos e ideas y programming concepts. Para entenderlos y hablar de ellos, usamos nuestra experiencia del mundo físico que nos rodea como una metáfora. Si observamos la forma en que hablamos de cosas abstractas, esto se vuelve obvio. Hablamos de ideas en términos de luz cuando decimos que es una idea realmente brillante o que realmente iluminó el problema. Hablamos de las emociones como si fueran objetos. Diremos, él escondió su celos o ella no maneja muy bien la ira. También podemos usar metáforas de fuerza y movimiento para describir experiencias. Podemos decir encontré tu charla conmovedora o tu charla realmente me tocó. Programación en términos de temperatura. Tenemos recarga en caliente en React o el panorama de JavaScript se está calentando. Esta no es una teoría que acabo de inventar. Estos principios provienen del campo de la metáfora cognitiva y la cognición encarnada. Fueron desarrollados por primera vez en la década de 1980 por George y Mark Johnson quienes han escrito numerosos libros sobre este tema y se ha convertido en un área importante de investigación en la ciencia cognitiva. Estos dos libros, Filosofía en la Carne y Metáforas que Vivimos son dos de los principales Pero no puedo profundizar demasiado en ello aquí.

Así que, esperemos que puedas hacer un doctorado sobre ello. Y al igual que cualquier otro tema abstracto que no podemos ver ni tocar, la programación se basa en gran medida en estas metáforas físicas encarnadas y tenemos que hacerlo porque la programación en sí es un juego de abstracciones, ¿verdad? Escribimos un archivo JavaScript y lo que realmente estamos haciendo es decirle a un microchip que cambie un montón de puertas lógicas usando pequeños pulsos eléctricos. Esto es tedioso y difícil para los humanos, por lo que hemos desarrollado una pila de metáforas elaboradas que lo hacen más rápido y fácil. Algunas personas podrían preferir llamar a estas abstracciones, pero para los propósitos de esta charla, asumamos que las metáforas y las abstracciones son más o menos lo mismo y podemos debatir las diferencias en Twitter más tarde.

Simplificamos nuestro code binario en code de máquina que simplificamos en lenguajes de nivel superior como JavaScript que simplificamos en GUIs. Y en cada paso de este proceso, estamos tratando de hacer que el mundo abstracto de la máquina se parezca a nuestro mundo humano tangible. Porque cuanto más nos acercamos al conocimiento intuitivo encarnado en el lado superior derecho de la scale, más fácil se nos hace entender lo que está sucediendo en un sistema.

Los componentes en React son un gran ejemplo de estas metáforas encarnadas en acción. Entonces, los componentes son esencialmente containers, ya sabes. Contienen conjuntos de elementos de UI para nosotros. Así que un componente de tarjeta podría tener una imagen, un botón y un párrafo dentro de él. La CPU que va a renderizar este componente en la pantalla no sabe nada sobre containers. Solo conoce el code de máquina y cómo hacer que los píxeles correctos se iluminen. El contenedor es una metáfora que necesitamos los humanos para gestionar y organizar el code que escribimos. La única razón por la que sabes lo que es un contenedor es porque cuando eras niño, vertiste arena en un cubo y la volviste a sacar. Y a través de este mundo físico, donde estás haciendo experiencia y aprendizaje encarnados, containers contienen cosas. Tienen interiores y exteriores. Tienen límites. Todos estos conceptos son esenciales y necesarios para que entiendas cómo funcionan los componentes en React. Así que tomemos otro. En React, estructuramos nuestros componentes en un árbol jerárquico donde todo está conectado de vuelta a un único componente raíz. Sabes lo que es un árbol por haber visto miles de árboles, y entiendes que tienen muchas ramas que se extienden desde una única raíz, una comprensión que te permite trabajar con árboles de componentes en React. La metáfora del árbol también es una especie de doble metáfora ya que se basa en la idea de un árbol genealógico. Tenemos componentes padres e hijos que heredan props de la misma manera que los niños heredan cualidades de sus padres, y estos conceptos que estamos tomando prestados del mundo humano nos permiten interactuar con las máquinas de una manera que es fácil y natural para nosotros. Y probablemente puedes ver a dónde voy con esto. Dado que tu comprensión de React se basa en tu conocimiento preexistente del mundo físico que te rodea, sería útil si pudiéramos hacerlo explícito en la forma en que representas y explicas React. Y los medios visuales nos permiten hacer esto. Ciertamente puedes leer sobre las estructuras de componentes de React y la transmisión de props, y luego formar una imagen mental en tu mente basada en tu comprensión de los árboles físicos y la herencia familiar, y luego aplicar ese conocimiento a la escritura de code lineal, todo sin verlo nunca explícitamente visualizado. Pero eso se llama hacerlo más difícil de lo que tiene que ser. Así que pasemos a la siguiente cualidad visual, el espacio. Como humanos con cuerpos, entendemos inherentemente una gran cantidad de conceptos espaciales como arriba, abajo, izquierda, derecha, dentro, fuera, grande, pequeño, y usamos metáforas al igual que usamos conceptos físicos para entender los programas. También usamos conceptos espaciales para hablar de la estructura y el comportamiento de los programas. Si piensas en la forma en que hablamos de internet, hay direcciones físicas muy claras para ello.

Subimos data a la cloud sobre nosotros y descargamos archivos a nuestros escritorios. Miramos a través de una ventana del navegador. Navegamos por las páginas web moviéndonos de izquierda a derecha. Por lo tanto, las páginas que visitaste en el pasado están a la izquierda y las páginas a las que vas en el futuro están a la derecha. Este formato se basa en nuestra cartografía cultural occidental del tiempo al espacio. Pensamos que el pasado está a la izquierda y el futuro a la derecha, pero no todas las culturas hacen eso.

Específicamente en React, usamos nuestra comprensión de las direcciones verticales para pensar en cómo se mueven los data. React tiene un orden jerárquico de dos componentes y los componentes padres están por encima de los hijos y pasan data hacia abajo, lo que significa que tenemos gravedad en la tierra de React. La idea de la perforación de propiedades es otra que sugiere perforar hacia abajo, por lo que tienes que pasar data profundamente en tu árbol, por lo que también tiene profundidad. Cuando hablamos de efectos secundarios, estamos usando nuestra comprensión de que hay un centro y una periferia donde las cosas suceden al margen, por lo que cuando ejecutamos una función como un set timeout dentro de un hook use effect, entendemos que está accediendo a algo fuera de nuestro componente central. Podría seguir. Nuestras aplicaciones tienen frontends y backends, fusionas objetos, captas la idea aquí. Usamos principios espaciales de nuestra experiencia encarnada del mundo para hablar y entender React. Cuando creamos visuales que muestran estos principios espaciales explícitamente, aclara lo que ya estamos haciendo en nuestras cabezas.

Nuestro elemento final aquí es el cambio a lo largo del tiempo. Cuando trabajamos en un editor de texto lineal, el tiempo es esencialmente invisible. Estamos mirando una representación estática que describe una serie completa de eventos futuros que pueden o no suceder dependiendo de qué botón haga clic un usuario o si nuestra solicitud de data se resuelve. Nos vemos obligados a usar nuestra imaginación para predecir lo que va a suceder en todos esos potenciales futuros, en lugar de poder verlo de alguna forma. Nuestra mejor técnica actual para tratar de ver cómo cambian las cosas con el tiempo es el registro de console data en el camino. El registro de console se siente como tratar de hacer que un programa envíe señales a la superficie de un oscuro océano donde todo se está ejecutando fuera de la vista. No podemos ver nada sucediendo allí abajo y tenemos que seguir pidiendo clues sobre cómo está cambiando la data, lo que no parece la mejor developer experience. Aquí es donde los visuales podrían ser útiles nuevamente porque nos permiten ver múltiples puntos en el tiempo dentro de un solo marco. Nos permiten comparar cosas lado a lado de una manera que no podemos con el texto lineal. Básicamente nos permiten jugar a encontrar las diferencias. Veamos la sintaxis del hook use effect como un ejemplo de esto. Aquí hay cuatro versiones diferentes del hook use effect que se comportarán de manera diferente cuando se ejecuten en el navegador. El primero no tiene matriz de dependencia. El segundo tiene una vacía. El tercero tiene el valor count como una dependencia, y el cuarto también tiene count como una dependencia y ejecuta una función de limpieza. Solo mirando estas cuatro versiones de sintaxis, ¿tienes alguna forma de saber cómo se va a ejecutar esta función una vez que se cargue en el navegador? Específicamente, ¿sabes con qué frecuencia se va a llamar y cuándo? Dada la demografía de esta audiencia, apuesto a que sí.

Es porque has memorizado el significado sintáctico aquí en lugar de saber porque la respuesta es visible en nuestra sintaxis. Lo que necesitamos hacer aquí es comparar cuatro cosas que se comportan de manera diferente con el tiempo. La mejor manera de hacer eso es mostrar visualmente qué cambia con el tiempo. He hecho un conjunto simple de diagramas que intentan mostrar la diferencia entre estos cuatro en una línea de tiempo. Aquí está nuestra primera versión sin dependencia en la RRA. La función use effect se llama en cada renderizado, independientemente de si nuestra variable count se actualiza o no. Aquí está nuestra segunda versión donde el array de dependencia está vacío, por lo que la función de efecto de usuario solo se llama en el renderizado inicial, y todavía no nos importa lo que la variable count esté haciendo. En nuestra tercera versión, con count en el array de dependencia, use effect se llama solo cuando count se actualiza, lo que provoca un nuevo renderizado. En nuestra versión final, use effect se llama en las actualizaciones de count y ejecuta una función de limpieza después. Incluso si quitamos las etiquetas en estos, esta simple representación visual de cómo use effect se comporta con el tiempo nos da una comprensión mucho mejor de cómo funciona que la sintaxis lineal es capaz de hacerlo.

Entonces, parte tres, ¿no lo hemos intentado ya? Obviamente, no soy la primera persona en darse cuenta de que los medios visuales nos permiten entender y razonar de formas que vale la pena explorar en la programación. La forma principal en que las personas han intentado incorporar elementos visuales en la programación en el pasado es pegando interfaces gráficas de usuario en los IDEs. Estos esfuerzos caen bajo el paraguas de lo que se llama programación visual.

Ha habido muchos, muchos intentos pasados en esto con grados variables de éxito. Voy a repasar rápidamente algunos ejemplos para que tengas una idea de lo que ya se ha intentado. El primer lenguaje de programación visual fue el Sketchpad de Ivan Sutherland en 1963. Este es Grail de 1968 donde pusimos texto en cajas por primera vez. Este es Pygmalion de 1975 que se basó en ese modelo de caja y flecha. Este es LabVIEW que salió en 1986 y se usa para ingeniería de sistemas y nos volvimos mucho más intensos acerca de las cajas en esta etapa. Aquí hay un ejemplo más moderno. Este es Blueprint en Unreal Engine, que se utiliza para el desarrollo de juegos 3D. Este es Max MSP, que se utiliza ampliamente para construir experiencias audiovisuales. Aquí está Touch Designer, también para multimedia interactiva. Este es Origami Studio, una herramienta de prototipado construida por Facebook. Notarás que el patrón de diseño de nodos y cables es muy popular en muchos de estos.

Entonces, hay muchas cosas prometedoras en estos ejemplos, pero la programación visual sigue siendo relativamente de nicho. También hemos descubierto un montón de desafíos de diseño realmente difíciles de resolver. Estos sistemas no escalan bien, a veces usan símbolos ambiguos y patrones de interfaz desconocidos. Intentan convertir todo en una caja, lo que ocupa demasiado espacio en la pantalla. Puede llevar a un código literalmente espagueti. Este es un prototipo de Figma que salió muy mal. Estos problemas han llevado a mucho escepticismo sobre la viabilidad de la programación visual. Ser un defensor de ella a menudo se siente como ser Gretchen en Mean Girls. La programación visual ciertamente no está muerta, sin embargo. Curiosamente, el nuevo movimiento de no código y bajo código parece programación visual bajo un nuevo nombre. Muchos de los patrones de interfaz que ayuda a desarrollar la programación visual son visibles en herramientas como IntegroMet y Zapier y Webflow. Pero en lugar de intentar construir lenguajes de programación visual que puedan alcanzar escalas industriales, hemos pasado tácticamente a desarrollar interfaces visuales para casos de uso específicos en programación con restricciones sensatas. Soy un gran fan de la agenda de programación visual y encontrar formas de agregar más posibilidades visuales en las herramientas actuales de desarrollo y hay muchas personas inteligentes e impresionantes trabajando en el problema, pero en muchos aspectos, está tomando el camino difícil. Construir un verdadero medio de programación visual requerirá superar un montón de desafíos de diseño y cultura e ingeniería y, francamente, va a llevar un tiempo.

Pero hay formas más fáciles de avanzar en este esfuerzo a corto plazo. Simplemente podemos esparcir algunos visuales en nuestro mundo textual existente, lo que significa agregar más diagramas e ilustraciones en publicaciones de blog, documentation y materiales de aprendizaje y si nos sentimos valientes, construyendo plugins para nuestros editores y herramientas de desarrollo que visualicen elementos muy pequeños de nuestros programas. Esta es esencialmente la versión de prototipo de papel de bajo tecnología de la construcción de una interfaz de programación visual completamente desarrollada.

Entonces, para concluir, aquí está lo que quiero que te lleves de esta charla. Necesitamos más visuales que revelen metáforas, significado espacial y cambio a lo largo del tiempo para hacer la programación más fácil para todos. Te facilitará a ti, ya que eres un humano encarnado que necesita aprender conceptos abstractos de programming concepts para hacer bien tu trabajo. Facilitará a todas las personas que actualmente no saben cómo programar pero están tratando de aprender y facilita a las personas que no son desarrolladores pero necesitan entender lo que hacemos, como los gerentes de producto y diseñadores que no pueden leer todo el argot en nuestra documentation pesada en texto.

Entonces, ¿qué debe hacer un desarrollador? Estoy seguro de que eres un humilde pero hábil desarrollador de React y quieres ayudar a avanzar en este objetivo. Primero, sugiero encarecidamente que investigues la historia de la programación visual y algunos de los pasados intentos en este campo. Hay mucho buen arte previo del que aprender. Si eres un creador actual o futuro de herramientas para otros desarrolladores, deberías considerar formas de incorporar posibilidades visuales en tus bibliotecas, plugins, aplicaciones o frameworks. Y finalmente, deberías usar y abogar por explicaciones visuales y documentation y tutoriales. Eso podría significar hacerlos para tus propias publicaciones de blog o colaborar con diseñadores si trabajas en proyectos más grandes con mucha documentation. Así que podemos poner el listón bajo por ahora. Estamos tratando de mover esta estadística falsa hasta, digamos, el diez por ciento. Así que eso fue mucha información empaquetada en una charla. Definitivamente esto fue más una degustación que una comida completa, así que he reunido una lista de algunas cosas que puedes buscar en Google para aprender más sobre este tema. Estos estarán en mi sitio web. George Laycoff y Mark Johnson son los que trabajaron en metáforas cognitivas. El trabajo de Barbara Javersky sobre cognición encarnada es genial. Literalmente todo lo que Brett Victor ha hecho vale la pena tu tiempo. Y hay algunos recursos realmente geniales en futureofcoding.org, son algo así como una community de entusiastas de la programación visual. Y el libro Visual Explanations de Edward Tufte es realmente genial para obtener advice. Así que muchas gracias por escuchar. Publicaré estos en mi sitio web, maggieappleton.com, donde tengo más escritos sobre metáforas y programación visual y ese tipo de cosas. Y puedes enviarme un tweet a @mappletons. Increíble. Gracias, Maggie. Por favor, ven y únete a mí en la oficina. Eso fue realmente increíble.

Y la gente tiene muchas preguntas. Así que vamos directo al grano. L, la letra, pregunta ¿cómo llegas a una metáfora visual? ¿Es algo que forms inconscientemente mientras te relacionas con el concepto? ¿O razonas verbalmente a través de ello? Definitivamente razono verbalmente a través de ello e investigo. Así que confío mucho en la lingüística y en el tipo de técnicas que los lingüistas utilizan para analizar el lenguaje que usamos en torno a las cosas. Así que cuando estoy tratando de design una metáfora para una cierta tecnología, leo los docs y realmente presto atención a las palabras que están usando. Y casi siempre están usando palabras físicas. Están moviendo, pasando, ya sabes, cosas espaciales. Están hablando de cómo las cosas están dispuestas en el espacio aunque sólo estén escribiendo en texto lineal. Pero presto mucha atención al lenguaje.

Hay más de una pregunta preguntando si tienes pegatinas o merchandising de tus ilustraciones. ¡La gente necesita más Maggie! No vendo nada personalmente. Egghead tiene un sitio de merchandising donde venden algunas de las pegatinas de ilustración del curso. Pero también tendemos a regalarlas gratis cuando aparecemos en conferencias. Pero no tengo una tienda de merchandising organizada. Lo siento.

Y de manera similar, de nuevo, la gente realmente está interesada. ¿Hay alguna posibilidad de una colaboración con el nuevo equipo de documentación beta de React? Creo que estoy autorizada para decir. Podría tener algunas visuales en la nueva documentación de React. Increíble. Están en progreso.

Uh, sí. Lo sé, ¿verdad? ¿Qué recursos recomendarías para alguien que quiere explorar estos conceptos más a fondo? Sé que mencionaste un par. ¿Pero hay algo más que te gustaría añadir? Creo que lo mejor es quizás ir a mi sitio web donde tengo esa lista en la sección de programación de imágenes. Añadiré más allí. Porque tengo una lista larga. Pero llevaría un tiempo leerlas todas.

Un par de personas están interesadas en las herramientas. ¿Qué usas para dibujar, para añadir tus ilustraciones a la presentación, etc.? Todas las ilustraciones que dibujo hoy en día son en un iPad con Procreate. Solía dibujar más en Photoshop en un Cintiq. Para ser honesta, son casi intercambiables y el iPad es simplemente mejor. Hemos tenido avances mucho mejores en hardware y software en los últimos cinco años que el iPad es una especie de estado del arte.

Esta es una interesante. ¿Crees que ... Estoy seguro de que hay. ¿Existe potencialmente un problema de que las metáforas sean interpretadas de manera diferente por diferentes países y culturas y cómo pensamos en eso? Definitivamente hay en que las metáforas son increíblemente culturales. Casi todas las metáforas que usamos están delimitadas al país en el que estamos y el idioma que estamos hablando. Dado el hecho de que React y la comunidad de desarrollo web es un lugar bastante unificado y todos tenemos una comprensión bastante compartida de metáforas y símbolos. Encuentro que no es tan difícil encontrar metáforas que se relacionen con todos. Aunque, siempre estoy consciente de que si alguien en otro país que no tiene muchas de las mismas asociaciones que nosotros lo ve, hay una buena posibilidad de que puedan perder matices de ello.

Eso es algo que debes considerar caso por caso. Necesitaremos Maggies en todos los países y en todas las zonas horarias, por si acaso. ¿Deberíamos, crees tú, estar aprovechando las metáforas existentes que ya están en nuestros lenguajes de programación y frameworks? ¿O intentar optimizar para aquellas que quizás comunican algo bien? Esa es una buena pregunta. Casi se convierte en una pregunta de diseño de lenguaje de programación. Me gusta suponer que las personas que diseñaron el lenguaje de programación pensaron lo suficiente en abstracciones y en el lenguaje de la API que las metáforas que han elegido, ya sea consciente o inconscientemente, son las correctas. No intento inventar nuevas de la nada si estoy tratando de dibujar algo que realmente pretende explicar el punto. Pero a veces, si no parece que haya una metáfora clara, es cuando te metes en la invención de una que se ajuste a las necesidades. Sí. Eso es realmente genial. Hay un par aquí que son personas que quieren saber un poco más sobre ti y tu proceso. ¿Empezaste a programar y luego te metiste en el diseño, o viceversa? ¿Cuál es un poco más tu proceso para convertir los conceptos de programación en? Mencionaste leer un poco la documentación. ¿Hay algo más que haces? La documentación y luego hago cosas como navegar por Reddit y Twitter y simplemente busco el lenguaje que la gente común usa alrededor de lo que sea la tecnología, si eso responde la pregunta. ¿Y cuál vino primero? Más o menos ambos al mismo tiempo. Empecé a jugar con HTML cuando tenía 12 años y había mucho deseo de hacer cosas bonitas en la web fue el impulso allí. Así que siempre he hecho ambos y he pasado por diferentes períodos de intensidad para cada uno. Creo que cuando empecé a aprender React hace seis años, me metí mucho más en la programación durante unos años y estaba principalmente diseñado antes de eso. Pero siempre he ido y venido. ¿Haces... esto es solo yo pensando, haces muchos dibujos en papel y lápiz alguna vez? Sí. Como, casi todos mis dibujos comienzan en notas adhesivas con un lápiz, y el iPad es realmente solo el paso final, pero hay muchos bocetos en el medio donde estoy simplemente averiguando cosas, y la versión final pulida casi nunca es la que lleva tiempo o el mayor esfuerzo. ¿Alguna vez encuentras un dibujo y no recuerdas para qué era? ¿Hago qué? ¿Encuentras un dibujo y no recuerdas para qué era? Oh, sí. No, sí. Miro hacia atrás, como, de la misma manera que encuentras notas de hace 10 años y dices, no entiendo ni siquiera qué se suponía que debía ser esto. Tenemos tiempo para una más. Drew pregunta, ¡ayuda! Soy terrible en el diseño y el dibujo. ¿Qué puedo hacer? Ooh. Tengo en mi sitio web, una lista completa de todos mis cursos y libros favoritos y enlaces y cosas que tratan sobre las tecnicidades de cómo dibujas bien un círculo, cómo haces que una cara humana parezca una cara humana? Ese tipo de contenido de dibujo técnico, eso, sí. Los recursos en mi sitio web serán un buen recurso para ti. Muchas gracias, Maggie, por tu tiempo. Encuentra a Maggie en internet. Claramente grandes recursos allí. Un gran agradecimiento a Maggie, por favor.