El pulgón

Dani había plantado algunas habas y judías en unas mesas de cultivo que tenía instaladas en su terraza. Llevaban ahí unas semanas y ya estaban creciendo sanas y hermosas.

Pero una mañana se encontró las hojas de las habas arrugadas. Parecían enfermas y débiles. Las observó de cerca y vio centenares de diminutos insectos.

Dani empezó a frotar las hojas de las habas y justo en ese momento David, su vecino, salió a la terraza contigua.

—¿Qué haces? —preguntó.
—Mato bichos —respondió Dani.
—Eso que ataca a tus habas es pulgón —aclaró David—. Las mariquitas comen pulgón, así que no es necesario que lo mates hoja por hoja.

Al día siguiente Dani dedicó toda la mañana a buscar mariquitas por el campo. Apenas consiguió una docena, pero se dirigió a casa y las soltó junto a las habas.

David, de nuevo, lo vio desde la terraza vecina.

—¿Qué haces? —preguntó.
—He traído mariquitas.
—Las mariquitas vienen solas, no es necesario que las vayas a buscar —sentenció David.

Dani se percató que efectivamente alguna mariquita se acercaba a sus habas por si sola; pero inmediatamente era atacada por ¿hormigas? Hasta ese momento no se había fijado, pero la mesa de cultivo no sólo estaba infestada de pulgón

—¿Las hormigas comen pulgón? —preguntó a David, que aún permanecía en la terraza.
—No —respondió—, los pulgones excretan sustancias dulces que gustan a las hormigas. Simplemente están protegiendo su rebaño.

Dani entendió. Si mataba el pulgón conseguiría ahuyentar también las hormigas. Al día siguiente fue a una droguería, compró insecticida y empezó a rociar todas las hojas.

David estaba de nuevo en su terraza.

—¿Qué haces? —preguntó como siempre.
—Mato el pulgón y las hormigas.
—También estás matando las mariquitas —dijo David—. Sin mariquitas volverá el pulgón y con él las hormigas.

Dani, visiblemente cansado (y algo preocupado de que David no le quitara el ojo de encima en todo el día), se sentó en una silla y contempló triste su mesa de cultivo.

Hasta ese momento no se había dado cuenta que por una de las patas de la mesa subía y bajaba la hilera de hormigas.

Tuvo una idea.

Fue a la cocina a por unos tarros anchos, levantó la mesa de cultivo, puso cada pata dentro de un tarro y los llenó de agua. Las hormigas empezaron a agolparse en los bordes, incapaces de seguir subiendo por la patas de la mesa.

—¿Qué haces? —preguntó de nuevo David, que seguía en la terraza.
—Mato pulgón —respondió Dani.

David sonrió y entró en su casa.

No quiero usar Google+ Hangouts

Actualización: Desde que escribí esta entrada se han hecho cambios que afectan a mi opinión sobre este servicio: Google ya no requiere la utilización de tu nombre real ni la vinculación obligatoria con una cuenta de Google+. 

Cada vez es más habitual que algunos de mis clientes utilicen Google+ Hangouts para su mensajería instantánea y videoconferencia.

Y siempre hay un silencio incómodo cuando yo les digo, tímidamente, que no quiero utilizar Google+ Hangouts.

No tengo nada especial en contra Google. Al menos nada que no tenga contra otras muchas empresas. Tengo un teléfono Android, una cuenta de Gmail y miro vídeos de gatos en Youtube. Y cada vez me importa menos que Google sea una empresa que eluda el pago de impuestos en España, que abuse de su posición dominante para entrar en otros sectores, que lógicamente acate las peticiones de censura de los gobiernos de turno o que contribuya a nuestro humano sesgo de confirmación de forma artificial. Todo esto es lo mismo que hace Microsoft, Apple o Amazon. Son problemas importantes, pero no son mi preocupación principal.

