Post-humanismo y diseño

No todos podemos sostener, con un alto grado de seguridad, que hemos sido siempre humanos. – Rosi Braidotti “Lo Posthumano”

El concepto de humano, nacido en la Ilustración, nos da cierta tranquilidad. Ser humano es lo natural en nosotros, es nuestra característica fundamental como especie, nuestra identidad.

Sin embargo, en el contexto de las sociedades globalizadas y tecnológicamente dirigidas, esta identidad y sus relaciones con los demás se vuelve más compleja. Robots, prótesis, neurociencias, biogenética nos llevan a un mundo de tecnotranscendencia y ciberdrama.

Read more

Diseñar con datos, más allá del A/B Testing

Resumen

Diseñar con datos parece sencillo: haces un test A/B y te quedas con la solución que más conversiones tenga ¿cierto? pero ¿somos conscientes de lo que nos dicen los datos? ¿cómo sabemos qué conviene evaluar? ¿qué hacemos si los resultados contradicen nuestras ideas originales?

¿Hay vida (y datos) más allá de los tests A/B? En esta charla me gustaría compartir algunas ideas y experiencias sobre cómo, cuándo, dónde y por qué podemos usar los datos a lo largo de un proceso de diseño para la Experiencia de Usuario, desde la investigación de usuarios (cuantitativa) hasta la toma de decisiones sobre un producto digital real.

Trataremos también de reflexionar (durante y después de la charla con un café) sobre cómo crear una cultura del diseño informado con datos, donde la experimentación y el desafío sean una constante.

Además, los datos están de moda, el diseño marca la moda, Netflix lo hace ¿qué puede salir mal?

Read more

Recursos para una intro a la UX

Este artículo está especialmente dedicado al alumnado del Máster Front-end Lemoncode, aunque creo que puede resultar útil a cualquier persona con perfil de desarrollo que quiera comenzar a practicar y saber más sobre la Experiencia de Usuario. 

Empiezo recordando un artículo que no pasa de moda: 14 libros de UX que pueden darte una base sólida teórica y conceptual sobre Diseño y Experiencia de Usuario.

Un recurso  online gratuito y tremendamente valioso es The Encyclopedia of Human-Computer Interaction.

Una vez tengamos alguna base teórica os comparto también recursos prácticos que cualquier perfil puede intentar utilizar en su día a día desde el momento cero.

Cómo hacer entrevistas

Steve Portigal es un referente en este ámbito, su libro Interviewing Users puede resultaros útil para empezar. Aunque si lo que queremos es sacar el máximo rendimiento, podéis seguir los consejos de este artículo:  3 better questions to ask in user interviews.

Read more

Test de usabilidad automático

Estamos ante un panorama donde el desarrollo de aplicaciones con tecnologías web está creciendo muy rápidamente y esto merece una atención especial. En concreto lo que respecta a la tradicional analítica web no parece salir de los modelos de aplicaciones como los e-commerce o redes sociales a la hora de ofrecer herramientas que permitan entender e interpretar ‘lo que está pasando’ desde una perspectiva de usuario. Plantearnos cómo podemos mejorar estas herramientas de analítica para entender cómo se comportan nuestros usuarios al mismo tiempo que capturamos datos globales sobre su experiencia y su percepción de usabilidad nos ayudará a tomar mejores decisiones de diseño.

En este artículo busco describir un modelo de automatización de los tests de usabilidad con usuarios como continuación del trabajo anterior ‘Measuring UX with your own tools’ con el que poder:

  1. Medir y analizar grandes cantidades de datos generados por los usuarios.
  2. Hacer del diseño un proceso experimental y cuantificable.

Partimos de que la Experiencia de Usuario abarca muchas más cosas que la interacción del usuario con el producto digital a través de su interfaz, pero que esta interacción condiciona su experiencia y es una parte fundamental de la misma. Dejando un lado la visión holísitica del término, la teoría de la actividad vendría a describir el framework en el que se basa este modelo de representación, análisis e interpretación, aunque no está limitado al mismo. Este trabajo también se inspira en la metodología HEART de Google como método para medir la UX a gran escala para aplicaciones web.

Read more

Ciencia de Datos y Experiencia de Usuario

La ciencia de datos no es algo en lo que una persona pueda especializarse en poco tiempo y es, sin embargo, una de las carreras más tendenciosas de los últimos cinco años. Si éste es un perfil profesional único como el de Experiencia de Usuario (UX) el tiempo lo dirá. Han pasado ya veintiocho años desde que Don Norman se llamara a sí mismo ‘User Experience Architect’ y al menos cincuenta desde que se hablara de la Interacción Persona-Ordenador.

Pero ¿cuál es la relación entre estas dos profesiones? ¿debe un especialista en UX saber algo sobre ciencia de datos? ¿debe un diseñador aprender a programar?

