Una breve introducción a Agile, parte 1

El término Agile es cada vez más común en una gran cantidad de escenarios y contextos distintos a los del mundo de desarrollo de software donde tuvo su origen, incluido el de Experiencia de Usuario.

Contrario a lo que comúnmente se interpreta de primera instancia, Agile no se trata simplemente de cómo desarrollar productos de forma rápida. Agile busca, en esencia, transformar paradigmas y organizaciones para propiciar entornos de trabajo con personas felices, motivadas y comprometidas, logrando en consecuencia, productos exitosos y clientes satisfechos.

Contexto histórico sobre Agile

Actualmente, Scrum, Kanban y eXtreme Programming (XP) son los enfoques o frameworks más representativos de Agile; sin embargo, otros métodos relativamente emergentes que incorporan en su definición parte de los conceptos clave del Agilismo han ganado una creciente popularidad, sobre todo en el ecosistema del emprendimiento, como Lean Startup, Lean UX o Design Sprint.

Más allá de los frameworks, la verdadera naturaleza de Agile radica en la profunda transformación de la manera en la que pensamos y nos comportamos. Es decir, el Agilismo no sólo consiste en la adopción de procesos y herramientas, sino en un cambio de cultura, verdadero, profundo y significativo.

Para comprender los motivos por los cuales Agile hace un llamado al cambio de paradigmas, es necesario hacer un recuento de su origen y evolución porque, como decimos en UX, el contexto lo es todo.

El Modelo en Cascada y los antecedentes de Agile

Explicar qué es Agile implica ineludiblemente hablar primero de su némesis: el Modelo en Cascada. De la misma forma en que no es posible explicar La Fuerza sin el Lado Oscuro, para entender el surgimiento de Agile, es importante comprender las razones de su origen, aquello a lo que trataba de oponerse.

El Modelo Secuencial de Procesos o Modelo en Cascada (Waterfall Model) es un modelo metodológico de la industria de desarrollo de software que surgió en la década de los 70. Sin entrar demasiado en detalle (porque para eso está Wikipedia) el Modelo en Cascada propone una serie de pasos, rigurosamente en secuencia, para el desarrollo de software:

  • Especificación de requerimientos
  • Diseño
  • Implementación
  • Verificación
  • Mantenimiento
Modelo en Cascada
Modelo en Cascada

 

Lo que vale la pena destacar del Modelo en Cascada es que, de alguna u otra forma, surgió como una herencia del pensamiento Taylorista, que tuvo su máximo esplendor durante la Revolución Industrial, y que definía a los procesos como una división de tareas bajo un ambiente rígido. En el Taylorismo, las personas no tenían participación ni control en los procesos, “todo lo que queremos de ellos (los obreros) es que obedezcan las órdenes que les damos, que hagan lo que les decimos y que lo hagan rápido“, decía Frederick Taylor en 1906.

Recreen en su mente la mítica escena de Charles Chaplin en Tiempos Modernos. Eso es el Taylorismo. Reemplacen la cadena de montaje por líneas de código. Eso es el Modelo en Cascada.

Escena del largometraje Tiempos Modernos (1936).
Escena del largometraje Tiempos Modernos (1936).

La razón por la que la naciente industria del software de la década de 1970 consideró que era buena idea adoptar un modelo secuencial, rígido y que restringía tanto la libertad y creatividad de las personas sigue siendo un misterio y quizá el mundo nunca lo sabrá.

Es tan controversial el tema sobre cómo fue posible que el Modelo en Cascada se haya convertido en un estándar de la industria del software, que existen varios mitos alrededor, uno de ellas señala que desde su origen, el modelo fue malinterpretado y que su autor, Winston Royce, en realidad quiso decir que el modelo era una mala idea y que no era recomendable implementarlo pues “invitaba al fracaso”. No es broma. Incluso el Departamento de Defensa de los Estados Unidos, en 1985,  tuvo esa “interpretación” incorrecta y estandarizó su propio proceso para el desarrollo de software basado en el modelo de Royce y como suele ocurrir con casi todo, el resto del mundo siguió el mismo estándar.

Las circunstancias del contexto también pudieron influir notablemente en la estandarización del Modelo de Cascada, piensen en la alocada década de los 70: la tecnología era accesible sólo para unos pocos privilegiados; apenas eran los albores de Internet; Steve Jobs y Bill Gates eran un par de jóvenes que iniciaban la construcción de los imperios de Apple y Microsoft, respectivamente. Si lo vemos en perspectiva, el Modelo en Cascada se convirtió en el modelo más utilizado simplemente porque en ese momento se concebía al software como algo tan complicado, grande y robusto que sólo era posible producirlo bajo un proceso riguroso y detallado.

Uso de la tecnología a principios de la década de los 70.
Uso de la tecnología a principios de la década de los 70.

Al paso de los años, el mundo empezó a cambiar drásticamente gracias a una vertiginosa revolución de las Tecnologías de la Información. La tecnología llegó a la vida cotidiana y el cliente empezó a convertirse paulatinamente en el centro del universo en el desarrollo de productos y servicios.

Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.
Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.

La industria del software tuvo que empezar a adaptarse al nuevo escenario y los problemas del Modelo en Cascada comenzaron a emerger:

  • Poco o nulo involucramiento del cliente a lo largo del proceso.
  • Limitación de la participación activa de las personas responsables del desarrollo.
  • Incapacidad de responder satisfactoriamente ante cambios de negocio.
  • Documentación excesiva del proceso.
  • Tiempos demasiado largos de producción.
  • Recuperación tardía y costosa ante errores.