Lo que me molesta es que el precio a pagar por usar un servicio aparentemente gratuito sea nuestra privacidad.

Puede parecer anecdótico, pero Google+ Hangouts guarda todas las conversaciones textuales que hacemos a no ser que indiquemos lo contrario. Esto significa que aunque a nosotros no nos interese guardar una conversación, puede que nuestro interlocutor sí lo esté haciendo. Esta información se guarda con su perfil de Google y ayuda a la empresa a seguir definiendo una identidad digital para esa persona.

Nada impide técnicamente, obviamente, que Google haga lo propio en un futuro con las conversaciones de voz.

Pero esto es sólo la punta del iceberg. Quien quiera unirse a una reunión con Google+ Hangouts debe tener una cuenta de Google+. Vamos, que el asistente acaba:

  • Con una cuenta de correo electrónico de Google (Gmail)
  • Dado de alta en una red social generalista como Google+ (ya no), donde es requisito utilizar el nombre real (ya no) y donde el perfil obligatoriamente es público.
  • Aceptando unos términos y condiciones que, entre otras cosas, dan el consentimiento a la empresa a utilizar datos personales explícitos (datos introducidos) e implícitos (datos recogidos como la posición geográfica, historial de búsquedas, etc.) para ofrecer resultados de búsqueda relevantes y publicidad personalizada.

Yo he pasado por todo esto. He hecho reuniones vía Google+ Hangouts. He creado perfiles falsos en Google+. Pero el tema está en que no quiero volver a hacerlo. Me molesta. Me indigna vender mi privacidad para algo tan mundano como una videoconferencia. Pero este mi problema, mi decisión. Lo verdaderamente grave es contribuir a que otras personas se sientan prácticamente obligadas a hacer lo mismo en un entorno donde es tan complicado decir “no” como es el profesional.

Y me encantaría acabar ofreciendo la solución, esa perfecta alternativa a Google+ Hangouts de protocolo abierto, descentralizada, libre, extendida y útil.

Pero si existe no la conozco.

¿Pero implica eso no hacer nada? Existen opciones cojas pero que, al menos, no obligan a los participantes de la reunión a registrarse en ningún sitio. Todos conoceréis cuáles son.

Layers en Axure

Si hay algo que me revienta de las herramientas de prototipado en general, y de Axure RP en particular, es el sistema de creación de layers.

En Axure RP si queremos crear un layer dinámico, esto es, una simple capa o ventana modal que aparece o desaparece según ciertas condiciones, nos vemos obligados a que al prototipar esté presente en el diseño de la pantalla que lo usa.

Esto, hasta donde yo sé, es inevitable, pero utilizo algunos “trucos” para hacerlo más llevadero:

  1. Cada layer es un master que contiene un dynamic panel oculto predeterminadamente (“Set hidden”) con todos los contenidos dentro.
  2. Si hay algún elemento dentro el propio layer que lo cierra vía OnClick, se define la interacción dentro el propio master con dos acciones: ocultar el panel dinámico de marras y enviarlo al fondo (“Hide Panel” y “Send Panel to Back”)
  3. Todos los layers usados habitualmente se introducen en un nuevo master “padre” con un comportamiento “Place in background”.
  4. Se incorpora el master “padre” a las pantallas necesarias.
  5. Cuando se deba mostrar un layer se define una interacción que muestre el panel dinámico, lo mande a primer plano y lo mueva al punto requerido (“Show Panel”, “Bring Panel to Front” y “Move panel”).
  6. Toda interacción que deba existir entre el layer y la ventana se define mediante raised events.