En este artículo me gustaría explicar por qué creo que es importante entender qué es la ciencia de datos y cómo puede aprovecharse desde el diseño de experiencias.

Cuantificando la Experiencia de Usuario

Si ya es difícil diseñar experiencias más de uno pensará que es casi imposible cuantificarla. Si bien no todos los factores que influyen en la interacción y la experiencia con el producto final pueden ser medibles, existen multitud de datos relacionados con la misma que pueden recogerse y analizarse para guiar el proceso de diseño:

  • Datos descriptivos de los usuarios (datos demográficos o tecnología que usan).
  • Datos de actividad y comportamiento (contenido que visitan, búsquedas, interacciones, tiempo que dedican…).
  • Conversión de objetivos.
  • Datos sobre la ejecución de tareas específicas (éxito de la tarea, duración, eficiencia, errores, satisfacción, aprendizaje).

Hasta ahora, todos estos datos los hemos venido interpretando de forma puntual y aislada buscando dar respuesta a algunas de las preguntas más importantes que nos hacemos durante el proceso:

  • ¿Cómo son nuestros usuarios? ¿cómo han llegado hasta mi producto?
  • ¿Qué necesidades de información tienen? ¿cómo interactúan para conseguirla?
  • ¿Han realizado determinada acción?
  • ¿Qué contenido funciona mejor que otro?
  • ¿Consideran que el producto es usable?

Read more

(echo echo) echo (echo): Poética de la línea de comandos

Me gustaría un texto que encontré hace tiempo y me pareció precioso. Desgraciadamente la web donde lo leí lleva caída mucho tiempo y sólo he podido rescatarlo dese archive.org. Ojalá lo hubiera escrito yo, pero no 🙂 el autor original es Florian Cramer y está traducido por Kamen Nedev (trad.)  – 2007 – CC-BY-NC-SA (espero que os guste tanto como a mí)

 

Diseño

La mayoría de los argumentos a favor del uso de la línea de comandos frente al uso de la interfaz gráfica de usuario (GUI) están lastrados por un platonismo de administrador de sistemas. Una instrucción como «cp test.txt /mnt/disk» no está, en realidad, ni un milímetro más cerca de una hipotética «verdad» de la máquina que arrastrar un icono del archivo.txt con el ratón al símbolo de un disco duro montado. Y, aunque estuviera más cerca de la «verdad» ¿qué ganaríamos con ello?

La línea de comandos es, de por sí, una interfaz de usuario tan abstraída del kernel del sistema operativo como lo es la GUI. Mientras que el aspecto y usabilidad de «escritorio» de la IGU emula objetos de la vida real de un entorno de oficina analógico, la línea de comandos de Unix, BSD, Linux/GNU y Max OS X emula las máquinas de teletipo que servían como terminales de usuario en los primeros ordenadores Unix de principios de los 70. Este legado sigue vivo en la terminología de la «terminal virtual», y el archivo de dispositivo /dev/tty (de «teletipo») en sistemas operativos compatibles con Unix. Por tanto, tanto el uso de entornos gráficos como el de la línea de comandos son medios; capas de mediación en el bucle de retroalimentación cibernético entre humanos y máquinas, y pruebas de la veracidad de la afirmación de McLuhan de que el contenido de un nuevo medio es siempre un medio antiguo.

Ambas interfaces de usuario fueron diseñadas con objetivos diferentes: en el caso del teletipo de la línea de comandos, el de minimizar el esfuerzo y el gasto de papel, mientras que en el caso de la GUI fue el uso de analogías – en un caso ideal – autoexplicativas. La minimización de escritura y gasto de papel tenía la intención de evitar la redundancia, manteniendo la sintaxis y la respuesta de las instrucciones lo más sucintas y eficaces posibles. Por eso «cp» no se escribe «copy», «/usr/bin» no es «/Unix Special Resources/Binaries», y por eso también el resultado de la instrucción de copiar recibe como respuesta una línea en blanco, y por eso la instrucción puede repetirse simplemente pulsando la flecha hacia arriba y el retorno, o por qué volver a escribir «/mnt/disk» se puede evitar escribiendo simplemente «!$».