La caja de Pandora fue abierta.

Los orígenes de Agile

El Movimiento Agile surgió como una reacción de hartazgo a todo lo que significaba el Modelo en Cascada.

Para muchos expertos, el año 1994 representa el punto de quiebre en la historia del Agilismo, cuando todos los problemas que el Modelo en Cascada venía arrastrando por más de dos décadas quedan exhibidos en CHAOS Report, un estudio que reveló una cifra contundente e irrefutable:

más del 80% de los proyectos de software se entregaban con sobrecostos, en forma tardía, sin cumplir las expectativas de los clientes o incluso eran cancelados antes de concluirse.

La industria del software estaba en crisis, empezaron a surgir o a cobrar notoriedad métodos alternativos al Modelo en Cascada como Scrum, eXtreme Programming (XP) y Lean Software Development, por citar algunos. La nueva “sombrilla” de métodos empezaron a ser identificados con el nombre de Metodologías Livianas (Lightweight Methodologies). Comenzaba así la versión en el mundo del software de Civil War, o eras #teamwaterfall o eras #teamagile.

Hay que abrir un breve paréntesis en esta línea del tiempo. Aunque muchos métodos relacionados con Agile empezaron a ser cada vez más populares a partir de la década de los 90, no significa que hayan sido creados simultáneamente, algunos conceptos clave surgieron desde mucho tiempo atrás:

El siguiente hito en la historia del Agilismo llegó en el 2001 cuando un grupo de profesionales y entusiastas de los métodos livianos se reunieron “en lo alto de una montaña” (como suele contar Mike Beedle) para discutir cómo la industria del desarrollo de software debería hacer frente al nuevo contexto, cómo responder de mejor forma a los cambios que surgían por intereses de negocio y cómo consolidar una alternativa los procesos tradicionales de desarrollo de software caracterizados por la rigidez de su proceso. El Manifiesto Ágil vió la luz.

El Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software…

Así inicia el Manifiesto Ágil, el documento que representa la declaratoria de principios de todo lo que significa el Agilismo.

Cuatro valores y doce principios. Es todo. Por más de 15 años, cada línea escrita en el Manifiesto Ágil ha permanecido intacta. Señal de su vigencia y pertinencia.

Valores:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Principios:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Waterfall vs. Agile

Lo que siguió después de la aparición del Manifiesto Ágil fue una disputa cada vez más frontal por la supremacía en la industria de desarrollo de software entre Waterfall y Agile; de manera simultánea, el mundo seguía cambiando, llegó el mundo de los dispositivos móviles, de las apps y startups.

En la versión 2012 del CHAOS Report (ahora llamado CHAOS Manifesto) se publicó una conclusión simbólica sobre la batalla entre Waterfall y Agile:

El proceso ágil es el remedio universal para el fracaso en los proyectos de desarrollo de software. Las aplicaciones de software desarrolladas a través del proceso ágil tienen tres veces la tasa de éxito del método en cascada tradicional y un porcentaje mucho menor de demoras y sobrecostos. El software debería ser construido en pequeños pasos iterativos, con equipos pequeños y enfocados”.

Parecía que la batalla tenía un ganador.

Ser Agile vs Hacer Agile

Ante el éxito de los métodos ágiles en la industria del software, su popularidad y adopción traspasaron fronteras. El ecosistema de emprendimiento y otras industrias distintas a las del desarrollo de software empezaron también a abrazar las prácticas ágiles. Hacían lo correcto, aunque por las razones incorrectas.

La promesa de ser el “remedio para el fracasso en los proyectos” comenzó a ser una carga muy pesada para el Agilismo y para lo que, insisto, realmente significa.

En 2015, otra vez el CHAOS Manifesto dió a conocer una cifra reveladora:

61% de los proyectos ágiles, son ágiles solamente en el nombre.

El Agilismo verdadero es orgánico, emerge, fluye; simplemente ocurre o perece en el intento. Es independiente de cualquier práctica dogmática, por encima incluso, de un “dogma ágil”, por contradictorio que esto parezca. Individuos e interacciones sobre procesos y herramientas. El origen de todos los males de la práctica incorrecta del Agilismo radica en la inadecuada comprensión del Manifiesto Ágil y todo lo que conlleva.

Agile no es una metodología. No es una colección de procesos y herramientas. Agile es un mindset, una forma de pensar y actuar distinta para encontrar mejores formas de hacer las cosas a través del empirismo y el aprendizaje.

La verdadera promesa de Agile

Quiero concluir con una cita del libro Por un Scrum Popular: Notas para una Revolución Agile, de Tobias Mayer y traducido al español por Alan Cyment:

“Pinten en el aire una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente donde se fomenta la escucha activa, la comunicación abierta y la colaboración a mansalva.

Estoy convencido de que se puede convertir esta imagen en realidad usando un mecanismo simple y conocido, que les permitirá llegar desde su crudo presente hasta ese sitio donde les gustaría estar. Y no, ese mecanismo no se llama Scrum.

No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión. Hay una sola persona que puede hacer realidad esta visión. Ese alguien eres tú”.