Todo esto puede parecer un poco engorroso, pero…

  • Tener un panel dinámico en el propio master permite que ocultar el layer sea responsabilidad del propio layer, así definimos la interacción una sola vez.
  • Tener todos los masters juntos permite agilizar la creación de nuevas pantallas. De esta forma no tenemos que estar continuamente añadiendo masters y en el momento de definir una interacción están todos presentes.
  • Que el master sea un “Place in background” nos permite trabajar con la pantalla sin que sus layers nos molesten.
  • Usar el z-indez (“Bring Panel to Front” y “Send Panel to Back”) asegura que el layer no se sitúe por debajo de otros elementos interactivos cuando está visible o quede accidentalmente por encima cuando está oculto.
  • Usar el “Move panel” nos permite que la posición del layer sea dinámica y a la vez tener todas las ventajas anteriores.

Y recordad que las interacciones no es necesario definirlas una y otra vez. Los casos (“case”) se pueden copiar/pegar o, incluso, introducir en un image map que, a su vez, podría ser un master. Este último ya me parece especialmente rebuscado y no lo he hecho nunca, pero imagino que si se quiere trabajar a un nivel de interacción de muy alta fidelidad puede ser útil.

En Axure RP 7 hay interesantes novedades sobre este tema, así que con un poco de suerte esto se vuelve obsoleto en poco tiempo.

Interfaces adaptativas

Hace casi ya 3 años, cuando Ethan Marcotte se sacó de la manga el “Responsive Web Design” tomó prestada la idea de otro sitio, de algo llamado “responsive architecture”.

Esta arquitectura “sensible” es un planteamiento basado en intentar romper la rigidez clásica de los edificios y otorgarles cierta capacidad de adaptación que les permita responder a necesidades inmediatas de sus usuarios y no únicamente a las necesidades genéricas, determinadas durante el proceso de diseño.

El palabro parece que fue inventado por Nicholas Negroponte, quien ya escribía sobre ello en los 70, intentando buscar una forma de humanizar la relación entre la gente y las construcciones. Un objetivo, la humanización, compartido con los diseñadores de interfaces, quienes justamente investigamos a los usuarios, sus tareas y sus cosas para obtener unos requisitos que serán la semilla de una interfaz.

Lo problemático es que nuestro proceso de investigación, como tantos otros, se nutre de muchas técnicas basadas en la categorización o la determinación de “acuerdos”. Un ejemplo son las personas de Cooper, con las que intentamos reducir la complejidad y disparidad de los usuarios a unos pocos perfiles; o los análisis de clustering de card-sorting, con los que determinamos el nivel de “acuerdo” existente sobre la estructura organizativa de ciertos conceptos.

Este proceso de investigación no deja de ser, y perdonad la expresión, un “café para todos”, que además cuenta con el agravante, digno de Capitán Obvio, de ser previo al propio uso de la interfaz.

¿Podríamos dotar a las interfaces de cierta capacidad para entender las necesidades particulares de los usuarios en un momento y lugar determinado? La respuesta es sí, y tampoco es nada novedoso, tenemos otro palabro para ello: “interfaces adaptativas”, cuya implementación se ha limitado tradicionalmente a preguntar al usuario en tiempo de ejecución “¿y tú quién eres?”

Un sitio web de una entidad financiera, con su típica dicotomía “Particulares” y “Empresas” podríamos considerarlo un ejemplo rudimentario de interfaz adaptativa. Otro, algo más “inteligente”, es el de una aplicación de salud que a partir del login del usuario ofrece opciones para médicos o enfermeros según corresponda. Pero yo creo que nuestra meta debería ser ir más allá, imitar esa arquitectura “sensible” en la que obviamente el usuario no se limita a elegir, sino que es el propio edificio quien se adapta y muta en función de las necesidades inmediatas.

Y no, no me estoy subiendo al carro de “eliminar la interfaz”, o al menos no de lo que yo entiendo por interfaz (que considero que pese a su etimología va mucho más allá de una mera superficie de contacto). Hablo de crear interfaces que, al estilo de la interfaz predictiva de Mathematica o Google Now de Android, tengan capacidad de anticipación para poder ofrecer al usuario información y acciones que tengan sentido en ese particular momento, en su contexto ambiental, social, organizativo y personal.