A su vez, la GUI reinventa el paradigma de los lenguajes universales de signos pictóricos, ideados por primera vez en las utopías educativas del Renacimiento, desde la Ciudad del Sol de Tommaso Campanella hasta el libro escolar ilustrado «Orbis Pictus» de Jan Amos Comenius. Los objetivos de sus diseños eran similares: «usabilidad», operación autoexplicativa a través de diferentes lenguas y culturas humanas, si es necesario a costa de la complejidad o la eficacia. En la operación de copiar un archivo, el acto de arrastrar es, en sentido estricto, redundante. Al significar nada más que la transferencia de «a» a «b», consigue exactamente lo mismo que el espacio entre las palabras – o, en términos técnicos: los argumentos – «test.txt» y «/mnt/disk», pero requiere una operación táctil mucho más complicada que pulsar la barra de espacio. Esta complicación es intencional, ya que la operación simula el común acto de arrastrar un objeto de la vida real a otro sitio. Pero, aun así, la analogía no es completamente intuitiva: en la vida real, arrastrar un objeto no lo copia. Y, con la evolución de las GUI desde Xerox Parc a través del primer Macintosh hacia paradigmas más contemporáneos de barras de herramientas, múltiples escritorios, integración con el navegador web, uno ya no puede sentar un analfabeto digital delante de una GUI y decirle que piense en ella como si fuera un escritorio de la vida real. Al margen de lo acertado de esta clase de analogías, el uso de la GUI es una técnica cultural tan construida y aprendida como lo es escribir instrucciones.

Por tanto, las categorías platónicas de la verdad no pueden evitarse del todo. Si bien la interfaz de línea de comandos también es una simulación – en concreto, la de una conversación telegráfica – sus expresiones alfanuméricas se traducen mucho más fácilmente en la operación numérica del ordenador, y viceversa. El lenguaje escrito puede usarse mucho más fácilmente para usar los ordenadores para aquello para lo que fueron construidos, para automatizar tareas de formateo: la operación «cp .txt /mnt/disk», que copia no sólo uno, sino todos los archivos de texto de un directorio a un disco montado sólo puede replicarse en una IGU encontrando, seleccionando y copiando a mano todos los archivos de texto, o usando una función de búsqueda o una función de script como una herramienta añadida. La extensión de la instrucción «for file in ; do cp $file $file.bak; done» no puede replicarse en una IGU a no ser que esta función haya sido ya programada en ella. En la línea de comandos, «usar» se extiende naturalmente a «programar».

En una perspectiva más amplia, esto quiere decir que las aplicaciones GUI son, típicamente, simulaciones directas de una herramienta analógica: el procesamiento de textos emula las máquinas de escribir, Photoshop el cuarto oscuro de un laboratorio fotográfico, el software de publicación digital una mesa de maquetación, los editores de vídeo un estudio de vídeo, etc. El software sigue anclado en una escaleta de tareas tradicional. Las herramientas equivalentes en la línea de comados – por ejemplo: sed, grep, awk, sort, wc para el procesamiento de textos, ImageMagick para la manipulación de imágenes, groff, TeX, o XML para la maquetación de documentos, ffmpeg o MLT para el procesamiento de vídeo – transforman el proceso de trabajo tradicional de la misma manera que «cp *.txt» transforma el concepto de copiar un documento. El diseñador Michael Murtaugh, por ejemplo, usa herramientas de línea de comandos para extraer automáticamente imágenes de una colección de archivos de vídeo para generar galerías o composites, un concepto que, sencillamente, excede el paradigma de un editor gráfico de vídeo, con su concepto predeterminado de qué supone la edición de vídeo.

Las implicaciones de esto llegan mucho más lejos de lo que pueda parecer a primera vista. La interfaz de línea de comandos provee funciones, no aplicaciones; métodos, no soluciones, o: nada más que un montón de plug-ins para ser promiscuamente enchufados unos en otros. La aplicación puede construirse, y la solución puede ser inventanda, por los propios usuarios. No es una interfaz empaquetada, o, – tomando prestados los términos de Roland Barthes – una interfaz «legible», sino «escribible». Según la distinción que hace Barthes entre literatura realista frente a literatura experimental, el texto legible se presenta lineal, compuesto suavemente, «como una despensa donde se guardan los significados, apilados, a salvo». 1 En cambio, al reflejar la «pluralidad de puntos de entrada, la apertura de redes, la infinidad de lenguajes» 2, el texto escribible intenta «convertir al lector no en consumidor, sino en productor del texto». 3 Además de la caracterización que hace Umberto Eco de la línea de comandos como una interfaz iconoclásticamente «protestante», y la GUI como idolátricamente «católica», la GUI podría calificarse como Tolstoi, o como Toni Morrison, y la línea de comandos como Gertrude Stein, «Finnegans Wake», o la poesía L.A.N.G.U.A.G.E. de las interfaces informáticas. O, también, el paradigma Lego de un juguete auto-definido frente al paradigma Playmobil de un juguete predefinido.