Espero que este llamado, los haga pensar en abrazar el Agilismo por las razones correctas.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Diseñando la web física

La Internet de las Cosas –Internet of Things, o IoT– es la promesa de que en algún momento los objetos cotidianos que nos rodean estarán conectados a la red mundial de datos. Aunque esta visión aún no llega por completo, la Web Física –Physical Web– es un paso importante para volverla tangible.

La Web Física (Physical Web)  podría sonar como un intento de darle un nombre distinto al Internet de las Cosas, aunque es realidad es una parte de ésta. Internet y la Web no son lo mismo, son diferentes entidades donde la primera se refiere a la tecnología e infraestructura que hace posible la red mundial de comunicación; la segunda se refiere a un servicio de transmisión de datos con la que se puede interactuar a través de un navegador web, o browser.

De  manera análoga, Internet de las Cosas es una colección de objetos inteligentes que se están conectando rapidamente a Internet, y la Web Física nos permite tener acceso e interactuar con esos objetos a través de un navegador web de una manera simple e intuitiva.

Web física en un iPhone  Web física en Android

Una solución de Web Física se basa en tres componentes:

1. Objetos inteligentes

El primer componente de la Web Física son esos objetos inteligentes que mencioné antes, que son pequeños dispositivos capaces de emitir una señal de corto alcance usando Bluetooth a otros dispositivos que se encuentren cerca, como smarthphones, para interactuar con ellos con información que obtienen de Internet.

Beacon comunicándose con una app
Un beacon comunicándose con una app

Los beacons son un buen ejemplo de estos objetos, además de que son baratos y sencillos de instalar. Algunos beacons tienen sensores que les permiten detectar su ubicación geográfica, medir la temperatura ambiente donde están instalados o detectar si otros dispositivos alrededor suyo se están acercando o alejando de ellos.

Tal vez el principal problema de los beacons es que para proveer una experiencia de usuario enriquecida dependen de que los usuarios tengan instalada un app en su móvil con capacidades para reconocerlos y comunicarse con ellos. Si el usuario no tiene la app o no puede instalarla, el beacon es invisible para él.

2. Direcciones web

URLPara resolver este problema, la Web Física utiliza como segundo componente una dirección web o URL. Los objetos inteligentes en la Web Física envían constantemente una dirección web que cualquier dispositivo cercano al objeto puede recibir; la idea es replantear los sitios web móviles para que muestren información relevante a un usuario en una ubicación física, por ejemplo: junto a una máquina expendedora, un poster, una parada de autobús o una cafetería, sin necesidad de que los usuarios descarguen una app primero sino que utilicen una app que ya está en su dispositivo: su browser.

3. El navegador web

Navegadores web para móvilEl tercer elemento de la Web Física es el navegador web del smartphone, que toma el lugar de la app en esa conexión con un beacon e interpreta la dirección que se le envía para abrir una página móvil específica para el contexto del usuario.

El navegador es capaz de detectar los beacons de Web Física alrededor suyo y mostrar su información ordenada por una combinación de factores como proximidad, intensidad de su señal, las preferencias del usuario, su historial de búsqueda y de navegación.

Al seleccionar un enlace de Web Física en una parada de autobús podría mostrar los horarios de los autobuses y un mapa con sus rutas. Una máquina expendedora podría ofrecer una página web para seleccionar y comprar un producto, o un parquímetro puede dirigir a su usuario a una página para pagar por tiempo de estacionamiento:

A donde sea que cada dirección web dirija, toda la interacción ocurrirá dentro del navegador web sin necesidad de que el usuario descargue una app especial para cada experiencia.

* * *

Comenzar a experimentar con la Web Física es muy sencillo: toda la información técnica está disponible en GitHub y hay una guía para comenzar desde cero en ese mismo sitio. Muchos beacons comerciales como BKON, Estimote y GemTot ya son compatibles con sus protocolos.

Aunque el planteamiento de la Web Física suena simple, aún se tienen que resolver los problemas que ya existen con la web móvil como privacidad, SPAM, problemas de usabilidad y de conectividad antes de que el concepto despegue del todo.

La idea de la Web Física es crear un estándar abierto que eventualmente pueda integrarse en cada dispositivo y navegador, y así comenzar a conectar la web con el mundo allá afuera.

 

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

Aplicaciones web progresivas, el retorno de la web al móvil

Durante años los sitios web ha sido relegados en los dispositivos móviles sobre las apps nativas debido a problemas de rendimiento, compatibilidad y, sobre todo, de conectividad. Las aplicaciones web progresivas (progressive web apps) prometen resolver estos problemas.

Las aplicaciones web progresivas (progressive web apps) son un acercamiento al desarrollo de apps para móviles que combinan lo mejor de la web y lo mejor de las apps nativas. Estas nuevas web apps son útiles para sus usuarios desde la primera visita en un navegador web, sin necesidad de instalar nada más.

A medida que el usuario crea una relación con la app de manera progresiva, ésta se vuelve más poderosa y útil: carga rápidamente, incluso en redes lentas o cuando el dispositivo está desconectado, puede enviar notificaciones, tiene un icono en la pantalla del móvil y funciona a pantalla completa.

Funcionamiento de una app web progresiva

