L.

La tecnología de la vigilancia

Camiseta morada TENCEL™ mensaje iridiscente in 2020 | Mens tops, T ...
Run to become less digital, enjoy the outdoors. – Camiseta deportiva Oysho.

Run to become less digital. Enjoy the outdoors.

Lema estampado en una camiseta deportiva

Hace unos meses compré una camiseta que me alentaba a practicar más ejercicio en el exterior. Mientras disfrutaba de mis paseos diarios con mi bebé no me podía imaginar lo que se nos venía encima a nosotras y a todo el mundo. Hoy volveremos a salir a la calle y posiblemente la semana que viene los adultos podamos también volver a enjoy the outdoors para become less digital. Sin embargo, aunque nos llene de emoción, aún estamos lejos de la nueva normalidad. Lejos de visitar a nuestros padres, abrazar a nuestros amigos y hacer algún viaje de vacaciones o lo que se nos ocurra.

La razón son más de veinte mil muertos en España y más de dos cientos mil en el mundo por culpa de una enfermedad de la que aún se sabe muy poco causada por un virus áltamente contajioso y del que también se sabe muy poco.

Enfrentarse a lo desconocido nos produce muchas emociones, dicen los expertos, perfectamente normales si añadimos que llevamos casi dos meses encerrados en nuestras casas. Incertidumbre, ansiedad y extrañeza son las más habituales. Si esto se alargara, la solución de salir a la calle no sería suficiente y habría que acudir a otros métodos.

Estos días hemos visto cómo en la industria de la tecnología, incluyo diseño y desarrollo de software y hardware, se han llevado a cabo muchas iniciativas para aportar. La energía de la gente y la solidaridad son abrumadoras y esperanzadoras y un gran valor de nuestra cultura, así como la responsabilidad individual para mantenernos sanos y a salvo. Evidentemente las ha habido de muchos tipos y no todas ellas iguales de efectivas, pero siempre bien intencionadas.

Sin embargo, hay una parte sel sector privado, incluyo start ups y estudios de diseño, que han encontrado su momentum justo ahora. En tiempos de pandemia, sentían que su forma de aportar era vendernos alguna receta mágica en forma de app móvil que se una a la ola de confusión e incertidumbre. Pero quién puede criticarlas, la economía se hunde y hay que “flotar” como sea, donde sea y a costa de quién sea.

La tecnología al rescate

Una de las soluciones que más me ha llamado la atención y preocupa es la idea de la vigilancia como solución a una desescalada del confinamiento.

Tal como lo expresé, todo es hipotético, ya que hay muchos ejemplos no me voy a centrar en uno solo. Esta hipotética solución incluiría:

  • Rastrear el movimiento de las personas usuarias (por Bluetooth de forma anónima preferiblemente).
  • Solicitar datos relacionados con tu estado de salud.
  • Analizar datos masivos estadísticamente para toma de decisiones.
  • Solicitar consentimiento voluntario.

A cambio, ofrecerían las siguientes ventajas:

  • Sugerir posibles áreas seguras para los desplazamientos.
  • Avisar de posible contagio si has estado cerca de personas que hayan dado positivo.
  • Permiso de movilidad mediante un carnet/pasaporte.

Hay muchas cosas que me aterran de esta forma de enfocar el problema y de las soluciones mínimas y viables.

  • Pérdida del derecho a la intimidad e incluso a la protección de datos personales dependiendo de la implementación.
  • Concesión de derechos humanos fundamentales a cambio de la demostración de un estado de salud.
  • Uso discriminatorio de tu nuevo carnet/permiso de movilidad.
  • Penalización por la falta de consentimiento al no compartir la información requerida.
  • Juicio rápido por parte de las fuerzas de seguridad y consecuentes penalizaciones.
  • Legalidad y normalización del estado de vigilancia de forma ininterrumpida.
  • Uso de software privativo para la gestión de la información y desarrollo de la solución.
  • Obligatoriedad del uso de los dispositivos móviles personales para la garantía del servicio (en un país en el que no existe si quiera el derecho al acceso a Internet).
  • Falta de transparenia de los algoritmos de decisión que harán uso de la información solicitada.
  • A medida que se sepa más de la enfermedad, modificación de la implementación incluyendo criterios que puedan resultar discriminatorios por cuestión de género, edad o lugar de nacimiento, entre otras.

¿Qué hacemos entonces?

Teniendo en cuenta que hay poco movimiento reivindicativo en nuestro sector que haya luchado por una clara participación en el sector público, creo que la primera cosa por la que deberíamos luchar hasta cansarnos es para que la inversión en ciencia sea real. Más y más ciencia es la única solución a la enfermedad y la muerte.