La ironía está en que el paradigma Lego había sido el objetivo de diseño inicial de Alan Kay para la interfaz gráfica de usuario en Xerox PARC en los años 70. Basado en el lenguaje de programación Smalltalk, y haciendo uso de la programación orientada a objetos, aquella GUI debía permitir a los usuarios conectar sus propias aplicaciones a partir de módulos preexistentes. En sus formas populares en Mac OS, Windows, o KDE/Gnome/XFCE, las GUI nunca cumplieron esa promesa, y en cambio reforzaron la división entre usuarios y desarrolladores. Incluso excepciones marginales del propio sistema de Kay – que sigue vivo en el proyecto «Squeak», y los entornos de programación multimedia gráficos de Miller Puckette «Max» y «Pure Data» manifiestan la limitación de las GUI para operar también como interfaces de programación gráfica, ya que ambos siguen requiriendo programación textual a nivel de la sintaxis base. En términos de programación, la GUI refuerza la separación entre la UI (la interfaz de usuario), y la API (la interfaz de programación de aplicaciones), mientras que en la línea de comandos, la propia UI es la API. Alan Kay reconoce que «no sería sorprendente que el sistema visual fuese menos capaz en este área [el de la programación] que el mecanismo que resuelve oraciones sustantivas en el lenguaje natural. Aunque no sería justo decir que los ‘lenguajes basados en iconos no funcionan’ sólo porque nadie haya sido capaz de diseñar uno bueno, es probable que la explicación anterior esté cerca de la verdad». 4

 

Mutant

 CORE CORE bash bash CORE bash

 There are %d possibilities.  Do you really  
 wish to see them all? (y or n)

 SECONDS  
 SECONDS

 grep hurt mm grep terr mm grep these mm grep eyes grep eyes mm grep hands  
 mm grep terr mm > zz grep hurt mm >> zz grep nobody mm >> zz grep  
 important mm >> zz grep terror mm > z grep hurt mm >> zz grep these mm >>  
 zz grep sexy mm >> zz grep eyes mm >> zz grep terror mm > zz grep hurt mm  
 >> zz grep these mm >> zz grep sexy mm >> zz grep eyes mm >> zz grep sexy  
 mm >> zz grep hurt mm >> zz grep eyes mm grep hurt mm grep hands mm grep  
 terr mm > zz grep these mm >> zz grep nobody mm >> zz prof!

 if [ "x`tput kbs`" != "x" ]; then # We can't do this with "dumb" terminal  
 stty erase `tput kbs`

 DYNAMIC LINKER BUG!!!

Codework de Alan Sondheim, enviado a la lista de correo «arc.hive» el 21 de julio de 2002

En una terminal, las instrucciones y los datos pasan a ser intercambiables. En la instrucción «echo date», «date» es el texto, o datos, que tiene que aparecer como resultado de la instrucción «echo». Pero si el resultado se vuelve a enviar al procesador de la línea de comandos (también conocido como shell) – «echo date -sh» – «date» se ejecuta como una instrucción en sí. Esto quiere decir: se pueden construir instrucciones de líneas de comandos que mezclan datos introducidos, texto, en nuevas instrucciones para ejecutarlas. Al contrario que en las GUI, hay recursividad en las interfaces de usuarios: las instrucciones pueden procesarse a sí mismas. Photoshop, en cambio, puede manipular sus propios diálogos gráficos, pero no puede después ejecutar estas mutaciones. Tal y como dice el programador y administrador de sistemas Thomas Scoville en su artículo de 1998 «The Elements of Style: UNIX As Literature», «Las herramientas de sistema de UNIX son como un kit de Lego para escritores. Tubos y filtros conectan una utilidad a la siguiente, y el texto fluye, invisible, entre ellas. Trabajar con una shell, con derivados de awk o lex, o con la herramienta set, es literalmente como bailar con palabras.» 6

En el net.art, «OSS» de jodi es lo más cercano a una hipotética GUI que se devora a sí misma, manipulando con Photoshop sus propios diálogos. El entorno de la línea de comandos de Unix/Linux/GNU es exactamente eso: un procesador de texto gigante en el que cada función – buscar, reemplazar, contar palabras, ordenar líneas – ha sido externalizada a un pequeño programa, cada uno representado por una instrucción de una sola palabra; palabras que pueden procesar palabras tanto como datos [correo electrónico, documentos de texto, páginas web, archivos de configuración, manuales de software, código fuente, por ejemplo] como las palabras en sí. Y, para más «shocks» culturales para la gente que no está acostumbrada a ella: con SSH o Telnet, cada línea de comandos pasa a ser «transparente a la red», esto es, cada instrucción puede ejecutarse tanto localmente como remotamente. «echo date – ssh user@somewhere.org» construye la instrucción en la máquina local, la ejecuta en la máquina remota somewhere.org, pero devuelve el resultado otra vez en la terminal local. Instrucciones y datos no solamente pueden mutar unos en otros, sino que instrucciones y datos en máquinas locales se pueden mezclar con los de máquinas remotas. El hecho de que ARPA – y, más tarde, Internet – fuera diseñado para computación distribuida se hace tangible a nivel microscópico en el espacio entre palabras, de una manera mucho más radical que en paradigmas monolíticos como «subir», o «aplicaciones web».