Una aplicación web progresiva es:

  • Estándar – utiliza la misma plataforma y tecnología que se utiliza para crear páginas web: HTML, CSS y Javascript.
  • Progresiva (¡obvio!) – funciona para todos los usuarios, independientemente de cuál navegador web o sistema operativo utilice, porque está construída para mejorar progresivamente desde el principio.
  • Responsiva – se ajusta a cualquier resolución y formato de pantalla: escritorio, móviles, tabletas, televisiones o lo que sea.
  • Independiente de la conexión – está mejorada con service workers para funcionar sin conexión o en redes lentas con conexiones intermitentes.
  • Como una app nativa – el usuario la usará como una app, con soporte para navegación e interacción con gestos.
  • Fresca – siempre estará actualizada gracias al proceso automático de actualización del service worker.
  • Segura – trabaja sobre HTTPS para prevenir que alguien intercepte datos y para asegurarse de que el contenido no ha sido manipulado por otros.
  • Descubrible – es identificable como una “aplicación” gracias al manifiesto de la W3C y al registro de funciones del service worker, permitiendo a los buscadores web encontrarlas.
  • Interactiva – hace fácil interactuar con ella incluso cuando está cerrada con características como notificaciones tipo push.
  • Instalable – le permite a sus usuarios crear accesos directos en la pantalla de su teléfono sin necesidad de una tienda de apps.
  • Enlazable – se pueden compartir fácilmente usando su dirección en la web (URL) y no requiere procesos de instalación complejos.

Ya existen casos de empresas que han comenzado a implementar apps web progresivas, como AirBerlin o Flipkart con resultados bien documentados en mejoras de experiencia de usuario, retención y conversión.

Apps web progresivas

Google creó un taller para aprender a crear aplicaciones web progresivas desde cero, incluyendo consideraciones de diseño y detalles de implementación para asegurar que tus web apps cumplan todos los principios que mencioné arriba.

Las aplicaciones web progresivas son una oportunidad para regresar a la web su importancia dentro de dispositivos móviles -o en cualquier otro dispositivo-, y de romper los problemas y  dependencias de compatibilidad que tienen las apps nativas.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

Lenguajes para prototipado: Jade

El diseño de experiencia de usuario es, por necesidad, una labor colaborativa y multidisciplinaria. Si decimos que ‘todos somos diseñadores’, ¿por qué no todos podemos también aportar código?

Un equipo que realiza diseño centrado en el usuario debe de contar entre sus miembros con al menos un diseñador que materialize la parte visual del proyecto y un programador que realice la ejecución técnica.

Aunque todavía hay empresas que continúan en la búsqueda del mítico Unicornio de UXuna rara criatura, mitad diseñador y mitad programador-, para la mayoría de los equipos de UX uno de los principales retos es lograr que sus miembros puedan trabajar y comunicarse de una manera coherente.

En el caso de la relaProgramando en HTMLción del dúo diseñador / programador, uno de sus principales problemas es la capacidad de cada uno de generar código útil para producción, y es un problema porque la mayor parte de esa responsabilidad normalmente cae en el programador, que debe lidear con la complejidad de volver tangible una visión de diseño que surge de bocetos en papel, dibujos en un programa de diseño o en el mejor caso, de un prototipo cuyo código no es reutilizable.

Éste es en parte, un problema creado en parte por la formación de los diseñadores a los que les hacen creer que escribir código es algo complejo y en parte por la falta de herramientas correctas para diseñar código usable. Hay una larga lista de programas de diseño WYSIWYG (What you see is what you get – Lo que ves es lo que obtienes) que ofuscan el código para que el diseñador no lo vea, pero que al final producen código poco eficiente y complejo que el diseñador que lo hizo no puede entender y que para integrarlo a un producto real requiere retoques del programador que deberá darle mantenimiento en lo sucesivo.

Lo que ves es lo que quieres decir

Una buena práctica de desarrollo es la separación en capas de los componentes de presentación, contenido y lógica para asignar responsables a cada una y después integrarlos; así la actualización de una capa por mantenimiento no obliga a las otras a cambiar a menos que cambien los requerimientos del proyecto.

El desarrollo para web en el navegador está diseñado de esta manera, dejando el contenido a HTML, la presentación de CSS y la lógica de la aplicación a Javascript. Idealmente la generación de HTML y CSS debería ser lo suficientemente sencilla para el diseñador de manera que pudiera enfocarse en qué está haciendo, y no en cómo lo está haciendo.

Estructura de una página web con HTML, CSS y Javascript en archivos separados
Estructura de una página web con HTML, CSS y Javascript en archivos separados

Para lograr eso es necesario dejar los generadores de código visuales WYSIWYG por el modelo WYSIWYM (What you see is what you mean – Lo que ves es lo que quieres decir). En este modelo el diseñador se encarga de introducir el contenido de forma estructurada siguiendo su valor semántico en lugar de indicar su formato de representación final.

Jade – un lenguaje sencillo para plantillas web

Logo de JadeUna herramienta que puede servir justo a este propósito es Jade, un sistema para generación de plantillas HTML hecho para trabajar con NodeJS y que puede usarse como lenguaje para prototipado.

Jade utiliza un metalenguaje -casi mecanografía- basado en la notación de HTML que ha sido simplificado para ser breve, consciso y fácil de recordar.

Este es un ejemplo de una página web escrita en Jade:

doctype html
html(lang="es")
  head
    title Jade
  body
    h1 Jade - sistema de plantillas para Node
    #container.col
      if youAreUsingJade
        p ¡Gracias por usar Jade!
      else
        p Deberías usar Jade
      p.
        Jade es un lenguaje de plantillas práctico y simple 
        enfocado en tener buen desempeño y características poderosas.

que genera el siguiente código HTML:

<!DOCTYPE html>
<html lang="es">
  <head>
    <title>Jade</title>
  </head>
  <body>
    <h1>Jade - sistema de plantillas para Node</h1>
    <div id="container" class="col">
      <p>¡Gracias por usar Jade!</p>
      <p>
        Jade es un lenguaje de plantillas práctico y simple enfocado en tener un buen desempeño y características poderosas.
      </p>
    </div>
  </body>
</html>

Es así de simple.

Jade se encarga de generar código HTML bien formado. En un ejemplo para generar una lista numerada escribimos:

ol
 li Elemento A
 li Elemento B
 li Elemento C

que genera en HTML:

<ol>
      <li>Elemento A</li>
      <li>Elemento B</li>
      <li>Elemento C</li>
</ol>

Jade también pueden utilizar variables y condicionales de Javascript para generar código HTML según su configuración:

var user = { description: 'Usuario frecuente' }
var authorised = false
#user
 if user.description
   h2 Descripción
   p.description= user.description
 else if authorised
   h2 Descripción
   p.description.
     El usuario no tiene descripción, ¿por qué no añades una?
   else
     h1 Description
     p.description El usuario no tiene descripción

en HTML:

<div id="user">
     <h2>Description</h2>
     <div class="description">Usuario frecuente</div>
</div>

Existe documentación sobre cómo escribir en Jade, y en general se puede comenzar a utilizar en poco tiempo. No es necesario tener un servidor, se puede instalar de manera local en un equipo de desarrollo / diseño, y tanto NodeJS como Jade son gratuitos.

Jade puede ser una herramienta útil para prototipar y generar código para prototipos funcionales usando como guía los bocetos y prototipos en papel, los archivos de Jade son compactos, fáciles de leer por humanos y es muy sencillo editarlos y compartirlos.

Lo mejor es que el HTML generado por Jade puede integrarse después al código en producción con poco esfuerzo, ya que su salida es de alta calidad y es compatible con otras librerías y frameworks que se usan en desarrollo web como Bootstrap, JQuery o AngularJS entre otros.

¿Es esto suficiente para habilitar a los diseñadores a escribir código? Tal vez no, pero es un buen acercamiento a resolver el problema y una buena idea para prototipar rápidamente con código para que todos los miembros de un equipo y no solo los desarrolladores puedan aportar código útil a un proyecto.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

Validación de sitios para móviles

Los dispositivos móviles, y en particular los smartphones, están dominando la web. Hoy más que nunca es muy importante asegurarnos que nuestros sitios web sean compatibles con estos dispositivos.

En los últimos años hemos visto un cambios importante en las preferencias de navegación de los usuarios de la web, donde se nota una tendencia de migración clara de los equipos de escritorio –workstations, laptops, etc.– hace los equipos móviles, y no parece que vaya a cambiar pronto.

En el estudio de AMIPCI en 2015 sobre hábitos de usuarios en México, el único segmento que registró crecimiento en su uso fue precisamente el de los smartphones, y creció a costillas de los dispositivos de escritorio para colocarse en un 58% de preferencia de los mexicanos al navegar la web:

AMICPI dispositivos de conexion
A nivel mundial también es notable la preferencia de compra de los usuarios finales de dispositivos móviles (smartphones y tabletas) contra los equipos de escritorio, en una razón de casi 3 a 1:

PCs vs smartphones

Desde la perspectiva de experiencia de usuario, es importante revisar que nuestros sitios web estén construidos de forma que puedan verse y navegarse desde dispositivos móviles de manera sencilla y natural. Debemos tener en cuenta que el ecosistema móvil es mucho más diverso que el de las PCs al hablar de tamaño y resolución de pantalla, ancho de banda, capacidad de procesamiento, navegadores web y muchos otros factores.Les comparto algunas herramientas que les pueden servir para validar sus sitios móviles, al menos para comenzar a revisarlos:

Validador para sitios móviles de W3C

W3C Mobile Validator
W3C Mobile Validator

El Worldwide Web Consourtium o W3C es el organismo mundial que crea y mantiene los estándares técnicos de la web. Para ayudar a las personas que crean sitios web creó este validador de páginas web basado en la recomendación de MobileOk que revisa la estructura del código de una página y entrega un reporte donde indica el grado de cumplimiento de estándares en su codificación, el impacto de cada error y guías sobre cómo arreglarlo.

Lo encuentras en: http://validator.w3.org/mobile

Mobile friendly de Google Webmasters

Google Mobile Friendly Tool
Google Mobile Friendly Tool

En abril de 2015 Google anunció que el hecho de que un sitio web no se vea correctamente en dispositivos móviles comenzará a afectar su posicionamiento en los resultados orgánicos (no pagados) de su buscador, en caso que necesitaramos una razón de peso para optimizar y actualizar nuestros sitios web.

Para ayudar a los webmasters, Google agregó una herramienta de validación más cualitativa que la de W3C, que conecta la página validada con una granja de render de móviles de Google para entregar un resultado más enfocado en cómo ve la página el buscador y cómo la vería un usuario en su móvil. También tiene mucha documentación sobre cómo optimizar sitios web para móviles.