La tecnología, open source a ser posible, debe ayudar a desarrollar esa ciencia con seguridad y eficacia, de llevar su aplicación a la gente de forma satisfactoria y sencilla. Toda esa ciencia y esa tecnología deberían en mi opinión estar trabajando sin descanso para:

  • Buscar una vacuna.
  • Buscar medicamentos paliativos.
  • Prevenir y detectar casos antes de que se sucedan.
  • Generar conocimiento para mejorar las decisiones derivadas de otra posible pandemia.
  • Analizar los factores que nos hacen ser vulnerables como individuos y sociedad.
  • Analizar el impacto de las decisiones tomadas.
  • Ayudar a la gente a adoptar con más rapidez y eficacia nuevos comportamientos sociales e individuales de forma colaborativa que ayuden a una organización comunitaria más eficiente.
  • Ayudar a las empresas, sobre todo pequeño comercio, a una adaptación más eficaz de sus modelos de negocio para garantizar la calidad del servicio y la supervivencia de las familias a las que sustenta.

La política tendrá por su parte que resolver el asunto económico y financiero con con su comité de expertos correspondiente y decidir si el tejido industrial debe ser o no revisado para una mejor recuperación y una mayor supervivencia en futuras crisis.

Ahora sí: Design Thinking

Por supuesto, si hay algo que desde el sector del diseño deberíamos intentar hacer es realizar un buen análisis del problema, pensando en las personas, en su entorno, en sus relaciones y experiencias vividas. Entender bien lo que les exigimos cuando usan la tecnología y lo que les aporta, el impacto en las formas de vida y las implicaciones políticas que hay que asumir o reivindicar.

Realicemos estudios de investigación de calidad, olvidémonos del agilismo tóxico de hackaton que sólo nos lleva a soluciones cortoplacistas cuya validación provoca más incertidumbre en la ciudadanía.

Hagamos diseño centrado en personas y no dirigido por el negocio necesariamente. Eso es para mí un diseño con espíritu de servicio público y universal.


Nada de esto es fácil, yo no he hecho mucho más aquí que expresar mi opinión y enumerar ideas con el único ánimo de aportar y hacer una reflexión pausada teniendo en cuenta que, como todo el mundo, me encuentro encerrada y desconcertada. Si hay mejores ideas me encantaría escucharlas y pensarlas. Gracias por compartir.

c.

connecting.the.dots.01

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

Steve Jobs

No hay nada más vulgar que una diseñadora citando a Steve Jobs. Y además de vulgar me sirve de inspiración para titular esta mini serie donde comentaré alguno de los enlaces ya compartidos por redes sociales que me han resultado de especial interés, incluyendo reacciones y contexto. Al lío.

Read more
P.

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
N.

Not a single design process

We spend years and years exploring, trying and following guidelines about what’s right and wrong to do when “doing UX”. We look for the perfect process, the one that tells you: yes, you’re following a user-centred design methodology that will ensure the best user experience possible.

But let’s face it: there’s no one single process that helps you to solve any and every single problem, and not all designers can and must follow the same creativity path to build good solutions.

So what shall we do then? My suggestion, follow principles, not processes and get alignment, not agreement.

Read more
D.

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
6.

6 examples of bad dashboard designs

Dashboards are used to present large amounts of information in a condensed and visual form. 

They are meant to be represented on a single screen, to make an efficient use of the space, avoid superfluous graphics and include actionable, meaningful and relevant data according to viewers objectives.

However, we can find some examples where dashboards display the information in the wrong way. These are some examples of bad designs that can make a nicely intentioned dashboards fail.

1. Tiny and spaced

Yet the dashboard is displayed in one single screen, the amount of white space between charts make it difficult to read as unique piece of information. Increasing font-size and adjusting proportions would make it more efficient.

Resultado de imagen de dashboard opensource
Pentaho Dashboard
Read more
O.

Opensouthcode: resultados de la encuesta y datos de la experiencia

task performance opensouthcode survey

El pasado 1 de Junio mi colega Miguel Torres y yo hicimos una presentación en el evento sobre software libre Opensouthcode y hablamos sobre cómo podíamos analizar la Experiencia de Usuario (UX) con Javascript (JS). Durante nuestra charla presentamos un modelo con el que tomar métricas automáticas de usabilidad para poder conocer mejor a las personas que interactúan con nuestros productos digitales construidos con tecnologías web.

Al final de la presentación hicimos una demostración de cómo podía aplicarse a un caso real y para ellos utilizamos como excusa una encuesta que habíamos lanzado semanas antes. La encuesta no serviría más que a la presentación, sin embargo, ya que un buen número de personas se molestaron en contestarla, es nuestro deber compartir la información que recogimos.