Con su hibridación de código y datos locales y remotos, la línea de comandos es el sueño húmedo de un poeta electrónico, «codewoker» o net.artista ASCII hecho realidad. Entre las «constricciones» poéticas inventadas por el grupo OULIPO, aquellas que son puramente sintácticas se pueden reproducir fácilmente en la línea de comandos. «POE», un programa diseñado a principios de los 90 por los poetas experimentales austriacos Franz Josef Czernin y Ferdinand Schmatz para asistir a los poetas con el análisis y construcción lingüísticos, acabó siendo, sin ninguna intención, una herramienta de texto Unix para DOS. En 1997, el poeta underground norteamericano ficus strangulensis hizo un llamamiento para la creación de un «sintetizador de texto», que es lo que la línea de comandos Unix realmente es. Por tanto, la «netwurker» mez breeze apunta, como principales influencias culturales en su trabajo net.poético «mezangelle» a «#unix [shelled + otherwise]», junto a «#LaTeX [+ LaTeX2e]», «#perl», «#python» and «#el concepto de ARGS [con un potencial todavía por realizar]». 7 En la dirección contraria, desarrolladores de C obfuscado, poetas Perl y hackers como jaromil han mutado sus programas en net.poesía experimental.

Las mutaciones y recursiones en la línea de comandos ni son una coincidencia, ni son agujeros de seguridad, sino herramientas que los administradores de sistemas necesitan a diario. Tal y como dice Richard Stallman, fundador del proyecto GNU y primer desarrollador de los programas de línea de comandos GNU, «es un poco paradójico que puedas conseguir definir algo en términos de sí mismo, que esa definición tenga sentido. […] El hecho de que […] puedas definir en términos de sí mismo y definirlo bien así, esa es una parte fundamental de la programación.» 8

Cuando, como observa Thomas Scoville, el vocabulario de instrucción y sintaxis como la de Unix pasa a ser «algo natural», 9 también se convierte en lenguaje conversacional, y la sintaxis se convierte en semántica no a través de algún tipo de inteligencia artificial, sino en términos pop culturales, como pasaba con las máquinas de escribir mutantes en la adaptación cinematográfica de «El almuerzo desnudo» que hizo David Cronenberg. Estas máquinas de escribir, literalmente «buggy», quizás sean el icono más potente del texto escribible. Y, aunque el software libre no se limite, de manera alguna, a las terminales – Unix empezó como software privativo – no dejar de ser esa cualidad escritora, y esa deconstrucción de la dicotomía usuario/consumidor, lo que hace que el software libre/de código abierto y la línea de comandos sean íntimos compañeros de cama.

[Este texto deliberadamente reutiliza y muta algunos pasajes de mi ensayo «Exe.cut[up]able Statements», publicado en el catálogo de ars electronica de 2003.]
 

Referencias

[Bar75] Roland Barthes. S/Z. Hill and Wang, Nueva York, 1975.

[Ben97] David Bennahum. Interview with Richard Stallman, founder of the free software foundation. MEME, (2.04), 5 1997. http://www.ljudmila.org/nettime/zkp4/21.htm.

[Kay90] Alan Kay. User Interface: A Personal View. En Brenda Laurel, editor, The Art of Human-Computer Interface Design, págs. 191-207. Addison Wesley, Reading, Massachusetts, 1990.

[Sco98] Thomas Scoville. The Elements of Style: Unix as Literature, 1998. http://web.meganet.net/yeti/PCarticle.html.


Notas a pie de página:


  1. [Bar75], p. 200
  2. [Bar75], p. 5
  3. [Bar75], p. 4
  4. [Kay90], p. 203
  5. Codework de Alan Sondheim, enviado a la lista de correo «arc.hive» el 21 de julio de 2002
  6. Thomas Scoville, The Elements of Style: Unix As Literature, [Sco98]
  7. Inédito en estos momentos, por publicar en la web http://www.cont3xt.net
  8. [Ben97]
  9. [Sco98], ibid.

Programar es difícil, pero no imposible

¿Que aún no sabes programar? ¿Cómo es posible? Todos deberíamos programar. Los diseñadores, a programar porque si no no hablaréis el mismo idioma que los desarrolladores. Las mujeres, venga ya chicas si es muy fácil y sabemos que sólo os gustan las cosas si son fáciles. Los niños de cuatro años, pero ¿a qué estáis esperando? ¿no os gustaría ser CEOs de una empresa a los once? Desde luego si no sabes programar es porque no quieres, todo el mundo lo hace… ¡es muy fácil! MENTIRA.