Lo encuentras en: https://www.google.com/webmasters/tools/mobile-friendly/

Responsinator

Responsinator
Responsinator

Esta herramienta sirve para simular cómo se vería una página web en diferentes dispositivos con diferentes tamaños, resoluciones y orientaciones. Aunque no es una manera definitiva de revisar el diseño de una página web, es una forma simple y sencilla de probar como se ajusta el diseño de un sitio a móviles si no tienes un teléfono de cada modelo a la mano para probar.

Lo encuentras en: http://www.responsinator.com

Test de velocidad de Rackspace

Prueba de velocidad de carga de Rackspace
Prueba de velocidad de carga de Rackspace

La velocidad cuenta mucho al navegar en un móvil. De acuerdo a Rackspace, actualmente un usuario tiene un rango de tolerancia entre 3 y 5 segundos para que un sitio móvil se visualice en su dispositivo antes de abandonarlo. La velocidad de carga de un sitio tiene que ver con muchos factores que van desde el ancho de banda en el servidor, la latencia de carga, el tiempo de renderizado y la carga del servidor, entre otros.

Rackspace creó una prueba de velocidad para sitios web en el que analiza varios componentes que afectan el tiempo de carga de un sitio y recomendaciones para mejorarla.

La encuentras en: http://www.rackspace.co.uk/ecommerce-hosting/page-speed-checker

* * *

Por supuesto, estas herramientas solo cubren una parte del análisis que se debe hacer a un sitio móvil y están enfocadas a la implementación técnica, no a la perspectiva del usuario, pero nos dan un punto de partida para poder analizar y mejorar de manera cuantitativa varios aspectos que sí afectan la experiencia de navegación de un usuario final.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

22 tutoriales en video sobre HTML5

Las habilidades de entender y desarrollar código no son ajenas a los profesionales de experiencia de usuario, aún cuando no tengan roles como programadores o diseñadores de interactivos.

Por eso, les compartimos 22 tutoriales en video sobre desarrollo web utilizando HTML5, CSS3 y Javascript (con algo de JQuery) hechos por Roma Mamukashvili.

  1. Cómo hacer un juego de “serpiente” utilizando HTML5, Canvas y JQuery
  2. Carrusel de imágenes con vista previa de imágenes con CSS3 y Javascript
  3. Barra de avance para formularios con pasos con JQuery y CSS3
  4. Efectos simples con filtros de CSS
  5. Cómo crear partículas en Canvas de HTML5
  6. Menú en Canvas con enlaces animados
  7. Cómo hacer gráficas de datos usando Canvas y Javascript
  8. Menú vertical con jQuery y CSS3
  9. Fuegos artificiales con HTML5, Canvas y Javascript
  10. Efectos interactivos en 3D para imágenes
  11. Efecto de nieve para Navidad usando Canvas y Javascript
  12. Efectos de animación de rejilla con jQuery y CSS3
  13. Cargador de Windows Phone con CSS3
  14. Animación de nubes de fondo con CSS3
  15. Pestañas para navegación con CSS3
  16. Un screensaver con HTML5 y Canvas
  17. Reloj con colores en hexadecimal con solo Javascript
  18. Bloques que rebotan con gravedad hechos con HTML5 y Javascript
  19. Funcionalidades básicas de HTML5
  20. Árbol genealógico con CSS3
  21. Menú sencillo hecho con CSS3
  22. Logo de Android en CSS3

Estos tutoriales también pueden servir como punto de partida si necesitan desarrollar algo rápido para sus proyectos web, y funcionan con todos los navegadores actuales y hasta con Internet Explorer 8.

Somos un grupo de profesionales de UX que trabajamos para fortalecer y profesionalizar a la comunidad de Experiencia de Usuario (User Experience) en español. Hacemos eventos en vivo por la noche para platicar de User Experience.

Cajeros automáticos centrados en el usuario

Imagínense nuevos cajeros automáticos (ATM – Automated Teller Machine) con una interfaz gráfica más comprensible, más accesible para cualquier tipo de usuario, en el que las personas no tardarán más 5 minutos para hacer sus movimientos, ¿no sería genial?

Justo leía una noticia sobre los nuevos cajeros interactivos que llegarán a México en 2016, pero hay que notar que la prensa exagera cuando usa el término “interactivo” como jerga informática.

Los cajeros (NCR interactive teller, Aptra series) que menciona el artículo cuentan con un par de años en la comunidad europea y Londres fue una de las primeras ciudades en contar con ellos (en México los podremos ver en Banamex, Banorte e Inbursa). Su principal innovación es tener una videoconferencia con un cajero humano: tener un chat con un asesor remoto que brindará operaciones que no están disponibles en uno convencional como retirar más efectivo del autorizado, expedir cheques y autorizar pagos. Esto no se escucha mal pero después de un poco de investigación éste es el único beneficio del que hablan sus creadores: ya no invertir en sucursales bancarias.

Es obvio que los costos operativos y de infraestructura de las sucursales bancarias son altísimos, (en parte porque ya se dieron cuenta que poner 10 cajas cuando sólo usan 3 es muy caro). El futuro del banco, como lo pintan, es contar con un enorme centro de atención personalizada: como un call center, pero con personas que te darán tu dinero.