Es importante aclarar que la forma en la que almacenamos los datos fue un poco peculiar, y por peculiar me refiero a que usamos el mismo Google Analytics, un servicio en principio destinado a analítica web. En cualquier caso, aquí están los resultados.

Read more

R.

Reinventando los ‘formularios’ de registro

Daily UI Design Challenge es una suscripción de correo que te envía a tu buzón un reto de diseño cada día durante 100 días. Personalmente no creo que pueda seguir el ritmo, pero sentí curiosidad por saber qué es lo primero que mandarían y he aquí el reto: Diseñar un formulario de registro.

Sign-up Forms

A mí me gustaría darle una vuelta a este reto y re-imaginar otra vez los formularios de registro por varias razones:

  • Los encuentro contra intuitivos: no existe una necesidad de identificarse sino de ser identificados
  • A los usuarios no les gusta dar sus datos una y otra vez para acceder a los servicios de una web

Read more

R.

Retrospectiva

Hace un año cambié de trabajo. Buscaba fundamentalmente dos cosas esenciales para mí:

  • Un buen proyecto con vida
  • Un buen ambiente de trabajo

Un buen proyecto

En mis anteriores años como diseñadora he pasado demasiado tiempo creando ‘conceptos’ que nunca terminaban viendo la luz. No se vendían, se cancelaban a mitad de desarrollo, nacían muertos, no terminaban, no se implantaban de forma adecuada… A pesar del rodaje y de lo mucho, muchísimo, que se aprende en esas circunstancias necesitaba recuperar el contacto con el mundo real, ése en el que tu trabajo impacta en la vida de un producto digital, en el que tus errores y tus éxitos tienen consecuencias y en el que se puede ver el valor de cada decisión.

Empezar a trabajar en un servicio online me ha dado la posibilidad de:

  • Tomar mejores decisiones en base a datos de analítica web
  • Experimentar con métricas de UX para medir la adopción de nuevos diseños
  • Asumir las consecuencias de una mala decisión y rectificar
  • Establecer un modelo de trabajo y un proceso de diseño que se ajuste mejor a un entorno de despliegue contínuo
  • Integrarme en un equipo de desarrollo bien engranado con la menor fricción posible
  • Disfrutar del resultado en equipo y del impacto que tiene el diseño y el desarrollo en el propio negocio
  • Hacer más ingeniería del software de la que me imaginaba

Evidentemente hay cosas que no he podido conseguir aún y que me gustaría conseguir este año:

  • Mejorar la consistencia total de la interfaz de usuario y las comunicaciones con los clientes
  • Eliminar todos los elementos excesivos del diseño
  • Homogeneizar la navegación y los patrones de interacción
  • Aumentar el nivel de detalle y excelencia visual
  • Aumentar la satisfacción de los usuarios en su experiencia global con los productos y servicios digitales
  • Crear una plataforma totalmente flexible para que se adapte mejor al flujo de trabajo de cada usuario

Un buen ambiente

El segundo aspecto era igualmente importante ya que en la anterior empresa en la que estuve, pasada la euforia startupera y la motivación por la belleza de un producto tecnológico intelectualmente desafiante, la oficina se convirtió para mí en un lugar anodino, aburrido y tóxico. No puedo culpar ni exculparme. Los egos chocaban, no se tomaban (buenas) decisiones y no se veían los frutos por ningún sitio. Cuando esas circunstancias se dan lo mejor que se puede hacer es usar la poca energía que queda y marcharse con la lección aprendida, en lugar de resistir hasta el agotamiento (si las circunstancias personales te lo permiten claro).

Pero he tenido mucha suerte y quiero pensar que he trabajado para progresar. Cambiar de empresa, de cultura y de oficina es una apuesta muy fuerte que se hace con muy poca información (a penas alguna recomendación de trabajadores que conozcas y lo que captes durante el proceso de selección). Aunque en realidad el aspecto más desafiante es mantener y contribuir al ‘buen ambiente’ ante cualquier circunstancia.

 

Hace un año me propuse hacer retrospectiva como forma de disfrutar de los éxitos profesionales conseguidos y entender bien qué cosas me estoy dejando a medio camino o en tierra de nadie. Hoy ha pasado un año desde que dije adiós a la firma ITRS, y decidí apostar por la fintech Ebury. No puedo estar más satisfecha de este año e ilusionada por lo que queda por delante, espero que sigan confiando en mí porque aún no he terminado con este proyecto 🙂

(.

(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.