Ya está bien de endulzar una práctica como la programación para que se subestime y de esta forma resulte más popular. Ya está bien de construir falacias acerca de la tecnología. Programar es difícil. Programar requiere de entender bien el problema que se quiere resolver, de ser capaz de diseñar y expresar la solución en un lenguaje de programación (ahí los hay más sencillos o más complejos) y de ser capaz de validarlo a prueba de fallos.

¿Qué es programar?

Hace poco me preguntaron cómo explicaría a una persona que no sabe nada de programación qué es programar. Mi respuesta fue más o menos esta:

Programar es la forma que tenemos de decirle a una máquina (generalmente un ordenador) lo que debe hacer y cómo debe hacerlo, a este conjunto de instrucciones lo llamamos programa. Es lo que hace posible que tengamos aplicaciones en el móvil, que tengamos Facebook, o que tengamos coches autoconducidos. El lenguaje de programación más básico es el binario, unos y ceros (pasa o no pasa corriente por un circuito), pero esto es muy difícil de manejar por humanos. Por esto se crearon lenguajes de programación de alto nivel, más cercanos al lenguaje natural, de forma que las instrucciones que escribimos se traducen automáticamente al binario y con la ventaja de que aprenderlo sea tan fácil como aprender un idioma. Como con los idiomas existen muchos lenguajes de programación, algunos de ellos están especializados en tecnologías diferentes, por ejemplo, para web, videojuegos, procesamiento de datos, etc. Pero la gran mayoría tienen muchas características en común.

Para programar se requiere desarrollar un pensamiento abstracto a diferentes niveles, a veces necesitarás conocimiento matemático, otras veces del lenguaje natural, otras veces de las arquitecturas sobre las que programas, otras sobre las personas que lo utilizarán… y otras veces todo a la vez.

Sin embargo,  no es imposible aprender a programar y depende mucho del lenguaje y entorno de desarrollo que lo hagas. Requiere práctica y tiempo para asimilar ciertas ideas, como todo. Hay ciertos lenguajes que son más agradecidos al principio, al igual que tocar el piano no requiere de técnica para ‘escuchar’ los primeros sonidos, hay lenguajes de programación que permiten ‘ver’ rápidamente los resultados como pudiera ser Javascript. No podemos olvidar que tanto el piano como la guitarra requiren años de maestría para poder crear buenas melodías y donde el estilo musical es importante.

¿Debería aprender a programar?

Depende. Si alguna vez te has preguntado esto imagino que es porque en algún momento te has planteado acercarte a alguna disciplina relacionada con la tecnología directa o indirectamente, o simplemente porque tienes un smartphone, una consola, una tablet y sientes curiosidad por saber qué pasa ahí dentro.

Saber programar tiene claros beneficios psicológicos, te prepara mejor para el mundo laboral del futuro y te ayudará a desarrollar tus propias ideas.

No necesitas estudiar una Ingenería para aprender a programar, las Ingenerías persiguen dotar de unos conocimientos más amplios sobre tecnología a quienes las cursan y programar es tan sólo la herramienta fundamental que hace tangible su trabajo.

Los lenguajes de programación pueden ser expresados tanto por ingenieros/as, como por artistas, científicos/as, estudiantes, administrativos/as, filósofos/as y cualquier otra persona que tenga un ordenador propio y tiempo para dedicarle.

Aprender programación es una de esas cosas que cada vez más están al alcance de cualquiera, existen cientos de recursos online, nunca antes la experiencia del aprendizaje había sido tan accesible y si de algo versa la web es de contenidos relacionados con la programación.

La oportunidad para adquirir este conocimiento es clara, las posibilidades de lo que se puede hacer son infinitas y la necesidad de diversificar las aplicaciones, los enfoques y las personas que la usan como herramienta creativa o de trabajo es cada vez más acuciante. No puedo más que animarte a intentarlo, a probarlo durante un tiempo. Empieza por resolver un problema que tengas tú, diviértete y coge soltura. Y sobre todo comparte.

No es fácil, pero sí posible.

Qué se aprende en un meetup

Los encuentros de tecnología que se organizan a través de la web Meetup en la ciudad de Málaga han crecido como la espuma en los últimos dos años. Yes We Tech, Databeers, Scala, Frontend, Digital Marketing e incluso comunidades con más recorrido como GDG se han pasado a esta plataforma para anunciar sus eventos. Cada semana hay al menos un meetup al que asistir y una oportunidad de aprender algo nuevo.

Pero ¿qué se aprende en un meetup realmente? Los beneficios de ir a uno de estos encuentros más allá de los contenidos residen en el networking en sí mismo. Si un meetup no favorece a que la gente interactúe entre sí, personalmente no iría, pero vamos a analizarlo desde sus diferentes perspectivas.

Asistentes

  1. Networking. Oportunidad de conocer y darme a conocer en un plano profesional.
  2. Practicar. Si es un taller, me permite practicar una herramienta o adquirir unos conceptos básicos.
  3. Escuchar. Inspiración o descubrimiento, pero dificilmente podré aprender algo si no lo continúo en casa.