Fernando Suárez, director de NCR México, comentó en entrevista a CNNExpansión. “Las sucursales sufrirán pocos cambios, pero sí vamos a empezar a utilizar productos como los cajeros automáticos interactivos. Es la tendencia mundial“. Tal vez en países de “primer mundo” esto sea viable, pero nuestra región, ¿estaremos preparados para este cambio?

Cajero interactivo

Hablemos más de lo que a nosotros nos interesa: dónde está el valor de la Experiencia de Usuario. Los cajeros automáticos son máquinas que vemos y usamos a diario –más los días de quincena– que han sufrido muchos cambios a nivel de software y hardware desde sus primeras versiones hace 40 años. Créanme cuando digo que ningún banco o fabricante de los cajeros le ha dado aún al clavo sobre cómo mejorar la experiencia en estos aparatos.

Estas son algunas acciones que los bancos deberían plantearse para poder implementar una buena experiencia para sus clientes al interactuar con los nuevos cajeros automáticos:

  1. La atención a clientes en los cajeros
    Los cajeros no son mágicos, y al usarlos hay que “migrar” los problemas de un call center convencional: la brusquedad en el  trato, la robotización de los agentes al contestar preguntas de manera programada, los cambios de acento por región y otras son cosas que odiamos de los call centers… y que seguro se migrarán al uso de los cajeros.
  2. Máquinas que funcionan con… ¿personas?
    Esto no es nada nuevo y no estoy nada a favor. ¿Cómo es posible que sigamos creando empleos que con personas que nunca ven la luz del sol? Ahora tendremos personas encerradas en un cubículo, esperando que llegues a sacar tus últimos billetes para el almuerzo.
  3. Horarios
    Sali a comerComo cliente de un banco yo esperaría que estos nuevos cajeros estuvieran disponibles todo el tiempo, pero ¿qué va a pasar por las noches? ¿Me va atender una persona en la India? Supongo que se mantendrán con el horario del banco (hasta las 17:30pm), aunque el valor del cajero automático es que está disponible todo el día.
  4. El Espacio-Tiempo
    Nadie ha podido descifrar por qué las personas se tardan tanto tiempo en las filas del cajero, pero seguro existe alguna formula para describir este comportamiento.Fila en el cajero automáticoAl implementar los nuevos cajeros, ¿cuál será el tiempo que una persona va a tardar en uno de estos dispositivos antes de que voltee a las ventanillas y las vea vacías? ¿Cuánto tiempo le tomará a los clientes del banco aprender a utilizar los nuevos cajeros? ¿Qué pasará cuando se descompongan?
  5. Menos sucursales, ¿menos seguridad?
    Seguridad bancariaUno de los costos más altos de un banco es el traslado de valores; llevar el dinero desde o hacia los cajeros como personal de seguridad o como cliente siempre ha sido y será una preocupación importante de ambas partes, y la nueva tecnología no resuelve nada en este aspecto.

Seguramente todos tenemos más preguntas o sugerencias al respecto, pero lo que no se debe olvidar es que la tecnología nos debe facilitar nuestra vida. En las últimas tres décadas la industria bancaria ha intentado sustituir a las personas por máquinas para trabajos mecánicos y repetitivos. Si estás leyendo en tu smartphone, ¿qué pasa con los pagos desde móviles? Creo que sería más económico -y seguro- fomentar el uso de este tipo de sistemas y terminales que aparatos de una tonelada.

Los líderes de la industria financiera siguen pensando en el pasado, en vez de pensar en que el Internet, las aplicaciones y los dispositivos están más a nuestro alcance. Creo que el camino de la banca móvil podría rendir más frutos y a la larga podría ser más económico para todos sin necesidad de revisar aspectos como los horario, la disponibilidad de los operadores humanos o el tiempo de espera para hacer transacciones, entre otras cosas.

A pesar de la marea tecnológica en la que vivimos, el abuso de la tecnología ha deshumanizado el trato a las personas en detrimento de su experiencia como clientes, y a veces perdemos la brújula de hasta dónde permita interactuar con otro ser vivo. ¿Quién ganará entre tratar con una persona directamente o por medio de una pantalla? Los usuarios del banco tendrán la última palabra.

Diseñador UI, analista de UX, creativo y estratega digital. Es parte del equipo de UX Nights.

Wearables – tomorrow

El mundo donde llevamos tecnología todo el tiempo a todas partes, es nuestra compañera en el día a día y la dejamos administrar nuestra vida no es algo del futuro: ya vivimos en él.

Esto no comenzó recientemente: a través de la historia la gente siempre ha tratado de llevar consigo conocimiento o ser capaces de desempeñar sus oficios en cualquier lugar. Un intento para logralo fue implementar ese conocimiento y herramientas en accesorios comunes de uso diario como brazaletes, anillos o collares. Los chinos fueron los pioneros en implementar estas prácticas, incluyendo ábacos y brújulas en accesorios personales desde el siglo XVII.

El brazalete fue la punta de lanza para promover el dispositivo de mayor demanda en el siglo XVIII: el reloj mecánico; aunque originalmente fue diseñado para uso exclusivo para la clase acomodada de la época, al volverse más barata su fabricación y parte de la vestimenta se convirtió en un objeto aspiracional y de deseo, elevándose al estatus de joya.

Entre las décadas de 1970 y 1980 se empezaron a desarrollar los primeros accesorios personales que incluían circuitos y procesadores como los de una computadora. Sin ir muy lejos, ¿quién no recuerda los relojes con calculadora o con sensor para la TV? Eran fascinantes y eran un artículo que definía a los verdaderos entusiastas de los gadgets de aquella época.

En la era de internet, los smartphones y las apps móviles funcionan como un puente para que otros dispositivos puedan estar conectados entre sí y entre ellos el reloj: un accesorio que las personas prefieren por ser práctico y sencillo de usar. Hoy existe una enorme variedad de dispositivos que se utilizan a modo de brazalete para medir y dar seguimiento a indicadores deportivos, de salud, de comunicación, ocio o entretenimiento. Estos dispositivos, mitad computadoras, mitad ropa los llaman wearables, o “computadoras corporales” y los relojes inteligentes o smartwatches son solo un miembro de una familia que está creciendo rápidamente.

Hace un mes comencé a utilizar el Moto 360 y en mi experiencia, el dispositivo es bueno pero no cumplió todas mis expectativas. Su sistema de notificaciones es lo que más vale la pena y me evitar estar sacando mi teléfono todo el tiempo. Es muy útil para responder mensajes por Whatsapp con respuestas rápidas como “Ok, Sí, No“, etc. y también se puede usar como disparador a distancia de la cámara del smartphone o para revisar el clima, notificaciones de correo o de redes sociales. ¡Hasta se puede consultar la hora en él!

Pero en una época donde la pérdida de energía de un dispositivo se ha convertido  un drama cotidiano me pareció frustrante que no contara con algún sistema de carga alternativo, ya que además de tener la preocupación de la batería del móvil ahora también debo preocuparme por la del reloj. La verdad dudo que alguien más esté dispuesto a pasar el doble de tiempo pegado a una pared para cargar ambos dispositivos.

Creo que nos depara un futuro donde la mayoría de nuestros accesorios – anteojos, carteras, hebillas de cinturón, ropa, entre otros- estarán conectados a internet todo el tiempo. Me parece curioso, sin embargo, que los fabricantes de esta tecnología “inteligente” promuevan en su publicidad a  las personas disfrutando de la vida mientras los aparatos les resuelven todo con un pequeño toque, cuando en la realidad parece que en lugar de simplificar la vida ¡estos dispositivos consumen demasiado tiempo de sus usuarios en ser configurados, sincronizados y en darles mantenimiento!

Hay un enorme campo de trabajo para llevar una buena experiencia a estos dispositivos y dentro de poco la  pregunta que los usuarios tendrán que responder será: ¿qué tanta tecnología quiero traer puesta?

Diseñador UI, analista de UX, creativo y estratega digital. Es parte del equipo de UX Nights.

Mapas Mentales

En muchos proyectos de tecnología no se genera una documentación inicial que englobe todos detalles que el producto debe de contener. Los mapas mentales son una herramienta útil para evitar huecos en el diseño de la experiencia del usuario.

El ámbito de la publicidad es muy común ignorar esos detalles, y se pasa directamente del brief del cliente al diseño y luego a desarrollo, sin ningún proceso de planeación.

Esta falta ocasiona que en la etapa de desarrollo aparezcan huecos que nunca fueron planeados: una sección adicional o procesos rutinarios como las pantallas de registro o recuperación de contraseña, pero que al no haber sido consideradas desde el inicio aumentan el tiempo del proyecto y con ello el stress y las pérdidas económicas de la agencia.

Una herramienta útil para evitar estos contratiempos son los mapas mentales. Con ellos podemos de forma creativa, lógica y organizada tener un vistazo completo a todas los elementos del proyecto.

Los mapas mentales parten de una idea central, de la que se desprenden los elementos que la integran, los cuales pueden ser, por ejemplo, las secciones de una página o funciones específicas de un app.

Mapa Mental
Mapa Mental para pedir pozole.

En la imagen podemos ver un mapa mental para una aplicación móvil ficticia para pedir pozole. En el mapa lo que encontramos no son los flujos del app, ni las secciones en específico, pero si los elementos que debe de contener. De esta forma este documento servirá de referencia para los diseñadores, desarrolladores y project managers que tendrán de una forma más sencilla una visualización lo que debe de incluirse en el producto.

El lápiz y el papel pueden usarse siempre para crear mapas mentales, pero quisiera recomendar un par de programas:

MindNode

MindNodeSin duda la mejor aplicación de su género para Mac y iPad, con la que hice la imagen de ejemplo del app pozolera. Es limpio y muy sencillo de utilizar, y permite personalizar con facilidad el look & feel de nuestros mapas. Existe una versión libre para Mac, pero limitada. Los documentos creados en MindNode Pro, la versión pagada de la app, se pueden compartir entre la versión de escritorio y la de iPad mediante iCloud.  En cualquier versión se puede exportar a documentos en formatos PDF, PNG, JPG o FreeMind.

FreeMind

FreeMindComo el nombre lo dice, FreeMind es una herramienta de software libre; está escrita en Java, lo que permite que se pueda utilizar en Windows, Mac OS y Linux sin costo. La herramienta es bastante buena y eficiente, pero la interfaz no es del todo amigable. Es una muy buena opción para empezar a implementar mapas mentales en nuestros proyectos.

UX Specialist en Foo Studio. Creador de geekoteca.com. Fan de LEGO