Ponentes

  1. Hablar en público. Practicar habilidades de comunicación en público, importantísimas.
  2. Venderse. Oportunidad de contar tus proyectos, experiencias, opiniones sobre un tema profesional.
  3. Feedback. Recibir feedback de la asistencia sobre un tema que te interesa particularmente.

Organizadores

  1. Liderar. Llevar la iniciativa y así posicionarte en la comunidad tecnológica.
  2. Innovar. Poder establecer un punto de vista diferente sobre las formas en las que se llevan a cabo estos eventos.
  3. Networking++. Oportunidad de conocer a muchas más gente de forma cercana.

 

Para mí son muchos los beneficios que tiene participar en cualquiera de sus roles en un meetup. Sin embargo, no todo es tan perfecto e ideal y debemos ser selectivos para no acabar intoxicados por el presencialismo en las comunidades. Hay ciertas cosas que deberían evitarse en mi opinión cuando se hacen meetups, también desde sus diferentes posiciones.

Asistencia

  1. Ir, escuchar y marcharte. A no ser que no te haya gustado nada de lo que has visto, recibir información y no aportar nada es una forma de menospreciar el valor del encuentro. La gente quiere conocerte y escucharte, ése es el objetivo del evento.
  2. Comentarios fuera de lugar. No ser conscientes de donde estamos o quiénes están a nuestro alrededor puede ser uno de los peores errores. Aunque haya cerveza no es un bar, aunque haya camaredería no son tus colegas. Siempre habla con respeto.
  3. Pasar de la charla. Ir a un meetup para no atender a la ponencia es una pérdida de tiempo y una intrusión para quienes sí quieren estar allí. Quédate en casa o espera al momento de la cerveza.

Ponencias

  1. No prepararte tu ponencia. No infravalores tu audiencia ni la oportunidad que se te da. Por pocos asistentes que creas que tienes o por muy experto/a que te creas, las ponencias hay que tratar de tenerlas preparadas. Si después salen mal no pasa nada.
  2. No incluir a los asistentes. La gente ha venido a escucharte, dales la oportunidad de ser escuchados, quizá te aporten más de lo que creas.
  3. No participar como asistente. Si te interesa una comunidad para dar una charla ¿por qué no para participar en ella? Ponte al otro lado sin ser protagonista y disfruta del encuentro.

Organización

  1. No avisar de la agenda. Algunos encuentros no son más que eso, encuentros, y no es necesariamente malo pero si el propósito es sólo conocerse avisa a la audiencia.
  2. No dar la bienvenida a las nuevas caras. Siempre hay gente nueva que se acerca tímidamente, y gente que viene por el networking, dales la oportunidad de presentarse.
  3. No contar cuáles son los valores de tu comunidad. Si mañana alguien organizara una comunidad sobre el mismo tema ¿por qué ir a la tuya? Si tu comunidad no tiene unos valores claros e interesantes, tu capacidad de convocatoria se verá debilitada.

En los últimos años he aprendido muchas cosas asistiendo, organizando e incluso impartiendo y me gustaría pensar que la gente a mi alrededor también. A veces algunos salen mejor que otros, se acierta mejor con los contenidos o con el formato o con la gente, pero es difícil de prever antes de asistir. Sin embargo están llenos de oportunidades que creo debemos trabajar más desde cualquiera de nuestros roles.

Desde luego si no te aportan nada es mejor no involucrarse, pero si lo haces, aprende, comparte y participa activamente.

 

 

Eventos y conferencias

Parece que la primavera trae consigo un periodo intenso de alergias y de concentración de eventos, meetups y conferencias profesionales. Desde hace cinco semanas tres de ellas han ocupado gran parte de mi tiempo, me gustaría compartir lo que he aprendido como organizadora, asistente y colaboradora.

Women Techmakers

El Women Techmakers tuvo lugar en Málaga el 1 de abril, en el Rayo Verde. Esta iniciativa de Google organizada por los grupos de desarrollo locales GDG se celebra todos los años con motivo del día de la mujer. Ésta es la segunda edición en la que Yes We Tech participa en la organización.

Lo mejor

  • 50/50 de participación y gran apoyo de la comunidad
  • Conocer nuevas mujeres que hacen tecnología en Málaga
  • Ponencias de excelencia que merecen aún más visibilidad, más tiempo y recursos
  • Colaboración entre comunidades tecnológicas locales

Lo peor

  • El formato irregular de las charlas hace difícil mantener el ritmo
  • El Rayo Verde no sirve para hacer un evento tan largo (ya que no permite el almuerzo dentro de sus instalaciones)
  • Algunas personas aún menosprecian el valor del evento y de tener una audiencia y ponentes profesionales

UX Spain

UX Spain es el encuentro de profesionales de la Experiencia de Usuario más importante de España. En esta edición reunión a unos 500 participantes y se quedaron en la lista de espera casi tantos como los que pudimos asistir. El UX Spain de 2017 se celebró el 12 y 13 de Mayo en Gijón.

Lo mejor

  • El encuentro, la gente, las ponencias… todo de 10 como siempre
  • Descubrir a alguien que no sabías ni que existía haciendo cosas alucinantes
  • La premisa de la organización de que debe haber paridad entre los ponentes
  • Saber con qué se están peleando el resto del país en temas de UX, dejando a un lado el hype

Lo peor

  • Las ciudad de Gijón tiene una malísima combinación de viaje
  • El centro de Gijón no estaba demasiado cerca del Palacio de Congresos
  • El derroche de testosterona de algún ponente demasiado encantado de conocerse

J On The Beach

J On The Beach es el evento tecnológico por excelencia en Málaga y se centra en temas de Big Data, IoT, DevOps, JVM, programación funcional y visualización de datos. Tuvo lugar en La Térmica el pasado 17-19 de Mayo. Yes We Tech formó parte del comité organizativo y celebramos un meetup durante las conferencias.

Lo mejor

  • Estar cerca de la gente que cuida su carrera profesional, que cree en Málaga como ciudad de innovación, que aporta y quiere aprender
  • Los ponentes y las ponencias de un nivel estratosférico
  • Una de las mejores organizaciones que he visto nunca desde la perspectiva de la experiencia del asistente: impecable
  • Es un encuentro internacional celebrado en una ciudad sin complejos
  • Conocer nuevamente a mujeres de otros países con ganas de dar caña a una red Yes We Tech global
  • El proyecto a modo hackathon que presentamos para Yes We Tech y el apoyo de nuestro core :_)

Lo peor

  • Los fallos técnicos que desmerecen a los ponentes al retrasar o desfavorecer sus charlas, fueron pocos pero los hubo
  • Los comentarios o salidas de tono de algún tío que aún no se da cuenta que a nadie le interesa sus complejos machirulos
  • La falta de coordinación para poder descansar y disfrutar del evento desde la organización, acabamos todos exhaustos física y mentalmente.
  • Las realidades de algunas empresas malagueñas que aún tratan a sus empleados y empleadas de forma desconfiada

Conclusiones

En las últimas semanas he dedicado mucho tiempo personal en formar parte de la comunidad profesional, siempre es enriquecedor por quién llegas a conocer, por cómo puedes ayudar a otros y otras a relacionarse, a aprender y a hacer networking. Sin embargo, hace falta una pausa para reflexionar y volver a lo básico, a las raíces, y sobre todo para no agotarse.

En temas de igualdad hay luces y sombras y mucho que hacer. En esta especie de burbuja de los eventos donde tus oportunidades laborales y profesionales parecen depender tan claramente de a quién conozcas y por dónde te dejes caer es más importante que nunca que las mujeres estemos aquí. También me hace reflexionar si no estaremos contribuyendo a una desigual forma de acceder a puestos de trabajo.

Por otra parte, como co-organizadora creo que si el equipo no comparte 100% unos valores básicos sobre la identidad y el saber-hacer del evento, se corre riesgo de implosión. Me gustaría que el próximo evento que co-organice empiece precisamente por poner en común estas ideas.

Por ahora volveré a nuestros modestos meetups a los que estáis todas y todos invitados y en los que espero poder reforzar el core de Yes We Tech para que la comunidad se sienta más cerca que nunca.

Building your own tools with existing software

I’m sure you’re sick to death to hear whether designers should learn to code or not.

To me, coding skills have let me create my own designer toolkit by reusing and extending current software tools. Have you ever imagine how cool would be to become your own user while developing a solution?

At the moment there are thousands of open-source apps available for anyone to improve them. Some of them do just basic things like To-Do lists apps and others are a bit more sophisticated like Chats.

I’m not even talking about libraries and that crazy need of knowing the whole universe of packages and extensions of a programming framework. I’m talking about already built-in solutions with a purpose, with an API, and with an easy-to-consume documentation.

This is an experiment that I love to make from time to time: just pick an existing tool, see the code, imagine a different purpose with the current interaction model, a different way of using the visual grammar and customise it to see how the UI paradigm will work for a different goal.

If you include yourself as the target user, as a designer no one better than you what you want and need so, you can go ahead and create something fantastic to make your life easier, funnier or more productive.

Designer, you have the power of imagination, the good habits of a well-stablished UX process, and a strong creativity and ability to conceptualise things that most people can hardly envision, you just need to know the keys to play with the code and cross the red line.

It is to me the funniest way to learn.

Soon I’ll share my latest experiment: buidling my own UX testing framework 😉